Wie schreibt man eine Projektanalyse oder ein Projektkurzbrief?

Question

Wir sind ein kleines (15 Personen) Webentwicklungs-/Designunternehmen mit etwa 8 Vollzeit-LAMP-Entwicklern. Um die Anzahl der Fehler zu reduzieren und zu verhindern, dass unsere Budgets unsere Schätzungen übersteigen, habe ich eine Art technische Analyse unserer Projekte eingeführt, bevor die Entwicklung beginnt. Für einen Anwendungsprogrammierer ist dies selbstverständlich, aber in unserem Bereich (Webentwicklung) scheint es weniger üblich zu sein. Bisher haben wir nur eine kleine Zusammenfassung erhalten, die unser Projektmanager zusammengestellt hat (oft weniger als eine Seite) und sind dann kopfüber in die Entwicklung gesprungen, was zu katastrophalen Budgetproblemen geführt hat.

Um dieses Problem anzugehen, habe ich angefangen, mich mit dem Thema zu beschäftigen. Ich habe CodeComplete2, Pragmatic Programmer und The Mythical Man-Month gelesen. Ich glaube, ich habe die Konzepte hinter der Vorbereitung und Analyse eines neuen Projekts verstanden, aber mir fehlen praktische Beispiele. Kennt jemand ein Beispiel für eine technische Analyse oder eine umfangreiche Projektzusammenfassung, die ich mir ansehen kann, um das Gelesene besser in die Praxis umzusetzen? Ich bin ein großer Fan des Lernens durch Beispiele, das muss ich nicht extra erwähnen :)

Answer 1

Leider sind die meisten Projektumfangsdokumente geschützt, so dass sie nicht veröffentlicht werden können. Ich freue mich jedoch, meine Erfahrung darüber zu teilen, was ein gutes ausmacht, und habe die Art von Dingen aufgenommen, die ich gerne sehen würde.

Das wichtigste ist daran zu denken, was Sie erreichen wollen - Sie versuchen, ein gemeinsames Verständnis zwischen Ihnen und dem Kunden darüber zu erreichen, was passiert. Schlechte Schätzungen betreffen nicht nur den Unterschied zwischen dem, was Sie dachten, dass es dauern würde und dem, was es tatsächlich dauerte, sondern auch das, was Sie dachten, dass Sie liefern würden und was der Kunde dachte, dass Sie liefern würden.

Ein Weg, all dies zu dokumentieren, ist, dass Sie abgesichert sind, und wenn der Kunde zurückkommt und sagt "Wo ist das Berichterstattungsmodul", können Sie einfach auf den Satz verweisen, in dem steht "es wird kein Berichterstattungsmodul geben", aber das ist es nicht wirklich. Es geht wirklich darum, dieses Gespräch am Anfang zu führen (wo es konstruktiv sein kann) anstatt am Ende (wo es wahrscheinlich konfrontativ sein wird). Denken Sie daran, wenn Ihr Projekt- oder Account-Manager sagt, dass zu viele Details negativ klingen.

Also, was sollten Sie einschließen:

• Hochrangige Beschreibung dessen, was getan wird - nur ein paar Absätze. Es wird wirklich keine Details liefern, aber es gibt den Rahmen vor. Also sagen Sie in diesem Abschnitt, dass Sie eine E-Commerce-Website zum Verkauf von Widgets erstellen, dass es sich um eine B2C-Website handelt und nicht um eine B2B-Website, dass das Projekt das komplette Design und den Aufbau der Website abdeckt und so weiter. Höchstens ein paar Absätze.

• Hochrangige funktionale Anforderungen - Aufzählungspunkte, die die wichtigsten Funktionen umreißen, die gebaut/entworfen werden. Geben Sie für jede enthaltene Dateneinheit an, ob sie erstellt, gelesen, aktualisiert und/oder gelöscht werden soll, da dies Ihnen helfen wird, die Aufgabe besser zu verstehen. Also die Fähigkeit, Benutzer zu erstellen/lesen/aktualisieren/löschen, die Fähigkeit, Bestellungen zu erstellen, lesen und aktualisieren, die Fähigkeit, Produktkategorien zu erstellen/lesen/aktualisieren/löschen, die Fähigkeit, Produkte einschließlich Text, Bilder und Videos zu erstellen/lesen/aktualisieren/löschen.

• Nicht-funktionale Anforderungen - ein weiterer Bereich, in dem viele Dinge übersehen werden. Nicht-funktionale Anforderungen umfassen Dinge wie Leistung, Benutzerlast, Überwachung, Archivierung, Sicherheit und so weiter. Berichterstattung könnte hier passen - obwohl es wirklich funktional ist, ist es etwas, das oft vergessen wird, da es oft etwas ist, das die Verwendung des Systems unterstützt, anstatt ein Kernbestandteil davon zu sein. Wenn Sie in einem bestimmten Bereich nichts tun (z. B. es wird keine Verlaufsprotokolle geben), dann geben Sie das klar an, vielleicht in einem anderen Abschnitt mit dem Titel...

• Aus dem Umfang raus - Während Diskussionen darüber kommen, ob etwas (eine Funktionalität, eine Schnittstelle zu einem anderen System) enthalten ist oder nicht. Schreiben Sie das auf! Einer der Hauptbereiche, in denen der Umfang in meiner Erfahrung scheitert, sind unterschiedliche Erinnerungen an diese Gespräche und wenn Sie es von Anfang an schriftlich festhalten, werden viele davon wegfallen. Dies ist ein weiterer Bereich, in dem Berichterstattung eine Rolle spielen kann (sie wissen, dass sie Berichte wollen, aber nicht was, also driftet es irgendwie ab, dann liefern Sie und sie fragen, wo sie sind), aber auch Benutzerverwaltung (Passwort zurücksetzen?) und Sicherheit.

• Annahmen - Zu diesem Zeitpunkt während des Projekts haben Sie nicht genügend Informationen, um eine wirklich genaue Schätzung abzugeben. Das ist in Ordnung, Sie können die Lücken selbst ausfüllen, solange Sie klar machen, dass dies das ist, was Sie getan haben. Wenn Sie davon ausgehen, dass sie Ihnen konzernweit Vorlagen zur Verfügung stellen, um Dinge zu layouten, dann notieren Sie das. Wenn Sie denken, dass sie den Text und die Bilder für alles zur Verfügung stellen, dann schreiben Sie es auch auf.

Andere Abschnitte, die ich in Betracht ziehen würde:

• Technische Plattform - wenn Sie der Meinung sind, dass es wichtig ist, beschreiben Sie die technische Plattform auf hohem Niveau (in diesem Fall LAMP plus eventuelle andere Teile). In meiner Erfahrung ist dies nicht wirklich ein Bereich, in dem der Umfang wirklich auftritt, aber es dauert tendenziell zwei Minuten, es zu tun, also kann es nicht schaden.

• Schnittstellen zu anderen Systemen - Meiner Erfahrung nach ist einer der Dinge, die jedes Projekt kompliziert macht, Dinge, über die Sie keine vollständige Kontrolle haben, und einer der Hauptbereiche, in denen dies geschieht, sind Schnittstellen zu anderen Systemen. Wo Sie mit diesen umgehen, ist es immer am besten, die Systeme aufzulisten, den Typ der Schnittstelle und welche Interaktionen stattfinden werden. Also, wenn Sie ihr Lagerverwaltungssystem aktualisieren, sagen Sie, dass Sie es tun, sagen Sie, dass es ein Webservice ist, sagen Sie, dass Sie Lagerbestandsanfragen senden, Lagerbestände aktualisieren usw.

• Abhängigkeiten - Auch dies ist Teil des Dinge außerhalb Ihrer Kontrolle. Wenn andere Parteien zum Projekt beitragen (einschließlich des Kunden), ist es am besten, aufzulisten, was Sie von ihnen erwarten. Wer stellt den Text bereit, in welchem Format (ist es eine gut strukturierte Excel-Datei, die leicht importiert werden kann oder eine Million Word-Dokumente)? Was ist mit einem Testsystem für die Drittanbieteranwendung, mit der Sie Schnittstellen erstellen sollen? Wann benötigen Sie diese Dinge?

Ich hoffe, das hilft.

Bearbeiten: Ich habe ein paar Vorlagen ausgegraben und leicht anonymisiert, die ich in meinem letzten Job verwendet habe. Sie sind intern (das heißt, wir waren ein internes Team, das innerhalb des Unternehmens arbeitete, im Gegensatz zu einem Team, das für andere Organisationen arbeitete), aber die Struktur und Prinzipien sind die gleichen.

Ich habe eine Projektmandatsvorlage beigefügt, die ziemlich nahe an dem Dokument ist, das Sie suchen:

http://seventeensix.tumblr.com/post/749062608/a-sample-project-mandate-template

und eine Spezifikationsvorlage, die auch einige Teile enthält, die Sie nützlich finden werden:

http://seventeensix.tumblr.com/post/749077647/a-sample-specification-template

Die Projektmandatsvorlage enthält einige echte Beispiele aus einem der Projekte dort (eine sehr langweilige Finanzsystemsabstimmungspakete), beide enthalten Struktur und Hinweise darauf, was wohin gehört, mit dem ein oder anderen Beispiel.

Answer 2

Das sind alles gute Bücher. Ich könnte auch vorschlagen, "Software Requirements 2" und "Peopleware: Produktive Projekte und Teams" hinzuzufügen (Ich habe Peopleware noch nicht gelesen; es steht schon seit einiger Zeit auf meiner To-Do-Liste, leider).

Aber ich fürchte, es gibt keinen Ersatz für Erfahrung; wenn Sie darauf achten, was Ihr Team in der Vergangenheit angegeben hat, was tatsächlich benötigt wurde, um zu liefern, und versuchen, die Gründe dafür zu finden, warum Sie mit den Teilen, bei denen Sie richtig oder falsch lagen, richtig oder falsch lagen, werden Sie lernen, wie Sie besser werden können.

In meiner Erfahrung schadet es nie, das große Problem in kleinere Probleme aufzuteilen. Iterieren. Wenn Sie denken, dass Sie schließlich Stücke haben, die 0,5 bis 1 Programmertag dauern werden, erreichen Sie den Punkt, an dem ich die besten Erfolge beim Schätzen der Zeit hatte.

Natürlich müssen Sie auch die Programmierer im Auge behalten, die für Sie arbeiten: Alice könnte eine versandfertige Lösung in einem halben Tag codieren, Bob könnte einen Tag dauern und Charlie könnte zwei Tage benötigen, wobei Bob etwas Zeit für die Codeprüfung benötigt. Die Stärken und Schwächen Ihrer Programmierer zu kennen, erfordert ebenfalls Erfahrung.