Ich bin Entwickler in einem 5-köpfigen Team und glaube, dass unser Projekt auf eine Katastrophe zusteuert. Ich beschreibe gleich, warum, aber meine Frage lautet: Wie soll ich mich verhalten?

Die Frist beträgt 1,5 Monate, und ich glaube, egal was wir tun, dieses Projekt wird scheitern. Ich bin der Meinung, wir sollten das Projekt einfach beenden und aufhören, unsere Zeit zu verschwenden, aber politisch denke ich, dass es für unseren Manager unmöglich ist, dies zu tun.

Was soll ich in diesem Fall tun? Sollte ich mich besonders anstrengen oder sollte ich es einfach ruhiger angehen lassen? Und was soll ich dem Manager sagen?

Gründe für das Scheitern dieses Projekts:

• Kurz vor dem Abgabetermin sind viele der unverzichtbaren Funktionen noch nicht fertig
• Die Anwendung ist instabil und sehr schwierig zu bedienen
• Das System ist sehr kompliziert, der Code sehr schwer zu verstehen und nur schwer zu ändern. Das Datenmodell wird zu stark von einer komplexen relationalen Datenbank (über 100 Tabellen) bestimmt.
• Unklare Führung; Der Manager reagiert auf neue Informationen mit wesentlichen Änderungen
• Fast keine automatisierten Tests oder Unit-Tests
• Hängt stark von anderen Systemen ab, aber noch keine Integrationstests

Tatsächlich haben wir dieses Projekt (zusammen mit dem Durcheinander) vor ungefähr ein bis zwei Monaten von einem anderen Entwicklerteam unter demselben Manager geerbt, der einige Monate daran gearbeitet hat.

Kommunizieren Sie Ihre Bedenken auf der Management-Leiter so knapp und konfliktfrei wie möglich. Fassen Sie die Risiken zusammen, aber zwingen Sie sie nicht zu Ihrer Schlussfolgerung.

Das Management muss immer die Wahl haben, was zu tun ist, aber es ist Ihre Aufgabe, die Situation zu bewerten und zu kommunizieren. Verwenden Sie E-Mail, um eine Papierspur zu hinterlassen, wenn die Dinge nach Süden gehen.

Nachdem Sie dies getan haben, arbeiten Sie in gutem Glauben weiter an dem Projekt.

Denken Sie daran, dass Sie möglicherweise nicht alles über das Projekt, seine Unterstützer und die finanziellen Entscheidungen wissen, die dahinter stehen. Managemententscheidungen, die Ihnen dumm erscheinen, basieren möglicherweise auf intelligenten Argumenten, die für Sie nicht sichtbar sind.

Führen Sie eine Papierspur (z. B. Tagebuch, gespeicherte E-Mails usw.). Schließen Sie nur Tatsachen und objektive Beobachtungen ein. Überlassen Sie alle Schlussfolgerungen demjenigen, der liest, was Sie geschrieben haben.

Wenn Sie als Entwickler nicht als Hindernis für das Projekt angesehen werden, ist es wahrscheinlich, dass Sie einen guten Eindruck davon bekommen, dass Sie mit dem Finger darauf zeigen, was zweifellos passieren wird. Ihr Manager mag nicht so glücklich sein, aber das ist hier nicht relevant.

Aktualisieren Sie Ihren Lebenslauf nach allgemeinen Grundsätzen und stellen Sie sicher, dass Sie sich gelegentlich mit anderen Entwicklern außerhalb Ihres Unternehmens treffen. Wenn Sie keiner lokalen Entwicklergruppe angehören, schließen Sie sich 2 oder 3 an. Es dauert Jahre, um ein Netzwerk von Freunden und Bekannten aufzubauen, aber auf lange Sicht lohnt es sich. Stellen Sie sicher, dass es sich um eine Einbahnstraße handelt. Wenn Sie dazu beitragen können, eine Stelle in Ihrem Unternehmen mit einer kompetenten Person zu besetzen, ist dies genauso gut wie mit einer Person, die Ihnen bei der Jobsuche hilft.

Ich empfehle Ihnen, sich ein wenig Zeit zu nehmen, um 2 Bücher zu lesen.

Der Todesmarsch ist das kanonische Buch, das einen pathologischen Projektmanagementstil beschreibt, der in der Softwareentwicklung weit verbreitet ist. Aufgrund von Zeitplankomprimierung, Funktionsüberlastung oder Missmanagement geraten viele Projekte in einen schlechten Zustand. Es hilft zu verstehen, dass Sie nicht allein sind und Ihr Projekt nicht der einzige Todesmarsch ist. Der Autor Edward Yourdon unterteilt Sackgassenprojekte in vier Quadranten, von denen jeder eine andere Bewältigungsstrategie verfolgt. Manchmal ist die einzige Bewältigungsstrategie, wegzugehen. Ich denke, dieses Buch wird Ihnen dabei helfen, herauszufinden, welche Möglichkeiten Sie haben und was Sie nicht können.

Katastrophenentflechtung ist eher für Projektmanager gedacht . Ziel ist es herauszufinden, wie man ein kaputtes Projekt ausfindig macht: Was muss geschnitten werden, was kann zurückgeschnitten werden und wie kann man dies den Kunden vermitteln? "Konventionelles" Software-Projektmanagement bringt uns in unübersichtliche Projekte, und wir werden uns unseren Problemen nicht entziehen, wenn wir die gleichen Überlegungen verwenden, mit denen wir uns überhaupt befasst haben. Dieses Buch ist etwas schwerer zu lesen als der Todesmarsch , aber es ist gut, es in Ihrem Bücherregal zu haben.

3 einfache und zynische Strategien zur Aufrechterhaltung der Karriere / geistigen Gesundheit.

1. Sehen Sie ein Zugunglück in der Entstehung - steigen Sie aus dem Zug aus: Fehlgeschlagene Projekte sind für die Moral schrecklich, und wenn Sie nicht über Ninja-Managementfähigkeiten verfügen, wirkt sich dies negativ auf Ihre Karriere aus. Spring jetzt, wenn du eine weiche Landung siehst.

