Devriez-vous promettre de fournir une fonctionnalité dont vous n'êtes pas sûr qu'elle soit implémentable?

Dans un article de HN , je suis tombé sur les conseils suivants:

Dites toujours "oui" à votre client / utilisateur, même si vous n'êtes pas sûr. 90% du temps, vous trouverez un moyen de le faire. 10% du temps, vous reviendrez et vous vous excuserez. Petit prix à payer pour une croissance personnelle majeure

Mais j'ai toujours pensé qu'il fallait faire une analyse de faisabilité avant de faire toute sorte de promesses à un client / utilisateur, afin qu'il ne soit induit en erreur à aucun moment. Dans quelles circonstances, alors, les conseils ci-dessus devraient-ils s'appliquer?

Il s'agit de la deuxième question consécutive déclenchée par cet article.

• Bon programmeur: j'optimise le code. Meilleur programmeur: je structure les données. Meilleur programmeur: quelle est la différence?
  Il y a un autre nom pour cela: optimisation prématurée.

• N'utilisez jamais de sorties anticipées.
  C'est la règle "point d'entrée unique / point de sortie unique". C'est un patch sur le vrai problème, c'est que sortir tôt pourrait laisser un gâchis. La bonne règle est "nettoyer votre gâchis". Une règle encore meilleure consiste à utiliser des constructions de données qui se nettoient après elles-mêmes afin que le programmeur n'ait pas à se soucier de nettoyer son gâchis.

• Et maintenant, dites toujours «oui» à votre client / utilisateur, même si vous n'êtes pas sûr. 90% du temps, vous trouverez un moyen de le faire.
  C'est aussi un conseil incroyablement mauvais.

Parfois, il faut dire non à votre client ou "dans quel millénaire le voulez-vous?" Ne promettez pas quelque chose qui détruira votre architecture, qui coûtera bien plus que ce que le client est prêt à dépenser, ou que vous ne savez pas comment y parvenir. Vous connaissez la technologie, pas le client. Si vous ne savez pas comment le faire, ne dites pas que vous pouvez le faire. Si vous n'êtes pas sûr, dites que vous avez besoin de temps pour rechercher si c'est possible. Il vaut mieux être honnête, et cela vous évitera des ennuis.

Les clients deviennent rapidement d'anciens clients si vous ne pouvez pas tenir vos promesses. Un taux d'échec de 10% peut sembler faible, mais c'est sur 10% que vos clients se concentreront. Parfois, ils poursuivent lorsque vous ne respectez pas ce que vous avez promis. Tu ne veux vraiment pas ça. D'autres fois, vous assurer de tenir une promesse peut vous mettre en faillite, devenir fou ou perdre votre conjoint parce que vous travaillez 18 heures par jour. Vous ne le voulez pas non plus.

Pensez-y de cette façon: que pensez-vous qu'il arriverait à l'industrie du transport aérien si 90% de tous les atterrissages d'avion étaient réussis? Pensez-vous que revenir en arrière et s'excuser pour les 10% qui se sont écrasés résoudrait quoi que ce soit?

Il serait préférable de dire "je pense que cela peut être fait". ou "Je vais vérifier et vous contacter". J'ai eu des moments où j'ai dit non ou contre proposé quelque chose. Si le client veut "une application basée sur un navigateur qui fonctionne sans jamais être connectée à Internet et utilise des commentaires tactiles", c'est probablement possible. Mais cela coûte cher et il serait plus utile de discuter des besoins réels.

Le client vous respectera si vous êtes honnête. Dans le conseil de la question, la personne se trompe 10% du temps. Si je travaille avec quelqu'un qui se trompe régulièrement une fois sur dix, je ne vais pas du tout lui faire confiance. C'est un bilan horrible.

Promettre la lune et livrer un rocher est une sorte d'approche commerciale qui ne doit pas être tolérée. Si vous ne savez pas si c'est possible, recherchez-le. Ou, donnez-leur un devis sur le temps que vous devrez prendre pour l'examiner. De cette façon, vous ne promettez rien que vous ne puissiez pas livrer, mais vous êtes payé pour le temps qu'il vous faut pour l'examiner.

