Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Hvis du nogensinde har set amerikanske actionfilm, er du helt sikkert stødt på en flok hårdtarbejdende politifolk på et blodigt gerningssted.
De er engageret i gang med at sikre beviser og diskutere de første teorier om, hvad der er gået forud for det rod, de står i.
Deres entusiasme får dog et skud for boven, når et par mørke biler drøner ind på gerningsstedet, og en flok - ofte lidt overlegne - FBI-agenter træder ud af bilerne.
I deres flotte logo-tøj trækker de skiltene og melder, at de overtager ansvaret herfra.
Hvad der sker derefter, kan gå i mange retninger, men ofte involverer det et lidt modvilligt samarbejde imellem den lokale "police department" og de skarpe typer fra FBI.
På trods af konflikterne løser de dog opgaven og får skurkene bag tremmer, hvorefter forbrødringen indfinder sig i solnedgangen.
Minder om forholdet mellem udviklere og arkitekter
Sat på spidsen minder forholdet imellem de lokale politifolk og FBI-agenterne om det forhold, arkitekter og udviklere af og til kan have til hinanden - jeg har gennem tiden selv oplevet det fra begge sider.
Udviklerne lever i en hands on-verden og har den daglige kontakt med de basale værktøjer og systemer, som de bruger til at løse de konkrete udviklingsopgaver, med de udfordringer, det giver.
Ligesom de lokale politifolk kender de deres nærmiljø og ved godt, hvilke områder de skal holde sig fra, hvis de vil undgå ballade, og om de i overført betydning skal trække bødeblokken eller pistolen, når de står overfor et "problem."
De har derfor ofte en stor portion sund skepsis overfor indblanding fra den føderale efterforskningsenhed (arkitekterne), som jo umuligt kan vide, hvad de taler om, når de aldrig får hænderne rigtig beskidte.
Arkitekterne lever omvendt i en mere overordnet og tværgående verden med et bredere syn på de udfordringer, der skal løses.
Ligesom FBI agenterne har de en værktøjskasse, der rækker ud over de forhåndenværende "våben" i politibæltet.
De har derfor ofte et klarere blik for de grundlæggende mønstre bag de opgaver, der skal løses, og kan derfor ofte bidrage med overblik og sikre sammenhæng i et større perspektiv.
De ryster måske endda på hovedet af de lokale politifolks (udviklernes) snæversynede og naive tilgang.
Skæbnefællesskab
På trods af gruppernes forskellige synsvinkler er de dog for evigt forenet i et skæbnefællesskab med de samme mål og udfordringer.
Politifolkene og FBI-agenterne har en fælles mission om at få opklaret mordsagen, selvom de er omgivet af korrupte chefer og tungt bevæbnede "bad guys" bag hvert et gadehjørne.
Udviklerene og arkitekterne har en fælles mission om at få skabt sunde og velfungerende it-løsninger, imens de løber spidsrod blandt kunder, brugere, projektledere, leverandører, chefer, scrum-masters og andet godtfolk.
Jeg er i tvivl om, hvem der har fået den hårdeste tjans.
I så fjendtlige miljøer er der ingen vej uden om konstruktivt samarbejde for at få den fælles mission til at lykkes.
Det er således en bunden opgave for it-mæssig success at få udviklernes håndgribelige erfaring med den systemmæssige virkelighed til at gå op i en højere enhed med arkitekternes tværgående blik og ofte lidt tættere relation til de styrende kræfter.
Heldigvis har de fleste FBI-folk og arkitekter en fortid med hands-on arbejde, så de både har en indbygget faglig respekt for den anden gruppes virkelighed og samtidig får en vis "credibility" retur, når tingenes tilstand skal afklares.
Det er en hjørnesten i gruppernes samarbejde og noget der skal bygges på, når den gensidige tillid skal op. Ligesom når en FBI agent kender en af de lokale betjente fra politiskolen.
Det er også forklaringen på, at samarbejdet kan komme i problemer, hvis der bliver for lang faglig afstand uden noget overlap i kompetencerne, så der ikke er tilstrækkelig grobund for den gensidige faglige respekt.
Det kan ske, hvis arkitekter og udviklere er for langt fra hinanden erfarings- og kompetencemæssigt.
I værste tilfælde varetages enten arkitekt- eller udviklingsopgaven af medarbejdere uden tilstrækkelige faglige kompetencer. I så fald falder samarbejdet til jorden, og kvaliteten og værdien af den anden gruppes arbejde reduceres desuden markant, da kvalificerede bidrag skal kunne gives og modtages af begge roller, for at brikkerne kan falde på plads.
Ellers risikerer det at blive, som når en ni-årig tager sig en patruljetur i en af politibilerne for at hjælpe.
Det kan være underholdende som tilskuer, men er sjældent fremmende for opgavens løsning.
Hierakiet
Hierarkiet skal også håndteres. Typisk rangerer arkitekterne lidt højere i det formelle hierarki og sidder lidt tættere på ledelsen med den indflydelse, det giver.
Det ændrer dog ikke på, at udviklerne sidder med den systemmæssige virkelighed. Og det ved de godt. Som bekendt er virkeligheden altid den samme, uanset hvordan noget tegnes i Powerpoint. Og et UML-diagram er sjældent det foretrukne redskab til at løse akutte driftsproblemer.
På den måde kan man sige, at der er balance i tingene, så unødige benspænd den ene eller anden vej skal undgås af hensyn til det fælles mål.
FBI ved godt, at det ikke gavner at ignorere politifolkene, og omvendt nægter den lokale betjent heller ikke at bruge sin politiradio, hvis en FBI kollega ligger såret på fortovet.
Det sidste men ikke desto mindre vigtigste aspekt i samarbejdet er, hvordan dialogen føres. Her stopper parallellen med filmuniverset dog, da tonen i de fleste actionfilm må siges at være vel direkte og rå til en hverdag på kontoret.
Men der er selvfølgelig også forskel på at dele dessiner ud i en hektisk ildkamp og at diskutere pros/cons ved et whiteboard.
Sidstnævnte kan dog også få pulsen op. Og det må det gerne, da en engageret faglig dialog er absolut nødvendig for at få trykprøvet og belyst de forskellige perspektiver, der altid vil være på en løsningsmæssig beslutning.
Dialogen skal blot altid tage udgangspunkt i de faglige argumenter og må ikke degenerere i retning af personlige konflikter eller ensidig kæpheste-dressur.
I det lys er der heldigvis et stykke vej fra det temperamentsfulde persongalleri i en amerikansk actionfilm til den gennemsnitlige danske it-udviklingsafdeling.
Det er dog svært ikke at lege med tanken om, hvorvidt nogle af tidens store it-skandaler måske kunne være undgået, hvis flere arkitekter og udviklere var mødt op med en attitude a'la Bruce Willis i Die Hard eller Tom Cruise i Mission lmpossible?
Gode råd
Uanset hvad, så prøv følgende, hvis du som udvikler eller arkitekt vil løfte dit samarbejde med din "partner in crime" til nye højder:
- Fokuser på jeres fælles mission og overlappende faglighed, da det (kun) er jer, der har kvalifikationerne til at tage de gode tekniske beslutninger på slutproduktets vegne
- og dem er der brug for. - Samarbejd ligeværdigt og anerkend hinandens erfaringer og roller.
- Giv fuld gas med engagementet i de faglige diskussioner, men hold fokus på de faglige argumenter - uanset hvem der bringer dem til bordet.
Og tag så eventuelt en tur i biografen sammen - I kunne jo se noget amerikansk action ...
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
