Manch BWLer oder sonst wer, der sich nach einem gescheitertem Software Projekt zum nachträglichen Fachmann ausruft, fordert vehement ein Pflichtenheft zu sehen. .... um es den Programmierern mal so richtig unter die Nase halten zu können.
Aber wäre ein Pflichtenheft wirklich schlau gewesen? Wäre man überhaupt fähig gewesen, dieses so zu formulieren, dass das Produkt beschrieben wird, welches man beschreiben wollte? Wird man überhaupt noch vom Knowhow der Programmierer und Softwarefachleuteprofitieren?
Ich plädiere eher dazu, im ersten Schritt nur die Intention der Software zu beschreiben, evtl zusätzlich mit Grafiken zu strukturieren. Das sollte möglichst leicht verständlich geschehen. Softwareteams sind keine Akademiker und deren Englisch ist auch eher ein Programmiererenglisch den BWL Englisch.
Im nächsten Schritt würde ich über eventuell sinvolle MVP Schritte nachdenken und ausführlich mit den Programmierern und ggf auch späteren Anwendern besprechen: die Suche nach dem Kern minimaler Funktionalität um danach die Weiterentwicklung anhand Nutzererfahrungen die Grundidee ggf. Iterativ zu justieren. Nach dieser Diskussion würde ich die Programmierer Agentur das in Userstories oder Jobstorys (jtbd) dokumentieren lassen. Diese sind dann eine bessere Vertragsgrundlage (immer in Verbindung mit der Beschreibung des Gesamtziels, um zu dokumentieren, welchen Leistungsanforderungen das programmierte Werk später standhalten muss) statt eines Pflichtenheftes.
Die Planungs- und Vertragsphase würde ich nach Unterzeichnung der formulierten Jobstories um die Erstellung von Wireframes erweitern. Diese geben die Chance zu überprüfen, ob alle beteiligten auch das gleiche Verständnis der geschriebenen Worte haben. Zudem zeigen sich hier erste Justierungsmöglichkeiten, da man auch die Bedienungsebene im Fokus hat.
Auch diese Wireframes würde ich abzeichnen und ggf Anpassungen in den Jobstories gegenlesen und abzeichnen lassen.
Jetzt erst würde ich sowohl als Peogrammierer Agentur als auch als Kunde den verbindlichen Vertrag fur Softwareerstellung aushandeln und unterschreiben.
Bezahlen Sie der Agentur lieber den Stundensatz für diese Planungsphase als selbst mit grossem Zeitaufwand oder gar nebenbei ein gutes Pflichtenheft oder eines aus lauter Träumen und ungaren Ideen zusammenzuschustern.
Die Planungsphase wird auch bei höheren Stundensätzen der externen Programmierer in der Summe günstiger und das Risiko von Missinterpretationen, unvollständigem Wissen über Optionen der Softwareentwickler und ausufernden Entwicklerkosten wird minimiert.
Ein Ausschreibung ersetzt diesen Prozess übrigens nicht und spart nur Geld an der falschen Stelle. ...
Alternative zum Pflichtenheft.
App Programmierer finden
Software Planung und Vertrag erstellen.
Meine Erfahrung basiert auf diversen Projekten sowohl auf Deiten der Entwickler als auch als Kunde und Berater des Kunden.
Dieser Beitrag ist eher als Diskussionsgrundlage zu verstehen und geht beim Pflichtenheft von der Erfahrung aus, dass diese oft ambitioniert aber recht realitätsfremd erstellt werden und zu Streit führen, wenn man der Kunde Streit sucht (um die Rechnung zu drücken) und die Programmierer dazu verleiten, billigste Lösungen zu suchen, um den meist unrealistischen Kostenrahmen einhalten zu können. Daher hatte oben auch geschrieben, dass man als Kunde auch über Einsatzgebiet und Anforderungen an Lasten sprechen sollte. Auch über MVP und Entwicklungsstrategie sollte gesprochen werden und vertraglich eine Notiz hinterlegt werden. Etc pp ;)
Jobstories und Wireframes statt Pflichtenheft (eventuell eine zu steile These?)
