🗞️ ⏫ 👩🏻‍💼 Évaluation. Calculer et rencontrer 📶 💰 👩🏼‍💻

La prévisibilité des délais joue un rôle important dans le développement de projets informatiques. Et en raison de la grande complexité des processus, l'évaluation des tâches est un problème difficile, qui n'a pas d'algorithme explicite ni de plan simple. Ceci est aggravé par le fait que dans le processus de communication sur les évaluations, les affaires, la gestion de projet et le développement peuvent parler différentes langues, ne comprennent pas et ne veulent pas comprendre les problèmes et les valeurs des autres. Le résultat est une "désinscription" sur laquelle des efforts sont déployés, mais ils n'apportent pas l'effet nécessaire.

L'article sera utile aux développeurs qui souhaitent améliorer et rendre le processus d'évaluation plus confortable pour eux-mêmes. Dans ce document, je partagerai l'approche développée, qui nous permet d'accroître la compréhension mutuelle avec d'autres unités, ainsi que de réduire le niveau de nos propres efforts d'évaluation. Nous analyserons pourquoi nous avons besoin d'estimations, comment évaluer les grandes tâches et les sous-tâches décomposées. Et, plus important encore, que faire pour entrer dans ces évaluations.

La version vidéo de la présentation est disponible ici .

Eh bien, maintenant au point.

Pourquoi donner des notes

Dans la vie de chaque développeur, ce moment désagréable vient quand «ils» viennent à nous et demandent: «quand sera-t-il prêt?». "Ils" sont des managers, des produits, des chefs d'équipe, des patrons ... La question est, pourquoi est-ce "eux"? Que vont-ils faire avec ça? Si nous comprenons cela, nous pouvons leur donner exactement ce dont ils ont besoin et gagner du temps. Il existe plusieurs options, et voici les principales.

Le manager doit évaluer l'étendue des travaux (livraison, release, sprint): le calendrier et leur volume total. Dans ce cas, il est important d'entrer dans l'évaluation globale, entrer dans chaque tâche spécifique n'a pas d'importance (quelque part dépensé plus, quelque part moins - généralement convenu). À l'avenir, le travail des autres départements est prévu à ce sujet et les indicateurs que l'entreprise gère en dépendent. Et l'entreprise a besoin de prévisibilité: pour réduire les risques et améliorer la gérabilité.
. , . /. , , (, , ) . : , - . , . .
( ). , . , : , . , /, , ( ), . (, , ), .

Eh bien, pourquoi ces "eux" ont-ils été démantelés. Mais en avons-nous besoin? Imaginez que votre manager soit parti en vacances. Pour toujours. Et donc vous vous asseyez, travaillez tranquillement, un jour, deux, une semaine. Personne n'a besoin de notes, la vie est belle. Allez-vous vous évaluer?

Leur donner ou non est une affaire personnelle, mais voici les arguments pour cela.

