Que faire lorsqu'un client a des attentes irréalistes? [fermé]

Je travaille sur un projet depuis six mois sur un site client, car ils nécessitent la confidentialité des données et ne veulent pas que nous travaillions dans notre propre bureau.

Lorsque je me suis présenté seul sur ce site client, on m'a dit que je devais terminer le projet en deux mois.

Étant donné que le client n'est pas une société de logiciels et en raison de diverses politiques, il m'a fallu environ 20 à 25 jours juste pour me donner des droits sur ma machine pour installer des trucs comme Eclipse, Tomcat, etc. Même après le retard dans la configuration de l'environnement, ils s'attendaient toujours à ce que je termine le projet au cours de la même période de deux mois.

Ils ne m'ont pas donné de documents sur les exigences, mais comme je travaille sur le site du client, nous nous réunissions régulièrement pour discuter des exigences.

Après six mois, l'application n'est toujours pas terminée, et tout le monde m'en veut, mais ils ne réalisent pas que nous avons ajouté beaucoup plus de fonctionnalités que celles discutées lors des premières réunions.

J'ai dû refaire beaucoup de choses pendant cette période, par exemple séparer un formulaire en deux sections; quelques semaines plus tard, ils m'ont demandé de fusionner à nouveau les deux formulaires car c'est déroutant, etc.

La portée de l'application augmente chaque jour, mais ils pensent toujours que c'est un projet de deux mois qui a été retardé. Quand je leur ai dit que la portée avait augmenté, ils demandent pourquoi je n'ai pas demandé d'exigences au début.

Je travaille déjà 11-12 heures tous les jours et voyage 3-4 heures, et maintenant ils s'attendent à ce que je vienne aussi le samedi.

Je dois tout faire ici: prendre les exigences, la conception, le code et les tests.

Veuillez me conseiller que faire dans un tel cas?

_{Détails supplémentaires: Nous avions une liste de produits livrables, mais ils y ont ajouté quelques éléments supplémentaires en disant qu'ils étaient également importants. Ils ont également modifié quelques livrables. Ils n'ont même pas leur serveur UAT, ils testent sur ma machine de développement elle-même via son adresse IP.}

C'est un échec de votre manager . Vous, en tant que contractant, n'auriez pas dû être placé dans une situation avec un délai aussi serré par votre entreprise sans un ensemble ferme d'exigences à l'avance, par écrit. Rien de tout cela "ils ont ajouté des fonctionnalités" par la suite un non-sens - chaque fois que cela s'est produit, ils devraient avoir signé un calendrier mis à jour que vous leur avez donné .

Votre responsable, étant donné qu'il prévoit de le rencontrer, doit obtenir du client un ensemble spécifique d'exigences - le projet doit faire A, B, C, D et E. Et après cela, il est terminé. La signature du client doit figurer sur ce document acceptant cette liste. Vous auriez dû avoir ça depuis le début.

Si votre manager ne vous soutient pas et ne vous soutient pas dans ce domaine - et je ne le dis pas très souvent - commencez à chercher un autre emploi. Parce que vous finirez probablement par être le bouc émissaire de tout le bordel. Et si vous êtes prêt à travailler 11 heures par jour et 3 heures de trajet, il est évident que vous êtes une personne très dévouée qui mérite mieux.

L'important dans de telles situations est de créer une trace papier de l'ACY. Rien ne doit être fait sans l'avoir écrit, surtout dans une relation commerciale compliquée. S'en tenir au calendrier initial, bien qu'il leur ait fallu 20 jours pour vous laisser travailler, est un gros drapeau rouge qui va devenir compliqué.

Vous tenez une réunion où des fonctionnalités supplémentaires sont nécessaires? Notez-le par la suite, étiquetez "+ X jours à l'horaire actuel" sur chaque article et envoyez-le à toutes les personnes impliquées. Si vous utilisez uniquement le système de messagerie interne du client, imprimez-le en plus, y compris la liste des destinataires to :, cc: et bcc: et archivez-la soigneusement. En outre, comme l'a dit GrandmasterB, le client doit approuver ces modifications par rapport aux exigences d'origine.

Si le calendrier requis ne peut être respecté, écrivez-le. En cas de changement, écrivez-leur, y compris les conséquences. Etc.

