it-swarm-eu.dev

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

Bei einer früheren Anstellung war ein Projektmanager (PM) mit der Lieferzeit des Codes für ein Projekt, an dem ich beteiligt war, nicht zufrieden. Mein Projektleiter sagte mir, dass die PM erwägen, mich einen Vertrag unterzeichnen zu lassen, um meine Zeitschätzungen zu sichern Ich gab für Aufgaben und Liefertermine.

Die Situation im Projekt war, dass wir mit neuen Technologien, Codebasis, Codierungsstandards und sehr anfälligen Änderungen arbeiteten. 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 stiegen um das 2-3-fache, wobei meine Schätzung bis zum Abschluss um das 5- bis 8-fache zunahm. Die einzigen Dinge, die sich nicht geändert haben, waren die Schätzungen und Liefertermine.

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

Damals schien es mir, dass der PM wollte, dass sich seine Zahlen summieren - und ich einen Vertrag unterschreiben sollte, um "sicherzustellen", dass ich den Arbeitscode immer pünktlich liefern würde. Ich nehme an Mit einem unterschriebenen Vertrag könnte der PM) ihn gegen mich verwenden, wenn ich nicht rechtzeitig liefern könnte.

Ich glaube, als nächstes haben mich andere Projektmanager und/oder Projektleiter verteidigt und dies nicht zugelassen.

Meine Frage lautet: Sollte dies eine rote Fahne über den Manager auslösen? Ist es üblich, dass ein Manager Zeitschätzungen eines Softwareentwicklers mit einem unterzeichneten Vertrag festlegt? Oder versuchen Sie es in diesem Fall.

Bitte beachten Sie, dass ich ein Vollzeitangestellter und kein unabhängiger Berater war.

pdate: Ich möchte hinzufügen, dass ich wöchentlich neue Schätzungen abgegeben habe, aber es scheint, dass die ursprünglichen Schätzungen und Liefertermine was waren das PM wurde fixiert auf.

116
spong

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

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 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 voller übermäßigem Optimismus ist. Es gibt einige Schätzsysteme, die in Zukunft bei Schätzungen helfen könnten, aber sie müssen historische Statistiken von Ihnen selbst sammeln. Einer ist PSP . Ein anderer ist Funktionspunkte . Viele Entwickler mögen beides nicht 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 das dann basierend auf dem, was Sie tatsächlich erledigen, mit dem, was Sie zu tun glaubten. Und verwenden Sie dies, um Ihre Schätzparameter zu ändern. In der Technik nennen wir dies " Feedback ".

109
Tangurena

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 unterschreiben, in dem alle Anforderungen eingefroren sind. Ich kann mir vorstellen, dass der Manager wahrscheinlich auf Kaution gehen würde. Dann würde ich gehen.

160
whatsisname

Nun, das ist einfach. Sagen Sie Ihrem Manager einfach, dass Sie unterschreiben, um Ihre geschätzte Zeit zu sichern, wenn er unterschreibt, um die Spezifikation zu sperren. Weil Sie sicher keine Schätzungen für etwas Unbekanntes liefern können. Vollständige Projektspezifikation vor dem Start, keine Änderungen - und Sie können sie rechtzeitig beenden :)

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

59
Slawek

Ja, das ist eine rote Fahne. Sie erfahren, dass der Manager nicht versteht, wie Risiken in Softwareprojekten zu managen sind. Was er tun sollte, ist herauszufinden, was genau die Verzögerung verursacht hat, und dann einen Prozess zu instrumentieren, um Zeitplanrisiken, die während eines Softwareprojekts unvermeidlich sind, effektiv zu managen.

NIEMALS würde ich einen Vertrag mit meinem Manager unterschreiben, der einen Zeitplan garantiert. Andere haben erwähnt, dass er ein Lock-In für Spezifikationen unterschreibt. Dies 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.

31
Pemdas

Dies ist keine rote Fahne, dies ist eine waffenfähige Dummheit.

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 wegläuft!

27
Steven A. Lowe

