Comment expliquer à une personne non technique pourquoi la tâche prendra beaucoup plus de temps que prévu? [fermé]

Presque tous les développeurs doivent répondre à des questions d’ordre commercial, telles que:
Pourquoi va-t-il falloir 2 jours pour ajouter ce simple formulaire de contact?

Lorsqu'un développeur estime cette tâche, il peut la diviser en plusieurs étapes:

• apporter des modifications à la base de données
• optimiser les changements de base de données pour la vitesse
• ajouter du HTML frontal
• écrire le code côté serveur
• ajouter une validation
• ajouter du javascript côté client
• utiliser des tests unitaires
• assurez-vous que la configuration du référencement fonctionne
• implémenter un email de confirmation
• refactoriser et optimiser le code pour la vitesse
• ...

Celles-ci sont peut-être difficiles à expliquer à une personne non technique, qui considère en gros que toute la tâche consiste simplement à assembler du code HTML et à créer un tableau pour stocker les données. Pour eux, cela pourrait être 2 heures MAX.

Alors, y a-t-il une meilleure façon d'expliquer pourquoi l'estimation est élevée pour un non-développeur?

Vous venez de le faire dans votre question.

Divisez la tâche en étapes individuelles et donnez des estimations pour chacune d’elles. Cela montrera que vous avez envisagé toutes les options et (espérons-le) couvert toutes les éventualités.

Si les délais sont trop longs, vous pouvez alors discuter des éléments (par exemple, la confirmation par courrier électronique) qui ne sont pas nécessaires dans ce cas avec des données concrètes plutôt que d'essayer simplement de mettre une pinte dans un pot.

Faites-le assez souvent et vous leur apprendrez, espérons-le, que le développement ne se limite généralement pas au regard.

La liste des tâches est presque parfaite, mais gardez à l'esprit que les tâches qui ont un sens parfait pour un ingénieur ont très peu de sens pour une personne non technique. Par exemple, dans la liste ci-dessus, je sais que "optimiser les modifications de la base de données pour une utilisation plus rapide" peut être une ou plusieurs tâches fastidieuses, telles que profiler le code, l'exécuter, rechercher des points lents, l'examiner avec des experts ou l'exécuter avec ensemble de tests prédéfinis spécifiques au produit. Et puis vous avez probablement plusieurs heures, voire plusieurs jours, de coups de tête sur votre bureau pendant que vous essayez de trouver un moyen de réparer les zones qui sont trop lentes.

Mais vous avez peut-être perdu la gestion de votre projet avec le mot "DB" sinon le mot "optimiser".

J'exprime généralement ce genre de choses à la gestion de projet sous forme de grandes étapes avec des mots décrivant le risque en termes d'activité. En prenant votre liste, je résumerais ainsi si je parlais à ma gestion de projet:

1. Tout d’abord, il s’agit de deux choses: la page Web que l’utilisateur voit et le serveur qui fait le gros du travail. Les deux parties doivent être présentes pour que cette fonctionnalité fonctionne.
2. La première partie consistera à créer une page Web qui ait du sens pour l’utilisateur (ajout de HTML frontal, ajout de javascript côté client). La clé ici est que la page Web doit ressembler à ce produit, qu'elle doit fonctionner dans tous les navigateurs que nous prenons en charge et qu'elle doit être lisse. C’est ce que l’utilisateur voit. Par conséquent, s’il semble mauvais, il pensera que notre produit est mauvais. Développer ceci et ensuite le tester prendra X jours.
3. Ensuite, il doit y avoir des éléments sous la page Web effectuant le travail. Dans ce cas, cela signifie d' insérer la description de la fonctionnalité ici (mappe pour - apporter des modifications à la base de données, écrire le code côté serveur, implémenter la confirmation par e-mail, ajouter une validation, utiliser des tests unitaires). Je ne peux pas simplement jeter cela ensemble. Si le code est développé et ensuite testé, nous risquons d'endommager les données de TOUS les utilisateurs. Cela signifie qu'une simple nouveauté pourrait nuire à la réputation du produit, même pour les utilisateurs qui n'utilisent pas cette fonctionnalité. Nos pratiques de développement couvrent ce sujet - nous effectuons de nombreux tests pour nous assurer que cela ne se produira pas - mais cela signifie que je dois planifier à temps pour le tester correctement. Cela me prendra Y jours.
4. La vitesse est un gros problème dans notre produit. Si tout ne se passe pas vite, les utilisateurs penseront que le produit n’est pas bon. Donc, après avoir écrit tout ça, je dois passer au travers du travail et m'assurer qu'il est à la hauteur en termes de performance. Il s’agit là d’une grosse affaire pour le Web: si les gens voient un site devenir lent, ils se tourneront rapidement vers un produit différent pour répondre au même besoin, car il est très difficile de voir la différence entre lent et cassé. Ce type de travail prend généralement Z jours (optimiser les modifications de la base de données pour accélérer, refactoriser et optimiser le code pour accélérer)

