La parabole de l’homme affamé |

Je parle avec de nombreux cadres du côté de la commercialisation de la maison qui pensent que la construction de logiciels sérieux est aussi facile – et facilement estimable – que la construction d’une clôture. Est-ce qu’il en était ainsi.

Un effet secondaire destructeur de ce malentendu peut être de changer à plusieurs reprises la priorité numéro 1 en cours de développement, avant il y a beaucoup à montrer au monde mais après consacrer beaucoup de temps à la découverte / conception / architecture / développement sur la priorité n ° 1 précédente. Alors que l’équipe de direction se lasse des rapports d’étape intermédiaires et des délais de livraison plus longs que prévu, elle perd courage et perd confiance dans le côté «créateur» de l’entreprise. Donc, quelque chose de nouveau devient la priorité numéro 1. Dispersés dans l’atelier de développement, il y a des piles de projets partiellement achevés qui ne sont pas réalisés – vieillissant par négligence. Et des millions de dollars sont gaspillés alors que nous dépensons à plusieurs reprises des talents rares pour finir à moitié.

Il s’agit d’un problème de cadrage difficile, qui peut renforcer la conviction profonde que les organisations d’ingénierie ne travaillent pas dur, sont manifestement inefficaces ou ont besoin de plus de surveillance. (Ce qui aggrave généralement les choses.) C’est une souche particulièrement mauvaise Dunning Kruger là où les ingénieurs pensent que vendre est facile, les vendeurs pensent que les logiciels d’entreprise ne sont qu’un SMOP (petite question de programmation), et les cadres non technologiques s’attendent à ce que créer un logiciel, c’est comme faire des sandwichs.

Comment communiquer cela? Dans le bon cadre avec le bon public, je raconte cette histoire fictive…

La parabole de l’homme affamé
Un homme affamé est dans une rue pleine de restaurants. En entrant dans le premier restaurant, on lui annonce une attente de 20 à 25 minutes pour une table. Au bout de 10 minutes, il a encore plus faim et perd patience… en sortant et en allant au restaurant voisin. Ils ont également une attente de 20 à 30 minutes pour une table. Au bout de 10 minutes, il perd à nouveau patience et part … Finalement, l’homme meurt de faim.

La compilation de la liste des initiatives à moitié abandonnées d’une entreprise peut mettre en évidence le fait que nous cuisinons activement même si rien de nutritif n’est servi à nos clients. (“Vous vous souvenez de A et B et C et D que nous avons laissé tomber à mi-chemin?”) Nos bacs à compost numériques sont remplis de logiciels de décomposition.

Variation en fonction des coûts

Le coût pour notre entreprise est plus que de ne pas fournir certaines fonctionnalités promises. Nous dépensons systématiquement la ressource la plus rare de la planète – l’objectif de notre organisation d’ingénierie surdouée mais surdouée – à des travaux que nous pourrions abandonner à mi-chemin. Si une équipe de développement coûte 1 M $ / an, alors nous gaspillons des incréments de 100 000 $. Et en ignorant le coût d’opportunité de ne pas terminer un autre travail critique.

L’HOMME AFFAMÉ PAYE À L’AVANCE
Notre homme affamé entre dans un restaurant, commande un repas à emporter. Et le paie d’avance. Le repas devrait être prêt à emporter dans 15 à 18 minutes. Il pense cependant que les commandes à emporter ne devraient prendre que 6 minutes. Au bout de 10 minutes, il sort avec frustration: argent dépensé, temps perdu et toujours affamé. Passage au restaurant suivant, commande à emporter et prochaine dépense radiée.

J’ai trouvé ce récit utile avec les directeurs financiers et d’autres personnes qui s’inquiètent autant du coût de développement que de la valeur des produits livrés. Nous pouvons passer de «pourquoi la R&D est-elle si chère» à «comment réduire notre gaspillage décisionnel?»

Variation construction-achat

J’ai vu des dizaines d’entreprises refuser d’octroyer des licences SaaS standard pour des capacités génériques non stratégiques en faveur de projets de bricolage mal conçus. Plutôt que de concentrer leurs équipes de développement (toujours trop petites) sur quelques facteurs de différenciation stratégiques forts, ils diluent leurs efforts en créant des versions internes de produits commerciaux robustes.

Les enfants construisent leurs propres réacteurs nucléaires!

La startup biosciences qui assemble une passerelle SMS… le conseil en formation écrivant son propre système de gestion de contenu… la société ERP se convainc que Jira / Asana / Pivotal Tracker / VersionOne / Monday / Aha! / Wrike / productboard / Kanbanize / etc ne le font pas répondent parfaitement à leurs besoins, mais dont les développeurs mettent au point un système de billetterie simple non pris en charge pendant le week-end.

Souvent, cela est motivé par une demande de fonctionnalité aberrante qui est minime par rapport à la création d’un produit commercial à partir de zéro. (“Aucun des principaux fournisseurs de messagerie hébergée ne nous donne le pouvoir délégué de définir une politique régionale autour de l’authentification à quatre facteurs. Nous ne pouvons donc pas utiliser Gmail, Office365 ou ProtonMail. Je parie qu’il n’est pas difficile de créer la nôtre.”) Mais ils oublient que faire correspondre ces produits commerciaux fonctionnalité par fonctionnalité prendra des années, nécessitera une équipe dédiée pour toujours et ignore les économies d’échelle: Twilio a des milliers de personnes intelligentes fournissant une infrastructure de communication complexe que vous pouvez utiliser pour moins de 1 ¢ par SMS.

Nous pourrions adopter une approche narrative légère pour faire passer ce point:

EXIGER UN INGRÉDIENT SPÉCIAL
Notre homme affamé entre dans un restaurant de hamburgers chic et décontracté qui propose 60 variantes de bœuf, poulet, tofu, dinde, sans gluten et des hamburgers impossibles. Mais il a entendu dire que la viande d’émeu est plus saine et plus savoureuse. La négociation avec le serveur échoue. (“Hé, je paierai 600 $ pour un hamburger d’émeu. Il suffit d’envoyer un membre du personnel de cuisine en Tasmanie et d’en ramener. J’attendrai.”) Frustré et toujours affamé, il décide d’investir dans sa propre chaîne de restaurants proposant des burgers d’émeu. Puisqu’il est anesthésiste et non restaurateur, ce sera une véritable expérience d’apprentissage.

Connaissez votre public, cependant. Tout le monde n’aime pas les analogies ou les histoires de chiens hirsutes. D’autres peuvent rater l’intention, saisir la métaphore de la nourriture et vouloir que les développeurs aient des recettes exactes ou des listes d’ingrédients entièrement tarifées avant de commencer chaque nouveau projet. Après tout, créer un logiciel, c’est simplement aimer cuisiner le dîner – et mon enfant maîtrise le macaroni au fromage, il devrait donc être notre prochain architecte de microservices.

Octet sonore

Du côté du produit / développement, nous savons à quel point il est important de commencer moins de choses et de s’y tenir jusqu’à la fin. Les changements de priorité rapides sont coûteux et démoralisants. Mais ce n’est peut-être pas un concept natif pour certains du côté de la commercialisation. Recherchez diverses façons de formuler les problèmes de manière à ce que votre public les comprenne. (Et partagez un repas avec eux quand vous le pouvez.)