Während der Manager nicht mit seiner Forderung übereinstimmte. Er ist nicht voll schuld. Wenn Sie in einem völlig unbekannten Gebiet gearbeitet haben, ist es nichts Falsches, wenn Sie sagen: "Ich weiß nicht." Es hat eine Weile gedauert, bis mir klar wurde, dass "Ich weiß nicht" eine absolut akzeptable Antwort ist, also weiß ich, wie sehr es mich sticht, diese Worte auszusprechen. Aber wenn Sie es wirklich nicht wissen, dann ist das die Antwort. Und wenn sie sich dagegen wehren, bitten Sie sie, Ihnen eine Schätzung zu geben, wie viele Pennys erforderlich sind, um einen Stapel so hoch wie den Sears-Turm (machen Sie es Willis) zu machen. Und wären sie bereit, einen Vertrag zu unterschreiben, der Ihnen jeden Cent zahlt, den sie verloren haben?

Jeder Projektmanager, der sein Gehalt wert ist, sollte wissen, dass einige Dinge nicht gut und hübsch in eine Tabelle passen. Manchmal sind 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 Nummern zu aktualisieren.

Eine andere Übung besteht darin, die große Aufgabe in kleinere, schätzbarere Einheiten aufzuteilen. Diese Übung hilft Ihnen, besser zu verstehen, was Sie ebenfalls tun müssen. In Steve McConnells Software Estimation und Stephen Withalls Software Requirements Patterns finden Sie Tipps zum Aufteilen von Aufgaben und zum Erkennen versteckter Anforderungen.

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, andere sind jedoch vorbei und sie neigen dazu, sich gegenseitig abzuwägen) der großen Aufgabe.

19
Michael Brown

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

14
ThomasW

Ich bin ein Projektmanager und ein Programmierer :-) Ich könnte mich lange darüber austoben, wie die meisten PMs von außerhalb der Branche stammen und mit nichts umgehen können, was nicht gut in ein Produktionslinienmodell passt ... aber ich wird nicht, nicht hier. Stattdessen gibt es hier eine lange Polemik darüber, was tatsächlich 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 hier ist, was ich denke, am besten Ihr erster Schritt gewesen wäre. Oh, und die offensichtliche Antwort auf Ihre Frage lautet ja, aber das wird unten in einer farbenfrohen und detaillierten Sprache ausgearbeitet.

Bevor ich jedoch anfange, beachte, dass das PM höchstwahrscheinlich dir Kummer bereitet, weil jemand anderes weiter oben in der Nahrungskette ihnen Kummer bereitet. Sie (wir) sind einfache Kreaturen ... Es gibt Wege Um die von Ihnen beschriebene Situation zu vermeiden - Mike Brown deckt das ziemlich gut ab. Es ist auch nichts Falsches daran, etwas für 3/4/5 Stunden vor dem Start einzukaufen (tatsächlich müssen alle Arten von Alarmen ausgelöst werden, wenn dies nicht der Fall ist). t passieren). Und wenn Sie in unbekanntes Gebiet gehen, drücken Sie zurück und bitten Sie um eine Woche, um das Gebiet und die Technologien zu erforschen, um eine vernünftige Schätzung vornehmen zu können (Sie sollten dies richtig machen, weil Sie möchten, dass neue Technologien lernen & spielen Sie mit nicht wahr?). Wenn Ihr PM und das Management an dem Ort, an dem Sie sich befinden, dies nicht verstehen ... dann aktualisieren Sie Ihren Lebenslauf und suchen Sie nach dem nächsten Ausgang, Sie dem Schicksal zu überlassen, das sie so reich verdienen. Dass der PM) sogar daran denken würde, einen Vollzeitbeschäftigten dazu zu bringen, einen solchen Vertrag zu unterschreiben, ist ein schlechtes Zeichen n ... der einzige Weg, wie ich sehen konnte, dass sie nicht völlig inkompetent sind, ist, dass sie wirklich nur Gedankenspiele mit Ihrem Projektleiter und Ihnen spielten (Nach dem, was ich gelesen habe, haben sie dies nicht direkt an Sie weitergegeben und die Bedrohung letztendlich nicht weiterverfolgt). PMing ist schließlich ein Paradies für Ihren Standard-Unternehmenspsychopathen. Es war gut, dass andere nach Ihren Aussagen für Sie in die Fledermaus gegangen sind, also würden die folgenden Ratschläge dies tun habe sich am ende wohl positiv für dich herausgestellt. Ich kann mir vorstellen, dass sie eine Revolution in ihren Händen gehabt hätten, wenn sich herausgestellt hätte, dass es mehr als nur Reden war.

