it-swarm-eu.dev

Wie soll ich mich als Entwickler in einem Projekt verhalten, das auf einen Misserfolg zusteuert?

Ich bin Entwickler in einem 5-köpfigen Team und ich glaube, unser Projekt steht vor einer Katastrophe. Ich werde gleich beschreiben, warum, aber meine Frage ist: Wie soll ich mich verhalten?

Die Frist beträgt 1,5 Monate, und ich bin der Meinung, dass dieses Projekt scheitern wird, egal was wir tun. Ich bin der Meinung, dass wir das Projekt einfach beenden und aufhören sollten, 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 ruhig angehen lassen? Und was soll ich dem Manager sagen?

Gründe für das Scheitern dieses Projekts:

  • Kurz vor Ablauf der Frist sind viele der unverzichtbaren Funktionen noch nicht abgeschlossen
  • Die Anwendung ist instabil und sehr schwierig zu bedienen
  • Das System ist sehr kompliziert, der Code sehr schwer zu verstehen, sehr schwer zu ändern - das Datenmodell wird zu stark von einer komplexen relationalen Datenbank (über 100 Tabellen) gesteuert.
  • 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 1-2 Monaten von einem anderen Entwicklerteam unter demselben Manager geerbt, der einige Monate daran gearbeitet hat.

341
Louis Rhys

Kommunizieren Sie Ihre Bedenken so präzise und konfrontationsfrei wie möglich auf der Managementleiter. Fassen Sie die Risiken zusammen, aber legen Sie ihnen nicht Ihre Schlussfolgerung auf.

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 dahinter stehenden finanziellen Entscheidungen wissen. Managemententscheidungen, die Ihnen dumm erscheinen, basieren möglicherweise auf intelligenten Überlegungen, die für Sie nicht sichtbar sind.

320
MrFox

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

Wenn Sie als Entwickler nicht als Hindernis für das Projekt angesehen werden, werden Sie wahrscheinlich gut mit dem Fingerzeig herauskommen, der zweifellos passieren wird. Ihr Manager hat vielleicht nicht so viel Glück, aber das ist hier nicht relevant.

Aktualisieren Sie Ihren Lebenslauf nur 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, treten Sie 2 oder 3 bei. Es dauert Jahre, um ein Netzwerk von Freunden und Bekannten aufzubauen, aber auf lange Sicht lohnt es sich. Stellen Sie sicher, dass Sie es als Einbahnstraße betrachten. Wenn Sie dabei helfen können, eine Stelle in Ihrem Unternehmen mit jemandem zu füllen, der dazu in der Lage ist, ist das genauso gut wie jemand, der Ihnen bei der Arbeitssuche hilft.

105
Dan Pichelman

Ich werde empfehlen, dass Sie sich etwas Zeit nehmen, um 2 Bücher zu lesen.

Death March ist das kanonische Buch, das einen pathologischen Projektmanagementstil beschreibt, der in der Softwareentwicklung weit verbreitet ist. Aufgrund von Zeitplankomprimierung, Aufblähen von Funktionen 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 kategorisiert Sackgassenprojekte in 4 Quadranten, von denen jeder unterschiedliche Bewältigungsstrategien hat. Manchmal besteht die einzige Bewältigungsstrategie darin, wegzugehen. Ich denke, dieses Buch wird Ihnen helfen, herauszufinden, welche Möglichkeiten Sie haben, und einzugrenzen, was Sie können und was nicht.

My leet skills with MS Paint helped me make this!

Katastrophenentflechtung ist mehr für Projektmanager geschrieben. Ziel ist es herauszufinden, wie ein kaputtes Projekt analysiert werden kann: Was muss gekürzt werden, was kann gekürzt werden und wie kann dies den Kunden mitgeteilt werden? "Konventionelles" Software-Projektmanagement bringt uns in unordentliche Projekte, und wir werden unseren Problemen nicht entkommen, wenn wir das gleiche Denken anwenden, das uns überhaupt dazu gebracht hat. Dieses Buch ist etwas schwieriger zu lesen als Todesmarsch , aber ein gutes Buch, das Sie in Ihrem Bücherregal haben sollten.

