Der Blick für die Gesamtlösung

In mei­nen Soft­ware­pro­jek­ten gibt es immer min­des­tens eine Per­son, die einen Blick auf die tech­ni­sche Gesamt­lö­sung hat. Die­ser tech­ni­sche Chef­de­si­gner ist dafür ver­ant­wort­lich, das die Soft­ware am Ende ein in sich stim­mi­ges Gesamt­bild ergibt. Kei­ne leich­te Auf­ga­be, die zudem nicht immer expli­zit so als Rol­le benannt und besetzt wird, son­dern irgend­wie neben­bei erle­digt wer­den soll. Ich hal­te aber genau das für einen ent­schei­den­den Erfolgs­fak­tor in Softwareprojekten.

Da ich in der Regel weder tech­nisch noch fach­lich tief genug in der Mate­rie des Pro­jekts ste­cke, und als Pro­jekt­lei­ter auch nicht ste­cken soll­te, brau­che ich min­des­tens einen Men­schen in mei­nem Team, der einen Blick auf die tech­ni­sche Gesamt­lö­sung hat. Ich nen­ne die­se Rol­le dann ger­ne tech­ni­scher Chef­de­si­gner oder Chef­ar­chi­tekt. In ande­ren Bran­chen heißt die­se Rol­le viel­leicht anders, aber ich bin mir sicher, dass es sie dort auch in ähn­li­cher Wei­se gibt.

Der tech­ni­sche Chef­de­si­gner ist ver­ant­wort­lich für die Archi­tek­tur der Soft­ware im Sin­ne des modu­la­ren Auf­baus, die beim Kun­den ein­setz­ba­ren und schließ­lich ein­ge­setz­ten Kom­po­nen­ten und letzt­lich für die tech­ni­sche Qua­li­tät. Wobei ver­ant­wort­lich nicht hei­ßen soll, dass er die­se Din­ge ganz im Sti­le der tay­lo­ris­ti­schen Krea­ti­vi­täts­apart­heid vor­gibt, das kann und soll­te bes­ser im Team gemein­sam ent­schie­den wer­den. Ver­ant­wort­lich heißt aber, dass er den ande­ren Mit­glie­dern des Teams hilft, die Archi­tek­tur und Vor­ga­ben kor­rekt umzu­set­zen. Damit hat der tech­ni­sche Chef­de­si­gner, der in der Regel auch ein wenig erfah­re­ner ist als die ande­ren Team­mit­glie­der, auch ein wenig die Rol­le des Vor­ar­bei­ters oder Handwerksmeisters.

In grö­ße­ren und kom­pli­zier­te­ren Pro­jek­ten wird die­se Rol­le des tech­ni­schen Chef­de­si­gners meist auch expli­zit besetzt. In klei­ne­ren hin­ge­gen ist es oft der Pro­jekt­lei­ter, der die­se Rol­le über­nimmt. Oder bes­ser gesagt: Der eigent­li­che Chef­ar­chi­tekt wird neben­bei zum Pro­jekt­lei­ter gemacht. Vor die­sem Rol­len­kon­flikt zwi­schen Füh­rungs­auf­ga­be einer­seits und inhalt­li­cher Arbeit als Top-Exper­te ande­rer­seits kann nicht oft genug gewarnt wer­den. Weni­ger in dem Sin­ne, dass die­se Dop­pel­rol­le nicht mach­bar wäre, son­dern viel­mehr, dass ein bewuss­tes Reflek­tie­ren not­wen­dig ist, um bei­den Rol­len gerecht zu wer­den. Bewährt hat sich in die­sem Zusam­men­hang die Beglei­tung durch einen erfah­re­nen Men­tor als Pro­jekt­coach.

Arti­kel­bild: Saad Akhtar bei flickr.com (CC BY 2.0)

Wie hilf­reich war die­ser Beitrag? 

Kli­cke auf die Ster­ne um zu bewerten! 

Durch­schnitt­li­che Bewer­tung 0 / 5. Anzahl Bewer­tun­gen: 0

Bis­her kei­ne Bewer­tun­gen! Sei der Ers­te, der die­sen Bei­trag bewertet. 

Es tut uns leid, dass der Bei­trag für dich nicht hilf­reich war! 

Las­se uns die­sen Bei­trag verbessern! 

Wie kön­nen wir die­sen Bei­trag verbessern? 