Cette question a été étudiée de manière formelle et est traitée par le code de déontologie IEEE Computer Society / ACM .

2.01. Fournir des services dans leurs domaines de compétence, en étant honnête et franc sur les limites de leur expérience et de leur éducation.

3.04. Assurez-vous qu'ils sont qualifiés pour tout projet sur lequel ils travaillent ou proposent de travailler par une combinaison appropriée d'éducation et de formation et d'expérience.

3.09. Assurer des estimations quantitatives réalistes des coûts, du calendrier, du personnel, de la qualité et des résultats de tout projet sur lequel ils travaillent ou se proposent de travailler et fournir une évaluation de l'incertitude de ces estimations.

5.05. Assurer des estimations quantitatives réalistes des coûts, du calendrier, du personnel, de la qualité et des résultats de tout projet sur lequel ils travaillent ou se proposent de travailler, et fournir une évaluation de l'incertitude de ces estimations.

Il y a certainement des implications commerciales et juridiques à promettre quelque chose que vous ne pouvez pas livrer. Habituellement, cela vient du client qui va ailleurs, refuse de payer ou poursuit votre entreprise. Si vous êtes en partenariat avec d'autres, ils peuvent intenter une action en dommages et intérêts si votre pièce n'est pas livrée. Les poursuites peuvent même provenir de concurrents.

Il y a une histoire des premiers jours des supercalculateurs où Seymour Cray et une équipe de Control Data Corporation étaient sur le point de lancer un produit, et une autre très grande entreprise informatique a déclaré à ses clients qu'elle était également proche du lancement. Le mensonge a coûté beaucoup de travail à CDC et s'est transformé en un procès où la grande entreprise n'a pu montrer aucune preuve crédible de ses allégations. Le résultat fut ce qui était à l'époque un gros règlement d'une valeur de 80 millions de dollars 1970 (environ 223 millions de dollars en 2012, corrigé de l'inflation). Vous pouvez lire à ce sujet ici:

http://en.wikipedia.org/wiki/Control_Data_Corporation#CDC_6600:_defining_supercomputing

Avec suffisamment de temps, de ressources et de flexibilité pour définir le succès, tout est possible. L'exemple de la masse x blanche est facile si vous ne voulez qu'une précision supérieure à 50% et que vous avez la position géographique de l'utilisateur et un peu de données statistiques.

La vraie première question dans la plupart des projets n'est pas de savoir si quelque chose est possible, mais si c'est raisonnable compte tenu d'un certain ensemble de circonstances.

La fonctionnalité ajoute-t-elle suffisamment de valeur pour justifier les frais de la tentative?

Même si l'idée serait assez géniale, si elle nécessite une longue période de développement ou l'acquisition de matériel plus exotique, il serait préférable que le client le sache à l'avance et ramène la conversation à des objectifs plus raisonnables dans la plupart des cas.

Si quelqu'un est assez fou pour vous donner un chèque en blanc et sans délai, dites-lui que tout est possible, faites-le-lui savoir que vous devez inventer et distribuer plusieurs des technologies impliquées pour atteindre l'objectif en cours de route.

D'un autre côté, lorsque vous traitez avec des clients raisonnables avec des ressources raisonnables, il n'y a parfois rien de pire que de dire au client qu'une fonctionnalité doit être supprimée après que vous l'ayez acceptée, car ils peuvent déjà être partis et avoir passé du temps / de l'argent / des ressources à promouvoir ou documenter et que 10% auraient pu être la chose qui a donné le feu vert au projet en premier lieu. Tombez dans l'une de ces situations et vous venez de perdre un client, et plus que probablement gagné une mauvaise référence très verbale dans un marché entier.

Jouer l'avocat du diable

