In meinen Softwareprojekten gibt es immer mindestens eine Person, die einen Blick auf die technische Gesamtlösung hat. Dieser technische Chefdesigner ist dafür verantwortlich, das die Software am Ende ein in sich stimmiges Gesamtbild ergibt. Keine leichte Aufgabe, die zudem nicht immer explizit so als Rolle benannt und besetzt wird, sondern irgendwie nebenbei erledigt werden soll. Ich halte aber genau das für einen entscheidenden Erfolgsfaktor in Softwareprojekten.
Da ich in der Regel weder technisch noch fachlich tief genug in der Materie des Projekts stecke, und als Projektleiter auch nicht stecken sollte, brauche ich mindestens einen Menschen in meinem Team, der einen Blick auf die technische Gesamtlösung hat. Ich nenne diese Rolle dann gerne technischer Chefdesigner oder Chefarchitekt. In anderen Branchen heißt diese Rolle vielleicht anders, aber ich bin mir sicher, dass es sie dort auch in ähnlicher Weise gibt.
Der technische Chefdesigner ist verantwortlich für die Architektur der Software im Sinne des modularen Aufbaus, die beim Kunden einsetzbaren und schließlich eingesetzten Komponenten und letztlich für die technische Qualität. Wobei verantwortlich nicht heißen soll, dass er diese Dinge ganz im Stile der tayloristischen Kreativitätsapartheid vorgibt, das kann und sollte besser im Team gemeinsam entschieden werden. Verantwortlich heißt aber, dass er den anderen Mitgliedern des Teams hilft, die Architektur und Vorgaben korrekt umzusetzen. Damit hat der technische Chefdesigner, der in der Regel auch ein wenig erfahrener ist als die anderen Teammitglieder, auch ein wenig die Rolle des Vorarbeiters oder Handwerksmeisters.
In größeren und komplizierteren Projekten wird diese Rolle des technischen Chefdesigners meist auch explizit besetzt. In kleineren hingegen ist es oft der Projektleiter, der diese Rolle übernimmt. Oder besser gesagt: Der eigentliche Chefarchitekt wird nebenbei zum Projektleiter gemacht. Vor diesem Rollenkonflikt zwischen Führungsaufgabe einerseits und inhaltlicher Arbeit als Top-Experte andererseits kann nicht oft genug gewarnt werden. Weniger in dem Sinne, dass diese Doppelrolle nicht machbar wäre, sondern vielmehr, dass ein bewusstes Reflektieren notwendig ist, um beiden Rollen gerecht zu werden. Bewährt hat sich in diesem Zusammenhang die Begleitung durch einen erfahrenen Mentor als Projektcoach.
Artikelbild: Saad Akhtar bei flickr.com (CC BY 2.0)
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
11 Kommentare
Hmmm…,
nicht nur aus einer „agilen“ Brille betrachtet, erlebe ich die (explizite) Rolle des „Chefdesigners“ als kritisch.
Kritisch als übliche „una persona“ Auskleidung – häufig zusätzlich mit weiteren Verantwortungsbereichen – mit all den Herausforderungen, die sich dadurch ergeben.
Wissens-Monopol, Truck / Bus factor, geringe Identifikation mit Architektur-Entscheidungen (im Elfenbeinturm), dadurch fehlende Übernahme von „verantwortlich sein“ bei den Teammitgliedern, schlechte Umsetzungsqualität (selbst „junge“ Software besteht aus architekturalem Spaghetti-Code, dadurch schlechte Wartbarkeit, hohe Bug Rate, schnell steigende technische Schulden), usw.
Dies scheint sich wie ein Naturgesetz durch die Projekte zu ziehen.
Eine (Teil-) Lösung, d.h. eine signifikante Verbesserung erlebe ich in Kontexten, in denen auch die Architektur-Verantwortung bei Cross-functional Teams /1/ liegt (nicht nur auf dem Papier). Bei Teams, die z.B. im Sinne eines Community of Practices-Konzeptes (CoP) u.a. auch Architektur-Wissen aufbauen und gelebt umsetzen können. Und weil es aus den Teams heraus – von den eigenen Teammitgliedern – unter Berücksichtigung nicht nur theoretischer, sondern ganz praktischer Anforderungen entsteht, ist die Identifikation und damit die Umsetzungsqualität deutlich vorteilhafter.
Meine Erfahrungen und meine 2 cents…
CU
Boeffi
/1/ http://boeffi.net/scrum/agile-smells/agile-smells-im-team/cross-functional-team-semantik-falsch-interpretiert/
Danke Boeffi für Deinen Kommentar! Ich sehe das ganz ähnlich wie Du. Wir sind uns schon Mal einig, dass jemand den Blick für die Gesamtlösung haben sollte. Ich habe versucht im Artikel auch anklingen zu lassen, dass das nicht unbedingt eine Person sein muss. Idealerweise ist es wirklich so wie Du schreibst, dass die Verantwortung dafür bei einem Cross-functional Team liegt. Bevor ich aber niemand habe, der sich darum kümmert oder nur jemand nebenbei, ist mir eine Person immer noch lieber. Wie gesagt, es ging mir nicht um diese explizite Rolle des Chefdesigners im Elfenbeinturm, sondern darum, dass die Verantwortung für’s Ganze wahrgenommen wird.
Stimmt, beim genauen Lesen erkenne ich, dass Du „nicht unbedingt eine Person“ für diese Rolle siehst. Da bin ich froh.
Beim üblichen Querlesen bin ich leider an den 6x im Singular erwähnten „Chef(designer|architekt)“ hängengeblieben, so dass sich für mich ein falscher Eindruck ergab.
Und natürlich ist ein Spatz in der Hand besser als eine Taube auf dem Dach (Person vs Cross-functional Team)… immer.
CU
Boeffi
Umso wichtiger ist ja Dein Kommentar, weil er genau das präzisiert. Mir geht es einzig darum, dass mind. eine Person sich für die technische Gesamtlösung verantwortlich fühlt. Meist ist das bei mir ein einziger Chefdesigner, können aber schon auch Mal zwei oder drei Personen sein, z.B. einer eher mit Schwerpunkt Backend und einer mit Schwerpunkt GUI.
Ich würde sogar noch einen Schritt weiter gehen. Bei jedem Projekt/Vorhaben braucht es jemanden, der das Gesamtergebnis im Auge hat. Ich erlebe oft genug, dass die Teilbereiche alle vorschriftsgemäß ihre Aufgaben erledigen. Am Ende jedoch das bestellte Ergebnis nicht erreicht wird. Dann sind alle ganz betroffen und argumentieren: ich habe alle richtig gemacht.
Genau das ist der Punkt um den es mir geht: Wenn niemand sich für die Gesamtlösung verantwortlich fühlt können alle alles richtig machen und das Ergebnis ist trotzdem falsch.
Genau meine Meinung. Aber wenn ich Deinen Artikel richtig verstanden habe, soll das gerade nicht der Projektleiter sein?!
Auf einer recht hohen Abstraktionsebene braucht der Projektleiter natürlich schon den Blick für die Gesamtlösung. Auf tiefer technischer Ebene der Architektur und der Komponenten und Module oder auch auf Detailebene des Fachprozesses sehe ich das eher kritisch, weil dann der Projektleiter tendenziell zu viel in dieser Expertenrolle arbeitet und die Führungsebene vernachlässigt.
Das gilt m.E. nicht nur in Softwareprojekten, Marcus.
In allen (komplexeren) Projekten ist eine unsaubere Rollenaufteilung der größte Showstopper. Das sehe ich täglich in der Energietechnik.
Bei einer Vermischung zwischen Projektleitung und Ausführung/Planung leiden alle PM-Prozesse, wie Risk Management, Claim Management und Zeitmanagement.
Anders gesagt: Es ist besser, wenn der Projektleiter seine Aufgaben in zwei Projekten ausübt, als daß er in einem einzigen Projekt mehrere Rollen ausfüllen muß.
Die (im Anlagenbau gängige) Trennung in Project Manager, Engineering Manager, Project Engineer und Commissioning Manager kommt nicht von ungefähr und beruht nicht darauf, daß man zuviel Personal hätte.
Vielmehr ist es sinnvoll, gewisse Rollen auf verschiedene Personen zu verteilen.
Danke, Thilo, für diese wichtige Ergänzung. Insbesondere Deine Leitlinie, dass es besser ist die gleiche Rolle in verschiedenen Projekten auszuüben als in einer Person mehrere Rollen zu vermischen finde ich sehr gut!
Gerne, Marcus!
Ich freue mich, wenn ich auch mal interessante Fragen aufwerfen kann. Das mache ich so selten. ;o)
Die (noch ausführlichere) Antwort habe ich bei openPM ja bereits eingeworfen.