Rencontre post-projet une perte de temps?

À mon lieu de travail, nous avons eu de sérieuses douleurs de croissance. Nous sommes passés d'une équipe de développement de 3 à 10 personnes, et l'entreprise elle-même a augmenté de 30% au cours de la dernière année. D'après la plupart des mesures, nous nous en sortons bien. Malheureusement, la qualité de notre logiciel a souffert.

Lors d'une réunion aujourd'hui avec le responsable de ma division, j'ai proposé une réunion de l'équipe projet un jour ou deux après le lancement du produit. Nous pourrions discuter des préoccupations budgétaires, de la portée, de ce qui a mal tourné et de ce qui s'est bien passé. Idéalement, apprendre de nos erreurs. Nous créons des sites / applications pour d'autres personnes, notre temps est donc facturable sur non facturable. Une telle réunion relèverait de ce dernier.

Mon manager l'a abattu presque immédiatement: "Ce temps n'est pas facturable. Cela nous fera prendre du retard sur un autre projet parce que nous perdons du temps à la fin de celui-là à en parler." J'étais tellement pris au dépourvu par cette logique que je n'ai même pas pris la peine de le combattre.

Donc, ma question: je vois que la valeur est des réunions post-projet, mais il ne le fait pas. Existe-t-il des preuves documentées de réunions post-projet permettant d'économiser temps et argent à long (ou court terme)? Intuitivement, je pense que ce sera / serait, mais il est clairement plus préoccupé par une petite quantité de temps non facturable des 5 personnes qui devraient être là.

Rétrospectivement, Regarder vers l'avenir serait proche d'une preuve documentée de l'idée. Le projet post-mortem: un outil précieux pour l'amélioration continue serait un article de blog à ce sujet.

L'art du post-mortem a ce point sur l'idée:

Les origines de l'autopsie remontent aux militaires, qui utilisent régulièrement ce type de processus pour faire le point avec les gens sur les lignes de front. Mais son application de gestion est essentielle à toute organisation d'apprentissage performante.

Votre gestionnaire ne comprend pas le concept de dette technique .

Les réunions post-projet sont un investissement et non un coût. Voilà comment vous devez les vendre. Le but de toute réunion est d'échanger des idées sur la façon d'économiser de l'argent et d'atteindre les objectifs de l'entreprise à long terme.

Votre manager est un manager car il s'occupe de ces objectifs à long terme. Donc, à mon avis, il y a deux vérités possibles: votre manager veut tout le contrôle pour lui-même, ou votre manager ne fait pas son travail. Si l'entreprise a une histoire et une philosophie de faire les choses «de la bonne façon» et d'investir dans son propre succès, envisagez de prendre la question au-dessus de votre manager.

Il s'agit essentiellement d'un examen après action , qui est particulièrement utile dans de nombreux contextes différents, pas seulement dans l'armée.

Mon propre cycle de développement consiste à analyser à la fois ce qui devrait être fait dans la prochaine itération ou projet et ce qui pourrait être mieux fait dans le projet précédent. Même si un projet est suspendu pendant un certain temps, avoir une liste de choses à travailler aide quand il sort de l'étagère (ou backburner ...) et est à nouveau un projet actif. La prochaine fois que je le toucherai, je n'aurai pas à passer autant de temps à revoir ce que je dois faire.

De plus, en examinant un projet et en trouvant les astuces que moi ou d'autres avons mises en œuvre, celles-ci sont diffusées et le prochain projet ou la prochaine itération est d'autant mieux. (Il n'est pas surprenant que je pense souvent en termes d'itérations.)

La valeur de ceci est une logique simple et intrinsèquement évidente. Comment pouvez-vous améliorer vos projets futurs si vous ne tirez jamais les leçons de vos erreurs sur vos projets précédents?

Bien qu'il ne s'agisse pas spécifiquement de documentation, l'examen du processus (pendant ou après l'achèvement) est un élément majeur de presque tous les systèmes de contrôle de la qualité basés sur des normes que je connais, CMMI et Lean 6 Sigma en particulier.

Peut-être pourriez-vous le proposer comme une obligation, quelque chose qui se fait volontairement lors d'un déjeuner ou quelque chose? Il y a de bonnes chances que plusieurs membres de votre équipe de développement soient impatients de venir essayer de nouvelles choses ... donc si vous pouvez balancer au moins la première, les résultats parleront d'eux-mêmes.

Il se peut que votre manager subisse des pressions budgétaires. Cela doit être une grande préoccupation lors de l'extension de 3 à 10 développeurs en peu de temps. Si tel est le cas, alors c'est probablement une bonne idée de simplement sauter les réunions post-mortem pour l'instant et de les suggérer à nouveau dans quelques mois, alors que, espérons-le, les problèmes budgétaires immédiats ne seront pas si pressants.

L'une des raisons pour lesquelles la qualité peut souffrir est que la communication entre 10 personnes est un problème beaucoup plus important que la communication entre 3 personnes: 3! << 10 !. Bien que vous puissiez probablement vous embrouiller pendant un petit moment, vous devrez éventuellement apporter des modifications pour favoriser une meilleure communication entre les développeurs et vous assurer que les principes établis par les 3 développeurs originaux soient diffusés au les gens plus récents et mis à jour pour bien fonctionner dans votre nouveau groupe plus important. Les réunions post mortem du projet sont une façon de le faire; les révisions périodiques de code en sont une autre. Il ne ferait pas de mal de souligner que les réunions post-mortem sont un élément essentiel de l'amélioration de la qualité dans les industries de la médecine à la fabrication.

Il est difficile d'imaginer que votre manager pense qu'il peut étendre son équipe de développement simplement en embauchant des personnes supplémentaires. Il faut absolument investir dans la formation et la constitution d’équipes; sans cela, votre organisation s'effondrera sous son propre poids. Si vous attendez un peu, votre organisation peut commencer à rencontrer des problèmes concrets directement attribuables à une mauvaise communication. À ce stade, votre manager dira probablement: "Nous devons mettre tout le monde sur la même page! Planifiez une réunion avec tous les développeurs!" Et si cela semble aider, il dira probablement: "Nous devrions le faire après chaque projet!" ;-)

Soyez donc patient, mais persévérez.

Je vais inverser la tendance: je suis d'accord avec le manager.

J'ai trouvé des revues post-projet largement inutiles car il est trop tard pour faire grand chose pour corriger les problèmes révélés.

Ce que je recommanderais le plus, ce sont des rétrospectives périodiques effectuées pendant le projet. Une ou deux fois par mois, demandez à l'équipe de parler de ce qui s'est bien passé ou non; quoi faire de plus, quoi de moins. Faites-le pendant le projet afin de pouvoir appliquer immédiatement les suggestions et voir à quel point elles fonctionnent.

Regardez la fomalisation de la réunion. De nombreuses réunions post-projet sont des talk-fiests et votre manager a absolument raison de ne pas les soutenir.

Invitez-vous à gérer la réunion (demandez-lui de présider / modérer), de faire circuler un ordre du jour et d'obtenir des résultats spécifiques. En tant que manager, il peut alors voir la valeur de la réunion.

Nous utilisons, et je recommande le processus de révision "6 Thinking Hats" de De Bono ( voir Wikipidia ). Le résultat est quelques (2 ou 3) points d'action que la réunion identifie comme étant la raison la plus importante apprise. Les premières fois, nous avons du mal à sortir des blocs de départ, mais une fois que nous nous y sommes habitués, je n'y retournerai pas.

Ne pas effectuer un examen post-projet vous condamne à faire les mêmes erreurs que vous avez faites dans le projet précédent.