Le mois mythique de l'homme mythique

En tant que chef de produit dans une entreprise de technologie, je suis un besoin sans fond. Mon travail en tant que chef de produit chez Mailchimp est de mettre le produit sur le marché qui va gagner dans un espace très compétitif. 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 que nous en faisons 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 Le Mois de l'homme mythique [19659007] référencé. C'est comme une de ces boules anti-stress où si vous pressez une extrémité, puis sort le Mois-homme mythique à l'autre extrémité.

Publié par Frederick Brooks en 1975 (vous vous souvenez de 1975, 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, pas raccourcit, le calendrier. »

Solution facile. Désormais, je ne ferai qu'engager des femmes dans des projets (voir Le retour du roi et la lutte contre le roi-sorcier d'Angmar ).

Mais supposons que Brooks ' ce point est valable quelle que soit l'identité de genre des ingénieurs logiciels 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.

Lorsque j'ajoute des gens à une équipe, ils doivent être intégrés et greffés dans le projet. Quelqu'un doit se tailler le bon travail pour eux. L'équipe doit communiquer pour s'assurer que leurs trucs fonctionnent tous ensemble, et chaque personne supplémentaire augmente géométriquement cette complexité de 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:

Grand aperçu )

C'est absolument un bon point. C’est pourquoi je l’entends tellement au travail. Les contributeurs individuels épuisés et les dirigeants épuisés vont tout jeter – nous ne pouvons pas aller plus vite, nous ne pouvons pas faire plus, arrêter l'embauche, lire Le Mois de l'homme mythique et désespérer! La seule solution est apparemment d'arrêter de croître et de tuer certains projets.

Quand je dis en tant que CPO: "nous allons faire cette chose!", La réponse est alors souvent: "OK, alors qu'allons-nous tuer ? »Le Mois-homme mythique 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 mythe réel, et j'appelle le hogwash.

Et pris à 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 les quatre personnes – quatre hommes apparemment. Rien de plus ne fait que ralentir le tout. Quelqu'un devrait envoyer à Amazon, Apple et Google des copies du livre, afin qu'ils puissent corriger leurs organisations manifestement gonflées.

Le seul problème avec cette approche est que dans un espace où la concurrence s'intensifie et itère et s'exécute – bourrant simplement l'organisation croissance – l'édition et la concentration de la charge de travail pour correspondre peuvent être une recette pour l'extinction. Vous serez plus sain d'esprit et moins stressé – jusqu'à ce que vous ayez quitté votre emploi.

Et en tant que propriétaire de la gestion des produits pour mon entreprise, je ne suis pas indifférent à ce besoin de ralentir et de se concentrer. Nous devons prioriser impitoyablement! Sans aucun doute. Mais gérer un produit est un exercice de contradiction. Je dois donner la priorité à ce que je possède tout en planifiant simultanément pour en faire plus. Mais que dois-je faire face au mois-homme mythique ?

É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 à faire évoluer le développement de produits. Si le travail que vous essayez d'accomplir est purement partitionnable, alors allez-y et ajoutez des gens! Si votre travail est tous connectés, alors à un moment donné, ajouter des gens 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 évoluer.

C'est pourquoi l'ajout de cœurs à un processeur peut augmenter la vitesse expérimentée de votre ordinateur ou de votre téléphone jusqu'à un certain point – ce que les ingénieurs devraient 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 responsable de produit puis entre la mise à l'échelle et la priorisation impitoyable peut être géré.

