Comment puis-je, chef d'équipe, évaluer des projets

Les timlids apprécient souvent les projets, et tout le monde ne le fait pas bien. Ici, beaucoup dépend de la personnalité du chef d'équipe lui-même, ainsi que de sa compréhension de l'équipe. Il existe de nombreuses techniques pour évaluer des projets de la méthode «par analogie» à PERT. Mais aujourd'hui, je vais parler de la façon dont j'utilise la planification du poker et d'autres techniques pour évaluer plus précisément et avec plus d'avantages.




Avant de parler d'approches spécifiques, il convient de s'attarder sur les principales difficultés du processus.

Il y a toujours deux côtés à une évaluation: une équipe et un client. Étant entre eux, le chef d'équipe ou le manager est obligé de rechercher un équilibre d'intérêts opposés. Il est impossible de surestimer le devis, car le client refusera de payer plus. La sous-estimation n'en vaut pas la peine. Dans ce cas, vous devrez perturber le rythme de l'équipe, risquant une fatigue excessive, l'épuisement professionnel et le fait que le code entre en production sans contrôle.

La profondeur de l'étude de la tâche d'évaluation est une question philosophique. Les tâches peuvent être discutées pendant longtemps, puis l'évaluation de l'ensemble du sprint sera retardée. Mais si vous ne plongez pas dans l'essence, vous pouvez manquer quelque chose d'important qui affecte le délai.

Les développeurs faibles et forts agissent différemment. Si un développeur fort apprécie la tâche, le faible ne respectera pas ses délais. Inversement, les forts rendront la tâche beaucoup plus rapide que les faibles appréciés. Compte tenu de la différence de vitesse de travail, différentes erreurs «sociales» sont possibles dans l'évaluation, par exemple, lorsqu'un développeur faible «jettera un coup d'œil» à quel moment un développeur fort évalue une tâche et fixe les mêmes délais afin de ne pas expliquer pourquoi son «estimation» est plus longue: « Il a appelé la semaine, ne puis-je pas dire qu'il en faudra trois? Je dirai au moins un an et demi ... ".

Le soi-disant poker de planification aide à contourner ce problème, lorsque toute l'équipe participe à l'évaluation, ne sachant pas qui sera la tâche, et l'évaluant à l'aveuglette, ne voyant pas ce que ses collègues proposent.


Auteur: Hkniberg de Wikipédia en anglais - Déplacé de en.wikipedia vers Wikimedia Commons., Domaine public Tout le monde scanne une

tâche dans sa tête. Si les termes énoncés par les membres de l'équipe sont très différents, la discussion commence. À ces moments, il s'avère généralement que l'équipe n'a pas remarqué de fonctionnalité à implémenter dans le cadre de la tâche. Après cela, tout le monde votera à nouveau. Et puis il n'y a eu aucune affirmation selon laquelle quelqu'un avait estimé quelque chose de mal - tout le monde a participé. Même s'il y a une erreur, personne ne perdra son temps à rechercher les coupables, il y aura une conversation plus constructive sur les nouveaux facteurs qui sont apparus et qui ont changé l'alignement (et comment les prendre en compte à l'avenir - en travaillant sur les erreurs, j'en ai écrit à ce sujet dans un article précédent dans paragraphe 5 ).

Une évaluation plus précise du projet permet de poser des questions supplémentaires au client. Mais ici, vous pouvez facilement aller trop loin. Certains développeurs ne sont pas invités à faire une évaluation précisément parce qu'ils bombardent le client d'un grand nombre de lettres de clarification. Du point de vue des relations clients, le nombre de questions supplémentaires est le mieux minimisé, ce qui augmente l'incertitude de la tâche.

Quelques conseils pour éviter les erreurs

Pour minimiser l'erreur dans l'évaluation, je respecte quelques règles simples.

J'initie un appel d'introduction avec le client avant de lire les TdR. Lors de cet appel, je vous demande de parler du problème à vol d'oiseau: qui sera l'utilisateur final, comment ils appliqueront le résultat, quels appareils seront impliqués (avec de telles autorisations), à quoi ressemble le backend s'il existe déjà, etc. Après cela, vous pouvez commencer à lire les savoirs traditionnels.

En lisant les TdR, je fais une liste de questions pour le client. En étudiant la tâche, dans votre tête, vous devriez essayer de «coder» l'ensemble du projet - imaginez à quoi il ressemblera. La liste des questions doit être telle qu'après avoir reçu les réponses, il est possible de former une évaluation fiable.
L'idée principale ici est que les questions ne doivent pas être posées progressivement, mais à la fois. Et souvent, il vaut mieux faire appel à une liste de questions préparée afin de ne pas étirer la correspondance. Pourtant, le texte véhicule beaucoup moins d'informations. Lors de l'appel, vous pouvez fouiller l'écran si cela clarifie en quelque sorte la situation.

