Le Mois-Homme Mythique Mythique

En tant que chef de produit dans une entreprise de technologie, je suis un puits sans fond de besoins. Mon travail en tant que Chief Product Officer chez Mailchimp consiste à mettre sur le marché le produit qui va gagner dans un espace très concurrentiel. Les aspirations de Mailchimp sont élevées, et pour les réaliser, nous devons livrer une quantité substantielle de produits sur le marché. Souvent, pour beaucoup dans l'entreprise, on a l'impression d'en faire trop. Nous sommes toujours au bord des roues qui se détachent.

Et quand vous en faites trop et que vous décidez d'en faire plus que cela, vous commencerez inévitablement à entendre parler de The Mythical Man-Month . C'est comme une de ces balles anti-stress où si vous pressez une extrémité, le Mythical Man-Month apparaît à l'autre extrémité.

Publié par Frederick Brooks en 1975 (vous vous souvenez de 1975, n'est-ce pas ? Quand le développement logiciel ressemblait à 100 % au développement logiciel en 2020 ?), ce livre est plutôt célèbre parmi les ingénieurs logiciels. Plus précisément, il y a un point dans tout le livre qui est célèbre (je ne suis pas convaincu que les gens lisent autre chose que ce point s'ils ont lu le livre):

"... ajouter plus d'hommes allonge, et non raccourcit, le calendrier."