Ce n'est pas pour "je vous l'ai dit". quand le désordre frappe enfin le mur - ils ne l'écouteront pas, de toute façon. Il s'agit de votre assurance lorsque le client vous poursuit parce qu'il pense que vous n'avez pas respecté le contrat ou lorsque votre entreprise poursuit le client parce qu'il refuse le paiement.

D'après ce que vous décrivez, il semble que vous participiez à un projet classique de la Marche de la mort :

Dans la gestion de projet , une marche de la mort est l'un de plusieurs types de projets pathologiques impliquant une analogie dysphémiste et d'humour noir avec de vraies marches de la mort, par exemple, être extrêmement épuisé et (souvent et surtout) être épuisé pour des raisons mal fondées sur un projet qui est manifestement à haut risque de mauvais résultats (c.-à-d. échec du projet, et peut-être une menace d'atteinte à la réputation personnelle et de groupe) . Ainsi, le nom de «marche de la mort» peut être appliqué à un projet qui est finalement couronné de succès, mais implique un tronçon de surcharge de travail insoutenable, ou (peut-être plus souvent) à un projet que tout membre intelligent et informé peut voir est destiné à échouer (ou est risque d'échec très élevé) mais que les membres sont quand même contraints de passer à l'acte par leurs supérieurs ...

Le phénomène est bien connu et il y a beaucoup de littérature sur la façon de procéder - y compris bien sûr le livre séminal d'Edward Yourdon Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Project .

Article de Wikipedia cité ci - dessus fait un bon point de départ pour trouver des informations supplémentaires, de la recherche et des recommandations pour les personnes concernées / intéressé à mars de mort projets.

Marcher dans vos chaussures, la première chose que je considérerais serait de passer une référence à l'article ci-dessus à mon manager.

Cela leur permettrait de savoir que je suis au courant de ce qui se passe, et peut-être même de les aider à me guider en termes de cadre fourni pour cette notion, comme «Regardez, notre état actuel est proche de celui décrit dans le chapitre Xde Yourdon. out, avec un chapitre étroitement lié, Yetc ... "

Dans le cas (peu probable) où le gestionnaire n'est pas au courant de ce domaine d'études, le renvoi pourrait leur donner matière à réflexion en aidant à identifier la situation et à décider comment la gérer.

Honnêtement, s'il vous est possible de le faire, la meilleure solution est d'arrêter. Des situations comme celle-ci sont toxiques pour vous et elles s'améliorent rarement avec le temps, peu importe vos efforts.

Mieux vaut réduire vos pertes et trouver un autre concert. Mais réfléchissez à votre expérience et suivez les conseils d'autres réponses sur ce fil.

C'est un sérieux issue in project management . Il semble que vous Project Managerdevriez travailler sur la liste des livrables et les hiérarchiser avec le client.

