Comment gérer les modifications rapides des spécifications du projet dans un scénario de délai serré? [fermé]

Question

Comment traiter avec un chef de projet qui impose des délais très serrés, mais avec un jour environ à l’échéance, de nouvelles fonctionnalités et des modifications de spécifications à mettre en œuvre, ainsi que des délais plus courts.

Le pire, c’est que la plupart des nouveautés entraînent une réécriture majeure du code existant, car les règles de gestion précédemment mises en œuvre ne sont plus applicables ou les "gains". cas de coin étranges qui doivent être traités séparément.

Il semble que, peu importe les efforts que nous déployons pour rendre le système extensible, il y a toujours des problèmes qui se posent littéralement au dernier moment et qui doivent être mis en œuvre et pris en charge rapidement.

Comment pourrais-je faire face à une telle situation? C'est vraiment démoralisant et un collègue a déjà quitté l'équipe.

Answer 1

C’est vrai que quoi que vous fassiez, vous êtes humain et vous ferez des erreurs ou des ratés. Cela dit, les modifications régulières apportées à vos besoins sont le plus souvent le résultat de besoins insatisfaisants ou d’un processus de développement médiocre, ou des deux.

Un peu de design avant?

Les développeurs, les chefs de projet, etc., analysent régulièrement les analyses commerciales. La plupart des développeurs souhaitent simplement commencer à pirater le jeu dès le premier jour et la plupart des chefs de projet aiment bien les laisser: passer à la phase de construction en 1 jour sans aucune de ces analyses d’affaires ridicules qui prennent du temps! Cela ira bien pour les bonus d'achèvement! & Quot; Mais rappelez-vous que la tâche principale du Premier ministre est de garder le projet sous contrôle (dans les délais impartis et dans les limites du budget alloué) ... pas nécessairement pour rendre les utilisateurs heureux et surtout pas pour rendre les développeurs heureux. Cela ne veut pas dire qu'ils sont totalement sans cœur; les bons chefs de projet atteindront leurs objectifs en renforçant le contrôle de la portée et en favorisant la communication, ce qui est utile.

Toutefois, prendre le temps de bien réfléchir à ce qui est nécessaire et de passer en revue les scénarios possibles peut faire une différence importante dans les problèmes que vous rencontrez.

• Si vous avez essayé de faire une analyse approfondie de votre entreprise et que vous avez encore des changements de dernière minute, votre problème est peut-être un autre défi classique: les utilisateurs désengagés. Vos experts en la matière sont votre principale arme pour traiter et identifier ces affaires critiques. Si vous avez des utilisateurs qui ne participent pas au processus d'analyse, obtenez de meilleurs experts en la matière.
• Il est également possible que les utilisateurs soient désengagés, car ils sont trop occupés par leur travail habituel. Dans ce cas, il s’agit d’un problème de gestion et il faut leur indiquer que la participation à un projet fait partie de leur travail; C'est parfois difficile, car souvent, c'est la même direction qui vous a dit de "faire le travail hier". C'est le même groupe de knuckleheads qui s'attend à ce que le projet se déroule comme par magie sans aucun hoquet et sans aucune ressource (ils sont courants en ce sens qu'ils ne comprennent pas la complexité du développement de logiciels personnalisés et supposent que c'est facile). Si la direction est désemparée et ne changera pas ... eh bien, vous devez soit faire des heures supplémentaires et régler les problèmes que vous avez décrits, soit obtenir un nouvel emploi.

Can Agile Help?

Il serait bien que vos utilisateurs vous informent plus tôt de ces problèmes, non? Ceci est lié à ce que Toby Hede a discuté dans son post. Peut-être qu'une méthodologie qui permet au logiciel de se présenter au plus vite aux utilisateurs, même dans un état non poli, peut déclencher un retour d'information plus rapidement. C'était l'une des inspirations de tous les concepts agiles. Les créateurs en avaient assez des problèmes que vous décrivez et ils se sont rendu compte que, si la direction et les utilisateurs ne devaient pas changer, le développement pourrait peut-être se faire. Il est encore en développement, mais l'accent est mis sur l'obtention de premières réactions via diverses techniques (les experts en la matière ont-ils co-localisé l'équipe de développement, les prototypes approximatifs sont-ils entre les mains des utilisateurs plus tôt, la programmation en binôme pour capitaliser sur l'expérience des développeurs, etc.) . Tout cela parce qu’il est entendu que nous sommes des êtres humains et que nous allons rater des choses.