90
Tangurena

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

  1. Sehen Sie ein Zugunglück im Entstehen - steigen Sie aus dem Zug: 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. Springe jetzt, wenn du eine sanfte Landung siehst.

  2. Wenn das nicht funktioniert, halten Sie den Kopf gesenkt: Die Leute werden nach Schuldigen suchen - machen Sie es ihnen nicht einfach! Eskalierende Bedenken in der Managementkette sind zwar das Richtige, aber sie sind sowohl ineffektiv als auch riskant. Es ist unwahrscheinlich, dass Ihr eigener Manager Ihre Bedenken weitergibt. Wenn Sie ihn/sie umgehen, sehen Sie beide nicht nur schlecht aus, sondern können Sie auch als „Unruhestifter“ bezeichnen, dh als eine Person, die dafür verantwortlich gemacht werden kann, dass sie das Projekt überhaupt untergraben hat Das bedeutet natürlich auch, professionell zu sein, Stunden zu investieren, aber keine Heldentaten.

  3. Planen Sie einen Notausgang auf 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, darauf zu warten, dass andere entscheiden, was mit Ihnen geschehen soll, wenn die Projektfinanzierung gekürzt wird, oder in den unvermeidlichen „Ansturm“ der Menschen, die in ein paar Monaten abwandern, überschwemmt zu werden.

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

59
Mark S

Welche Auswirkungen wird dieses bald gescheiterte Projekt auf Ihre Karriere in der Firma und darüber hinaus haben? Nach meiner Erfahrung ist die bloße Verbindung mit erfolgreichen Projekten kein Indikator für Ihre persönliche Exzellenz.

Die Qualitäten, die Sie angesichts von Widrigkeiten und manchmal etwas, das als sicheres Versagen erscheint, aufweisen, werden von den Höheren oft mehr wahrgenommen, als Sie denken. Und ich spreche über Ihren direkten Manager hinaus.

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

Oft bietet Ihnen das gleiche Chaos und die Desorganisation, die mit einem fehlgeschlagenen Projekt einhergehen, die Möglichkeit, zu glänzen.

Betrachten Sie das Projekt also so: Welche Gelegenheit bietet dieses scheiternde Projekt, damit das Licht auf alle meine Stärken und besten Qualitäten scheint? Welche Lehren lerne ich aus dieser Erfahrung, die mich zu einem besseren Fachmann und einem besseren Menschen machen?

Im Wesentlichen ist die Summe der Erfahrungen, die aus Fehlern gezogen wurden, der wahre Erfolg.

Hinweis: Thomas Owens fragte, welche spezifischen Dinge eine Person in einem solchen Projekt tun könne. Ich habe einige allgemeine Vorschläge, die ich in diesen Situationen als persönliche Richtlinien verwendet habe. Wird es einem Notprojekt helfen, auf wundersame Weise erfolgreich zu sein? Nein - aber ich habe festgestellt, dass es mir geholfen hat, die Dinge aus der richtigen Perspektive zu betrachten und trotz der schlechten Situation persönlichen Erfolg zu finden.

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 auf so niedrig wie möglich. Wenn Sie nach einem Kostenvoranschlag für eine Ihnen zugewiesene Aufgabe gefragt werden, sind Sie im Allgemeinen korrekt oder stellen Sie fest, dass Sie die Zeitachse zu stark über- oder unterpuffert haben? Geben Sie bei der tatsächlichen Zuweisung einer Aufgabe ein gutes Feedback zum Arbeitsfortschritt, einschließlich einer frühzeitigen Benachrichtigung über Probleme mit dem Lieferzeitplan?

3) Konzentrieren Sie sich auf Teammetriken - Dies sind nur einige Dinge, die mir aus dem Kopf gehen: Bleiben andere Teammitglieder aufgrund der Abhängigkeit von einer Aufgabe, an der Sie arbeiten, zurück? Können Sie Ihre Aufgaben/Unteraufgaben gut an andere im Team 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.

35
code4life

In einer solchen Situation können Sie als unterste Stufe der Leiter nur so viel tun, um das Projekt zu unterstützen.

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

Abgesehen davon muss man sich wirklich um Nummer 1 kümmern.

  • Dokumentieren Sie alles
  • bewahren Sie alle E-Mails und IM-Gespräche auf
  • Versuchen Sie, einen Ausweg aus dem Projekt zu finden, wenn dies alles möglich ist
23
ozz

Fehlgeschlagene Projekte können für die Seele giftig sein, Depressionen, Überarbeitung und ein geringes Selbstwertgefühl verursachen.

Es ist alles relativ zur Perspektive.

