Comment gérer les problèmes chroniques de temps?

https://stackoverflow.com/questions/612892

03-07-2019
|

Question

Mon personnel compte un développeur qui dépasse régulièrement les délais et les estimations. Sur plusieurs projets, la dernière semaine ou les deux derniers jours, j’entends dire que cela devrait se faire d’ici la fin de la journée. Ce développeur fait du bon travail.

Je lui ai déjà parlé de ses problèmes. Il semble sincèrement frustré et irrité par les mesures à prendre pour les corriger.

Mes questions sont les suivantes:

Quels types de punitions pour le dépassement d'une échéance sont efficaces?
De quelles manières puis-je contraindre cet employé à surveiller lui-même ses actions (estimation du temps, etc.)?

MISE À JOUR : Basé sur les réponses; voici ce que j'ai compris.

La punition est une mauvaise idée.
Il est naturel pour un employé d’être incapable de résoudre les problèmes d’estimation sans intervention.
Ne fixez pas d’échéances à moins que la société (perte du contrat) n’éprouve les conséquences de ne pas le faire à cette date.
Utilisez les méthodes disponibles (Agile, la liste de contrôle de Joel) pour aider le développeur à mieux estimer.

Merci pour les liens et les informations. Merci également de mettre à jour ma pensée.

La solution

Je ne pense pas que le problème est qu'il manque ces délais.

Je pense qu'il a de la difficulté à estimer le temps qu'il faudra pour mener à bien une tâche.

Demandez-lui de commencer à tenir un journal de ce qu’il dit qu’une tâche va prendre et combien de temps il lui a effectivement fallu pour la terminer. À terme, ce journal deviendra en quelque sorte un guide pour lui permettre de créer de meilleures estimations. Une fois qu’il a amélioré ses estimations, il ne devrait plus se sentir aussi pressé ni harcelé.

Autres conseils

Il existe un article intéressant de Joel Spolsky: Planification basée sur des preuves

1) Détruisez-vous

Lorsque je vois un horaire mesuré en jours, voire en semaines, je sais qu'il ne va pas au travail. Vous devez diviser votre emploi du temps en très petites tâches pouvant être mesurées en heures. Rien de plus que 16 heures.

Cela vous oblige à déterminer ce que vous allez faire. Ecrire sous-routine foo. Créez cette boîte de dialogue. Analyser le fichier Fizzbott. Les tâches de développement individuelles sont faciles à estimer car vous avez déjà écrit des sous-routines, créé des boîtes de dialogue et analysé des fichiers.

