Kreativität durch Umdenken

Kreativität durch Umdenken

Schlech­te Ideen und der Weg zum Erfolg

Von Sup­port über Prä­sen­ta­tio­nen, bis hin zur Teil­nah­me an Work­shops und der Mode­ra­ti­on von Mee­tings: unse­re Arbeit besteht zu erheb­li­chen Tei­len aus Kom­mu­ni­ka­ti­on. So ste­hen wir immer vor der Her­aus­for­de­rung, krea­ti­ve Gesprächs­si­tua­tio­nen zu schaf­fen. Auch in der inter­nen Kom­mu­ni­ka­ti­on ist es uner­läss­lich, klas­si­sche For­ma­te wie Dai­lys oder Retro­spek­ti­ven für die Teil­neh­mer inter­es­sant und anre­gend zu gestal­ten, um mög­lichst viel krea­ti­ves Poten­zi­al freizusetzen.

Klassische Gesprächstechniken

Ein All-Time-Clas­sic unter den Gesprächs­tech­ni­ken ist das Brain­stor­ming. Die Teil­neh­mer wer­den dazu ermun­tert, ihren Ideen frei­en Lauf zu las­sen. Es geht dabei im ers­ten Schritt nicht um die qua­li­ta­ti­ve Bewer­tung die­ser Ideen, denn es sol­len ja gera­de unkon­ven­tio­nel­le, ori­gi­nel­le Gedan­ken Gehör fin­den. Aller­dings ver­lässt sich der Ansatz prin­zi­pi­ell dar­auf, dass die Teil­neh­mer die­se ori­gi­nel­len Gedan­ken auch abru­fen und arti­ku­lie­ren kön­nen. Es gibt jedoch eini­ge Fak­to­ren, die dem im Weg ste­hen können.

Was ist zum Bei­spiel, wenn die Teil­neh­mer ihre bes­ten Ideen bereits zum Aus­druck gebracht haben? Wich­ti­ge The­men inner­halb eines Pro­jekts tre­ten nor­ma­ler­wei­se nicht von jetzt auf gleich auf, die meis­ten Betei­lig­ten haben ver­mut­lich schon viel­fach über das The­ma nach­ge­dacht und sich eine fes­te Mei­nung gebil­det. Haben sich grund­sätz­li­che Annah­men und Ver­fah­rens­wei­sen erst ein­mal fest­ge­setzt, fällt es häu­fig schwer, die eige­ne Krea­ti­vi­tät noch­mal „auf Anfang“ zu stel­len. Auch kann es vor­kom­men, dass sich zu einem The­ma bereits nega­ti­ve Emo­tio­nen gebil­det haben, die eine offe­ne und auf­ge­schlos­se­ne Aus­ein­an­der­set­zung behindern. 

Neue Blickwinkel

In sol­chen Fäl­len kann es hilf­reich sein, den Gesprächs­teil­neh­mern einen Per­spek­tiv­wech­sel anzu­bie­ten, ja viel­leicht sogar deren poten­zi­ell nega­ti­ve Gefüh­le anzu­zap­fen. Wenn bei­spiels­wei­se Pro­ble­me an einem Pro­dukt beho­ben wer­den sol­len, kann die Per­spek­ti­ve eines ver­är­ger­ten Kun­den inter­es­san­te neue Ein­bli­cke geben. Wir stel­len uns also die Fra­ge, wie das Pro­dukt beschaf­fen sein müss­te, damit der Kun­de frus­triert auf­schreit: „Hier funk­tio­niert ja gar nichts!“ 