Plus important encore , votre PM should discusset convenez avec le client du délai (y compris la conception et l'analyse du problème / solution) dans vos estimations.

La possession clear estimation of your work loadet les éléments livrables du projet vous soulageront du stress, ainsi que la tranquillité d'esprit et la confiance dans votre travail.

Essayez d'utiliser l' approche Agile en livrant vos articles en sprint (2-3 semaines) et en réalisant UAT (test d'acceptation utilisateur) avec le client. N'oubliez pas, faites toujours votre planification de sprint avant de commencer le sprint.

Edit: D'après les commentaires, il est clair qu'il s'agit bien d'un échec de votre chef de projet . Ne pas disposer d'un environnement de test et / ou de développement approprié pour un projet sérieux comme le vôtre est un gros trou pour le projectprocessus SDLC et.

Bien que je convienne qu'il s'agit d'un échec de gestion, c'est également un échec de votre part. À ce stade, il sera très difficile à corriger, donc une partie de ce dont vous avez besoin pour en sortir est de savoir comment gérer les projets futurs.

Tout d'abord, vous devez insister sur un document de référence sur les exigences au début du projet. Il n'est pas nécessaire qu'il soit sophistiqué ou formel, mais vous ne pouvez rien construire avec succès tant que le client n'a pas spécifié ce qui est attendu. Si vous ne l'avez pas par écrit, les chances que le client soit satisfait du résultat final sont d'environ 0%. C'est donc extrêmement important. Il vous appartient également de rechercher les ambiguïtés contenues dans ce document et de les dissiper le plus rapidement possible. Lorsque vous rencontrez l'un de ces éléments et que vous ne savez pas comment l'interpréter, ne devinez pas ce que vous pensez que cela signifie, assurez-vous que vous et le client êtes sur la même longueur d'onde à propos de ce que cela signifie. Oui, cela signifie plus de discussions avec les gens et plus de réunions et moins de codage. Mais il faut beaucoup moins de temps pour effacer une exigence peu claire que pour la coder incorrectement, puis la recoder. De plus, vous devez souvent leur donner le recodage gratuitement et ce n'est pas bon pour l'entreprise pour laquelle vous travaillez.

Ensuite, vous leur dites combien de temps il faut pour faire le travail et cela fixe la date limite. Vous n'acceptez jamais un délai qui est basé sur autre chose que le nombre d'heures qu'il faudra pour faire le travail pour répondre aux exigences. Si vous le faites, vous serez de nouveau dans une marche de la mort. Montrez-leur qu'il n'est pas possible de respecter le délai en ayant une explication détaillée des heures qu'il faudra. Vous ne pouvez pas intégrer 200 heures de temps de développement dans une semaine avec un seul développeur, quel que soit le souhait du client. À ce stade, lorsque la date limite est inamovible, vous demandez quels éléments doivent être déplacés vers la prochaine itération.

N'oubliez pas que le temps de développement n'est qu'une petite partie du temps du projet lors de l'estimation du temps du projet. Vous devez également tenir compte des réunions et des communications par e-mail / téléphone, des tests, du déploiement, de la documentation, de la configuration physique des serveurs, des postes de travail et des logiciels. De plus, lors de la planification de la date limite, vous ne pouvez que supposer que vous disposez de 6 heures par jour et non de 8. Cela tient compte des congés, du deuil, des congés de maladie, des retards inévitables (par exemple, lorsque vous avez dû les attendre pour obtenir des autorisations). sur le réseau, etc.), la formation, les travaux non liés au projet (feuilles de temps, réunions RH, etc.). L'une des principales raisons pour lesquelles les gens ne respectent pas leurs délais est qu'ils font l'hypothèse qu'ils ne feront que du développement et travailleront dur 8 heures chaque jour. Ce n'est tout simplement pas une hypothèse réaliste.

Et chaque fois qu'ils ajoutent une autre pièce, vous leur dites combien de temps cela prendra et combien le travail supplémentaire fera avancer la date limite. Vous ne demandez pas de déplacer la date limite, vous leur dites que cela bouge en raison de la nouvelle exigence. Maintenant, vous devriez passer par votre gestionnaire pour cela, mais c'est d'abord votre responsabilité de vous assurer que votre gestionnaire sait à chaque fois que l'exigence est modifiée et combien cela ajoutera au projet. Assurez-vous que tout cela est écrit, afin que vous puissiez vous défendre si besoin est.

Ensuite, ne vous laissez pas abuser par des journées et des week-ends de 11 heures. C'est correct en petites poussées (de moins d'une semaine tous les six mois environ), mais à long terme, cela n'est tout simplement pas acceptable. Les gens fatigués codent plus lentement et font plus d'erreurs. Vous pouvez en faire plus avec une meilleure qualité en travaillant régulièrement 8 heures que régulièrement 11 heures. et les week-ends.

J'ai trouvé que les diagrammes de Gantt peuvent être très bons dans ce genre de situations. Ils peuvent illustrer aux clients le calendrier actuel et peuvent être utiles pour illustrer l'effet de l'ajout de nouvelles fonctionnalités / modifications. Parfois, dire à un client que la fonctionnalité x affectera la livraison d'ici y jours ne s'enregistre pas auprès d'eux. En l'ayant clairement sur un graphique, ils peuvent mieux le comprendre.

Idéalement, cela devrait être fait dès le début du projet. Il pourrait ne pas être aussi utile d'expliquer les « retards » jusqu'à présent, mais pourrait aider à faire avancer le projet.

De Wiki :

Les diagrammes de Gantt illustrent les dates de début et de fin des éléments terminaux et des éléments récapitulatifs d'un projet.