2. Wenn das nicht funktioniert, bleiben Sie ruhig: Die Leute werden nach Schuldigen suchen - machen Sie es ihnen nicht leicht! Obwohl es zu einer Eskalation von Bedenken in der Managementkette kommt, ist dies sowohl ineffektiv als auch riskant. Es ist unwahrscheinlich, dass Ihr eigener Vorgesetzter Ihre Bedenken weitergibt, und wenn Sie ihn umgehen, werden Sie nicht nur schlecht aussehen, sondern Sie könnten auch als "Unruhestifter" eingestuft werden, d. H Das heißt natürlich auch, professionell zu sein, in die eigenen Stunden zu stecken, aber keine Heldentaten.

3. Planen Sie einen Notausgang für T + 1: Geben Sie sich einige Optionen und bereiten Sie jetzt die Voraussetzungen für einen möglichen internen oder externen Transfer vor. Mit Leuten reden; Es gibt keinen Grund, auf andere zu warten, um zu entscheiden, was mit Ihnen geschehen soll, wenn die Projektfinanzierung gekürzt wird, oder um von der unvermeidlichen „Flut“ von Menschen überschwemmt zu werden, die in ein paar Monaten abwandern.

Entschuldigung, wenn es zu zynisch klingt, aber wenn Sie es richtig genannt haben, ist es kein Vorteil, die Unannehmlichkeit zu ertragen, die auf Sie zukommt. Seien Sie professionell, optimistisch, aber immer realistisch.

Welche Auswirkungen hat dieses bald gescheiterte Projekt auf Ihre Karriere in der Firma und darüber hinaus? Nach meiner Erfahrung ist es kein Indikator für Ihre persönliche Exzellenz, nur mit erfolgreichen Projekten in Verbindung gebracht zu werden.

Die Qualitäten, die Sie angesichts von Widrigkeiten und manchmal scheinbar sicherem Scheitern aufweisen, werden von den Höheren oft stärker wahrgenommen, als Sie denken. Und ich spreche über Ihren direkten Vorgesetzten hinaus.

Ich habe persönlich erlebt, wie mein direkter Vorgesetzter wegen Inkompetenz entlassen wurde, und bin dann noch am selben Tag in seine Position befördert worden. Nicht angenehm, aber es zeigte, dass die Leute mich beobachteten und mochten, was ich tat.

Das gleiche Chaos und die gleiche Desorganisation, die mit einem scheiternden Projekt einhergeht, bietet Ihnen oft die Möglichkeit, zu glänzen.

Schauen Sie sich das Projekt also so an: Welche Gelegenheit bietet dieses scheiternde Projekt, damit das Licht auf all meine Stärken und besten Eigenschaften scheint? Welche Lektionen lerne ich aus dieser Erfahrung, die mich zu einem besseren Fachmann und einer besseren Person machen wird?

Im Wesentlichen ist die Summe der Erfahrungen aus Fehlern der Grund für den Erfolg.

Hinweis: Thomas Owens hat gefragt, was eine Person in einem solchen Projekt genau tun kann. Ich habe einige allgemeine Vorschläge, die ich in diesen Situationen als persönliche Richtlinien verwendet habe. Hilft es einem Notprojekt, auf wundersame Weise erfolgreich zu sein? Nein - aber ich habe festgestellt, dass es mir geholfen hat, die Dinge im Blick zu behalten und trotz der schlechten Situation persönlichen Erfolg zu haben.

1) Konzentrieren Sie sich auf persönliche Exzellenz - bemühen Sie sich, immer besseren Code zu schreiben und immer höhere Qualitäts- und Funktionsstandards zu erfüllen.

2) Konzentrieren Sie sich auf persönliche Metriken - wie viel Code schreiben Sie, der nachfolgende Fehler hervorruft? Reduzieren Sie dieses Verhältnis so niedrig wie möglich. Sind Sie im Allgemeinen korrekt, wenn Sie aufgefordert werden, einen Kostenvoranschlag für eine Ihnen zugewiesene Aufgabe zu erstellen, oder stellen Sie fest, dass Sie die Zeitachse zu stark über- / unterpuffert haben? Bieten Sie, wenn Sie tatsächlich eine Aufgabe zugewiesen bekommen, ein gutes Feedback zum Fortschritt der Arbeit, einschließlich einer frühzeitigen Benachrichtigung über Probleme mit der Lieferfrist?

3) Konzentrieren Sie sich auf Teamkennzahlen - Dies sind nur einige Dinge, die mir völlig verborgen bleiben: Sind andere Teammitglieder aufgrund der Abhängigkeit von einer Aufgabe, an der Sie arbeiten, im Rückstand? Können Sie Ihre Aufgaben / Unteraufgaben gut an andere Teammitglieder delegieren oder aufteilen? Fällt es Ihnen schwer, mit einem oder mehreren Teammitgliedern zu kommunizieren? Alle Bereiche, an denen ich arbeite, um mich regelmäßig zu verbessern.

In einer Situation wie dieser, als unterste Sprosse der Leiter, können Sie nur so viel tun, um dem Projekt zu helfen.

• Stellen Sie sicher, dass Ihre Arbeit makellos ist
• helfen, die größten Problembereiche zu identifizieren
• Versuche Antworten zu geben, nicht nur Probleme. Sieh aus, als würdest du versuchen, sie zu reparieren.

Ansonsten muss man sich wirklich um die Nummer 1 kümmern.

• Alles dokumentieren
• Bewahren Sie alle E-Mails und Sofortnachrichten auf
• Versuchen Sie, wenn möglich, einen Ausweg aus dem Projekt zu finden

Fehlgeschlagene Projekte können für die Seele giftig sein, zu Depressionen, Überarbeitung und geringem Selbstwertgefühl führen.

Es ist alles relativ zur Perspektive.

Ich habe an schrecklichen Projekten gearbeitet, als ich einem anderen Mann gegenüber saß, der jeden Tag ein Lächeln auf den Lippen hatte. Oh, wie wollte ich ihm dieses Lächeln verpassen?

