Projektmanager, der die Zeitschätzung mit einem unterzeichneten Vertrag festlegen möchte

Bei einer früheren Beschäftigung war ein Projektmanager (PM) mit der Lieferzeit des Codes für ein Projekt, an dem ich beteiligt war, nicht zufrieden. Mein Projektleiter teilte mir mit, dass der Ministerpräsident erwägt, einen Vertrag zu unterzeichnen, um meine Zeitvoranschläge für Aufgaben und Liefertermine festzuhalten.

Die Situation bei dem Projekt war, dass wir mit neuen Technologien, Codebasis, Codierungsstandards und sehr anfälligen Anforderungen gearbeitet haben. Ich lernte neue Dinge und wandte sie so gut ich konnte auf Anforderungen an, die sich ständig änderten. Die Anforderungen während der Iterationen sind um das 2-3-fache gewachsen, wobei meine geschätzte Gesamtgröße um das 5- bis 8-fache gestiegen ist. Die einzigen Dinge, die sich nicht geändert haben, waren die Kostenvoranschläge und Liefertermine.

Ja, ich habe die meisten Fristen versäumt. Und ich arbeitete an einigen sehr neuen Technologien, an denen niemand im gesamten Entwicklungsteam wirklich mitarbeiten konnte, weil sie nicht damit vertraut waren. Zumindest nicht leicht.

Damals schien mir, dass der Premierminister wollte, dass sich seine Nummern summierten - und dass ich einen Vertrag unterschrieb, um sicherzustellen, dass ich immer pünktlichen Arbeitscode liefern würde. Ich nehme an, mit einem unterschriebenen Vertrag könnte der Premierminister ihn gegen mich verwenden, wenn ich nicht rechtzeitig liefern könnte.

Ich glaube, was als nächstes geschah, war, dass andere Projektmanager und / oder Projektleiter mich verteidigten und dies nicht zuließen.

Meine Frage ist, sollte dies eine rote Fahne über den Manager wecken? Ist es üblich, dass ein Manager die Zeitschätzungen eines Softwareentwicklers mit einem unterzeichneten Vertrag festlegt? Oder versuchen Sie es in diesem Fall.

Bitte beachten Sie, dass ich Vollzeitbeschäftigter und kein unabhängiger Berater war.

Update : Ich möchte hinzufügen, dass ich wöchentlich neue Schätzungen gegeben habe, aber es scheint, dass die ursprünglichen Schätzungen und Liefertermine das waren, worauf die PM fixiert war.

Meine Frage ist, sollte dies eine rote Fahne über den Manager wecken?

Ja . Es ist an der Zeit, dass Sie Ihren Lebenslauf auf den neuesten Stand bringen und sich auf die Suche nach einem neuen Job machen. Oder es bedeutet, dass Ihr Manager im Begriff ist, einige sehr böse Spiele mit Ihnen zu spielen.

Ist es üblich, dass ein Manager die Zeitschätzungen eines Softwareentwicklers mit einem unterzeichneten Vertrag festlegt?

Ich habe noch nie davon gehört, dass dies auf einen Mitarbeiter angewendet wird.

Die Schätzung von Zeit und Aufwand ist immer schwierig. Zumal unser Beruf überaus optimistisch ist. Es gibt einige Schätzsysteme, die bei zukünftigen Schätzungen hilfreich sein könnten, aber sie müssen historische Statistiken von Ihnen selbst sammeln. Eine davon ist PSP . Ein weiterer Grund sind Funktionspunkte . Viele Entwickler mögen keine, und Sie werden sehr starke Meinungen gegen beide finden.

Die Hauptschwierigkeit bei der Schätzung von Zeit und Aufwand ist das Fehlen von Rückmeldungen in unseren Schätzungsheuristiken. Einer der Schlüssel besteht darin, aufzuschreiben, was Ihrer Meinung nach die Schätzung ist und welche Parameter Sie zur Schätzung verwendet haben. Vergleichen Sie dann, basierend auf dem, was Sie tatsächlich erledigt haben, das mit dem, von dem Sie dachten, Sie würden es tun. Und verwenden Sie dies, um Ihre Schätzparameter zu ändern. In der Technik nennen wir dies " Feedback ".

Ja, das sollte unbedingt Alarmglocken läuten.