Also zu der tatsächlichen Situation/dem Loch, das Sie beschrieben haben, weil es irgendwo wieder jemandem passieren wird (wie vor ungefähr 5 Minuten und wieder in einem anderen 5, ScheduleRepeat ()). Wahrscheinlich ohne die Vertragsdummheit, aber die grundlegende Handlung ist immer dieselbe. Organisiere ein Meeting (!), Sie mögen Meetings ;-) Jeder kann sich am Ende auf den Rücken klopfen, als wäre tatsächlich etwas getan worden. WICHTIG : Stellen Sie sicher, dass Sie Ihren technischen Projektleiter/Teamleiter/Architekten/Designmanager in die Besprechungseinladung einbeziehen, nachdem 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 zieht sie im Allgemeinen wieder in Einklang , weil sie jetzt für jemanden sichtbar sind, der sie wahrscheinlich sofort entlassen kann. Wenn sie mit Ihnen spielen, dürfen Sie den Gefallen erwidern.

Gehen Sie in der Besprechung die technischen Details durch, 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 passiert ... Sie werden wahrscheinlich 10 Minuten Zeit haben, bevor ihre Augen wieder in ihren Kopf rollen. Was ich hier tun möchte, ist wahrscheinlich nicht legal ... Ja, ich habe nachgesehen, es ist höchst illegal und du willst nicht so lange ins Gefängnis. Der Punkt ist, dass Sie sich nach besten Kräften bemüht haben, proaktiv zu sein, und wenn Sie einige Höhere anwesend haben, liegt Ihr Schmerz jetzt bei ihnen ... so wie er sein sollte. Sie müssen Ihr Urteil darüber abgeben, wie sich die Dinge wahrscheinlich entwickeln werden, denn es kommt zu einer Eskalation. Wenn die Führung an dem Ort, an dem Sie sich befinden, halbwegs anständig ist, werden sie das Richtige tun und auch das Richtige von Ihnen. Wenn nicht, dann hätten Sie Ihren Lebenslauf vorher auf dem Markt veröffentlicht ... Sie würden sowieso bei der ersten Gelegenheit gehen (und es sieht so aus, als hätten Sie es letztendlich getan). Die Führung wird in zwei Gruppen unterteilt - entweder sind sie technisch versiert und sehen sofort Ihren Standpunkt; oder sind sie es nicht und was werden sie dagegen tun, außer zu grinsen und es zu ertragen? Wenn sie tun könnten, was Sie tun, dann würden sie es bereits tun.

Behalten Sie das Problem der sich ändernden Anforderungen als Ihre Trumpfkarte bei, die Sie am Ende verwenden können ... es wird als Ausgang für alle dienen. Das Projekt selbst und der verdammte Kunde/Stakeholder werden vergeblich benannt. Der schmerzloseste Weg wäre, eine Art Reset für das Projekt durchzuführen, und vielleicht würde das PM stillschweigend einem anderen Bereich zugewiesen werden. Gelegentlich geschehen Wunder. Wenn das Vertragsproblem auftrat In der Besprechung vom Premierminister angesprochen, dann mit der Forderung zurückgeschlagen, die Nachfrage nach Gegenverträgen einzufrieren - soweit es mich betrifft, haben sie bereits ihre Brücken mit Ihnen und dem gesamten Entwicklungsteam gebrannt, als sie anfingen, diese Art von Verstand zu spielen Spiele.

Bevor ich mich abmelde: Umfang/Anforderungen ändern - einer der besten Gründe, die Agile-Methodik zu übernehmen, damit die Kunden/Stakeholder ordnungsgemäß dafür verantwortlich sind, ihre Meinung über das zu ändern, was sie wollen ...

