Wie man einen Softwareentwickler beauftragt

(English: How to Contract a Software Developer)

Wir sind ein kleines Unternehmen, das kundenspezifische Software entwickelt, die in der Regel geschäftskritische Funktionen implementiert: Back-Ends mit vielen asynchronen transaktionalen Geschäftsabläufen, Massendatenverarbeitung, Integration mit anderen Back-Ends, Maschinendaten und auch Benutzeroberflächen in der Produktion.

Wir entwerfen und implementieren diese Software nicht von Grund auf. Wir verfügen über Werkzeuge, eine solide Softwarebasis und Erfahrung, um Geschäftsprozesse zu analysieren, sie in Software abzubilden und schließlich zu implementieren. Das bringen wir mit.

Im Allgemeinen führen wir keine Projekte zu Festpreisen durch. Das tun wir nicht, weil es im Allgemeinen einfach keinen Sinn macht – nicht für uns, nicht für unsere Kunden.

In diesem Beitrag geht es darum, warum es in den meisten Fällen falsch ist, nach einem Festpreisprojekt zu fragen – für uns als Entwickler und für Sie als Kunde. Es geht darum, warum Sie einen Entwickler nicht für ein Festpreisprojekt beauftragen sollten, und was Sie stattdessen tun sollten – um das Leben für Sie als Kunde und uns als Entwickler besser zu machen.

Grundsätzliches

Normalerweise liest man, dass der allererste Schritt eines jeden Softwareprojekts darin besteht, ein Verständnis für das eigentliche Geschäftsproblem, seine wesentlichen Datenbeziehungen und die Benutzeranforderungen an ein Softwaresystem zu entwickeln.

Zwar gibt es eine anfängliche Problembeschreibung, aber diese beschreibt das zu lösende Problem nicht unbedingt in Begriffen, die sich leicht auf einen technischen Lösungsansatz übertragen lassen. Sie müssen also eine technischere und grundlegendere Formulierung des zu lösenden Geschäftsproblems erstellen, um eine Grundlage zu schaffen, auf der das Projekt geplant und umgesetzt werden kann.

Aber das ist nicht die ganze Geschichte. Wenn Sie an diesem Punkt angelangt sind, befinden Sie sich bereits im Projekt. Ein unverzichtbarer erster Schritt ist der Aufbau einer gemeinsamen Vertrauensbasis zwischen Kunde und Entwickler.

Warum sollte ein Kunde einem Entwickler ein Softwareprojekt anvertrauen, das sich möglicherweise zu einem millionenschweren Unterfangen entwickelt, das auf einem Austausch von Designideen und einer vagen Planung beruht?

Warum sollte ein Softwareentwickler einen teuren Rechtsstreit riskieren, weil er nicht verstanden hat, was eine Lösung er für ein millionenschweres Softwareprojekt auf der Grundlage eines Entwurfs liefern soll, der sich als Wunschdenken herausgestellt hat?

Den Zeitlauf verstehen und den Erfolg absichern

Ich glaube, dass es in jedem Projekt drei wesentliche (bewegliche) Meta-Meilensteine gibt:

Nächstes: Alle Funktionen und Korrekturen, von denen Sie wissen, dass sie benötigt werden, und von denen der Entwickler weiß (oder zu wissen glaubt), wie man sie richtig umsetzt. Alles im Nächsten kann jetzt gemacht werden.

Bald: All die Funktionen, die Ihrer Meinung nach in Zukunft realisiert werden könnten, möglicherweise in Verbindung mit dem Nächsten, die Sie für sehr nützlich halten, von denen Sie aber nicht sicher sind, ob Sie wirklich bereit sind, dafür zu bezahlen, und bei denen sich Ihr Entwickler nicht sicher ist, wie lange es dauern wird, und wie gut sie funktionieren werden.

Ferne: Die Vision von dem, was man tun könnte, wenn man das Nächste und etwas vom Baldigen hätte, und vielleicht eine coole Idee und den richtigen Geschäftsrahmen. Man weiss nicht, wie man das jetzt planen soll, aber wenn man den Gedanken mit anderen teilt, erhält man eine Orientierung, wohin wir letztendlich gehen wollen.

