Gestion de projet, catégorie 30+

Arrêtez, arrêtez, nettoyez-le immédiatement! Pour fermer un projet ayant échoué, vous avez besoin de deux choses: vous devez comprendre que le projet a échoué et vous devez le fermer. Mais pas si simple.



Cet article est basé sur un rapport de Maria Belkina de SEMrush, de l' OKR-mitap à Saint-Pétersbourg : «L'expérience du passage d'OKR à Spotify Rhythm». Bien que le titre du rapport implique une démonstration des lacunes de OKR, des avantages de Rhythm et de la manière de remplacer l'un par l'autre, son sujet principal était la question: «Que faire des projets qui ont échoué?». Il s'agit d'un sujet aigu et douloureux qui est intéressant à comprendre.

La culture de démarrage est déterminée à réussir. Si vous pouvez atteindre l'objectif, vous devez continuer dans le même esprit. Mais tous les projets ne réussissent pas, dans la plupart des cas, seuls des résultats médiocres peuvent être atteints, ou pire. Qu'advient-il de ces projets? - Ils continuent. Pour tout le monde: tant pour la direction que pour les artistes interprètes ou exécutants, il est beaucoup plus facile de continuer à investir dans un projet infructueux que d'en reconnaître l'échec. L'escalade du problème peut entraîner des conflits dans l'équipe, ce qui peut ruiner les relations avec les collègues. Personne n'en a besoin. Mais si vous ne faites rien, le développement s'enlisera dans des projets futiles et le produit se transformera en un méli-mélo de fonctions inutiles non pris en charge. Ce n'est pas bon non plus.

L'argent est toujours important, mais les gens sont une ressource de développement clé. Pour un mois de travail, un groupe d'une centaine de personnes brûlera une somme égale, quel que soit le résultat. Bien sûr, organiser le meilleur résultat est l'essentiel dans la gestion du développement. Mais lorsqu'une nouvelle idée apparaît, «c'est ce que nous devons faire!», Il s'avère souvent qu'il n'y a personne pour y faire face. Tous les développeurs sont occupés par les tâches en cours, et ce n'est pas le plus important, mais vous ne pouvez pas les laisser. C'est typique d'un produit mature.

Plus le produit logiciel est ancien, plus la proportion de ressources dépensées pour son support est importante et plus le nouveau développement est lent. Même si les fonctionnalités sont utilisées par deux cents utilisateurs sur cent mille, le bogue devra encore être corrigé. L'introduction de nouvelles technologies nécessitera la correction de tout le code, que la méthode soit appelée toutes les millisecondes ou une fois par mois. Un projet commencé est préférable de terminer que de laisser inachevé. Toute modification globale nécessitera des tests complets, etc. Tout cela donne un peu à réfléchir et vous fait réfléchir de manière critique sur les perspectives.

Tous les projets ne réussiront pas, c'est la réalité. Vous pouvez vivre avec cela, mais à un moment donné, la direction devrait comprendre que vous ne pouvez pas simplement continuer à disperser des jouets sur le sol. Périodiquement, ils doivent être récupérés dans la boîte, sinon il y aura un gâchis. Oui, le rangement est ennuyeux. Oui, cela prend du temps. Oui, quelqu'un peut être contrarié que son jouet préféré ait été remis dans la boîte. Mais nous sommes adultes.

Que signifie fermer un projet qui a échoué? Il ne s'agit pas seulement d'annuler à perte dix années-homme de travail. Toutes les fonctionnalités développées doivent également être supprimées du produit, ce qui représente un travail supplémentaire et des coûts supplémentaires. Il y aura également des utilisateurs mécontents qui, pour une raison quelconque, ont aimé la fonctionnalité du projet. N'oubliez pas les occasions manquées. Il semble que le temps et les efforts consacrés à la clôture du projet puissent être utilisés avec plus d'avantages. Fermez le projet - cher. Pour franchir une telle étape, vous avez besoin de la volonté, de la détermination et de la compréhension que la santé à long terme des produits est plus importante que les économies tactiques. Mais même s'il y a une volonté de mettre en place de telles mesures drastiques, le déclencheur est toujours nécessaire, un moyen est nécessaire pour comprendre que le projet a échoué.

Critère d'échec du projet. En règle générale, il est habituel de définir un critère de réussite. Il semblerait que si des critères de réussite étaient définis et que le projet ne les atteignait pas, il échouait. Absolument pas. Entre le succès et l'échec se trouve une grande zone grise. N'atteignant pas les valeurs des indicateurs qui déterminent le succès, il y a toujours le sentiment que "nous n'en avons pas assez fait", "juste un peu plus et ensuite tout ira bien". C'est peut-être le cas. Mais évaluer le projet selon des critères de réussite ne pose que la question «continuer ou pas?», Et une telle question n'implique pas la réponse «fermer et détruire!».

Le critère d'échec du projet est la limite inférieure des indicateurs, en dessous de laquelle le projet doit être détruit. Comme un navire qui a un trou sous la ligne de flottaison, il devrait descendre. Avec toute la fierté, la grandeur et le professionnalisme possibles.

Tout comme le succès ne doit pas conduire à l'envie, l'échec ne doit pas inciter à la haine dans une équipe. À long terme, tout cela est une routine du processus de travail. Pour que l'échec du projet ne conduise pas à des conflits, les critères d'échec doivent être déterminés et convenus à l'avance, ainsi que les critères de réussite. De plus, un plan de fin de projet doit être préparé à l'avance, même avant le plan de projet lui-même. Ensuite, après avoir déterminé que le projet a échoué, il n'y aura aucun doute que faire dans cette situation. Vous pouvez immédiatement procéder à une action décisive. Le tout de façon adulte.

Il est raisonnable de soutenir que notre cerveau est agencé de telle sorte que, en pensant à l'échec à l'avance, nous nous préparons à l'échec. Peut être. Mais la capacité de penser aux conséquences est un signe de pensée mûre. Et les difficultés associées à cela, semble-t-il, peuvent être surmontées.

---

Dmitry Mamonov,
Wrike

PS Dans la suite du sujet sur comment, pourquoi et quand supprimer des fonctionnalités du produit, je peux recommander un rapport de mon collègue, Yuri Andreikovich.