1. Vous priorisez impitoyablement dans des endroits qui sont un seul thread (le carnet de commandes d'une équipe de produits, 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 de support (informatique globale, juridique, RH, etc.), ce qui entraîne des goulots d'étranglement.

Tout est une question de gestion des dépendances

Le travail d'un chef de produit devient alors non seulement la création une stratégie, mais exécutée de manière à maximiser la valeur pour le client et l'entreprise en garantissant le débit et en réduisant autant que possible les risques 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'à l'ancien. L'interdépendance est une maladie incurable mais ses symptômes peuvent être gérés avec de nombreux traitements.

Une solution consiste à élaborer une orientation stratégique pour l'entreprise qui minimise ou limite la dépendance grâce à un portefeuille soigneusement sélectionné de initiatives. Le plus drôle ici, c'est que beaucoup de gens vont repousser cela. Disons que j'ai deux options, une où je peux exécuter les 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 les projets D1, D2 et D3 qui ont des tonnes d'interdépendances (disons qu'elles ont toutes un impact sur le même produit ). Il arrive souvent que le Mois-homme mythique soit invoqué contre le premier plan plutôt que contre le dernier. Parce que sur le papier, il 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 le personnel supplémentaire.

Gardez à l'esprit, Je ne dis pas de choisir un tas de travail pour l'entreprise qui n'est pas liée. Mailchimp ne construira pas de four à micro-ondes de sitôt. Tout travail doit aller dans la même direction à long terme. Cette approche peut augmenter le risque lié à l'expérience client (dont nous parlerons plus loin) ainsi que la charge pesant sur les fonctions mondiales telles que la recherche client.

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

La contention dans le Mythical Man-Month est que lorsque vous ajoutez des gens à 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, c'est 6 lignes de communication. Une personne supplémentaire, dans ce cas, conduit à doubler la communication! Amusement. (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 bénéficient donc de différents degrés d'autonomie. Peut-être que le chef de projet doit communiquer avec tout le monde dans l'équipe. Mais un ingénieur travaillant sur l'API doit-il communiquer avec le responsable du marketing produit? Ou le responsable marketing peut-il simplement passer par le chef de produit? Un bon processus et une bonne cadence de réunion peuvent alors éliminer la communication et les réunions inutiles. Le fait est que la formule d'intercommunication de Brooks est une limite supérieure de coordination pas une condamnation à mort.

Enfin, utilisez des outils, des principes et des cadres combinés à un travail indépendant sur 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 à se déplacer plus ou moins dans la même direction, alors leur travail indépendant est plus susceptible de se retrouver «plus rapprochés» que si leurs KPI encouragent le mouvement orthogonal. Cela ne garantira pas que les choses s’emboîtent parfaitement, mais seulement que le travail que je dois faire pour les assembler à l’avenir est moindre qu’il ne le serait 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.

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

Étant donné que le client de Mailchimp est souvent un propriétaire de petite entreprise qui est un novice en marketing (et il y a des millions de petites entreprises) les propriétaires sont devenus des spécialistes du marketing dans le monde entier), 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 entreprises. Nous ne pouvons pas utiliser des logiciels mal intégrés avec des consultants et des gestionnaires de comptes.

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

Mais, le partitionnement parfait des projets introduit alors le 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 savoir où se termine le travail d'une équipe et où commence le travail de l'autre équipe.

Donc, vous essayez de connecter le travail de tout le monde ensemble – pas seulement sur le back-end mais aussi sur le front-end, aussi . À l'ère de l'écosystème, dominé par l'excellence CX de joueurs comme Apple, cela est devenu presque un enjeu de table dans l'espace des consommateurs. Mais c'est un cauchemar Mythical Man-Month mais pas du point de vue technique cette fois. C'est du point de vue de la conception des services. Au fur et à mesure que nous ajoutons de plus en plus de personnes à tout ce travail connecté de bout en bout, tout ralentit vers une exploration collaborative.

À part le troisième correctif que j'ai noté ci-dessus, en utilisant des outils et des cadres plutôt que des surveillants et des scènes – portes, il y a une autre soupape de décharge: faire des compromis délibérés sur l'expérience client . Plus précisément, où sommes-nous à l'aise de publier une expérience qui est déconnectée des autres (c.-à-d. Qui est inférieure à la normale)? Accepter les risques et aller de l'avant est la tâche du chef de produit. Et donc vous utilisez certains critères pour le trier (peut-être que cela ne tient pas les nouvelles zones à faible trafic de l'application aux mêmes normes d'expérience que vos «vaches à lait»), et prenez une décision (par exemple, itération et apprentissage du polissage sur des zones adjacentes). innovations).

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

[19659010] Je mettrai cela en garde en disant que le logiciel que je crée ne tue personne. Je ne recommanderais pas cette approche si je construisais un appareil médical. Mais dans une société de logiciels de marketing, je peux délibérément isoler des équipes en sachant que j'ai augmenté les chances d'incompatibilité comme compromis pour augmenter le personnel et aller plus vite.

Je suis triste d'admettre que le Mythical L'homme-mois est une réalité dans mon entreprise, et je soupçonne également la vôtre. Mais c'est gérable – c'est le résultat. La parallélisation et l'atténuation de la dépendance nous offrent une issue qui limite le statut quasi mythique du Mois-homme mythique . Donc, la prochaine fois que la dichotomie sévère augmentera dans votre entreprise (évoluez pour ralentir ou abandonner vos aspirations), souvenez-vous que si vous êtes intelligent dans la façon dont vous alignez le travail, vous pouvez toujours grandir.

Oubliez le côté plus souple de la mise à l'échelle

Gardez à l'esprit que la gestion du Mois-homme mythique n'empêchera pas les ingénieurs de l'invoquer comme par magie noire. Ils invoquent le principe non seulement parce qu'il contient une part de vérité, mais parce que la mise à l'échelle aspire (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 trouver comment travailler avec de nouvelles personnes et une équipe plus large.

Lorsque vous faites évoluer votre entreprise, souvenez-vous pour faire preuve d'empathie face à la douleur de l'entartrage et du changement. Une équipe qui ajoute même un seul membre devient une toute nouvelle équipe d'un point de vue culturel et de confiance. Les gens sont fatigués de ce changement. Cela signifie que pendant que vous allez gérer et atténuer le Mois-homme mythique vous devrez gérer les émotions entourant la croissance. C'est peut-être la tâche la plus critique de toutes.

La forte croyance en le mois mythique de l'homme par une équipe en elle-même peut faire en sorte que ses conclusions deviennent réalité. C'est essentiellement l'équivalent de la croyance en voler à Peter Pan. Si l'équipe pense que la mise à l'échelle les ralentira et qu'ils n'adhéreront pas au changement, ils ralentiront en effet. les pratiques. Faites participer les gens à 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.

(ra, il )