Quelle devrait être la pénalité/réponse en cas de non-respect d'un délai ?

Question

Étant relativement nouveau dans le secteur des logiciels, j'ai été confronté à un problème de respect des délais :

À l'époque idyllique de l'université, la date limite était la fin du semestre et la sanction était un "F" bien défini (ou l'équivalent local). Ici, dans le monde réel, nous devons créer un code avec lequel nos pairs actuels et futurs peuvent travailler, je suis confronté à la situation où la date limite arrive, la date limite repart, et le projet n'est toujours pas terminé.

Et maintenant ? D'un côté, nous pourrions licencier toutes les personnes concernées, de l'autre, nous pourrions récompenser généreusement toutes les personnes concernées.

1. Quelles sont les actions que vous avez vues appliquées comme "pénalité" pour un délai non respecté, et lesquelles ont finalement abouti à un code plus performant ?

2. Quelles sont les réponses de la direction du projet qui ont provoqué l'échec total du projet,

3. Quelles réponses ont permis de rétablir l'ordre de fonctionnement et d'obtenir un code pouvant être maintenu par la suite ?

4. Quelles réponses ont donné lieu à plus de mauvais code ?

Answer 1

Les délais font partie d'une idée fondamentalement erronée sur la façon de faire du développement logiciel. Les personnes nouvellement arrivées dans le secteur du développement de logiciels, ou qui n'en font pas partie, ne le comprennent pas :

Un logiciel est terminé quand il est terminé, ni plus tôt ni plus tard.

Si un développeur a une tâche à accomplir et une semaine pour le faire, et qu'il semble que cela prendra plus d'une semaine, rien ne peut être fait pour changer cela. Peu importe les efforts du développeur, peu importe le nombre de personnes ajoutées à la tâche, elle prendra toujours autant de temps (en fait, ajouter des personnes la rend généralement plus longue).

Au lieu de cela, lisez sur le processus de développement agile. Les logiciels doivent être développés de manière itérative, et chaque itération doit être basée sur les résultats de l'itération précédente, pas sur les exigences externes imposées.

Modifier en fonction des nombreux commentaires ci-dessous :

Je ne dirais jamais que les développeurs ne peuvent pas être tenus à une certaine forme d'attente de livraison. Mon point de vue est en réponse à la spécifique L'hypothèse posée par l'auteur de la question est que la nature du développement de logiciels dans les entreprises est en quelque sorte analogue au travail scolaire, ou à tout autre type de travail d'ailleurs. Je soutiens que ce n'est absolument pas le cas. Une "date limite" implique bien plus qu'une simple date de livraison. Il s'agit d'un point fixe pour lequel une quantité fixe de travail doit être achevée. Les logiciels ne fonctionnent tout simplement pas de cette manière. J'ai écrit quelques paragraphes supplémentaires pour expliquer pourquoi, mais honnêtement, si vous ne le croyez pas déjà, rien de ce que je dis ne vous convaincra.

Si vous travaillez sur un projet de logiciel et qu'il est clair que vous ne serez pas en mesure de respecter votre délai, que pouvez-vous faire pour y remédier ? La réponse est bien connue : pratiquement rien. Vous ne pouvez pas augmenter le nombre de personnes. Vous ne pouvez pas "travailler plus vite". Le travail ne sera tout simplement pas fait à temps. Vous le dites aux parties prenantes, tout le monde s'adapte, et vous continuez à travailler (ou pas). Que signifiait donc la date initiale ?

Quiconque prétend que le développement de logiciels est analogue à la construction d'un pont ou à un travail à domicile, ou que les échéances imminentes peuvent encore être respectées si les développeurs se ressaisissent et travaillent d'arrache-pied, ne comprend pas bien sa propre profession.

Answer 2

Votre première réaction ne doit pas être de savoir quoi faire en réponse au dépassement du délai, mais d'analyser pourquoi vous avez dépassé le délai. La réponse à cette situation découlerait alors naturellement de cette raison.

Par exemple, si toutes les personnes impliquées n'ont pas fait leur travail, licenciez-les.

Mais s'ils ont fait leur travail, et plus encore, alors pourquoi a-t-il encore été manqué ? Trop d'autres activités réalisées par les mêmes personnes ? La portée du projet est trop grande pour le délai (c'est-à-dire un délai irréaliste). Ou ... etc.

D'après mon expérience, la principale raison pour laquelle un délai n'est pas respecté est que les gens ne sont pas autorisés à travailler à 100 % sur le projet en cours, et donc que toute estimation que vous pourriez avoir, bien qu'exacte en soi, n'est pas vraiment utile. Cela, plus des estimations et des délais irréalistes.

Answer 3

Les développeurs ne devraient jamais être pénalisés pour les erreurs de la direction.

C'est comme si un parent punissait un enfant parce qu'il a eu une mauvaise journée.

Raisonnement :

Les délais sont une réalité de la vie. Les gens veulent savoir combien de temps quelque chose va prendre. Le mieux que l'on puisse faire est d'estimer/de deviner. C'est le rôle de la direction d'essayer de comprendre cette estimation magique, jamais correcte. Lorsqu'ils fixent un délai, ils doivent utiliser les bons outils (expérience, demande d'aide aux développeurs, avocats, RH, etc.)

Cependant....

La pénalité pour le non-respect d'un délai devrait pas se retourner contre les travailleurs. C'est la faute de la direction si les délais ne sont pas respectés. Elle aurait dû dire non, réduire le projet ou mieux motiver les travailleurs.

Dans une équipe de construction, si vous énervez les ouvriers, vous déclenchez une bagarre. Dans mon entreprise, si on ne respecte pas les délais, c'est la direction qui a des problèmes. Pas les ouvriers. C'est le travail du directeur de contrôler le projet et ce qui est fait. Les travailleurs font seulement ce qu'ils peuvent. Les managers sont chargés d'attribuer les rôles et les tâches.

Je ne dis pas que la qualité des travailleurs n'est pas un facteur, mais la direction devrait le SAVOIR ! Il ne faut pas être un génie pour savoir qu'un projet n'est pas bien pensé ou bien contrôlé. Demandez à n'importe qui si son manager a la moindre idée de ce qui se passe et vous trouverez le problème.

Nous avons cessé de manquer autant de délais lorsque les responsables ont réalisé que c'était leur faute pour avoir fixé/accepté les délais.

</rant>

Re : Les questions :

Quelles actions ont été appliquées à titre de "pénalité" en cas de non-respect des délais, et lesquelles ont réellement permis d'améliorer la situation ?

• Le manager a moins de responsabilités. Cette personne n'est pas promue ou remerciée publiquement. Il est fort probable que cette personne soit affectée à un projet "moins critique".

Quelles sont les mesures prises par la direction du projet qui ont entraîné l'échec pur et simple du projet, et quelles sont les mesures qui ont permis de rétablir le fonctionnement et d'obtenir un code pouvant être maintenu par la suite ?

• feature creep : le manager continue à ajouter des choses dans la liste. <- combattez cela avec une liste de tâches classées par priorité. Lorsque vous ajoutez des choses à la liste, comparez leur priorité avec les choses qui l'entourent. Faites en sorte que les nouvelles choses aient plus de mal à être définies comme "priorité absolue".
• trop de bogues dans le code : Le manager doit exiger des tests (au moins critiques) et l'automatisation. Les constructions doivent être standardisées et automatiques. Les utilisateurs réels doivent voir le code avant qu'il ne soit "terminé".
• un code illisible : Instituez des revues de code par les pairs. Si quelqu'un a du code sale, demandez à quelqu'un de l'"aider" sur un projet.
• Si vous avez le problème du vendeur, où le vendeur promet des fonctionnalités qui n'existent pas ou ne fonctionnent pas : La direction doit intervenir et expliquer le problème à ce vendeur. Et aussi, pas Donner à ce vendeur l'affirmation publique d'un travail bien fait peut parfois aider.

Answer 4

Plutôt qu'une pénalité, que diriez-vous d'estimations réalistes et de récompenser le respect des délais de publication ?

---

Inspiré par les commentaires de ma réponse

La question devrait peut-être être "Comment faire des estimations réalistes ?". Pour moi, j'utilise FogBugz historique des estimations et date d'achèvement parcelles. Ils me donnent des points de données sur le temps que j'ai estimé qu'une tâche prendrait et le temps qu'elle a réellement pris. Cela m'a aidé à donner des dates de publication réalistes à long terme (cela ne s'est pas fait du jour au lendemain). Je trouve que l'estimation des délais est un processus interactif : I

1. design
2. estimation
3. développer
4. trouver une lacune dans la conception et itérer.

Answer 5

Cela dépend de la question de savoir si les développeurs fixent des délais pour chaque demande de modification, ou si ceux-ci sont fixés pour eux par la direction.

Dans ce dernier cas, à moins que tous vos développeurs ne soient assis et jouent à Halo 3 toute la journée, un délai non respecté est souvent le signe d'une erreur de la part de la direction ou des chefs d'équipe. Donc, licencier tout le monde ne résoudrait pas le problème. Il serait peut-être judicieux d'introduire de meilleurs indicateurs dans votre processus logiciel afin de pouvoir voir que le délai sera dépassé bien avant qu'il ne se produise.

Si vos développeurs donnent des estimations de temps, je ferais très attention à ne pas récompenser ou pénaliser les développeurs qui respectent ou non les délais. Cela pourrait avoir pour conséquence qu'ils ajustent leur "facteur d'erreur" dans l'estimation du temps. Ils se donneraient trop de temps supplémentaire (pour récolter les récompenses), ce qui perturberait les choses s'ils sont bons en estimation. Votre objectif doit être de les amener à fournir des estimations fiables et de qualité, et non de modifier leur façon de travailler pour répondre à ces estimations.