Comment les grandes entreprises technologiques mènent-elles leurs projets ?

• Résultat d’une enquête menée auprès de plus de 100 entreprises de la big tech
• Si l’on résume la manière dont la big tech gère les projets ⇨ « Cela dépend du contexte » (It Depends)
  • La plupart n’ont pas de méthodologie ni de mode de travail imposés, et chaque équipe choisit ce qui lui convient
  • Les entreprises cotées ou financées se disent moins satisfaites de la présence d’un PM dédié, tandis que les entreprises non financées affichent une satisfaction plus élevée
  • Il existe une forte corrélation entre l’autonomie des équipes et leur satisfaction
  • Dans les équipes en difficulté, le problème ne venait généralement pas de la méthodologie, mais plutôt d’une vision mal communiquée, d’un manque de transparence ou d’outils insuffisants
  • JIRA a suscité majoritairement des réponses négatives
• Méthodes de gestion de projet qui n’ont pas bien fonctionné
  • Les ingénieurs ne participent pas à l’estimation de la durée des projets
  • Les exigences changent malgré la présence d’un PM dédié
  • Les équipes qui n’ont pas l’autonomie nécessaire pour changer une méthode de gestion de projet défaillante affichent un faible niveau de satisfaction
• Comment la big tech mène ses projets
  • Les ingénieurs dirigent la plupart des projets
  • Il n’y a pas de méthodologie imposée, et les équipes sont libres de choisir
  • Pour les projets à l’échelle d’une équipe, il n’y a pas de Project Manager dédié. Pour les grands projets impliquant plusieurs équipes ou l’ensemble de l’entreprise, on met en place un Technical Program Manager. Chez Uber, le ratio est d’environ 1 pour 50
  • Des outils développeur de premier ordre sont fournis, ce qui a un impact majeur sur des cycles d’itération courts

Structures organisationnelles des grandes entreprises technologiques qui influencent les projets

• Environnement de base
  • Les ingénieurs et les équipes disposent d’autonomie
  • Ce ne sont pas des ressources inconscientes (ouvriers d’usine), mais des résolveurs de problèmes curieux
  • Les données, le code et la documentation internes sont exposés de manière transparente
  • Les ingénieurs sont aussi exposés au business et aux métriques business
  • On privilégie une communication d’ingénieur à ingénieur, rapide, plutôt qu’une communication hiérarchique
  • Investissement dans une expérience développeur moins frustrante
  • Des salaires plus élevés, justifiés par un levier plus important
  • Possibilité de recruter de meilleurs talents
• Des équipes autonomes et responsabilisées
• Des équipes avec une propriété clairement définie

Product Manager oui, Project Manager non

• Le rôle du Product Manager est de comprendre « What game we're playing » et « How we're going to play it »
• Dans de nombreux cas, les Product Managers des grandes entreprises technologiques ne font pas de Project Management
  • L’équipe est responsable de l’exécution et, dans la plupart des cas, les responsables techniques (leads d’équipe) sont chargés de la gestion de projet
  • Dans des équipes autonomes et responsabilisées, il est rare que la gestion de projet soit descendante ⇨ tout le monde y participe
• Questions fréquentes lorsqu’il n’y a pas de Project Manager dédié
  • Projets à l’échelle d’une équipe : simplifier le processus et renforcer les relations interpersonnelles
  • Projets complexes : les grandes entreprises technologiques utilisent des Technical Program Managers (TPM)
  • Il existe bien des Program Managers / Project Managers dédiés. En général, ils sont reliés à l’externe, aux clients et à la planification d’exécution à long terme
• Pourquoi, dans un environnement centré produit, on ne fait pas de Scrum
• Le Scrum exécuté par sprint s’adapte mal à un contexte de déploiement rapide
• L’infrastructure et les outils développeur remplacent une grande partie des activités Scrum
  • Les grandes entreprises technologiques ont compris qu’investir dans l’infrastructure et les outils développeur améliore la productivité
• Facebook, Google, Netflix, etc. n’utilisent pas Scrum. Pourquoi ?
  • Les personnes compétentes et autonomes ont moins besoin de ce type de structure
  • Si l’on donne à une équipe compétente la liberté de décider comment opérer, on peut mieux en tirer parti
• Faire évoluer une organisation d’ingénierie va bien au-delà des processus au niveau de l’équipe
• Cela dit, ce serait une erreur que tout le monde abandonne Scrum pour imiter la big tech
  → Il existe des situations où utiliser Scrum est pertinent, et cela peut même apporter une productivité supérieure
  • Équipe « kitchen sink » : lorsqu’une seule équipe doit tout gérer (startup en phase initiale)
  • Au moment de former une nouvelle équipe
  • Lorsque les déploiements ont lieu une fois toutes les quelques semaines
  • Lorsqu’il est obligatoire de fournir un reporting standardisé sur l’avancement des projets

Comment faut-il faire fonctionner une équipe ?

• Les changements itératifs valent toujours mieux qu’un changement « big bang »
• Il est plus difficile d’apprendre à quelqu’un à pêcher que de lui donner du poisson
• Donner des directives, faire du mentorat et faire du coaching ont chacun leur utilité
  • Les directives consistent à n’intervenir en micro-management qu’à titre d’assistance, lorsqu’ils pourraient le faire eux-mêmes mais n’y parviennent pas
• Moins il faut de personnes pour prendre une décision, plus celle-ci peut être prise rapidement
• Optimiser pour le reporting, c’est optimiser pour un environnement de faible confiance
• Les consultants ont tendance à privilégier des résultats faciles à mesurer, car c’est la façon la plus simple de prouver leur valeur
• Apprendre de ses concurrents directs est sous-estimé
• Certains des meilleurs ingénieurs préfèrent partir plutôt que d’être micro-managés

[sixmen]

« La plupart des retours sur JIRA étaient négatifs »

Je pense qu’il est nécessaire de gérer les tickets, quel qu’en soit le format, et moi aussi j’étais plutôt négatif vis-à-vis de JIRA, donc j’ai volontairement essayé d’autres outils (GitHub Issues, Trello, Asana, etc.).
Mais au final, comme on dit, on revient souvent à ses classiques, et je suis finalement revenu à JIRA...

Cela dit, je continue à me demander s’il n’existe pas une meilleure méthode.

[roxie]

En quoi avez-vous pensé que les anciennes méthodes étaient meilleures ?

[ffdd270]

J’aime bien YouTrack. C’est un outil de gestion de projet créé par JetBrains, et il me permet de gérer les projets exactement dans la mesure dont j’ai besoin.

[jeemyeong]

Notre équipe est passée à Linear, et globalement, notre niveau de satisfaction a beaucoup augmenté. Je vous recommande d’y jeter un œil.

[ryuheechul]

On dirait que c’est ce produit, https://linear.app/. Ça a l’air intéressant.

[jeemyeong]

Oui, les points que j’y vois comme avantages sont les suivants :

1. C’est léger et rapide. - vitesse de l’application, raccourcis, profondeur des fonctionnalités
2. Il y a des lignes directrices bien définies.
3. La courbe d’apprentissage est faible. Facile à apprendre même sans être familier avec un issue tracker.
4. L’intégration est suffisamment bien faite.

C’est à peu près ce que j’en pense.

[nicewook]

À quoi servent donc les outils de développement de première classe ?

[xguru]

Je l’ai simplement repris pour préserver le ton du texte original.
À ce stade, on peut considérer que c’est sans doute le meilleur outil de développement qu’une organisation puisse mettre à disposition.