Quelles sont, selon vous, les erreurs les plus importantes commises par un chef de projet typique ?
Par "le plus important", je veux dire avec un impact négatif important sur le projet. Et le contexte est celui des projets de ligne d'affaires, où le logiciel n'est pas le produit principal de l'organisation.
Pour chaque erreur dont vous parlez, il serait bon que vous puissiez noter la cause la plus probable et la meilleure solution liée à cette erreur.
Des développeurs qui font du rentre-dedans pour réduire les estimations afin de respecter le budget.
Solution : Décomposer toutes les tâches en une granularité d'environ 4 heures. Jouer poker de planification :
L'idée derrière la planification du poker est simple. Les histoires individuelles sont présentées pour une estimation. Après une période de discussion, chaque participant choisit dans son propre jeu la carte numérotée carte numérotée qui représente son estimation de la quantité de travail nécessaire pour l'histoire discussion. Toutes les estimations sont privées jusqu'à ce que chaque participant ait choisi une carte. A ce moment-là, toutes les estimations sont révélées et la discussion peut recommencer.
Une excellente ressource pour l'estimation est celle de Steve McConnell : Estimation des logiciels : Démystifier l'art noir
Reprogrammation continue des priorités décime la productivité.
On nous a tous dit : "Arrêtez ce que vous faites. Ce site est plus important - fais-le tout de suite"
Souvent causée par :
Des réactions instinctives aux crises ou aux "feux de forêt" qui ont une grande visibilité et/ou de graves conséquences, associées à un ordre venu d'en haut pour les régler immédiatement.
Les opportunités qui sont "trop bonnes" pour être ignorées ou qui ont de "brèves fenêtres d'opportunité".
Regardons les choses en face : des situations inattendues surviennent souvent, et nous devons y faire face. Mais elles doivent être traitées avec compétence géré . Comment ?
Évaluer la véritable priorité de la crise. Peut-elle attendre un jour ou deux ? Quelques heures ?
Tenez compte du coût du stress supplémentaire, de l'impact sur le calendrier et de tous les effets d'entraînement qui résulteront de l'interruption. Demandez aux personnes qui font le travail pour leur contribution à ce sujet.
Si vous devez redéfinir vos priorités, laisser le développeur choisir un endroit intelligent pour mettre en pause la tâche en cours. Cela peut sembler évident, mais les managers non techniques ne comprennent souvent pas qu'il est difficile, long et parfois impossible de reprendre le cours d'une pensée interrompue.
Peut-être que la meilleure solution est l'oxymore de interruptions programmées : dire aux développeurs de s'attendre à être interrompus, peut-être dès le matin et au retour du déjeuner, pour lutter contre les incendies. Très peu de crises ne peuvent pas attendre une heure ou deux, et ce sont des moments naturels pour s'attendre à des interruptions.
Dans un environnement où les crises sont légion, former les développeurs à planifier le travail par petits morceaux autant que possible, afin que toute interruption n'affecte qu'un seul morceau, plutôt qu'une longue activité nécessitant une réflexion approfondie. Dans le pire des cas, si une tâche est complètement abandonnée, les morceaux terminés pourront peut-être être utilisés ailleurs au lieu d'être gaspillés.
Communiquer avec l'ensemble de l'équipe, afin que chacun sache s'il s'agit d'un moment relativement bon ou mauvais pour faire du multitâche ou gérer des crises.
Lancer un projet après que des estimations ont montré que le projet n'est pas possible dans les contraintes de temps et/ou de budget données.
Cause probable : Chef de projet/chef d'équipe subissant des pressions d'en haut pour accepter un délai impossible.
Solución : Dites à la direction la vérité, pas ce qu'elle veut entendre.
Dicter une solution technique sans l'apport des développeurs.
Cause probable : ils ont lu un article sur une nouvelle technologie (ou une ancienne technologie) qui promet de résoudre un problème similaire au vôtre.
Solution : prendre des décisions en équipe, être ouvert et honnête sur les questions techniques, réaliser des prototypes/expérimentations/pointes pour explorer les options.
Jouer à "faire semblant".
Vous savez, du genre "faisons comme si nous pouvions établir un calendrier pour un projet de deux ans, dans lequel nous attribuons les efforts à la demi-journée près, et imaginons que nous ferons ce qui a été prévu pour chaque jour particulier".
Ou comme "prétendons que cela ne demande aucun effort supplémentaire pour maintenir le système, administrer les comptes utilisateurs, gérer le dépôt SVN, écrire des scripts de construction, et organiser le matériel ; après tout, nous n'avons pas obtenu l'effectif nécessaire pour un administrateur système".
Ou encore "faisons comme si, même si nous ne savons pas quelles sont les exigences, nous pouvions faire une estimation des coûts maintenant".
La gestion de projet exige d'être en contact avec la réalité.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
