Tipps beim ersten größeren Softwareprojekt

Wenn noch keine Erfahrungen bei größeren Softwareprojekten vorliegen, würde ich folgende dringende Empfehlungen geben:

Sich der Kosten bewusst sein

Softwareentwicklung ist teuer. Bei normalen Programmieraufgaben im embedded-Bereich muss man von 80 Euro an aufwärts rechnen, bei speziellen Aufgaben wesentlich mehr. Mein Eindruck: wer noch keine Softwareprojekte vorher durchgeführt hat, unterschätzt die Kosten bei weitem. Preisdumping ist dennoch keine gute Idee und rächt sich später bitter, unsaubere Architekturen, unsauberer schlecht wartbarer Code, fehlende Dokumentation etc. führen schnell zu Folgekosten, welche in keinem Verhältnis zu einem gleich „sauberen Anfang“ stehen, wie ein Haus, welches gleich als Ruine errichtet wurde und abgerissen werden muss. Wer billigt kauft, kauft zweimal.
Muss gespart werden, dann besser zuerst an der Funktionalität, die man dann aus den Gewinnen der ersten Ausbaustufen erweitert … auf Basis von Komponenten, die dann wirklich verlässlich und wiederverwertbar sind.
ABER: nichts ohne Ausnahme. Es gibt auch Projekte, die erst einmal nur Machbarkeiten aufzeigen sollen, Proof of Concept (PoC). Hier stehen andere Erkenntnisse im Mittelpunkt, auf deren Grundlage man dann wieder „auf der grünen Wiese“ noch einmal neu anfangen kann. In diesem Fall ist quick hack gar nicht schlecht, man muss sich dessen aber dann auch bewusst sein: das meiste an Code ist danach „für die Tonne“, vieles muss neu geschrieben werden. Aber auch hier sollte man Fachleute suchen, die sich damit auskennen und wissen, worauf es ankommt.

Von Anfang an richtig

Gerade die Anfänge eines neuen Softwareprojektes sind wichtig, auch in der Art, wie man ein Projekt führt, welche Werkzeuge wie eingesetzt werden etc. Je später hier grundsätzliche Richtungswechsel erfolgen, um so aufwendiger werden deren Umsetzungen. Die Frühphasen eines Projektes sind daher der beste Zeitpunkt, Kommunikation, Werkzeuge und Arbeitsweisen aufzubauen, zu testen und anzupassen. Ein Aufschieben rächt sich bitter, „Provisorien“ sind die längsten „Umsetzungen“ mit allen Folgen. Diese Bereitschaft muss man als Auftragsgeber aufbringen und dem Projekt gerade am Anfang die entsprechende große Priorität einräumen, an Zeit, Gedanken, Meetings etc. Und das gerade auf Ebene der Entscheidungsträger. Später dann kann man das Projekt im Idealfall gut „laufen lassen“ und sich wieder anderen Aufgaben widmen. Am Anfang schleifen lassen belastet in der Regel auch die Projektparteien in den späteren Phasen, die Anfangssünden ziehen sich durch das ganze Projekt und führen zu immer stärkeren Spannungen. Am Ende sind beide Parteien unzufrieden miteinander. Ich habe sogar Projekte erlebt, die dann nie zu Ende geführt wurden.

Nutzeranalyse, Nutzeranalyse, Nutzeranalyse

Die Nutzeranalyse steht meist irgendwo in einem Projekt als Arbeitspunkt, real aber wird hier sehr häufig geschlammt oder der Punkt steht gar nur pro forma in der Abrechnung. Die Folge: die IT dient nicht mehr dem Nutzer, sondern der Nutzer wird von der IT versklavt. Auftragsnehmer gewinnen damit sogar doppelt, in der Rolle als Fachverkäufer: man verkauft einfach, was grad im Fach ist, sprich, was man schon hat, statt neu und auf den Kunden zugeschnitten zu entwickeln. Meist explodiert das Ganze erst ganz am Schluss des Projektes kurz vor oder nach dem roll out, wenn die Nutzer zum ersten Mal wirklich mit den Systemen arbeiten müssen.
Die Nutzeranalyse ist ein iterativer Prozess, der viel Geduld von beiden Seiten bedarf, auch darin, erst einmal eine gemeinsame Sprache zu finden, die Denkweise der anderen Seite zu verstehen. Hier kommt es auch auf Ehrlichkeit beider Seiten an, z.B. wenn man etwas nicht versteht, dies nicht zu überdecken, transparent zu bleiben. Auch bedeutet dies einen Mehraufwand vor allem am Anfang des Projektes für die späteren Nutzer, welche nun noch zusätzlich zu ihrem Tagesgeschäft hier immer wieder ihre Arbeitsweisen und Wünsche erläutern und Vorschläge prüfen müssen. Manager können diese Aufgabe selten erfüllen, sie stecken nicht tief genug in den Problemen der täglich mit den Systemen arbeitenden realen Nutzer. Ihre Aufgabe besteht vielmehr darin, in dieser Phase den späteren Nutzern „die nötige Luft“ zu verschaffen. Immer neues Verschieben wegen dem alltäglichem Arbeitsdruck rächt sich später bitter, die Zeche zahlt der Auftragsgeber.