Manche Leute stören sich nicht an dem aktuellen Stand der Dinge in einem Projekt. Sie genießen ihren Beitrag, ihre Aufgaben und arbeiten im Bereich ihrer Interessen. Während andere eine stark negative Reaktion auf den aktuellen Stand der Dinge haben. Es dreht sich alles um unsere wahrgenommenen Erwartungen an unsere täglichen Jobs.

Während Sie vielleicht einen Teil der Arbeit erledigen, die Ihnen Spaß macht. Das aktuelle Projekt enthält eindeutig Elemente, die Sie nicht mögen.

Sie müssen die Problemelemente identifizieren und beheben.

• Termindruck
• Qualitätskontrolle
• Professionalität
• Führung durch das Management

Es gibt viele Teams und Unternehmen, die die oben genannten Aspekte der Entwicklung nicht für wichtig halten. Was ich gefunden habe, ist, dass sie oft Folgendes denken.

• Termindruck wird als Motivationsmittel für Menschen empfunden.
• Qualität kostet mehr und bringt Grenze zurück.
• Professionalität gilt auch für andere Geschäftsbereiche.
• Ein Manager ist ein Zeitnehmer und keine Person, die zur Entwicklung beiträgt.

Diese Probleme gehören dir nicht. Es gehört ihnen und du solltest keine Energie für ihr Verhalten verschwenden. Wenn Sie nicht zu den Leuten gehören, die lächeln und Spaß an seinem Job haben, auch wenn er auf eine Klippe zusteuert, sollten Sie darüber nachdenken, einen Platz für like mindedEntwickler zu finden.

Sie werden viel glücklicher sein.

Versuchen Sie proaktiv einen neuen Weg zu finden, um Erfolg für das Projekt zu erzielen. Überlegen Sie, wie Sie Alternativen vorschlagen können. Im Moment wird Ihr Chef wahrscheinlich verprügelt, dass das Projekt gescheitert ist. Würde er es nicht begrüßen, wenn jemand mit Lösungen anstelle von Problemen hereinkommt?

Vielleicht gibt es eine Möglichkeit, die Funktionen in gestaffelte Ergebnisse aufzuteilen? Es gibt oft Grade von "muss haben", also sehen Sie, ob Sie diese priorisieren und in Meilensteine ​​gruppieren können. Lieber ein Produkt am Ende der Timeline als nichts. Oder überlegen Sie sich, das Team zwischen Mitarbeitern aufzuteilen, die an neuen Funktionen arbeiten, und Mitarbeitern, die an der Stabilität arbeiten. Auf diese Weise können Sie an beiden Fronten Fortschritte erzielen.

Wenn diese Bemühungen erfolgreich sind, haben Sie gezeigt, dass Sie ein Teammitglied sind, das einen Weg zum Erfolg finden kann. Andernfalls haben Sie immer noch bewiesen, dass Sie nicht aufgeben und daran arbeiten, eine Lösung zu finden.

Klingt wie die meisten Projekte, an denen ich gearbeitet habe. Es wird jedoch wahrscheinlich nicht so schlimm enden, wie Sie denken:

1) Mach deinen Job. Sorgen Sie sich nicht so sehr um das Gesamtprojekt, solange Sie Ihre Aufgaben erfüllen.

2) CYA. Wenn das Projekt fehlschlägt und Sie vermuten, dass der Manager anfängt, alle außer sich selbst zu beschuldigen, stellen Sie sicher, dass Sie über ausreichende Nachweise verfügen, dass Sie alle von Ihnen geforderten Maßnahmen ergriffen haben (siehe Punkt 1).

3) Machen Sie ein paar höfliche Verbesserungsvorschläge. Lass die Warnglocken nicht läuten, sei nicht finster und finster, sei nur höflich und subtil.

Wenn das Team beispielsweise keine effektiven Komponententests (oder Tests) schreibt, schreiben Sie ein paar Komponententests näher an das, was Sie sehen möchten, und erwähnen Sie kausal, wie Ihnen dies bei der Lösung eines bestimmten Problems geholfen oder Zeit gespart hat.

Was auch immer es sein mag, wenn Sie Veränderungen bewirken wollen, konzentrieren Sie sich auf die positiven Schritte, die konkrete Ergebnisse haben. Dieses Projekt wird vielleicht nie ein Gewinner, aber vielleicht kann das Team für das nächste lernen.

Ebenfalls:

4) Opportunistisches Refactoring ist dein Freund.

1. Hart arbeiten; aber nicht auf Kosten Ihrer Familie oder Ihrer Gesundheit.
2. Führen Sie ein Protokoll aller kritischen Entwurfsentscheidungen. vor allem, weil sie zu Ihrer Arbeit gehören.
3. Bleiben Sie vernetzt und behalten Sie Ihre Möglichkeiten offen, wenn die Situation zu schwierig wird oder Sie Opfer einer Massenentlassung werden.
4. Versuchen Sie nicht zu denken , Ihr Projekt als „gescheitertes Projekt“. Jeder mag Menschen, die positiv bleiben und hart gegen Widrigkeiten kämpfen. Versuchen Sie also so lange wie möglich, diese Person zu sein. Ein positiver Ausblick, eine positive Einstellung und Entschlossenheit sind immer gut für den Arbeitsplatz.
5. Wenn Sie ein gescheitertes Projekt erwarten, dann erwarten Sie ein Post-Mortem-Meeting. Bei der Obduktion werden alle zur Rechenschaft gezogen. Seien Sie bereit, Ihren gesamten Code zu verteidigen. [Hinweis: In der Regel sollten Sie immer sauberen Code schreiben, damit er später problemlos verteidigt werden kann.] Wenn Sie eine E-Mail oder ein Designdokument haben, das Sie zu Ihren Entscheidungen inspiriert hat, ist dies sogar noch besser.
6. Versuchen Sie bei diesem Post-Mortem-Treffen, positiv zu bleiben. und legen Sie Ihre E-Mail- und Designdokumente nur dann vor, wenn Ihre Beurteilung, Ihr Aufwand oder Ihre Verarbeitung in Frage gestellt werden.

Was ich als am effektivsten empfunden habe, ist die Empfehlung von Robert L. Read, wie man gegen den Zeitplandruck vorgeht . Folgendes schreibt Read:

Der Schlüssel zur Bekämpfung des Zeitplandrucks besteht einfach darin, ihn in Zeitdruck umzuwandeln. Auf diese Weise erhalten Sie einen Einblick in die Beziehung zwischen verfügbarer Arbeitskraft und Produkt. Eine ehrliche, detaillierte und vor allem nachvollziehbare Schätzung aller anfallenden Arbeitskräfte ist der beste Weg, um dies zu erreichen. Es hat den zusätzlichen Vorteil, dass gute Managemententscheidungen über mögliche Kompromisse bei der Funktionalität getroffen werden können.

Die wichtigste Erkenntnis, die die Schätzung verdeutlichen muss, ist, dass Arbeit eine fast inkompressible Flüssigkeit ist. Sie können nicht mehr in eine Zeitspanne packen als mehr Wasser in einen Behälter, der über das Volumen dieses Behälters hinausgeht. In gewissem Sinne sollte ein Programmierer niemals "Nein" sagen, sondern "Was werden Sie aufgeben, um das gewünschte Ding zu bekommen?" Die Erstellung klarer Schätzungen wird den Respekt für Programmierer erhöhen. So verhalten sich andere Profis. Die harte Arbeit der Programmierer wird sichtbar. Das Festlegen eines unrealistischen Zeitplans ist für jeden schmerzlich offensichtlich. Programmierer können nicht hinters Licht geführt werden. Es ist respektlos und demoralisierend, sie zu bitten, etwas Unrealistisches zu tun.

Wenn Sie sagen, das Projekt steht kurz vor dem Scheitern, dann basiert dies auf Ihrer Einschätzung, welche Aufgaben erledigt werden müssen und wie viel Aufwand jeder einzelne von ihnen erfordert. Machen Sie diese Einschätzung explizit , verständlich und detailliert . Aufgaben in ihre Bestandteile aufteilen; Erklären Sie so detailliert wie möglich, wie viel Entwicklungszeit aufgewendet wird.

Sobald Sie dies tun, haben Sie eine solide Grundlage, um Bedenken mit dem Management zu besprechen. Wenn Sie Ihre Einschätzung in alle zu erledigenden Aufgaben unterteilt haben, können Sie aller Wahrscheinlichkeit nach nachweisen, dass der Job mehr Zeit in Anspruch nimmt als Sie - möglicherweise viel, viel mehr.

Wenn Sie diesen detaillierten Zeitplan mit Ihrem Manager besprochen haben, können Sie flexibel sein. Ihr Vorgesetzter könnte sagen: "Aufgabe X dauert keinen Monat, höchstens eine Woche." Oder "Aufgabe Y ist völlig unnötig, kürzen Sie das aus dem Zeitplan." Sie können diese Punkte sicherlich diskutieren, aber was viel wichtiger ist, ist eine Verständigung zwischen Ihnen und Ihrem Vorgesetzten über eine realistische Version eines Zeitplans. Auf diese Weise haben Sie eine explizite Anweisung, nicht zu testen, anstatt nur "unerwartet" die Zeit zu verlieren, wenn Ihnen keine Zeit zum Testen zugewiesen wird. Und es ist auf jeden Fall möglich, dass Ihr Manager zu Recht bereit ist, bestimmte Punkte ausdrücklich zu streichen, um pünktlich zu versenden.

Die Schätzung gibt Ihnen konkrete Substanz zum Diskutieren und Diskutieren. Es bringt Sie auf die gleiche Seite; Sie können sich sicher sein, dass Ihr Vorgesetzter Ihre Bedenken berücksichtigt hat. Und es bringt Sie zu einem Punkt, an dem es für Sie beide vollkommen offensichtlich ist, wenn Ihr Vorgesetzter das Unmögliche klar fragt. Wenn das Projekt endgültig zum Scheitern verurteilt ist, haben Sie dies klargestellt, und es liegt an Ihrem Manager, genau zu entscheiden, wie er möchte, dass Sie Ihre Zeit verbringen.

Da Ihr Manager weiß, dass es wahrscheinlich scheitern wird, sind Sie besser dran als die meisten anderen. Ich würde in Betracht ziehen, mit dem Manager zusammenzuarbeiten und zu prüfen, ob Teile / Funktionen der App ausgeschlossen werden können.

Zu oft halten wir jede Kundenanfrage für einen "Deal Killer" und geben uns alle Mühe, die Lieferung zu versprechen. Sie können diese Entscheidungen möglicherweise erst treffen, wenn jemand mit dem Kunden zusammenarbeitet und eingehendere Untersuchungen durchführt. Wenn Sie dies nicht können, versuchen Sie immer noch, das zu liefern, was Sie für das Wichtigste halten. Manchmal ist es einfacher, um Vergebung zu bitten als um Erlaubnis.

Ich habe an drei Projekten teilgenommen, die eindeutig gescheitert sind. Diese waren ziemlich schmerzhaft, aber im Rückblick hatten zwei von drei keine negativen Auswirkungen auf meine Karriere, und selbst der dritte war nicht das Ende der Welt.

Hier sind einige Beobachtungen, an die ich mich erinnere.

Entwickler auf Junior-Positionen ("Code per spec", "Fix the Bug", so etwas) sind nicht sehr betroffen, es sei denn, sie verlieren aufgrund der verringerten Moral im Team an Schwung. In solchen Positionen könnte eine vernünftige und manchmal sogar erfolgreiche Überlebensstrategie nur das Beste sein, was Sie können.

• ^{Zum Beispiel wurde einer der Fehler, den ich erlebt habe, durch die einfache, methodische Behebung von mehr als hundert bekannten Fehlern behoben, die (zusammen mit einem besonders intelligenten Ansatz zur Förderung dieses Fortschritts durch den technischen Leiter) das obere Management schließlich zu der Entscheidung veranlassten, das Projekt wiederherzustellen und zu geben Es ist eine weitere Chance mit einer neuen Veröffentlichung, die wiederum einen vernünftigen Erfolg brachte.}