Ich habe an schrecklichen Projekten gearbeitet, während ich einem anderen Mann gegenüber saß, der jeden Tag ein Lächeln im Gesicht hatte. Oh, wie ich dieses Lächeln von seinem Gesicht schlagen wollte.

Einige Leute stören sich nicht am aktuellen Stand eines Projekts. Sie genießen ihren Beitrag, ihre Aufgaben und arbeiten im Bereich ihrer Interessen. Während andere eine starke negative Reaktion auf den aktuellen Stand der Dinge haben. Es geht 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 diese Problemelemente identifizieren und ansprechen.

  • termindruck
  • qualitätskontrolle
  • professionalität
  • anleitung 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 wahrgenommen.
  • Qualität kostet mehr und Retourenlimit.
  • 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 nicht dir. Es gehört ihnen, und Sie sollten keine Energie für ihr Verhalten verschwenden. Wenn Sie nicht zu den Leuten gehören, die lächeln und seinen Job genießen, auch wenn er auf eine Klippe zusteuert, sollten Sie darüber nachdenken, einen Ort zu finden, an dem like minded Entwickler.

Du wirst viel glücklicher sein.

22
Reactgular

Klingt nach den meisten Projekten, an denen ich gearbeitet habe. Es wird 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 den Verdacht haben, dass der Manager alle außer sich selbst beschuldigt, stellen Sie sicher, dass Sie genügend Beweise dafür haben, dass Sie alles getan haben, was von Ihnen verlangt wird (siehe Punkt 1).

3) Machen Sie ein paar höflich Verbesserungsvorschläge. Läuten Sie nicht die Warnglocken, seien Sie nicht Untergang und Finsternis, seien Sie nur höflich und subtil.

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

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

Ebenfalls:

4) Opportunistisches Refactoring ist dein Freund.

13
Michael Cook

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, weil das Projekt gescheitert ist. Würde er es nicht schätzen, wenn jemand Lösungen anstelle von Problemen einbringt?

Vielleicht gibt es eine Möglichkeit, die Funktionen in gestaffelte Ergebnisse aufzuteilen? Es gibt oft Grade von "Muss". Sehen Sie also nach, ob Sie diese priorisieren und in Meilensteine ​​gruppieren können. Es ist besser, ein Produkt am Ende der Zeitleiste zu haben als nichts. Oder denken Sie daran, das Team zwischen Personen, die an neuen Funktionen arbeiten, und Personen, die an der Stabilität arbeiten, aufzuteilen. Auf diese Weise können Sie einige Fortschritte an beiden Fronten zeigen.

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

12
cdkMoose
  1. Hart arbeiten; aber nicht auf Kosten Ihrer Familie oder Ihrer Gesundheit.
  2. Führen Sie Aufzeichnungen über alle kritischen Entwurfsentscheidungen. vor allem, weil sie sich auf Ihre Arbeit beziehen.
  3. Bleiben Sie vernetzt und halten Sie Ihre Optionen offen, wenn die Situation zu schwierig wird oder Sie Opfer einer Massenentlassung werden.
  4. Versuchen Sie nicht, sich Ihr Projekt als "fehlgeschlagenes Projekt" vorzustellen. 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 fehlgeschlagenes Projekt erwarten, 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 Sie ihn später leicht verteidigen können.] Wenn Sie eine E-Mail oder ein Designdokument haben, das Ihre Entscheidungen inspiriert hat, ist dies sogar noch besser.
  6. Versuchen Sie bei diesem Post-Mortem-Treffen, positiv zu bleiben. und nur legen Sie Ihre E-Mail- und Designdokumentnachweise vor, wenn Ihr Urteilsvermögen, Ihr Aufwand oder Ihre Verarbeitung in Frage gestellt werden.
11
Jim G.

Was ich am effektivsten gefunden habe, ist die Empfehlung von Robert L. Read zu wie man den Zeitplandruck bekämpft . Folgendes schreibt Read:

