Wie soll ich mich als Entwickler in einem Projekt verhalten, das auf ein Scheitern zusteuert?

335

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.

Louis Rhys
quelle
Teilweise sind Sie Teil eines Problems. Warum haben Sie keine Komponententests durchgeführt? Als Entwickler sollte es Ihre Pflicht sein. Sie können das als großen Fehler für jeden hinzufügen, der dieses Projekt verwaltet hat.
Freitag,
1
Verwandte Frage (aber ich denke kein Duplikat): Was ist der produktivste Weg, um entwicklungsbedingte Fehler zu behandeln? . Der beste Rat, den ich Ihnen geben kann, ist, das Management zu informieren und dann Ihr Bestes zu geben. Sie können Ihre zugewiesenen Jobs nicht kontrollieren, aber Sie können Ihre Reaktion darauf kontrollieren und beweisen, dass Sie ein wertvoller Mitarbeiter sind, der immer sein Bestes gibt, egal was passiert.
Rachel
Welche Art von Softwareprozess verwenden Sie? Wasserfall / Agile? Und welches? RUP / Scrum / XP ...?
Sjuul Janssen
28
Aktualisieren Sie Ihren Lebenslauf. Verliere nicht den Schlaf wegen des Problems eines anderen. Erwarten Sie, dass die Dinge nach Ablauf der Frist verlängert werden.
Sean McSomething
6
@ Kevincline Es ist eine lange Geschichte, aber am Ende haben wir sie pünktlich geliefert, mit vielen Fehlern und fehlenden Funktionen. Sie scheinen das System ziemlich sehr zu wollen, deshalb haben sie beschlossen, uns mehr Zeit zu geben. Unser Ruf hat sehr gelitten, aber im Allgemeinen haben die Leute gemerkt, dass viele Leute eine Menge Fehler in diesem Projekt begangen haben, also sind wir nicht der Sündenbock dafür. Projekttechnisch lief es besser als erwartet, aber persönlich ist die monatelange Arbeit in diesem Projekt und in der Codebasis wirklich demotivierend
Louis Rhys

Antworten:

317

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.

MrFox
quelle
51
+ 1. Eine Sache, die ich hinzufügen möchte, ist, dass Managemententscheidungen, die Ihnen dumm vorkommen, mit einer geringen Wahrscheinlichkeit gute Gründe haben, die Sie nicht einschätzen können, aber die meiste Zeit in der Tat dumm sind. Natürlich liegt es im Interesse des Managements, Sie von etwas anderem zu überzeugen
;-)
178
+1, aber "in gutem Glauben arbeiten" bedeutet nicht, Ihr persönliches Leben zu opfern, um an einem Todesmarsch endloser unbezahlter Überstunden teilzunehmen.
Kevin Cline
27
@LouisRhys Immer wenn Sie es mit etwas Sensiblem zu tun haben, bei dem Emotionen auftreten können, und wenn Sie jemandem sagen, dass etwas Wichtiges scheitern könnte, in das er investiert ist, kann es sehr wichtig sein, eine Papierspur zu haben. Dies ist definitiv eine Zeit für CYA.
Jeremy Pridemore
17
@LouisRhys Sie können mit ihm bei einem Kaffee / Tee sprechen, aber schreiben Sie anschließend immer Ihre Hauptanliegen in eine offizielle E-Mail. Wenn die Scheiße in 1,5 Monaten den Fan erreicht, können Sie auf die E-Mail zurückgreifen, die Sie gesendet haben, und so die Schuld für das "Warum wurde uns nicht früher Bescheid gegeben?" Fragen, die von oben aufkommen werden. Es fungiert auch als "umsetzbares" Element, was bedeutet, dass Ihr Manager eher dazu geneigt ist, etwas zu tun, als seinen Kopf zu senken, und hofft, dass am Ende alles in Ordnung ist.
Mike Weller
4
Versuchen Sie in Ihrer Zusammenfassung, technische Details und Meinungen nach Möglichkeit zu vermeiden, aber formulieren Sie die Dinge so, dass sie von jemandem gelesen und verstanden werden können, der kein Spezialist für Ihre Technologie ist, aber in der Lage ist, Ihre Gründe für Bedenken zu verfolgen und zu berücksichtigen das bei der Entscheidung berücksichtigen.
TobyEvans
105

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.

