Comment je livre des projets informatiques dans de grandes entreprises technologiques, par Sean Goedecke
Comment je livre des projets informatiques dans de grandes entreprises technologiques, par Sean Goedecke
J'ai livré beaucoup de projets différents au cours des 10 dernières années dans le domaine de la technologie. On me confie souvent la direction de nouveaux projets lorsqu'il est important de bien faire les choses, parce que je suis bon dans ce domaine. Livrer dans une grande entreprise de technologie est une compétence très différente de celle d'écrire du code, et beaucoup de gens qui sont excellents en écriture de code sont terribles en livraison.
Voici ce à quoi je pense lorsque je dirige un projet et ce que j'ai vu faire de travers par les gens.
Livrer est difficile
L'erreur la plus fréquente que je constate est de supposer que livrer est facile. L'état par défaut d'un projet est de ne pas être livré : d'être retardé indéfiniment, d'être annulé ou de sortir à moitié cuit et de prendre feu. Les projets ne sont pas livrés automatiquement une fois que tout le code a été écrit ou que tous les tickets Jira ont été fermés. Ils sont livrés parce que quelqu'un prend en charge la tâche difficile et délicate de les livrer.
Cela signifie que dans presque tous les cas, livrer doit passer en premier. Vous ne pouvez pas avoir d'autre priorité. Si vous passez tout votre temps à vous soucier de peaufiner l'expérience client (par exemple), vous ne livrerez pas ! Être obsédé par l'expérience client est un comportement louable lorsque vous êtes un ingénieur de l'équipe, mais une erreur si vous dirigez le projet. Vous devez chérir les autres ingénieurs de votre équipe qui font ce travail et leur apporter tout le soutien possible. Mais votre principale préoccupation doit être de livrer le projet. C'est un travail trop difficile à réaliser pendant votre temps libre.
D'après mon expérience, les projets sont presque toujours livrés parce qu'une seule personne les a fait livrer. Pour être clair, cette personne n'écrit pas tout le code et ne fait pas tout le travail, et je ne dis pas que le projet pourrait être livré sans l'appui d'une équipe entière. Mais il est très important qu'une seule personne sur le projet ait une compréhension de bout en bout de l'ensemble : comment il s'articule techniquement, et quel produit ou objectif commercial il sert. Les bonnes équipes et les bonnes entreprises le comprennent et veillent à ce que chaque projet ait un seul ingénieur responsable (ce poste est généralement appelé « responsable technique » ou « DRI »). Les mauvaises équipes et entreprises ne le font pas, et les projets vivent ou meurent selon qu'un ingénieur assume ou non ce rôle de son propre chef.
Qu'est-ce que la livraison ?
Pourquoi tant d'ingénieurs pensent-ils que livrer est facile ? Je sais que cela peut sembler extrême, mais je pense que de nombreux ingénieurs ne comprennent pas ce qu'est le fait de livrer au sein d'une grande entreprise technologique. Que signifie livrer ? Il ne s'agit pas de déployer du code ou même de mettre une fonctionnalité à la disposition des utilisateurs. Livrer est une construction sociale au sein d'une entreprise. Concrètement, cela signifie qu'un projet est livré lorsque les personnes importantes de votre entreprise estiment qu'il est livré. Si vous déployez votre système, mais que votre manager, votre vice-président ou votre PDG n'en est pas satisfait, c'est que vous n'avez pas livré. (Peut-être avez-vous livré quelque chose, mais vous n'avez pas livré le projet en tant que tel.) Vous ne savez que vous avez livré que lorsque les dirigeants de votre entreprise reconnaissent que vous avez livré. Un message de félicitations dans Slack de la part de votre vice-président est un bon signe, tout comme un article de blog interne qui revendique la victoire. Pour les petites livraisons, un « atta-boy » de votre manager fera l'affaire.
Cela semble probablement circulaire, mais je pense qu'il s'agit d'un point très important. Bien sûr, si vous déployez quelque chose que les utilisateurs adorent et qui rapporte beaucoup d'argent, vous avez livré. Mais cela n'est vrai que parce que satisfaire les utilisateurs et gagner de l'argent est quelque chose qui rend votre équipe de direction heureuse. Si vous livrez quelque chose que les utilisateurs détestent et qui ne rapporte rien, mais que votre équipe dirigeante est heureuse, vous avez quand même livré. Vous pouvez en penser ce que vous voulez, mais c'est vrai. Si vous n'aimez pas ça, vous devriez probablement aller travailler pour des entreprises qui se soucient vraiment de la satisfaction de leurs utilisateurs.
Les ingénieurs qui pensent que la livraison consiste à délivrer une spec ou à déployer un code se retrouveront à maintes reprises dans des situations d'échec.
Communication
Si votre tâche principale lors de la livraison d'un produit est de faire en sorte que les dirigeants de votre entreprise soient satisfaits du projet, qu'est-ce que cela signifie en pratique ? Tout d'abord, vous devez savoir clairement ce que l'entreprise cherche à obtenir du projet. Parfois, il s'agit d'obtenir plus d'argent d'un petit groupe d'utilisateurs (par exemple, des fonctionnalités d'entreprise). Parfois, il s'agit de dépenser de l'argent pour augmenter le nombre total d'utilisateurs (par exemple, des fonctionnalités gratuites spectaculaires). Parfois, il s'agit d'apaiser un très gros client particulier en créant une fonction spécialement pour lui. Parfois, il s'agit simplement du projet favori d'un vice-président ou d'un PDG influent, et vous devez vous aligner sur sa vision. Il existe de nombreuses raisons possibles, et si vous voulez livrer le projet, vous devez savoir lesquelles s'appliquent dans ce cas. Alignez votre travail et votre communication en conséquence ! Par exemple, les fonctionnalités d'entreprise n'ont souvent pas besoin d'une interface utilisateur spectaculaire mais sont totalement inflexibles en termes d'exigences, les fonctionnalités destinées aux utilisateurs finaux doivent être peaufinées, les projets de prédilection signifient que vous devez être en communication active avec les personnes qui ont fait bouger les choses, et ainsi de suite.
Deuxièmement, quel que soit l'objectif du projet, votre équipe de direction (les personnes de votre chaîne hiérarchique qui s'intéressent au projet) n'aura toujours pratiquement aucun contexte technique sur le projet par rapport à vous. Cela signifie qu'ils vous feront confiance pour les estimations, pour répondre aux questions techniques et pour anticiper les problèmes techniques. Le maintien de cette confiance doit être votre priorité absolue. S'ils n'ont pas confiance en votre capacité à faire le travail et à les tenir informés, vous ne livrerez pas. Ils réduiront les risques en annulant le projet ou en le laissant se dérouler sans aucune attention ni célébration (rappelez-vous qu'un lancement sans célébration n'est pas une livraison) ou ils vous mettront sur la touche et s'adresseront à un autre ingénieur, qui sera alors officiellement ou officieusement celui qui livrera le projet. Quoi qu'il en soit, vous le sentirez au moment de l'évaluation et ils s'adresseront à quelqu'un d'autre pour la prochaine fois.
Comment maintenir la confiance avec votre équipe de direction ? Cette question pourrait faire l'objet d'un article (ou d'un livre) à elle seule, mais voici mon résumé :
- La meilleure chose est d'avoir un historique des livraisons effectuées par le passé, si vous pouvez l'obtenir
- Faites preuve de confiance (si vous êtes visiblement inquiet, ils le seront aussi)
- Faites preuve de compétence. Vous devez avoir l'air d'un contrôleur de mission de la NASA.
- Communiquez de manière professionnelle et concise, et ne les obligez pas à vous courir après pour obtenir des mises à jour : publiez un fil de discussion quotidien ou hebdomadaire quelque part.
Il est beaucoup, beaucoup plus important de faire ces choses que de livrer le projet sans aucun bogue à la date limite exacte. Si un projet doit être retardé pour des raisons techniques, d'après mon expérience, vous n'en subirez pas les conséquences si vous le communiquez clairement, en toute confiance (et idéalement avec un certain préavis). En fait, paradoxalement, il est souvent préférable pour vous qu'un problème quelconque entraîne un retard, pour la même raison que l'ingénieur d'astreinte héroïque qui corrige un incident reçoit plus de crédit que l'ingénieur prudent qui en prévient un.
Mettre en production
Malgré cela, il faut encore mettre le projet en production. Le problème le plus courant ici est qu'il manque un détail clé. Il s'agit parfois d'un détail technique : nous comptons peut-être sur le stockage des documents des utilisateurs dans Memcached, mais de nombreux documents font plusieurs mégaoctets et seront plus volumineux que la taille des blocs de Memcached. Il s'agit parfois d'un détail de coordination : l'équipe de la plateforme qui possède Memcached s'attendait peut-être à un dixième du trafic que notre projet lui enverra, elle a donc convoqué une réunion avec les vice-présidents et a retardé le projet. Il s'agit parfois d'un détail juridique : les données des utilisateurs sont peut-être étonnamment sensibles, et notre système ne dispose pas des contrôles nécessaires pour les traiter en toute sécurité. Ces problèmes peuvent provenir de n'importe où et sont très difficiles à anticiper. Pour y faire face, il faut avoir une connaissance technique approfondie du système et être capable de pivoter rapidement.
Par exemple, vous avez peut-être lu ce premier exemple et vous vous dites « vous pourriez répartir les documents sur plusieurs clés Memcached, ou augmenter la taille des blocs, ou passer à Redis, etc... ». Ce sont toutes des solutions potentielles ! Mais il est impossible de savoir laquelle de ces solutions fonctionnera - et, plus important encore, laquelle de ces solutions ne fera pas exploser le calendrier du projet - à moins d'en avoir une compréhension approfondie.
C'est d'autant plus important que le problème en question n'a même pas besoin d'être réel. Avant le lancement d'un projet, il est très fréquent que d'autres équipes ou ingénieurs soulèvent des problèmes potentiels (par exemple, « hé, sommes-nous sûrs que les données de l'utilisateur tiendront dans Memcached ? »). Si personne ne se manifeste pour expliquer pourquoi ce n'est pas un problème (ou, si c'en est un, comment il est résolu avant le lancement), le projet sera retardé, et vous en serez responsable. Pourquoi ? Parce que votre responsable (ou le sien) ne saura pas s'il s'agit d'un problème grave. C'est pour cela qu'ils vous paient ! Si vous n'intervenez pas pour régler le problème, il préférera naturellement jouer la carte de la prudence et ne pas livrer le projet.
Vous devez rester vigilant afin de ne pas vous retrouver plongé dans d'autres tâches lorsque ces problèmes surviennent. Cela signifie généralement qu'il ne faut pas se consacrer entièrement à l'implémentation (c'est-à-dire déléguer des tâches à d'autres ingénieurs du projet). Idéalement, vous devriez consacrer au moins 20 % de votre temps à la mise en œuvre dans les premières phases du projet, et jusqu'à 90-100 % dans les derniers jours. Ainsi, lorsque des problèmes surviendront, vous pourrez leur accorder toute votre attention.
Pouvons-nous livrer tout de suite ?
Les flags de fonctionnalités sont le meilleur moyen que j'ai vu pour faire cela, mais les environnements de staging fonctionnent également, et ainsi de suite. L'essentiel est de présenter ce que vous construisez au plus grand nombre d'yeux possible : les vôtres, mais aussi ceux d'autres ingénieurs et, idéalement, ceux de la direction, du produit, de la conception, etc. Cinq minutes de jeu avec la fonctionnalité actuelle, même dans un état très approximatif, feront apparaître des problèmes que personne n'avait anticipés. Le fait d'être en mesure de voir directement le résultat est également très utile pour rassurer la direction sur le fait que vous maîtrisez la situation.
Le meilleur moyen d'anticiper les problèmes est de procéder à un déploiement précoce. En général, il est utile de se poser la question suivante : « Puis-je livrer ce produit tout de suite ? Pas cette semaine, pas aujourd'hui : tout de suite. Si ce n'est pas le cas, que faudrait-il changer pour que je puisse livrer quelque chose ? Si la livraison a besoin d'un déploiement, cela peut-il se faire maintenant derrière un flag de fonctionnalité ? Si nous attendons qu'une autre équipe fasse un changement de son côté, puis-je faire en sorte que le système n'ait pas strictement besoin de ce changement après tout ? Par exemple, si l'équipe de la plateforme met en place une couche de cache, je pourrais faire en sorte que ma fonctionnalité continue de fonctionner (bien qu'un peu plus lentement) si elle ne trouve pas le cache.
N'oubliez pas que votre principale priorité est de maintenir la confiance avec votre équipe de direction. Rien ne renforce la confiance comme le fait d'avoir des plans de repli, car en cas d'urgence, les plans de repli indiquent que l'on maîtrise la situation. Si le pire se produit et que vous ne pouvez pas livrer le produit le jour même, votre responsable sera beaucoup plus heureux d'en parler à son supérieur s'il peut lui dire quelque chose comme « nos options sont de retarder de quatre jours ou de livrer le produit demain en sacrifiant X » - même si sacrifier X n'est pas envisageable. Cela signifie qu'ils seront plus enclins à interpréter le retard comme un problème inévitable que vous avez géré efficacement, plutôt que comme une erreur que vous avez commise et qui signifie qu'ils ne peuvent pas compter sur vous.
Je pense que beaucoup d'ingénieurs s'abstiennent de faire des déploiements essentiellement par peur. Si vous voulez livrer, vous devez faire exactement le contraire : vous devez déployer autant que possible le plus tôt possible, et vous devez faire les changements les plus effrayants le plus tôt possible. N'oubliez pas que c'est vous qui avez le plus de recul sur le projet, ce qui signifie que c'est vous qui devez avoir le moins peur des changements effrayants. Tous les autres sont confrontés à davantage d'inconnues et seront encore moins enclins à actionner le grand levier. (S'il y a un autre ingénieur qui est à travers tout cela et que vous attendez, mauvaise nouvelle : c'est probablement lui qui livrera votre projet).
En résumé
- La livraison est vraiment difficile et vous devez en faire votre principale priorité
- Livrer ne signifie pas déployer du code, mais rendre votre équipe dirigeante heureuse.
- Vous avez besoin que votre équipe dirigeante vous fasse confiance pour livrer.
- La majeure partie du travail technique essentiel consiste à anticiper les problèmes et à créer des plans de secours.
- Réduisez votre travail d'implémentation à mesure que vous approchez du lancement afin d'être libre de vous attaquer aux problèmes de dernière minute.
- Vous devez constamment vous demander : « Puis-je livrer à l'instant même ? ».
- Ayez du courage !
Source : "How I ship projects at big tech companies" (par Sean Goedecke)
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi :
Répondre avec citation
Partager