Der Schlüssel zur Bekämpfung des Zeitplandrucks besteht einfach darin, ihn in Time-to-Market-Druck umzuwandeln. Der Weg, dies zu tun, um Einblick in die Beziehung zwischen der verfügbaren Arbeitskraft und dem Produkt zu geben. Eine ehrliche, detaillierte und vor allem verständlich Schätzung aller beteiligten Arbeitskräfte zu erstellen, ist der beste Weg, dies zu tun. 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 deutlich machen muss, ist, dass Arbeit eine fast inkompressible Flüssigkeit ist. Sie können nicht mehr in einer bestimmten Zeitspanne packen, als Sie mehr Wasser in einen Behälter packen können, der über das Volumen dieses Behälters hinausgeht. In gewissem Sinne sollte ein Programmierer niemals "Nein" sagen, sondern "Was werden Sie aufgeben, um das zu bekommen, was Sie wollen?". Durch die Erstellung klarer Schätzungen wird der Respekt für Programmierer erhöht. So verhalten sich andere Profis. Die harte Arbeit der Programmierer wird sichtbar. Das Festlegen eines unrealistischen Zeitplans ist auch für alle schmerzlich offensichtlich. Programmierer können nicht getäuscht werden. Es ist respektlos und demoralisierend, sie zu bitten, etwas Unrealistisches zu tun.

Wenn Sie sagen, dass das Projekt auf dem Weg zum Scheitern ist, basiert dies auf Ihrer Einschätzung, welche Aufgaben zu erledigen sind und wie viel Aufwand jeder einzelne von ihnen erfordert. Machen Sie diese Einschätzung explizit , verständlich und detailliert . Trennen Sie Aufgaben in ihre Bestandteile; Erklären Sie so detailliert wie möglich, wie viel Entwicklungszeit aufgewendet wird.

Sobald Sie dies getan haben, haben Sie eine solide Grundlage, um Bedenken mit dem Management zu besprechen. Wenn Sie Ihre Einschätzung in alle spezifischen Aufgaben unterteilt haben, die erledigt werden müssen, können Sie höchstwahrscheinlich nachweisen, dass der Job mehr Zeit in Anspruch nimmt als Sie - möglicherweise viel, viel mehr.

Wenn Sie diesen detaillierten Zeitplan mit Ihrem Manager besprechen, sollten Sie darauf vorbereitet sein, flexibel zu sein. Ihr Manager könnte sagen: "Aufgabe X dauert keinen Monat, es dauert höchstens eine Woche" oder "Aufgabe Y ist völlig unnötig, schneiden Sie das aus dem Zeitplan." Sie können diese Punkte sicherlich diskutieren, aber was viel wichtiger ist, ist eine Einigung zwischen Ihnen und Ihrem Manager über einige realistische Version eines Zeitplans. Auf diese Weise haben Sie eine explizite Anweisung, nicht zu testen, anstatt nur "unerwartet" die Zeit zu verlieren, wenn Ihnen beispielsweise keine Zeit zum Testen zugewiesen wird. Und es ist definitiv möglich, dass Ihr Manager zu Recht bereit ist, bestimmte Ecken explizit zu kürzen, um pünktlich zu versenden - es gibt viele Fälle, in denen dies ein absolut vernünftiger Anruf ist!

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

8
Standback

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

Die Frist ist in 1,5 Monaten

und

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

Damit....

Willkommen zu Team Patsy Die Rächer

Das vorherige Team hatte bessere Dinge zu tun ... als zu scheitern. Und irgendwie hat der Manager das mitgemacht. Ein Teamwechsel so kurz vor dem Stichtag ist nicht der beste Schritt für das Projektmanagement. Also ... was ist damit los?

Korrektur: Das vorherige Team wurde ~ 3 Monate vor Ablauf der Frist ersetzt.

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

3 Monate sind kaum genug Zeit, um ein System dieser scheinbaren Größe auf den neuesten Stand zu bringen, geschweige denn seine Architektur zu korrigieren, Tests hinzuzufügen und es zu beenden. Du brauchst mehr Zeit

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

Hart? Ja. Aber während eine schlechte Planung (zumindest!) Durch frühere Teams/Manager nicht Ihre Schuld ist, ist 'Nichterfüllung' wird.

Das vorherige Team hat gegen Kaution . Das vorherige Team wurde an den Straßenrand getreten. Was sagt dir das? Es sagt mir, dass Sie das Turnaround-Team sind ... und Ihr Manager zählt auf Ihre Heldentaten, 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 über der Lernkurve ist . Wenn ich die Größe dieses Projekts grob errate, sieht es für mich so aus, als ob das neue Team wäre auf keinen Fall über die Lernkurve hinausgegangen, selbst wenn das Projekt überhaupt keine Probleme gehabt hätte.

