Comment planifier les projets de manière réaliste tout en tenant compte des problèmes de support?

Nous avons un problème au travail: nous essayons de planifier le travail afin que nous puissions évaluer les échelles de temps et obtenir des dates limites.

Le problème est qu'il est difficile de planifier un projet sans savoir tout ce qui va se passer.

Par exemple, en ce moment, nous avons planifié tous nos projets jusqu'au début du mois de décembre, mais pendant ce temps, nous aurons diverses réunions internes et externes, des téléconférences et du travail supplémentaire. C'est bien beau de dire qu'un projet prendra trois semaines, mais s'il y a une semaine d'interruption pendant cette période, la date d'achèvement sera repoussée d'une semaine.

Le problème est triple:

1. Lorsque nous planifions des projets, les échelles de temps sont prises à la lettre. Si nous estimons trois semaines, le délai est fixé à trois semaines, le client est informé et il n'y a pas de place pour une prolongation.

2. Le travail intérimaire et cela signifie que nous perdons du temps productif à travailler sur le projet.

3. Parfois, les clients n'ont pas le temps dont nous avons besoin pour faire le travail, alors ils viennent parfois nous voir et disent qu'ils ont besoin d'un projet fait avant la fin du mois même lorsque nous pensons que le travail prendra deux mois - sans oublier que nous avons déjà du travail à faire.

Nous avons un diagramme de Gantt que nous essayons de remplir avec tous les projets que nous avons et nous remplissons des feuilles de temps, mais elles ne sont pas du tout comparées au diagramme de Gantt. Il est donc difficile de dire "Eh bien, nous avons prévu 3 semaines pour ce projet, mais nous avons perdu une semaine ici, donc le délai doit reculer d'une semaine."

Il n'est pas non plus professionnel de respecter les délais manquants que nous avons communiqués au client.

Comment les autres gèrent-ils ce type de situation? Comment gérez-vous la planification des projets? Combien de temps «supplémentaire» prévoyez-vous dans un projet pour tenir compte du travail hors projet qui se produit pendant un projet? Comment gérez-vous les problèmes de support, les bugs et autres choses? Des choses dont vous ne pouvez pas tenir compte pendant la planification

MISE À JOUR

Beaucoup de bonnes réponses merci.

Le problème est cependant qu'il est difficile de planifier un projet sans savoir tout ce qui va se passer.

Voilà le point de la gestion des risques. Vous ne pouvez pas tout savoir, alors vous planifiez en fonction de ce que vous savez et identifiez les choses qui pourraient avoir le plus d'impact sur votre plan et la probabilité que cela se produise. Évaluez également l'impact potentiel du calendrier en disant que si X se produit, le calendrier glissera d'environ Y jours ou semaines (mot clé - estimé).

C'est bien beau de dire qu'un projet prendra 3 semaines,

Ne donnez jamais une estimation aussi précise. Donnez une fourchette ou quantifiez la probabilité d'atteindre cette estimation. Par exemple, dites "ce projet prendra de 2 à 5 semaines" ou "il y a 85% de chances que ce projet se fasse en 3 semaines et 95% de chances qu'il se fasse en 4 semaines".

Ce n'est pas non plus professionnel pour le client de continuer à dire que nous avons manqué un délai.

Vrai. Cependant, vous mélangez les concepts d '"estimation", de "calendrier" et de "date limite". Votre estimation est une approximation du temps qu'il faudra pour terminer une tâche ou un projet donné et la probabilité d'y parvenir. Le délai est une date imposée par le client à laquelle le projet doit être réalisé afin d'ajouter de la valeur. Le calendrier est la façon dont vous utilisez vos ressources disponibles pour respecter votre échéance.

Il y a des moments où il n'est tout simplement pas possible de terminer le travail assigné dans un délai et toutes les estimations et la planification dans le monde ne feront pas de différence.

Alors ma question ... comment les autres font-ils cela? Comment gérez-vous la planification des projets? Combien de temps «supplémentaire» prévoyez-vous dans un projet pour tenir compte de tout ce qui se passe entre-temps?

Je recommande la lecture de deux livres, tous deux par Steve McConnell: Software Estimation: Demystifying the Black Art and Rapid Development: Taming Wild Software Schedules . L'estimation de logiciels consiste à proposer vos estimations, à les présenter aux clients, à certains aspects de la négociation et à répondre aux attentes irréalistes. Le développement rapide est la gestion générale de projet, traitant des cycles de vie du développement, de la planification, de l'allocation des ressources et de la meilleure façon de planifier et de budgéter les projets pour respecter vos estimations et vos délais.

Je suggère de creuser dans les détails du processus de développement Scrum . Il couvre ces activités de détournement par la focus factormétrique. Fondamentalement, vous devez travailler 2-3 sprints / itérations, puis mesurer le facteur de concentration de votre équipe (et pour chaque membre, cela serait également utile). Après cela, vous pourrez fournir des estimations plus précises qui couvrent l'activité quotidienne.

Jetez un oeil à cet article - "Le facteur de concentration"

Si l'un d'entre vous connaît le développement Agile, vous avez probablement entendu parler du facteur de concentration (ou facteur de productivité). Il est utilisé pour la planification afin de déterminer combien d'heures réelles vous devez travailler sur quelque chose. C'est la différence entre les «heures réelles» et les «heures idéales».

