Chef de projet qui souhaite verrouiller une estimation de temps avec un contrat signé

Lors d'un emploi précédent, un chef de projet (PM) n'était pas satisfait du délai de livraison du code pour un projet sur lequel j'étais. Mon responsable de projet m'a dit que le Premier ministre envisageait de me faire signer un contrat pour consigner dans le temps que j'avais prévu le temps que j'avais donné pour les tâches et les dates de livraison.

La situation du projet était que nous travaillions avec de nouvelles technologies, une base de code, des normes de codage et des exigences très sujettes à changement. J'apprenais de nouvelles choses et les appliquais du mieux que je pouvais à des exigences qui changeaient constamment. Les besoins au fil des itérations ont été multipliés par 2 à 3, et mon estimation du total à compléter par environ 5 à 8 fois. Les seules choses qui n'ont pas changé sont les estimations et les dates de livraison.

Oui, j'ai manqué la plupart des délais. Et je travaillais sur de très nouvelles technologies que personne au sein de l’équipe de développement ne pourrait vraiment aider, car elles ne le connaissaient pas. Du moins pas facilement.

Il me semblait alors que le Premier ministre voulait que ses chiffres s’additionnent - et donc que je signe un contrat pour "s’assurer" que je livrerais toujours le code de travail à temps. Je suppose qu'avec un contrat signé, le premier ministre pourrait l'utiliser contre moi si je ne pouvais pas livrer à temps.

Je crois que ce qui est arrivé ensuite, c’est que d’autres chefs de projet et / ou chefs de projet m'ont défendu et n’ont pas laissé cela se produire.

Ma question est la suivante: cela devrait-il lever le drapeau rouge à propos du manager? Est-ce une pratique courante pour un gestionnaire de mémoriser les estimations de temps d'un développeur de logiciel avec un contrat signé? Ou dans ce cas, essayez de.

Veuillez noter que j'étais un employé à temps plein et non un consultant indépendant.

Mise à jour : je tiens à ajouter que j’ai présenté de nouvelles estimations chaque semaine, mais il semble que les estimations et les dates de livraison initiales étaient celles sur lesquelles le PM était fixé.

Ma question est la suivante: cela devrait-il déclencher un drapeau rouge à propos du manager?

Oui . Cela signifie qu'il est temps pour vous de mettre votre CV à jour et de commencer à chercher un nouvel emploi. Ou bien cela signifie que votre manager est sur le point de commencer à jouer à des jeux très méchants avec vous.

Est-ce une pratique courante pour un gestionnaire de mémoriser les estimations de temps d'un développeur de logiciel avec un contrat signé?

Je n'ai jamais entendu parler de cela s'appliquant à un employé.

L'estimation du temps et des efforts est toujours difficile. Surtout que notre profession est pleine d'optimisme excessif. Certains systèmes d'estimation pourraient vous aider à l'avenir, mais ils ont besoin de collecter des statistiques historiques de votre part. L'un est la PSP . Un autre est les points de fonction . De nombreux développeurs n’apprécient ni l’un ni l’autre, et vous trouverez des opinions très fortes contre les deux.

La difficulté principale dans l'estimation du temps et des efforts est le manque de retour d'informations dans nos méthodes heuristiques d'estimation. L'une des clés est d'écrire ce que vous pensez être l'estimation et les paramètres que vous avez utilisés pour l'estimation. Ensuite, en fonction de ce que vous avez réellement accompli, comparez cela avec ce que vous pensiez faire. Et utilisez-le pour modifier vos paramètres d’estimation. En ingénierie, nous appelons cela " feedback ".

Oui, cela devrait absolument sonner l'alarme.

Si j'avais été en poste, pour mon divertissement personnel, j'aurais demandé au gestionnaire de signer un contrat gelant toutes les exigences. J'imagine que le directeur serait susceptible de caution. Ensuite, je partirais.

Eh bien c'est simple. Dites simplement à votre responsable que vous vous connecterez pour verrouiller votre estimation de temps lorsqu'il signera pour verrouiller la spécification. Parce que vous ne pouvez pas, à coup sûr, fournir des estimations pour quelque chose d'inconnu. Spécifications du projet complètes avant de commencer, pas de modifications - et vous pouvez les terminer à temps :)

