Wie behält man alle Ziele eines großen Projekts im Auge?

Die Antwort von Mathias ist solide. Ich persönlich würde dafür nicht zu einem vollständigen Scrum gehen, da es sich um ein Ein-Personen-Projekt handelt und die laufende Arbeit das Kritische ist, was hier vor sich geht. Ich würde also bei einem geradlinigen Kanban-Workflow bleiben und Ihre WIP-Limits für aktive Arbeit sorgfältig im Auge behalten.

Im Wesentlichen müssen Sie Ihren Rückstand stufen. Wie bei einem Trichter erhalten Sie immer tiefere Details, je näher Sie der eigentlichen Arbeit kommen. Hier ist, was ich neige dazu zu verwenden.

Episch – Auf diesem Level haben Sie einen Rückstand an den allgemeinen High-Level-Dingen, die erledigt werden müssen. Wenn wir zum Beispiel das nächste Tesla-Auto bauen, könnte ein Epic-Element „Neues Dashboard“ sein. Sie brauchen nicht mehr Details als diese. Wenn Sie Dinge im Dashboard kennen, die erledigt werden müssen, listen Sie sie als Akzeptanztests für das Epic „Neues Dashboard“ auf. So haben Sie vielleicht „Glovebox“ und „Driver’s Multi-Function Display“ als Abnahmetest im Epic für „New Dashboard“ aufgeführt.

Feature - Ein Epic wird normalerweise in 4-6 Features zerlegt. Dies sind immer noch "Projekte" für sich, obwohl Sie immer mehr ins Detail gehen und verstehen. Am Tesla-Beispiel würden wir uns jetzt das „Fahrer-MFD“ ansehen. Wir beginnen, mehr Einzelheiten darüber zu erfahren, was passieren wird, und die Abnahmetests sollten umfangreicher sein.

User Story – Dies ist das eigentliche Arbeitsprodukt. Eine ausreichend kleine Arbeit, die in wenigen Tagen erledigt werden kann (2-3 sind optimal). Um das obige Beispiel fortzusetzen, könnte „Warnleuchte für niedrigen Reifendruck“ eine User Story aus der Funktion „MFD des Fahrers“ sein. In diesem Stadium haben Sie eine vollständig detaillierte Geschichte, die der Definition von „Bereit“ entspricht, dh sie ist bereit, an ihr gearbeitet zu werden.

Aufgaben - Während ich versuche, Aufgaben zu vermeiden, indem ich stattdessen User Storys klein genug zerlege, können Aufgaben dennoch einen gewissen Nutzen haben. Wenn Sie eine dreitägige User Story haben, kann Ihnen die Aufteilung der Arbeit in Aufgaben helfen, Ihre Zeitblöcke besser zu verwalten. Ich schätze Aufgaben aber nicht. Bei User Stories höre ich auf zu schätzen. Aufgaben sind nur eine Möglichkeit, Ihren Arbeitstag in überschaubare Abschnitte zu unterteilen. Ich neige dazu, Aufgaben nur als Akzeptanztests der User Story aufzulisten.

Dies sind drei separate Backlogs mit zunehmendem Detaillierungsgrad. Indem Sie sie in ihren eigenen Backlogs behalten, können Sie den Überblick nicht verlieren, während Sie sich auf die Detailarbeit konzentrieren.

Tool-Tipp: Ich benutze Trello seit Jahren. Ich verwende die Checklistenfunktion, um „Akzeptanztests“ oder Unteraufgaben zu verfolgen. Das verhindert, dass die Epic- und Feature-Backlogs überladen werden. Wenn Sie ein physisches Board verwenden, investieren Sie in großformatige Haftnotizen und schreiben Sie Ihre Epics und Features darauf. Dann können Sie die Rückseite der Notizen verwenden, um Abnahmetests oder Teilaufgaben zu notieren.

Ich würde empfehlen, hier einen Scrum-Projektansatz anzuwenden.

Sie sollten Ihr Minimum Viable Product definieren.

Sie erstellen ein größeres Backlog, das alle Projektideen (oder User Stories) enthält.

Sie organisieren dann Sprints, in denen Sie die Backlog-Elemente auswählen, an denen Sie als nächstes arbeiten möchten.

Der Versuch, alle Ziele gleichzeitig zu verfolgen, wird nicht funktionieren.

Sie müssen die Ziele zuerst auf einer niedrigen Detailebene definieren und dann spontan detailliertere Ideen einbringen. Damit alle Details direkt vor der Umsetzung im Sprint festgelegt werden.

Sie können dann eine taktische Ebene haben, auf der Sie die Details für einen Sprint definieren und organisieren. Und die strategische Ebene, auf der Sie „das große Ganze“ organisieren.

Ich werde eine Antwort der alten Schule anbieten – Sie brauchen einen Projektstrukturplan.

1. Definieren Sie das Endprodukt – wie sieht es aus? Das ist 100% der Arbeit. Beiseite: Ich würde Ihnen raten, dies auch dann zu tun, wenn Sie die anderen Antworten übernehmen. Ihr Kommentar, ich habe viele Ideen für die Aspekte des Projekts, die ich umsetzen möchte, macht mich misstrauisch, dass das Problem nicht darin besteht, dass Sie eine Fülle von Zielen im Auge behalten müssen, sondern dass Sie diese nicht erfasst haben Projekt. Erfolg kommt nicht von der Umsetzung all der coolen Ideen, die Sie haben, sondern von der rigorosen Festlegung des Projektumfangs auf etwas, das klar, eindeutig, begrenzt und erreichbar ist. Sie werden vielleicht feststellen, dass Sie durch die Reduzierung der Idee auf das minimal realisierbare Produkt auch die Anzahl der Dinge, die Sie im Auge behalten müssen, auf eine überschaubare Anzahl reduziert haben. Wenn eine Idee cool ist, aber außerhalb des Rahmens des minimal realisierbaren Produkts liegt, schreiben Sie sie auf und fügen Sie sie dem Rückstand der Dinge hinzu, die Sie später tun möchten.

2. Teilen Sie das Produkt/den Endzustand in kleinere Pakete auf. Jedes Paket sollte mit einem Verb beginnen und prüfbar vollständig sein. Die Kombination aller Pakete auf allen Ebenen sollte 100 % der Arbeit ausmachen.

3. Unterteilen Sie jedes Paket in kleinere Pakete. Arbeiten Sie rekursiv, bis ein Paket 40 Stunden oder weniger dauert.
4. Reihenfolge der Pakete - welche Pakete hängen von anderen Paketen ab? Welche müssen zuerst oder zuletzt erledigt werden.
5. Schau dir an, wie viel Zeit du hast. Wenn Sie 40 Pakete haben, für deren Fertigstellung Sie jeweils 40 Stunden benötigen, müssen Sie zugeben, dass dieses Projekt nicht in 1,5 bis zwei Jahren abgeschlossen sein wird. Wenn diese Frist zu weit entfernt ist, müssen Sie zu Schritt 1 zurückkehren und weitere coole Ideen aus der Produktionswarteschlange in den Rückstand verschieben.

Ich würde dringend empfehlen, eine Produkt-/Story-Map in Betracht zu ziehen (Google "Story Mapping" für Ausgangspunkte); physisch, wenn Sie den Platz haben, digital, wenn nicht. Ich habe im Laufe der Jahre alle Arten von Backlogs und Arbeitsansichten für Projekte unterschiedlicher Größe ausprobiert und festgestellt, dass „flache“ Formate, die das Produkt nicht wirklich repräsentieren, einfach nicht genug Kontext und „Ganzheit“ bieten. Bei der Planung ist es viel einfacher, fehlende Funktionen oder versteckte Arbeiten in einer Karte zu erkennen als in einer riesigen Liste von Dingen. Sie können es auch mit einem Iterations- oder Kanban-Board kombinieren, wie andere empfohlen haben, wobei die Karte die große Ansicht und Kanban die unmittelbare Ansicht ist.

Sie können die meisten allgemeinen Funktionen eines flachen Backlogs abdecken, indem Sie es visuell markieren – riskante Elemente, unvollständige Karten oder Funktionen, zu denen Sie zurückkehren können, Abhängigkeiten, externe Komponenten, Iterationen, Eventualitäten usw. Ich habe sogar wichtige UX-Momente abgebildet ( oder "Produktsäulen") auf bestimmte Karten, damit klar ist, wo der Benutzer sie in jedem Pfad oder Funktionsbereich treffen wird. Die Hauptnachteile, die ich bei physischen vs. digitalen Karten gefunden habe, sind, dass sie nicht schnell durchsucht werden können, und es kann schmerzhaft sein, die gesamte verbleibende Arbeit zu erhalten (da Sie manuell zählen müssen), aber das kann gemildert werden, indem Sie bleiben regelmäßig auffüllen und die Dinge in Chunks/Sprints/Kanban-Kartengeschwindigkeit gruppieren.

Das Grundproblem Ihrer Frage ist der Umgang mit Komplexität. Es könnte hilfreich sein zu sehen, wie andere Domänen (außer PM) versuchen, mit Komplexität umzugehen.

Wie gehen (wir) Programmierer mit Komplexität in den von uns analysierten Systemen um? Wir verwenden Tools (oder vielleicht sind dies Strategien). Seien Sie sich bewusst, dass es zwei Seiten geben kann, um mit Komplexität umzugehen, was in meiner Aufzählungsliste gezeigt wird. Es könnte sich lohnen, nach einigen dieser Techniken oder Prinzipien zu googeln.

• Generalisierung und Spezialisierung;
• Verbergen von Informationen, Kapselung;
• Aggregation, Zusammensetzung;
• Trennung von Bedenken;
• Modularisierung;
• Detailebenen.

Auf einer abstrakten Ebene geht es immer darum

1. Heben Sie die Spezialität der Ziele hervor, um einen klaren Umfang zu definieren
2. Zusammenfassung der zugehörigen Ziele