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

13

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?

TCSGrad
la source
20
En programmation, tout est possible. N'oubliez pas que "Oui" n'est pas une réponse à "Combien de temps cela prendra-t-il?"
Steven Evers
9
@SnOrfus: Certains problèmes ne peuvent tout simplement pas être résolus. Si vous pensez le contraire, programmez une routine de prévisions météorologiques qui vous dira si nous aurons un Noël blanc.
Loren Pechtel
5
@Earlz: cela suppose que l'univers est déterministe, ce qui n'est pas nécessairement vrai.
whatsisname
4
Désolé, impossible. Le temps devient chaotique après sept à dix jours. Il y a un article très célèbre sur le sujet, «Prévisibilité: le battement des ailes d'un papillon au Brésil déclenche-t-il une tornade au Texas? par Edward Lorenz.
David Hammen
26
Si les programmeurs vont faire des promesses qu'ils ne peuvent pas tenir, que vont faire les commerciaux?
JeffO

Réponses:

20

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?

David Hammen
la source
2
+1 Je n'ai pas parcouru cette liste liée plus tôt, bon travail pour signaler qu'il y a là des conseils vraiment horribles. Le gars est peut-être un bon développeur, je n'en ai aucune idée, mais il est certain qu'il ne l'est pas, ce qui n'est généralement pas un bon signe.Ce conseil se lit comme s'il provenait d'un chiffon mensuel destiné aux gestionnaires.
Jimmy Hoffa
+1 - Je ne dis jamais "Non" aux clients (sauf si je ne veux pas les revoir) - C'est toujours dans la ligne de "Ça coûtera X dollars", "Votre pile technologique ne supporte pas ça" etc. "Non" clôt le problème mort. utilisez les réponses qui l'ouvrent pour une discussion plus approfondie. par exemple "... mais je pourrais vous donner 90% de ce que vous voulez pour 10% du coût" ou ".... Mais je pourrais l'implémenter de cette façon et vous donner une solution qui fonctionne de cette façon ...."
mattnz
1
@mattnz - Il est difficile de dire «non», mais parfois c'est nécessaire. "Pouvez-vous faire ce changement d'ici demain?" Et bien non. Mais je peux l'obtenir d'ici la fin de la semaine. "Pourriez-vous faire une analyse de Monte Carlo avec chacune de ces centaines de variables de contrôle variées au hasard par cycle?" C'est celle qui a suscité la réponse "dans quel millénaire voulez-vous le résultat". J'ai discuté de la malédiction de la dimensionnalité et suggéré de réduire cette liste à quelque chose de raisonnable. La façon dont vous dites non est importante, mais vous devez parfois dire non. Diplomatiquement, bien sûr.
David Hammen
Un taux d'échec de 10% serait une amélioration MASSIVE par rapport aux taux de réussite moyens actuels de la livraison de logiciels.
Graham
Concernant l'analogie avec l'atterrissage d'un avion - Les avions sont posés en toute sécurité tous les jours. Si je suis pilote et que je réponds "laissez-moi vous revenir là-dessus" à la question de savoir si je peux poser mon avion en toute sécurité, cela ne m'achètera pas de karma avec les passagers. Même si je sais qu'il y a une petite chance d'un accident à l'atterrissage, c'est un bon exemple où montrer la confiance dans mes capacités de pilote est plus important que de se concentrer sur la petite chance d'échec.
Cliff
24

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.

Jeanne Boyarsky
la source
17
Il est souvent préférable de s'assurer qu'un client vous indique le problème qu'il souhaite résoudre ... plutôt que de lui demander de parler de la solution qu'il souhaite . Obtenez le problème .. et dites-leur la solution.
Simon Whitehead
+1 et plus - deux très bons points que vous faites - Ne dites jamais «non» et ne perdez pas en crédibilité auprès de votre client.
mattnz
+1 "Le client vous respectera si vous êtes honnête". Cette déclaration est tellement vraie et vaut de l'or. Soyez honnête lorsque vous présentez des options au client. Dites-leur simplement que ce qu'ils demandent n'est pas un widget pré-construit que vous pouvez acheter et brancher. Faites-leur savoir qu'ils demandent une solution personnalisée et qu'un logiciel personnalisé coûte très cher. Cela provoque généralement une ou deux choses. 1.) Ils veulent une alternative rentable. 2.) Ils sont prêts à payer pour la solution personnalisée. Quoi qu'il en soit, c'est un gagnant / gagnant.
Michael Riley - AKA Gunny
6

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.

Joshua Burns
la source
6

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

DeveloperDon
la source
+1 pour référencer un code d'éthique pour répondre à une question sur l'éthique.
Jay Elston
5

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.

Facture
la source
4

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.

Falaise
la source
3

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.

Tulains Córdova
la source
1

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.

ronin
la source
1
c'est le meilleur moyen de ... rendre les utilisateurs mécontents. Plus souvent qu'autrement, cela entraînera une baisse des bénéfices
moucher
3
Honnêtement, pour certains développeurs internes, ce n'est pas une idée terrible. Le travail en interne n'est généralement pas facturé directement (l'informatique ne fait que partie du budget général) et vous pouvez être submergé de demandes de merde parce que les demandeurs ne perdent pas d'argent en vous envoyant du spam.
Graham