Wäre ich zu meiner persönlichen Unterhaltung in der Lage gewesen, hätte ich den Manager gebeten, einen Vertrag zu unterzeichnen, der alle Anforderungen einfriert. Ich stelle mir vor, der Manager würde wahrscheinlich auf Kaution gehen. Dann würde ich gehen.

Das ist ganz einfach. Teilen Sie Ihrem Manager einfach mit, dass Sie unterschreiben werden, um Ihre Zeitschätzung festzulegen, wenn er unterschreibt, um die Spezifikation festzulegen. Sie können keine Schätzungen für etwas Unbekanntes bereitstellen. Volle Projektspezifikation bevor Sie anfangen, keine Änderungen - und Sie können es rechtzeitig beenden :)

Eine Änderung der Spezifikation => Vertrag ist nichtig. Wahrscheinlich wird das Ding gleich nach 10 Minuten an deinem ersten Tag ungültig :)

Ja, das ist eine rote Fahne. Was es Ihnen sagt, ist, dass der Manager nicht versteht, wie man Risiken in Softwareprojekten handhabt. Was er tun sollte, ist herauszufinden, was genau die Verzögerung an erster Stelle verursacht hat, und dann einen Prozess zu instrumentieren, um Terminrisiken, die während eines Softwareprojekts unvermeidlich sind, effektiv zu managen.

NIEMALS würde ich mit meinem Vorgesetzten einen Vertrag abschließen, der einen Zeitplan garantiert. Andere haben erwähnt, dass er eine Sperre für Spezifikationen unterschreibt. Das reicht meiner Meinung nach nicht aus. Dies berücksichtigt nicht unvorhergesehene Schwierigkeiten mit den Werkzeugen oder der Technologie, unvollständige oder schlechte Designs, die Leistung anderer Teammitglieder usw.

Das ist keine rote Fahne, das ist Dummheit auf Waffenebene.

Wenn Schätzungen und Fristen konsequent eingehalten werden, ist es sinnvoll, Ursachen zu identifizieren und Prozesse zu verbessern.

Wenn Sie das Pferd beschuldigen und treten, weil Sie nicht wissen, wohin Sie gehen, wundern Sie sich nicht, wenn das Pferd Sie beißt und davonläuft!

Während der Manager seiner Forderung nicht nachkam. Er ist nicht voll schuld. Wenn Sie in einem völlig unbekannten Gebiet gearbeitet haben, ist es nichts Falsches, wenn Sie "Ich weiß nicht" sagen. Es hat eine Weile gedauert, bis mir klar wurde, dass "Ich weiß nicht" eine völlig akzeptable Antwort ist. Ich weiß also, wie wichtig es ist, diese Worte auszusprechen. Aber wenn Sie es wirklich nicht wissen, ist das die Antwort. Und wenn sie sich dagegen wehren, bitten Sie sie, Ihnen eine Schätzung der Anzahl der Pfennige zu geben, die erforderlich sind, um einen Stapel so hoch wie den Turm der Sears (make it Willis) zu machen. Und würden sie bereit sein, einen Vertrag zu unterzeichnen, in dem sie Ihnen jeden Cent zahlen, den sie verdienen?

Jeder Projektmanager, der sein Gehalt verdient, sollte wissen, dass einige Dinge nicht gut und schön in eine Tabelle passen. Manchmal werden Dinge erledigt, wenn sie erledigt sind. Ich denke, du machst es gut, indem du Fortschritte machst, wie viel du getan hast. Hören Sie einfach auf, die Nummer zu aktualisieren.

Eine andere Übung besteht darin, die große Aufgabe in kleinere, besser schätzbare Einheiten aufzuteilen. Diese Übung wird Ihnen helfen, besser zu verstehen, was Sie ebenfalls tun müssen. In Steve McConnells Software Estimation und Stephen Withalls Software Requirements Patterns finden Sie Tipps, wie Sie Aufgaben aufschlüsseln und versteckte Anforderungen aufdecken können .

Schießen Sie nicht aus der Hüfte auf eine Schätzung. Nehmen Sie sich Zeit, um es zu brechen. Wenn Sie eine große Anzahl kleiner Aufgaben schätzen, erhalten Sie eine bessere Gesamtschätzung (aufgrund des Durchschnittsgesetzes liegen einige Ihrer Schätzungen unter den Erwartungen, andere sind jedoch vorüber und sie neigen dazu, sich gegenseitig abzuwägen) der großen Aufgabe.

Fragen Sie Ihren "Projektmanager": Verkaufen wir Software oder Fristen?