11 Kommentare

Boeffi 10. August 2014 Antworten

Hmmm…,

nicht nur aus einer „agi­len“ Bril­le betrach­tet, erle­be ich die (expli­zi­te) Rol­le des „Chef­de­si­gners“ als kritisch.

Kri­tisch als übli­che „una per­so­na“ Aus­klei­dung – häu­fig zusätz­lich mit wei­te­ren Ver­ant­wor­tungs­be­rei­chen – mit all den Her­aus­for­de­run­gen, die sich dadurch ergeben. 

Wis­sens-Mono­pol, Truck / Bus fac­tor, gerin­ge Iden­ti­fi­ka­ti­on mit Archi­tek­tur-Ent­schei­dun­gen (im Elfen­bein­turm), dadurch feh­len­de Über­nah­me von „ver­ant­wort­lich sein“ bei den Team­mit­glie­dern, schlech­te Umset­zungs­qua­li­tät (selbst „jun­ge“ Soft­ware besteht aus archi­tek­tu­ra­lem Spa­ghet­ti-Code, dadurch schlech­te Wart­bar­keit, hohe Bug Rate, schnell stei­gen­de tech­ni­sche Schul­den), usw.

Dies scheint sich wie ein Natur­ge­setz durch die Pro­jek­te zu ziehen.

Eine (Teil-) Lösung, d.h. eine signi­fi­kan­te Ver­bes­se­rung erle­be ich in Kon­tex­ten, in denen auch die Archi­tek­tur-Ver­ant­wor­tung bei Cross-func­tio­n­al Teams /1/ liegt (nicht nur auf dem Papier). Bei Teams, die z.B. im Sin­ne eines Com­mu­ni­ty of Prac­ti­ces-Kon­zep­tes (CoP) u.a. auch Archi­tek­tur-Wis­sen auf­bau­en und gelebt umset­zen kön­nen. Und weil es aus den Teams her­aus – von den eige­nen Team­mit­glie­dern – unter Berück­sich­ti­gung nicht nur theo­re­ti­scher, son­dern ganz prak­ti­scher Anfor­de­run­gen ent­steht, ist die Iden­ti­fi­ka­ti­on und damit die Umset­zungs­qua­li­tät deut­lich vorteilhafter.

Mei­ne Erfah­run­gen und mei­ne 2 cents…

CU
Boeffi

/1/ http://boeffi.net/scrum/agile-smells/agile-smells-im-team/cross-functional-team-semantik-falsch-interpretiert/

Marcus Raitner 10. August 2014 Antworten

Dan­ke Boef­fi für Dei­nen Kom­men­tar! Ich sehe das ganz ähn­lich wie Du. Wir sind uns schon Mal einig, dass jemand den Blick für die Gesamt­lö­sung haben soll­te. Ich habe ver­sucht im Arti­kel auch anklin­gen zu las­sen, dass das nicht unbe­dingt eine Per­son sein muss. Idea­ler­wei­se ist es wirk­lich so wie Du schreibst, dass die Ver­ant­wor­tung dafür bei einem Cross-func­tio­n­al Team liegt. Bevor ich aber nie­mand habe, der sich dar­um küm­mert oder nur jemand neben­bei, ist mir eine Per­son immer noch lie­ber. Wie gesagt, es ging mir nicht um die­se expli­zi­te Rol­le des Chef­de­si­gners im Elfen­bein­turm, son­dern dar­um, dass die Ver­ant­wor­tung für’s Gan­ze wahr­ge­nom­men wird.

Boeffi 10. August 2014 Antworten

Stimmt, beim genau­en Lesen erken­ne ich, dass Du „nicht unbe­dingt eine Per­son“ für die­se Rol­le siehst. Da bin ich froh.

Beim übli­chen Quer­le­sen bin ich lei­der an den 6x im Sin­gu­lar erwähn­ten „Chef(designer|architekt)“ hän­gen­ge­blie­ben, so dass sich für mich ein fal­scher Ein­druck ergab.

Und natür­lich ist ein Spatz in der Hand bes­ser als eine Tau­be auf dem Dach (Per­son vs Cross-func­tio­n­al Team)… immer.

CU
Boeffi

Marcus Raitner 10. August 2014 Antworten

