Umgang mit unrealistischen Fristen [Duplikat]

Wenn es eine unrealistische Frist gibt, muss einer der folgenden Schritte eintreten:

1. a. Verlängerung der Frist / b. über die Frist hinaus liefern.
2. Drop-Funktionen.
3. Drop-Qualität (erwarten Sie hier und da den einen oder anderen Absturz oder Datenverlust).
4. Bringen Sie jemanden hoch qualifizierten hinzu, der einen wesentlichen Beitrag zu der Arbeit leisten kann, das ist teuer.
5. Lächerliche Stunden arbeiten und sich dadurch krank machen, mit zweifelhaften Folgen.

Was nicht funktioniert, aber was Ihr Management zu tun scheint, ist

6. Schließen Sie Augen und Ohren vor jedem, der Ihnen sagt, dass die Frist in Gefahr ist.

Nummer 5 hat den Nachteil, dass es dich krank macht, ohne Vorteile für dich (das Unternehmen wird keine Überstunden zahlen oder dir danken, aber erkennen, dass du ausgenutzt werden kannst), und es hilft sowieso nicht viel , also ist dies die Option, die Sie um jeden Preis vermeiden und ablehnen müssen.

Ich würde vorschlagen, eine Liste von Funktionen zu erstellen, die weggelassen werden könnten, während man noch ein nützliches Produkt hat, und eine Liste von Punkten, wo die Qualität weggelassen werden kann, einschließlich der offensichtlichen Konsequenzen. Ihr Management muss dann entscheiden, was zu tun ist. Weisen Sie sie gegebenenfalls darauf hin, dass Option 6 nicht funktioniert (vorsichtig vorgehen) und dass Option 1b. wird automatisch passieren.

Was Sie betonen müssen, ist, dass die Frist ohne Maßnahmen nicht eingehalten wird.

Erstens - akzeptieren Sie, dass es nicht in Ordnung ist, wenn dies wirklich der Fall ist. Zu viele Programmierer nehmen ihre Arbeit mit nach Hause und schweigen zu diesen Themen und lassen das Management im Dunkeln (auch wenn sie es nicht zu sein scheinen).

Sie möchten auch niemals ein Problem ohne eine Art Argumentation oder Lösung präsentieren. Dazu ist Kommunikation der Schlüssel. Teilen Sie Ihrem Vorgesetzten nicht nur mit, dass Sie eine Deadline nicht einhalten können, sondern verfeinern Sie die Art und Weise, wie Sie dies kommunizieren.

Wenn ich an Ihrer Stelle wäre, würde ich die Arbeit in einzelne Punkte aufteilen und jeden von ihnen mit einem Zeitplan und Fristen versehen. Sie können dies dann verwenden, um genau zu kommunizieren, warum die Frist nicht eingehalten werden kann, mit harten Daten, auf deren Grundlage das Unternehmen eine Entscheidung treffen kann. Wenn Sie damit einverstanden sind (abhängig von Ihrem Niveau und dem Team), können Sie sogar einige Kompromisse vorschlagen, die eingegangen werden könnten (mit Änderungen oder Ihrem eigenen Zeitplan), um das Projekt wieder auf Kurs zu bringen.

Sollte dies nicht funktionieren, aktualisiere ich häufig weiterhin ein Arbeitsblatt, wenn das Projekt beginnt, und sende wöchentlich (oder bei Bedarf täglich) eine Zusammenfassung der abgeschlossenen Arbeitselemente, aller Hindernisse für die Erledigung der Arbeit und des prognostizierten Zeitplans.

Zunächst einmal klingt es so, als würde Ihr Unternehmen das Konzept von Fristen und Schätzungen missbrauchen - Schätzungen sind Schätzungen und das ist alles, was sie sind. Niemand sollte jemals erwarten, dass eine Schätzung genau in eine Frist passt, und die Frist sollte für genau diese Situationen einen sehr vernünftigen Sicherheitspuffer gegenüber der Schätzung haben. Eine frühere Lieferung ist in Ordnung, eine Lieferung nach Ablauf der Frist nicht.

Ergänzend zu den vorherigen Antworten und basierend auf meinen bisherigen Erfahrungen könnte dies aus einem einfachen Grund genauso gut ein Kommunikationsproblem sein - Führungskräften fehlt es oft an technischen Fähigkeiten und Verständnis, und einfach gesagt, sie unterschätzen die Bedeutung der Softwarequalität, die a ist in diesem Fall offenbar wirklich notwendig, da Sie sagten, dass eine Menge Refactoring erforderlich sein wird. Auf dieser Grundlage sollten Sie dem Management wahrscheinlich mitteilen, dass es später mehr kosten wird, da die technischen Schulden nur zunehmen und das bereits bestehende Problem nicht einfach verschwindet, wenn es verschoben wird – es wird an Schwere zunehmen, wenn Sie mehr und mehr hinzufügen Komplexität des Projekts, und diese Zunahme wird exponentiell sein, bis zu dem Punkt, an dem die Aufrechterhaltung des Projekts riesige Mengen an Ressourcen verschlingt. ich nicht

Wenn dies ein Insider-Produkt ist, sollte das Argument, dass wir tatsächlich etwas produzieren sollten, das gut funktioniert, statt eines halbgebackenen Kuchens, mit Bravour durchgehen.

Wenn es sich um ein Produkt für einen externen Kunden handelt, sogar noch mehr - die Leute sind normalerweise vernünftig genug, Fristverlängerungen zu akzeptieren, wenn dies bedeutet, dass sich das Endergebnis um eine Größenordnung verbessert.

Zu guter Letzt sollten Sie herausfinden, warum diese grobe Unterschätzung überhaupt passiert ist, und einen Mechanismus einrichten, der dies in Zukunft verhindert - waren die Techniker nicht an Schätzungen beteiligt? Wurde etwas Wichtiges von den Schätzungen ausgeschlossen, und wenn ja, warum? Und wenn ja, warum wurde die Frist nicht verlängert, nachdem sie sich als unrealistisch erwiesen hatte?

Entschuldigung, aber ich denke, Sie nähern sich dem Problem zu sehr von einem technischen Standpunkt aus. Es ist einfach, dem Management vorzuwerfen, nicht vernünftig zu sein, besonders wenn es nicht technisch versiert ist, aber Sie verlieren Kunden. Das ist eine Realität.

Wie in allen Notfallsituationen (schwere Verluste und Schäden mit wenig Zeit und Ressourcen) müssen Sie eine Sichtung durchführen. In Ihrem Fall muss dies sowohl im Refactoring- als auch im Feature/Requirements-Bereich geschehen. Holen Sie sich diese beiden synchron, wenn möglich. Wenn Funktion A dabei hilft, die meisten Clients zu halten, refaktorisieren Sie diesen Teil der Codebasis bei Bedarf. Beschränken Sie das Refactoring zumindest auf Bereiche, die für Ihre Kunden am wenigsten interessant sind. Mir ist klar, dass Sie möglicherweise allgemeine Bereiche, Dienstprogramme oder Frameworks umgestalten.

Ich bin skeptisch gegenüber dieser großen Umgestaltung in einer Zeit, in der Kunden mit Ihrer Bewerbung nicht zufrieden sind. Reparieren Sie, was Sie haben, um ihre Probleme zu lösen. Wenn Sie mich über den Fluss bringen können, brauche ich keine neue Brücke.