Obwohl wir immer noch über das glei­che The­ma – und eigent­lich auch die glei­che Fra­ge­stel­lung – reden, ergibt sich eine kom­plett neue Sicht­wei­se, die den Teil­neh­mern einen fri­schen Zugang ermög­licht. Hier befin­den wir uns bereits mit­ten im Rever­se Brain­stor­ming. Auch die­se Metho­de stammt – wie ihr Gegen­part – aus dem „Design Thin­king“. Die­ser Ansatz geht davon aus, dass die Lösung eines kom­ple­xen Pro­blems am bes­ten durch die Inter­ak­ti­on zwi­schen krea­ti­ven Men­schen aus ver­schie­de­nen Dis­zi­pli­nen erreicht wer­den kann, die gemein­sam einen struk­tu­rier­ten Pro­zess der Ideen­fin­dung durch­wan­dern. Wir set­zen uns also eine Fra­ge­stel­lung für unser ima­gi­nä­res Mee­ting und ver­keh­ren die­se dann ins Gegenteil.

Wie soll­te ein krea­ti­ves Mee­ting aus­se­hen, bei dem ein mög­lichst schlech­tes Ergeb­nis herauskommt?“

Die Doku­men­ta­ti­on eines Brain­stor­mings zu die­ser Fra­ge könn­te wie folgt aussehen.

Gegenteiltag im Meetingraum

  1. Legen Sie kei­ne Zie­le und Erwar­tun­gen für das Mee­ting fest. Um einen Miss­erfolg zu garan­tie­ren, soll­ten die Teil­neh­mer mög­lichst unstruk­tu­riert an das The­ma her­an­ge­hen, damit sich kei­ne gemein­sa­me Visi­on ent­wi­ckeln kann. Bit­ten sie die Teil­neh­mer dar­über hin­aus, sich nicht auf das The­ma vor­zu­be­rei­ten und stel­len Sie ihnen im Vor­feld kei­ne Mate­ria­li­en zur Ver­fü­gung. Eine knap­pe Anset­zung („in einer Stun­de im Mee­ting­raum!“) kann die­se Effek­te ver­stär­ken und men­ta­le sowie inhalt­li­che Vor­be­rei­tung erfolg­reich unterbinden.
  1. Auch die unsorg­fäl­ti­ge Aus­wahl der Teil­neh­mer ist ele­men­tar für ein Schei­tern. Die­se soll­ten alle aus dem­sel­ben Fach­be­reich stam­men und eine mög­lichst schma­le Band­brei­te an Per­spek­ti­ven in den Krea­tiv­pro­zess ein­brin­gen. Idea­ler­wei­se gibt der ers­te Teil­neh­mer ein State­ment ab und alle ande­ren schlie­ßen sich ihm kom­men­tar­los an. Ein sol­cher Krea­tiv­pro­zess kann schon inner­halb weni­ger Minu­ten zum Erlie­gen kommen.
  1. Mit einer unge­eig­ne­ten Mode­ra­ti­on kann die­ser Effekt noch ver­stärkt wer­den. Stil­le, intro­ver­tier­te Teil­neh­mer ver­su­chen häu­fig nicht aktiv, sich ins Gespräch ein­zu­brin­gen, gut so! Hier soll­te von­sei­ten der Gesprächs­füh­rung nicht inter­ve­niert wer­den, denn je weni­ger Teil­neh­mer sich äußern, des­to weni­ger krea­ti­ve Syn­er­gien kön­nen ent­ste­hen. Gera­de mei­nungs­star­ke Teil­neh­mer, die sich ger­ne selbst reden hören, soll­ten ermun­tert wer­den, das Mee­ting in eine One-Man-Show zu verwandeln.
  1. Schlech­tes Zeit­ma­nage­ment und nicht vor­han­de­ne Doku­men­ta­ti­on run­den jedes erfolg­lo­se Krea­tiv­mee­ting ab. Je län­ger sich mit den immer glei­chen Punk­ten beschäf­tigt wird, des­to unwahr­schein­li­cher wird ein krea­ti­ver Durch­bruch. Soll­te doch fünf Minu­ten vor dem Anschluss­ter­min jemand einen Geis­tes­blitz haben, kann die­ser lei­der nicht mehr aus­führ­lich bespro­chen wer­den. Da sowie­so kein kla­res Ziel for­mu­liert wur­de, ist das aber auch gar nicht schlimm. Wenn das Mee­ting dar­über hin­aus nicht schrift­lich fest­ge­hal­ten wird, ist sicher­ge­stellt, dass das Team beim nächs­ten mal wie­der exakt bei null anfängt.