Ich bin ein Projektmanager und ein Programmierer :-) Ich könnte lange darüber streiten, wie die meisten PMs von außerhalb der Branche stammen, und kann nichts verarbeiten, was nicht gut in ein Produktionslinienmodell passt ... aber ich wird nicht, nicht hier. Stattdessen ist hier eine lange Polemik darüber, was zu tun ist (Herr Mod, wenn es zu lang ist, tun Sie, was Sie wollen). Ich stimme den hier bereits gemachten Kommentaren zu, einige sollten Sie vor anderen machen, aber ich denke, dies wäre am besten Ihr erster Schritt gewesen . Oh, und die offensichtliche Antwort auf Ihre Frage lautet Ja, aber das wird unten in farbenfroher und detaillierter Sprache ausgeführt.

Bevor ich anfange, beachte ich jedoch, dass der Premierminister dir höchstwahrscheinlich Kummer bereitet, weil jemand anderes in der Nahrungskette ihm Kummer bereitet. Sie (wir) sind einfache Wesen ... Es gibt Möglichkeiten, die von Ihnen beschriebene Situation zu umgehen - Mike Brown deckt das ziemlich gut ab. Es ist auch nichts Falsches daran, etwas für 3/4/5 Stunden direkt vor dem Start zu kaufen (eigentlich müssen alle Arten von Alarmen ausgelöst werden, wenn dies nicht geschieht). Und wenn Sie Neuland betreten, sollten Sie sich zurücklehnen und eine Woche lang nach dem Gebiet und den Technologien fragen, um eine vernünftige Schätzung vornehmen zu können nicht wahr?). Wenn Ihr PM und das Management an dem Ort, an dem Sie sich befinden, dies nicht verstehen, aktualisieren Sie Ihren Lebenslauf und suchen Sie nach dem nächsten Ausgang. sie dem Schicksal überlassen, das sie so reich verdienen. Dass der Ministerpräsident überhaupt daran denkt, einen Vollzeitangestellten dazu zu bringen, einen solchen Vertrag zu unterschreiben, ist ein schlechtes Zeichen ... der einzige Weg, wie ich das sehen kannVielleicht ist es nicht völlig inkompetent, dass sie wirklich nur Gedankenspiele mit Ihrem Projektleiter und Ihnen spielten. Schließlich ist PMing eine Oase für Ihren Standard-Unternehmenspsychopathen. Es war gut, dass andere nach Ihren Aussagen in die Fledermaus gegangen sind, daher wäre der Ratschlag unten am Ende wahrscheinlich positiv für Sie ausgefallen. Ich stelle mir vor, sie hätten eine Revolution in ihren Händen gehabt, wenn sich herausgestellt hätte, dass mehr als nur geredet wurde.

Also zu der tatsächlichen Situation / dem tatsächlichen Loch, das Sie beschrieben haben , weil es jemandem wieder passieren wird, irgendwo (wie vor ungefähr 5 Minuten und erneut in anderen 5, scheduleRepeat ()). Vermutlich ohne die Vertragsdummheit, aber die Grundhandlung ist immer die gleiche. Organisieren Sie ein Meeting (!), Sie mögen Meetings ;-) Jeder kann sich am Ende auf den Rücken klopfen, als ob tatsächlich etwas getan worden wäre. WICHTIG:Stellen Sie sicher, dass Sie Ihren technischen Projektleiter / Teamleiter / Architekten / Designmanager in die Besprechung einbeziehen, indem Sie das Problem bereits besprochen und an Bord geholt haben. Je höher die Hierarchie, die Sie für jemanden auf Ihrer "Seite" wählen können, desto besser. Weil Ihr PM das sieht und versucht, Ihren Designmanager mit einem Äquivalent abzugleichen. Wenn nicht, sind sie dumm und Sie haben bereits gewonnen. Das an sich wird sie in der Regel wieder in eine Linie bringen, denn jetzt sind sie für jemanden sichtbar, der sie wahrscheinlich an Ort und Stelle entlassen kann. Wenn sie mit Ihnen spielen, können Sie den Gefallen erwidern.