Diese Meta-Meilensteine als bewegliches Ziel bilden die Grundlage für die wiederholte Planung und Umsetzung. Indem wir uns auf sie einigen, schaffen wir ein gemeinsames Verständnis darüber, wie wir glauben, dass das Projekt vorankommen soll – und verpflichten uns gleichzeitig, den nächsten “realistischen” Teil davon zu erreichen:

Das Bald definiert das Nächste, indem es Ihnen die Grenze dessen aufzeigt, wovon Sie sich sicher fühlen. Das Ferne wiederum leitet die Schaffung des Nahen und die Vision, die zu kommunizieren ist, wenn man die Bemühungen als Ganzes rechtfertigt.

Während der Arbeit am Nächsten werden das Baldige und das Ferne klarer – im Idealfall fließt das Baldige in das Nächste. und es gibt ständig Nahrung für die Arbeit und den Erfolg im Projekt.

Die Sache ist jedoch folgende:

• Während man sich auf das Baldige einigt und das Ferne kommuniziert, schließt man nur einen Vertrag über das Nächste ab.
• Während Sie am Nächsten arbeiten, füllen Sie es wieder mit dem Baldigen auf.
• Sie stellen sicher, dass eine Trennung der Vertragsparteien zwar nicht wünschenswert ist, aber nicht mehr verbrannte Erde hinterlässt als das aktuelle Nächste.

In der Praxis

Als potenzielle Projektpartner sollten sich Entwickler und Kunde auf eine erste Reihe von Nah- und Fernprojekten einigen. Ich neige dazu, sie als Phase 1 und Phase 2 zu bezeichnen, da dies wahrscheinlich eher erwartet wird. Das erste, was zu tun ist, ist ein erstes High-Level-Design oder sogar so etwas wie eine Spezifikation zu erstellen, die das Nächste genau definiert.

Das sollte die erste Verpflichtung sein.

Das Ergebnis der Spezifizierung wird ein verfeinertes Nächstes, Baldiges und möglicherweise auch ein aktualisiertes Fernes sein. Die Zielpfosten werden sich verschoben haben, und Sie können zur nächsten Iteration übergehen: Die tatsächliche Implementierung des Nächsten.

Im Sinne der agilen Entwicklung: Eine Iteration ist hier im Allgemeinen kein Sprint, sondern eher mehrere Sprints, je nach Größe des Projekts und des Planungshorizonts. Dennoch würden Sie die Budgetierung und die mittelfristige Planung auf die Sprintgrenzen abstimmen, um die Arbeit nicht unnötig zu unterbrechen.

Sie stellen jederzeit sicher, dass die Arbeiten spezifiziert und die Dokumentation so weit aktualisiert wurde, dass die Arbeiten bei Bedarf weitergegeben werden können.

Als Entwickler wissen Sie, dass alles vorbereitet ist und Sie keine (unerwarteten) technischen oder dokumentarischen Unzulänglichkeiten haben, die Sie später heimsuchen werden.

Als Kunde wissen Sie, dass es keine unnötigen Abhängigkeiten gibt, die dazu führen könnten, dass Sie die Kontrolle über Ihre Investition verlieren.

Dies bedeutet insbesondere:

• Verträge stellen sicher, dass alles, was entwickelt wird, dem Kunden gehört.
• Falls erforderlich, kann der Kunde die Entwicklung mit einem anderen Team fortsetzen, neue Entwickler einstellen oder die Entwicklung intern verlagern, falls dies gewünscht wird.

Letzteres bedeutet, dass die Tools für die Projektorganisation und die Inhalte sowie die Entwicklungs- und Testinfrastruktur entweder bereits vom Kunden betrieben werden, mit dem Projekt geliefert werden oder vom Kunden leicht neu erstellt werden können.

Am besten ist es natürlich, wenn die Entwicklung und das Testen in den Projektquellen enthalten und weitgehend unabhängig von anderen externen oder urheberrechtlich geschätzten Tools sind.

Um das Vertrauen in das Projekt und in Sie als Entwickler aufrechtzuerhalten, sollten Sie darauf achten, einen gut gefüllten Backlog für das Baldige zu verwalten, damit die Kontinuität des Projekts gewahrt bleibt.