Fixer des attentes réalistes en matière de délais

Je suis responsable technique pour une petite équipe. L'une des tâches principales de mon assiette est de communiquer avec le client. Une chose que je trouve particulièrement difficile est de traiter les délais car ils sont mandatés par le client et je ne suis souvent pas consulté.

Habituellement, l'interaction suit le modèle suivant. Le client propose une fonctionnalité qu'il souhaite ajouter, la fonctionnalité X. La fonctionnalité X aurait fière allure dans la version d'application de la semaine prochaine, dans environ 6 jours ouvrables. À ce stade, la demande de fonctionnalité doit passer par l'approbation et il existe fréquemment d'autres dépendances qui doivent être traitées. Finalement, N jours plus tard, la demande de fonctionnalité parvient à mon équipe. Même si la date limite d'origine (qui a été définie par un gestionnaire non développeur) était réalisable, elle ne l'est plus. Mon équipe est blâmée, se sent découragée et il y a une atmosphère générale de défaite , je me sens découragée et vaincue.

De toute évidence, le processus global est rompu. Malheureusement, je ne peux pas faire grand-chose car je ne suis pas en position de pouvoir ici. Mon approche actuelle consiste à rappeler doucement au client notre date de début par rapport à la date limite, la portée de la fonctionnalité, etc. Cela ressemble beaucoup à des excuses.

Avez-vous été dans des situations similaires? Qu'est-ce qui a / n'a pas fonctionné pour vous?

Vous devez vraiment en parler à votre patron et définir des règles de base:

• Un délai n'est pas un délai sauf si vous vous y engagez.
• Une estimation n'est pas une estimation à moins que vous ne la donniez, et alors c'est une "estimation" et non une échéance ferme.

Clean Coder de Robert Martin a un très bon chapitre sur la façon de communiquer ces informations à votre patron. Ce n'est pas de votre faute si l'équipe commerciale prend des engagements impossibles.

Lorsque vous obtenez une nouvelle fonctionnalité, VOUS l'évaluez et utilisez PERT pour avoir une distribution de probabilité. "Je devrais le faire en 4 jours mais cela peut prendre jusqu'à 8 jours". Défend ton territoire. Ne négociez JAMAIS un devis avec un vendeur, vous finirez par vous engager dans l'impossible.

Après quelques itérations, nous espérons que le vendeur en aura marre d'être fait pour avoir l'air d'un imbécile et ajustera le comportement à "Je vérifierai avec l'équipe de développement et verrons quand nous pourrons le faire" plutôt qu'une promesse que vous vous retrouviez rupture.

Avez-vous été dans des situations similaires? Qu'est-ce qui a / n'a pas fonctionné pour vous?

La plupart du temps, ce qui fonctionne, c'est dire la vérité au pouvoir.

Rassemblez les faits. Présentez les faits. Laissez le client apprendre (ou ne pas apprendre) à son propre rythme.

Mon équipe est blâmée, découragée et il y a une atmosphère générale de défaite.

Pourquoi votre équipe est-elle consciente du blâme? Si le client vous contourne et parle directement à l'équipe, vous êtes rendu inefficace et devez comprendre pourquoi.

Votre équipe doit ignorer le "blâme" ou le manque de blâme. Ils doivent simplement créer des logiciels et vous devez simplement communiquer au client ce que vous faites et quand vous le faites.

Le client devrait --- éventuellement --- se développer pour comprendre le processus. Il faut beaucoup de répétitions pour briser les mauvaises habitudes. Une bonne affaire.

J'ai été dans cette situation exacte et ce n'était pas agréable. Cependant, une approche que j'ai faite a été de garder méticuleusement un registre des travaux en cours de développement. Lorsque des tâches se présentent, vous rappelez au client, à la direction ou au chef de projet que d'autres tâches vont glisser car cela est désormais devenu leur priorité (parfois cela peut les faire deviner, puis vous continuez à pousser pour allonger le délai).

Sinon, je suppose que vous devez essayer de continuer à marteler ce ciseau dans le mur de pierre qui est le chef de projet / liaison client / gestion / vendeur qui traite avec le client et accepte ces délais. J'ai souvent martelé le fait que s'ils conviennent que quelque chose prendra 5 jours, alors ils parlent évidemment de développement de 5 jours, ce qui signifie que cela prend 5 jours à partir du moment où vous l'obtenez (pas quand ils raccrochent le téléphone et passent ensuite les deux prochains jours rédiger un mot fantaisie doc).

Cependant, puisque vous êtes le responsable du développement, toute décision comme celle-ci n'est pas pertinente si elle n'est pas consultée avec vous en premier lieu.

Vous devez également essayer de mettre votre équipe à l'abri de tout cela autant que possible. Bien qu'il soit difficile, ils doivent autant que possible être tenus à l'écart de la politique client / gestion. Si ce n'est pas le cas, un martelage supplémentaire de la tête est nécessaire.

En gros, je n'ai pas aimé ça et peu importe à quel point j'ai malmené le processus n'est pas devenu parfait. Cependant, j'ai réussi à améliorer quelque peu les choses.

