Nachdem ich im April 2011 mit dem Sammeln von Konsolen und Heimcomputern begann – mit dem Ziel ein Museum aufzubauen – erwarb ich im August 2014 eine Immobile der ehemaligen Ruhrkohle AG. Im April 2015, nachdem die Stadt Dortmund den Nutzungsänderungsantrag bestätigt hatte, begannen die Umbaumaßnehmen. In den letzten Monaten konnte ich viel über das Handwerk und Baumaßnahmen lernen. Da ich aus dem Bereich der agilen Softwareentwicklung komme gehe ich auch das Bauprojekt so an, doch die Parallelen sind nicht überall gegeben.
Bauen ist wie Softwareentwicklung
Wie bei der Softwareentwicklung gibt es beim Bauen Tätigkeiten, die parallel laufen können, andere wiederum finden strikt sequenziell statt. Herauszufinden was alles gemacht werden muss ist einfach. Dann alles hintereinander auszuführen ist auch einfach. Spannender ist es die Arbeiten so zu koordinieren, dass sie parallel stattfinden können. Das ist wie beim Multi-Threading: es läuft erst dann wirklich schnell, wenn sich die Threads nicht im Wege stehen und sich nicht koordinieren müssen.
In einem Team hat jeder eine feste Aufgabe und es ist essenziell ein gutes Team zu haben. Ich habe im Grunde mit meinen Team Glück. Leider gab es unvorhersehbare Ausfälle, von kranken Mitarbeitern bis zu defekten Maschinen, aber so ist das, und das muss einkalkuliert werden. Arbeiten auf Stundenlohn haben den Vorteil, dass man sich von Mitarbeiten schnell trennen kann; Arbeiten zum Festpreis haben IMO den Vorteil, dass es leichter ist, Nachbesserungen zu verlangen.
Die meisten Softwareentwickler wollen ihre Sache gut machen und werden oft vom Management daran gehindert, zu dokumentieren oder notwendige Refactorings durchzuführen, da von oben laufend neue Anforderungen kommen und der Termindruck hoch ist. Bei meinen Handwerkern habe ich nicht das Gefühl, dass sie ihre Aufgaben irgendwie schnell hinter sich bringen wollen, sondern ihre Aufgabe gut machen wollen, unabhängig davon ob sie für einen Stundenlohn arbeiten oder zum Festpreis. Sie wollen später auf ihr „Werk“ stolz sein und gute Arbeit abliefern. Keiner ist im Handwerk, weil er viel Geld verdienen will.
Leider musste ich wiederholt erleben, dass ein fähiger Handwerker einen unfähigen Helfer mitbrachte, der zum gleichen Stundenlohn arbeitete. Das führte immer wieder zu Diskussionen. Bei der Maut-Software wird auch nicht jede Zeile Code von einem Vollprofi programmiert sein … Und genauso wie einige Entwickler mit rauchen, telefonieren und chatten Zeit vertrödeln tuen dies Handwerker. Ein paar Tage war ein Ausbilder hier, der sicherlich in der Theorie seine Sache versteht, aber Arbeiten nicht gewohnt war und die GK-Platten krumm und schief klebte. Ein IBM-Consultant muss auch keine Granate beim Debugging des DB2-Treibers sein.
Software und Werkzeuge sind gut dokumentiert und so sind viele Informationen im Netz verfügbar. Auch wenn man nicht selbst den Trockenbau erledigt, oder den Estrich gießt, findet man unzählige Videos im Netz, die einen Eindruck von der Arbeit geben. Zuschauen und Fragen hilft die Zusammenhänge und Abläufe zu verstehen. Und eigentlich erklären die Handwerker auch gerne.
Externe Kräfte einzusetzen ist immer teuer als es selbst zu machen. Wer eine WordPress-Homepage selbst aufsetzen kann spart genauso Geld wie jemand, der einen Tag am Teppich-Stripper steht.
Die Dauer – und damit letztendlich die Kosten – mancher Aufgaben und Tätigkeiten ist schlecht abschätzbar. Einige Dinge gehen schnell, andere dauern ungewöhnlich lange. 2000 qm Decke nebeln ist in 2 Tagen gemacht, alle Heizkörper reinigen dauert ein Vielfaches.
Beim Bauen geht es wie bei den Softwareentwicklung darum, Standard-Komponenten zu nehmen und diese zu etwas Größerem zusammenzufügen. Einige Komponenten sind absolut gleichwertig, aber verschieden teuer, etwa GK-Platten oder Putz; dann merkt man, dass es in einem Bereich nur noch zwei Hersteller gibt, und man an diesen nicht vorbeikommt.
Materialkosten + Arbeitslohn = Gesamtkosten. Nicht selten musste ich entscheiden entweder günstige bzw. vorhandene Materialien zu nutzen, mit denen für das Endergebnis mehr Arbeitszeit anfällt, oder komplett neue Produkte einzusetzen, die schnell in der Verarbeitung sind. Das ist ein wenig so, als ob man ein sehr bekanntes, aber in die Jahre gekommenes Framework einsetzt und die Schwächen ausbügelt, oder das neue chice Framework nutzt, aber Einarbeitungszeit anfällt. Ich erinnere mich an einen Handwerker, der immer eine günstige Lösung für das Material im Blick hatte — was toll ist — aber so langsam gearbeitet hat, das der Einkauf von schnell zu verarbeitende Produkten bei ihm günstiger gewesen wäre.
Bei kommerzieller Software sind die Verkäufer geschult, die Vorteile ihrer Produkte zu preisen und ggf. Mitbewerber kleinzureden. Das ist bei Bauprodukten nicht anders; es ist schwierig, eine unabhängige Quelle zu finden, die einem klar macht, welche Vor-/Nachteile PVC gegenüber Epoxy-Beschichtung hat, ob man die Decke von innen oder außen dämmt, mit GK-Platten die Wand verkleidet oder Putz aufspritzt. Es gibt zwar massig Informationen zu speziellen Produkten im Netz, aber weniger „Meta-Informationen“.
Der Software-Architekt hat das Große im Blick, schwächelt aber im Detail. So ist es beim Bauen auch. Ein Architekt delegiert schnell an Fachplaner, ist eher für die „Vision“ da und schiebt die Realisierung auf andere ab. Ein Architekt muss kein guter Bauleiter sein.
Die agile Softwareentwicklung lebt vom Feedback des Kunden. Mein Vorteil ist, dass ich das Bauvorhaben permanent begleite und immer ansprechbar bin. Jeden Tag gibt es Mikroentscheidungen: Hier Kabeltrasse oder Plastik-Kabelkanal oder Aufputz mit Kabelschelle? Oberflächen-Rauputz hier oder doch glatt in den Durchgängen? Eisenarmierungen abflexen oder abkneifen? Internet-Kabel CAT 7 neu oder CAT 5 Bestand weiternutzen? Und so weiter, und so weiter.
Bei IT-Projekten gibt es im besten Fall die Entwickler als ausführende Einheit und Architekten bzw. Designer, die fundamentale Vorgaben machen. In der Praxis ist das verkürzt: stellt der Kunde die Anforderungen gehen diese häufig direkt zum Entwicklerteam, weil Entwickler und Designer mitunter identisch sind. Beim Bauen kann das so laufen, muss aber nicht. Wenn ich als Bauherr meine Wünsche bezüglich Sanitär und Trockenbau äußere, bekomme ich Vorschläge zur Umsetzung. Doch Elektriker wollen am liebsten ein Konzept auf Papier sehen, was sie einfach umsetzen können; hier wäre also ein „Designer“ gefragt.
Bauen ist nicht wie agile Softwareentwicklung
Die klassische Softwareentwicklung arbeitet in den Phasen Analyse, Design, Implementieren, Testen, Geld kassieren. Doch das Wasserfallmodell funktionierte nie! Schnell kam man daher zu agilen Methoden: Realisiere erst dann etwas in der Software, wenn es eine Anforderung wird. Kurz gesagt: Wann man einen Toaster braucht, dann schreibt man die Software nicht so generisch, dass aus dem Toaster ein Kühlschrank werden kann. Bauen ist weniger agil.
Drei Beispiele:
Hätte ich in die Zukunft schauen können, hätte ich bei dem Abriss Geld und Zeit gespart. Denn die Bodenfliesen hätten gleich bei der Entkernung runtergekonnt, die Wandfliesen zu entfernen war jedoch ein Fehler. Und die ganzen alten Brandmelder zu entfernen war auch ein Fehler, die Bestandsleitungen hätte man noch nutzen dürfen.
Viele Dinge müssen lange im Voraus geplant und bestellt werden. Ein Fahrstuhl dauert drei Monate, eine Fluchttreppe (wenn man Glück hat) einen Monat, T30 RS-Türen einen Monat und 2000 qm PVC-Boden ist vielleicht überhaupt nicht verfügbar, sondern erst wieder in Monaten, weil die Ware erst in China produziert werden muss. Fundamente müssen wochenlang durchtrocknen, ebenso Putz, bis er gestrichen werden kann. Hat man das nicht im Blick, verzögert sich das Projekt.
Resümee
Die Planung von IT-Projekten hat viel mit Bauprojekten gemeinsam. In beiden Fällen gilt: Je mehr man am Anfang weiß, desto weniger Stress hat man später. Das Design spielt eine große Rolle und bei der Ausführung/Implementierung ist es gut, wenn der Auftraggeber immer in der Nähe ist.