Oh, noch etwas: Bei der Aussage "Ich weiß nicht" war es immer mein persönlicher Maßstab, wie ich den Wert eines Technologen oder Mitglieds in einem meiner Projektteams beurteilen kann. Ich finde, die einzigen Menschen, die in der Lage sind zu sagen, dass direkt zu Ihrem Gesicht die besten sind, die es gibt, vor allem, weil jemand, der weiß, dass sie überfordert sind, dies niemals sagen wird - öffnet sie für die eindeutige Enthüllung durch jemanden mit tatsächlichen Fähigkeiten in ein Herzschlag. Auf der anderen Seite wird jemand, der vorgeht und es sagt, auch einen Grundplan (auch wenn er nicht durchdacht wurde) haben, wie man die Unbekannten angeht, damit es in 24 Stunden eine nützlichere Antwort gibt. und in einer Woche noch besser. Als Apollo 13 um die dunkle Seite des Mondes flog, passierte eine ganze Reihe von "Ich weiß nicht". Wenn Sie mit so etwas nicht umgehen können, sind Sie im falschen Spiel.

10
nomaderWhat

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

Dies weist darauf hin, dass der Manager keine Ahnung hat, wie er ein Projekt verwalten soll, das sich mit neuen/unbekannten Technologien und wechselnden Anforderungen befasst, die sich direkt auf den geschätzten Aufwand auswirken. Während manchmal harte Fristen auftreten, 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 Crunch-Zeiten werden schlecht sein, aber das ist wahrscheinlich selbstverständlich. Und trotzdem wird manchmal die Frist verrutschen. Es kommt vor, und wie bei einer anderen Person besteht die einzige Möglichkeit, sich an den Zeitplan zu halten, darin, die Anforderungen frühzeitig einzufrieren, damit noch genügend Platz vorhanden ist, um die Zeitachse beizubehalten.

Nach allem, was Sie gesagt haben, sind die Alarmglocken einige Monate zu spät. Es ist normalerweise riskant, ein zeitkritisches Projekt auf Technologien zu stützen, mit denen die Mitarbeiter noch nicht vertraut sind. Es ist tollkühn, dies zu tun, wenn Sie nicht mit dem Sammeln von Anforderungen und dem Scope-Management vertraut sind.

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

8
Larry Coleman

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

Es scheint, dass der PM nicht in den Entwicklungsprozess involviert sein möchte.

In meiner persönlichen Praxis habe ich mich lange nicht mehr mit detaillierten Vorabspezifikationen, Abmeldungen, vollständigen Projektschätzungen oder festen Gebotspreisen (aus beratender Sicht) befasst.

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

Viele Menschen haben immer noch Probleme mit dieser Vorstellung, und es klingt so, als ob Ihr PM auch). Es kommt auf ein einfaches Verständnis der Kompromisse an.

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

In der Software haben sich die Leute sehr an die Idee gewöhnt, dass die Kosten für Änderungen niedrig sind, und nutzen daher gerne die Möglichkeit, Dinge zu ändern, sobald sie eine Version sehen, und ein neues Verständnis für die Anwendung, das Geschäft und den Kunden zu entwickeln eine fortlaufende 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 PMs) möchten eine kontinuierliche Traktion sehen. Hierher kam die iterative Entwicklung mit ihren kleinen, inkrementellen Funktionsfreigaben. Es gibt andere Methoden, die verwendet werden können, z. B. die testgetriebene Entwicklung, um sicherzustellen, dass die Änderungskosten niedrig bleiben und die technischen Schulden begrenzt sind.

Damit dies funktioniert, ist ein "Vertrag" zwischen beiden Seiten, dem Product Owner (Agile Speak for Your PM oder Kunden oder QA-Team) und den Entwicklern) erforderlich. Entwickler erklären sich damit einverstanden, nur an priorisierten Dingen zu arbeiten Dies ist für die gegebene Iteration am wichtigsten und sollte nicht ewig dauern, sondern sich bemühen, häufig (z. B. wöchentlich oder monatlich) vollständig integrierte Funktionsblöcke freizugeben. Umgekehrt stimmen Produktbesitzer zu, die inkrementellen Versionen kontinuierlich zu überprüfen und umgehend Feedback zu geben Stimmen Sie auch zu, die Prioritäten für die nächste Iteration festzulegen und einmal 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 tatsächlich nicht. Einige von ihnen denken, dass ihre Arbeit erledigt ist, wenn sie die Spezifikation abgeben; sie Ich möchte nicht über Probleme, Alternativen, bessere Wege usw. hören. Der Nachteil ist, dass dies nicht nur dem Fluss der Softwareentwicklung entgegenwirkt, sondern auch der Organisation schadet, indem viele Möglichkeiten auf dem Tisch bleiben.

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

