Business : Où nous mène cette route?

Ce n’est pas parce que vous avez une feuille de route que vous êtes sur la bonne voie.

Il y a cette célèbre lignée d’Alice au pays des merveilles où le chat du Cheshire dit « Si vous ne savez pas où vous allez, n’importe quelle route vous y mènera« . C’est une reformulation poétique de ce à quoi Marty Cagan aurait pu penser lorsqu’il a tué le concept de la feuille de route dans sa préface Christina Wodtkes’Livre brillant Radical Focus. Dans ce document, Cagan dit essentiellement que les feuilles de route ne sont devenues rien de plus que la manière dont la direction structure ses listes de souhaits, ce qui transforme les équipes de développement en usines de fonctionnalités et fait un mauvais travail de visualisation de la situation dans son ensemble.

Les feuilles de route ont été inventées par Boeing comme un moyen de garder une trace des innombrables pièces mobiles dans la construction d’avions dans les délais et le budget. C’était un outil valable dans ce contexte puisque l’état final était si clairement défini. Cependant, lorsque chaque hypothèse doit être constamment remise en question, vous devez être agile non seulement dans l’exécution, mais également au niveau stratégique. Vous ne pouvez donc pas vous permettre de faire des plans à long terme, car votre objectif aura changé avant que l’encre ne sèche sur le papier. Ou au moins avant la fin de votre horizon de planification, qui selon l’église d’OKR est généralement de quatre mois.

Maintenant, quatre mois peuvent sembler éternels dans un pays en démarrage rapide, suffisamment de temps pour un pivot ou deux.

C’est cependant un clin d’œil en termes de feuilles de route produits. La plupart des exemples utiles que j’ai vus ou que j’ai trouvés moi-même s’étendent tellement au-delà de l’horizon qu’il est impossible de dire comment les sols se seront déplacés sous vos pieds avant votre arrivée.

Toujours chaque fois que j’ai vu des équipes de développement être en mesure de fournir une valeur commerciale substantielle, il y a eu suffisamment de temps (ou plutôt, suffisamment de temps a été créé par la direction) pour poursuivre des objectifs à long terme.

Lorsque cela a été le cas, la feuille de route a fonctionné comme un document presque intemporel, affiché sur le mur pour rappeler à tout le monde le vrai nord. La définition d’objectifs a ensuite été un exercice de décomposition de la feuille de route en livrables tout en essayant de voir lesquels d’entre eux créent la plus grande valeur commerciale à court terme. Si ce travail est effectué de manière suffisamment approfondie, le propriétaire du produit et l’équipe de développement auront peu de problèmes à hiérarchiser les éléments de backlog dans les sprints.

C’est ce que les programmeurs appellent le «chemin heureux». Avec suffisamment de grain et une vision limpide de l’endroit où vous voulez vous retrouver, c’est certainement un bon moyen de progresser. Mais comme l’indique le terme chemin heureux, suivre avec succès une feuille de route à long terme doit être considéré comme l’exception plutôt que la règle. Parce que, comme Mike Tyson l’a dit un jour: « Tout le monde a un plan jusqu’à ce qu’il soit frappé à la bouche. » Ce qui est vrai dans la boxe est vrai dans les affaires: la planification n’est pas une baguette magique qui donne le contrôle sur les prochains mouvements de vos concurrents.

Et il arrive donc que nous finissions souvent par aller de l’avant en mode combat de rue, avec une mise au point dispersée et des agendas réactifs. C’est probablement le problème le plus important à résoudre pour un chef de produit, mais comment procéder?

J’ai obtenu des réponses très utiles à cette question l’autre jour quand j’ai entendu Gustav Grenås parler au sujet des feuilles de route. Du point de vue de la conception industrielle et du développement matériel, Gustav voit le problème de la feuille de route comme l’un des crédibilité. Trop souvent, les seules équipes qui comprennent vraiment à quel point elles sont irréalistes sont les équipes de développement. Cela me semble assez vrai, mais comment régler le problème?

Dans l’esprit de Gustav, vous devez reculer de quelques pas et commencer à parler du produit architecture. Dans le monde du matériel, les trois éléments constitutifs les plus importants sont variantes de produits, variantes de module et traits. Ces trois aspects du produit ont tous besoin de leur propre feuille de route, qui doit ensuite être tracée en vagues de lancement. L’exemple de Gustav tournait autour d’un classique du design. Une lampe industrielle française composée de différents modules, qui peuvent être configurés en un certain nombre de variantes de produits, chacune avec ses propres caractéristiques. Il a ensuite montré comment synchroniser les feuilles de route pour chacun de ces aspects.

Une idée si simple et pourtant si puissante. De toute évidence, un concept mérite d’être introduit dans le monde du développement logiciel, où les feuilles de route sont souvent axées sur les fonctionnalités et l’architecture est considérée comme une préoccupation technique.