Si téléphoner est impossible pour une raison quelconque, je recherche un document Google, où j'ajouterai ces questions, et le client y répondra le moment venu. C'est un moyen plus efficace de communiquer sur une tâche qu'un chat ou un courrier personnel. Ce document peut ensuite être envoyé aux développeurs qui participeront au projet - ils n'auront plus à poser les mêmes questions.

Soit dit en passant, il est souhaitable que la personne responsable du projet réponde aux questions du côté du client, et non l'ancien secrétaire du directeur, qui joue simplement le rôle d'un téléphone endommagé. Cela réduira le risque que les paramètres du projet changent directement pendant l'exploitation.

Si possible, j'amène des développeurs sur le terrain.Comprendre comment le produit sera utilisé dans la réalité aide à marquer le «et» et à améliorer le score. Par exemple, un logiciel pour les caisses enregistreuses est en cours de développement. Et vos développeurs sont assis devant l'ordinateur depuis 15 ans et n'ont pas vu la caisse dans leurs yeux. Vous les apportez aux utilisateurs finaux, demandez à faire un achat non pas quelque part, mais spécifiquement dans ce magasin. Et ils voient que tante Masha est assise là, qui appuie simultanément sur deux boutons avec ses doigts et ne peut pas distinguer les lettres dans les lunettes sur le moniteur. En conséquence, de nombreuses questions sur le projet disparaissent d'elles-mêmes - la police s'agrandit, une confirmation des opérations est ajoutée. C'est difficile d'imaginer de telles choses dans ma tête. Et le sentiment de réalité reçu d'une visite personnelle alimentera le développeur pour une autre année.
Malheureusement, une telle immersion n'est pas possible dans tous les projets.

Je n'évalue pas la tâche si la condition est «et» / «ou». Par exemple, s'il est proposé de «faire l'autorisation et l'enregistrement». Il n'y a aucun problème à diviser ce point en deux tâches et à évaluer chacune d'elles individuellement. Une telle évaluation sera plus précise, car vous ne mélangerez pas des entités similaires, mais toujours différentes. Plus la décomposition est bonne, plus le résultat est précis.

“Ou” est encore pire, il est toujours identique au savoir traditionnel flou, à partir duquel il est impossible de construire des estimations précises. Est-il nécessaire ou non de faire une autorisation via les réseaux sociaux? Et s'il y a une API spécifique pour le backend? Si vous ne connaissez pas les détails, vous ne pouvez tout simplement pas donner une évaluation précise.


Photo: Michael Dubakov @ Medium

Il ne peut pas y avoir d'évaluation de 40 heures pour la tâche.Il s'agit d'une autre variante de la règle précédente. Agile recommande de décomposer un projet en tâches ne dépassant pas 20 heures. Il ne devrait pas y avoir de tâches indivisibles pour une semaine de travail. En petites portions, l'estimation est beaucoup plus précise.

Lors de la décomposition d'une tâche, j'essaie de l'enregistrer. Il est utile en même temps sous deux angles.

Premièrement, cela simplifie le processus. Dès que vous commencez à écrire des pensées sur un sujet donné, le cerveau les développe avec plaisir. Soit dit en passant, c'est pourquoi je ne recommande pas de mélanger la décomposition avec l'estimation, c'est-à-dire sélectionnez une tâche et évaluez-la immédiatement. Il est préférable de diviser l'ensemble du projet en composants, de le réparer, puis de les évaluer à la fois, afin de ne pas faire fonctionner votre tête dans deux modes à la fois.

Deuxièmement, le «log» de la décomposition aide à expliquer la possible divergence entre les estimations et la réalité à l'avenir. En fait, vous avez une description complète de la tâche en cours de formation - quelles options avez-vous envisagées. Par exemple, vous avez pris en compte l'autorisation par identifiant et mot de passe avec un jeton, le renouvellement de jeton, etc., et le client, il s'avère, voulait toujours une autorisation via les réseaux sociaux, n'a tout simplement pas écrit à ce sujet. La décomposition de votre «journal» aidera à protéger l'équipe contre les affirmations selon lesquelles vous avez apprécié quelque chose, mais n'avez pas respecté les délais.

J'enseigne à l'équipe à ne pas saisir les tâches connexes avant qu'elles ne soient terminées.Les développeurs passent beaucoup de temps sur des fonctionnalités supplémentaires. Ils font une autorisation, tout au long du processus, ils voient que quelque chose doit être réparé quelque part, et se plongent dans ce processus secondaire. J'essaie d'évoquer un réflexe: j'ai vu une tâche d'accompagnement - former un ticket séparé. Vous n'avez même pas à exécuter la tâche via le chef d'équipe ou le responsable. Lorsque le chef d'équipe analyse les tâches, il le verra lui-même et l'enverra pour travailler, si nécessaire. Vous n'avez donc pas besoin de retirer du travail à quelqu'un (vous avez créé une tâche et vous l'avez oublié) et l'exactitude de l'évaluation sera préservée.