Programmierer in höheren, einflussreicheren Positionen wären besser bereit, die negativen Konsequenzen des Scheiterns eines Projekts zu teilen. Von einem Architekten, technischen Leiter und leitenden Entwickler wird normalerweise erwartet, dass er eine so große Wirkung erzielt, dass er für den Erfolg oder Misserfolg eines Projekts verantwortlich ist.

In leitender Position sollte man besser darauf vorbereitet sein, "indirekt" vom Scheitern zu profitieren, indem man analysiert, was schief gelaufen ist und was hätte besser gemacht werden können.

Diese Erkenntnisse und Lehren nach dem Tod können von unschätzbarem Wert sein, wenn sie richtig gelernt werden. Die sehr erfolgreiche Karriere in leitenden Positionen kann davon abhängen, wie gut sie gelernt werden. Dies wird in dieser hervorragenden Antwort von WP erläutert :

Das Urteil kommt nicht vom Erfolg, sondern von Misserfolgen. Die meisten Unternehmen möchten Mitarbeiter einstellen, deren Ausfälle von früheren Unternehmen bezahlt wurden ...

Praktischer kann man den Ansatz "next / update release" als einen möglichen Ausweg aus dem Fehler betrachten. Zufällig oder nicht (glaube ich nicht ), aber beide Fehler, die meiner Karriere nicht geschadet haben, gingen von sehr ähnlichen Szenarien aus: Veröffentlichung Nwar eine totale Katastrophe, Veröffentlichung N+1war erträglich, Veröffentlichungen N+2und später waren klarer Erfolg.

Wenn ich in Ihren Schuhen liege, würde ich höchstwahrscheinlich einige Anstrengungen unternehmen, um die Idee der "nächsten Veröffentlichung" vorzubereiten / zu fördern. Erstellen Sie (und kommunizieren Sie !) So etwas wie eine vorläufige Liste bekannter Probleme, die Sie nach der geplanten Veröffentlichung beheben möchten . Entwurf eines informellen, groben Fahrplans für die nächste (n) Version (en).

Überlegen Sie, wie Sie diese Ideen an die Menschen in Ihrer Umgebung weitergeben und wie Sie das Management dazu bringen können, diesen Plan zu berücksichtigen. Wenn das Projekt jemanden mit guten Marketingfähigkeiten hat, versuchen Sie, ihn in die Behebung des Fehlschlags einzubeziehen, indem Sie die kommende Veröffentlichung in flüssigere Begriffe wie "Early Access", "Beta", "Kundenvorschau", "Introductory Release" usw. umwandeln Das.

Denken Sie an einen Backup-Plan für den Fall, dass höhere Ups für diese Idee taub erscheinen. Erinnern Sie sich an die obige Geschichte über "das Beheben von mehr als hundert bekannten Fehlern"? Es gibt eine Chance, dass sich die Dinge wirklich ändern.

Das Management mag jetzt taub erscheinen, wenn es um Ideen für die nächste Veröffentlichung geht, aber es besteht eine gute Chance, dass sie sich angesichts überzeugender Beweise für den Fortschritt der Projektqualität erneut Gedanken machen.

• ^{Es ist sehr wahrscheinlich, dass zwischen dem Einfrieren des Codes für die geplante Veröffentlichung und der Entscheidung des Managements, ihn vollständig zu löschen, ziemlich viel Zeit verbleibt. Diese Zeit ist Ihre Chance: Wenn Sie sich darauf konzentrieren, bekannte Probleme zu beheben und den Fortschritt richtig zu "evangelisieren", könnte dies einen Unterschied bewirken (wie es einst für mich der Fall war).}

Hier gibt es bereits unzählige praktische (und anderweitige) Ratschläge, aber für mich sind die Schlüssel zu diesem Rätsel die folgenden zwei Punkte (Hervorhebung von mir):

Die Frist beträgt 1,5 Monate

und

... wir haben dieses Projekt (zusammen mit dem Durcheinander) vor ungefähr 1-2 Monaten von einem anderen Entwicklerteam unter demselben Manager geerbt ...

Damit....

Willkommen beim Team Patsy The Avengers

Das vorherige Team hatte besseres zu tun als zu versagen. Und irgendwie hat der Manager das mitgemacht. Ein kurzfristiger Wechsel der Teams ist nicht die beste Maßnahme für das Projektmanagement, also ... was ist damit los?

Korrektur: Das vorherige Team wurde ca. 3 Monate vor dem Abgabetermin ersetzt.

-> Finden Sie heraus, wie das vorherige Entwicklerteam entkommen konnte, und tun Sie dies. <-

3 Monate reichen kaum aus, um ein System dieser scheinbaren Größe auf den neuesten Stand zu bringen, seine Architektur noch weniger zu korrigieren, Tests hinzuzufügen und es fertigzustellen. Du brauchst mehr Zeit

Und wenn Sie das nicht können, es sei denn, Sie sind sich absolut sicher, dass das Projekt auf unbestimmte Zeit verlängert wird, oder wenn Sie von magischen Elfen oder etwas anderem unterstützt werden, möchten Sie nicht der letzte Mann sein, der die Tasche in der Hand hält.

Hart? Ja. Aber während eine schlechte Planung (zumindest!) Durch frühere Teams / Manager nicht Ihre Schuld ist, wird es ein "Misserfolg" sein .

Der Stand des Team gebürgt . Das vorherige Team wurde an den Randstein gekickt. Was sagt dir das? Es sagt mir, dass Sie das Turnaround-Team sind ... und Ihr Manager auf Ihre Heldentaten setzt, um den Tag zu retten.

Ein 5-köpfiges Team und noch 1,5 Monate. Das neue Team hat das Projekt erst seit 1-2 Monaten, so dass das neue Team noch nicht einmal die Lernkurve hinter sich hat . Wenn man sich die Größe dieses Projekts genauer ansieht, scheint es mir, als hätte das neue Team die Lernkurve auf keinen Fall hinter sich gebracht, selbst wenn das Projekt überhaupt keine Probleme gehabt hätte.

Also, ich glaube (immer noch), du wurdest verpfuscht.

