Bon bref, je m'arrête là, mais tout ça pour vous dire, que quand on vous dit d'aller vite et qu'il faut que ça sorte, battez vous pour obtenir du rabe si vous êtes limite et au pire, un délai après la sortie pour bien ré-architecturer et bien documenter ce que vous avez dégueulé en une demi journée.
Pas totalement d'accord sur l'approche de gratter du temps. Pour un projet il existe quatre variable d'ajustement: l'ensemble de fonctionnalités, la date de sortie, la vélocité, la qualité.
En général un produit est créé pour répondre à un besoin et il est totalement stupide d'utiliser la qualité comme variable d'ajustement. C'est assez facile à expliquer dans tout contexte qui n'est pas borné au court terme (coût du support, vélocité après quelque années, perte de clients, évolutions). Bref si on arrive pas à faire immédiatement oublier cette variable, il faut soit se remettre en question, soit partir direct. Attention on ne parle pas de faire quelque chose de parfait, mais quelque chose de viable dans le temps. Sortir un produit qui marche et qu'on pourra maintenir.
La vélocité étant assez difficile à maîtriser et à faire évoluer. C'est un objectif à long terme mais certainement pas une variable pour un produit. On cherche à la maximiser, et on l'ajuste pour la vision à long terme mais on ne s'en sert pas pour du court terme.
Il reste donc deux variables possibles et cohérentes: la date mais surtout les fonctionnalités.
Bien souvent il est plus facile et raisonnable de négocier les fonctionnalités qu'une date. On peut facilement expliquer ce qui coûte, pourquoi, comment on pourrait faire moins cher et laisser les gens choisir. On maintient la qualité constante, et on fait au mieux pour une date fixe. On pourra toujours compléter en gardant la même vitesse. Réussir à calculer une date pour une large ensemble de fonctionnalités contractuelle est beaucoup beaucoup plus difficile et plus mauvais pour le produit: obligé d'utiliser la qualité comme variable, ou prévoir des marges énormes. Mais dans ce cas, ça coûte très cher pour rien...
Il existe des cas ou ce n'est pas possible et où on va devoir fixer les fonctionnalités: Première livraison du sous ensemble de fonctionnalité minimum par exemple, contrat pourri etc. De mon expérience, c'est souvent douloureux pour toutes les parties. Ça marche vachement moins bien que l'autre sens.
Bref impliquer toutes les parties concernés par le produit pour construire l'histoire au mieux avec eux pour un coût donné me semble souvent une meilleure idée que de jouer à perpétuellement gratter du temps et donc utiliser le coût comme variable d'ajustement. Ceux qui payent ont une raison de le faire et ne sont généralement pas stupides. Si ils sont content de ce qui est livré, ils remettront du pognon pour ce qui est à rajouter. Il vaut souvent mieux livrer une ou deux fonctionnalité tout les mois, que toutes dans 2 ans (ou 4, ou 6 mois, ou 3 mois mais ca marche pas...).
[^] # Re: Leurre, moi je dis "non !"
Posté par ckyl . En réponse au journal Le libre libère la créativité. Évalué à 7.
Pas totalement d'accord sur l'approche de gratter du temps. Pour un projet il existe quatre variable d'ajustement: l'ensemble de fonctionnalités, la date de sortie, la vélocité, la qualité.
En général un produit est créé pour répondre à un besoin et il est totalement stupide d'utiliser la qualité comme variable d'ajustement. C'est assez facile à expliquer dans tout contexte qui n'est pas borné au court terme (coût du support, vélocité après quelque années, perte de clients, évolutions). Bref si on arrive pas à faire immédiatement oublier cette variable, il faut soit se remettre en question, soit partir direct. Attention on ne parle pas de faire quelque chose de parfait, mais quelque chose de viable dans le temps. Sortir un produit qui marche et qu'on pourra maintenir.
La vélocité étant assez difficile à maîtriser et à faire évoluer. C'est un objectif à long terme mais certainement pas une variable pour un produit. On cherche à la maximiser, et on l'ajuste pour la vision à long terme mais on ne s'en sert pas pour du court terme.
Il reste donc deux variables possibles et cohérentes: la date mais surtout les fonctionnalités.
Bien souvent il est plus facile et raisonnable de négocier les fonctionnalités qu'une date. On peut facilement expliquer ce qui coûte, pourquoi, comment on pourrait faire moins cher et laisser les gens choisir. On maintient la qualité constante, et on fait au mieux pour une date fixe. On pourra toujours compléter en gardant la même vitesse. Réussir à calculer une date pour une large ensemble de fonctionnalités contractuelle est beaucoup beaucoup plus difficile et plus mauvais pour le produit: obligé d'utiliser la qualité comme variable, ou prévoir des marges énormes. Mais dans ce cas, ça coûte très cher pour rien...
Il existe des cas ou ce n'est pas possible et où on va devoir fixer les fonctionnalités: Première livraison du sous ensemble de fonctionnalité minimum par exemple, contrat pourri etc. De mon expérience, c'est souvent douloureux pour toutes les parties. Ça marche vachement moins bien que l'autre sens.
Bref impliquer toutes les parties concernés par le produit pour construire l'histoire au mieux avec eux pour un coût donné me semble souvent une meilleure idée que de jouer à perpétuellement gratter du temps et donc utiliser le coût comme variable d'ajustement. Ceux qui payent ont une raison de le faire et ne sont généralement pas stupides. Si ils sont content de ce qui est livré, ils remettront du pognon pour ce qui est à rajouter. Il vaut souvent mieux livrer une ou deux fonctionnalité tout les mois, que toutes dans 2 ans (ou 4, ou 6 mois, ou 3 mois mais ca marche pas...).