La seule chose que vous pouvez probablement faire est de parler au client. Décrivez simplement ce qui se passe tel que vous le voyez, décrivez tous les risques, etc. J'avais une situation similaire et j'étais vraiment fou. Même maintenant, quand je suis responsable de toutes les estimations techniques, j'entends souvent - nous voulons que ce soit fait d'ici lundi. Je dis juste - vous ne l'obtiendrez pas, discutons de ce que vous aimeriez avoir exactement lundi, et puis il apparaît souvent que toutes les fonctionnalités critiques sont assez faciles à implémenter et que lundi est absolument parfait. Toutes les autres fonctionnalités sont ensuite planifiées pour des versions ultérieures.

Le problème est que le client connaît surtout la valeur commerciale de la fonctionnalité, mais ne se rend pas compte de sa complexité. Il suffit de discuter et de clarifier. Toujours.

C'est un bon début que vous rappeliez au client que votre date de début est postérieure à la date à laquelle il demande la fonctionnalité. Vous devez également parler à celui qui fait la conversation initiale avec le client pour obtenir des détails sur la fonctionnalité afin qu'il puisse dire au client au moment opportun quel serait le meilleur délai. Puisque vous êtes déjà en communication avec le client, vous pouvez simplement dire "alors qui était-ce dans le département Y qui a accepté ce délai?"

S'ils ne vous laissent pas entrer dans les pourparlers ou s'ils vous disent de vous taire et de respecter les délais qu'ils acceptent, vous pouvez leur rappeler que cela irait mieux pour toute l'entreprise si votre équipe était à l'heure, et la manière pour y parvenir, c'est obtenir votre avis sur les délais.

Corrigez le flux d'informations.

• Si vous êtes censé communiquer avec le client, forcer toutes les parties prenantes du projet (y compris le client) à l' interface directement avec vous, toujours .

Malheureusement, le pouvoir est principalement pris par vous-même plutôt que par les autres.

L'une des tâches principales de mon assiette est de communiquer avec le client. Une chose que je trouve particulièrement difficile est de traiter les délais car ils sont mandatés par le client et je ne suis souvent pas consulté.

Si vous êtes censé être responsable de la communication avec le client, pourquoi n'êtes-vous pas consulté sur la planification (et la budgétisation) afin de pouvoir communiquer ces informations entre les personnes responsables au sein de votre organisation et leurs homologues du côté du client? Je pense que la résolution de ce problème sera un énorme avantage pour vous, votre équipe et votre projet.

Le client propose une fonctionnalité qu'il souhaite ajouter, la fonctionnalité X. La fonctionnalité X aurait fière allure dans la version d'application de la semaine prochaine, dans environ 6 jours ouvrables. À ce stade, la demande de fonctionnalité doit passer par l'approbation et il existe fréquemment d'autres dépendances qui doivent être traitées. Finalement, N jours plus tard, la demande de fonctionnalité parvient à mon équipe. Même si la date limite d'origine (qui a été définie par un gestionnaire non développeur) était réalisable, elle ne l'est plus.

Ce système de planification semble pour le moins étrange.

D'après mes expériences, le client signe pour une version particulière. Ils peuvent soumettre une liste des fonctionnalités et des modifications qu'ils souhaitent et quand ils les souhaitent, puis négocier avec l'équipe qui élabore le logiciel. Ou ils peuvent donner une liste prioritaire de fonctionnalités à l'équipe de développement, et l'équipe de développement fournit des estimations quant au moment où ils peuvent expédier divers ensembles de fonctionnalités. Il existe également d'autres variantes.

Mais une chose que je n'ai jamais vue autorisée est qu'un client puisse changer la version si tard dans le jeu, surtout pas à une semaine d'une version. Cela ne semble pas juste de mettre les concepteurs, les développeurs et les testeurs sous ce genre de pression. Si vous effectuez un développement itératif, s'il s'agit d'une fonctionnalité de haute priorité, assurez-vous simplement de l'ajouter au formulaire de backlog et de le prendre dès que vous le pouvez. Si ce n'est pas une fonctionnalité de haute priorité, ils n'en ont certainement pas besoin pendant cette version et peuvent attendre la prochaine.

Je recommanderais de définir des règles de base adaptées à vos équipes de conception, de développement, de test et de livraison ainsi qu'à votre client en ce qui concerne les blocages, les blocages de code et les livraisons. Mettez-les par écrit, obtenez l'engagement de tous et respectez-le. Si vous bougez une fois, vous devrez vous plier davantage et vous perdrez le contrôle du processus.

Malheureusement, je ne peux pas faire grand-chose car je ne suis pas en position de pouvoir ici.

Vous pourriez ne pas être seul. Mais il semble que vos concepteurs et / ou développeurs et / ou testeurs subissent beaucoup de pression pour respecter les horaires. Vous devriez vous asseoir avec vos supérieurs en équipe et expliquer la situation. Tout d'abord, demandez à votre organisation de s'engager à améliorer le processus, puis travaillez avec le client pour obtenir son adhésion à la façon dont les choses vont fonctionner.