J'éviterais toute estimation inférieure à une demi-journée. Ils vont devoir faire confiance, à un certain niveau, que vous savez de quoi vous parlez. Et s’ils pensent vraiment que cela ne prendra que 2 heures, invitez-les à s’asseoir avec vous pendant 2 heures pendant que vous leur expliquez exactement à quoi ressemble 2 heures dans la vie d’un développeur SW - puis suivez un cours de codage 101 pour environ 2 heures, pour montrer exactement ce que tout doit être considéré pour commencer même à résoudre le problème.

Le plus important est les choses suivantes:

• Si vous parlez surtout de la perception des clients et de l’utilisation des produits, vous commencez à parler leur langage - le langage de $$ -, le fait est que si le code est piraté ensemble, vous finirez par perdre des affaires - sinon sur cette fonctionnalité, puis sur une fonctionnalité ultérieure lorsque de mauvaises pratiques de développement ont rendu impossible l'extension du code.
• Établissez une séquence d'événements. La prochaine question non technique sera "Si nous avons plus de développeurs que vous, cela se produira-t-il plus rapidement? Si oui, si cela prendra 40 heures pour réaliser cela, est-ce que 40 personnes pourront le faire cet après-midi?" La réponse, bien sûr, est "NON! TU ES TON ESPRIT ??". Mais ce n'est pas le meilleur. Le meilleur est qu'il y a une séquence logique d'étapes ici. La chose B ne peut pas être faite tant que la chose A n'est pas en place (si vous n'avez écrit aucun code, vous ne pouvez pas vraiment l'optimiser ou le tester ...). Les choses A et A 'pourraient être faites ensemble, alors si elles pouvaient épargner ce type malin, vous pourriez gagner du temps, de une semaine à quatre jours, et s’ils peuvent garantir l’impressionnant support de test, vous pourrez probablement 3 jours. Là'
• Concentrez-vous sur les risques et soyez prêt à vous faire comprendre que certains risques en valent la peine pour le moment. C’est la raison pour laquelle les hommes d’affaires sont payés très cher: déterminer quels risques valent la peine d’être pris. Par exemple, si la rapidité de mise sur le marché pèse sur les performances médiocres, car votre société dispose de suffisamment de liquidités pour organiser un nombre ridicule de serveurs à court terme, vous pouvez être invité à ignorer tous ces éléments à l'étape 4 (optimisation du code / de la base de données). ). C’est leur droit - c’est à vous d’expliquer les risques inhérents à cette décision.
• Cependant, si vous ne faites pas confiance à ces gens, obtenez une confirmation écrite - cela ne doit pas forcément être conflictuel, juste un petit courriel disant "voici ce que je pense que nous avons discuté, voici ce que je ne fais pas, voici le Je vais le faire maintenant, alors laissez-moi savoir si vous êtes en désaccord ... si je ne reçois pas d’avis, vous assumerez que c’est la bonne façon de procéder ". Étant donné que la gestion des produits peut être le centre des pertes de mémoire à court terme, cela est très utile pour tout le monde.