Un changement à spec => contrat est nul. La chose sera probablement annulée juste après 10 minutes le premier jour :)

Oui, c'est un drapeau rouge. Cela vous dit que le responsable ne comprend pas comment gérer les risques dans les projets logiciels. Ce qu'il devrait faire, c'est déterminer la cause exacte du retard, puis commencer à mettre en place un processus permettant de gérer efficacement les risques de calendrier qui se produiront inévitablement au cours d'un projet de logiciel.

Je ne signerais JAMAIS, en aucune circonstance, un contrat avec mon responsable garantissant un emploi du temps. D'autres ont indiqué l'avoir fait signer un cahier des charges. Ceci à mon avis n'est pas suffisant. Cela ne rend pas compte des difficultés imprévues liées aux outils ou à la technologie, des conceptions incomplètes ou médiocres, des performances des autres membres de l’équipe, etc.

Ce n’est pas un drapeau rouge, c’est une stupidité de niveau militaire.

Si les estimations et les délais sont systématiquement dépassés, il est rationnel d'identifier les causes et d'améliorer les processus.

Si vous blâmez et tuez le cheval parce que vous ne savez pas où vous allez, ne soyez pas surpris si le cheval vous mord et se sauve!

Alors que le directeur était en décalage avec sa demande. Il n'est pas entièrement à blâmer. Si vous travailliez dans un territoire totalement inconnu, rien ne vous empêche de dire «je ne sais pas». Il m'a fallu un certain temps pour comprendre que "je ne sais pas" est une réponse parfaitement acceptable. Je sais donc à quel point il est pénible de prononcer ces mots. Mais si vous ne savez vraiment pas, c'est la solution. Et s’ils hésitent à le faire, demandez-leur de vous donner une estimation du nombre de sous qu’il faudra pour constituer une pile aussi haute que la tour Sears (make it Willis). Et seraient-ils disposés à signer un contrat vous payant chaque centime dépensé?

Tout chef de projet digne de ce salaire devrait savoir que certaines choses ne vont pas bien dans un tableur. Parfois, les choses sont faites quand elles sont finies. Je pense que vous vous en tirez bien en faisant des progrès sur vos progrès. Arrêtez simplement de donner le nombre de mises à jour.

Un autre exercice consiste à décomposer la tâche importante en unités plus petites et plus estimables. Cet exercice vous aidera à mieux comprendre ce que vous devez faire. Consultez Software Estimation de Steve McConnell et Patterns des exigences logicielles de Stephen Withall pour des conseils sur la répartition des tâches et la découverte d'exigences cachées, respectivement.

Ne tirez pas de la hanche sur une estimation. Prenez le temps de le décomposer. L'estimation d'un grand nombre de petites tâches vous donnera une meilleure estimation globale (en raison de la loi des moyennes, certaines de vos estimations seront sous-estimées mais d'autres seront terminées et auront tendance à se peser les unes les autres) de la grosse tâche.

Demandez à votre "chef de projet": vendons-nous des logiciels ou des délais?

Je suis chef de projet et programmeur :-) Je pourrais parler longuement du fait que la plupart des chefs de projet ne sont pas de l'industrie et ne peuvent pas gérer tout ce qui ne correspond pas à un modèle de chaîne de production ... mais je ne sera pas, pas ici. Au lieu de cela, voici une longue polémique sur ce qu’il faut réellement faire (M. Mod, s’il est trop long, faites ce que vous voulez avec). Je suis d'accord avec les commentaires déjà formulés ici, certains que vous devriez faire avant d'autres, mais voici ce qui, à mon avis, aurait été votre meilleur geste . Oh, et la réponse évidente à votre question est oui, mais cela est détaillé dans un langage coloré et détaillé ci-dessous.