Sehen Sie sich in der Besprechung die technischen Details an, mit denen Sie es zu tun haben und warum es so lange dauert. Sie sollten dies wissen wollen (und wie sie Ihnen dabei helfen können), aber die traurige Tatsache ist, dass dies im Allgemeinen nicht der Fall ist ... Sie werden wahrscheinlich 10 Minuten brauchen, bevor ihre Augen wieder in ihren Kopf rollen. Was ich hier machen möchte, ist wahrscheinlich nicht legal ... Ja, ich habe nachgesehen, es ist tatsächlich höchst illegal und du willst nicht so lange ins Gefängnis. Der Punkt ist, dass Sie sich nach besten Kräften bemühen, proaktiv zu sein, und wenn Sie einige höhere Aufgaben haben, liegt Ihr Schmerz nun bei ihnen ... so wie es sein sollte. Sie müssen einschätzen, wie sich die Dinge voraussichtlich entwickeln werden, denn "Eskalation" ist das, was passieren wird. Wenn die Führung an dem Ort, an dem Sie sind, halb anständig ist, werden sie das Richtige tun, und tu auch das Richtige von dir. Wenn nicht, dann hättest du deinen Lebenslauf vorher auf dem Marktplatz veröffentlicht ... du würdest sowieso bei der ersten Gelegenheit gehen (und es sieht so aus, als ob du es letztendlich getan hättest). Die Führung wird in zwei Gruppen eingeteilt - entweder sie sind technisch versiert und sie werden sofort Ihren Standpunkt sehen; oder sind sie es nicht und was werden sie dagegen tun, außer zu grinsen und es zu ertragen? Wenn sie das tun könnten, was Sie tun, würden sie es bereits tun. t und was werden sie dagegen tun, als zu grinsen und es zu ertragen? Wenn sie das tun könnten, was Sie tun, würden sie es bereits tun. t und was werden sie dagegen tun, als zu grinsen und es zu ertragen? Wenn sie das tun könnten, was Sie tun, würden sie es bereits tun.

Behalten Sie das Problem der sich ändernden Anforderungen als Trumpfkarte bei, die Sie am Ende verwenden können. Das Projekt selbst und der verdammte Kunde / Stakeholder werden vergeblich namentlich genannt. Der einfachste Weg wäre, eine Art Reset für das Projekt durchzuführen, und möglicherweise würde diese PM stillschweigend einem anderen Bereich zugewiesen. Wunder geschehen gelegentlich. Wenn die Vertragsfrage in der Besprechung vom Ministerpräsidenten angesprochen wurde, dann schlagen Sie mit den Anforderungen zurück, um die Gegenvertragsnachfrage einzufrieren - meiner Meinung nach haben sie ihre Brücken bei Ihnen und dem gesamten Entwicklungsteam bereits gebrannt, als sie begannen diese Art von Gedankenspielen spielen.

Bevor ich mich abmelde: Änderung des Umfangs / der Anforderungen - einer der besten Gründe, die Agile-Methodik zu übernehmen, damit die Kunden / Stakeholder ihre Meinung über das, was sie wollen, ordnungsgemäß ändern können ...

Oh, noch etwas: Bei der Aussage "Ich weiß nicht" war es immer mein persönlicher Maßstab, wie man den Wert eines Kollegen in einem meiner Projektteams beurteilt. Ich finde, die einzigen Menschen, die sagen können, dass sie direkt ins Gesicht gehen, sind die besten, die es gibt, vor allem, weil jemand, der weiß, dass er überfordert ist, dies niemals sagen wird - er öffnet sie für die Offenlegung durch jemanden mit tatsächlichen Fähigkeiten in ein Herzschlag. Auf der anderen Seite wird jemand, der sich mit dem Thema auseinandersetzt und es sagt, auch einen grundlegenden Plan haben (auch wenn noch nicht darüber nachgedacht wurde), wie man die Unbekannten angeht, sodass es in 24 Stunden eine nützlichere Antwort gibt. und in einer Woche eine noch bessere. Als Apollo 13 um die dunkle Seite des Mondes flog, passierte eine ganze Reihe von "Ich weiß nicht".

Ja, dies sollte eine rote Fahne werfen, insbesondere wenn Sie Vollzeitbeschäftigter sind. Was waren die Vertragsbedingungen? Wären Sie tatsächlich entlassen worden, wenn Sie Termine verpasst hätten? Oder würden Sie einfach einen Bonus verpassen? Was würden sie tun?