Cela dit, je ne peux pas non plus m’empêcher de penser aux défis particuliers auxquels est confronté un architecte logiciel chargé d’élaborer une feuille de route pour ce que Gustav appelle des variantes de produits et de modules. Parce que même dans les projets matériels les plus difficiles (je suis impliqué dans quelques-uns en ce moment), il est relativement facile d’identifier les pièces mobiles individuelles, mais dans le logiciel, il semble y avoir une tendance naturelle dans la direction opposée. À moins que vous ne fassiez un effort sérieux et continu, vous vous retrouvez avec une base de code monolithique où tout est à peu près interconnecté, ce qui rend difficile de planifier des «modules» individuels.

Bien sûr, ce n’est pas une nouvelle, c’est pourquoi nous avons mis au point des concepts tels que la programmation orientée objet, le développement piloté par les tests, la conception pilotée par domaine et les architectures orientées services. Tous visant à découplage, un terme utilisé par les ingénieurs logiciels pour indiquer dans quelle mesure un système peut être traité comme un ensemble de modules indépendants.

Maintenant, je ne suis pas sûr que cela doive être ainsi, mais d’après mon expérience, il semble qu’une certaine marque d’entropie fonctionne, ce qui fait qu’un projet logiciel donné prend une courbe en cloche de complexité.

Commençant avec une table rase, il y aura toujours une période de grâce où un programmeur individuel contrôle la base de code entière, généralement en respectant un certain cadre ou une école de pensée.

Puis, inévitablement, la complexité commence à s’introduire. Plus de personnes sont ajoutées à l’équipe, de nouvelles technologies sont testées, le besoin de documentation augmente rapidement. C’est le prix du succès, vous n’obtiendrez pas l’entropie sans utilisateurs actifs. C’est vraiment une bonne chose, mais cela devient aussi un défi. D’un point de vue technique, bien sûr, mais aussi pour la gestion.

Parce que lorsque vous êtes dans le vif du sujet, en haut de la courbe en cloche de la complexité, c’est généralement lorsque vous avez * vraiment * besoin de prendre le contrôle de la feuille de route du produit. Il s’agit de la «phase de mise à l’échelle» et si vous êtes parvenu à ce stade, il est probable que vous ayez attiré l’attention de la communauté des investisseurs. Cela peut être flatteur, mais l’argent a un prix. On s’attend maintenant à ce que vous puissiez accélérer tout en bénéficiant d’une meilleure maîtrise de la feuille de route du produit. Dans le langage des startups, « Qu’est-ce qui vous a amené ici (= traction, une base d’utilisateurs enthousiaste) ne vous y amènera pas «  (= évaluation en milliards de dollars).

Les règles du jeu changent donc à ce stade. La mentalité doit passer de celle des cow-boys à celle des talibans (c’est ce que nous disions). Vous ne pouvez plus vous concentrer exclusivement sur le développement d’un produit que les gens vont adorer, mais vous devrez consacrer une grande partie de vos efforts à combattre la complexité, de sorte que vous sortirez de l’autre côté de la courbe en cloche avec une architecture qui permet suffisamment de liberté de mouvement pour pouvoir, encore une fois, trouver et exécuter des feuilles de route crédibles.

Maintenant, j’ai été témoin de cela dans la nature mais je n’ai jamais donné beaucoup de sens à cette expérience. Entendre Gustav partager ses pensées m’a fait voir les bois pour les arbres. L’idée d’avoir toujours au moins trois pistes parallèles constituant une feuille de route produit m’a donné un vrai moment de haine, même si cela m’a aussi fait voir que même si c’est un idéal qui vaut la peine d’être recherché, vous ne devriez pas vous sentir trop mal si vous ne pouvez pas toujours le faire fonctionner par vous-même. Il se peut simplement que vous vous trouviez dans cet endroit sombre et déroutant où tout est – et doit être – un gâchis emmêlé.

(Note latérale: L’un des meilleurs (et des plus réconfortants) livres que j’ai lu sur cette partie héroïque du parcours entrepreneurial est Le milieu désordonné: trouver votre chemin à travers la partie la plus difficile et la plus cruciale de toute entreprise audacieuse par Scott Belsky, fondateur de Behance)

Alors, vers quoi vous tourner si vous ne comprenez pas l’architecture de votre produit et qu’il est difficile de voir au-delà de la prochaine période OKR (ou même du prochain sprint)?

Eh bien, il y a un livre pour ça. Comme toujours, dans la méthodologie de conception, les gourous se battent pour l’attention et celui qui a obtenu sa juste part est Donald G. Reinertsen, auteur de Gérer l’usine de design aussi bien que Les principes du flux de conception des produits (Je suis tombé sur lui en lisant sa préface au livre de Dean Liffingwell Configuration logicielle agile requise, qui mérite également d’être mentionné / lu dans ce contexte).