Pflichtenheft

Eigentlich könnte man diesen Punkt den anderen Punkten zuordnen, aber durch die besondere Rolle möchte ich diesen Punkt unbedingt extra stehen lassen. Aus Erfahrung: ein Projekt steht und fällt für den Auftraggeber mit dem Pflichtenheft. Dieses definiert im Detail, was am Ende der Auftragnehmer dem Auftraggeber übergibt. Unsauberkeiten treffen hier im Regelfall den Auftraggeber, der Auftragnehmer kann sich zurücklehnen und unsaubere Beschreibungen zu seinen Gunsten auslegen. Wer als Auftragnehmer schnell verdienen und dann „verschwinden“ möchte, für den ist ein fehlendes oder schlechtes Pflichtenheft das beste Geschenk.
WARNUNG: Wer als Auftraggeber einen Auftrag ohne fertiges und gutes Pflichtenheft vergibt, hat im Moment der Vergabe bereits verloren. Dann kann auch kein Anwalt mehr retten. Das Pflichtenheft ist sozusagen wesentlicher Bestandteil des Vertrages.
Aber auch wer als Auftragnehmer langfristig mit dem Auftraggeber arbeiten möchte, wird durch ein unsauberes Pflichtenheft in eine unmögliche Situation gebracht. Er kann beim besten Willen nicht liefern, was sich der Auftraggeber wünscht, die Spannungen und Unzufriedenheiten beim besten Bemühen beider Projektparteien sind vorprogrammiert. Am Ende verlieren alle.
Ein gutes Pflichtenheft macht Arbeit. Ein seriöser Auftragnehmer kann einem Auftraggeber ohne entsprechende Projekterfahrung bei der Erstellung seines ersten Pflichtenheftes unterstützen. Das Wissen, wie man ein Pflichtenheft erstellt, ist „Gold wert“.

In House

Es gibt Dinge, die kann man outsourcen, es gibt Dinge, die sollten immer sicher und direkt zugreifbar im Haus bleiben, wie das eigene geistige Eigentum. Und dazu gehört speziell z.B. Dokumentation, Projektmanagement, Sourcecode etc. Nicht selten üben z.B. Entwickler Druck auf ihre Kunden aus, indem sie Code zurückhalten etc. Ich rate daher dringend zum Aufbau einer entsprechenden Infrastruktur in house, z.B. der Repositorien und dem Zwang externen Entwickler, hier regelmäßig ihre Codeänderungen einzupflegen, wie auch das Projektmanagement und Dokumentation immer aktuell zu halten. Ohne Kontrolle und Führung kommt es dabei schnell zum Wildwuchs. Und dann hilft auch keine verstreute Dokumentation mehr, wenn niemand weiß, wo was zu finden ist. Daher muss auch vom Auftraggeber in die eigenen Mitarbeiter investiert werden. Diese müssen zumindest soweit mit den Werkzeugen und Prozessen vertraut sein, dass sie externe Kräfte real(!) überwachen und korrigieren können. Qualitätsstandards lassen sich am besten frühzeitig etablieren und festigen, je später man hier versucht zu korrigieren, um so mehr Kraftanstrengungen und Konfrontationen bedarf es, irgendwann ist es nicht mehr durchsetzbar, auch juristisch oder monetär nicht. Hier gilt wieder „Wehret den Anfängen“. Auch dieser Punkt zeigt wieder, das Gelingen eines Projektes wird primär in den Frühphasen bestimmt.

Projektleitung

Ein Projekt wird massiv durch seine Leitung geprägt. Hier kommt es auch sehr auf die eingesetzte Person an. Diese muss nicht unbedingt selbst ein Softwareentwickler sein. Wichtiger sind Charaktermerkmale und die Stellung zum Projekt. Die Person sollte in sich gefestigt sein, sie darf sich nicht als Person verunsichert fühlen, wenn Fachpersonal sich in ihren Gebieten fachlich besser auskennen. Würden sie das nicht, wären sie kein echtes Fachpersonal. Auf der anderen Seite müssen Qualitätsstandards und Nutzerwünsche durchgesetzt werden, es darf hier keine Scheu vor auch harten Konfrontationen bestehen. Falscher Friede hilft hier nicht weiter. Das betrifft aber eher die Managerebene zwischen Auftraggeber und Auftragnehmern. Ehrlichkeit ist immens wichtig in einem Projekt. Dazu muss eine entsprechende Atmosphäre geschaffen werden. Menschen machen Fehler, das ist die Natur des Menschen. In einer guten Umgebung können Entwickler ihre Fehler aufzeigen wie auch ihre fachlichen Grenzen(!), dann kann man reagieren und die Probleme beseitigen. Immens wichtig ist die Identifikation des Projektleiters mit dem Projekt. Steht er als Person wirklich dahinter oder macht er „Dienst nach Vorschrift“? Diese Einstellung wird sich im Ergebnis des Projektes niederschlagen. Aus eigener Erfahrung: ein Projektleiter aus eigentlich z.B. dem Vertrieb mit einer Sicht für den Kunden und einem hervorragenden Charakter kann ein viel besserer Projektleiter sein als ein „eigentlicher Entwicklungsleiter“, der diese Qualitäten nicht mitbringt.