Dies zeigt, dass der Manager keine Ahnung hat, wie ein Projekt zu verwalten ist, das sich mit neuen / unbekannten Technologien und sich verändernden Anforderungen befasst, die sich direkt auf den geschätzten Aufwand auswirken. Während manchmal schwierige Fristen eintreten, sollte ein Manager, der die Situation kennt, nicht versuchen, Mitarbeiter dazu zu bringen, Verträge zu unterzeichnen, um sie durchzusetzen. Späte Nächte und Krisenzeiten werden schlecht sein, aber das ist wahrscheinlich die Regel. Und trotzdem wird manchmal die Frist verrutschen. Es kommt vor, und wie bei einem anderen Beitrag besteht die einzige Möglichkeit, sich an den Zeitplan zu halten, darin, die Anforderungen EARLY ON einzufrieren, damit noch genügend Platz für die Aufbewahrung der Timeline vorhanden ist.

Nach dem, was Sie gesagt haben, sind die Alarmglocken einige Monate zu spät. Es ist normalerweise riskant, ein zeitkritisches Projekt auf Technologien aufzubauen, mit denen die Mitarbeiter noch nicht vertraut sind. Wenn Sie keine Ahnung von der Erfassung von Anforderungen und der Verwaltung von Bereichen haben, ist dies ein Kinderspiel.

Trotzdem stimme ich den anderen Antworten zu. Möglicherweise möchten Sie auch Ihren Lebenslauf aktualisieren, falls Sie dies noch nicht getan haben.

Genau wie bei allen anderen Befragten konnte ich nicht mehr zustimmen, dass dies eine rote Fahne hissen sollte.

Es scheint, dass der PM nicht in den Entwicklungsprozess einbezogen werden möchte.

In meiner persönlichen Praxis habe ich mich lange nicht mehr mit detaillierten Vorabspezifikationen, Abnahmen, vollständigen Projektschätzungen oder Festpreisangeboten (aus Beratungssicht) befasst.

Der Grund dafür ist die Erkenntnis, von der viele der Agile- und Lean-Software-Gurus sprechen, dass Software keine fest herstellbare Einheit ist, sondern größtenteils ein Entdeckungsprozess.

Viele Menschen haben immer noch Probleme mit dieser Vorstellung, und es hört sich so an, als ob Ihre PM es auch getan hätte. Es kommt auf ein einfaches Verständnis der Kompromisse an.

Starre Vorabspezifikationen und feste Schätzungen funktionieren für Systeme, bei denen die Änderungskosten hoch sind. Als würde man ein Hochhaus bauen. Wenn Sie vergessen haben, die Aufzugsschächte von vorn zu spezifizieren, ist es wirklich schwierig, das Gebäude nach der Errichtung nachzurüsten. Hohe Änderungskosten erfordern viel Vorausplanung, das Erlernen der Unbekannten von Komponenten und Technologien sowie erste Experimente. Erst wenn Sie all diese Hausaufgaben gemacht haben, können Sie das Budget und die Kosten abschätzen.

In der Software haben sich die Menschen sehr an die Vorstellung gewöhnt, dass die Kosten für Änderungen niedrig sind, und sie möchten gern die Möglichkeit nutzen, Änderungen vorzunehmen, sobald sie eine Veröffentlichung sehen, und ein neues Verständnis für die Anwendung, das Unternehmen und den Kunden entwickeln eine laufende Basis. All dies ist gut und eine große Chance, wenn es richtig eingesetzt wird. Die meisten Software-Leute, mit denen ich zusammengearbeitet habe, verbringen nicht viel Zeit mit Planen oder Nachforschen. Die meisten von uns (einschließlich der PMs) möchten, dass die Traktion fortgesetzt wird. Hierher kam die iterative Entwicklung mit ihren kleinen, inkrementellen Versionen der Funktionalität. Es gibt andere Methoden , die verwendet werden können, wie testgetriebene Entwicklung zu gewährleisten , dass die Kosten für die Änderung bleibt niedrig und technische Schulden enthalten ist.

Um diese Arbeit zu erledigen, müssen beide Seiten, der Product Owner (Agile Speak für Ihren PM oder Kunden oder das QA-Team) und die Entwickler einen Vertrag abschließen. Entwickler erklären sich damit einverstanden, nur an Dingen zu arbeiten, die für die jeweilige Iteration als am wichtigsten eingestuft wurden, und diese nicht für immer in Anspruch zu nehmen. Sie sind jedoch bestrebt, häufig (z. B. wöchentlich oder monatlich) vollständig integrierte Funktionsbereiche freizugeben. Umgekehrt erklären sich die Produktbesitzer damit einverstanden, die inkrementellen Releases fortlaufend zu überprüfen und umgehend Feedback zu geben. Sie erklären sich auch damit einverstanden, die Prioritäten für die nächste Iteration festzulegen und ihre Meinung für die Dauer der Iteration nicht zu ändern.