Avant de commencer, sachez que le premier ministre vous chagrine probablement, car un autre acteur plus haut dans la chaîne alimentaire leur en donne. Ce sont (nous) des créatures simples ... Il existe des moyens d'éviter la situation que vous avez décrite - Mike Brown couvre cela très bien. Il n’ya également rien de mal à travailler quelque chose pendant 3/4/5 .. heures de travail avant de commencer (en fait, toutes sortes d’alarmes doivent être déclenchées si cela ne se produit pas). Et si vous vous dirigez vers un territoire inconnu, repoussez-vous et demandez une semaine de recherche sur le secteur et les technologies pour pouvoir faire une estimation raisonnable (vous voudrez le faire correctement, car vous voulez de nouvelles technologies pour apprendre et jouer avec d est-ce pas?) Si votre PM et la direction de l'endroit où vous vous trouvez ne comprennent pas cela ... mettez à jour votre CV et recherchez la sortie la plus proche, les laissant au sort qu’ils méritent si richement. Que le Premier ministre pense même à faire signer un contrat de ce type à un employé à temps plein est un mauvais signe ... la seule façon pour moi de voir qu'ilsn’est peut- être pas totalement incompétent, c’est qu’ils ne faisaient en fait que des jeux d’esprit avec votre chef de projet et vous (selon ce que j’ai lu, ils ne vous ont pas directement expliqué cela et n’ont finalement pas donné suite à la menace). Le PMing est un refuge pour votre psychopathe d'entreprise standard après tout. C’était bien que d’autres aient eu raison de ce que vous avez dit, alors le conseil ci-dessous aurait probablement été positif pour vous à la fin. J'imagine qu'ils auraient eu une révolution entre leurs mains si cela s'avérait être plus que du discours.

Donc, à la situation / trou que vous avez décrit , parce que cela va se reproduire, quelque part (comme il y a environ 5 minutes et à nouveau dans 5 minutes, scheduleRepeat ()). Probablement sans la stupidité du contrat, mais le scénario de base est toujours le même. Organisez une réunion (!), Ils aiment les réunions ;-) tout le monde peut se féliciter à la fin, comme si quelque chose avait été fait. IMPORTANT:Assurez-vous d'inclure votre chef de projet technique / chef d'équipe / architecte / responsable de la conception dans l'invitation à la réunion après avoir déjà traité du problème avec eux et les avoir intégrés. Plus haut dans la hiérarchie, vous pourrez aller chercher quelqu'un de votre "côté", mieux ce sera. Parce que votre PM va le voir et essayer d’associer votre responsable de la conception à un équivalent. Sinon, ils sont stupides et vous avez déjà gagné. En soi, cela les ramènera dans la ligne, car ils sont maintenant visibles par quelqu'un qui peut probablement les renvoyer sur-le-champ. S'ils jouent à des jeux avec vous, vous êtes autorisé à rendre la faveur.

Lors de la réunion, passez en revue les détails techniques de votre problématique et expliquez pourquoi cela prend du temps. Ils devraient vouloir le savoir (et comment ils peuvent vous aider à le faire), mais la triste réalité est généralement que cela ne se produit pas… vous aurez probablement 10 minutes avant que leurs yeux ne reviennent dans leurs têtes. Maintenant, ce que je voudrais faire ici n’est probablement pas légal… Oui, j’ai vérifié, c’est très illégal, et vous ne voulez pas aller en prison aussi longtemps. Le fait est que vous avez fait de votre mieux pour être proactif et que si vous avez des supérieurs hiérarchiques, votre douleur leur appartient maintenant ... comme il se doit. Vous devrez utiliser votre jugement sur la manière dont les choses vont probablement se dérouler, car c'est l'escalade qui se produira. Si la direction à l'endroit où vous vous trouvez est à moitié décente, ils feront ce qu'il faut, et faire la bonne chose par vous aussi. Sinon, votre CV serait déjà disponible sur le marché… vous alliez quand même partir à la première occasion (et vous ressemblez finalement). La direction se divisera en deux groupes - soit ils sont techniquement avisés et ils verront instantanément votre point de vue. ou ils ne le sont pas et que vont-ils faire à ce sujet si ce n’est le sourire aux lèvres et le supporter? S'ils pouvaient faire ce que vous faites, ils le feraient déjà. t et que vont-ils faire à ce sujet si ce n’est un sourire et le supporter? S'ils pouvaient faire ce que vous faites, ils le feraient déjà. t et que vont-ils faire à ce sujet si ce n’est un sourire et le supporter? S'ils pouvaient faire ce que vous faites, ils le feraient déjà.