Also, ich denke (immer noch) du wurdest geschockt.

Wenn dies der Fall ist - und nur Sie können entscheiden, was wahr ist oder was Sie glauben möchten -, 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 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 nicht von Fremden im Internet beraten.

5
Steven A. Lowe

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 denken wir, dass jede Kundenanfrage ein "Deal Killer" ist und geben uns alle Mühe, die Lieferung zu versprechen. Bis jemand mit dem Kunden zusammenarbeitet und tiefer geht, können Sie diese Entscheidungen möglicherweise nicht treffen. Wenn Sie dazu nicht in der Lage sind, versuchen Sie dennoch, das zu liefern, was Sie für am wichtigsten halten. Manchmal ist es einfacher, um Vergebung zu bitten als um Erlaubnis.

4
JeffO

Ich habe an drei Projekten teilgenommen, die eindeutig gescheitert sind. Diese waren ziemlich schmerzhaft, aber rückblickend hatten zwei von drei keine negativen Konsequenzen für meine Karriere, und selbst der dritte war nicht das Ende der Welt.

Hier sind einige Beobachtungen, an die ich mich erinnere.

Entwickler in Junior-Positionen ("Code per spec", "Fix the Bug", solche Sachen) sind nicht sehr betroffen, es sei denn, sie lassen aufgrund der verminderten Moral im Team nach. In solchen Positionen könnte eine vernünftige und manchmal sogar erfolgreiche Überlebensstrategie nur das Beste geben, was Sie können.

  • Zum Beispiel wurde einer der Fehler, die ich erlebt habe, durch eine 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 Vorsprung) das obere Management schließlich zu der Entscheidung veranlassten, das Projekt wiederherzustellen und zu geben Es ist eine weitere Chance mit einer neuen Version, die wiederum einen vernünftigen Erfolg hatte.

Programmierer in höheren, einflussreichen Positionen wären besser bereit, die negativen Folgen eines Projektversagens zu teilen. Von einem Architekten, technischen Leiter oder leitenden Entwickler wird normalerweise erwartet, dass er eine Wirkung erzielt, die groß genug ist, um als verantwortlich für den Erfolg oder Misserfolg eines Projekts angesehen zu werden.

In einer höheren Position wäre man besser bereit, "indirekt" vom Scheitern zu profitieren, indem man analysiert, was schief gelaufen ist und was hätte besser gemacht werden können.

Diese Erkenntnisse, Post-Mortem-Lektionen, 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 diese gelernt werden, wie erklärt in dieser brillanten Antwort bei WP :

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


Praktischer gesagt kann man den Ansatz "Next/Update Release" als einen möglichen Ausweg aus dem Fehler betrachten. Zufällig oder nicht (ich denke nicht), aber beide Fehler, die meiner Karriere nicht geschadet haben, verliefen in sehr ähnlichen Szenarien: Release N war eine totale Katastrophe, Release N+1 war erträglich, veröffentlicht N+2 und später waren klarer Erfolg.

Wenn ich in Ihren Schuhen stehe, würde ich höchstwahrscheinlich einige Anstrengungen unternehmen, um die Idee der "nächsten Veröffentlichung" vorzubereiten/zu fördern. Machen Sie (und kommunizieren!) So etwas wie eine vorläufige Liste bekannter Probleme, die Sie beheben möchten nach geplante Veröffentlichung. Erstellen Sie eine informelle, grobe Roadmap 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 beeinflussen können, um diesen Plan zu berücksichtigen. Wenn das Projekt jemanden mit guten Marketingfähigkeiten hat, versuchen Sie, ihn in die Amortisation des Fehlerschadens einzubeziehen, indem Sie die kommende Version in reibungslosere Begriffe wie "Early Access", "Beta", "Kundenvorschau", "Einführungsversion" usw. einbinden Das.

Denken Sie an einen Backup-Plan für den Fall, dass höhere Gruppen 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 für die Ideen der nächsten Veröffentlichung taub erscheinen, aber es besteht eine gute Chance, dass sie angesichts starker überzeugender Beweise für den Fortschritt der Projektqualität erneut darüber nachdenken.

  • 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 liegen wird. 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 machen (wie es mir einmal gemacht hat).
4
gnat

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

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

Dies ist Ihre Chance, wichtige Fähigkeiten im systematischen Denken und in der zwischenmenschlichen Kommunikation zu üben. Verstehen und visualisieren Sie die verpassten Probleme und potenziellen Chancen, 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.