Je mets du temps pour les tests.Lors de l'évaluation, beaucoup oublient les testeurs. Mais en fait, toute tâche, en particulier une tâche difficile, doit passer par des tests par des personnes vivantes - ils doivent y penser, rechercher des bogues. S'ils trouvent quelque chose, les bugs iront aux développeurs qui ont déjà réussi à passer à un autre contexte. Ils devront replonger dans le sujet. Et ce cycle peut être répété plus d'une fois.
Il faut prévoir du temps pour les tests. En règle générale, cette évaluation est donnée séparément de ce que le développeur a dit.

Je prends en compte le temps de programmation en binôme et les autres fonctionnalités du travail.La programmation en binôme permet d'échanger des expériences et de motiver les développeurs. Ils s'assoient ensemble ou fouillent autour de l'écran, discutent de la tâche et des outils utilisés, et apportent à leur tour quelques changements. Cette approche est payante pour l'équipe, mais du point de vue du client, la tâche n'avance pas deux fois plus vite. Sur les projets où je travaillais, nous ne pratiquions pas constamment la programmation en binôme, mais certaines tâches étaient pratiques pour le faire. Et nous en avons tenu compte au stade de l'évaluation.

De même, vous devez prévoir du temps pour une démonstration au client, un appel téléphonique, une correspondance, etc. Et en général, afin de s'insérer dans l'évaluation, le développeur doit travailler efficacement, et pour cela, il doit dormir suffisamment, se reposer normalement (et non pas toute l'équipe de service le week-end en production) et ne pas conduire le travail plus vite, plus vite. Par conséquent, l'évaluation doit toujours être basée sur des pratiques de travail réelles et non sur des prévisions optimistes selon lesquelles nous allons tous nous asseoir et «faire le plan quinquennal en trois ans».

Je mets du temps pour le calcul du projet. Il existe quatre types de stands: développement, test, pré-production et production. Il est préférable de déployer ces stands au début du projet et de se coucher immédiatement pour cette période. Si cela n'est pas fait, la synchronisation du développement, des tests et du déploiement sera interrompue, ce qui peut se transformer en un véritable gag.

Je ne fais pas d'évaluations d'en haut et d'en bas - j'appelle un terme spécifique. Selon les règles du marketing, lorsqu'un développeur dit «de 4 à 12 heures», il veut dire «faites-le plus vite que 12 heures». Le client entend «4 heures». Si la tâche est terminée en 11, le développeur considérera que tout va bien et le client sera insatisfait. Il arrive que le client soit mécontent, même si la tâche est terminée en 4 heures et 15 minutes. Par conséquent, même si une étiquette est établie au sein de l'équipe (entreprise) avec une durée minimale et maximale, puis que la moyenne est calculée (il y a du sens dans cette approche), seul le résultat final est montré au client.

Je nomme les dates uniquement en heures - pas en jours ou en mois.Beaucoup de gens pensent que si le projet est estimé à 96 heures, il sera achevé en 12 jours pendant 8 heures, à condition qu'une seule personne y travaille. La situation est facilement extrapolable à deux développeurs, nommant une note de 6 jours. Mais ce n'est pas vrai. Il existe de nombreuses tâches qui dépendent les unes des autres. Premièrement, les développeurs ne peuvent pas commencer à travailler jusqu'à ce qu'un modèle de projet ait été créé avec tous les systèmes d'assemblage et supports (et il est créé 2-3 jours en tenant compte des souhaits du client). Deuxièmement, tout s'arrête lorsqu'il y a des appels à la planification. Troisièmement, il existe des bogues de blocage qui vous empêchent de continuer. En d'autres termes, 96 heures sur le lieu de travail ne signifient pas du tout que 100% du temps (8 heures par jour) sera consacré spécifiquement à ces tâches. Pour une évaluation en jours, nous pouvons supposer que le développeur n'en a pas 8, mais, disons,6 heures de travail par jour (le chiffre exact doit être déterminé à partir de la pratique).

Je demande toujours aux développeurs combien d'heures une tâche prendra sur un ordinateur (et non «après combien de temps elle sera prête»). C'est une conséquence du paragraphe précédent. Interagissant avec l'équipe dans le cadre de l'évaluation, il est important de formuler correctement la question.

Je prends en compte le "coefficient d'équipe".Habituellement, les aînés d'hier vont aux timlids. Ils évaluent les tâches en fonction de leur expérience, même s'ils ont des intermédiaires dans leur équipe. Peut-être que l'aîné ne travaille pas beaucoup plus vite, mais après lui, il n'y a presque plus de bugs. Le milieu n'est pas d'une telle qualité. Par conséquent, dans Agile, il y a ce qu'on appelle le «coefficient d'équipe», qui montre la différence entre l'optimisme de l'évaluateur et la vie réelle d'une équipe particulière. Elle n'est calculée qu'en pratique: une estimation théorique est comparée à une estimation réelle pour les derniers sprints. Mieux le chef d'équipe connaît son équipe (et mieux il a mis la main sur l'évaluation), plus ce coefficient est proche de 1.

Entre autres, le «coefficient d'équipe» prend également en compte le soi-disant «optimisme des développeurs» lors de l'évaluation. Les tâches sont toujours évaluées en fonction de l'absence d'erreurs, de la satiété et de la bonne humeur des interprètes, de l'absence de problèmes dans l'environnement. Mais la réalité est remplie de contingences et il n'y a aucun moyen de s'en protéger. Le «ratio d'équipe», calculé sur une durée raisonnable, permet d'en tenir compte.

En essayant de donner l'influence de l'équipe, parfois dans l'évaluation interne, ils passent des heures aux histoires. Sachant que la tâche prendra 8 points d'histoire, ils se rappellent que la semaine dernière, 1 point d'histoire a coûté 8 heures. De cela, prédire les coûts de main-d'œuvre. Mais il m'est plus facile de penser en quelques heures.

Je n'introduis pas de facteurs supplémentaires afin de ne pas confondre les autres participants au processus.Je vois souvent des gens, effectuant une évaluation au niveau de l'équipe, y consacrant du temps pour négocier. Mais l'unité d'évaluation ne doit pas constituer ce stock ni prendre en compte d'autres éléments étrangers. Et il s'avère que le développeur a évalué la tâche à 8 heures, mais multipliée par 2 pour la fidélité. Timlid a de nouveau doublé sa note, s'adaptant à l'équipe. Et le manager de 32 heures en a fait 40 pour le client (pour un compte pair ou tout simplement dans le but de négocier ensuite pendant 30 heures). Cela ressemble plus à la bonne aventure sur le marc de café. Oui, et le client, voyant une estimation de 40 heures pour une tâche de 8 heures, décidera que l'équipe ne sait pas comment.

Comme je l'ai noté ci-dessus, au niveau de l'équipe, il suffit de prendre en compte les caractéristiques de l'équipe elle-même, en convenant de qui met la force majeure dans l'évaluation (et cela devrait être pris en compte là-bas, car nous évaluons toujours les tâches, en supposant que l'éditeur de code ne demande pas de licence, les développeurs ne pas être en arrêt maladie, etc.).

Résiste fermement à ma défense de l'évaluation. Le corollaire du paragraphe précédent - Je suis toujours fermement sur mon évaluation. Si je sais que le projet sera réalisé pendant 6 mois, et qu'ils attendent une évaluation de 3 de ma part, je ne nommerai jamais 4 mois pour «faire plaisir» au client ou au manager.
Il convient de noter qu'il y a parfois des négociations internes. Lorsque vous savez que le projet doit être prêt pour la nouvelle année, vous commencez inconsciemment à truquer les résultats de l'évaluation afin de respecter le temps restant. Le cerveau lance parfaitement ces choses. Même si vous avez une liste de 200 sous-tâches, elles convergeront alors de manière à rencontrer le Nouvel An.

Malgré tout cela, je suis prêt à changer l'évaluation. C'est normal - les projets vivent, se développent. Formant toute évaluation, je comprends que c'est une caractéristique du projet en ce moment particulier.

Et le dernier mot d'adieu: n'obligez pas les développeurs qui ne respectent pas les délais à écrire de longues lettres aux gestionnaires sur ce sujet. Premièrement, ils sont susceptibles d'être timides. Deuxièmement, le manager va probablement demander quelque chose et encore une fois distraire. Troisièmement, sa lettre d'explication sera simplement perdue dans la correspondance. Je vous demande généralement d'écrire un commentaire sur une tâche dans Jira. Sans la participation d'une personne vivante (gestionnaire), c'est généralement plus simple et plus rapide. Et pendant le débriefing, ce sera facile à trouver. Et timlidu plus - toutes les tâches qui sont hors de propos seront commentées. Encore une fois, travaillez sur les bugs pour améliorer la qualité de l'évaluation à l'avenir.

L'auteur de l'article: Eugene Wetzel ( @imater )

PS Nous publions nos articles sur plusieurs sites du Runet. Abonnez-vous à nos pages enChaîne VK , FB , Instagram ou Telegram pour en savoir plus sur toutes nos publications et autres actualités Maxilect.