Conservez la question des exigences changeantes comme atout à utiliser à la fin… elle servira de prétexte pour tout le monde. Le projet lui-même et le foutu client / intervenant auront leur nom pris en vain. Le moyen le plus simple d’aller de l’avant serait une sorte de réinitialisation du projet, et peut-être que ce PM serait réaffecté discrètement à un autre domaine. Les miracles se produisent de temps en temps. Si la question du contrat a été soulevée lors de la réunion par le Premier ministre, vous devez répondre aux exigences de gel de la demande de contre-contrat; jouer à ce genre de jeux d'esprit.

Avant de signer: modification du périmètre / des exigences - l’une des meilleures raisons d’adopter la méthode Agile afin que les clients / parties prenantes aient la responsabilité de changer d’avis quant à ce qu’ils souhaitent ...

Oh, encore une chose: dans la déclaration «je ne sais pas», j’ai toujours été ma référence personnelle sur la façon de jauger la valeur d’un collègue technologue ou d’un membre de l’une de mes équipes de projet. Je trouve que les seules personnes qui sont en mesure de dire que ce sont les meilleures qui soient, les meilleures qui soient, principalement parce que quelqu'un qui sait qu'elles sont trop profondes ne diront jamais cela - les ouvre à être clairement exposées par une personne ayant des capacités réelles un battement de coeur. D'autre part, quelqu'un qui le dira et le dira aura également un plan de base (même si rien n'a été pensé) sur la manière de s'attaquer aux inconnus afin qu'une réponse plus utile soit disponible dans les 24 heures, et dans une semaine, une situation encore meilleure. Quand Apollo 13 volait autour du côté obscur de la Lune, il se passait toute une série de "Je ne sais pas".

Oui, cela devrait déclencher un drapeau rouge, surtout si vous êtes un employé à temps plein. Quelles étaient les conditions du contrat? Seriez-vous réellement viré si vous n'aviez pas respecté les délais? Ou voudriez-vous juste manquer un bonus? Que feraient-ils?

Le problème que cela soulève est que le responsable n’a aucune idée de la façon de gérer un projet traitant de technologies nouvelles / inconnues et d’exigences changeantes qui affectent directement l’effort estimé. Bien que des délais difficiles soient parfois imposés, un responsable connaissant la situation ne devrait pas chercher à faire signer aux employés des contrats pour les faire respecter. Les nuits tardives et les périodes difficiles seront mauvaises, mais c’est probablement tout à fait normal. Et encore parfois, le délai va glisser. Cela arrive, et comme l’a signalé quelqu'un d’autre chose, le seul moyen de respecter le calendrier est de geler les exigences EARLY ON afin d’avoir suffisamment d’espace pour conserver la chronologie.

D'après ce que vous avez dit, les sonnettes d'alarme se font attendre quelques mois trop tard. Il est normalement risqué de baser un projet à durée limitée sur des technologies avec lesquelles le personnel n'est pas déjà familiarisé. Il est imprudent de le faire si vous ne maîtrisez pas la collecte des exigences et la gestion de l'étendue.

Cela dit, je suis d’accord avec les autres réponses. En outre, vous voudrez peut-être mettre à jour votre CV si vous ne l'avez pas déjà fait.

Comme tous les autres répondants, je suis tout à fait d'accord pour dire que cela devrait donner un signal d'alarme.

Il semble que le Premier ministre ne veuille pas participer au processus de développement.

Dans ma pratique personnelle, je me suis longtemps éloigné des spécifications détaillées initiales, des approbations, des estimations de projet complètes ou de la tarification des offres fixes (du point de vue du conseil).

La raison en est la prise de conscience, dont parlent beaucoup de gourous en logiciels Agile et Lean, que le logiciel n'est pas une entité pouvant être fabriquée, mais qu'il s'agit principalement d'un processus de découverte.

Beaucoup de gens ont encore des problèmes avec cette notion, et il semble que votre premier ministre aussi. Cela se résume à une compréhension simple des compromis.

Les spécifications initiales rigides et les estimations fixes fonctionnent pour les systèmes où le coût du changement est élevé. Comme construire une tour. Si vous avez oublié de spécifier les cages d'ascenseur à l'avance, il sera très difficile de rénover le bâtiment une fois qu'il aura été construit. Le coût élevé du changement nécessite beaucoup de planification, d’apprentissage des inconnues des composants et des technologies et d’expérimentation. Une fois que vous avez terminé tous vos devoirs, vous pouvez estimer votre budget et vos coûts.

Dans le secteur des logiciels, les gens se sont habitués à l’idée que le coût du changement est peu coûteux. Ils aiment donc pouvoir changer les choses une fois qu’ils voient une version, incorporent une nouvelle compréhension de l’application, de l’entreprise, du client. une base continue. Tout cela est bon et représente une énorme opportunité s’il est utilisé correctement. La plupart des informaticiens que j'ai rencontrés et avec qui je travaille n’apprécient en réalité pas beaucoup de temps consacré à la planification ou aux enquêtes; la plupart d'entre nous (y compris les chefs de projet) voulons voir une traction continue. C’est de là que vient le développement itératif avec ses petites versions incrémentielles de fonctionnalités. D'autres pratiques peuvent être utilisées, telles que le développement piloté par des tests pour garantir que le coût du changement reste bas et que la dette technique soit maîtrisée.

Faire ce travail implique un "contrat" ​​entre les deux parties, le propriétaire du produit (Agile parle pour votre PM, vos clients ou l'équipe d'assurance qualité) et les développeurs. Les développeurs acceptent de ne travailler que sur les éléments jugés prioritaires pour l'itération donnée et de ne pas prendre pour toujours avec cela, mais s'efforcent de proposer fréquemment des fonctionnalités totalement intégrées (par exemple, une fois par semaine ou par mois). À l’inverse, les propriétaires de produit acceptent d’examiner en permanence les nouvelles versions et de fournir un retour rapide. Ils conviennent également de définir les priorités pour la prochaine itération et, une fois, de ne pas changer d'avis pendant la durée de l'itération.

Cette dernière partie de l'accord est quelque chose que votre Premier ministre ne comprend probablement pas. Beaucoup de PM traditionnels ne le font pas. Certains pensent que leur travail est terminé lorsqu'ils déposent les spécifications. ils ne veulent pas entendre parler de problèmes, d'alternatives, de meilleures solutions, etc. L'inconvénient est qu'il s'agit non seulement de contrecarrer le flux de développement de logiciels, mais également de nuire à l'organisation en laissant beaucoup d'opportunités.

Jetez un coup d’œil au Manifeste Agile: http://agilemanifesto.org/ Il pourrait vous intéresser. Le livre "Lean Software Development" de Mary Poppendieck est un bon livre à lire.

Bonne chance.

On dirait que le directeur cherche quelqu'un à blâmer quand il rend compte à son supérieur.

Je trouve que si vous avez un gestionnaire déraisonnable qui pense qu'une "estimation" est identique à une "période fixe", la meilleure chose à faire est de penser à une période d'estimation très généreuse et de la doubler!

De plus, forcez le responsable à s’assurer que les exigences sont complètement détaillées et fixes. Toute modification à partir de ce moment-là ne sera pas traitée sans une "renégociation formelle" avec le chef de projet de la nouvelle heure d'achèvement.

Finalement, le chef de projet comprend l’idée et planifie en conséquence.

Mon expérience personnelle avec ce genre de chose est que le chef de projet essaie de créer une trace écrite pour vous débarrasser de vous, tout en faisant de votre cessation votre faute. Cela en ferait un drapeau très rouge. Votre kilométrage peut bien sûr varier quelque peu.

Bonnes réponses tout autour, mais laissez-moi ajouter mes 2 centimes.

Si vous étudiez la probabilité, il existe une "variable aléatoire". C'est un nombre dont vous ne connaissez pas la valeur, mais vous pouvez décrire votre non-connaissance avec une distribution, comme une distribution normale (courbe en cloche) ou une autre.

Le fait est que le travail prendra un certain temps, mais toute estimation préalable sera fausse, légèrement ou beaucoup, du côté négatif ou positif, de sorte qu'il y a un risque et que quelqu'un doit prendre le risque. Généralement, si les gens prennent des risques, ils sont payés pour cela. L'assurance coûte de l'argent.

Quand j'étais consultant, j'avais généralement le choix de signer un contrat temps / matériel plutôt qu'un contrat à prix fixe. Avec le temps et les matériaux, le client assume le risque. Au forfait, je supporte le risque. Avec le prix fixe, je crée une marge de sécurité, car si je ne parviens pas à atteindre mon objectif, personne ne gagne.

Vous demander de vous engager à respecter une date de livraison fixe, en particulier si aucune exigence n’est définie, vous donne l’impression de vouloir vous transférer le risque, même s’il n’est pas certain de ce que vous risquez. Dans tous les cas, une réponse consiste simplement à ménager une marge de sécurité vraiment généreuse.

PS Vous voyez cela tout le temps avec les contrats du gouvernement. Il y a une première demande de propositions, des offres sont faites, une offre basse est acceptée, puis les demandes de modification commencent à arriver, de sorte que les coûts montent en flèche et que l'entrepreneur soit blâmé. Les choses fonctionnent beaucoup mieux s'il existe une relation de travail d'équipe entre le client et l'entrepreneur, plutôt qu'une relation conflictuelle.

Oui, bien sûr, cela met en lumière l'expérience et la compétence de votre ancien patron. Oui, comme la plupart des gens l'ont suggéré, ce serait un bon moment pour mettre à jour votre CV.

Oui, comme l’indiquent les autres réponses, dans la plupart des situations, vous ne voudriez pas signer cet accord. Cependant, je tiens à suggérer que dans certaines situations, vous pourriez envisager de le signer.

La plupart des développeurs et des gestionnaires sont conscients de la friction constante entre la fonctionnalité, les délais et le budget. Beaucoup ont également proposé la qualité en tant que quatrième dimension ("Je peux répondre à toutes les exigences de votre choix, à partir de demain, pour un budget réduit, aussi longtemps que vous êtes prêt à accepter que cela ne fonctionne pas!")

Mais il y a encore une autre dimension: le risque. Si je n'ai besoin que de livrer avec succès 50% du temps, je peux abaisser mes estimations énormément; ils sont rembourrés pour gérer un taux de livraison beaucoup plus élevé.

Nous pouvons traiter les risques de différentes manières (les estimations de remplissage sont l’une d’elles). Le gestionnaire ne veut accepter aucun risque et veut le mettre sur vos épaules. Normalement, vous devriez refuser un tel mouvement ... sauf si vous êtes bien récompensé.

Si vous êtes en mesure de fixer votre échéance, avec une quantité de rembourrage mutuellement acceptable pour faire face aux retards inattendus, et êtes en mesure de négocier un bonus (très important) si vous le respectez, et si vous êtes financièrement en mesure de le gérer. Si vous ne le pouvez pas, vous pouvez être amené à accepter ce risque et à signer le contrat, avec des clauses appropriées permettant de gérer les modifications des exigences.

C'est une bêtise directe. Je ne sais pas quel était l'objectif ultime, mais chaque chef de projet à la moitié décent, responsable des produits logiciels, devrait savoir que les estimations sont exactement comme elles s'appellent: estimations. Ce ne sont pas des promesses et elles ne peuvent être faites sans soit épuiser toute l’énergie du développeur de logiciels ou les obliger à rompre leur "promesse" de toute façon.

Si vous voulez montrer à quel point un tel contrat est ridicule, voici deux suggestions:

a) Très surestimé au point que le projet prenne cinq à dix fois plus longtemps que prévu sans contrat. Si le chef de projet demande pourquoi les estimations sont si élevées, dites simplement que vous vous assurez simplement que vous pouvez remplir votre contrat.