3
Tone

Was können Sie tun

  • Behandeln Sie dies in Ihren eigenen Begriffen, es ist "ihr" Projekt, aber auch Ihr Projekt, übernehmen Sie die Verantwortung, obwohl Sie wissen, dass es scheitern wird. Warum? weil a) Sie möglicherweise dazu beitragen, dass es ein wenig weniger scheitert, b) in Zeiten der Herausforderung lernen Sie hier am meisten c) Sie sollten sich anhand Ihrer eigenen Metriken der Exzellenz messen. Wenn Sie Ihr Bestes geben, wird das Projekt möglicherweise nicht gerettet, aber Sie könnte 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 teilen. Wenn Sie dies sorgfältig tun (lassen Sie die Leute nicht glauben, dass Sie eine Meuterei beginnen möchten oder so), kann dies nicht nur Ihnen, sondern auch helfen andere auch

  • Das Ignorieren des Problems wird es nicht verschwinden lassen und darüber sprechen, wie man es trotz aller Widrigkeiten immer noch durchziehen kann, z. Zumindest ein paar anständige Must-Haves, oder der Hauptanwendungsfall "Wow-Faktor", der richtig gemacht wird, könnte dazu führen, dass dieses Projekt weniger kläglich scheitert. Wie es geht? Nun, nur wenige Ideen von "Wenn es hart auf hart geht, wird hart" oder "verzweifelte Zeiten rechtfertigen verzweifelte Maßnahmen" und andere Klischees, zum Beispiel: massiver Einsatz von OSS, extreme Programmierung/agile Methoden, 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 Teamleiter-/Führungsposition sind), aber Sie können diesen Vorteil nutzen und zu ihrem Spottjay werden. Lassen Sie die Leute einfach das Gefühl haben, dass sie dieses Projekt möglicherweise nur ein wenig weniger scheitern lassen als Jeder weiß, dass es so sein wird. Sie können hier einige Führungsqualitäten zeigen, die Ihnen später auf dem Weg helfen könnten, das Problem als Herausforderung zu behandeln.

  • Stellen Sie sicher, dass Ihr Management es weiß, aber sehr, sehr sorgfältig, wenn sie es wissen, werden sie es zu schätzen wissen, dass Sie es auf nicht konfrontative, ruhige Weise erzählen, wenn sie es nicht tun, werden sie es noch mehr zu schätzen wissen und sich fragen, warum niemand davon erzählt hat sie darüber vorher. 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 Zeichen ist, aber selten), lesen Sie den nächsten Abschnitt

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

  • Sie sollten dem Projekt nicht mehr Personen hinzufügen, "um zu helfen", siehe this
  • 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 es hassen selbst Wasserfallliebhaber böse Überraschungen. Wenn der Kunde im Voraus weiß, dass dieses Projekt zum Scheitern verurteilt ist, ist er unglücklich, aber viel glücklicher, wenn Sie ihm mitteilen, dass es Probleme gibt, bevor es ihm ins Gesicht bläst, und dass Sie sich damit befassen und Ihr Bestes tun, um sich anzupassen es. Der Kunde kann viele Dinge tun, aber die meisten von ihnen sind nicht schlechter, als in letzter Minute herauszufinden, dass sie kein Ergebnis haben (oder sie tun es, aber es ist von nicht verwendbarer Qualität). Der Kunde wird es zu schätzen wissen, da er die Einstellung von Testpersonal, Offshore-IT-Mitarbeitern, die Änderung seiner internen Schulungspläne und alles nur verzögern kann, nur weil Sie ehrlich zu ihnen waren.

  • überlegen Sie sich beim Kunden, wie Sie aus dem Projekt noch etwas machen können. Am häufigsten werden Dinge deskopiert. Beispielsweise kann es einige Funktionen geben, deren Entwicklung einfach zu schwierig ist. Wenn der Kunde einigen kleinen Änderungen und Vereinfachungen zustimmt, werden einige Funktionen einfacher.

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

