Zeitverschwendung nach dem Projekt?

An meinem Arbeitsplatz hatten wir einige ernsthafte Wachstumsbeschwerden. Wir sind von einem 3-köpfigen Entwicklerteam auf 10 angewachsen, und das Unternehmen selbst ist im vergangenen Jahr um 30% gewachsen. Bei den meisten Messungen geht es uns gut. Leider hat die Qualität unserer Software gelitten.

In einem heutigen Meeting mit dem Manager meiner Abteilung schlug ich ein Projektteam vor, das sich ein oder zwei Tage nach Einführung des Produkts trifft. Wir konnten über Budgetprobleme, den Umfang, das, was schief gelaufen ist und was richtig gelaufen ist, diskutieren. Idealerweise aus unseren Fehlern lernen. Wir erstellen Websites / Apps für andere Personen, sodass unsere Zeit entweder nicht abgerechnet werden kann. Ein solches Treffen würde unter Letzteres fallen.

Mein Vorgesetzter hat es fast sofort abgeschossen: "Diese Zeit ist nicht fakturierbar. Dadurch kommen wir bei einem anderen Projekt ins Hintertreffen, weil wir am Ende Zeit damit verschwenden, darüber zu reden." Ich war von dieser Logik so überrascht, dass ich mich nicht einmal darum gekämpft habe.

Also meine Frage: Ich sehe, der Wert sind Meetings nach dem Projekt, aber er tut es nicht. Gibt es dokumentierte Nachweise für Meetings nach dem Projekt, die helfen, auf lange (oder kurze) Sicht Zeit und Geld zu sparen? Intuitiv denke ich, es wird / würde, aber er ist eindeutig besorgter über eine kleine Menge nicht abrechenbarer Zeit von den 5 Leuten, die da sein müssten.

Rückblickend wäre ein Blick in die Zukunft ein dokumentierter Beweis für die Idee. Das Projekt Post-Mortem: Ein wertvolles Instrument zur kontinuierlichen Verbesserung wäre ein Blog-Beitrag darüber.

Die Kunst des Obduktionsprozesses hat diesen Punkt in Bezug auf die Idee:

Die Ursprünge des Post-Mortem liegen beim Militär, das routinemäßig diese Art von Verfahren einsetzt, um die Leute an der Front zu befragen. Die Managementanwendung ist jedoch für jede leistungsstarke, lernende Organisation von entscheidender Bedeutung.

Ihr Manager versteht das Konzept der technischen Schulden nicht .

Meetings nach dem Projekt sind eine Investition, keine Kosten. So muss man sie verkaufen. Ziel eines Meetings ist es, Ideen auszutauschen, wie man Geld spart und die Unternehmensziele langfristig erreicht.

Ihr Manager ist ein Manager, weil er sich mit diesen langfristigen Zielen befasst. Meiner Ansicht nach gibt es also zwei mögliche Wahrheiten: Ihr Manager möchte die volle Kontrolle über sich selbst haben, oder Ihr Manager erledigt seine Arbeit nicht. Wenn das Unternehmen die Tradition und Philosophie hat, Dinge "richtig" zu machen und in den eigenen Erfolg zu investieren, sollten Sie das Problem über Ihren Vorgesetzten stellen.

Dies ist im Wesentlichen eine Überprüfung nach einer Aktion , die in vielen verschiedenen Zusammenhängen, nicht nur beim Militär, besonders nützlich ist.

In meinem eigenen Entwicklungszyklus analysiere ich sowohl, was in der nächsten Iteration oder im nächsten Projekt getan werden sollte, als auch, was im vorherigen Projekt besser getan werden könnte. Selbst wenn ein Projekt für eine Weile auf Eis gelegt wird, hilft es, eine Liste von Dingen zu haben, an denen gearbeitet werden muss, wenn es von der Stange ist (oder Backburner ...) und wieder aktiv ist. Wenn ich es das nächste Mal berühre, muss ich nicht mehr so ​​viel Zeit darauf verwenden, zu überprüfen, was ich tun muss.

Durch Überprüfen eines Projekts und Auffinden der von mir oder anderen implementierten Tricks werden diese außerdem verbreitet, und das nächste Projekt oder die nächste Iteration ist umso besser. (Es mag nicht überraschen, dass ich häufig an Iterationen denke.)

Der Wert davon ist einfache Logik und von Natur aus offensichtlich. Wie können Sie zukünftige Projekte verbessern, wenn Sie nie aus Ihren Fehlern bei früheren Projekten lernen?

Die Überprüfung des Prozesses (während oder nach der Fertigstellung) ist ein wesentlicher Bestandteil fast aller mir bekannten standardbasierten Qualitätskontrollsysteme, insbesondere CMMI und Lean 6 Sigma.