b) Cela a déjà été suggéré: demandez un contrat qui garantit qu'aucune exigence ne change et assurez-vous que cela inclut la correction des fautes d'orthographe. D'après mon expérience, il n'y a pas un seul projet logiciel où les exigences ne changent pas au cours du développement. Le chef de projet est plus susceptible que vous de devoir rompre son contrat.

Si le chef de projet accepte l'une de ces deux suggestions, vous saurez à coup sûr qu'elles sont hors de propos.

Au fait, comment un contrat pour un employé à temps plein pourrait-il fonctionner? Je ne connais pas la réglementation du travail dans d'autres pays, mais en tant qu'employé à temps plein dans une entreprise, je ne pense pas que quiconque puisse vous forcer à signer un contrat contraignant pour respecter un délai et avoir un cas valable. Bien sûr, ils pourraient vous donner l'enfer si vous ne respectez pas les délais, mais ils n'ont pas besoin d'un contrat pour cela. Personne ne pourrait te virer ou te donner moins d'argent. Ils pourraient réduire votre bonus convenu au pire. Ainsi, à moins que cela ne soit différent dans d'autres pays, cela semble davantage être une menace vide que tout ce que vous devriez prendre au sérieux.

Je vais aller à contre-courant ici.

La situation que vous décrivez n’est pas si inhabituelle au niveau de l’ équipe d’ ingénierie , en particulier après un projet / une publication particulièrement tardif. Dans de nombreuses situations, votre direction et l'ensemble de votre organisation peuvent en fait s'être inscrits pour une date de publication particulière, et d'autres parties de l'organisation seront préparées pour cette date. Votre chaîne de gestion peut être soumise à une pression énorme pour arriver à cette date.