Dan Pichelman
quelle
59
@JimG. Es soll dem oberen Management und / oder der Personalabteilung zeigen, ob / wann die Dinge schlecht laufen. Wenn Sie in eine Situation geraten, in der Sie etwas sagen und jemand anderes (möglicherweise Ihr Vorgesetzter, der versucht, seine eigene Haut zu retten) etwas anderes sagt, ist es hilfreich, eine Dokumentation auf Ihrer Seite zu haben. Fehlgeschlagene Projekte führen nicht immer zu Fingerzeig und Schlammschlägen, aber es kommt oft genug vor, dass ein bisschen Selbstverteidigung mit gesundem Menschenverstand nie weh tut.
Dan Pichelman
89

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.

Meine Fertigkeiten im Umgang mit MS Paint haben mir dabei geholfen!

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.

Tangurena
quelle
4
+1 für eine Antwort, die etwas mit Softwareentwicklung zu tun hat.
PSR
2
Um ein anderes Yourdon-Zitat zu stehlen: "Stimme mit deinen Füßen ab". Vor ungefähr 10 Jahren befand ich mich in einer Situation, in der ich die fünfte Person innerhalb eines Jahres war, die ein 4-köpfiges Entwicklungsteam verließ. Kurz bevor wir abreisten, hatten wir einen neuen Vizepräsidenten, der hereinkam und uns so etwas wie die "Motivations" -Rede an die Orks in den zwei Türmen überreichte, um nach den Hobbits zu suchen. Ein paar Monate später bin ich einfach gelaufen. Es wäre schön gewesen, einen Job zu haben, aber ich war einfach zu ausgebrannt. Der Abflug war im Nachhinein eines der besten Dinge, die ich je getan habe.
Roboprog
Dies ist eine viel bessere Antwort. Das OP beschreibt eine Situation, in der ich mich befinde und von der ich zu oft höre. Manchmal zum Scheitern verurteilt, und manchmal in kleine Stücke geschnitten und serviert ..
hanzolo
58

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.

Mark S
quelle
11
+1: Nummer 2 ist so wahr ... Keine gute Tat bleibt ungestraft.
Paulo Scardine
3
Meine Regel im Leben ist, wenn (2 :) dann gehe zu (3 :) in Bezug auf (1 :)
John Nicholas
1
Ich stimme voll und ganz mit # 1 überein. Der Erfolg kann größtenteils innerhalb der ersten 100 Tage des Projekts vorhergesagt werden. Wenn dir dein Bauch sagt, dass etwas nicht stimmt ... hör es dir an.
Herr JavaScript
35

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.

code4life
quelle
Nur ein Zweifel: "Bemühen Sie sich, immer besseren Code zu schreiben, immer höhere Qualitäts- und Funktionsstandards zu erfüllen": Wenn das Projekt scheitert, ist wahrscheinlich keine Zeit, mehr Qualität anzustreben. Vielleicht sollte der Fokus stattdessen auf Produktivität / Effizienz liegen.
Francesco Feltrinelli
2
@FrancescoFeltrinelli: Du hast wahrscheinlich einen Punkt. Ein Teil von mir ist jedoch der Meinung, dass ich nicht den Fokus verlieren möchte, in Krisenzeiten nach Möglichkeiten zur persönlichen Verbesserung zu suchen. Es ist erstaunlich, was wir in einer Krise lernen können und wie uns dies dazu verleitet, größere Herausforderungen im weiteren Leben zu meistern.
Code4life
Ein gescheitertes Projekt zu retten, kann seine Schattenseiten haben. Dies erhöht die Wahrscheinlichkeit, dass Sie dem nächsten fehlgeschlagenen Projekt zugewiesen werden.
Martin Brown
23

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
ozz
quelle
12
Gutes Management weiß, dass Projekte manchmal scheitern. Ein schlechtes Management versucht, Sündenböcke zu finden, wenn Projekte scheitern. In beiden Situationen ist guter Code besonders wichtig, wenn Sie einen anderen Job benötigen. Bei Interviews werden Sie zwangsläufig gefragt, woran Sie arbeiten. Zumindest können Sie ehrlich auf Ihren eigenen Code stolz sein.
Michael Shopsin
22

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.