Dieser letzte Teil der Vereinbarung ist etwas, das Ihr PM wahrscheinlich nicht versteht. Viele traditionelle PMs tun dies tatsächlich nicht. Einige von ihnen denken, dass ihre Arbeit erledigt ist, wenn sie die Spezifikation abgeben. Sie wollen nichts über Probleme, Alternativen, bessere Wege usw. hören. Der Nachteil ist, dass dies nicht nur dem Fluss der Softwareentwicklung entgegenwirkt, sondern auch die Organisation verletzt, indem es viele Möglichkeiten auf dem Tisch lässt.

Schauen Sie sich das Agile Manifest an: http://agilemanifesto.org/ Es könnte bei Ihnen Anklang finden. Ein gutes Buch zum Lesen ist auch Mary Poppendiecks "Lean Software Development"

Viel Glück.

Klingt so, als würde der Manager jemanden suchen, dem er die Schuld gibt, wenn er seinem Vorgesetzten Bericht erstattet.

Ich finde, wenn Sie einen unvernünftigen Manager haben, der denkt, dass eine Schätzung mit einer festen Periode identisch ist, ist es das Beste, an eine sehr großzügige Schätzung zu denken und sie dann zu verdoppeln!

Erzwingen Sie außerdem, dass der Manager sicherstellt, dass die Anforderungen vollständig detailliert und behoben sind. Änderungen von diesem Zeitpunkt an werden nicht ohne eine „formelle Neuverhandlung“ mit dem Projektmanager des neuen Fertigstellungszeitpunkts behandelt.

Irgendwann kommt der Projektleiter auf die Idee und plant entsprechend.

Meine persönliche Erfahrung mit solchen Dingen ist, dass der Projektmanager versucht, einen Papierpfad einzurichten, um Sie zu entsorgen, während Sie Ihre Kündigung selbst verschulden. Das würde es zu einer sehr roten Fahne machen. Ihr Kilometerstand kann natürlich etwas variieren.

Überall gute Antworten, aber lassen Sie mich meine 2 Cent addieren.

Wenn Sie jemals Wahrscheinlichkeit studieren, gibt es so etwas wie eine "Zufallsvariable". Das ist eine Zahl, deren Wert Sie nicht kennen, aber Sie können Ihr Nichtwissen mit einer Verteilung beschreiben, wie einer normalen (Glockenkurven-) Verteilung oder einer anderen.

Der Punkt ist, dass die Arbeit eine gewisse Zeit in Anspruch nimmt, aber jede vorherige Schätzung wird ein wenig oder viel falsch sein, negativ oder positiv, so dass ein Risiko besteht und jemand das Risiko eingehen muss. Wenn Menschen Risiken eingehen, werden sie im Allgemeinen dafür bezahlt. Versicherung kostet Geld.

Als Berater hatte ich normalerweise die Wahl, einen Zeit- und Materialvertrag im Vergleich zu einem Festpreisvertrag zu unterzeichnen. Mit Zeit und Material trägt der Kunde das Risiko. Bei Festpreisen trage ich das Risiko. Mit dem Festpreis baue ich eine Sicherheitsmarge ein, denn wenn ich das Ziel nicht erreiche, gewinnt niemand.

Die Aufforderung, sich auf einen festen Liefertermin zu verpflichten, insbesondere ohne feste Anforderungen, klingt nach dem Versuch, das Risiko auf Sie zu übertragen, obwohl nicht klar ist, was Sie tatsächlich riskieren. In jedem Fall besteht eine Antwort einfach darin, einen wirklich großzügigen Sicherheitsspielraum einzuräumen.

PS Sie sehen das die ganze Zeit mit Regierungsverträgen. Es gibt eine erste Aufforderung zur Einreichung von Vorschlägen, Gebote werden abgegeben, ein niedriges Gebot wird angenommen, und dann kommen die Änderungswünsche, sodass die Kosten in die Höhe schnellen und der Auftragnehmer dafür verantwortlich gemacht wird. Die Dinge funktionieren viel besser, wenn es eine Teamarbeit zwischen Auftraggeber und Auftragnehmer gibt, als eine kontroverse.