Solution facile. Je me contenterai de recruter des femmes pour les projets à partir de maintenant (voir le retour du roi et le combat contre le roi sorcier d'Angmar).

Mais supposons que le point de Brooks soit valable quelle que soit l'identification sexuelle des ingénieurs en logiciel en question. Voici le point : le logiciel est difficile à construire avec beaucoup d'interdépendances complexes. Et tout le monde doit travailler ensemble pour y arriver.

Au fur et à mesure que j'ajoute des personnes à une équipe, elles doivent être intégrées et greffées dans le projet. Quelqu'un doit leur trouver le bon travail. L'équipe doit communiquer pour s'assurer que tout fonctionne ensemble, et chaque personne supplémentaire augmente géométriquement la complexité de la communication. Et à un moment donné, l'ajout de personnes devient un fardeau pour le projet - pas un avantage.

Voici le graphique du livre illustrant ce point:

C'est tout à fait juste. C'est pourquoi je l'entends autant au travail. Les contributeurs individuels épuisés et les dirigeants épuisés le jetteront - nous ne pouvons pas aller plus vite, nous ne pouvons pas faire plus, arrêtez l'embauche, lisez The Mythical Man-Month et désespérez ! La seule solution est apparemment d'arrêter de grandir et de tuer certains projets.

Quand, en tant que CPO, je dis : « nous allons faire ce truc ! la réponse est alors souvent "OK, alors qu'est-ce qu'on va tuer ?" Le Mythical Man-Month transforme le développement de produits en un jeu à somme nulle. Si nous voulons une chose, nous devons en arrêter une autre. Maintenant, c'est un vrai mythe, et j'appelle de la foutaise.

Et amené à sa conclusion pathologiquement mal interprétée (nous y arriverons), le livre dit apparemment que l'entreprise technologique la plus rapide est celle qui emploie quatre personnes – quatre hommes , apparemment. Rien de plus ne fait que ralentir le tout. Quelqu'un devrait envoyer des copies du livre à Amazon, Apple et Google, afin qu'ils puissent réparer leurs organisations manifestement gonflées.

Le seul problème avec cette approche est que dans un espace où la concurrence se développe, itère et s'exécute – ne faisant que freiner la croissance organisationnelle – l'édition et la concentration de la charge de travail peuvent être une recette pour l'extinction. Vous serez plus sain d'esprit et moins stressé, jusqu'à ce que vous perdiez votre emploi.

Et en tant que responsable de la gestion des produits de mon entreprise, je ne suis pas indifférent à ce besoin de ralentir et de se concentrer. Il faut impitoyablement prioriser ! Sans doute. Mais gérer un produit est un exercice contradictoire. Je dois donner la priorité à ce que j'ai tout en complotant simultanément pour en faire plus. Mais que faire face au Mythical Man-Month ?

Étonnamment, la réponse à cette question vient du même livre de Brooks. Voici un autre graphique dans le même chapitre :

Il y a une bataille dans la mise à l'échelle du développement de produits. Si le travail que vous essayez d'accomplir est purement partitionnable, alors allez-y et ajoutez des personnes ! Si votre travail est entièrement connecté, à un moment donné, ajouter des personnes est tout simplement faux.

Si quelqu'un dit que je dois absolument tuer un projet pour en démarrer un autre, ce n'est tout simplement pas le cas. Si les deux projets nécessitent très peu de communication et de coordination, alors nous pouvons nous étendre.

C'est pourquoi l'ajout de cœurs à un processeur peut augmenter la vitesse de votre ordinateur ou de votre téléphone jusqu'à un certain point, ce que les ingénieurs doivent tout savoir. Bien sûr, l'ajout de cœurs ne m'aidera pas à effectuer un calcul complexe à un seul thread. Mais cela peut m'aider à exécuter un tas de tâches indépendantes .

Le conflit pour un directeur de produit entre la mise à l'échelle et la hiérarchisation impitoyable peut alors être géré.

1. Vous hiérarchisez impitoyablement dans les endroits à thread unique (le backlog d'une équipe produit, disons).
2. Vous évoluez en ajoutant plus de cœurs pour gérer le travail indépendant.

Cependant, il est très rare que quelque chose soit totalement indépendant de tout le reste dans une entreprise. Au strict minimum, votre entreprise va centraliser les fonctions supports (informatique globale, juridique, RH, etc.) entraînant des goulots d'étranglement.

Tout tourne autour de la gestion des dépendances

Le travail d'un directeur de produit devient alors non seulement la création d'une stratégie, mais l'exécution d'une manière qui maximise la valeur pour le client et l'entreprise en garantissant le débit et en réduisant autant que possible le risque d'interdépendance. "Autant que possible" étant la clé ici. De cette façon, vous pouvez faire en sorte que l'entreprise ressemble autant à ce dernier graphique qu'au premier. L'interdépendance est une maladie incurable , mais ses symptômes peuvent être gérés avec de nombreux traitements.

Une solution consiste à assembler une direction stratégique pour l'entreprise qui minimise ou limite la dépendance grâce à un portefeuille d'initiatives soigneusement sélectionnées. Ce qui est drôle ici, c'est que beaucoup de gens repousseront cela. Disons que j'ai deux options, une où je peux exécuter des projets A, B et C qui ont très peu de coordination (disons qu'ils ont un impact sur différents produits), et une autre option avec des projets D1, D2 et D3 qui ont des tonnes d'interdépendances ( disons qu'ils impactent tous le même produit). Il arrive souvent que le Mois-Homme Mythique soit invoqué contre le premier plan plutôt que contre le second. Parce que sur le papier ça ressemble plus .

En effet, il est moins "concentré". Mais, c'est en fait moins difficile du point de vue de la dépendance et donc mieux avec du personnel supplémentaire.

Gardez à l'esprit que je ne dis pas de choisir un tas de travaux pour l'entreprise qui ne sont pas liés. Mailchimp ne construira pas de four à micro-ondes de si tôt. Tous les travaux doivent aller dans la même direction à long terme. Cette approche peut augmenter le risque lié à l'expérience client (dont nous parlerons plus tard) ainsi que la charge sur les fonctions globales telles que la recherche client. Gardez un œil sur cela.

Un autre traitement consiste à créer un processus de gestion des produits et des programmes qui facilite la coordination des dépendances et la communication si nécessaire sans surcharger les équipes de coordination si cela n'est pas nécessaire . Parfois, en essayant de gérer la coordination pour pouvoir faire plus, nous finissons par créer des processus si onéreux que nous finissons par en faire moins. C'est un équilibre entre faire trop peu de coordination qui empêche les pièces d'interagir et faire trop de coordination qui fait que les pièces ne sont jamais construites parce que nous sommes tous debout pour l'éternité.

L'affirmation dans le Mythical Man-Month est que lorsque vous ajoutez des personnes à un projet logiciel, la communication doit augmenter géométriquement. Par exemple, si vous avez 3 personnes sur le projet, c'est 3 lignes de communication. Mais si vous en avez 4, cela fait 6 lignes de communication. Une personne supplémentaire, dans ce cas, conduit à doubler la communication ! Amusant. (Il s'agit bien sûr d'une simplification excessive de la communication sur les projets de développement de logiciels.)

Différentes personnes ont des rôles différents et reçoivent donc différents niveaux d'autonomie. Peut-être que le chef de projet doit communiquer avec tous les membres de l'équipe. Mais un ingénieur travaillant sur l'API doit-il communiquer avec le responsable du marketing produit ? Ou le marketeur peut-il simplement passer par le chef de produit ? Un bon processus et une bonne cadence de réunion peuvent alors éliminer les communications et les réunions inutiles. Le fait est que la formule d'intercommunication de Brooks est une limite supérieure de la coordination , pas une condamnation à mort.

Enfin, utilisez des outils, des principes et des cadres combinés à un travail indépendant plutôt qu'à une collaboration réelle pour lutter contre les symptômes d'interdépendance. Par exemple, si je peux coordonner les indicateurs de performance clés de deux équipes (KPI, c'est-à-dire les mesures de succès) pour inciter le mouvement dans plus ou moins la même direction, alors leur travail indépendant est plus susceptible de se terminer "plus proche" que si leurs KPI encouragent le mouvement orthogonal. Cela ne garantira pas que les choses s'emboîtent parfaitement, seulement que le travail que je dois faire pour les faire s'emboîter à l'avenir est inférieur à ce qu'il pourrait être autrement. D'autres exemples peuvent inclure l'utilisation d'instructions "égales", de systèmes de conception et de tests automatisés.

Il y a donc un début. Mais les interdépendances prennent de nombreuses formes au-delà du code. Permettez-moi de donner un exemple de Mailchimp.

Risque lié à l'expérience client : le coût caché (mais acceptable ?) du travail de pare-feu

Étant donné que le client de Mailchimp est souvent un propriétaire de petite entreprise novice en marketing (et qu'il existe des millions de propriétaires de petites entreprises devenus spécialistes du marketing dans le monde), nous devons offrir une expérience transparente et immédiatement compréhensible de bout en bout . Nous n'avons pas le luxe d'assembler un monstre de nuages ​​de Frankenstein via l'acquisition comme le peuvent les joueurs d'entreprise. Nous ne pouvons pas dissimuler des logiciels mal intégrés aux consultants et aux gestionnaires de comptes.

En tant que produit de consommation (pensez à Instagram, à une Nintendo Switch ou à un Roomba), nous devons être utilisables dès la sortie de la boîte. Pour une plateforme marketing tout-en-un destinée à propulser votre entreprise, c'est difficile ! Et cela signifie que chaque chose que Mailchimp construit doit être connectée de manière transparente du point de vue de l'expérience.

Mais, cloisonner parfaitement les projets introduit alors un risque d'expérience . Ce n'est pas que le code ne peut pas être écrit indépendamment. Cela peut être réalisé, mais il y a toujours un risque que les produits aient l'air d'avoir été construits par différentes équipes, et cette expérience peut être vraiment déroutante pour l'utilisateur. Nous nous heurtons à la loi de Conway : nos clients peuvent dire où se termine le travail d'une équipe et où commence le travail de l'autre équipe.

Vous essayez donc de connecter le travail de chacun, pas seulement sur le back-end, mais aussi sur le front-end. À l'ère de l'écosystème, dominée par l'excellence CX d'acteurs comme Apple, cela est devenu presque un enjeu de table dans l'espace grand public. Mais c'est un cauchemar mythique du mois de l'homme , mais pas du point de vue de l'ingénierie cette fois. C'est du point de vue de la conception des services. Au fur et à mesure que nous ajoutons plus de personnes à tout ce travail connecté «de bout en bout», tout ralentit pour devenir une exploration collaborative.

Outre le troisième correctif que j'ai noté ci-dessus, en utilisant des outils et des cadres plutôt que des over-watchers et des stage-gates, il existe une autre soupape de libération : faites des compromis délibérés sur l'expérience client . Plus précisément, où sommes-nous à l'aise pour diffuser une expérience déconnectée du reste (c'est-à-dire inférieure à la normale) ? Accepter le risque et aller de l'avant est le travail du chef de produit. Et vous utilisez donc certains critères pour le trier (peut-être que les nouvelles zones à faible trafic de l'application ne respectent pas les mêmes normes d'expérience que vos «vaches à lait») et prenez une décision (par exemple, itération et apprentissage par-dessus le polissage sur adjacent nouveautés). Ceci, bien sûr, va au-delà de la conception.

Vous pouvez toujours court-circuiter la loi de Brooks en choisissant de pare-feu, y compris des efforts qui, dans un monde parfait, ne devraient pas être pare-feu !

"

Je vais mettre cela en garde en disant que le logiciel que je construis ne tue personne. Je ne préconiserais pas cette approche si je construisais un dispositif médical. Mais dans une société de logiciels de marketing, je peux délibérément isoler les équipes en sachant que j'ai augmenté les risques d'incompatibilité en échange d'une augmentation du personnel et d'une évolution plus rapide.

Je suis triste d'admettre que le Mythical Man-Month est une réalité dans mon entreprise, et je soupçonne également la vôtre. Mais c'est gérable - c'est l'essentiel. La parallélisation et l'atténuation des dépendances nous offrent une issue qui limite le statut quasi mythique du mois-homme mythique . Ainsi, la prochaine fois que la dichotomie frappante est soulevée dans votre entreprise (échelle pour aller plus lentement ou abandonner vos aspirations), rappelez-vous que si vous êtes intelligent dans la façon dont vous alignez le travail, vous pouvez toujours grandir.

N'oubliez pas le côté plus doux de la mise à l'échelle

Gardez à l'esprit que la gestion du Mythical Man-Month n'empêchera pas les ingénieurs de l'invoquer comme de la magie noire. Ils invoquent le principe non seulement parce qu'il y a du vrai là-dedans, mais parce que la mise à l'échelle craint (toujours) d'un point de vue émotionnel et cognitif. Si je pense que je suis payé pour écrire du code et résoudre les problèmes des clients, la dernière chose que je veux faire est de changer ma routine et de comprendre comment travailler avec de nouvelles personnes et une équipe plus importante.

Au fur et à mesure que vous faites évoluer votre entreprise, n'oubliez pas de faire preuve d'empathie face à la douleur de la mise à l'échelle et du changement. Une équipe qui ajoute ne serait-ce qu'un seul membre devient une toute nouvelle équipe du point de vue de la confiance et de la culture. Les gens sont fatigués de ce changement. Cela signifie que pendant que vous gérez et atténuez le mois mythique de l'homme , vous devrez gérer les émotions entourant la croissance. C'est peut-être la tâche la plus critique de toutes.

Une forte croyance dans le Mythical Man-Month par une équipe en elle-même peut concrétiser ses conclusions. C'est fondamentalement l'équivalent de la croyance en voler dans Peter Pan. Si l'équipe pense que la mise à l'échelle les ralentira et qu'elle n'accepte pas le changement, elle ralentira effectivement.

Ainsi, lorsque vous travaillez à gérer les dépendances et à introduire des outils pour vous aider à évoluer, assurez-vous de communiquer clairement le pourquoi des pratiques. Impliquez les gens dans la sélection du travail et des processus qui atténuent les problèmes de mois-homme, car lorsqu'ils font partie du changement et que leurs perspectives changent, la mise à l'échelle devient soudainement au moins culturellement possible.