Wenn dies der Fall ist - und nur Sie können entscheiden, was wahr ist oder was Sie glauben wollen -, schulden Sie niemandem eine Erklärung oder Entschuldigung dafür, dass Sie diesem Zugunglück aus dem Weg gegangen sind. Sie müssen jedoch diskret darüber sein.

Ich bezweifle ernsthaft, dass der Manager nicht weiß, dass das Projekt in Gefahr ist, was bedeutet, dass sanfte Erklärungen Ihnen nur negative Aufmerksamkeit verschaffen. Wenn Ihr Manager nicht Mr. Rogers ist , ist Ihre Zukunft in Gefahr.

Aber denken Sie immer daran : Lassen Sie sich im Internet nicht von Fremden beraten.

Dies ist eine unglaubliche Gelegenheit für Sie! Nehmen wir hierzu einen unternehmerischen Standpunkt ein.

Angenommen, das Management möchte, dass dieses Projekt erfolgreich ist, dann sind Sie in einer hervorragenden Position, um ihnen dabei zu helfen. Der Grund, warum diese Erkenntnis so wichtig ist, ist, dass Sie die Überzeugung und das Vertrauen entwickeln müssen, dass die Warnzeichen, die Sie sehen, tatsächlich zum Scheitern dieses Projekts führen werden [1].

Dies ist Ihre Chance, wichtige Fähigkeiten in systematischem Denken und zwischenmenschlicher Kommunikation zu üben. Verstehen und visualisieren Sie die Probleme und potenziellen Chancen, die verpasst werden, damit Sie eine Strategie entwickeln können, um diese so klar und einfach wie möglich zu kommunizieren.

Erkennen Sie hier Ihre Chance, Ihre Fähigkeiten zu verbessern.

[1] Das Projekt abzubrechen wäre tatsächlich ein Erfolg. Misserfolg würde gutes Geld nach schlechtem ausgeben.

Was kannst du tun

• Behandeln Sie dies in Ihren eigenen Begriffen, es ist "ihr" Projekt, aber auch Ihr, übernehmen Sie die Verantwortung, auch wenn Sie wissen, dass es scheitern wird. Warum? weil a) Sie vielleicht dazu beitragen, dass es ein bisschen weniger scheitert, b) in der Zeit der Herausforderung lernen Sie am meisten, c) Sie sollten sich anhand Ihrer eigenen Leistungsmetriken messen, wenn Sie Ihr Bestes geben, retten Sie vielleicht nicht das Projekt, sondern Sie könnte am Ende immer noch stolz auf dich sein

• Sprechen Sie mit anderen Entwicklerkollegen und sehen Sie, was sie denken. Sie werden wahrscheinlich feststellen, dass viele die gleiche Frustration haben. Wenn Sie dies sorgfältig tun (lassen Sie die Leute nicht glauben, dass Sie eine Meuterei oder so etwas anfangen möchten), kann dies nicht nur Ihnen, sondern auch Ihnen helfen andere auch

• Das Ignorieren des Problems wird es nicht zum Verschwinden bringen und darüber sprechen, wie man es trotz aller Widrigkeiten durchziehen kann, z. B. um wenigstens ein paar anständige Muss-Haves zu bekommen, oder der Hauptnutzungsfall "Wow-Faktor" könnte dies richtig machen Projekt scheitern weniger kläglich. Wie es geht? Nun, wenige Ideen wie "Wenn es hart wird, wird es hart" oder "verzweifelte Zeiten rechtfertigen verzweifelte Maßnahmen" und andere Klischees, zum Beispiel: massiver Einsatz von OSS, extreme Programmier- / Agilitätsmethoden, Wochenend-Hackathons (nur Freiwillige, die die Leute nicht dazu zwingen) Arbeitswochenenden). Dies ist die Zeit, in der Sie Führung zeigen können (vorsichtig, wenn Sie nicht in einer leitenden Position sind), aber Sie können diesen Vorteil nutzen und zu ihrem Spott werden. Lassen Sie die Leute spüren, dass sie dieses Projekt vielleicht ein bisschen weniger scheitern als Jeder weiß, dass es so sein wird.

• Stellen Sie sicher, dass Ihr Management Bescheid weiß, aber sehr, sehr sorgfältig, wenn sie Bescheid wissen, werden sie es zu schätzen wissen, wenn Sie dies nicht konfrontativ und ruhig sagen sie darüber vor. Sie sollten ihnen dies als Dienstleistung, ohne emotionale Seite, nur einfache Fakten und ohne Agenda mitteilen. Wenn sie Sie fragen, was sie Ihrer Meinung nach tun sollen (was ein gutes, aber seltenes Zeichen ist), lesen Sie den nächsten Abschnitt

Was Sie nicht können, aber Ihr Management sollte es wahrscheinlich tun

• Sie sollten dem Projekt keine weiteren Personen hinzufügen, "um zu helfen", dies zu sehen

• Rufen Sie den Kunden sofort an und teilen Sie ihm die schlechten Nachrichten mit. Warum ist das eine gute Idee? Nun, ich werde das Manifest für agile Softwareentwicklung zitieren lassen, aber auch ohne dieses Manifest hassen selbst Liebhaber von Wasserfällen böse Überraschungen. Wenn der Kunde im Voraus weiß, dass dieses Projekt zum Scheitern verurteilt ist, ist er unglücklich, aber umso glücklicher, dass Sie ihm mitteilen, dass es Probleme gibt, bevor es ihm in die Augen sprengt, und dass Sie dabei sind und Ihr Bestes tun, um sich anzupassen es. Der Kunde kann viele Dinge tun, aber die meisten von ihnen sind nicht schlimmer, als in letzter Minute herauszufinden, dass er kein Ergebnis hat (oder er tut es, aber es ist von nicht verwendbarer Qualität). Der Kunde wird es zu schätzen wissen, da er die Einstellung von Testmitarbeitern und Offshore-IT-Mitarbeitern verzögern, ihre internen Schulungspläne ändern und das alles nur, weil Sie mit ihnen ehrlich waren.