Il y a un dicton qui dit: "On ne peut pas contenir dix livres de (merde) dans un sac de cinq livres." Votre travail consiste à montrer que la tâche est de dix livres et ils demandent de le faire dans un délai de cinq livres.

La seule chose qui vous manque, c'est l'estimation de temps. Fixez une estimation de temps pour chaque tâche et montrez comment toutes ces choses s'additionnent pour l'estimation que vous fournissez. Ne laissez aucune estimation dépasser 4 heures. Si vous avez une tâche pour laquelle vous dites "un jour" ou "10 heures", décomposez-la en tâches plus petites.

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

Vous avez maintenant une facture détaillée des coûts. En tout, cela représente 27 heures de travail.

Vous pouvez maintenant montrer ceci à votre client et lui dire "Ce sont les choses à faire, avec le coût de chacune". Utilisez le mot "coût", car le temps est un coût et la direction comprend les coûts. Expliquez que vous pouvez éventuellement supprimer les deux tâches d’optimisation à la fin, mais que cela aura un effet négatif à terme, elles ne représentent que 15% de l’estimation totale.

Assurez-vous également que vous expliquez votre heure / jour de façon réaliste. Par exemple, si vous êtes invité à faire de l’assistance technique, à maintenir des bases de données, peu importe, figurez-le dans votre estimation. Ne dites pas "Eh bien, je peux faire 7,5 heures par jour de codage de qualité", car vous ne pouvez probablement pas. C'est probablement plus comme 5 ou 6.

Ensuite, surtout, suivez vos progrès. Dites que vous pouvez faire 5 heures par jour de codage. Ensuite, vous devriez être en mesure de supprimer les deux premières tâches (dans mon exemple) lundi, de terminer la troisième et de commencer la quatrième mardi, et ainsi de suite. Faites une liste de contrôle qui montre cela, de sorte que vous puissiez leur montrer le mercredi quand ils viendront et dire: "Comment ça va, allez-vous encore avoir terminé vendredi?"

Voir mes diapositives pour mon exposé Prévenir les crises: estimation et suivi de projet qui fonctionne que j'ai donné à OSCON il y a quelques années. Regardez la diapositive 21, "Planifier la semaine". Il existe également un exemple de graphique de vélocité .

Leur demander:

Comment le ferais-tu? Quels modules changeriez-vous? Combien de lignes de code? Quelles sont les implications pour la sécurité? Avez-vous modifié le schéma de la base de données? Si vous apportez des modifications à la base de données, combien de fichiers sont affectés? Combien de temps a-t-il fallu pour ajouter le dernier formulaire? Quelle est la moyenne (moyenne arithmétique) pour l'ajout d'un formulaire? Quel était le plus long? Je pense que cela prendra une minute de moins que la plus longue. Si vous ne savez pas combien de temps il a fallu ajouter les N derniers formulaires, il est alors garanti que cette estimation n’est précise qu’à un ordre de grandeur.

Je pourrais vous dire de leur expliquer que leur logiciel est comme une machine de 100 tonnes avec 10 000 pièces différentes, dont la plupart sont connectées de manière compliquée. Le montage d'un morceau de pouce dans cette machine demande un peu d'ingénierie, pour ne pas la casser, MAIS la meilleure réponse est:

Si vous aviez une meilleure architecture de code, cela faciliterait-il des tâches comme celle-ci? Et la réponse est que la plupart des équipes logicielles ne sont pas de bons architectes (parce qu’elles n’ont tout simplement pas amassé des modèles génériques d’architecture ou ne maîtrisent pas suffisamment le domaine des problèmes pour anticiper tous les problèmes) et qu’ils ne sont pas toujours de bons ingénieurs. , de sorte qu'ils ne se sentent pas en confiance pour faire des estimations ou faire des promesses.

Tout comme il a fallu le 20ème siècle pour réunir une bonne architecture et l'ingénierie nécessaire à la construction de grands bâtiments, les outils de génie logiciel ne sont tout simplement pas encore connus. Ils sont en cours de développement: il faut un nouvel état d'esprit. Voir Code Zen sur wiki.hackerspaces.org/Hacking_with_the_Tao.