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)



Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

11 Kommentare

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­tion­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/

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­tion­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.

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­tion­al Team)… immer.

CU
Boeffi

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.

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.

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.

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?!

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.

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, Cla­im 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.

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!

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