Der diebische Spaß am Destruktiven

Das soll erst­mal rei­chen, obwohl noch eini­ge Punk­te hät­ten fol­gen kön­nen. Denn dem Leser mag auf­ge­fal­len sein, wie viel Spaß der Autor beim Schrei­ben die­ses Abschnitts hat­te. Tat­säch­lich lie­ßen sich die Absät­ze ein­fach so run­ter­schrei­ben und er muss­te sich kaum am Rie­men rei­ßen, um nicht gedank­lich abzu­schwei­fen. Dar­in wird die Kraft des Rever­se Brain­stor­mings deut­lich. Das Anzap­fen nega­ti­ver Gefüh­le wird – aus nach­voll­zieh­ba­ren Grün­den – eher sel­ten im Krea­tiv­pro­zess genutzt. Umso erfri­schen­der ist es, wenn man in der Phan­ta­sie mal so rich­tig die Welt bren­nen las­sen kann.

Nach­dem zu Beginn ein Pro­blem defi­niert wur­de, kön­nen wir final die erziel­ten Ergeb­nis­se ins Gegen­teil umkeh­ren, um Lösungs­vor­schlä­ge zu for­mu­lie­ren. Das soll­te nun kaum noch Schwie­rig­kei­ten berei­ten, da die Krea­tiv­ar­beit – ohne dass es sich wirk­lich so ange­fühlt hat – schon erle­digt ist.

Confluence und Jira in gewachsenen Kundenprojekten

Confluence und Jira in gewachsenen Kundenprojekten

SYST­HE­MIS at Work

Wir arbei­ten seit Lan­gem mit Con­fluence und Jira und haben uns über die Jah­re eine Exper­ti­se in der Ein­füh­rung und Betreu­ung der Tools in Kun­den­pro­jek­ten erar­bei­tet. Heu­te wol­len wir einen Ein­blick in unse­re Arbeit geben und auf häu­fi­ge Feh­ler und Miss­ver­ständ­nis­se hin­wei­sen, die bei der Ein­füh­rung zu beach­ten sind.

Warum Atlassian?

Die SYST­HE­MIS setzt aus guten Grün­den auf Atlas­si­an-Pro­duk­te, da sie sowohl was den Umfang, die Inter­kon­nek­ti­vi­tät sowie die Ska­lier­bar­keit betrifft, für jede Art von Pro­jekt – nicht nur in der Soft­ware­ent­wick­lung – eine umfas­sen­de Basis für gelun­ge­nes Pro­jekt­ma­nage­ment bie­ten. Eine gro­ße Stär­ke von Atlas­si­an-Tools ist ihre Fähig­keit, orga­nisch mit einem Kun­den­pro­jekt zu wach­sen. Das gilt sowohl für die indi­vi­du­el­le Kon­fi­gu­ra­ti­on der Werk­zeu­ge selbst, als auch für ihre Inter­kon­nek­ti­vi­tät. Jira kann bei­spiels­wei­se pro­blem­los in eine bestehen­de Con­fluence-Infra­struk­tur inte­griert wer­den, wenn zu einem spä­te­ren Zeit­punkt im Pro­jekt ein Bedarf ent­steht. Zudem ste­hen zahl­rei­che Erwei­te­run­gen zur Ver­fü­gung und auch eine Ver­bin­dung mit ande­ren Sys­te­men ist möglich.

All die­se Vor­tei­le und Mög­lich­kei­ten dür­fen jedoch nicht den Ein­druck erwe­cken, dass die Ein­füh­rung sowie ein grund­sätz­li­ches Ver­ständ­nis der Anwen­dun­gen allein schon eine Struk­tur in Unter­neh­mens­pro­zes­se brin­gen. Atlas­si­an Tools sind kei­ne Black­bo­xes, die man mit rele­van­ten Infor­ma­tio­nen füt­tert und die einem dann eine Road­map aus­spu­cken: es sind im bes­ten Sin­ne Werk­zeu­ge, die von Men­schen kom­pe­tent bedient wer­den müs­sen, um ihre vol­le Wir­kung zu entfalten.