Ja, das zeigt natürlich die Erfahrung und Kompetenz Ihres ehemaligen Chefs. Ja, wie die meisten Leute vorgeschlagen haben, ist dies ein guter Zeitpunkt, um Ihren Lebenslauf zu aktualisieren.

Ja, wie in den anderen Antworten angegeben, möchten Sie diese Vereinbarung in den meisten Situationen nicht unterzeichnen. Ich möchte jedoch vorschlagen, dass es einige Situationen geben könnte, in denen Sie in Betracht ziehen könnten, es zu unterschreiben.

Die meisten Entwickler und Manager sind sich der ständigen Reibung zwischen Funktionalität, Frist und Budget bewusst. Viele würden auch Qualität als vierte Dimension vorschlagen ("Ich kann für ein geringes Budget bis morgen alle gewünschten Anforderungen erfüllen, solange Sie bereit sind zu akzeptieren, dass dies nicht funktioniert!")

Es gibt aber noch eine andere Dimension: das Risiko. Wenn ich nur 50% der Zeit erfolgreich liefern muss, kann ich meine Schätzungen erheblich senken. Sie sind gepolstert, um eine viel höhere Lieferrate zu bewältigen.

Wir können das Risiko auf verschiedene Arten angehen (und Polsterungsschätzungen sind eine davon). Der Manager ist nicht bereit, ein Risiko einzugehen, und möchte das Risiko auf Ihre Schultern legen. Normalerweise sollten Sie einen solchen Zug ablehnen ... es sei denn, Sie werden gut entschädigt.

Wenn Sie in der Lage sind, Ihre Deadline mit einem für beide Seiten akzeptablen Auffüllungsbetrag zu benennen, um unerwartete Verzögerungen zu bewältigen, und in der Lage sind, einen (sehr großen) Bonus auszuhandeln, wenn Sie darauf treffen, und in der finanziellen Lage sind, die zu bewältigen Strafen (zB gefeuert werden) Wenn Sie dies nicht können, ist es möglicherweise ein lohnendes "Glücksspiel", dieses Risiko selbst einzugehen und den Vertrag zu unterzeichnen - mit geeigneten Klauseln, um Anforderungsänderungen zu bewältigen.

Das ist geradezu Dummheit. Ich weiß nicht, was das Endziel war, aber jeder halbwegs anständige Projektmanager, der für Softwareprodukte verantwortlich ist, sollte sich darüber im Klaren sein, dass Schätzungen genau das sind, was sie genannt werden: Schätzungen. Sie sind keine Versprechungen, und sie können nicht gemacht werden, ohne den Softwareentwickler von all ihrer Energie zu befreien oder sie zu zwingen, ihr "Versprechen" trotzdem zu brechen.

Wenn Sie zeigen möchten, wie lächerlich ein solcher Vertrag ist, können Sie zwei Vorschläge machen:

a) Überschätzen Sie den Punkt, an dem das Projekt fünf- oder zehnmal so lange dauert, wie Sie es ohne Vertrag schätzen würden. Wenn der Projektmanager fragt, warum die Schätzungen so hoch sind, sagen Sie einfach, dass Sie nur sicherstellen, dass Sie Ihren Vertrag erfüllen können.

b) Dies wurde bereits vorgeschlagen: Fordern Sie einen Vertrag an, der sicherstellt, dass sich keine einzige Anforderung ändert, und stellen Sie sicher, dass Rechtschreibfehler korrigiert werden. Meiner Erfahrung nach gibt es kein einziges Softwareprojekt, bei dem sich die Anforderungen während der Entwicklung nicht ändern. Es ist wahrscheinlicher, dass der Projektmanager seinen Vertrag brechen muss als Sie.

Wenn der Projektmanager einem dieser beiden Vorschläge zustimmen würde, würden Sie sicher wissen, dass sie nicht mehr im Kopf sind.

Übrigens, wie würde ein Vertrag für einen Vollzeitbeschäftigten überhaupt funktionieren? Ich kenne keine Arbeitsvorschriften in anderen Ländern, aber als Vollzeitbeschäftigter in einem Unternehmen glaube ich nicht, dass Sie jemand zwingen könnte, einen verbindlichen Vertrag zu unterzeichnen, um eine Frist einzuhalten und einen gültigen Fall zu haben. Sicher, sie könnten dir die Hölle geben, wenn du die Frist nicht einhältst, aber sie brauchen keinen Vertrag dafür. Niemand könnte dich feuern oder dir weniger Geld geben. Sie könnten Ihren vereinbarten Bonus im schlimmsten Fall kürzen. Sofern dies in anderen Ländern nicht anders ist, scheint dies eher eine leere Bedrohung zu sein als alles, was Sie ernst nehmen sollten.

