Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03355.jsonl.gz/2749

Grund Nr. 1: Unklare Absicht und fehlende Entscheide
d.h. unklare Ziele auf jeder Ebene.
- Das Gesamtziel, die Teilziele der Teilprojekte und die eigentlichen Ziele der Meilensteine sind nicht dem ganzen Team klar.
- Die Ziele des Projektes, der Teams und der einzelnen Entwickler sind nicht aufeinander ausgerichtet.
- Es werden zu viele Ziele gleichzeitig verfolgt, jedes Ziel hat noch drei Optionen, es gibt keine klaren Entscheide für oder wider.
- Es werden unnötige Ziele erreicht, da das Entwicklungsprojekt Technologie-getrieben statt Kunden-getrieben ist.
Lösung: Klare operationalisierte Ziele aufschreiben
- Operationalisierte Ziele heisst, dass es klar ist was das Produkt beim Erreichen des Ziels macht, oder zumindest was der Stand welcher Dokumente und sonstigen Artefakte im Projekt ist.
- Es heisst auch klarzustellen, was das Produkt nicht macht, was die Nicht-Ziele sind.
- Wir finden es am effizientesten, mit Absichten zu arbeiten:
- Wie sieht Erfolg aus?
- Was wollen wir hier erreichen?
- Aufschreiben heisst, dass die Ziele in einem jedem zugänglichen Dokument oder noch besser auf einer Team-Wiki Seite formuliert sind.
- Achtung Falle: in vielen Teams gibt es einen sehr digitalen Umgang mit Zielen: entweder wird nichts aufgeschrieben, oder dann entsteht gerade ein riesiger "Requirement-Management" Formalismus. Auch hier liegt der Weg in der Mitte, ein paar Bullet-Points auf einer Wiki Seite sind am Anfang besser als nichts, aber auch besser als formal richtige Anforderungen, welche erst am Ende des Projektes fertig werden...
- Was nicht heisst, dass es ohne Requirements geht: Anforderungen sind als Detail-Ziele unverzichtbar.
- Unverzichtbar ist auch die Einsicht, dass Änderungen der Anforderungen Bestandteil jedes Projektes sind.
- Sobald Anforderungen aufgeschrieben sind, können sie diskutiert werden. Wenn diese Diskussionen mit allen Betroffenen von Produktmanagement bis Entwicklern gut geführt werden, dann werden die Anforderungen "automatisch" den richtigen Detaillierungsgrad erreichen.
- Entscheide: einfach entscheiden und die Resultate schriftlich festhalten.
- Wir schauen Entscheide als Experimente an, dann fallen sie leichter: Wir stellen mit dem Entscheid eine Hypothese auf. Dann überprüfen wir diese Hypothese in der Praxis, in einem Experiment. Sobald wir sehen, dass wir die falsche Hypothese genommen haben, passen wir diese an. Wenn wir die richtige genommen haben, müssen wir nichts anpassen.
- Wenn Termine eingehalten werden sollen, ist es besser, zu entscheiden statt noch auf zusätzliche Informationen zu warten ("Paralysis by Analyis").
- Änderungsmanagement: Was nicht den Zielen entspricht, ist eine Änderung, diese im Projekt klar ausweisen und ihre Auswirkungen abschätzen ("Impact Management"). Diese Abschätzung dient als Entscheidungshilfe dafür, ob sich der Aufwand in Zeit und Geld für die Änderung lohnt.
Übrigens entkräftet die klare Formulierung von Zielen und Anforderungen das Argument "interne Mitarbeiter und Freelancer sind einfacher zu führen als ein externes (Teil-)Projekt, da wir nichts spezifizieren müssen": auch Interne müssen wissen, was sie zu tun haben!