Viel Glück.

4
Wolfram Arnold

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

Ich finde, wenn Sie einen unvernünftigen Manager haben, der der Meinung ist, dass eine „Schätzung“ mit einer „festen Periode“ identisch ist, ist es am besten, sich eine sehr großzügige Schätzung vorzustellen und diese dann zu verdoppeln!

Erzwingen Sie außerdem, dass der Manager sicherstellt, dass die Anforderungen vollständig detailliert und festgelegt sind. Änderungen von da an werden nicht ohne eine "formelle Neuverhandlung" mit dem Projektmanager über die neue Fertigstellungszeit behandelt.

Schließlich kommt der Projektmanager auf die Idee und plant entsprechend.

4
martinws

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

2
PSU

Rundum gute Antworten, aber lassen Sie mich meine 2 Cent hinzufügen.

Wenn Sie jemals die Wahrscheinlichkeit untersuchen, 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 Normalverteilung (Glockenkurve) oder einer anderen.

Der Punkt ist, dass die Arbeit einige Zeit in Anspruch nehmen wird, aber jede vorherige Schätzung wird ein wenig oder viel falsch sein, auf der negativen oder positiven Seite, so dass ein Risiko besteht und jemand das Risiko eingehen muss. Wenn Menschen ein Risiko eingehen, werden sie im Allgemeinen dafür bezahlt. Versicherung kostet Geld.

Als Berater hatte ich normalerweise die Wahl, einen Zeit- und Materialvertrag gegenüber einem Festpreisvertrag zu unterzeichnen. Mit Zeit und Material trägt der Kunde das Risiko. Beim Festpreis trage ich das Risiko. Mit dem Festpreis baue ich einen Sicherheitsspielraum ein, denn wenn ich das Ziel nicht erreiche, gewinnt niemand.

Wenn Sie aufgefordert werden, sich auf einen festen Liefertermin festzulegen, insbesondere ohne feste Anforderungen, versuchen Sie, das Risiko auf Sie zu übertragen, auch wenn nicht klar ist, was Sie tatsächlich riskieren. In jedem Fall besteht eine Antwort einfach darin, einen wirklich großzügigen Sicherheitsspielraum einzurichten.

P.S. Sie sehen dies die ganze Zeit bei Regierungsaufträgen. Es gibt eine erste Aufforderung zur Einreichung von Vorschlägen, Gebote werden abgegeben, ein niedriges Gebot wird angenommen, und dann gehen die Änderungsanfragen ein, sodass die Kosten steigen und der Auftragnehmer beschuldigt wird. Die Dinge funktionieren viel besser, wenn es eine Teamarbeitsbeziehung zwischen Auftraggeber und Auftragnehmer gibt, als eine kontroverse.

1
Mike Dunlavey

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

-Edward V. Berard

Wenn sich Ihre Anforderungen ändern, ist es nicht zumutbar, dass Ihre anfänglichen Schätzungen korrekt sind. Ja, das sollte eine rote Fahne sein.

0
Bill the Lizard

Ja, dies wirft natürlich ein Zeichen für die Erfahrung und Kompetenz Ihres ehemaligen Chefs. Ja, wie die meisten Leute vorgeschlagen haben, wäre 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 Situationen geben kann, in denen Sie eine Unterzeichnung in Betracht ziehen könnten.

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

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

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 Schritt ablehnen ... es sei denn, Sie werden gut entschädigt.

Wenn Sie in der Lage sind, Ihre Frist mit einer für beide Seiten akzeptablen Menge an Polstern zu benennen, um unerwartete Verzögerungen zu bewältigen, und in der Lage sind, einen (sehr großen) Bonus auszuhandeln, wenn Sie ihn erreichen, und in der finanziellen Lage sind, die Frist zu bewältigen Strafen (z. B. gefeuert werden) Wenn Sie dies nicht können, ist es möglicherweise ein lohnendes "Glücksspiel", dieses Risiko selbst zu akzeptieren und den Vertrag zu unterzeichnen - mit geeigneten Klauseln, um Änderungen der Anforderungen zu bewältigen.