• Denken Sie mit dem Kunden darüber nach, wie Sie aus dem Projekt noch etwas machen können. Am häufigsten werden Dinge herabgesetzt. Es kann zum Beispiel einige Funktionen geben, die einfach zu schwer zu entwickeln sind, und wenn der Kunde einigen kleinen Änderungen und Vereinfachungen zustimmt, werden einige Funktionen einfacher.

• Aktualisieren Sie ihr eigenes höheres Management, es wird ihnen auch helfen, ihren Job zu behalten ...

Was du NICHT tun solltest

• Bitten Sie, weitere Personen zum Projekt hinzuzufügen (siehe dies ).

• Kündige / suche einen anderen Job (zumindest noch nicht), davon kannst du lernen und was dich eines Tages zu einem besseren Entwickler oder Manager machen wird. Sie werden lernen, vieles besser zu schätzen, die Zeit besser zu verwalten, besser zu gestalten, Code besser zu schreiben und besser mit Kollegen und der Verwaltung zusammenzuarbeiten. Suchen Sie nach diesen 2 Monaten einen Job, wenn Sie nicht gerne dort arbeiten, nicht aus einem anderen Grund.

• Jammern, sich beschweren oder negativ über das Projekt, das Management, das schlechte Design, das Sie geerbt haben, die neuen Entwickler, die Sie betreuen müssen, dass Sie 3 Stunden brauchen, um sie zu erklären, was Sie 1 Stunde brauchen. Seien Sie genauso positiv wie Sie kann.

• Kritisieren Sie das Management und werden Sie zum Ziel eines Unruhestifterns. Sie sitzen im selben Boot und kennen möglicherweise Dinge, die Sie nicht wissen. Alles, was Sie tun können, ist, sie zu aktualisieren (aktualisieren Sie immer Ihren eigenen direkten Manager, umgehen Sie ihn niemals).

• Beschuldige die Leute (oder dich selbst), es hilft nicht, niemals

• Nehmen Sie es zu ernst, es sei denn, es handelt sich um medizinische Geräte. Es ist unwahrscheinlich, dass jemand stirbt, wenn Sie die Fristen verpassen. Es ist Software. Wir verpassen die Fristen für den Lebensunterhalt. Entspannen Sie sich.

Das sind nur meine zwei Cent, YMMV

Finden Sie die Probleme, auf die Ihr Projekt stößt, und versuchen Sie, sie so objektiv wie möglich zu quantifizieren. Stellen Sie bei jeder quantifizierten "Metrik" sicher, dass Sie definieren, warum diese Metrik Ihrer Meinung nach wichtig ist. Sie möchten Ihrem Manager einen Einblick in die Konsequenzen geben, die sich ergeben würden, wenn eine bestimmte Metrik nicht im "akzeptablen Bereich" liegen würde. Sie müssen für jede Metrik einige Richtlinien angeben, um anzugeben, welche Werte "Gut", "Akzeptabel", "Problematisch" oder "Schlecht" sind. Definieren Sie jedes Kriterium im Voraus. Wenn möglich, können Sie beschreiben, was für den Erfolg eines Projekts nur minimal erforderlich ist, und dies dem aktuellen Projekt gegenüberstellen.

• Die Qualität des statischen Codes kann mit vielen statischen Analysewerkzeugen quantifiziert werden. Sie können dies so einfach oder detailliert halten, wie Sie es für richtig halten. Die Metriken, die ich vorschlage, beginnen mit:
  • Zyklomatische Komplexität
  • Größe Ihres Codes (zB Anzahl der Zeilen pro Funktion / Klasse, Anzahl der Dateien, Anzahl der Tabellen ...)
  • Identifizieren Sie, welche Module zu groß sind
  • Vervielfältigung.
  • Einhaltung des Code-Stils
• Fehlerrate
  • pro KLOC nach Modul und / oder Subsystem (Identifizierung problematischer Teile Ihres Systems)
  • Sie könnten berechnen, wie viel pro Teammitglied, aber ich denke, Sie sollten das für sich behalten
  • gelöst vs gefunden
  • Zeit, die benötigt wird, um einen Fehler zu beheben
  • machen Sie vielleicht eine Schätzung, wie viel Zeit benötigt wird, wenn dies mit der aktuellen Rate weitergeht
• Planung
  • Extrapolieren Sie die für die erstellten Funktionen verwendete Zeit. Berücksichtigen Sie die Komplexität der Funktion. Das muss nicht sehr genau sein. Was Sie damit vermitteln möchten, ist in etwa die Komplexität von D, E und F. Mit den Features ABC werden 170% der geplanten Zeit verwendet. Wenn sich nichts ändert, erwarten wir dasselbe Zeit wird für DEF benötigt "oder nach dem Muster" Das durchschnittliche Feature benötigt X% mehr Zeit als berechnet. Wir haben keinen Grund anzunehmen, dass der Rest der Funktionalität einfacher zu erstellen ist, daher sollten wir dies in der zukünftigen Planung ausgleichen Eine Planung nützt nichts, wenn sie nicht realistisch ist.
  • Versuchen Sie, einen monatlichen oder am besten noch kürzeren Veröffentlichungsplan zu haben. Wenn nur intern. Dies kann Ihnen helfen, die für das Projekt benötigte Zeit weiter zu extrapolieren. Dies könnte Sie auch davor bewahren, unrealistische Verpflichtungen einzugehen (wenn Sie sich nicht vor Abschluss einer Veröffentlichung zu neuen Arbeiten verpflichten). Machen Sie eine Planung für jeden Zyklus und stellen Sie sicher, dass neue Funktionen nur in den nächsten Zyklus aufgenommen werden (dh sie können niemals zum aktuellen Zyklus hinzugefügt werden).
• Testabdeckung: Erklären Sie die "normalen" Testabdeckungswerte und zeigen Sie, wie Ihre aktuelle Abdeckung ist
• Dokumentation: Wie viel% ist tatsächlich dokumentiert? Wie gut?
• Modularität:
  • Klassenbasiert (Kopplung und Zusammenhalt)
  • Paket basiert
  • Subsystem-basiert (wie viele Kommunikationswege gibt es?)