Cela ressemble beaucoup à des excuses.

Lorsque vous commencez à trouver des excuses, il est peut-être temps d'avoir une conversation difficile ou une conversation cruciale . Je recommanderais l'un de ces deux livres. Les lire m'a aidé à améliorer mes compétences en communication, surtout lorsque vous devez faire face à une situation difficile où les tensions sont élevées de tous les côtés.

Pour répondre à certaines des autres réponses.

Malheureusement, le pouvoir est principalement pris par vous-même plutôt que par les autres.

Je ne sais pas où va Andrea . Oui, vous devez corriger le flux d'informations. Mais vous devez travailler avec les PM et le client pour vous assurer que tout le monde sait ce qui a été (je suppose, de toute façon) convenu au début du projet. Si l'arrangement, pour une raison quelconque, ne fonctionne pas, revoyez-le et redistribuez le travail et les rôles aux personnes qui leur conviennent le mieux.

Vous ne prenez pas le pouvoir ou ne combattez pas le pouvoir, mais vous travaillez avec, essayant de l'apprivoiser et de le faire fonctionner pour tout le monde.

Le problème est que le client connaît surtout la valeur commerciale de la fonctionnalité, mais ne se rend pas compte de sa complexité. Il suffit de discuter et de clarifier. Toujours.

Cette citation de loki2302 est à peu près exacte . L'un de vos emplois en tant qu'ingénieur logiciel consiste à vous assurer que les bonnes personnes savent à quel point la tâche est difficile, combien de temps cela prendra et quels types d'options et de risques existent pour faire quelque chose. En tant que principal communicateur de votre équipe, la transmission de ces informations de votre organisation à votre client est, en théorie, votre travail.

Trouvez un forum pour approcher celui qui fixe ces délais. Faites-leur savoir qu'ils peuvent vous consulter et présenter quelque chose de plus réaliste. Les alternatives sont: vous pouvez dire au client que cela ne se produira pas ou ils peuvent le dire au client.

Vous pouvez le présenter comme vous pouvez le faire en X jours après que votre équipe commence à travailler dessus. C'était peut-être la confusion? C'est une erreur honnête à moins qu'elle ne se reproduise encore et encore. Ensuite, c'est juste de la négligence.

Je suppose que votre équipe a respecté ces délais dans le passé.

Malheureusement, c'est endémique dans notre industrie, de nombreuses agences numériques / logicielles ne savent rien du fonctionnement interne ou des exigences de leur entreprise. Beaucoup ne se préoccupent que de l'argent comptant rapide. Comme beaucoup l'ont déjà dit si vous ne fournissez pas les estimations ou les délais, informez la direction. Comment est-il possible de livrer un travail technique par x temps sans estimation d'une personne technique qui est au courant du calendrier de l'équipe de développement.

Si tout le reste échoue, partez.

Donnez au chef de projet / patron / client vos estimations et calendriers réalisables, demandez-lui de confirmer votre plan ou déterminez d'abord ce sur quoi il veut que vous travailliez, puis partez - ne l'engagez pas ou ne le divertissez d'aucune façon.
S'il revient avec un plan de projet qui ne reflète pas vos estimations, renvoyez-le-lui avec une déclaration: «Je ne négocie pas d'estimations». et partez.

Assurez-vous de disposer d'une documentation abondante sur l'ACY. Expliquez clairement à toutes les personnes impliquées que vous conservez ces documents. J'ai envoyé de tels enregistrements par e-mail à mon adresse e-mail personnelle et CC'd mon patron, qui a été très réussi.

Voici une approche qui devrait apparaître comme constructive au lieu de pointer du doigt. Je ne vous accuse pas de cela, je dis simplement que ce n'est pas bien d'avoir une excuse avec quelqu'un d'autre en faute, quelle que soit la vérité de l'accusation.

Après cela, faites un post mortem pour calculer le temps qu'il a fallu pour terminer le projet, ou l'auriez fait si vous l'aviez terminé. Calculez ensuite le nombre d'heures de ressources dont vous disposiez à partir du moment où vous disposiez de suffisamment d'informations et du feu vert pour y travailler. Convertissez ces chiffres en combien de programmeurs supplémentaires il aurait fallu pour respecter le délai.

Maintenant, discutez avec votre patron de la manière suivante:

Nous avions X heures de travail disponibles entre la date de début du projet Y et la date limite Z.
Le projet nécessitait X + C heures de travail pour se terminer.
Des délais d'exécution similaires ont été appliqués à d'autres projets.
Nous aurons besoin de Q programmeurs supplémentaires pour atteindre la capacité nécessaire pour répondre aux attentes.
... bien sûr, si les budgets sont serrés, nous pourrions peut-être travailler avec les chefs de projet pour intégrer plus de temps à leurs estimations afin que nous puissions sous-promettre et sur-livrer (assurez-vous d'utiliser une gestion banale)