Wie viele Projektstunden werden für jede Stunde Codeschneiden für etwas anderes aufgewendet?

Ich werde argumentieren, dass das Schreiben von Code wahrscheinlich einer der unwichtigsten Teile des Projekts ist. Aus meiner Sicht ist es ein Mittel zum Zweck, am Ende des Tages übersetzen Sie die Anforderungen eines Kunden in eine bestimmte Syntax, die von einer Maschine ausgeführt werden kann, um diesem Kunden Vorteile zu bieten.

• "Anforderungserfassung, Geschäfts- und Systemanalyse" und "Funktionales und technisches Design" - Sie sollten viel mehr Zeit damit verbringen als mit dem Schreiben von Code. Wenn Anforderungen und Design nicht klar sind, verurteilen Sie sich im besten Fall zu viel Nacharbeit und verschwendeter Zeit oder im schlimmsten Fall zu einem Projektprodukt, das nicht den geplanten Nutzen bringt.
• „Systemtests, einschließlich Testplanung und Entwicklerzeit zum Beheben von Fehlern“ und „Entwicklerzeit zum Beheben von Fehlern, die sich aus Benutzerakzeptanztests ergeben“ – ich glaube nicht, dass irgendjemand die Zeit dafür aufwendet, die er sollte, es gibt zu viel Druck, etwas herauszubringen schnell. Idealerweise planen Sie in Ihren Plänen viel Zeit für das Testen und Beheben von Fehlern ein (schätzungsweise 20-30 % der gesamten Projektzeit). Das hört sich nach viel an, aber denken Sie daran, dass Sie a priori nicht vorhersagen können, wie viele Fehler Sie haben werden oder wie schwer sie zu beheben sein werden.
• "Bereitstellungsplanung, Bereitstellung und Unterstützung nach der Bereitstellung" - Sie können den besten Code der Welt haben, aber wenn Ihre Bereitstellung schlecht ist, wird Ihr Projekt nicht die Vorteile ernten, die es sollte. Analog dazu kann ich das am besten konstruierte Auto der Welt bauen, aber wenn ich keinen guten Plan für den Verkauf und die Wartung nach dem ersten Verkauf habe, werde ich eher früher als später aus dem Geschäft sein.
• "Project Management, Requirements and Design Walkthroughs" - Dies hängt vollständig von der Kritikalität und Komplexität Ihres Projekts ab. Selbst für das einfachste Projekt benötigen Sie mehr Aufsicht/Governance, wenn es Ihrem Unternehmen gut oder schlecht geht. Abgesehen davon ist die Projektaufsicht wahrscheinlich das einzige Element, das ich anpassen würde, damit ich mehr Budget für die Programmierung zuweisen kann.

TL;DR

Sie haben ein Szenario beschrieben, in dem Ihr Prozess-Overhead tatsächlich nur etwa 10 % beträgt. Das scheint für die meisten Zwecke sicherlich ausreichend zu sein.

Möglicherweise kategorisieren Sie Voraussetzungen und Abhängigkeiten fälschlicherweise als Prozess-Overhead. Dadurch haben Sie fälschlicherweise festgestellt, dass Ihr Prozess 80 % Ihrer verfügbaren Arbeitsstunden verschwendet (oder einen Prozess-Overhead von etwa 500 % verursacht), obwohl Ihr Prozess-Overhead weit unter dem Durchschnitt von 35 % für die amerikanische Industrie zu liegen scheint eine ganze.

Akzeptable Ebenen des Prozess-Overheads sind eigentlich nur Managementziele und variieren je nach Organisation, Tätigkeitsbereich und Projektmanagement-Framework. Es gibt keine einzelne Zahl, die für alle Szenarien ideal ist.

Prozessvoraussetzungen

In gewisser Weise betrachten Sie die Dinge rückwärts, weil Ihre Frage axiomatisch davon ausgeht, dass das Schreiben von Code der Hauptzweck Ihres Projektmanagementprozesses ist. Es ist nicht. Wert auf vorhersehbare und kontrollierte Weise zu liefern, ist die Daseinsberechtigung des Projektmanagements.

Im Allgemeinen sind die meisten der zusätzlichen Schritte, die Sie als Overhead aufgeführt haben, nicht . Beispielsweise ist das Sammeln von Anforderungen kein wirklicher Overhead, da Sie keinen funktionierenden Code liefern können, wenn Sie nicht wissen, welchen Code Sie schreiben sollen oder was dieser Code tun soll, sobald er geschrieben ist. Das Sammeln von Anforderungen ist daher eine Voraussetzung für das Schreiben des Codes; oder, wenn Sie es vorziehen, es umzukehren, das Schreiben von Code hängt von der Erfassung von Anforderungen ab.

Die meisten der Schritte, die Sie aufgelistet haben, schaffen einen Mehrwert für das Projekt. Sie stellen sicher, dass Sie die richtigen Dinge in der richtigen Reihenfolge bauen. Das klassifiziert sie als Voraussetzungen und Abhängigkeiten und nicht als Verschwendung .

Verarbeitungsaufwand

Während es sicherlich eine technische Definition gibt, ist der Prozessaufwand in der Praxis alles, was den Ergebnissen keinen inneren Wert hinzufügt, aber dennoch für das Funktionieren des Projekts selbst notwendig ist. Projektmeetings, Projektmanagement-Artefakte und Projektkommunikation sind oft gute Beispiele für typische Gemeinkosten.

Rechne nach

Sie haben einen Prozess definiert, der insgesamt 5 Mannstunden pro Feature umfasst, von denen nur 30 Minuten als Overhead klassifiziert werden sollten. So verbringen Sie nur 10 % Ihrer Projektzeit mit Prozessgemeinkosten. Im Gegensatz dazu erfordert ein typisches Scrum-Projekt oft rund 30 % Overhead für seine Prozesse.

Ich sehe kein wirkliches Problem, es sei denn, Sie haben einen bestimmten Geschäftsgrund, um diese Zahl auf unter 10 % zu reduzieren. Wenn das Management oder Ihr Entwicklungsteam jedoch der Meinung ist, dass es Verschwendung gibt, die gekürzt werden kann, können Sie auf jeden Fall nachsehen, wo Sie einige inkrementelle Verbesserungen vornehmen können, ohne die Qualität zu beeinträchtigen.