0
Oddthinking

Ich sage, versetzen Sie sich in seine/ihre Schuhe und versuchen Sie 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 im Sitzungssaal verspottet wurde, weil er Fristen verschoben hatte und zu viele Fristen verpasst hatte. Er versuchte auf einfachste Weise, sie einzusperren. Geben Sie mir eine Nummer und unterschreiben Sie hier! Wenn Sie am anderen Ende sind, hätten Sie nur erkennen können, dass es etwas gegen Sie ist. Wie auch immer, Schätzungen vorzunehmen und zu erkennen, dass sie angepasst werden müssen, ist für ihn nützlicher. Wenn Sie verstehen, was die Anfrage motiviert hat und was das eigentliche Problem ist, mit dem er konfrontiert ist, können Sie ihm und sich selbst möglicherweise 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 planen! Er braucht Hilfe bei seiner Arbeit, die einfachste Lösung war, jemanden ein Papier unterschreiben zu lassen! Wahrscheinlich bekam er das von einem Management für Dummies-Buch: "Lassen Sie Ihre Mitarbeiter unterschreiben und helfen Sie, für eine Nummer verantwortlich zu sein." Lustig aber traurig

0
Arjang

Das ist geradlinige Dummheit. Ich weiß nicht, was das ultimative Ziel war, aber jeder halbwegs anständige Projektmanager, der für Softwareprodukte verantwortlich ist, sollte sich bewusst sein, dass Schätzungen genau das sind, was sie genannt werden: Schätzungen. Sie sind keine Versprechen und können auch 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 das Projekt bis zu dem Punkt, an dem es 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 dies die Korrektur von Rechtschreibfehlern umfasst. Nach meiner Erfahrung gibt es kein einziges Softwareprojekt, bei dem sich die Anforderungen zu einem bestimmten Zeitpunkt 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 verrückt sind.

Wie würde ein Vertrag für einen Vollzeitbeschäftigten überhaupt funktionieren? Ich weiß nichts über Arbeitsvorschriften in anderen Ländern, aber als Vollzeitbeschäftigter in einem Unternehmen glaube ich nicht, dass jemand Sie 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 dafür brauchen sie keinen Vertrag. Niemand könnte dich feuern oder dir weniger Geld geben. Sie könnten Ihren vereinbarten Bonus im schlimmsten Fall kürzen. Wenn dies in anderen Ländern nicht anders ist, scheint dies eher eine leere Bedrohung zu sein als alles, was Sie ernst nehmen sollten.

0
Anne Schuessler

Ich werde hier gegen den Strich gehen.

Die von Ihnen beschriebene Situation ist auf der Ebene Engineering Team nicht allzu ungewöhnlich, insbesondere nach einem besonders späten Projekt/Release. In vielen Situationen haben Ihr Management und Ihre gesamte Organisation möglicherweise angemeldet für ein bestimmtes Veröffentlichungsdatum, und andere Teile der Organisation werden auf dieses Datum vorbereitet. Es kann enormen Druck auf Ihre Managementkette geben, dieses Datum zu erreichen.

Hier kommt ein allgemeiner Engineering-Prozess ins Spiel. Sie haben wahrscheinlich schon vom Wasserfallmodell gehört. Es gibt andere Modelle, aber das Endziel von allen ist es, konsequent etwas zu liefern wann es wird erwartet und enthält was wurde vereinbart. Funktionale Spezifikationen, Designs, Aufgabenlisten usw. tragen dazu bei, dass dies ein vorhersehbarer Prozess ist. 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 Pläne angepasst werden können. Und ja, es sollte Anpassungen am Plan geben, wenn Features hinzugefügt oder entfernt werden.

In einigen der Teams, mit denen ich zusammengearbeitet habe, würde ich meine Schätzungen ohne zu zögern als unterzeichnete Verpflichtungen 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 zu unterschreiben für die pünktliche Lieferung ist ein Indikator für ein gut funktionierendes Team, keine rote Fahne.

0
TREE