Enfin, vous dites que vous essayez de rendre le système extensible pour vous aider à faire face aux changements rapides, mais comment? Séparez-vous la logique de présentation de la logique métier? Encapsulez-vous la logique métier dans des objets, partitionnés de manière appropriée pour minimiser les dépendances et le couplage? Toutes ces choses sont difficiles à faire et peuvent prendre du temps à planifier et à construire.

Au fait, vous n'êtes pas seul. Beaucoup de magasins (peut-être tous) ont ces défis.

Answer 2

Ne les laissez pas imposer la date limite en premier lieu.

Vous avez 2 options

• Le PM vous donne une liste de fonctionnalités et vous leur dites quand il sera prêt.
• Le PM vous fournit une liste de fonctionnalités et une date limite. Vous leur dites ensuite quelles fonctionnalités vous allez implémenter dans le temps imparti.

Si le PM est votre manager ou a le pouvoir d'imposer des délais + un nombre de fonctionnalités, alors je chercherais un nouvel emploi. careers.stackoverflow.com

Si le chef de projet n'est pas votre responsable, vous devez le faire participer et lui demander de lui donner ses options dans la liste ci-dessus.

Answer 3

Ce sujet est vraiment difficile à gérer. Le vrai problème ici est que vous n’avez actuellement aucun processus.

La réponse dépend vraiment de la situation politique de votre organisation et de la quantité d'énergie dont vous disposez pour conduire le changement.

Dans le passé, j'ai essayé d'introduire des changements de processus dans plusieurs organisations et cela a toujours été une lutte. C'est possible, cependant.

Je jetterais un coup d'œil à certaines méthodologies de gestion du développement logiciel. J'utilise et recommande Scrum, par exemple.

Dans une situation de changement rapide, travailler sur de courtes itérations qui ont des objectifs clairement responsables peut être très utile. Vous aurez probablement besoin de défendre et de gérer votre chef de projet, mais cela ressemble au "processus" en cours. Il est clair que la vente d'un nouveau processus devient plus facile - vous avez une solide analyse de rentabilité pour une amélioration.

Un processus solide vous aidera à "repousser les erreurs". sur l'évolution des besoins. Un changement réactionnaire rapide est souvent le symptôme de problèmes plus vastes en matière de direction et de stratégie organisationnelles et il est dans l'intérêt de tous de résoudre ce problème au sein de l'organisation.

Answer 4

C’est l’un des défis majeurs auquel vous serez confronté en tant que développeur.

Une bonne technique que j'ai utilisée par le passé consiste à poser des questions. Lorsque vous obtenez les spécifications, trouvez quelque chose qui nécessite des éclaircissements de la part des utilisateurs finaux. Cela ralentit toujours les choses et soulève la possibilité de risques pour les gestionnaires.

Assurez-vous que votre chef de projet connaît les risques liés à la mise en œuvre de modifications tardives pour un projet.

Answer 5

Votre équipe et vous-même avez-vous essayé d’en discuter avec le responsable lui-même? C'est la première chose à faire.

Il n’a peut-être pas beaucoup d’expérience dans le processus de développement, d’où les délais serrés et les changements très tardifs majeurs . J'ai vu de tels cas, des personnes qui ne pouvaient pas se développer mais qui pensaient pouvoir faire un meilleur travail chez PM.
De s'asseoir et de lui parler, il pourrait en résulter deux choses, selon sa personnalité et son professionnalisme. Il accepterait vos points et essayerait de changer la situation pour le futur ou il serait un smartboy et ne céderait pas un peu, auquel cas il valait la peine de faire évoluer la situation à un niveau supérieur. Je ne pense pas qu’une entreprise accepte volontiers les développeurs perdants.

Alternativement, son manager pourrait être sur lui. Et c'est un problème.

Si rien ne fonctionne, comme déjà suggéré, changer de travail est une bonne chose à faire.