Fallstricke bei der Implementierung

Die Ein­füh­rung von Con­fluence und/oder Jira läuft unse­rer Erfah­rung nach häu­fig so ab: eine oder meh­re­re Per­so­nen wer­den mit der Auf­ga­be betraut und befas­sen sich mit dem The­ma. Die Tools wer­den als ein Auf­ga­ben­be­reich ver­stan­den, der mög­lichst von einem klei­nen Team abge­deckt wer­den soll. Dabei haben die betrof­fe­nen Per­so­nen oft noch ande­re rele­van­te Funk­tio­nen im Unter­neh­men und sol­len die Betreu­ung der Platt­form zusätz­lich erle­di­gen. Schon bald nach der Ein­füh­rung beginnt die Platt­form zu wach­sen, neue Auf­ga­ben kom­men hin­zu, das „Unkraut“ sprießt. Der eigent­li­che Effekt, den man sich von einem Kol­la­bo­ra­ti­ons-Tool erhofft hat, näm­lich ein Mehr an Struk­tur, ein Mehr an Über­sicht­lich­keit, droht, sich ins Gegen­teil zu ver­keh­ren: anstatt dem Team Arbeit abzu­neh­men, ent­steht zusätz­li­che Arbeit.

Organisatorische Rahmenbedingungen

Um die­ses Pro­blem zu ver­mei­den, soll­te die Ein­füh­rung eines Kol­la­bo­ra­ti­ons-Tools von Beginn an auf meh­re­re orga­ni­sa­to­ri­sche Säu­len ver­teilt wer­den. Es ist uner­läss­lich, sich bereits zu Beginn die Fra­ge zu stel­len, wel­che Anfor­de­run­gen man an das Tool hat und wel­che The­men im spä­te­ren Ver­lauf noch hin­zu­kom­men könn­ten. Denn jedes The­ma bringt auch wei­te­re Auf­ga­ben mit sich und benö­tigt zusätz­li­che Res­sour­cen. Ist der Über­blick in einem gewach­se­nen Kun­den­pro­jekt erst ein­mal ver­lo­ren gegan­gen, führt oft kein Weg an einer grund­sätz­li­chen Neu­struk­tu­rie­rung vor­bei. Als Ori­en­tie­rung dient uns hier das ITIL v4 Framework.

Bereiche und Funktionen

Grund­sätz­lich lässt sich eine Unter­schei­dung zwi­schen tech­ni­schen und fach­li­chen The­men tref­fen. Auf der tech­ni­schen Sei­te ste­hen der Betrieb der Pro­duk­te sowie die tech­ni­sche Admi­nis­tra­ti­on. Im Betrieb geht es um The­men wie das Moni­to­ring auf Sys­tem­ebe­ne, Lizenz­be­schaf­fung, das Patch- und Update­ma­nage­ment, CR-Manage­ment und Ver­trags­con­trol­ling. Die Admi­nis­tra­ti­on dage­gen trägt die Gesamt­ver­ant­wor­tung für das Sys­tem. Von tech­ni­scher Bera­tung über War­tungs­auf­ga­ben bis hin zu Feh­ler- und Plug­in­ma­nage­ment lau­fen hier alle Fäden zusammen.

Der First und Second Level-Sup­port ist der zen­tra­le Ansprech­part­ner, an den die Nut­zer des Sys­tems sich wen­den kön­nen, um Tickets für alle mög­li­chen Anlie­gen auf­zu­ma­chen; wenn bei­spiels­wei­se neue Nut­zer oder Rech­te gebraucht wer­den, aber auch für neue Fea­tures und grund­sätz­li­che Fragen.