Si vous êtes bâclé et que vous choisissez de grosses tâches de trois semaines (par exemple, & # 8220; Implémenter l'éditeur de photos Ajax & # 8221;), alors vous n'avez pas pensé à ce que vous allez faire. En détail. Pas à pas. Et si vous n'avez pas pensé à ce que vous allez faire, vous ne pouvez pas savoir combien de temps cela prendra.

La définition d'une durée maximale de 16 heures vous oblige à concevoir cette fonction. Si vous possédez une fonctionnalité de trois semaines main-ondulée appelée & # 8220; éditeur de photos Ajax & # 8221; sans une conception détaillée, je suis désolé d'être celui qui vous le révélera, mais vous êtes officiellement condamné. Vous n'avez jamais pensé aux étapes qu'il va suivre et vous êtes sûr d'en oublier beaucoup.

Le point essentiel est qu’il (et vous) devrait apprendre de ses erreurs et en tenir compte lors de la prochaine estimation.

De plus, si vous êtes développeur, je réviserais régulièrement le code en fin de journée pour mieux comprendre son processus de développement.

Et, bien sûr, des itérations plus petites et plus de granularité dans les tâches. Définissez la durée maximale de la tâche sur 1 jour. C'est la règle que nous avons.

Si votre première question est quel type de punition envisager Je pense que vous êtes tout de suite un perdant. Si vous pensez qu'il fait du bon travail, vous devrez peut-être examiner les échéances / estimations et voir si elles étaient réalistes au départ. Qui les a configurés, si le développeur en question n'était pas impliqué, cela pourrait faire partie du problème.

Je suis d’accord avec @OTisler pour dire que la programmation en binôme et éventuellement une analyse régulière des progrès réalisés à la fin de la journée peuvent l’aider à passer à travers ... bien que si les délais / estimations ne soient pas réalistes, ce n’est pas là votre problème.

Une surveillance plus étroite de quelques tâches spécifiques doit mettre en évidence les problèmes.

Quels types de punition pour avoir passé une échéance est-elle effective?

Aucun. Si vous le mettez en colère, il ne fera pas le travail ou il trouvera un autre travail. Vous devriez l'aider à comprendre pourquoi ses estimations sont fausses. Steve McConnell a publié un livre sur les estimations. je commencerais par là.

De quelles façons puis-je mettre cela en cohérence? employé à la police ses actions (temps estimations, etc.) lui-même?

En l'aidant à trouver le bon moyen de faire des estimations.

Tout d'abord, assurez-vous que vos exigences sont parfaitement claires.

Je déteste le dire, mais d’après mon expérience, les délais très brefs sont aussi souvent liés à des exigences peu claires ou à des spécifications faibles de la part d’un superviseur. La première chose à faire est de s’assurer que le problème ne provient pas de vous ou n’exacerbe pas votre problème.

Assurez-vous également que vos exigences sont réalistes, ainsi que ses estimations.

Assurez-vous que vos propres attentes ne l’incitent pas à faire des estimations irréalistes afin de répondre à des exigences irréalistes.

N'oubliez pas que vous remplissez les conditions requises, mais que le développeur effectue TOUJOURS les estimations et ne doit pas se laisser influencer par "pouvons-nous le faire plus rapidement" sauf si vous spécifiez également la fonctionnalité à supprimer.

Ensuite, assurez-vous qu'il surveille son temps et ses tâches avec précision, de sorte que vous puissiez avoir une bonne vue de ce qui se passe dans le projet.

Ce processus montrera tout manque de suivi approprié du temps / des tâches, ce qui pourrait être la première étape vers une amélioration. Si vous ne pouvez pas voir après le projet combien de temps un élément particulier a pris, c'est probablement la cause du problème ici: définition insuffisante dans l'estimation, ou absence de "dépendance". tâches découvertes en cours de projet, mais jamais estimées.

Vous DEVEZ savoir combien de temps a été consacré à faire quoi avant de savoir exactement où était le fluage, ou ce que vous pouvez faire pour y remédier.

Ensuite, voyez où ses estimations échouent et pourquoi. Passez en revue l’estimation d’un projet en souffrance, transformez-la en projet lui-même - un problème à résoudre.

Une fois que vous avez déterminé que ses estimations sont bien la source du problème, passez en revue une estimation qui a été faite avec lui, et peut-être un autre développeur, et essayez de comprendre pourquoi.

Cela vous aidera à déterminer la cause du problème. Une bonne compréhension du problème sera probablement la solution réelle.

Enfin, si vous atteignez un point où vous devez vous soumettre à une punition ou à la contrainte, il est temps de le renvoyer et de recommencer à zéro.

La punition et la contrainte sont des réponses appropriées à des actes répréhensibles volontaires dans certaines situations.

Toutefois, si ce développeur tente activement de faire du bon travail, vous ne feriez qu'aggraver la situation en générant une attitude négative et de la frustration.

Si le problème ne peut pas être résolu et que vous êtes sûr que le problème vient de lui, et non de vous, il est temps de le licencier et de trouver un développeur capable de respecter les délais. Un excellent travail ne veut pas dire grand-chose lorsque vos coûts sont gonflés et que vos profits sont mis à mal.

D'accord, c'est assez courant - les développeurs sont optimistes. C'est le travail de la direction de s'en occuper. Si quelqu'un doit être puni, c'est le responsable (vous?)

Je suis content que vous ayez au moins demandé, il semble que vous ayez de bonnes réponses sur cette liste, j'espère qu'ils vous aideront et que vous trouverez le moyen de mettre en œuvre certains de ces travaux.

Quand j'étais jeune, mon premier bon manager a traité la question de cette façon:

Tout d'abord, il m'avait proposé une liste détaillée - décomposant les tâches en heures et estimant chaque tâche avec une estimation très libérale - aucune période ne devrait être inférieure à 4 heures, quelle que soit la taille de la tâche. .

Puis il les a regardés et m'a dit de doubler toutes mes estimations. (Les développeurs, en particulier les plus jeunes, ne pensent pas au fait que vous ne pouvez être productif que pendant environ la moitié de la journée, si vous avez de la chance - et la moitié de cette somme est consacrée à des tâches que vous ne pensiez pas devoir accomplir. faire).

Ensuite, avant de créer son emploi du temps, il a doublé tous mes devis (sans me le dire).

Il les a tournés de cette manière, quelles que soient les exigences du calendrier ci-dessus. Un bon manager devrait comprendre que dire que cela doit être fait en 2 jours ne le rend pas possible.

Comme je pouvais mieux estimer, nous avons tous deux remarqué et ajusté en conséquence.

Un travail de manager ne consiste pas seulement à faire un projet, mais à constituer une équipe. Le plus souvent, cela nécessitera une formation quelconque. C’est aussi la raison pour laquelle un responsable technique qui n’est pas un ingénieur est inacceptable, il ne peut pas vraiment aider ce genre de choses.

L'échec d'un projet ou d'un calendrier n'est pratiquement jamais la faute du développeur (sauf dans quelques cas chroniques où il n'est pas vraiment réparable ou n'a aucune valeur et doit être congédié). Le responsable a pris de mauvaises décisions en recrutant le développeur, en lui faisant confiance, en le gérant ou en gérant le projet.

Et vraiment, quelle est la faute de toute façon? Je suppose que si le responsable n’est pas très doué pour réaliser le projet, il aura besoin de quelqu'un à qui pointer du doigt ... Si son responsable est bon, il demandera pourquoi il est allé si loin et ce que vous avez fait pour le réparer. , etc.

Embaucher un gestionnaire, c'est embaucher quelqu'un pour résoudre les problèmes. Rendre les développeurs productifs. S'il ne peut pas les rendre productifs, il n'est pas la bonne personne.

À vos questions:

Si vous choisissez de punir les personnes qui ne respectent pas les délais, vous n'obtiendrez pas de bons résultats. Ils seront démotivés et se sentiront rabaissés. Si vous continuez à pousser les gens à respecter les délais, la qualité du travail en souffrira et vous aurez beaucoup de temps passé à réparer les bugs par la suite.
Pour améliorer ses estimations de temps, vous pouvez utiliser la planification basée sur des preuves de Joel Spolsky qui a une belle boucle de rétroaction pour améliorer les estimations résultantes.

Mais j’ai des questions auxquelles vous devez réfléchir, je pense.

Est-il plus tard que tout le monde? Si oui, pourquoi - est-ce parce qu’il est un estimateur trop optimiste ou un travailleur lent? Il est facile de corriger les estimations trop optimistes - il suffit de multiplier tous ses chiffres par un facteur, conformément à la planification ci-dessus fondée sur des preuves. S'il est un travailleur lent, pourquoi? Est-il distrait? Fait-il très attention à produire un code de défaut très faible? Est-il sur des solutions d'ingénierie? Ne réutilise-t-il pas le code efficacement?

Les délais sont-ils importants ou s'agit-il simplement de dates arbitraires basées sur les estimations afin de rendre compte de la progression dans la hiérarchie de gestion? Si ce dernier, vous pouvez résoudre ce problème en modifiant vous-même ses estimations.

Quels types de punition pour avoir passé une échéance est-elle effective?

Vous avez énoncé le point et vous l'avez manqué. La peine évidente pour passer une date limite est la mort. Si le développeur est toujours en vie après avoir dépassé une date limite, le "date limite" n'était évidemment pas un vrai délai. Pensez-vous qu’il est amusant de mettre la pression sur les développeurs en utilisant un langage martial?

Corrigez votre libellé.

Motivation

Tout d’abord: lisez Peopleware

Suivant. Pourquoi pensez-vous que la punition sera un moyen efficace de gérer des personnes supposées être créatives? Je pense que vous devez repenser toute l'approche de la gestion par rapport à l'équipe.

Comme je le vois d’abord, les gestionnaires et le rôle le plus important est de s’assurer que les développeurs peuvent être créatifs et productifs. Pas qu'ils soient productifs. Il y a une grande différence dans ces petits mots. Pour être créatif, vous avez besoin d'un environnement sécurisé. En étant constamment sous la pression de délais et de menaces de punition, vous créez exactement le contraire de ce qui est sûr.

En outre, en tant que responsable, vous avez besoin d'informations précises sur lesquelles baser vos décisions. Cela nécessite également un environnement sûr. S'il y a un risque de punition pour être honnête et franc, vous êtes assuré de mentir et d'absence d'informations. Une base très dangereuse pour prendre des décisions.

Estimations

Comme mentionné précédemment, les estimations sont des estimations. Dans notre équipe, nous ne faisons aucune estimation individuelle, nous faisons des estimations en équipe. (Je suis un peu réticent à appeler ce que nous faisons Scrum, mais la plupart essaie de l'imiter si rien de moins) Je pense que c'est un très bon moyen de faire des estimations: chaque membre de l'équipe reçoit un jeu de cartes composé de nombres 0 , 1 / 2,1,3,5,8,13,20,40,60,100 et lors de l’estimation d’une tâche, chaque développeur choisit une carte (les cartes sont masquées jusqu'à ce que tout le monde ait choisi une carte pour ne pas influencer les estimations) et la moyenne de les cartes sélectionnées sont considérées comme une estimation.

Notez que les chiffres deviennent progressivement moins précis. C’est ce que nous avons voulu faire parce que les grandes estimations sont nécessairement moins précises.

Pour notre équipe, nous avons choisi d'utiliser l'unité "jours-hommes idéaux". pour les estimations. Pour autant que chacun de nous se souvienne, une journée idéale n’a pas encore eu lieu, mais c’est une bonne base pour savoir comment traduire les jours de calendrier en "jours de travail idéaux".

Comme Scrum le prescrit, le développement est effectué en sprints de deux semaines après le déploiement de la nouvelle version dans l'environnement de production. Après chaque sprint, nous prenons la somme des estimations des tâches terminées et nous la divisons par le nombre de jours-personnes prévus pour le sprint. Ce facteur sert alors à estimer le nombre de "jours-hommes idéaux". l'équipe peut passer dans une période de deux semaines.

Les tâches exécutées par un développeur individuel ne nécessitent pas d'estimation. La première approximation est toujours 1/2 - 1 jour à compléter. Si cette estimation s'avère fausse, il vous suffit de saisir un développeur et de le faire ensemble pour le faire. Vous pouvez également décomposer l’élément de travail en tâches plus petites afin de mieux le répartir.

Définissez jalons et essayez Agile comme le suggère @OTisler.

Je ne pense pas que vous devriez le punir. Faites lui simplement comprendre comment faire des estimations précises.

En tant que chef d'équipe, les membres de mon équipe m'ont dit que ce ne serait "pas un problème". pour terminer X fonctionnalité à la date limite. Ensuite, je m'assois habituellement avec eux et leur explique quelles tâches et quelles sous-tâches doivent être accomplies pour que la fonctionnalité soit terminée et combien de temps le développeur pense que cela prendra.

Après avoir effectué cet exercice et additionné toutes les estimations de tâches et de sous-tâches, cela prendra inévitablement beaucoup plus de temps que ne le prévoit le développeur dans son estimation initiale. Je n'ai généralement à faire cet exercice qu'avec eux à quelques reprises avant qu'ils ne commencent à faire des estimations plus précises.

Ce qui me surprend, c’est que vous n’avez qu’un de ces gars-là.

Les ingénieurs sont horribles à estimer combien de temps il faudra quelque chose. Je parie que si vous examinez attentivement les estimations de vos autres développeurs, vous constaterez qu'il y a beaucoup de rembourrage. Parfois, le remplissage n'est pas nécessaire, mais la tâche se développe de manière à occuper le temps disponible.

La solution à ce problème consiste à modifier votre estimation - pour tout le monde. Les développeurs ont peut-être du mal à estimer le temps absolu, mais ils sont plutôt bons au temps relatif. Donc lundi, au lieu de "Combien de temps faudra-t-il pour ajouter un whoosiwhatsit?" demandez "Que pouvez-vous faire sur le site Web en moins d'une semaine?" Cela devient leur tâche pour la semaine.

Le lundi suivant, vous regardez comment cela s'est passé. "Eh bien, le floogle a été installé en deux jours, mais il s'avère que cela a eu un impact sur le mcphee ... donc cette semaine, je dois découpler ces types pour que les fichiers whoosiwhatsit ne soient pas écrasés." Ok, il y a leur tâche pour la semaine.

Vous pensez peut-être que cela ne vous aidera pas, car vous ne savez toujours pas quand le whoosiwhatsit sera prêt. C'est vrai. Vous avez deux choix ici:

Si vous avez besoin d’une échéance, vous devez obliger votre développeur errant à compléter ses estimations comme tout le monde. Il ne tardera pas à s’y habituer et, en un rien de temps, il prendra "2 semaines". écrire quelque chose qui aurait dû prendre un jour.

Vous pouvez également échanger les estimations fictives contre plus de visibilité. À long terme, cette approche vous rend plus ingénieux et plus heureux.

Le développeur fait donc du bon travail, mais sa capacité à estimer le temps de livraison est médiocre. Je ne suis pas sûr que vous ayez une situation de punition sur les mains pour l'instant.

Peut-être que, dans l'avenir, demandez-lui de vous expliquer son processus d'estimation d'un point de livraison. Cela peut être l'occasion de lui demander pourquoi les étapes X, Y et Z prennent un certain temps. Il peut être amené à réviser ses estimations en faisant simplement l'exercice à un rythme presque certainement plus lent.

demandez-vous ceci: en quoi consiste votre travail?

Si vous ne faites que passer aveuglément aux estimations des développeurs (qui, vous le savez, ne peuvent pas donner de bonnes estimations) en amont de la hiérarchie, sans décider vous-même si cette estimation est réalisable, vous ne faites pas votre travail.

Essayez de penser en termes de " valeur-add " (Un de mes anciens employeurs a beaucoup utilisé ce terme et je le détestais, mais cela fonctionne probablement pour vous dans cette situation). Quelle valeur ajoutez-vous? Si vous ne faites que passer des choses dans les deux sens entre la haute direction et les développeurs, vous ne gagnez donc pas votre argent. Vous pourriez être retiré et rien ne changerait.

Le meilleur manager que j'ai jamais eu a été celui qui a examiné une série d'exigences qui lui avaient été données par une autre équipe et leur a tout de suite dit que près d'un tiers d'entre eux était un taureau et qu'ils avaient été retirés avant même d'avoir vu le liste. Le pire que j’ai jamais fait m’a obligé à rédiger toute cette documentation de type gestion qu’aucun des autres gestionnaires que je m’avais jamais demandé de faire (j’ai vraiment eu l’impression que je faisais littéralement son travail pour lui), n’a pas même me donner les dates d'échéance du projet, et à peine arrivé au travail. Bizarrement, ils étaient tous deux dans la même entreprise.

90 heures est une échéance commune à un projet court. Le moyen le plus simple est d’évaluer votre temps au lieu d’estimer votre temps. Les informaticiens ne devraient pas faire une estimation de la durée de leurs projets car il est prouvé que calculer son propre temps entraîne une erreur plus importante que l'observation d'un autre.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow