Ein Projekt starten

Lass uns von Null zu Held werden, indem wir uns die Bestandteile für ein Projekt ansehen, das zu einem Produkt wird, das etwas Nützliches wird.

Du wirst ein großartiges Produkt bauen, aber ich habe eine Nachricht für dich. Alles beginnt als Projekt. Das ist in Ordnung. Wir können es Produkt, MVP (Minimum Viable Product) oder was auch immer nennen, aber es wird zuerst als Projekt beginnen.

Viele Unternehmen diskutieren das Warum und welche Vorteile diese besondere Aktivität hinzufügen würde. Schau dir Budget an, um einige Informationen über NPV (Net present value - was ist es jetzt wert?) – Berechnungen und Build oder Buy zu erhalten.

Es gibt viele Projektmanagement-Methodologien, die dir beim Starten, Planen, Implementieren, Testen, Freigeben und Schließen deines Projekts helfen können. Es gibt auch einige Methodologien, die dies in Iterationen durchführen, also kurze Wiederholungen, anstatt längere "Phasen".

Was dies für Projekte bedeutet, hat große Auswirkungen darauf, wie du es einrichtest, wie du es führst und wie es ausgeliefert wird.

Um der Vollständigkeit dieses kleinen Buches willen werde ich kurz die klassische Projektmanagement-Methode, aka "Waterfall", erklären. Stelle dir einen Fluss vor. Das ist dein Projektprozess. Du bewegst dich immer den Fluss hinunter und du kehrst nicht zurück, um Dinge zu ändern, während du vorwärts gehst, es ist festgelegt und entschieden.

Also bewegst du dich weiter und gehst in verschiedene Phasen, wie die Implementierungsphase, in der der gesamte Code codiert werden soll, und später die Testphase, in der er getestet werden soll. Alles basiert auf vorherigen Spezifikationen, die vor dem Start des Projekts geschrieben wurden.

Du wusstest genau, was du bauen wolltest, bis zur letzten Schaltfläche. Also hast du Monate damit verbracht, dies in ein Dokument zu packen, dann haben deine Senior-Entwickler oder Architekt dir geholfen, die Funktionen im Funktionalen Spezifikationsdokument zu schreiben. Dann hast du in der Implementierungsphase genau das gebaut, was in dieser Spezifikation stand. Dann hast du getestet, ob es wie spezifiziert funktioniert.

Das hat in keinem Technologie-Projekt jemals funktioniert. Die besten Auslieferungen solcher Art von Projekten haben eine Anwendung hervorgebracht, die genau das tat, was sie sollte, aber keine Erkenntnisse oder Ideen berücksichtigt, die während der Entwicklung gefunden wurden.

Auch ist im Laufe des Projektverlaufs Zeit vergangen und du hast einige Chancen verloren, dies potenziellen Kunden zu zeigen und wertvolles Feedback zu erhalten. Jetzt hast du etwas gebaut, das du nicht gegen echte Benutzer getestet hast. Ich werde hier einen mutigen Sprung machen und sagen, dass es wahrscheinlich nicht das ist, was du wolltest.

Lies mehr in "The CTO Playbook" verfügbar auf Amazon/Kindle.