Vielleicht könnten Sie es als nicht verpflichtend vorschlagen, etwas, das freiwillig während eines Mittagessens gemacht wird, oder so? Die Chancen stehen gut, dass nicht wenige in Ihrem Entwicklerteam gerne neue Dinge ausprobieren möchten. Wenn Sie also mindestens die erste Variante ausprobieren können, werden die Ergebnisse für sich sprechen.

Es kann sein, dass Ihr Manager unter Budgetdruck steht. Das muss ein großes Problem sein, wenn man in kurzer Zeit von 3 auf 10 Entwickler expandiert. Wenn dies der Fall ist, ist es wahrscheinlich eine gute Idee, die Post-Mortem-Sitzungen vorerst zu überspringen und sie in ein paar Monaten erneut vorzuschlagen, wenn die unmittelbaren Budgetprobleme hoffentlich nicht so dringend sind.

Ein Grund dafür, dass die Qualität darunter leidet, ist, dass die Kommunikation zwischen 10 Personen ein viel größeres Problem darstellt als die Kommunikation zwischen 3 Personen: 3! << 10 !. Während Sie wahrscheinlich eine Weile durcheinander sein können, müssen Sie eventuell einige Änderungen vornehmen, um eine bessere Kommunikation zwischen den Entwicklern zu fördern und um sicherzustellen, dass die Prinzipien, die die ursprünglichen 3 Entwickler festgelegt haben, auch auf die Website übertragen werden Neuere Leute und aktualisiert, um in Ihrer neuen größeren Gruppe gut zu funktionieren. Project Post-Mortem-Meetings sind eine Möglichkeit, dies zu tun. regelmäßige Codeüberprüfungen sind eine andere. Es würde nicht schaden, darauf hinzuweisen, dass Obduktionen ein entscheidender Bestandteil der Qualitätsverbesserung in den Branchen von der Medizin bis zur Fertigung sind.

Es ist kaum vorstellbar, dass Ihr Manager der Meinung ist, dass er sein Entwicklungsteam erweitern kann, indem er einfach zusätzliche Mitarbeiter anstellt. In Training und Teambuilding muss unbedingt investiert werden. Andernfalls wird Ihre Organisation unter ihrem eigenen Gewicht zusammenbrechen. Wenn Sie etwas warten, kann es in Ihrem Unternehmen zu konkreten Problemen kommen, die direkt auf eine schlechte Kommunikation zurückzuführen sind. Zu diesem Zeitpunkt wird Ihr Manager wahrscheinlich sagen: "Wir müssen alle auf die gleiche Seite bringen! Planen Sie ein Treffen mit allen Entwicklern!" Und wenn es zu helfen scheint, wird er wahrscheinlich sagen: "Wir sollten das nach jedem Projekt tun!" ;-)

Sei also geduldig, aber beharrlich.

Ich werde mich gegen den Trend wenden: Ich stimme dem Manager zu.

Ich fand Überprüfungen nach dem Projekt größtenteils sinnlos, weil es zu spät ist, irgendetwas zu tun, um die aufgedeckten Probleme zu beheben.

Was ich wärmstens empfehlen würde, sind regelmäßige Rückblicke während des Projekts. Ein- oder zweimal im Monat soll das Team darüber sprechen, was gut gelaufen ist und was nicht. was mehr zu tun, was weniger zu tun. Tun Sie dies während des Projekts, damit Sie die Vorschläge sofort anwenden und sehen können, wie gut sie funktionieren.

Schauen Sie sich an, wie Sie das Meeting vervollständigen. Viele Post-Projekt-Meetings sind Talk-Fiests, und Ihr Manager hat absolut Recht, sie nicht zu unterstützen.

Laden Sie Sie ein, das Meeting zu leiten (bitten Sie ihn, den Vorsitz zu führen / zu moderieren), eine Tagesordnung zu verteilen und konkrete Ergebnisse zu erzielen. Als Manager kann er dann den Wert in der Besprechung sehen.

Wir verwenden, und ich empfehle de Bonos "6 Thinking Hats" -Überprüfungsverfahren ( siehe Wikipidia ). Das Ergebnis sind einige (2 oder 3) Aktionspunkte, die das Meeting als die wichtigste erlernte Ursache identifiziert. Die ersten Male haben wir Probleme, aus den Startlöchern herauszukommen, aber sobald wir uns daran gewöhnt haben, werden wir nicht mehr zurückkehren.

Wenn Sie nach dem Projekt keine Überprüfung durchführen, werden Sie die gleichen Fehler machen, die Sie im vorherigen Projekt gemacht haben.