Fach­ad­mi­nis­tra­ti­on und Con­tent-Pfle­ge sind stets eng gekop­pelt mit der tech­ni­schen Admi­nis­tra­ti­on, da jede Neue­rung im Sys­tem indi­vi­du­ell kon­fi­gu­riert wer­den muss. Sie ist unter­stüt­zend tätig für neue Anfor­de­run­gen, die nicht auf dem First und Second Level lie­gen. Dabei kann es um die Struk­tu­rie­rung und Gestal­tung von Berei­chen in den Anwen­dun­gen gehen, oder auch um den Umgang mit Plug­ins und Makros.

Wie ver­hin­dert man nun aber das oben beschrie­be­ne Sprie­ßen von „Unkraut“? Anstatt die Nut­zer selbst wild drauf los arbei­ten zu las­sen, wer­den im Bereich Vor­la­gen und Plug­ins Stan­dards ange­legt: Bereichs- und Sei­ten­vor­la­gen wie bei­spiels­wei­se Pro­to­kol­le, Über­sichts­sei­ten, sowie vor­ausge­wähl­te Plug­ins. Die­ser Pro­zess soll­te in eine Art Vor­la­gen­ma­nage­ment mün­den, in die sinn­vol­le Ver­wal­tung und Wei­ter­ent­wick­lung sol­cher Vor­la­gen. Auch das The­ma Wor­ding spielt hier eine Rol­le: wie benen­ne ich mei­ne Sei­ten oder wie erzie­le ich ein­heit­li­che Sei­ten­struk­tu­ren, damit sich jeder über­all zurechtfindet?

Es emp­fiehlt sich auch, ein eige­nes Test­sys­tem ein­zu­füh­ren, um Plug­ins aus­pro­bie­ren zu kön­nen. Bei Tests im Pro­duk­tiv­sys­tem geht viel zu schnell der Über­blick ver­lo­ren und es ver­ur­sacht extra Arbeit im Nach­gang, wenn Plug­ins wie­der zurück­ge­baut wer­den müssen.

An die­ser Stel­le schlägt sich eine Brü­cke zum The­ma Pro­zes­se und Stan­dards, also zur Fra­ge: Wie arbei­te ich mit den Werk­zeu­gen? Wird bei­spiels­wei­se ein neu­es Jira-Pro­jekt benö­tigt, emp­fiehlt es sich, das in Con­fluence fest­zu­hal­ten, um den Vor­gang für die Nut­zer nach­voll­zieh­bar zu machen. Alle Wege füh­ren in Rich­tung Standardisierung.

Der Qua­li­täts­ma­na­ger ist der Gärt­ner in unse­rem Sys­tem. Er über­wacht und prüft, ob Pro­zes­se und Stan­dards gelebt, sowie Vor­la­gen gemäß den Vor­ga­ben ver­wen­det wer­den. Er hat das gro­ße Bild, das gan­ze Sys­tem im Blick. Gera­de in Jira besteht immer die Gefahr einer „Über­mül­lung“. Daher ist es wich­tig, eine neu­tra­le Stel­le zu instal­lie­ren, die prüft, ob Tickets oder Tei­le von Pro­jek­ten unbe­ar­bei­tet im Sys­tem lie­gen und gege­be­nen­falls ent­fernt wer­den können.

Rollen

Wie nun die beschrie­be­nen Berei­che auf kon­kre­te Rol­len ver­teilt wer­den, hängt von den indi­vi­du­el­len Vor­aus­set­zun­gen und Bedürf­nis­sen des jewei­li­gen Unter­neh­mens ab. In einem klas­si­schen Kick-Off wür­de der Bera­ter der SYST­HE­MIS mit dem Kun­den gemein­sam ein Kon­zept erar­bei­ten, wie die rich­ti­gen Exper­ten am bes­ten ein­zu­set­zen sind, um die Berei­che opti­mal abzu­de­cken. Unse­re Erfah­rung zeigt: ein geschul­ter Blick von außen ist häu­fig Gold wert, um Poten­zia­le zu erken­nen und opti­mal zu nutzen.