Le problème des interruptions est que, pour des individus ou des équipes donnés, elles ont tendance à se produire dans une plage de probabilités relativement petite. Par exemple, vous avez environ le même nombre de réunions chaque semaine, ou environ le même nombre d'heures consacrées à des corrections de bogues urgentes chaque mois, ou le même temps consacré à répondre aux questions des personnes qui passent par votre bureau, en particulier lorsqu'elles font la moyenne de une longue période de temps.

De nombreuses techniques de planification modernes en tiennent compte. Scrum le facteur en vitesse. La planification basée sur des preuves utilise également une vitesse avec un intervalle de confiance pour toute estimation donnée. Pomodoro prend en compte les interruptions lorsque vous décidez du nombre de "pomodoros" que vous pouvez compter terminer au cours d'une semaine donnée. Tout cela dépend du suivi des mesures historiques de vos interruptions et de leur prise en compte dans vos estimations d'une manière ou d'une autre. Je vous recommande de les examiner tous et de concevoir une technique qui fonctionnera pour votre équipe.

De bons conseils tout autour.

Une autre chose qui pourrait être utile pour résoudre les problèmes de support est de dédier les gens au support sur une base fixe "round-robin".

Par exemple, si vous avez 5 développeurs, affectez-en un à chaque jour de la semaine. Lorsque ce jour arrive, le développeur affecté travaille pour ce jour UNIQUEMENT sur le support. Le lendemain, un autre développeur prend en charge le support. De cette façon, tout le monde a une chance de rester dans leur "flux", tout le monde a un avant-goût de la nourriture pour chiens.

La façon dont vous choisissez RÉELLEMENT de répartir le travail de soutien régulier n'a pas vraiment d'importance (le tournoi à la ronde des jours de la semaine n'est qu'un exemple). Ce qui importe, c'est de limiter le temps de support à des intervalles réguliers fixes. Cela rend le temps de développement plus prévisible avec le compromis que vous ne pouvez pas demander à "tout le monde de tout laisser tomber" pour traiter les problèmes de support.

C'est une compétence qui vient vraiment avec l'expérience, et souvent on demande aux gens avant de pouvoir juger avec précision une telle chose. J'ai toujours travaillé dans un groupe assez soudé avec un style informel, mais nous avons développé quelques règles générales qui semblaient bien tenir.

D'abord, aucune tâche ne prend moins d'une semaine. Estimez toujours en semaines, même si une tâche semble ne prendre que quelques jours. Il y aura une raison pour laquelle cela ne sera pas fait avant la fin de la semaine.

Deuxièmement, faites de votre mieux pour estimer la durée de la tâche, y compris les interruptions, les problèmes de support client, la réalisation des tests, etc. Maintenant, doublez ce nombre. C'est votre estimation (en semaines).

Troisièmement, assurez-vous que votre gestionnaire n'ajoute pas déjà du rembourrage à vos estimations. Notre équipe avait un gestionnaire se plaindre de nos estimations. Il s'est avéré qu'il allait déjà le multiplier par 2,1 (son estimation de remplissage empiriquement dérivée) et nous l'avions déjà doublé avant de le lui dire.

Ce n'est pas un outil sophistiqué et ce n'est peut-être pas une méthode parfaite, mais cela fonctionne étonnamment bien.

Les personnes qui font l'estimation doivent comprendre qu'aucune équipe n'est jamais à 100% sur un projet. Vous avez des congés de maladie, des vacances, des fonctions de jury, des congés de deuil, des réunions RH requises (c'est le temps des avantages!), Des réunions d'équipe qui ne sont pas liées au projet, un retard inévitable, des pauses toilettes, un travail de support sur des articles déjà en production, le traitement des e-mails, , configurer le nouvel ordinateur après la mort de l'ancien, répondre aux questions sur le travail futur et faire des estimations pour ce travail, encadrer les juniors, etc. qui doivent être prises en compte. Il est irresponsable pour un estimateur de supposer plus de 6 heures sur 8 heures disponible par jour. C'est une garantie que le délai ne peut être respecté. Si vous garantissez que le délai ne peut pas être respecté, vous garantissez un client mécontent.

Vous avez absolument raison - il est difficile de planifier un projet sans savoir tout ce qui va se passer. Mais il est très important de garder une trace des choses qui sont une norme ainsi que des tâches que vous prévoyez. Voici où la gestion des horaires joue un rôle. J'ai utilisé la gestion de projet Microsoft (version standard) pour laquelle comprend également des fonctionnalités qui font partie d'un logiciel de planification de gestion de projet.

Vous pouvez visiter http://www.microsoft.com/project/en/us/schedule-management.aspx pour plus d'informations.

Il semble qu'il y ait beaucoup d'efforts cachés tirés de vos équipes de projet à travers lesquels vous perdez votre concentration et votre vitesse. Il pourrait être essentiel de séparer la tâche de traitement des

..support des problèmes et des bugs et autres choses?

à un groupe spécifique de personnes afin que les autres membres de l'équipe puissent se concentrer sur les nouvelles tâches de développement. Grâce à cela, leur production globale pourrait baisser un peu, mais la qualité s'améliorera car il y a moins de distraction. En retour, cela réduira le nombre de bogues, d'où un travail ponctuel qui pénètre dans vos projets.

En ce qui concerne la partie planification, je suis entièrement d'accord avec la réponse de Thomas Owens.