L'évaluation montre comment terminer la tâche. Le cerveau humain est une chose coûteuse, et une personne n'aime pas penser - c'est difficile. Par conséquent, le désir naturel de penser le moins possible. Mais comment le faire? Vous pouvez diviser l'activité en une activité plus étroite. Nous partageons la planification et l'exécution: nous pensons d'abord à la méthode (pendant l'évaluation), puis nous passons à l'exécution et pensons à l'exécution (dans le processus).
, «» . , — . , () ( ) , . , - .
— . — . , , . . , . 2 . 2 , - , . . , , — . , , — . ( /), . , , : « , !!». , , . ? . «», , . , , — - .
L'effet psychologique. Si la tâche est complexe, elle change au cours du processus de développement ou nos connaissances à ce sujet changent. Si nous n'avons pas donné une évaluation initiale, la tâche dans le processus était envahie de nouveaux détails, et en conséquence nous n'y sommes pas arrivés - nous ne nous souvenons pas pourquoi. Après plusieurs itérations de ce type, l'effet d'un imposteur frappe à la tête. Et s'ils avaient donné une évaluation initiale, la raison aurait été fixée: ils pensaient que 5 perroquets étaient nécessaires, mais il s'est avéré 10. Pourquoi cela s'est avéré être la deuxième question, ils s'en souviennent bien. Et la raison n’est pas toujours («Les développeurs ne font toujours rien» / «Ces produits ne peuvent pas penser pour rien pour toujours, puis ils apparaissent»).

Nous avons donc décidé: des évaluations sont nécessaires à la fois pour «nous» et «eux». Il est logique de poursuivre la lecture de l'article.

Objectif de l'évaluation

Il est inutile de deviner la durée de la tâche. Vous ne pouvez pas deviner exactement, et si vous le pouvez, vous ne pourrez pas le dire de manière fiable tant que vous ne le ferez pas: alors j'ai deviné ou je ne l'ai pas deviné. Et à ce stade, personne n'est intéressé par l'évaluation.

Ainsi, une évaluation n'est pas une tentative de deviner combien de temps prendra une tâche. L'évaluation est un accord entre le client et l'entrepreneur sur le cadre et (éventuellement) la manière dont la tâche est exécutée .

Habituellement, une entreprise adéquate n'a pas de tâche à écraser dans un délai précis; une entreprise a besoin de prévisibilité et de limitation des risques. Le temps n'est pas caractérisé par la vitesse de travail du programmeur, mais par la quantité de travail qu'il met dans la tâche. Et vous pouvez aussi dire bonjour à un collègue: si je reçois une tâche avec une évaluation inadéquate, c'est une occasion pour moi de penser, nos méthodes sont-elles exactement les mêmes? Peut-être qu'il a vu un moyen plus facile de résoudre? Ou peut-être au contraire, n’avez-vous pas remarqué quelque chose de grand? En tout cas, une raison de vérifier la montre.

Processus d'évaluation

La base du processus d'évaluation est de voir la valeur de la tâche commerciale, ainsi que les principaux risques de la tâche et le volume de la routine. Ensuite, évaluez-les en joignant le cadre: on ne sait pas exactement ce que c'est, mais il est définitivement supérieur à X et inférieur à Y. Et bien sûr, nous l'évaluons avec la précision avec laquelle il est nécessaire (car l'estimation exacte est coûteuse et le cerveau est paresseux).

Composition des tâches:

