“Vi skal tjene penge og have det sjovt. Men vi skal ikke tjene så mange penge at vi ikke
At tegne en hane
Det fortælles om Kejseren af Kina at han bestilte en tuschtegning af en hane hos en dygtig tegner. Tegneren sagde at den kunne være klar om fire år. Fire år senere var den dog endnu ikke klar, men tegneren lovede at om fire år mere ville den være færdig. Fire år senere gentog historien sig. Da Kejseren efter nu tolv års forløb troppede op med hele sit følge hos teg-neren, sagde denne atnuvar den klar. Han tog et nyt stykke papir, og med sin pensel tegnede han i én eneste hurtig bevægelse en helt ufatteligt livagtig hane. Da Kejseren spurgte hvorfor han skulle bruge tolv år, tog tegneren ham med ind i rummet ved siden af hvor der lå stabler af tegninger fra gulv til loft – af haner!
Frit efter [Bastian88]
har det sjovt. Og vi skal ikke have det så sjovt at vi ikke tjener penge”. Sådan lyder en klassiker fra ledelseslitteraturen. Og den kan overføres til it-udvikling. Nogle gange har vi det så sjovt at vi får udviklet for lidt og forkert. Vi har så meget fokus på hele tiden at anvende den ultimative og nyeste teknologi at vi glemmer det vigtigste: at vi skal lave gode systemer til kunderne. Her bør vi satse mere på det gode håndværk, frem for at forfølge de nyeste (og sjoveste) værktøjer og ideer for enhver pris. Det er nemlig ikke altid brugerne opdager at deres system er lavet med en meget fancy, ny indmad – og som regel er de også ligeglade.
Man kunne stille spørgsmålet: For hvis skyld er det så vi uophørligt jagter det nye-ste? Er det i virkeligheden for udviklernes egen skyld? For at de kan have det sjovt? Og vise at de er med på noderne? Og at det er sjovt at arbejde her hos os, så vi kan tiltræk-ke og fastholde de dygtigste udviklere? Dette kaldes også Mount Everest-syndromet: vi bruger den nyeste teknologi bare for at bevise at vi kan. Og nogle kalder ny teknologi for “udviklernes opium”: de skal have noget nyt at lege med en gang imellem. Selvføl-gelig skal vi hele tiden holde nyhederne under observation, men måske ville vi en gang imellem stå os bedre ved lige at vente lidt og få andre til at indhøste erfaringer med nye værktøjer, mens vi koncentrerer os om at få løst opgaven til kundens tilfredshed.
Og så er der lige det med læreprocessen: når vi endelig er blevet gode til en bestemt teknologi eller et bestemt værktøj, kan vi jo lige så godt have glæde af det – i stedet for straks at ile videre til det næste og dermed starte forfra på læreprocessen.
Men man skal heller ikke vente alt for længe med at tage nye teknologier i brug.
Det kaldes Thomas Lawson-syndromet hvis man krampagtigt forsøger at holde fast i en kendt teknologi længe efter at man burde være skiftet til en ny:
Eller med den amerikanske psykolog Abraham Maslows ord: “hvis du er god til at
bru-T h o m a s L a w s o n
I slutningen af 1800-tallet, da dampskibene begyndte at fortrænge sejlskibene, forsøgte nogen at bygge større og større sejlskibe ud fra ideen om at det var en kendt teknologi, og de var prisbillige at sejle med. F.eks. byggede man både fem- og seks-mastede skonnerter. Og i 1902 byggede man verdens enestesyv-mastede skonnert, Thomas Lawson. For at håndtere sejlene havde den installeret en lille dampmaskine! Skibet var i øvrigt ikke særligt manøvredygtigt, og det sank i 1907.
ge en hammer, så ligner alle problemer søm”. Nogle har en tendens til udelukkende at løse problemer med de teknologier de nu en gang behersker (“Det vi har brug for her, er en større hammer”, [Senge99]). Det er også galt. Vi skal beherske så tilpas mange tek-nologier at vi er i stand til at vælge den bedst egnede til opgaven. Det er kompliceret, det her. Sammenlign i øvrigt med det multiperspektiviske syn – nogle har en tendens til at anskue verden ud fra et enkelt perspektiv. Så kender du kun til at bruge en ham-mer, bruger du “hammerperspektivet”.
2.5.2 Sølvkugler
I den mørke middelalders Transsylvanien – dengang ulvene tudede, bjørnene brølede og vampyrerne føg om ørerne på folk – mente folkeovertroen at man endegyldigt kun-ne dræbe en varulv ved at skyde den med en sølvkugle. Disse sølvkugler (eng.: silver bullet) er siden blevet synonyme med en enkeltstående, hurtig løsning på et slemt pro-blem (se [Brooks87]). Inden for it-verdenen har vi i tidens løb hørt om mange sådanne
“frelserteknologier”, f.eks.:
– CASE-værktøjer – Objektorientering (OO) – Genbrug og komponenter – Design Patterns
– Use Case-teknikken – Java
– XML
– eXtrem Programmering
Hver for sig udmærkede teknologier. Men fælles for dem er at ved deres fremkomst blev de udråbt som revolutionerende og med et potentiale til at løse (næsten) alle pro-blemer. Hvilket selvfølgelig er noget sludder. Så lad være med at tro at alle dine proble-mer med it-udvikling kan løses af én enkelt teknologi. Der er specielt grund til at tænke sig om ved anskaffelse af værktøjer. Det er før set at værktøjer er blevet oversolgt så nogle har fået det indtryk at de kunne løse flere problemer end tilfældet faktisk var.
Hvis man konsekvent halser efter de nyeste teknologier, kaldes det i spøg for Manage-ment by Buzzwords.
Som tidligere nævnt findes der heller ikke simple løsninger inden for projektledel-se. Hvis nogen prøver at bilde dig det ind, så lad være med at tro på dem. Det er og bli-ver kompliceret, det her.
2.5.3 Videndeling
Videndeling er vigtigt at beskæftige sig med som projektleder, og det vil vi kigge lidt på i dette afsnit.
Kan viden overhovedet deles?
I filmen The Matrix oplevede vi hvordan ny viden blev downloadet direkte ind i hjer-nen. Der går nok lige et par år før udviklerne kan dele deres viden på denne meget it-agtige måde. Spørgsmålet er om man i det hele taget kan dele sin viden med andre.
Viden er snarere noget som hver enkelt selv skal tilegne sig, og derfor er det også vig-tigt at man giver udviklerne muligheden for at tilegne sig hinandens viden. Det skal altså være politisk acceptabelt i virksomheden at man tilegner sig hinandens viden.
F.eks. gennem mesterlære (som i XP), gennem interne foredrag, gennem sparring og spørgen til råds, gennem review af hinandens kode osv.
Genbrug er besværligt
Dybe tallerkener er uhyre nyttige – ellers blev de vel heller ikke opfundet så tit. Der kan ligefrem gå sport i det. For mange it-udviklere er det i hvert fald en yndet beskæftigelse at genopfinde allerede kendte løsninger, og det er egentlig en skam, for det er både dyrt og forsinkende.
I ganske mange år har ordet genbrug været et magisk ord (en sølvkugle) blandt le-dere i it-branchen. Man så for sig hvordan udviklerne kunne spare enorme mængder af tid ved “blot” at genbruge tidligere udviklet kode i nye sammenhænge. Men efterhån-den har man indset at udviklernes iboende trang til tallerkenopfinding har stukket en effektiv kæp i hjulet for de altomfattende genbrugsbiblioteker. Dygtige udviklere ud-vikler hver for sig deres egne genbrugsbiblioteker hvorfra de klippe-klistrer kodestum-per og moduler. Men udviklerne imellem er det meget sværere. Dels skal man over psykologiske barrierer (NIH: Not Invented Here - det er ikke mig der har fundet på det). Dels skal man over økonomiske barrierer (det koster en del tid at gøre kode gen-brugelig). Og endelig skal man over tekniske barrierer (det er ikke helt let at organisere et genbrugsbibliotek så tingene faktisk er lette at genfinde). Derfor har kun ganske få virksomheder succes med genbrug ud over få standardmoduler.
NIH-syndromets modsætning er at man sætter en ære i at genbruge så meget som muligt: “Steal with pride, share with delight”.
Mønstre er viden
Midt i 1990’erne blev mønstrene (design patterns) heldigvis opfundet. Det er en metode
til at beskrive gode løsninger på bestemte problemer: – Når du står med dette problem, så er løsningen sådan-og-sådan. Og man satte oven i købet navn på. Nu kunne man høre udviklere snakke om et singleton-pattern, et observer-pattern osv. Hver udvikler behøvede nu ikke længere genopfinde de samme løsninger på de problemer som man tidligere havde opfundet udmærkede løsninger på. Det var et godt skridt i den rigtige retning. At det så er for få udviklere der sætter sig ind i de tilgængelige mønstre – ja, det er en helt anden sag. Hvis du vil gøre noget ved dette problem, kan du f.eks. lave en studiekreds hvor I hver gang diskuterer et bestemt emne som en af udviklerne så skal komme med oplæg til. Det er en god måde at holde hinandens viden ved lige på. I øvrigt taler man også om anti patterns som er mønstre for at gøre noget på den forkerte måde. Disse er f.eks. beskrevet i [Brown98] og [Brown00].
Lægerne bruger teknikken
Inden for andre erhverv er det velkendt at man deler sin viden til gavn for hinanden – og kunderne. F.eks. ser læger hinanden over skuldrene når de opererer. Noget der har sparet mange menneskeliv. Det er et eksempel på brug af den gamle mesterlære. Man betragter “Mesteren i arbejde” og lærer derved hvordan man selv skal gøre. Det er en effektiv teknik når man ikke er i stand til at sætte ord på sin viden. Sådan ordløs viden kaldes i øvrigt tavs viden eller implicit viden (i modsætning til den viden man kan skri-ve ned – den kaldes eksplicit viden).
It-udviklere i mesterlære
Den mest omtalte af de teknikker der tilsammen udgør eXtrem Programmering, er par-programmering: kode udvikles af to udviklere samtidig ved den samme skærm.
Og det er i realiteten en fantastisk måde at lære af hinanden på. God programmerings-skik er nemlig en vanskelig evne at sætte ord på. De fleste dygtige udviklere kan kende god programmering når de ser den. Men at beskrive det.... Derfor foregår der ekstremt meget videndeling når udviklerne benytter XP. Det forudsætter dog at det faktisk er god programmeringsskik der videreføres – og ikke unoder. Derfor er en vis rokering en god ide, så man lærer fra forskellige og ikke udelukkende fra den samme. Se i øvrigt [McConnell93] omkring god programmeringsskik.
Procesviden kan også deles
Vidensteoretikerne har en model som fortæller hvordan viden skabes i en stadig vek-slen mellem tavs og eksplicit viden. Man nedskriver, man læser og sammensætter fra flere kilder, man ser hinanden gøre tingene, man begynder selv at gøre dem:
– SOCIALISERING(eng.: Socialization). Tavs-tavs. Her videregives den tavse viden fra én person til en anden, uden at sætte ord på. Det er typisk for bl.a. mesterlæren hvor lærlingen ser hvordan mester gør. Jf. parprogrammering i XP.
– EKSTERNALISERING(eng.: Externalization). Tavs-eksplicit. Her sætter vi ord og begre-ber på den tavse viden, dvs. vi gør den eksplicit. Det sker f.eks. når man laver en soft-warehåndbog hvor man nedskriver de arbejdsgange vi hidtil blot har udført uden at tænke nærmere over det.
– KOMBINERING(eng.: Combination). Eksplicit-eksplicit. Her opstår nye måder at gøre tingene på ved at sammenstille andre. Det sker f.eks. når man i to projekter har gjort tingene på hver sin måde og så mødes og finder på noget helt tredje som tager det bedste fra de to andre. Det er f.eks. det vi gør under projektevalueringen.
– INTERNALISERING(eng.: Internalization). Eksplicit-tavs. Her bruger udviklerne den beskrevne, eksplicitte viden i praksis, og derved får de den ind under huden så den til sidst bliver en del af deres tavse viden – sådan gør vi altså her i huset.
Modellen stammer fra [Nonaka95] og kaldes SECI-modellen (efter forbogstaverne i de engelske betegnelser). Læring er den proces at viden bliver til erkendelse som bliver til kunnen.
Hvis udviklingsafdelingen begynder at få fokus på selve udviklingsprocessen, vil det at deltage i udviklingsprojekterne øge udviklernes viden om hvordan man laver god udvikling. Men det forudsætter altså lige en lille detalje: der skal være fokus på processen. Den skal diskuteres, den skal nedskrives, den skal bruges, den skal ændres.
Det er i øvrigt sådan man skaber de gode vaner som en projektkultur består af. En må-de at må-dele procesvimå-den på er gennem projektevalueringer. Når projektet er slut, evalu-erer projektgruppen hvordan det gik (se kapitlet om Projektevaluering på side 361). Og de positive og negative erfaringer formidles så til de udviklere som ikke selv var med i projektet. Det er nu heller ikke uden problemer. Bedst er det hvis man kan sætte navn på de “mønstre” man oplevede i projektet. Så kan udviklerne nemlig huske dem når de næste gang står i en lignende situation.
It som formidler af viden
Mange har forsøgt at understøtte videndelingsprocessen med it-systemer (SECI-model-lens eksternalisering). Det kaldes også Knowledge Management. Men ifølge sagens natur må den viden der gemmes i et it-system være eksplicit. Tavs viden kan selvsagt ikke repræsenteres i et it-system. Den eksplicitte viden kan derimod godt – og bliver det.
F.eks. viden om hvem der ved hvad. Dette benyttes i større organisationer hvor man ad
denne vej kan finde frem til kolleger som besidder viden inden for et bestemt felt. Men lige så snart man forsøger at overføre den konkrete viden med et it-system som mel-lemled, opstår problemerne. Det er hundesvært at lave en ordentlig beskrivelse og end-nu sværere at få den formidlet ind i hovedet på modtagerne så de faktisk bruger den.
Brug hinanden
It-udviklerne skal udnytte hinandens viden i langt højere grad end tilfældet er mange steder. Og i udviklingsafdelingerne skal man begynde at udbygge de processer der understøtter videndeling. Måske ligefrem stille krav om at man forsøger at bruge hinan-den. Der er store resurser gemt her. Både økonomisk og kvalitetsmæssigt. For slet ikke at tale om den menneskelige dimension: det er sjovt at tilegne sig ny viden. Og kan man oven i købet få den fra en god kollega, så er det med til at udbygge sammenholdet blandt udviklerne. Det optimale er at udviklerne i fællesskab kan skabe ny viden. F.eks. review af hinandens produkter, evaluering af projekterne og diskussion af gode løsninger.
To-timers-reglen
I en dansk elektronikvirksomhed har man indført en totimersregel som betyder at hvis en udvikler har forsøgt at løse et problem, men ikke har løst det inden for to timer, har vedkommende pligt til at få hjælp af en kollega. Flere par øjne ser ofte bedre end et par, og man mener her at det simpelthen er spild af virksomhedens tid hvis en medarbejder sidder alene og kæmper med et problem uden at komme videre. Især hvis en kollega kunne have givet en hjælpende hånd.
Her hjælper det i øvrigt meget hvis man har et godt og velplejet netværk. Folk er mere villige til at hjælpe hvis de på forhånd kender den som kommer og spørger efter hjælp.
Læs mere om videndeling på arbejdspladsen i [Bjerrum03].
2.6 Modenhed
Modenhed handler ikke kun om at være voksen og følsom. Det er i denne forbindelse en betegnelse der beskriver en virksomheds evne til at udvikle it-systemer – en evne der i øvrigt også omfatter de mere bløde kompetencer. I det følgende vil vi beskrive nogle af de modeller der ofte bruges i denne sammenhæng. Men bemærk at det er virk-somhedens modenhedsniveau der beskrives – ikke det udviklede system.