Reactgular
quelle
12

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.

cdkMoose
quelle
+1; Dies ist, was gutes Management tun sollte, aber wenn es nicht kann oder nicht kann, kann es den Tag retten, Initiative zu zeigen. Verstehe nur, dass diese Dinge normalerweise bereits in Betracht gezogen wurden.
1
Einverstanden, das sind Dinge, von denen ich auch sagen würde, dass sie der Manager hätte tun und seinem Manager vorlegen sollen. Nach Meinung von OP ist dies der positivste Ansatz, anstatt sich in den Treibsand der Niederlage zu stürzen.
cdkMoose
12

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.

Michael Cook
quelle
3
Wofür steht CYA?
Radu Murzea
3
"Bedecke deinen Arsch". Ich bin mir nicht sicher, ob ich das hier sagen kann, aber das bedeutet es.
Michael Cook
Punkt 4, ohne eine automatisierte Testsuite, wird die Dinge zerbrechen. Sei vorsichtig.
Steven A. Lowe
11
  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.
Jim G.
quelle
7

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.

Treten Sie zurück
quelle
4

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.

JeffO
quelle
4

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).
Mücke
quelle
4

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.

Steven A. Lowe
quelle
Zur Klarstellung, das vorherige Team hat nicht in diesem Sinne "Kaution". Der Manager war wirklich unzufrieden mit seiner Arbeit und dachte, dass unser Team es besser machen wird
Louis Rhys
@ LouisRhys: sehr interessant. Der Manager war der Meinung, dass Ihr Team ein fehlgeschlagenes Projekt aufgreifen, alles darüber erfahren, es umdrehen und es in ~ 3 Monaten fertigstellen könnte? Die Implikation ist, dass Ihr Team großartig ist ... und Ihr Manager auf Heldentaten setzt. Dies ändert die Interpretation der Situation ... aber von Ihrer Beschreibung halte ich es nicht für das Ergebnis. Wenn Sie so geneigt sind, teilen Sie dem Manager genau mit, was Sie für den Erfolg benötigen (einschließlich viel mehr Zeit), und machen Sie es. Viel Glück!
Steven A. Lowe
@ LouisRhys: Antwort bearbeitet, um die falsche Annahme zu korrigieren, danke!
Steven A. Lowe
Wir haben vor diesem ein paar erfolgreiche Projekte abgeliefert, also hoffte er vielleicht, wir könnten dasselbe mit diesem machen. Aber ich denke, er hat uns wirklich überschätzt und unterschätzt, was nötig ist, um dieses Projekt zu "reparieren"
Louis Rhys
@ Louis Rhys: Töte dich nicht für seine Fehler; Wunder brauchen Zeit und kosten Geld!
Steven A. Lowe
3

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.

Ton
quelle
3

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

Eran Medan
quelle
1

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?)
Sjuul Janssen
quelle
0

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.

Dunk
quelle
+1: Ein zum Scheitern verurteiltes Projekt ist wie Treibsand: Je mehr Sie sich bewegen, desto mehr sinken Sie.
Paulo Scardine
@Paulo: Ich denke, es hängt davon ab, "warum" das Projekt zum Scheitern verurteilt ist. Wenn es hauptsächlich darum geht, ob das Budget oder der Zeitplan nicht eingehalten werden kann, gibt es Dinge, die das Management tun kann. Wenn es sich um Inkompetenz von Entwicklern (insbesondere SW Lead) handelt und das Management dies nicht sieht, ist dies eine ganz andere Sache. Auf jeden Fall ändert dies jedoch nichts an der Tatsache, dass Sie sich weiterhin nach besten Kräften um die Teile bemühen sollten, die Sie kontrollieren können. Das Unternehmen zahlt Ihnen immer noch das gleiche, ob das Projekt gut läuft oder nicht.
Eintauchen
0

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.

Radarbob
quelle
0

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.

Lech Rzedzicki
quelle
Dieser Beitrag ist ziemlich schwer zu lesen (Textwand). Hätten Sie etwas dagegen bearbeiten sie in eine bessere Form ing?
gnat