Étant d'un état d'esprit analytique, les techniciens peuvent avoir tendance à supposer que leur performance sera principalement jugée sur la base d'un tableau de bord des demandes achevées par rapport aux demandes engagées, mais en pratique, ce n'est pas aussi simple que ça.

Avant même que le développement ne commence, les clients commencent à se forger une opinion sur les performances d'une équipe en fonction de leur niveau de confiance et de leur volonté de s'engager.

Cela s'explique en partie par le fait que les clients peuvent avoir du mal à évaluer si l'hésitation d'un entrepreneur à s'engager est due à la difficulté de la demande ou au manque de capacité de l'entrepreneur.

Comme il n'y a pas de critère absolu pour mesurer la difficulté d'une demande, ce qui est souvent plus important pour le client, c'est la confiance que l'entrepreneur donne 100% d'efforts, plutôt que de savoir si 90% ou 100% des demandes sont satisfaites.

Supposons que le client doive choisir entre deux scénarios:

Entrepreneur A :

• Confiants qu'ils peuvent répondre à toutes les demandes
• Résultat: 90% des demandes livrées
• Le client est heureux que l'entrepreneur ait fourni 100% d'efforts
• Le client perçoit que les demandes inachevées sont dues à des problèmes imprévus, qui échappent probablement au contrôle des entrepreneurs

Entrepreneur B :

• S'engage à répondre à 90% des demandes. Pas confiants de pouvoir respecter les 10% restants
• Résultat: 90% des demandes livrées
• Le client est déçu que le contractant n'ait pas essayé de répondre aux 10% restants de ses demandes
• Le client suppose que les 10% de demandes incomplètes étaient dues soit au manque d'effort, soit à la capacité de l'entrepreneur

Dans les deux scénarios, le même nombre de demandes a été livré; cependant, le client estimait que l'entrepreneur «sur-engagé» donnait 100% d'efforts et a utilisé cela pour valider que les demandes restantes étaient vraiment difficiles, au crédit de l'entrepreneur A.

D'un autre côté, le client avait l'impression que l'entrepreneur B ne faisait pas d'efforts à 100% et son incapacité à répondre à toutes les demandes était due au manque d'efforts ou de capacité de l'entrepreneur B.

Avertissement: je ne préconise pas le surengagement en tant que stratégie; il s'agit simplement d'une observation d'une éventuelle situation dans le monde réel dans laquelle un engagement excessif pourrait avoir des résultats positifs.

Vous devez leur dire de vous donner le temps de créer une «solution de pointe» .

Une solution de pointe est un petit programme qui, en le codant, vous permet de comprendre comment faire, ou même s'il est possible du tout, quelque chose qui crée de l'incertitude dans un projet.

Par exemple, supposons que vous n'ayez jamais envoyé de SMS par programme, mais vous savez que c'est possible. Une solution de pointe serait de créer un petit programme qui envoie un SMS. De cette façon, ce n'est plus une incertitude et vous pouvez faire de nouvelles estimations sur la faisabilité.

Voici ce que la documentation de programmation eXtreme dit à ce sujet:

Créez des solutions de pointe pour trouver des réponses aux problèmes techniques ou de conception difficiles. Une solution de pointe est un programme très simple pour explorer des solutions potentielles. Construisez le pic pour résoudre uniquement le problème à l'examen et ignorer toutes les autres préoccupations. La plupart des pointes ne sont pas assez bonnes pour être conservées, alors attendez-vous à les jeter. L'objectif est de réduire le risque d'un problème technique ou d'augmenter la fiabilité de l'estimation d'une user story. Lorsqu'une difficulté technique menace de bloquer le développement du système, mettez une paire de développeurs sur le problème pendant une semaine ou deux et réduisez le risque potentiel.

D'après mon expérience, lorsqu'un utilisateur demande quelque chose, vous devez lui demander une spécification détaillée de ce que l'utilisateur veut ou a vraiment besoin. Plus souvent qu'autrement, vous n'entendrez plus jamais parler de la demande.