Comment communiquer une estimation Swag
Je soutiens un grand projet de logiciel d'entreprise qui reçoit fréquemment des demandes d'amélioration de notre client. Le client ne paiera les travaux à l'avance que dans des contrats à prix fixe. Nous fournissons d'abord une estimation Swag , puis nous fournissons une estimation détaillée après le feu vert du Swag. Les estimations détaillées prennent beaucoup de temps et nous ne sommes rémunérés que pour le temps d'estimation lorsqu'ils signent l'amélioration, de sorte que l'estimation Swag nous fournit un niveau de protection.
Nous communiquons notre estimation Swag comme petite, moyenne, grande ou très grande, et nous avons communiqué les plages associées à chacune de ces valeurs. Par exemple,
Small: < 5 days
Medium: 5 - 15 days
Large: 15 - 50 days
Very Large: > 50 days
Ayant mis cela en pratique pendant quelques années, j'ai quelques inquiétudes:
- Parfois, l'estimation de Swag devrait se situer à l'extrémité supérieure d'une fourchette. Cette forme d'estimation peut rendre difficile la gestion des attentes des clients, un effort de 15 jours est très différent d'un effort de 50 jours et le client peut donner le feu vert à un Swag dans l'hypothèse optimiste.
- Si le client approuve une estimation de Swag, nous pouvons nous sentir obligés de plafonner notre estimation détaillée à la gamme haute de Swag. Si nous montons dans une fourchette, il y a généralement des discussions de facturation supplémentaires qui sont douloureuses, lentes et manquent de garanties d'indemnisation.
Existe-t-il des pratiques standard ou des méthodes éprouvées de communication des SWAG qui peuvent nous aider à mieux gérer les attentes des clients?
Est-il préférable d'utiliser les plages d'utilisation au cas par cas, plutôt que les plages fixes que j'ai notées? Dois-je passer à un numéro unique au lieu d'une plage?
Il y a en fait une vieille approche qui traite ce genre de problème qui vient du PERT et CPM pratiques. Vous pourriez obtenir une résistance si vous mentionnez cela, car cela est associé à la cascade et au PMI. Mais cela n'a vraiment rien à voir avec la cascade et je n'ai pas vu beaucoup de preuves que les chefs de projet certifiés en savent quelque chose (bien que cela fasse partie de la certification).
Vous obtenez 2 ou 3 estimations pour chaque article. Vous donnez un scénario dans le meilleur des cas, c'est-à-dire dans la limite inférieure, c'est-à-dire que cela ne se fera pas plus rapidement. Ensuite, vous arrivez avec une estimation haut de gamme, c'est-à-dire que cela ne devrait jamais prendre longtemps. Facultativement, vous fournissez une estimation "meilleure estimation" qui se situe quelque part entre les deux. Cela aide à pondérer l'estimation vers le haut ou le bas, mais ce n'est pas strictement nécessaire. Vous effectuez cette opération pour chaque livrable de haut niveau . Une partie de ce que les gens se trompent sur cette approche est qu'ils essaient de le faire à un niveau extrêmement fin. Cela ne fonctionne pas/ne vaut pas la peine.
Ensuite, vous disposez et les dépendances et en utilisant un algorithme bien connu, vous pouvez arriver à une estimation globale avec un niveau de confiance pour l'ensemble du bundle. Il est bon de comprendre que plus vous estimez d'éléments de cette façon, plus l'estimation globale est fiable, car les choses ont tendance à se stabiliser.
Vous pouvez utiliser cette approche avec des tailles de t-shirt pour les livrables des composants. Si les plages sont assez fiables, alors ça devrait aller. Certaines personnes peuvent essayer de vous dire que cela est incompatible avec les méthodologies agiles mais ce n'est vraiment pas le cas. C'est simplement une façon de prendre un tas d'estimations et de le transformer en une estimation composite en utilisant des approches statistiques bien étudiées. De très bons praticiens agiles utilisent des méthodes statistiques. Cependant, ce n'est généralement pas quelque chose que la plupart de l'équipe voit, et une grande partie d'Agile est devenue simplement un processus culte.
On m'a demandé d'estimer les emplois de toutes les manières imaginables. J'ai vu des estimations mal tourner à bien des égards.
Je peux atteindre n'importe quel délai avec une portée de travail suffisamment floue.
Donc, en supposant une portée de travail avec des tests d'acceptation significatifs, je vous dirai le secret pour générer les seules estimations de temps significatives que j'ai jamais rencontrées.
Imaginez que le travail qu'on vous a demandé de faire soit plus difficile que prévu. Imaginez que cela ait déjà pris autant de temps que quiconque pensait que cela prendrait et que ce n'est toujours pas fait. Maintenant, combien de temps êtes-vous prêt à y perdre du temps avant d'en avoir marre et de vouloir essayer autre chose?
Ce processus génère les estimations de temps les plus réalistes que j'ai jamais vues. N'a rien à voir avec le problème mal défini, pas encore compris. Il s'agit de savoir à quel point nous sommes patients pour obtenir la solution de cette façon avant de vouloir déchirer tout le plan.
La seule façon de m'améliorer est de créer une solution prototype avant le début du travail, donc je sais déjà que cela fonctionnera. Certaines personnes effectuent des tâches de coupe-biscuits qui sont la même chose encore et encore. C'est à peu près la même chose que le prototypage. Ces types répondent mieux aux spécifications détaillées. Principalement parce que ces emplois consistent à ne pas oublier de faire quelque chose.
Pour Swag c'est vraiment ce que les gens ressentent. La réalité autour du problème. Pas le problème. Le travail se termine quand c'est fait ou que les gens en ont assez d'attendre et d'essayer autre chose. Nous estimons vraiment notre patience avec le problème.
En ce qui concerne la communication d'une estimation Swag, vous avez déjà pris soin de l'une des plus grandes sources de malentendus. En exprimant les durées de temps comme des travaux de petite, moyenne, grande et très grande, vous évitez de penser que vous avez dit que cela se ferait dans exactement 50 jours. Ces nombres sont toujours flous. Les clients ne devraient pas être amenés à penser qu'ils ne le sont pas.
Quelle que soit la façon dont vous le communiquez, écoutez votre client. Essayez d'avoir une idée de votre compréhension. Ce qui vous semble parfaitement évident pourrait vous surprendre complètement. Ce processus comporte suffisamment d'incertitude sans ajouter de surprises inutiles.
Parfois, l'estimation de Swag devrait se situer à l'extrémité supérieure d'une fourchette. Cette forme d'estimation peut rendre difficile la gestion des attentes des clients, un effort de 15 jours est très différent d'un effort de 50 jours et le client peut donner le feu vert à un Swag dans l'hypothèse optimiste.
C'est exactement pourquoi je lie explicitement une estimation Swag à ce que les gens pensent du travail. Si le client est manifestement mal à l'aise avec l'idée qu'une tâche pourrait être un effort de 50 jours, ne cédez pas à la tentation de la vendre en tant qu'effort de 15 jours sans clouer l'étendue du travail à quelque chose qui correspond bien dans un délai de 15 jours. effort. Ne laissez jamais ce que vous ressentez du temps se comprimer sans dire ce qui sera perdu en faisant cela.
Si le client approuve une estimation de Swag, nous pouvons nous sentir obligés de plafonner notre estimation détaillée à la gamme haute de Swag. Si nous montons dans une fourchette, il y a généralement des discussions de facturation supplémentaires qui sont douloureuses, lentes et manquent de garanties d'indemnisation.
Et bien tu es obligé. En fait, vous êtes obligé de ne pas attendre pour commencer les discussions supplémentaires sur la facturation. Si après le premier jour d'un travail de 15 jours, il devient clair que ce sera un travail de 40 jours, vous devez le signaler. Pas après 15 jours. Si le client dit non, la chose responsable à faire n'est pas de devenir fou en essayant de le faire en 15 jours. C'est de vouloir partir.
Personnellement, j'aime donner au client la meilleure compréhension possible des progrès. Lorsque je travaille avec un délai, je donne des mises à jour quotidiennes sur la probabilité que nous pensons que nous respecterons le délai. Lorsque je travaille une liste de contrôle sur le travail estimé, j'encourage planification basée sur des preuves . Autrement dit, utiliser vélocité pour évaluer dans quelle mesure nous correspondons à nos estimations et extrapoler notre date d'achèvement. Cela peut être recalculé après chaque étape. C'est bien de voir cela recalculé souvent.
Faire cela ne fait rien pour accélérer le travail, mais cela donne à ceux qui l'attendent le sentiment de comprendre ce qui se passe. La gestion de ces sentiments est en fait la chose la plus importante si vous voulez qu'ils continuent à vous donner du travail.
C'est un problème inhérent aux estimations de haut niveau. Vous êtes obligé de faire des hypothèses car vous n'avez pas fait d'analyse approfondie. Parfois, vous êtes puni pour ces hypothèses au fur et à mesure qu'elles s'avèrent incorrectes. Je recommanderais de créer des plages S, SM, M, MH, H comme <5, 5-10, 10-15, 15-20,> 20
Dans le cadre de la transmission de vos estimations de taille de TShirt, mettez en évidence toutes les hypothèses de haut niveau afin que le sponsor soit clair sur les implications. Pour ce que ça vaut!
Habituellement, lorsque je communique avec quelqu'un au sujet d'estimations, qu'il s'agisse de SWAG ou d'estimations d'analyse plus détaillées, je vais essayer d'exprimer et de souligner l'incertitude de l'estimation.
Par exemple, vous avez parlé de donner une plage sur le temps nécessaire à une fonctionnalité et je pense que c'est bien. Cela montre qu'il y a une gamme de temps que quelque chose pourrait prendre. Cependant, je ne suis pas sûr que je répondrais toujours avec ces petites, moyennes et grandes étiquettes avec les plages de temps attribuées. Il y a une grande différence entre un projet qui prendra 14 à 18 jours et un projet qui prendra 40 à 50 jours. Pourtant, ils seraient tous deux classés comme "grands". Je pense qu'une meilleure estimation serait de donner ces fourchettes. Si un client savait d'avance que vous pensiez qu'une tâche prendrait de 40 à 50 jours, il ne devrait jamais être si optimiste qu'il pense que cela se fera en 15 jours (et s'ils le font, eh bien, c'est à eux de décider pas ce qu'ils attendent).
J'ai également tendance à essayer de donner aux gens des estimations avec des mesures de confiance. Cela signifie que je vais proposer une plage de temps pour l'estimation et exprimer à quel point je suis confiant que nous pourrions atteindre cette estimation en pourcentage, généralement pour différentes parties de la plage. Par exemple, disons qu'un client vient me voir avec une nouvelle fonctionnalité qu'il souhaite. Et nous dirons qu'il s'agit d'une fonctionnalité sur un site Web qui impliquera un certain travail d'interface utilisateur et la création de nouveaux appels/points de terminaison de base de données et d'API. Je pourrais donc décomposer cela comme ceci:
Database work:
Create new sprocs for getting data - .5 days
Testing sprocs (correct returns, validating performance, etc) - .5 days + up to .5 days
API work:
Create new stubbed endpoint - .25 days
Create hook stubbed endpoint to DB and call sproc - .25 days
Test endpoint - .25 days + up to .5 days (for bug fixes)
UI work (we'll assume the front end is a mess and doing anything there is a nightmare of brittle, interdependent code):
Adding button to existing page for feature - .25 days
Making AJAX call to endpoint - 1 day
Fixing everything that has broken so far in the UI - .5 days + up to 1 day
Testing the UI / end to end tests - .25 days
Fixing more broken things the test uncovered - .5 days
Alors ajoutez tout cela et je reçois 4,25 jours + jusqu'à 2 jours supplémentaires. Ensuite, j'ajoute quelques suppositions en fonction de la variance que j'attends dans mes estimations (élevées ou basses) et je pourrais proposer une plage de 3 à 8 jours avec un délai prévu de 5 jours. Ensuite, je dirais à quelqu'un quelque chose comme ceci:
Estimate (days) Confidence
3 40%
5 80%
8 90%
Et cela pourrait être dit au client comme ceci:
Nous avons donc brièvement examiné la possibilité de créer la fonctionnalité X pour vous. Nous avons proposé une estimation de 3-8 jours pour le faire. Nous prévoyons que cela prendra probablement environ 5 jours. Cela signifie que nous sommes à environ 40% confiants que nous pourrions le faire en 3 jours, 80% confiants que nous pourrions le faire en 5 jours et 90% confiants que nous pourrons le faire en 8 jours. Ce n'est qu'une supposition préliminaire que nous avons faite sur la base de notre expérience avec leur système et des fonctionnalités similaires. Ceci est censé être une supposition seulement et ne doit pas être utilisé comme garantie que cette fonctionnalité sera effectuée dans un laps de temps spécifique.
Je me rends compte que certains de ces mots sont un peu maladroits, mais je crois avoir fait valoir ce point ici. Ce point étant que si vous pouvez communiquer à quel point vous êtes certain ou incertain de quelque chose, cela permet aux gens de faire de meilleurs choix sur ce que vous leur dites. Et être explicite sur votre incertitude empêche les autres de faire des hypothèses à ce sujet.
Comparez l'exemple précédent à un comme celui-ci:
Nous avons fait une analyse sur la fonctionnalité Z. Il y a beaucoup d'inconnues ici et nous travaillerions dans une partie délicate du système qui a été connue pour causer des problèmes si nous ne sommes pas extrêmement prudents. Nous avons estimé que cela prendra entre 40 et 80 jours (30% de confiance pendant 40 jours, 50% de confiance pendant 70 jours et 55% de confiance pendant 80 jours). Nous pensons que cela pourrait même prendre jusqu'à 120 jours. Nous vous recommandons de faire des exigences plus approfondies et de planifier un peu plus si vous êtes toujours intéressé.
Cela pourrait suffire à un client pour dire "non, ça ne vaut pas le coup". Mais cela les prépare également à l'idée que ce n'est pas une solution miracle et que plus de travail est nécessaire pour obtenir une meilleure estimation.
Je recommanderais de lire Software Estimation: Demystifying the Black Art par Steve McConnell. Il y a quelques chapitres sur la façon de communiquer des estimations à différentes personnes en fonction de ce dont elles ont besoin et comment les faire comprendre ce que vous essayez de dire. (Je ne suis pas affilié à ce livre en aucune façon, je l'aime juste.)
Hy,
mon expérience est que de telles estimations de haut niveau vont très mal et que certaines limites doivent être établies.
- Définissez jusqu'à quand le client est-il disposé à dépenser de l'argent. Chaque client a un budget et en veut un maximum. Le problème commence quand il n'a aucune idée de ses besoins ou de ses souhaits irréalistes. Dans votre cas, cela ressemble à quelqu'un qui a essayé quelque chose d'étrange et maintenant il n'y a plus de confiance.
- Définissez les exigences strictes et les livraisons. Dans votre cas, tout doit être défini en dur, vous devez donc définir des jalons. Une certaine prudence est conseillée ici. Chaque demande de changement doit être négociée séparément, chaque jalon doit être renégocié et tout changement dans un jalon s'accompagne d'une prime.
- Une façon de résoudre le problème d'estimation du temps consiste à écrire dans l'estimation un facteur de certitude en pourcentage, ce facteur donnerait une valeur indiquant le succès certain dans le temps estimé. Surtout, cela effraie la gestion.
- Le problème suivant est l'allocation des ressources (développeurs, architectes, etc.) et l'ordre d'exécution des tâches. La plupart des problèmes surviennent lorsque le client identifie une fonctionnalité dont il a besoin demain. C'est pourquoi un calendrier signé avec des jalons est la clé. Cela vous évite bien des ennuis.
Si je trouve autre chose, je modifierai mon message.