C'est là qu'intervient un processus général d'ingénierie. Vous avez probablement entendu parler du modèle de cascade. Il existe d' autres modèles, mais l'objectif final de chacun d'eux est d'offrir toujours quelque chose quand il est prévu et contenant ce qui a été convenu. Les spécifications fonctionnelles, les conceptions, les listes de tâches, etc. contribuent à en faire un processus prévisible. La communication, l'analyse des risques et (comme vous l'avez dit) la mise à jour régulière des attentes en matière de planning réduisent les surprises et mettent les informations à disposition le plus rapidement possible afin d'ajuster les plans. Et oui, il devrait y avoir des ajustements au plan chaque fois que des fonctionnalités sont ajoutées ou supprimées.

Dans certaines des équipes avec lesquelles j'ai travaillé, je n'hésiterais pas à considérer mes estimations comme des engagements signés, mais cela reflète la qualité des équipes et de la direction, et non une compétence particulière en matière d'estimation. Une équipe disposée à signer un contrat pour une livraison à temps est un indicateur du bon fonctionnement d'une équipe et non un drapeau rouge.

Je dis: mets-toi à sa place et essaie de comprendre ce qui a motivé cela. Les futurs gestionnaires / comptables ont besoin d’un numéro pour justifier ce qui se passe et comment les choses se passent.

Peut-être qu'être ridiculisé dans la salle du conseil d'administration pour changer les délais, manquer trop de délais, il a essayé le moyen le plus simple de les verrouiller. Donnez-moi un numéro et signez ici! Si vous étiez à l’autre bout, vous auriez seulement pu percevoir que c’était quelque chose contre vous. Cependant, il est plus utile pour lui de faire des estimations et de réaliser qu'il est nécessaire de les ajuster. Si vous comprenez ce qui a motivé la demande et quel est le véritable problème auquel il est confronté, vous pourrez peut-être l’aider et l’aider vous-même. En tant que programmeurs, nous résolvons les problèmes. Ce n'est pas différent, comprendre et résoudre son problème et il sera votre meilleur ami. Il y a tellement de travail à faire que personne n'a le temps de préparer une vendetta personnelle! Il a besoin d'aide pour son travail. La solution la plus simple était de faire signer un papier à quelqu'un! Il a probablement obtenu cela dans un livre de la direction pour les nuls: "Faites signer vos travailleurs et soyez responsable de l'aide pour un numéro". Drôle mais triste

"Marcher sur l'eau et développer un logiciel à partir d'une spécification sont faciles si les deux sont gelés."

-Edward V. Bérard

Si vos besoins changent, il n’est pas raisonnable de s’attendre à ce que vos estimations initiales soient exactes. Oui, cela devrait être un drapeau rouge.

Le contrat spécifie-t-il une pénalité pour ne pas respecter l'échéance? Si ce n'est pas le cas, ce n'est pas un problème du tout. Vous vous contentez de signer une estimation en fonction de vos connaissances à l'époque.