Sie sollten an die Arbeit gehen und das tun, was Sie bei jedem Projekt tun würden, ob es erfolgreich war oder nicht. Sie werden für Ihre Arbeit bezahlt. Tun Sie es nach besten Kräften. Vorausgesetzt, Sie sind nicht der Projektmanager / -leiter, liegt es nicht in Ihrer Verantwortung, zu entscheiden, ob ein Programm abgebrochen werden soll oder nicht. Wenn Sie sich für eine Unterbrechung entscheiden, haben Sie auch die Entscheidung getroffen, das Projekt abzubrechen. Das ist nicht Teil Ihrer Stellenbeschreibung.

Im Großen und Ganzen bedeutet dies jedoch nicht, dass Sie 50, 60 oder mehr Stunden pro Woche arbeiten sollten, um den Zeitplan einzuhalten. Wieder einmal ist es die Aufgabe des Managements, herauszufinden, wie die Projektziele erreicht werden können. Wochen mit mehr als 50 Stunden Arbeit sind keine vernünftige Option, es sei denn, sie sind bereit, Überstunden zu bezahlen und Sie sind bereit, Ihr Familienleben in die Warteschleife zu legen. Es war erneut Aufgabe des Managements, einen realisierbaren Zeitplan aufzustellen. Sie können nicht davon ausgehen, dass sie Mitarbeiter dazu zwingen können, ihr Familienleben zu ignorieren, um unrealistische Zeitpläne einzuhalten.

Auch während der Zeitplan 1 1/2 verbleibende Monate sagen kann. Das ist wahrscheinlich nicht der "Drop Dead" -Datum. Einige Kunden nehmen möglicherweise, was Sie bis zu diesem Datum haben, auch wenn es nicht alles ist. Einige Kunden haben möglicherweise zusätzliche Finanzierungsmöglichkeiten, da sie bereits viel Geld in das Projekt gesteckt haben. Manchmal übernimmt das Unternehmen selbst die zusätzlichen Kosten, um einen zufriedenen Kunden zu gewährleisten. All das liegt außerhalb Ihrer Kontrolle. Machen Sie Ihren Job nach besten Kräften. Dies gibt Managementoptionen, mit denen ein Katastrophenprojekt zu einer großartigen Erfolgsgeschichte werden kann. Ich habe es schon oft gesehen.

Ich kann nur wiederholen, was andere gesagt haben, aber ich betone nachdrücklich: Strebe immer nach deiner besten Arbeit und behalte einen Überblick über das Papier. sowohl aus CYA als auch aus technischen Gründen.

Jeder Fall, der auf Sie zukommt, hängt vom persönlichen Charakter des Managements ab. Aber lassen Sie mich Ihnen sagen, dass es die Hölle ist, wenn inkompetentes, lügnerisches Management ankommt. Aber das Schlimmste, was Sie hinterlassen werden, ist, dass Sie selbst (und Gleichaltrige) den Respekt behalten.

Notieren Sie sich die technischen Aspekte Ihres Todesmarsches. Wenn Sie die unvermeidliche Interviewfrage bekommen, waren Sie in einem gescheiterten Projekt; Warum ist es gescheitert und was haben Sie unternommen, um dies zu verhindern? Knochenmanagement ist keine Antwort - auch wenn es der Grund ist.

Es kann ein einfacher Ausweg sein, anzunehmen, dass es sich um einen unvermeidlichen und völligen Fehler handelt, und das Projekt einfach aufzugeben. Als Berater werde ich häufig gebeten, bei Projekten mitzuwirken, die sich in verschiedenen Stadien der Degeneration befinden, gescheitert oder gescheitert sind. Ein Teil meiner Vergütung besteht darin, solche Projekte wiederzubeleben und abzuschließen.

Was Sie als völliges Versagen ansehen, wird je nach Perspektive möglicherweise nicht von allen als solches wahrgenommen. In einer idealen Welt würde jede Funktion vollständig, elegant und unabhängig von anderen Systemen codiert und jede Codezeile getestet. Ich habe noch kein einziges Projekt gesehen, das in Rev. 1 so ausgesehen hat. In der Praxis bedeutet der Versand eines Projekts, dass einige Kompromisse eingegangen werden, möglicherweise fehlen sogar einige wichtige Funktionen, aber das Produkt kann ausgeliefert werden, obwohl es bestenfalls Beta-Qualität aufweist Zumindest erhalten Sie das Feedback, welche Probleme Sie zuerst beheben müssen. Dies hat den Vorteil, dass das Management davon in Kenntnis gesetzt werden kann, dass die Software niemals ausgeführt wird. Statt zu versuchen, eine bestimmte Version 1.0 im Vakuum zu entwickeln, ist es besser, sie zu iterieren und agil auf Änderungen zu reagieren. Endlich für Sie als Entwickler in dieser Position, Ich denke, das Wichtigste ist, unter diesen Bedingungen so guten Code wie möglich zu entwickeln - dokumentieren Sie ihn, schreiben Sie Tests selbst, wenn Sie müssen (insbesondere für externe Abhängigkeiten) und nutzen Sie Ihre Systemkenntnisse, um zu kommunizieren, welche Funktionen wirklich entscheidend sind und müssen -habe und welche können eine Woche oder einen Monat warten. Stellen Sie Ihre Bedenken zur Sprache und begründen Sie sie so, wie Sie es uns angetan haben. Anstatt Plan B vorzubereiten, sollten Sie sich darauf vorbereiten, dass Sie und andere arme Seelen wahrscheinlich den gesamten fehlerhaften und noch nicht erledigten Code reparieren, nachdem das Produkt ausgeliefert wurde - wie oben angegeben - bedeutet dies, dass Sie Ihren Code modular entkoppelt schreiben, wenn Wenn Sie der Meinung sind, dass der Code der Persistenzschicht schlecht ist, sollten Sie ihn hoffentlich in der nächsten Revision vollständig ersetzen können. Schließlich nicht verzweifeln - Umgang mit einer solchen Situation ist Teil dessen, was Sie " bezahlt werden und es ist ein Lernprozess. Unabhängig von den Ergebnissen in diesem speziellen Projekt wird dies in Zukunft eine wertvolle Erfahrung sein.