Eine Vision erstellen und rechtzeitig beginnen

So klar dieser Punkt sein sollte, die Realität hat mich gelehrt, man muss es sagen. Ich möchte in Urlaub fahren? Dann muss ich mir zuerst Gedanken machen, wo möchte ich diesen verbringen. Dann ergeben sich die Etappen, was muss ich mitnehmen, wann starten, auf welchem Weg möchte ich dort hin, kann ich mir den Urlaub so leisten? Projekte sind sehr verschieden, auch in ihrer Komplexität und Abhängigkeit von anderen Projekten. Je komplexer und / oder von anderen Projekten abhängiger ein Projekt ist, um so mehr muss man aus der „Vogelperspektive“ starten, wo möchte man z.B. in 10, 5 1nem Jahr stehen. Das aktuelle Projekt ist dann wie die erste Stufe einer Treppe, auf welche die nächste Stufe gesetzt wird. Aber dazu muss ich ein Bild haben, wie später diese Treppe aussehen soll, BEVOR ich diese erste Stufe baue. Weiter benötigen gerade komplexe Projekte Zeit. Bei diesen kann man gar nicht alle Dinge „auf dem Reißbrett“ bedenken. Ein einzelnes fehlendes Synchronisationssignal kann ganze Features später crashen, Datenblätter von Sensoren etc. geben in der Regel „nur einen Ausschnitt der Wirklichkeit“ wieder, schön gefärbt vom Hersteller, man findet Fehler in Hard- und Software der Zulieferer, es ist oft ein langer und harter Prozess, diese zum fixen zu bewegen, viele Probleme werden auch von den besten Entwicklern erst in der Entwicklung identifiziert. Gerade bei komplexen Projekten kommt man daher nicht um die Phase „Proof of Concept“ herum, erst wenn der Prototyp von vorn bis hinten funktioniert, kann man an die Überarbeitung zum späteren Endprodukt gehen. Und ein Projekt kann zwischenzeitlich in der Schublade landen, z.B. da eine Komponente noch nicht auf dem Markt verfügbar oder noch zu teuer ist. Wenn diese dann z.B. 2 Jahre später zur Verfügung steht, ist man sogar im Vorteil, hat gute Chancen, der Erste auf dem Markt zu sein.

Das neue System wird nicht fehlerfrei sein!

Selbst die NASA bekommt es nicht hin. Egal wie viel Zeit und Geld man in ein neues Projekt investiert, immer wieder wird es zu Fehlern kommen. Und viele dieser Fehler zeigen sich erst in der Realität, nach dem roll out bei den eigentlichen Nutzern, vorrangig in der ersten Nutzungsphase. Wohl dem, der hier entsprechende Werkzeuge voraussichtlich eingebaut hat, wie gute loggings, remote Firmwareupdates etc., um diese dann beim Kunden auch über große Distanzen schnell identifizieren und fixen zu können. Ja, in der bitteren Realität werden tatsächlich Geräte über Kontinente nur für einen Flash verschickt und auseinandergenommen, da man dies nicht im Blick hatte oder auf später verschob, oder Geräte sind neu produziert schon wegen unkorrigierbarer buggs (kein Flash möglich) Elektroschrott. Das alles ist keine Raketenwissenschaft, alles eigentlich bekannte Dinge, und es gibt für alles die richtigen Werkzeuge. Man muss sie nur im Blick behalten und umsetzen. So kann ein USB-Port immens wichtig sein, um später noch flashen zu können, so muss vielleicht die Wahl eines MCs oder SoCs anders aussehen, da dieser Dinge wie OTA unterstützt, der andere nicht. Daher gehören diese Punkte wieder in die Frühphasen der Projektplanung. Wenn das Werkzeug für den Spritzguss schon fertig ist und man an die Öffnung für die dahinter liegende Flashbuchse nicht gedacht hat oder man schon fleißig die Entwicklung für einen SoC vorangetrieben hat und dann erst merkt, der kann kein OTA oder der Flashspeicher ist zu klein für mehrere „schaltbare“ Partitionen, dann „wird es sehr schwierig“. Gerade diese Punkte gehören in einem Projekt sogar an den Anfang. Wenn ich eine gute und getestete Methode habe, meine Firmware auch beim Kunden noch testen und bereinigen zu können, kann ich sogar andere Entwicklungen, die noch Zeit brauchen, auf einen Zeitpunkt nach dem roll out verschieben. Anders herum wird das aber nichts.