Was Sie [~ # ~] nicht [~ # ~] tun sollten

  • Bitten Sie darum, weitere Personen zum Projekt hinzuzufügen (siehe this )

  • Kündigen/suchen Sie nach einem anderen Job (zumindest noch nicht), das können Sie lernen und was Sie eines Tages zu einem besseren Entwickler oder Manager machen wird. Sie werden lernen, viele Dinge besser zu schätzen, die Zeit besser zu verwalten, besser zu entwerfen, Code besser zu schreiben und besser mit Kollegen und dem Management zusammenzuarbeiten. Suchen Sie nach Ablauf dieser zwei Monate nach einem Job, wenn Sie dort nicht gerne arbeiten, nicht aus einem anderen Grund.

  • Jammern Sie, beschweren Sie sich oder seien Sie 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 ihnen zu erklären, dass sie etwas tun, das Sie 1 Stunde dauert. Seien Sie genauso positiv wie Sie kann.

  • Kritisieren Sie das Management und werden Sie als Unruhestifter zum Ziel. Sie sitzen im selben Boot und wissen möglicherweise Dinge, die Sie nicht wissen. Sie können sie nur aktualisieren (aktualisieren Sie immer Ihren eigenen direkten Manager, umgehen Sie ihn/sie niemals).

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

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

Das sind nur meine zwei Cent, YMMV

3
Eran Medan

Finden Sie die Probleme, auf die Ihr Projekt stößt, und versuchen Sie, sie so objektiv wie möglich klar zu quantifizieren. Stellen Sie bei jeder von Ihnen quantifizierten "Metrik" sicher, dass Sie definieren, warum Sie diese Metrik für wichtig halten. Sie möchten Ihrem Manager einen Einblick in die Konsequenzen geben, wenn eine bestimmte Metrik nicht im "akzeptablen Bereich" liegt. 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 Sie vorschlagen, beginnen mit:
    • Zyklomatische Komplexität
    • Größe Ihres Codes (z. B. Anzahl der Zeilen pro Funktion/Klasse, Anzahl der Dateien, Anzahl der Tabellen ...)
    • Identifizieren Sie, welche Module zu groß sind
    • Vervielfältigung.
    • Einhaltung des Codestils
  • Fehlerrate
    • pro KLOC nach Modul und/oder Subsystem (identifizieren Sie störende 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 (wenn dies geneigt ist, machen Sie ein Diagramm davon)
    • machen Sie vielleicht eine Schätzung, wie viel Zeit benötigt wird, wenn dies mit der aktuellen Rate weitergeht
  • Planung
    • Extrapolieren Sie die Zeit, die für die erstellten Funktionen verwendet wird. Berücksichtigen Sie die Komplexität der Funktion. Das muss nicht sehr genau sein. Was Sie damit vermitteln möchten, wäre in Anlehnung an "Merkmal A, B und C sind ungefähr gleich komplex wie D, E und F. Mit Merkmalen verwendet ABC 170%, wenn sich die geplante Zeit ändert. Wenn sich nichts ändert, erwarten wir dasselbe Zeit wird für DEF benötigt "oder in Anlehnung an" 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 kompensieren Eine Planung nützt nichts, wenn sie nicht realistisch ist.
    • Versuchen Sie, einen monatlichen oder vorzugsweise noch kürzeren Veröffentlichungsplan zu haben. Wenn nur intern. Dies könnte Ihnen bei der Extrapolation der für das Projekt benötigten Zeit weiter helfen. Dies könnte Sie auch davor bewahren, unrealistische Verpflichtungen einzugehen (wenn Sie sich vor Abschluss einer Veröffentlichung nicht zu neuen Arbeiten verpflichten). Machen Sie eine Planung für jeden Zylinder 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)
    • Paketbasiert
    • Subsystembasiert (wie viele Kommunikationspfade gibt es?)
1
Sjuul Janssen

Sie sollten zur Arbeit gehen und das tun, was Sie bei jedem Projekt tun würden, unabhängig davon, ob es erfolgreich war oder nicht. Sie werden für die Ausführung Ihrer Arbeit bezahlt. Tun Sie es nach besten Kräften. Angenommen, Sie sind nicht der Projektmanager/-leiter, liegt es nicht in Ihrer Verantwortung, zu entscheiden, ob ein Programm abgebrochen werden soll oder nicht. Ihre Entscheidung, nachzulassen, entspricht der Entscheidung, 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 sind keine vernünftige Option, es sei denn, sie sind bereit, Überstunden zu zahlen, und Sie sind bereit, Ihr Familienleben auf Eis zu legen. Es war erneut Aufgabe des Managements, einen erreichbaren Zeitplan zusammenzustellen. 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 Monate verbleiben kann. Das ist wahrscheinlich nicht das "Drop Dead" -Datum. Einige Kunden nehmen möglicherweise das, was Sie bis zu diesem Datum haben, auch wenn es nicht alles ist. Einige Kunden haben möglicherweise zusätzliche Mittel, 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 dem Management die Möglichkeit, damit zu arbeiten, und könnte aus einem Katastrophenprojekt eine großartige Erfolgsgeschichte machen. Ich habe es schon oft gesehen.

0
Dunk

Es kann ein einfacher Ausweg sein, anzunehmen, dass es sich um einen unvermeidlichen und völligen Misserfolg handelt, und das Projekt einfach aufzugeben. Als Berater werde ich oft eingeladen, bei Projekten zu helfen, die sich in verschiedenen Stadien der Degeneration befinden, gescheitert oder gescheitert sind. Ein Teil meiner Bezahlung besteht darin, solche Projekte wiederzubeleben und abzuschließen.

Was Sie als völligen Misserfolg ansehen, wird je nach Perspektive möglicherweise nicht von jedem als solcher wahrgenommen. In einer idealen Welt würde jede Funktion vervollständigt, elegant und unabhängig von anderen Systemen codiert und jede Codezeile getestet. Ich habe kein einziges Projekt gesehen, das in Version 1 so aussah. In der realen Welt bedeutet der Versand eines Projekts, einige Kompromisse einzugehen, möglicherweise sogar einige wichtige Funktionen zu verpassen, aber das Produkt kann ausgeliefert werden, obwohl es bestenfalls Beta-Qualität aufweist Zumindest erhalten Sie das Feedback, welche Probleme zuerst behoben werden müssen. Dies hat den Vorteil, dass das Management möglicherweise darüber informiert wird, dass Software niemals ausgeführt wird. Anstatt zu versuchen, eine bestimmte Version 1.0 im luftleeren Raum zu entwickeln, ist es besser, Änderungen agil durchzuführen und darauf zu reagieren. Schließlich denke ich, dass es für Sie als Entwickler in dieser Position wichtig ist, unter diesen Bedingungen so guten Code wie möglich zu entwickeln - dokumentieren Sie ihn, schreiben Sie selbst Tests, wenn Sie müssen (insbesondere für externe Abhängigkeiten) und nutzen Sie Ihr Wissen über die System, um zu kommunizieren, welche Funktionen wirklich wichtig und unverzichtbar sind und welche eine Woche oder einen Monat warten können. Machen Sie Ihre Äußerungen deutlich und begründen Sie sie so, wie Sie es uns angetan haben. Anstatt sich auf Plan B vorzubereiten, sollten Sie sich darauf vorbereiten, dass Sie und andere arme Seelen wahrscheinlich den ganzen fehlerhaften und noch nicht fertiggestellten Code reparieren, nachdem das Produkt ausgeliefert wurde - wie oben angegeben, bedeutet dies, dass Sie Ihren Code modular entkoppelt schreiben - wenn Sie denken, dass der Persistenzschichtcode schlecht ist, hoffentlich sollten Sie ihn in der nächsten Revision vollständig ersetzen können. Verzweifeln Sie nicht - der Umgang mit einer solchen Situation ist Teil dessen, wofür Sie bezahlt werden, und es ist ein Lernprozess. Unabhängig vom Ergebnis dieses speziellen Projekts wird dies in Zukunft eine wertvolle Erfahrung sein.

0
Lech Rzedzicki

Ich kann nur wiederholen, was andere gesagt haben, aber ich betone nachdrücklich: Bemühen Sie sich immer um Ihre beste Arbeit und behalten Sie eine Papierspur. sowohl aus CYA- als auch aus technischen Gründen.

Jeder Ausfall, 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, inkompetentes, lügnerisches Management zu empfangen. Aber das Schlimmste, was Sie mit intaktem Selbstnd Peer-) Respekt hinterlassen werden.

Machen Sie sich gute Notizen zu technischen Aspekten Ihres Todesmarsches. Wenn Sie die unvermeidliche Interviewfrage erhalten --- (Waren Sie in einem fehlgeschlagenen Projekt; warum ist es fehlgeschlagen und was haben Sie getan, um es zu verhindern? Bonehead-Management ist keine Antwort - auch wenn es der Grund ist .

0
radarbob