Reinertsen est donc l’un des évangélistes anti-feuille de route. Avec son expérience dans les marines, il fait valoir que les équipes de logiciels devraient libérer suffisamment de capacité pour pouvoir agir selon «l’intention des commandants». Ceci est un concept issu de la doctrine du leadership appelé commande de mission, ce qui, de façon intéressante, était en soi une sorte de réaction à l’échec de l’équivalence militaire des feuilles de route, ce qui est logique si vous envahissez la France, mais sont inefficaces pour diriger de petites forces opérationnelles opérant derrière les lignes ennemies. Dans ces cas, vous voulez que les gens sur le terrain prennent les décisions stratégiques. C’est la gestion en disant Je me fiche de comment vous y arrivez.

Transfert de la vie dans le réel des tranchées aux principales équipes de logiciels, Reinertsen a commencé à penser que tout le problème se résumait à un seul mot: files d’attente.

Une si petite chose innocente, non? Faux. Les files d’attente sont le Viet Cong du génie logiciel; la menace asymétrique que vous ne pouvez pas prévoir, sauf qu’elle trouvera toujours un moyen de vous mordre.

Si le concept semble vague, essayez plutôt d’utiliser le mot arriéré. Maintenant, vous voyez, le fléau de l’existence d’un chef de produit. Et pourquoi en est-il exactement ainsi?

Parce que sa longueur et son ampleur sont des indicateurs avancés de complexité. La façon la plus sûre de savoir que vous êtes au milieu du désordre est que votre arriéré nous a fait perdre le contrôle. Produit gestionnaires restera inconscient de cela pendant un certain temps, mais le produit les propriétaires voir de première main. Peu importe la clarté avec laquelle ils essaient de communiquer leur «intention du commandant» à l’équipe lors des réunions de planification de sprint, ils parviennent à obtenir de moins en moins de témoignages d’utilisateurs par la porte. Au lieu de cela, l’équipe s’engage dans des «histoires techniques», allant de l’orchestration du nouveau cluster de serveurs et de l’automatisation des pipelines de déploiement, à la configuration d’un environnement pour les nouveaux développeurs rejoignant l’équipe, la documentation des nouvelles ressources API ou le nettoyage des dépendances. Quiconque y est allé connaîtra ce sentiment de naufrage.

C’est pourquoi Reinertsen crie du haut de ses poumons que:

«Le paradigme dominant pour gérer le développement de produits est faux. Pas seulement un peu faux, mais faux dans son cœur. »

Il prétend que nous nous sommes mis dans le pétrin en poursuivant les mauvais objectifs. Nous essayons de maximiser l’efficacité et de minimiser la variabilité, puis nous nous demandons pourquoi l’innovation se dissipe lentement alors que les temps de cycle s’allongent de plus en plus. Reinertsen fait valoir que tant que les équipes de développement arriveront à terminer chaque travail à leurs propres conditions (= arriver à utiliser leur propre définition de fait), cela résoudra le problème de l’augmentation des arriérés. Cela conduira ensuite à libérer suffisamment de capacité pour que l’équipe puisse trouver le moyen de travailler le type de magie qui répondra à l’intention du commandant.

(Note annexe 2: Il me semble que Reinertsen s’inspire assez du classique de gestion d’Eliyahu M. Goldratt L’objectif: un processus d’amélioration continue. Ce livre n’a rien à voir avec les logiciels. En fait, ce n’est même pas vraiment un livre de gestion au sens classique, mais un roman (également converti en écran argenté) sur Alex Rogo, le directeur d’une usine en difficulté où, malgré de nouveaux robots brillants, des travailleurs brillants et une forte demande pour les produits, tout semble aller mal. Il se trouve que Rogo rencontre son ancien professeur de physique Jonah, qui vient de commencer sa deuxième carrière en tant que consultant en gestion, une profession qui n’existait pas / n’avait pas de nom à l’époque (The Goal a été publié en 1986). Avec l’aide de la réflexion de Jonah sur la théorie de la file d’attente, Rogo parvient finalement à renverser la situation. Comme par magie, la productivité semble augmenter à mesure que les gens sont moins occupés. Rogo lui-même libère suffisamment de temps libre pour commencer à travailler sur la sauvegarde de son mariage, qui souffre comme effet secondaire d’être mangé vivant par le travail. La clé pour faire en sorte qu’Alex Rogo agisse selon les théories de Jonas, c’est quand il se porte volontaire pour conduire son fils dans une expédition de reconnaissance dans les montagnes et voit de première main à quel point le groupe est aussi rapide que l’enfant le plus lent de la lignée et que cela en vaut la peine pour le reste du groupe de faire tout investissement pour aider à l’accélérer. C’est une bonne lecture de ce livre, et l’un des premiers à commencer à explorer le concept de lean.)

Comme pour tout gourou digne de ce nom, les idées de Reinertsens semblent vraiment attrayantes sur le papier. Testé au combat dans le vrai sens du terme. Comme avec tout une approche cependant, il vous donne également juste une boîte à outils limitée. Un vocabulaire qui vous servira bien dans certaines situations mais qui doit être complété. Je suis convaincu que le point de vue de Gustav Grenås sur les feuilles de route multi-pistes a donné un tel complément. Très inspirant en effet.