Chef de projet qui veut verrouiller l'estimation du 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 sur un projet sur lequel j'étais. Mon chef de projet m'a dit que le PM envisageait de me faire signer un contrat pour verrouiller mes estimations de temps J'ai donné pour les tâches et les dates de livraison.
La situation sur le projet était que nous travaillions avec de nouvelles technologies, une base de code, des normes de codage et des exigences très susceptibles de changer. J'apprenais de nouvelles choses et les appliquais du mieux que je pouvais sur des exigences qui ne cessaient de changer. Les exigences tout au long des itérations ont augmenté de 2 à 3 fois, et mon estimation de la fin a augmenté d'environ 5 à 8 fois. Les seules choses qui n'ont pas changé sont les estimations et les dates de livraison.
Oui, j'ai fini par manquer la plupart des délais. Et je travaillais sur des technologies très nouvelles sur lesquelles personne d'autre de toute l'équipe de développement ne pouvait vraiment aider car ils ne le connaissaient pas. Du moins pas facilement.
Il me semblait alors que le PM voulait que ses chiffres s'additionnent - et voulait donc que je signe un contrat pour "m'assurer" que je livrerais toujours le code de travail à temps. Je suppose avec un contrat signé, le PM pourrait l'utiliser contre moi si je ne pouvais pas livrer à temps.
Je crois que ce qui s'est passé 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, cela devrait-il déclencher un signal d'alarme concernant le gestionnaire? Est-ce une pratique courante pour un gestionnaire de verrouiller les estimations de temps d'un développeur de logiciels avec un contrat signé? Ou dans ce cas, essayez de le faire.
Veuillez noter que j'étais un employé à temps plein, pas un consultant indépendant.
Mise à jour: Je veux ajouter que j'ai donné de nouvelles estimations chaque semaine, mais il semble que les estimations estimations et dates de livraison originales étaient ce que le PM a été fixé sur.
Ma question est, est-ce que cela devrait déclencher un drapeau rouge sur le manager?
Oui . Cela signifie qu'il est temps pour vous de mettre à jour votre CV/CV et de commencer à chercher un nouvel emploi. Ou cela signifie que votre manager est sur le point de commencer à jouer avec vous jeux très méchants .
Est-il courant qu'un gestionnaire bloque les estimations de temps d'un développeur de logiciels avec un contrat signé?
Je n'ai jamais entendu parler de cette application à un employé.
L'estimation du temps et des efforts est toujours difficile. D'autant plus que notre métier est plein d'optimisme excessif. Il existe certains systèmes d'estimation qui pourraient aider à effectuer des estimations à l'avenir, mais ils nécessitent de collecter des statistiques historiques de vous-même. L'un est PSP . Un autre est Points de fonction . De nombreux développeurs n'aiment ni l'un ni l'autre, et vous trouverez des opinions très fortes contre les deux.
La principale difficulté pour estimer le temps et l'effort est le manque de rétroaction dans nos heuristiques d'estimation. L'une des clés consiste à noter ce que vous pensez de l'estimation et les paramètres que vous avez utilisés pour l'estimer. Ensuite, en fonction de ce que vous faites réellement, 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 position, pour mon divertissement personnel, j'aurais demandé au directeur de signer un contrat gelant toutes les exigences. J'imagine que le directeur serait probablement en liberté sous caution. Alors je partirais.
Eh bien, c'est simple. Dites simplement à votre responsable que vous signerez pour verrouiller votre estimation de temps lorsqu'il signera pour verrouiller la spécification. Parce que vous ne pouvez pas, assurez-vous de fournir des estimations pour quelque chose qui est inconnu. Spécifications complètes du projet avant de commencer, aucun changement - et vous pouvez le 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. Ce qu'il vous dit, c'est que le gestionnaire 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 à instrumenter un processus pour gérer efficacement les risques de planification qui se produiront inévitablement pendant un projet logiciel.
En aucun cas je ne signerais de contrat avec mon manager garantissant un planning. D'autres ont mentionné qu'il avait signé un cadenas sur les spécifications. À mon avis, cela ne suffit pas. Cela ne tient pas compte des difficultés imprévues avec les outils ou la technologie, les conceptions incomplètes ou médiocres, les performances des autres membres de l'équipe, etc.
Ce n'est pas un drapeau rouge, c'est de la stupidité de niveau militaire.
Si les estimations et les délais sont systématiquement dépassés, la chose rationnelle à faire est d'identifier les causes et d'améliorer les processus.
Si vous blâmez et donnez un coup de pied au cheval parce que vous ne savez pas où vous allez, ne soyez pas surpris si le cheval vous mord et s'enfuit!
Alors que le manager n'était pas en ligne avec sa demande. Il n'est pas entièrement à blâmer. Si vous travailliez dans un territoire totalement inconnu, il n'y a rien de mal à dire "je ne sais pas". Il m'a fallu un certain temps pour réaliser que "je ne sais pas" est une réponse parfaitement acceptable, donc je sais combien ça pique de prononcer ces mots. Mais si vous ne savez vraiment pas, c'est la réponse. Et s'ils refusent, demandez-leur de vous donner une estimation du nombre de pièces qu'il faudra pour faire une pile aussi haute que la tour Sears (faites-en Willis). Et seraient-ils prêts à signer un contrat qui vous paierait chaque centime qu'ils ont perdu?
Tout chef de projet qui vaut son salaire doit savoir que certaines choses ne correspondent pas à Nice et jolies dans une feuille de calcul. Parfois, les choses se font quand elles sont terminées. Je pense que vous vous débrouillez bien en indiquant les progrès réalisés. Arrêtez simplement de donner les mises à jour du numéro.
Un autre exercice consiste à décomposer la tâche importante en unités plus petites et plus estimables. Cet exercice vous aidera également à mieux comprendre ce que vous devez faire. Consultez Software Estimation de Steve McConnell et Pattern Requirements Software Patterns de Stephen Withall pour obtenir des conseils sur la répartition des tâches et la découverte des 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 inférieures mais certaines seront terminées et elles auront tendance à se peser) de la grosse tâche.
Demandez à votre "chef de projet": vendons-nous des logiciels ou des délais?
Je suis un chef de projet et un programmeur :-) Je pourrais m'expliquer longuement sur la façon dont la plupart des PM viennent de l'extérieur de l'industrie et je ne peux rien gérer qui ne rentre pas bien dans un modèle de ligne de production ... mais je pas, pas ici. Au lieu de cela, voici une longue polémique sur ce qu'il faut réellement faire (M. Mod, si c'est trop long, faites ce que vous voulez). Je suis d'accord avec les commentaires déjà faits ici, certains que vous devriez faire avant d'autres, mais voici ce que je pense aurait été le mieux votre premier coup. Oh, et la réponse évidente à votre question est oui, mais c'est élaboré dans un langage coloré et détaillé ci-dessous.
Avant de commencer, notez que le PM est très probablement une source de chagrin, car quelqu'un d'autre plus haut dans la chaîne alimentaire est en train de lui faire du chagrin. Ce sont (nous) de simples créatures ... pour éviter la situation que vous avez décrite - Mike Brown le couvre assez bien. Il n'y a rien de mal à faire quelque chose pendant 3/4/5 heures .. avant de démarrer (en fait, toutes sortes d'alarmes doivent se déclencher si cela ne fonctionne pas) Et si vous allez en territoire inconnu, repoussez et demandez une semaine pour rechercher le domaine et les technologies afin de pouvoir faire une estimation raisonnable (vous voudrez le faire correctement parce que vous voulez que les nouvelles technologies apprennent & jouer avec vous non?). Si votre PM et la direction de l'endroit où vous êtes ne comprennent pas cela ... alors mettez à jour votre CV et recherchez la sortie la plus proche, les laissant au sort qu'ils méritent si richement. Que le PM penserait même à faire signer un contrat à temps plein à un employé à temps plein) n ... la seule façon pour moi de voir qu'ils pourraient ne pas être totalement incompétents, c'est qu'ils ne faisaient que jouer à des jeux d'esprit avec votre chef de projet et vous (d'après ce que j'ai lu, ils ne vous l'ont pas dit directement et n'ont finalement pas mis à exécution la menace). PMing est un refuge pour votre psychopathe d'entreprise standard après tout. Il était bon que d'autres se soient mis à votre place à partir de ce que vous avez dit, donc les conseils ci-dessous sont finalement devenus positifs pour vous. J'imagine qu'ils auraient eu une révolution sur leurs mains si cela s'était avéré être plus que parler.
Donc, à la situation/trou réel que vous avez décrit, parce que cela va se reproduire pour quelqu'un, quelque part (comme il y a environ 5 minutes, et encore dans un autre 5, scheduleRepeat ()). Sans la stupidité du contrat, probablement, 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 tapoter dans le dos à 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 ayant déjà passé en revue le problème avec eux et les avoir intégrés. Le plus haut dans la hiérarchie, vous pouvez aller pour quelqu'un de votre "côté", mieux c'est. Parce que votre PM verra cela et essaiera de faire correspondre votre gestionnaire de conception avec un équivalent. Sinon, ils sont stupides et vous avez déjà gagné. Cela en soi les ramènera généralement en ligne , car maintenant ils sont visibles par quelqu'un qui peut probablement les renvoyer sur place. S'ils jouent à des jeux avec vous, vous êtes autorisé à rendre la pareille.
Lors de la réunion, passez en revue les détails techniques de ce que vous traitez et pourquoi cela prend du temps. Ils devraient vouloir savoir cela (et comment ils peuvent vous aider à le faire), mais le triste fait est généralement que cela ne se produit pas ... vous aurez probablement 10 minutes avant que leurs yeux ne reviennent dans leur tête. Maintenant, ce que je voudrais faire ici n'est probablement pas légal ... ouais, j'ai vérifié, c'est très illégal en fait et vous ne voulez pas aller en prison aussi longtemps. Le fait est que vous avez fait de votre mieux pour être proactif et si vous avez des hauts placés, votre douleur est maintenant la leur ... comme il se doit. Vous devrez utiliser votre jugement sur la façon dont les choses vont probablement se dérouler, car l'escalade est ce qui se passera. Si le leadership à l'endroit où vous vous trouvez est à moitié décent, il fera la bonne chose et fera la bonne chose par vous aussi. Sinon, vous auriez eu votre CV sur le marché à l'avance ... vous alliez partir à la première occasion de toute façon (et on dirait que vous l'avez finalement fait). La direction se divisera en deux groupes - soit ils sont techniquement avertis et ils verront instantanément votre point de vue; ou ils ne le sont pas et que vont-ils faire à ce sujet autre que sourire et le supporter? S'ils pouvaient faire ce que vous faites, ils le feraient déjà.
Gardez le problème des exigences changeantes comme votre atout à utiliser à la fin ... il servira de sortie pour tout le monde. Le projet lui-même et le foutu client/intervenant verront leur nom en vain. La manière la plus indolore serait de procéder à une sorte de réinitialisation du projet, et peut-être que PM serait tranquillement réaffecté à une zone différente. Des miracles se produisent occasionnellement. Si le problème du contrat était soulevé lors de la réunion par le PM, puis répliqué avec les exigences de gel de la demande de contre-contrat - en ce qui me concerne, ils ont déjà brûlé leurs ponts avec vous, et avec toute l'équipe de développement, quand ils ont commencé à jouer ce genre d'esprit Jeux.
Avant de signer: modification de la portée/des exigences - l'une des meilleures raisons d'adopter la méthodologie Agile, afin que les clients/parties prenantes soient correctement tenus de changer d'avis sur ce qu'ils veulent ...
Oh, une autre chose: sur la déclaration "Je ne sais pas", j'ai toujours été ma référence personnelle sur la façon d'évaluer 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 les visages sont les meilleurs, principalement parce que quelqu'un qui sait qu'ils sont hors de leur profondeur ne le dira jamais - les ouvre à être clairement exposés par quelqu'un ayant des capacités réelles dans un battement de coeur. D'un autre côté, quelqu'un qui se prononcera et le dira, aura également un plan de base (même si cela n'a pas été pensé à travers) sur la façon de faire face aux inconnus afin qu'en 24 heures il y ait une réponse plus utile, et en une semaine encore meilleure. Quand Apollo 13 volait autour du côté obscur de la Lune, il y avait tout un tas de "je ne sais pas" qui se passaient. Si vous ne pouvez pas faire face à ce genre de choses, vous êtes dans le mauvais jeu.
Oui, cela devrait soulever un drapeau rouge, surtout si vous êtes un employé à temps plein. Quelles étaient les conditions du contrat? Seriez-vous réellement renvoyé si vous aviez manqué les délais? Ou voudriez-vous simplement manquer un bonus? Que feraient-ils?
Le signal que cela soulève est que le gestionnaire n'a aucune idée de la façon de gérer un projet portant sur des technologies nouvelles/inconnues et des exigences changeantes qui affectent directement l'effort estimé. Bien que des délais stricts se produisent parfois, un gestionnaire qui connaît la situation ne devrait pas essayer de faire signer des contrats aux employés pour les faire respecter. Les nuits tardives et les heures de crise seront mauvaises, mais c'est probablement la même chose pour le cours. Et parfois, la date limite glisse. Cela arrive, et comme quelqu'un d'autre a posté, la seule façon de respecter le calendrier est de geler TOTALEMENT les exigences afin qu'il y ait encore suffisamment de place pour respecter la chronologie.
D'après ce que vous avez dit, les sonnettes d'alarme sont en retard de quelques mois. Il est normalement risqué de fonder un projet sensible au facteur temps sur des technologies que le personnel ne connaît pas déjà. Il est imprudent de le faire si vous n'avez aucune compréhension de la collecte des exigences et de la gestion de la portée.
Cela dit, je suis d'accord avec les autres réponses. Vous pouvez également mettre à jour votre CV si vous ne l'avez pas déjà fait.
Tout comme tous les autres répondants, je ne pourrais pas être plus d'accord que cela devrait lever le drapeau rouge.
Il semble que le PM ne souhaite pas être impliqué dans le processus de développement.
Dans ma pratique personnelle, je me suis longtemps éloigné du traitement des spécifications initiales détaillées, des approbations, de l'estimation complète du projet ou de la tarification des offres fixes (du point de vue du conseil).
La raison en est la prise de conscience, dont beaucoup de gourous des logiciels Agile et Lean parlent, que le logiciel n'est pas une entité manufacturière fixe, mais c'est surtout un processus de découverte.
Beaucoup de gens ont encore des problèmes avec cette notion, et cela ressemble à votre PM l'a fait aussi. Cela revient à une simple compréhension des compromis.
Des spécifications initiales rigides et des estimations fixes fonctionnent pour les systèmes où le coût du changement est élevé. Comme construire un gratte-ciel. Si vous avez oublié de spécifier les cages d'ascenseur à l'avant, il sera très difficile de moderniser le bâtiment une fois qu'il aura été érigé. Le coût élevé du changement nécessite beaucoup de planification préalable, l'apprentissage des inconnues des composants et des technologies et l'expérimentation préalable. Ce n'est qu'une fois que vous avez fait tous ces devoirs que vous pouvez estimer le budget et les coûts.
Dans le domaine des logiciels, les gens sont devenus très habitués à l'idée que le coût du changement est faible, et ils aiment donc profiter de pouvoir changer les choses une fois qu'ils voient une version, intégrer une nouvelle compréhension de l'application, de l'entreprise, du client sur une base continue. Tout cela est bon et représente une énorme opportunité lorsqu'il est exploité correctement. La plupart des gens que j'ai rencontrés et avec lesquels j'ai travaillé sur les logiciels n'aiment pas passer beaucoup de temps à planifier ou enquêter; la plupart d'entre nous (les PM inclus) veulent voir une traction continue. C'est de là que vient le développement itératif avec ses petites versions incrémentielles de fonctionnalités. Il existe d'autres pratiques qui peuvent être utilisées, comme le développement piloté par les tests pour garantir que le coût du changement reste faible et que la dette technique est contenue.
Pour que cela fonctionne, il faut un "contrat" entre les deux parties, le propriétaire du produit (Agile parle au nom de votre PM ou clients ou équipe QA) et les développeurs. Les développeurs acceptent de ne travailler que sur les éléments qui ont été priorisés comme le plus important pour l'itération donnée et pour ne pas prendre une éternité avec cela, mais nous nous efforçons de publier fréquemment des blocs de fonctionnalités entièrement intégrés (par exemple, hebdomadairement ou mensuellement). conviennent également de fixer 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 PM ne comprend probablement pas. De nombreux PM traditionnels ne le savent pas. Certains d'entre eux pensent que leur travail est terminé lorsqu'ils abandonnent les spécifications; ils Je ne veux pas entendre parler de problèmes, d'alternatives, de meilleures méthodes, etc.
Jetez un oeil au Manifeste Agile: http://agilemanifesto.org/ Il peut résonner avec vous. Un bon livre à lire est aussi "Lean Software Development" de Mary Poppendieck
Bonne chance.
On dirait que le manager cherche quelqu'un à blâmer quand il rend compte à son supérieur.
Je trouve que si vous avez un manager déraisonnable qui pense qu'une "estimation" est la même chose qu'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 gestionnaire à s'assurer que les exigences sont entièrement détaillées et fixes. Toute modification à partir de ce moment ne sera pas prise en compte sans une "renégociation formelle" avec le chef de projet du nouveau délai d'achèvement.
Finalement, le chef de projet obtient 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 mettre en place une trace papier pour vous éliminer tout en faisant de votre résiliation votre propre faute. Cela en ferait un drapeau très rouge. Votre kilométrage peut bien sûr varier quelque peu.
De bonnes réponses tout autour, mais permettez-moi d'ajouter mes 2 cents.
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 autre.
Le fait est que le travail prendra un certain temps, mais toute estimation antérieure sera erronée, par un peu ou beaucoup, du côté négatif ou positif, donc il y a un risque, et 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 de temps et de matériaux par rapport à un contrat à prix fixe. Avec le temps et les matériaux, le client supporte le risque. Avec le forfait, je supporte le risque. Avec le forfait, j'installe une marge de sécurité, car si je n'atteins pas l'objectif, personne ne gagne.
Vous demander de vous engager à une date de livraison fixe, en particulier sans exigences fixes, revient à essayer de vous transférer le risque, même si vous ne savez pas exactement ce que vous risquez réellement. Dans tous les cas, une réponse est simplement de mettre une marge de sécurité très généreuse.
P.S. Vous voyez cela tout le temps avec les contrats du gouvernement. Il y a une demande initiale de propositions, des offres sont faites, une offre basse est acceptée, puis les demandes de changement commencent à arriver, donc les coûts montent en flèche et l'entrepreneur est blâmé. Les choses fonctionnent beaucoup mieux s'il y a une relation de travail d'équipe entre le client et l'entrepreneur, plutôt qu'une relation contradictoire.
"Marcher sur l'eau et développer un logiciel à partir d'une spécification sont faciles si les deux sont gelés."
-Edward V. Berard
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.
Oui, bien sûr, cela met en évidence l'expérience et les compétences de votre ancien patron. Oui, comme la plupart des gens l'ont suggéré, ce serait le 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 veux suggérer qu'il pourrait y avoir des situations où vous pourriez envisager de le signer.
La plupart des développeurs et gestionnaires sont conscients de la friction constante entre la fonctionnalité, le délai et le budget. Beaucoup proposeraient également la qualité comme quatrième dimension ("Je peux répondre à toutes les exigences que vous souhaitez, d'ici demain pour un petit budget, tant que vous êtes prêt à accepter que cela ne fonctionnera pas!")
Mais il y a encore une autre dimension: le risque. Si j'ai seulement besoin de livrer avec succès 50% du temps, je peux réduire considérablement mes estimations; ils sont rembourrés pour gérer un taux de livraison beaucoup plus élevé.
Nous pouvons aborder le risque de plusieurs façons (et les estimations de remplissage en font partie). Le gestionnaire n'est pas disposé à accepter aucun risque et veut mettre le risque sur vos épaules. Normalement, vous devriez refuser un tel mouvement ... sauf si vous êtes bien rémunéré.
Si vous êtes en mesure de nommer votre échéance, avec une quantité de rembourrage mutuellement acceptable pour faire face à des retards inattendus, et êtes en mesure de négocier un (très gros) bonus si vous l'atteignez, et êtes en position financière pour pouvoir gérer le pénalités (par exemple, licenciement) si vous ne le pouvez pas, vous pouvez trouver que c'est un "pari" intéressant d'accepter ce risque vous-même et de signer le contrat - avec des clauses appropriées pour gérer les changements d'exigences.
Je dis: mettez-vous à sa place et essayez de comprendre ce qui a motivé cela. De futurs gestionnaires/comptables, ils ont besoin d'un numéro pour justifier ce qui s'est passé et comment les choses se passent.
Il se pourrait qu'en se moquant de la salle du conseil d'administration pour avoir décalé les délais, manquant trop de délais, il ait essayé le moyen le plus simple de les faire enfermer. Donnez-moi un numéro et signez ici! Vous étant de l'autre côté, vous n'auriez pu que percevoir que c'est quelque chose contre vous. Comment faire des estimations et en même temps se rendre compte qu'elles doivent être ajustées, c'est ce qui lui est le plus utile. 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, vous et vous-même. En tant que programmeurs, nous résolvons les problèmes. Ce n'est pas différent, comprenez et résolvez son problème et il sera votre meilleur ami. Il y a tellement de travail à faire que personne n'a le temps de tracer une vendetta personnelle! Il a besoin d'aide pour son travail, la solution la plus simple était de faire signer un papier par quelqu'un! Il a probablement obtenu cela d'un livre de gestion pour les nuls, "Demandez à vos employés de signer et d'être responsables d'un nombre." Drôle mais triste
C'est de la stupidité pure et simple. Je ne sais pas quel était le but ultime, mais chaque chef de projet à moitié décent responsable des produits logiciels devrait être conscient que les estimations sont exactement ce qu'elles sont appelées: des estimations. Ce ne sont pas des promesses et elles ne peuvent être faites sans vider le développeur de logiciels de toute leur énergie ou les forcer de toute façon à rompre leur "promesse".
Si vous voulez montrer à quel point un tel contrat est ridicule, voici deux suggestions:
a) Très surestimé au point où le projet prend cinq ou dix fois plus de temps que vous ne le feriez sans contrat. Si le chef de projet demande pourquoi les estimations sont si élevées, dites simplement que vous vous assurez de pouvoir exécuter 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 comprend 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 à un moment donné du développement. Le chef de projet est plus susceptible de devoir rompre son contrat que vous.
Si le chef de projet était d'accord avec l'une de ces deux suggestions, vous sauriez avec certitude qu'elles sont hors de leur esprit.
Soit dit en passant, comment un contrat pour un employé à temps plein fonctionnerait-il de toute façon? 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 dossier valide. Bien sûr, ils pourraient vous donner l'enfer si vous ne respectez pas le délai, mais ils n'ont pas besoin d'un contrat pour cela. Personne ne pourrait vous licencier ou vous donner moins d'argent. Ils pourraient au pire réduire votre bonus convenu. Donc, à moins que cela ne soit différent dans d'autres pays, cela ressemble plus à une menace vide que tout ce que vous devez prendre au sérieux.
Je vais aller à contre-courant ici.
La situation que vous décrivez n'est pas si inhabituelle au niveau Engineering team, surtout après un projet/une version particulièrement tardive. Dans de nombreuses situations, votre direction et l'ensemble de votre organisation peuvent en fait avoir signé pour une date de sortie particulière, et d'autres parties de l'organisation seront adaptées à cette date. Il peut y avoir une pression énorme sur votre chaîne de gestion pour atteindre cette date.
C'est là qu'intervient un processus d'ingénierie général. Vous avez probablement entendu parler du modèle en cascade. Il existe d'autres modèles, mais l'objectif final de chacun d'eux est de fournir systématiquement quelque chose lorsque il est attendu 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 concernant le calendrier réduisent les surprises et rendent les informations disponibles dès que possible afin que les plans puissent être ajustés. 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 à traiter mes devis comme des engagements signés, mais cela reflète la qualité des équipes et du management, et pas une compétence particulière d'estimation. Une équipe qui est disposée à signer un contrat pour livrer à temps est un indicateur d'une équipe qui fonctionne bien, pas un drapeau rouge.