Umso wich­ti­ger ist ja Dein Kom­men­tar, weil er genau das prä­zi­siert. Mir geht es ein­zig dar­um, dass mind. eine Per­son sich für die tech­ni­sche Gesamt­lö­sung ver­ant­wort­lich fühlt. Meist ist das bei mir ein ein­zi­ger Chef­de­si­gner, kön­nen aber schon auch Mal zwei oder drei Per­so­nen sein, z.B. einer eher mit Schwer­punkt Backend und einer mit Schwer­punkt GUI.

Erwin Zauner 11. August 2014 Antworten

Ich wür­de sogar noch einen Schritt wei­ter gehen. Bei jedem Projekt/Vorhaben braucht es jeman­den, der das Gesamt­ergeb­nis im Auge hat. Ich erle­be oft genug, dass die Teil­be­rei­che alle vor­schrifts­ge­mäß ihre Auf­ga­ben erle­di­gen. Am Ende jedoch das bestell­te Ergeb­nis nicht erreicht wird. Dann sind alle ganz betrof­fen und argu­men­tie­ren: ich habe alle rich­tig gemacht.

Marcus Raitner 11. August 2014 Antworten

Genau das ist der Punkt um den es mir geht: Wenn nie­mand sich für die Gesamt­lö­sung ver­ant­wort­lich fühlt kön­nen alle alles rich­tig machen und das Ergeb­nis ist trotz­dem falsch.

Erwin Zauner 11. August 2014 Antworten

Genau mei­ne Mei­nung. Aber wenn ich Dei­nen Arti­kel rich­tig ver­stan­den habe, soll das gera­de nicht der Pro­jekt­lei­ter sein?!

Marcus Raitner 11. August 2014 Antworten

Auf einer recht hohen Abs­trak­ti­ons­ebe­ne braucht der Pro­jekt­lei­ter natür­lich schon den Blick für die Gesamt­lö­sung. Auf tie­fer tech­ni­scher Ebe­ne der Archi­tek­tur und der Kom­po­nen­ten und Modu­le oder auch auf Detail­e­be­ne des Fach­pro­zes­ses sehe ich das eher kri­tisch, weil dann der Pro­jekt­lei­ter ten­den­zi­ell zu viel in die­ser Exper­ten­rol­le arbei­tet und die Füh­rungs­ebe­ne vernachlässigt.

Thilo 13. August 2014 Antworten

Das gilt m.E. nicht nur in Soft­ware­pro­jek­ten, Marcus.
In allen (kom­ple­xe­ren) Pro­jek­ten ist eine unsau­be­re Rol­len­auf­tei­lung der größ­te Show­stop­per. Das sehe ich täg­lich in der Energietechnik.
Bei einer Ver­mi­schung zwi­schen Pro­jekt­lei­tung und Ausführung/Planung lei­den alle PM-Pro­zes­se, wie Risk Manage­ment, Claim Manage­ment und Zeitmanagement.

Anders gesagt: Es ist bes­ser, wenn der Pro­jekt­lei­ter sei­ne Auf­ga­ben in zwei Pro­jek­ten aus­übt, als daß er in einem ein­zi­gen Pro­jekt meh­re­re Rol­len aus­fül­len muß.

Die (im Anla­gen­bau gän­gi­ge) Tren­nung in Pro­ject Mana­ger, Engi­nee­ring Mana­ger, Pro­ject Engi­neer und Com­mis­sio­ning Mana­ger kommt nicht von unge­fähr und beruht nicht dar­auf, daß man zuviel Per­so­nal hätte.

Viel­mehr ist es sinn­voll, gewis­se Rol­len auf ver­schie­de­ne Per­so­nen zu verteilen.

Marcus Raitner 14. August 2014 Antworten

Dan­ke, Thi­lo, für die­se wich­ti­ge Ergän­zung. Ins­be­son­de­re Dei­ne Leit­li­nie, dass es bes­ser ist die glei­che Rol­le in ver­schie­de­nen Pro­jek­ten aus­zu­üben als in einer Per­son meh­re­re Rol­len zu ver­mi­schen fin­de ich sehr gut!

Thilo 16. August 2014 Antworten

Ger­ne, Marcus!
Ich freue mich, wenn ich auch mal inter­es­san­te Fra­gen auf­wer­fen kann. Das mache ich so sel­ten. ;o)

Die (noch aus­führ­li­che­re) Ant­wort habe ich bei openPM ja bereits eingeworfen.

Schreibe einen Kommentar