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

Question

J'ai un développeur sur mon personnel qui chroniquement dépassements de délais, et les estimations. Sur plusieurs projets de la dernière semaine ou deux tous les jours, j'entends des "Il devrait être fait d'ici à la fin de la journée". Ce développeur fait du bon travail.

J'ai déjà parlé de lui à propos de ses problèmes. Il semble vraiment frustré et fâché à propos de quoi faire pour les corriger.

Mes Questions sont les suivantes:

1. Quels types de sanctions pour le passage de l'un délai sont-elles efficaces?
2. Comment puis-je forcer l'employé à la police de ses actions (les estimations de temps, etc.) lui-même?

Mise à JOUR: Sur la base des réponses; voici ce que j'ai compris.

1. La punition est une mauvaise idée.
2. Il est naturel pour un employé d'être incapable de corriger l'estimation des problèmes sans intervention.
3. Ne faites pas de délais de moins qu'il y ait de la compagnie conséquences (perte de contrat) pour ne pas être fait d'ici là.
4. Utiliser les méthodes disponibles (Agile, Joël liste de contrôle) pour aider le développeur à l'estimation de mieux.

Merci pour les liens et de l'information. Aussi merci pour la mise à jour de ma pensée.

Answer 1

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

Je pense qu'il a un réel problème pour 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 du temps qu'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 est devenu meilleur à estimer, il ne devrait pas se sentir aussi pressé ou harcelé.

Answer 2

Il y a un article intéressant par Joel Spolsky: la Planification Fondée sur des données Probantes

1) Rupture " er vers le bas

Quand je vois un planning mesuré en jours, voire des semaines, je sais qu'il ne va pas au travail. Vous devez sortir de votre calendrier dans de très petites tâches qui peuvent être mesurés en heures. Rien de plus de 16 heures.

Cela vous oblige à réellement comprendre ce que vous allez faire. Écrire la fonction toto. Créer cette boîte de dialogue. Analyser la Fizzbott fichier. Le développement individuel des tâches sont faciles à estimer, parce que vous avez déjà écrit des fonctions, créé des boîtes de dialogue et fichiers consultés avant.

Si vous êtes bâclée, et de choisir de grands trois semaines de tâches (par exemple, "mettre en oeuvre Ajax photo editor"), alors vous n'avez pas pensé à ce que vous allez faire. Dans le détail. Étape par étape. Et si vous n'avez pas pensé à ce que vous allez faire, vous ne pouvez pas savoir combien de temps il faudra.

Réglage de 16 heures maximum vous oblige à la conception de la merde fonctionnalité. Si vous avez une main-ondulé de trois semaines fonctionnalité appelée "Ajax" photo editor" sans une conception détaillée, je suis désolé de le rompre pour vous, mais vous êtes officiellement condamné. Vous n'avez jamais pensé que sur les mesures qu'il va prendre et que vous êtes sûr d'être en oublier beaucoup.

Le point principal est que lui (et vous) doit apprendre de ses erreurs, et de les prendre en compte sur la prochaine estimation.

Aussi, si vous êtes un développeur, je fais régulièrement de l'examen du code, à la fin de la journée pour obtenir un meilleur aperçu de son processus de développement.

Et, bien sûr, les petites itérations et plus niveau de granularité des tâches. Définir le maximum de la durée de la tâche à 1 jour. C'est la règle que nous avons.

Answer 3

Si votre première question est quel type de sanctions à envisager Je pense que vous êtes un perdant tout de suite. Si vous vous sentez qu'il fait du bon travail, vous pourriez avoir à regarder le délais/estimations et de voir si elles étaient réalistes, en premier lieu. Qui a mis en eux, si le développeur en question n'a pas été impliqués alors que peut-être une partie du problème.

Je suis d'accord avec @OTisler que la programmation en binôme et, éventuellement, un régulier de la fin de la journée d'évaluation des progrès avec vous-même pouvez l'aider par le biais de... bien que si les délais/estimations ont été irréaliste pour commencer c'est pas où votre problème.

Une surveillance plus étroite sur quelques tâches spécifiques doivent mettre en évidence où toutes les questions mensonge.

Answer 4

Quels types de sanctions pour le passage de une date limite est efficace?

Aucun. Si vous la colère lui, il ne sera pas faire le travail, ou il va trouver un autre emploi. Vous devez l'aider à comprendre pourquoi ses estimations sont hors tension. Il y a un livre par steve McConnell au sujet de faire des estimations. je commencerais par là.

De quelle manière puis-je la cohérence de cette employé à la police de ses actions(temps les estimations, etc.) lui-même?

En l'aidant à trouver la bonne façon de faire des estimations.

Answer 5

Tout d'abord, assurez-vous que vous êtes en cristal clair dans vos exigences.

Je déteste dire ça, mais dans mon expérience, soufflé les délais sont tout aussi souvent une question du manque de clarté des exigences ou de la faiblesse des spécifications de la part d'un superviseur. La première chose à faire est de vous assurer que le problème n'est pas originaire, ou exacerbé par, vous.

Aussi, assurez-vous que vos exigences sont réalistes, ainsi que des estimations.

Assurez-vous que vos propres attentes ne sont pas le pousser à faire des estimations irréalistes afin de répondre aux exigences irréalistes.

Rappelez-vous, vous ne les besoins, mais le développeur est TOUJOURS estimations, et ne doit pas être influencé avec des "peut-on le faire plus rapidement", sauf si vous spécifiez également la fonctionnalité de suppression.

Ensuite, assurez-vous qu'il est suivi de son temps/tâches avec précision, de sorte que vous pouvez obtenir une bonne vue de ce qui se passe avec le projet.

Ce processus indique le manque de temps/de suivi des tâches, ce qui peut finir par être la première étape vers l'amélioration. Si vous ne pouvez pas le voir après le projet de combien de temps un article en particulier a pris, c'est probablement la cause du problème - pas assez de définition dans l'estimation, ou manquant de "dépendance" des tâches qui sont découverts à mi-projet, mais jamais estimé.

Vous devez savoir combien de temps a été passé à faire ce que, précisément, vous pouvez trouver où le fluage a été, ou ce qui peut être fait à ce sujet.

Puis, de voir où ses estimations sont défaillants et de comprendre pourquoi. Aller sur une estimation d'un soufflé projet, faire un projet en lui-même - un problème à résoudre.

Une fois que vous avez déterminé que ses estimations sont en effet la source du problème, d'aller sur une estimation qui est allé avec lui, et peut-être un autre développeur, et de comprendre pourquoi.

Cela vous aidera à comprendre quelle est 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 essayer de punition ou de la coercition, il est temps pour lui mettre le feu et de recommencer.

Répression et la Coercition sont des réponses appropriées à intentionnelle des actes répréhensibles dans certaines situations.

Toutefois, si ce développeur est activement en essayant de faire un bon travail, alors vous ne ferait qu'aggraver la situation en générant une attitude négative et de la frustration.

Si le problème ne peut être résolu, et vous êtes sûr que le problème est avec lui, et pas vous, alors il est temps de le renvoyer et obtenir un développeur qui peut respecter les délais. Un grand travail ne signifie pas grand chose quand vos coûts sont à soufflé et le bénéfice va à la fenêtre.