Ich werde hier gegen den Strich gehen.

Die von Ihnen beschriebene Situation ist auf der Ebene des Engineering- Teams nicht allzu ungewöhnlich , insbesondere nach einem besonders späten Projekt / Release. In vielen Situationen haben sich Ihr Management und Ihr gesamtes Unternehmen möglicherweise für ein bestimmtes Veröffentlichungsdatum angemeldet , und andere Teile des Unternehmens sind auf dieses Datum eingestellt. Es kann einen enormen Druck auf Ihre Managementkette ausüben, dieses Datum zu erreichen.

Hier setzt ein allgemeiner Engineering-Prozess an. Sie haben wahrscheinlich schon vom Wasserfallmodell gehört. Es gibt andere Modelle, aber das Endziel von allen ist es, etwas konsequent zu liefern, wenn es erwartet wird und das enthält, was vereinbart wurde. Funktionsspezifikationen, Entwürfe, Aufgabenlisten usw. tragen dazu bei, dass dieser Prozess vorhersehbar wird. Kommunikation, Risikoanalyse und (wie Sie sagten) regelmäßige Aktualisierung der Erwartungen bezüglich des Zeitplans reduzieren Überraschungen und stellen Informationen so schnell wie möglich zur Verfügung, damit die Pläne angepasst werden können. Ja, der Plan sollte angepasst werden, wenn Features hinzugefügt oder entfernt werden.

In einigen der Teams, mit denen ich zusammengearbeitet habe, würde ich nicht zögern, meine Schätzungen als unterzeichnete Verpflichtungen zu behandeln. Dies spiegelt jedoch die Qualität der Teams und des Managements wider und keine besonderen Fähigkeiten bei der Schätzung. Ein Team , das bereit ist, einen Vertrag zur pünktlichen Lieferung zu unterzeichnen, ist ein Indikator für ein gut funktionierendes Team und keine rote Fahne.

Ich sage, versetze dich in seine Lage und versuche zu verstehen, was das motiviert hat. Von potenziellen Managern / Buchhaltern benötigen sie eine Nummer, um zu rechtfertigen, was passiert ist und wie die Dinge laufen.

Es könnte sein, dass er sich im Sitzungssaal über Terminverschiebungen lustig machte und zu viele Termine verpasste. Er versuchte auf einfachste Weise, sie einzusperren. Geben Sie mir eine Nummer und unterschreiben Sie hier! Sie am anderen Ende zu sein, hätte nur wahrnehmen können, dass es etwas gegen Sie ist. Es ist jedoch nützlicher für ihn, Schätzungen vorzunehmen und gleichzeitig zu erkennen, dass sie angepasst werden müssen. Wenn Sie verstehen, was die Anfrage motiviert hat und mit welchem ​​Problem er konfrontiert ist, können Sie ihm und sich selbst helfen. Als Programmierer lösen wir Probleme. Das ist nicht anders, verstehe und löse sein Problem und er wird dein bester Freund sein. Es gibt so viel zu tun, dass niemand die Zeit hat, eine persönliche Rache zu schmieden! Er braucht Hilfe bei seiner Arbeit, die einfachste Lösung war, jemanden ein Papier unterschreiben zu lassen! Wahrscheinlich hat er das von einem Management für Dummies-Buch erhalten: "Lassen Sie Ihre Mitarbeiter unterschreiben und helfen Sie, für eine Nummer Rechenschaft abzulegen." Lustig aber traurig

"Auf dem Wasser laufen und Software anhand einer Spezifikation entwickeln ist einfach, wenn beide eingefroren sind."

- Edward V. Berard

Wenn sich Ihre Anforderungen ändern, können Sie nicht davon ausgehen, dass Ihre ersten Schätzungen korrekt sind. Ja, das sollte eine rote Fahne sein.

Gibt der Vertrag eine Vertragsstrafe für die Nichteinhaltung der Frist vor? Wenn dies nicht der Fall ist, ist dies überhaupt kein Problem. Sie unterschreiben lediglich eine Schätzung, die auf Ihrem aktuellen Wissen basiert.