Wenn noch keine Erfahrungen bei gr\u00f6\u00dferen Softwareprojekten vorliegen, w\u00fcrde ich folgende dringende Empfehlungen geben:<\/p>\n\n\n\n
Softwareentwicklung ist teuer. Bei normalen Programmieraufgaben im embedded-Bereich muss man von 80 Euro an aufw\u00e4rts rechnen, bei speziellen Aufgaben wesentlich mehr. Mein Eindruck: wer noch keine Softwareprojekte vorher durchgef\u00fchrt hat, untersch\u00e4tzt die Kosten bei weitem. Preisdumping ist dennoch keine gute Idee und r\u00e4cht sich sp\u00e4ter bitter, unsaubere Architekturen, unsauberer schlecht wartbarer Code, fehlende Dokumentation etc. f\u00fchren schnell zu Folgekosten, welche in keinem Verh\u00e4ltnis zu einem gleich \u201esauberen Anfang\u201c 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\u00e4t, die man dann aus den Gewinnen der ersten Ausbaustufen erweitert \u2026 auf Basis von Komponenten, die dann wirklich verl\u00e4sslich 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 \u201eauf der gr\u00fcnen Wiese\u201c 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 \u201ef\u00fcr die Tonne\u201c, vieles muss neu geschrieben werden. Aber auch hier sollte man Fachleute suchen, die sich damit auskennen und wissen, worauf es ankommt.<\/p>\n\n\n\n
Gerade die Anf\u00e4nge eines neuen Softwareprojektes sind wichtig, auch in der Art, wie man ein Projekt f\u00fchrt, welche Werkzeuge wie eingesetzt werden etc. Je sp\u00e4ter hier grunds\u00e4tzliche Richtungswechsel erfolgen, um so aufwendiger werden deren Umsetzungen. Die Fr\u00fchphasen eines Projektes sind daher der beste Zeitpunkt, Kommunikation, Werkzeuge und Arbeitsweisen aufzubauen, zu testen und anzupassen. Ein Aufschieben r\u00e4cht sich bitter, \u201eProvisorien\u201c sind die l\u00e4ngsten \u201eUmsetzungen\u201c mit allen Folgen. Diese Bereitschaft muss man als Auftragsgeber aufbringen und dem Projekt gerade am Anfang die entsprechende gro\u00dfe Priorit\u00e4t einr\u00e4umen, an Zeit, Gedanken, Meetings etc. Und das gerade auf Ebene der Entscheidungstr\u00e4ger. Sp\u00e4ter dann kann man das Projekt im Idealfall gut \u201elaufen lassen\u201c und sich wieder anderen Aufgaben widmen. Am Anfang schleifen lassen belastet in der Regel auch die Projektparteien in den sp\u00e4teren Phasen, die Anfangss\u00fcnden ziehen sich durch das ganze Projekt und f\u00fchren zu immer st\u00e4rkeren Spannungen. Am Ende sind beide Parteien unzufrieden miteinander. Ich habe sogar Projekte erlebt, die dann nie zu Ende gef\u00fchrt wurden.<\/p>\n\n\n\n
Die Nutzeranalyse steht meist irgendwo in einem Projekt als Arbeitspunkt, real aber wird hier sehr h\u00e4ufig 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\u00e4ufer: 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\u00fcssen.
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 \u00fcberdecken, transparent zu bleiben. Auch bedeutet dies einen Mehraufwand vor allem am Anfang des Projektes f\u00fcr die sp\u00e4teren Nutzer, welche nun noch zus\u00e4tzlich zu ihrem Tagesgesch\u00e4ft hier immer wieder ihre Arbeitsweisen und W\u00fcnsche erl\u00e4utern und Vorschl\u00e4ge pr\u00fcfen m\u00fcssen. Manager k\u00f6nnen diese Aufgabe selten erf\u00fcllen, sie stecken nicht tief genug in den Problemen der t\u00e4glich mit den Systemen arbeitenden realen Nutzer. Ihre Aufgabe besteht vielmehr darin, in dieser Phase den sp\u00e4teren Nutzern \u201edie n\u00f6tige Luft\u201c zu verschaffen. Immer neues Verschieben wegen dem allt\u00e4glichem Arbeitsdruck r\u00e4cht sich sp\u00e4ter bitter, die Zeche zahlt der Auftragsgeber.<\/p>\n\n\n\n
Eigentlich k\u00f6nnte man diesen Punkt den anderen Punkten zuordnen, aber durch die besondere Rolle m\u00f6chte ich diesen Punkt unbedingt extra stehen lassen. Aus Erfahrung: ein Projekt steht und f\u00e4llt f\u00fcr den Auftraggeber mit dem Pflichtenheft. Dieses definiert im Detail, was am Ende der Auftragnehmer dem Auftraggeber \u00fcbergibt. Unsauberkeiten treffen hier im Regelfall den Auftraggeber, der Auftragnehmer kann sich zur\u00fccklehnen und unsaubere Beschreibungen zu seinen Gunsten auslegen. Wer als Auftragnehmer schnell verdienen und dann \u201everschwinden\u201c m\u00f6chte, f\u00fcr 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\u00f6chte, wird durch ein unsauberes Pflichtenheft in eine unm\u00f6gliche Situation gebracht. Er kann beim besten Willen nicht liefern, was sich der Auftraggeber w\u00fcnscht, die Spannungen und Unzufriedenheiten beim besten Bem\u00fchen beider Projektparteien sind vorprogrammiert. Am Ende verlieren alle.
Ein gutes Pflichtenheft macht Arbeit. Ein seri\u00f6ser Auftragnehmer kann einem Auftraggeber ohne entsprechende Projekterfahrung bei der Erstellung seines ersten Pflichtenheftes unterst\u00fctzen. Das Wissen, wie man ein Pflichtenheft erstellt, ist \u201eGold wert\u201c.<\/p>\n\n\n\n
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\u00f6rt speziell z.B. Dokumentation, Projektmanagement, Sourcecode etc. Nicht selten \u00fcben z.B. Entwickler Druck auf ihre Kunden aus, indem sie Code zur\u00fcckhalten etc. Ich rate daher dringend zum Aufbau einer entsprechenden Infrastruktur in house, z.B. der Repositorien und dem Zwang externen Entwickler, hier regelm\u00e4\u00dfig ihre Code\u00e4nderungen einzupflegen, wie auch das Projektmanagement und Dokumentation immer aktuell zu halten. Ohne Kontrolle und F\u00fchrung kommt es dabei schnell zum Wildwuchs. Und dann hilft auch keine verstreute Dokumentation mehr, wenn niemand wei\u00df, wo was zu finden ist. Daher muss auch vom Auftraggeber in die eigenen Mitarbeiter investiert werden. Diese m\u00fcssen zumindest soweit mit den Werkzeugen und Prozessen vertraut sein, dass sie externe Kr\u00e4fte real(!) \u00fcberwachen und korrigieren k\u00f6nnen. Qualit\u00e4tsstandards lassen sich am besten fr\u00fchzeitig etablieren und festigen, je sp\u00e4ter man hier versucht zu korrigieren, um so mehr Kraftanstrengungen und Konfrontationen bedarf es, irgendwann ist es nicht mehr durchsetzbar, auch juristisch oder monet\u00e4r nicht. Hier gilt wieder \u201eWehret den Anf\u00e4ngen\u201c. Auch dieser Punkt zeigt wieder, das Gelingen eines Projektes wird prim\u00e4r in den Fr\u00fchphasen bestimmt.<\/p>\n\n\n\n
Ein Projekt wird massiv durch seine Leitung gepr\u00e4gt. 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\u00fchlen, wenn Fachpersonal sich in ihren Gebieten fachlich besser auskennen. W\u00fcrden sie das nicht, w\u00e4ren sie kein echtes Fachpersonal. Auf der anderen Seite m\u00fcssen Qualit\u00e4tsstandards und Nutzerw\u00fcnsche 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\u00e4re geschaffen werden. Menschen machen Fehler, das ist die Natur des Menschen. In einer guten Umgebung k\u00f6nnen 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 \u201eDienst nach Vorschrift\u201c? Diese Einstellung wird sich im Ergebnis des Projektes niederschlagen. Aus eigener Erfahrung: ein Projektleiter aus eigentlich z.B. dem Vertrieb mit einer Sicht f\u00fcr den Kunden und einem hervorragenden Charakter kann ein viel besserer Projektleiter sein als ein \u201eeigentlicher Entwicklungsleiter\u201c, der diese Qualit\u00e4ten nicht mitbringt.<\/p>\n\n\n\n
So klar dieser Punkt sein sollte, die Realit\u00e4t hat mich gelehrt, man muss es sagen. Ich m\u00f6chte in Urlaub fahren? Dann muss ich mir zuerst Gedanken machen, wo m\u00f6chte ich diesen verbringen. Dann ergeben sich die Etappen, was muss ich mitnehmen, wann starten, auf welchem Weg m\u00f6chte ich dort hin, kann ich mir den Urlaub so leisten? Projekte sind sehr verschieden, auch in ihrer Komplexit\u00e4t und Abh\u00e4ngigkeit von anderen Projekten. Je komplexer und \/ oder von anderen Projekten abh\u00e4ngiger ein Projekt ist, um so mehr muss man aus der \u201eVogelperspektive\u201c starten, wo m\u00f6chte man z.B. in 10, 5 1nem Jahr stehen. Das aktuelle Projekt ist dann wie die erste Stufe einer Treppe, auf welche die n\u00e4chste Stufe gesetzt wird. Aber dazu muss ich ein Bild haben, wie sp\u00e4ter diese Treppe aussehen soll, BEVOR ich diese erste Stufe baue. Weiter ben\u00f6tigen gerade komplexe Projekte Zeit. Bei diesen kann man gar nicht alle Dinge \u201eauf dem Rei\u00dfbrett\u201c bedenken. Ein einzelnes fehlendes Synchronisationssignal kann ganze Features sp\u00e4ter crashen, Datenbl\u00e4tter von Sensoren etc. geben in der Regel \u201enur einen Ausschnitt der Wirklichkeit\u201c wieder, sch\u00f6n gef\u00e4rbt 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 \u201eProof of Concept\u201c herum, erst wenn der Prototyp von vorn bis hinten funktioniert, kann man an die \u00dcberarbeitung zum sp\u00e4teren Endprodukt gehen. Und ein Projekt kann zwischenzeitlich in der Schublade landen, z.B. da eine Komponente noch nicht auf dem Markt verf\u00fcgbar oder noch zu teuer ist. Wenn diese dann z.B. 2 Jahre sp\u00e4ter zur Verf\u00fcgung steht, ist man sogar im Vorteil, hat gute Chancen, der Erste auf dem Markt zu sein.<\/p>\n\n\n\n
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\u00e4t, 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 \u00fcber gro\u00dfe Distanzen schnell identifizieren und fixen zu k\u00f6nnen. Ja, in der bitteren Realit\u00e4t werden tats\u00e4chlich Ger\u00e4te \u00fcber Kontinente nur f\u00fcr einen Flash verschickt und auseinandergenommen, da man dies nicht im Blick hatte oder auf sp\u00e4ter verschob, oder Ger\u00e4te sind neu produziert schon wegen unkorrigierbarer buggs (kein Flash m\u00f6glich) Elektroschrott. Das alles ist keine Raketenwissenschaft, alles eigentlich bekannte Dinge, und es gibt f\u00fcr alles die richtigen Werkzeuge. Man muss sie nur im Blick behalten und umsetzen. So kann ein USB-Port immens wichtig sein, um sp\u00e4ter noch flashen zu k\u00f6nnen, so muss vielleicht die Wahl eines MCs oder SoCs anders aussehen, da dieser Dinge wie OTA unterst\u00fctzt, der andere nicht. Daher geh\u00f6ren diese Punkte wieder in die Fr\u00fchphasen der Projektplanung. Wenn das Werkzeug f\u00fcr den Spritzguss schon fertig ist und man an die \u00d6ffnung f\u00fcr die dahinter liegende Flashbuchse nicht gedacht hat oder man schon flei\u00dfig die Entwicklung f\u00fcr einen SoC vorangetrieben hat und dann erst merkt, der kann kein OTA oder der Flashspeicher ist zu klein f\u00fcr mehrere \u201eschaltbare\u201c Partitionen, dann \u201ewird es sehr schwierig\u201c. Gerade diese Punkte geh\u00f6ren 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\u00f6nnen, kann ich sogar andere Entwicklungen, die noch Zeit brauchen, auf einen Zeitpunkt nach dem roll out verschieben. Anders herum wird das aber nichts.<\/p>\n\n","protected":false},"excerpt":{"rendered":"
Wenn noch keine Erfahrungen bei gr\u00f6\u00dferen Softwareprojekten vorliegen, w\u00fcrde ich folgende dringende Empfehlungen geben: Sich der Kosten bewusst sein Softwareentwicklung ist teuer. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[8],"class_list":["post-91","post","type-post","status-publish","format-standard","hentry","category-tipps-fuer-den-start","tag-projektmanagement"],"_links":{"self":[{"href":"https:\/\/thurow.de\/index.php?rest_route=\/wp\/v2\/posts\/91","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thurow.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thurow.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thurow.de\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/thurow.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=91"}],"version-history":[{"count":3,"href":"https:\/\/thurow.de\/index.php?rest_route=\/wp\/v2\/posts\/91\/revisions"}],"predecessor-version":[{"id":245,"href":"https:\/\/thurow.de\/index.php?rest_route=\/wp\/v2\/posts\/91\/revisions\/245"}],"wp:attachment":[{"href":"https:\/\/thurow.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=91"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thurow.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=91"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thurow.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=91"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}