- ( ). , . smoke-test . , , , « ». , ! — . , : « - , ».
, - , . «» -. , , ( , , , , ), — .
. - , , - . , ( ). : , , , (, . — - . : ( , , : , , , , ), , , , ( ) , , zero-tolerance , , , -, . , (//), (//).
Tout le reste .

La procédure d'évaluation de l'épopée

Le schéma est né du fait que n'importe quelle tâche peut être effectuée en tout temps . La déclaration est exagérée, bien sûr, mais dans son ensemble reflète l'essence. Par exemple, un client vient me voir et me dit: «Je veux Facebook. Quand sera-t-il prêt? " Le temps minimum pour résoudre un tel problème que j'ai réussi à trouver est de 15 minutes. Je vais sur facebook, fais une capture d'écran, compose une page avec une image de capture d'écran, la mets sur mon serveur. Satisfait aux conditions du problème. Vous pouvez même améliorer la mise en œuvre: ne prenez pas de photo, mais faites un iframe avec facebook (bien que, comme je m'y attendais, facebook s'est déjà occupé de cela) Étant donné que l'évaluation du temps détermine la façon de terminer la tâche, vous pouvez réduire le temps pour terminer n'importe quelle tâche de 2 à 3 fois (il arrive que par 5 fois). Il est amusant que cette loi empirique se révèle constamment vérifiée dans la pratique.

Nous décomposons la tâche en sous-tâches. Il s'avère quelque chose comme cette image (nous l'appelons «l'arbre de Noël»): évaluer horizontalement les tâches dans le temps, verticalement - la priorité.
Nous trions les sous-tâches par priorité (première valeur métier + «charge», puis risqué, puis le reste par ordre d'importance).
Si l'estimation doit être réduite, nous réduisons le problème par le bas. Pourquoi pouvons-nous réduire: certains des risques ont fonctionné et le gonflement ou la valeur commerciale s'est avéré ne pas être tout à fait ce qu'ils étaient censés être - ce sont des choses importantes, et sans eux, la tâche ne peut pas être transmise. Il est nécessaire de le réparer. Ensuite, nous pourrons entrer dans l'évaluation en effectuant les principales parties de la tâche (selon l'échec, une partie plus ou moins grande de la tâche sera effectuée).

Processus d'évaluation des tâches

Ok, l'épopée était décomposée. Et comment évaluer la taille d'une tâche spécifique?

Si nous avons déjà fait exactement cette tâche . Nous avons des statistiques quelque part, combien de temps a été consacré à une tâche similaire. Si nous ne l'avons pas fait, mais un collègue, alors nous pouvons prendre son résultat et le multiplier par le coefficient de différence entre lui et maintenant (niveau développeur, connaissance du système, connaissance des risques). Nous montons dans les statistiques, multiplions - nous obtenons.
. , . , 60%. , 60% , . , — , 1.5-2 .
. R&D. — , . — . (1, 2, 4 ), — . , , . , R&D, 1-2 , R&D . — R&D. - — , , . — N — - ( ). , — , . , , — .

, ( ) , , . , , .
Planning poker. , . : -, , , , -, , ,
(/ ), . . , . , , 70% .
PERT. , (-) 5 . .
min real max
<> 2 8 20 9

— , , — , ( ), — , , ( ).
:

	min	real	max
<>	2	8	20	9

Si je comprends bien, les coefficients 4 et 6 sont tirés de l'hypothèse selon laquelle, dans le cas général, la probabilité de risque est distribuée normalement et les queues (min / max) sont également probables.

Le processus d'obtention des notes

Donner une évaluation est la moitié de la bataille. La chose la plus précieuse est d'entrer dans cette évaluation. Et le processus de réalisation d'une tâche est un processus actif, de la participation dont le résultat final dépend plus que d'une estimation réussie au tout début. Et adhérez à un look similaire dans des domaines complètement différents. J'ai vu beaucoup de cas où, après avoir fait une évaluation, le développeur prend une position passive "bien, où aller maintenant - quoi qu'il arrive", plie les jambes et suit le courant. Et il est maintenant temps d'agir.

Techniques utiles sur le hit:

6. : . — , - , . /, . ( «» - ). , , - . — . . ? N.
«».
, (- + ) — , . 30%.
.
, ( ) . ( ) — , . — , . — , . .
( ). . , , , . , , . « » — 20-30%, 50. . ( ) , , , .

Et pour commencer, il y a l'effet de la réduction des délais associés aux évaluations des tâches. Il est décrit plus en détail, par exemple ici , et je ne le répéterai donc pas. Telle qu'appliquée aux évaluations, elle a pour conséquence qu'il est nécessaire d'évaluer les tâches et de surveiller le hit, s'il est important pour nous de terminer d'ici un certain temps. Même si la tâche est petite et qu'il y a beaucoup de temps avant sa livraison (comme avec le développeur mentionné précédemment, débordé de travail, qui n'a pas aimé donner de notes). Et si nous ne représentons pas exactement ce qu'est le stock (et nous sommes guidés par le fait qu'il est grand et que «l'État ne deviendra pas pauvre»), nous obtenons un excès incontrôlé de termes. Et peu importe quel tampon est posé: 2x, 5x, 100x - si vous ne le gérez pas, il sera tout de même mangé.

Conclusion

Grâce à cette approche, les développeurs peuvent rationaliser et simplifier le processus d'évaluation. Et les forces seront dépensées moins, et le stress diminuera, et le résultat final sera meilleur. Et nous pouvons aussi leur présenter des surprises moins désagréables, puis nous découvrirons qu’ils ont commencé à parler la même langue avec «nous».

Évaluation. Calculer et rencontrer