Prøv at læse ComputerWorld i dag - de har en artikel med titlen "Sådan indretter du det bedste it-kontor" (nej, ingen præcise links, for det kan danske dagblade ikke lide) - man skal godt nok igennem de første par sider for at komme igennem de fleste almindeligheder, men så kommer der også et par fine pointer.
En pointe er, at store kontorer gør det nemt at finde sammen for at samarbejde. Forudsat selvfølgelig, at man kan finde ud af at samarbejde i forvejen, for ellers begynder man bare at gå hinanden på nerverne, og i værste fald udarter der sig en "tyssekultur" (hvor er det dog et fedt ord!). Det er sandt - jeg har siddet i store kontorer, hvor vi kunne sidde hele projektet, og være os selv, sammen, og det var rigtigt godt. Men jeg har også siddet i kontorlandskab, hvor vi var adskillige projektet fordelt over flere forskellige afdelinger, og det var en pest.
En anden pointe er, at der ikke kun er brug for samarbejde, men også brug for plads til individuelt arbejde. Ja, tak! Her er man knapt så klar i spyttet, og svinger sig højest op til at mumle noget om plads til hjemmearbejdspladser. Det er efter min mening ikke godt nok - hjemmearbejde er efter min mening ikke ideelt; både fordi, at det er et skråplan at invitere arbejdet alt for permanent indenfor, der hvor man helst skulle have en helle - men også fordi at det simpelthen er for upraktisk. Ja, bevares, ikke et eneste ondt ord herfra om den fleksibilitet, som hjemmearbejdspladser giver - tvært imod - det er bare ikke løsningen på behovet for rum til individualitet. Der må kunne laves noget, som er bedre, og gerne noget, som man kan føle er ens eget, på samme måde, som kontorstolen og bordet er det i storrummet. Jeg tror snildt at en gruppe af mennesker vil kunne dele sådan et sted, bare det ikke bliver alt for mange.
En tredje pointe er, at der er behov for "projektrum" - det er ikke helt klart, om det skal tages bogstaveligt, og forstås som en ekstra lokale til projektet (hvilket absolut giver mening), eller om det mere er et spørgsmål om projektet også skal kunne rummes. Vigtigt er det i hvert fald med vægplads til alt hvad projektet behøver - opslagstavler, grafer, plakater, oversigter og fælles bøger: alt det, som ofte bliver ofret i storrummene for at få stoppet de sidste par personer ind, og for at lave plads til store vinduer med dagslys. Forstå det dog: vi har brug for vægplads! ... og det inkluderer også pladsen umiddelbart foran væggen - der kan ikke lige stå et skrivebord eller sidde en ekstra person med ryggen til; og heller ikke selvom han er ekstern konsulent, og kun er der tre dage om ugen.
Så storrumskontorer - ja, tak, for det er på mange måder en genial ide - men husk at der stadig skal være plads til at være individuel ... og aldrig på bekostning af vægpladsen og rummet til spontane møder (ellers samles vi på gangen eller foran kaffeautomaten - eller endnu værre, holder helt op med at mødes!).
tirsdag den 27. oktober 2009
søndag den 11. oktober 2009
Hvad kan vi nå...?
Der er vist et ordsprog siger siger, at hvis man prøver at jage to fugle, så får man ingen af dem. Jeg vil her prøve at tale om to ting, som begge har noget at gøre med hvor meget man kan nå (som nogle kalder det effektivitet eller velocity eller noget helt tredje...), og så håber jeg, at de er så beslægtede, at jeg får ram på i hvert fald noget af det.
Den første er den erkendelse, som vi vel alle kender, at når man skal koncentrere sig, så skal man have ro. Det er derfor, at der er stille på bibliotekets læsesal, og det er derfor, at vi som studerende lukkede os inde på vores værelser, når vi skulle have noget fra hånden. Jeg ynder selv at bruge metaforen, at vi bygger mentale korthuse - med den prøver jeg dels at ramme det faktum, at man ikke kan bygge et korthus halvhjertet: det kræver fuld koncentration - men også at det hele kan ramle sammen selv ved små udefra kommende forstyrrelser: en tilfældig vind fra en dør som bliver åbent, eller en uforsigtig person, som lige snitter bordet, hvor korthuset står på ... der skal ikke meget til.
Jeg har tidligere blogget lidt om ready-ready, hvor jeg dengang hæftede mig ved det faktum, at ting skulle være i orden og helt klar, inden man gik i gang. Men jeg har også haft lejlighed høre Carsten fortælle om sin artikel, og han pegede også på, at det var vigtigt at kunne gøre det færdig, som man var gået i gang med. Eller med andre ord, at det ikke var nok, at alle opgaver var klar - det var også vigtigt, at der ikke blev skiftet hest i vadestedet flere gange undervejs.
Der er en erkendelse, som andre også er kommet frem til: i denne artikel fra Coding Horror fortælles om den dramatiske nedgang i opgaveløsningsevnen der kommer, når man prøver at multitaske - og i denne artikel fra Software Nation diskuteres begrebet "flow", og det faktum at flow-stilstanden kan brydes på et øjeblik, men som tommelfingerregel tager i omegnen af et helt kvarter at skabe - der skal mao. ikke mange forstyrrelser til på en dag førend megen god tid er blevet tabt.
Derfor ser man også tit, at folk med behov for at koncentrere sig prøver at skabe lommer af ro i løbet af dagen, f.eks. ved at møde tidligt, blive sent eller ved at tage hovedtelefoner på. Nogle kan også formå at komme i en zen-lignende trance, som gør at de virker distræte og tabt for omverdenen.
Ud fra ovenstående er det oplagt, at jo mere ro, jo bedre, men det er desværre ikke så simpelt. Meget af det, som vi i dag går og laver, er blevet så kompliceret, at det kræver andres hjælp - en hjælp, som vi har brug for, for ikke at få brudt vores flow, men som samtidig gør, at vi bliver nød til at bryde andres flow.
At diskutere hvad, der vil være den rette balance, er bestemt også interessant, men faktisk vil jeg ikke gå længere her, end til at konstatere, at ro og kontinuitet hhv. forstyrrelser og afbrydelser er en betydelig faktor i forståelsen af, hvor meget man kan nå.
Det er vel en af grundene til, at man ser mange gå væk fra at estimere i timer, for ingen timer er ens: et timeestimat indeholder både et gæt på opgavens kompleksitet og et gæt på den forventede produktivitet. En bedre måde at estimere på vil være, at fokusere på kompleksitet og effektivitet som to forskellige størrelser.
Kompleksitet kan man måle i idealtimer (hvor lang tid skal en uforstyrret udvikler bruge), og derefter lave en forholdsmæssig reduktion for, hvad forstyrrelser betyder - en tommelfingerregel siger, at der kan leveres 6 effektive timer på en 7½ times arbejdsdag, men det afhænger meget af forstyrrelsernes karakter og omfang, så det kan til tider være væsentligt mindre (i parentes skal bemærkes, at denne størrelse godt kan blive selvrefererende, for i virkeligheden vil det feedback som kommer i kraft af vundne erfaringer gøre, at man efter nogen tid ikke længere arbejder med "idealtimer", men derimod med "den slags timer, som der er seks af på en dag med de sædvanlige forstyrrelser" ... men det er en anden snak).
Andre går skridtet videre, og frigør helt kompleksitet fra fysisk eller virtuel tid, for vi har alle forskellige forudsætninger (og forskellighed kendetegner netop et godt team, for så kan man supplere hinanden). Forskelligheden betyder f.eks., at det er helt naturligt, at jeg kan se på en opgave og tænke "10 dage", mens mine kollegaer tænker "2 dage" hhv. "5 dage" - og vi kan alle have ret, hver for sig. Derfor vil man ofte i stedet prøve at estimere i relative størrelser af sammenlignelige opgaver - det være sig "storypoints" eller "gummibamser" eller hvad man nu finder på - pointen er, at ved at frigøre sig fra noget, som a priori har en fast betydning, så kan man i stedet blive enige om en fælles relativ reference.
Godt - hvis vi nu lige for argumentet skyld lige antager, at der er helt styr på det med vurdere, hvor lang tid noget tager, så er der faktisk endnu en usikkerhed, som jeg tit oplever at man overser: nemlig hvor meget tid, som rent faktisk står til rådighed.
Det mentale trylletrick som oftest laves, er at antage at alle er der fuld tid, medmindre at de holder fri eller er på heldags kursus el.lign ... og det er faktisk ofte på langt sigt og i det store og hele et meget godt gæt (som så også er regnet ind i antagelsen om en 6 effektive timer på en dag). Men det er et gæt, på samme måde som vi ovenfor gættede på produktiviteten.
I og med at det er et gæt, så er det faktisk interessant at måle på den på samme måde som fremdrift måles. Skyldes den faktiske fremdrift f.eks. høj produktivitet kombineret med korte dage og sygdom, eller er det lav produktivitet med lange dage og en helt usædvanlig sygdomsfri periode?
Har man let adgang til løbende registrering af timeforbrug, så kan det derfor være interessant at plotte en kurve over et "faktisk effort burndown" plottet op imod det "planlagte effort burndown", som jo findes på alle burndowncharts. Og hvis adgangen til faktisk forbrug ikke er så let, så er det såmænd også meget fint bare at tage totalen med i de jævnlige revurderinger (f.eks. ifm. retrospektiv). For på samme måde, som det er interessant at diskutere, hvor megen "kompleksitet", som man nåede i forhold til planen, så er det også ganske interessant at diskutere, hvor god planen var. Er niveauet stabilt, så bliver der ikke så meget at snakke om, men ændrer det sig, så kan det være, at der er forhold som kræver opmærksomhed.
Opsummerende, så kan man sige, at spørgsmålet om, hvad man kan nå afhænger af (mindst) tre faktorer:
Den første er den erkendelse, som vi vel alle kender, at når man skal koncentrere sig, så skal man have ro. Det er derfor, at der er stille på bibliotekets læsesal, og det er derfor, at vi som studerende lukkede os inde på vores værelser, når vi skulle have noget fra hånden. Jeg ynder selv at bruge metaforen, at vi bygger mentale korthuse - med den prøver jeg dels at ramme det faktum, at man ikke kan bygge et korthus halvhjertet: det kræver fuld koncentration - men også at det hele kan ramle sammen selv ved små udefra kommende forstyrrelser: en tilfældig vind fra en dør som bliver åbent, eller en uforsigtig person, som lige snitter bordet, hvor korthuset står på ... der skal ikke meget til.
Jeg har tidligere blogget lidt om ready-ready, hvor jeg dengang hæftede mig ved det faktum, at ting skulle være i orden og helt klar, inden man gik i gang. Men jeg har også haft lejlighed høre Carsten fortælle om sin artikel, og han pegede også på, at det var vigtigt at kunne gøre det færdig, som man var gået i gang med. Eller med andre ord, at det ikke var nok, at alle opgaver var klar - det var også vigtigt, at der ikke blev skiftet hest i vadestedet flere gange undervejs.
Der er en erkendelse, som andre også er kommet frem til: i denne artikel fra Coding Horror fortælles om den dramatiske nedgang i opgaveløsningsevnen der kommer, når man prøver at multitaske - og i denne artikel fra Software Nation diskuteres begrebet "flow", og det faktum at flow-stilstanden kan brydes på et øjeblik, men som tommelfingerregel tager i omegnen af et helt kvarter at skabe - der skal mao. ikke mange forstyrrelser til på en dag førend megen god tid er blevet tabt.
Derfor ser man også tit, at folk med behov for at koncentrere sig prøver at skabe lommer af ro i løbet af dagen, f.eks. ved at møde tidligt, blive sent eller ved at tage hovedtelefoner på. Nogle kan også formå at komme i en zen-lignende trance, som gør at de virker distræte og tabt for omverdenen.
Ud fra ovenstående er det oplagt, at jo mere ro, jo bedre, men det er desværre ikke så simpelt. Meget af det, som vi i dag går og laver, er blevet så kompliceret, at det kræver andres hjælp - en hjælp, som vi har brug for, for ikke at få brudt vores flow, men som samtidig gør, at vi bliver nød til at bryde andres flow.
At diskutere hvad, der vil være den rette balance, er bestemt også interessant, men faktisk vil jeg ikke gå længere her, end til at konstatere, at ro og kontinuitet hhv. forstyrrelser og afbrydelser er en betydelig faktor i forståelsen af, hvor meget man kan nå.
Det er vel en af grundene til, at man ser mange gå væk fra at estimere i timer, for ingen timer er ens: et timeestimat indeholder både et gæt på opgavens kompleksitet og et gæt på den forventede produktivitet. En bedre måde at estimere på vil være, at fokusere på kompleksitet og effektivitet som to forskellige størrelser.
Kompleksitet kan man måle i idealtimer (hvor lang tid skal en uforstyrret udvikler bruge), og derefter lave en forholdsmæssig reduktion for, hvad forstyrrelser betyder - en tommelfingerregel siger, at der kan leveres 6 effektive timer på en 7½ times arbejdsdag, men det afhænger meget af forstyrrelsernes karakter og omfang, så det kan til tider være væsentligt mindre (i parentes skal bemærkes, at denne størrelse godt kan blive selvrefererende, for i virkeligheden vil det feedback som kommer i kraft af vundne erfaringer gøre, at man efter nogen tid ikke længere arbejder med "idealtimer", men derimod med "den slags timer, som der er seks af på en dag med de sædvanlige forstyrrelser" ... men det er en anden snak).
Andre går skridtet videre, og frigør helt kompleksitet fra fysisk eller virtuel tid, for vi har alle forskellige forudsætninger (og forskellighed kendetegner netop et godt team, for så kan man supplere hinanden). Forskelligheden betyder f.eks., at det er helt naturligt, at jeg kan se på en opgave og tænke "10 dage", mens mine kollegaer tænker "2 dage" hhv. "5 dage" - og vi kan alle have ret, hver for sig. Derfor vil man ofte i stedet prøve at estimere i relative størrelser af sammenlignelige opgaver - det være sig "storypoints" eller "gummibamser" eller hvad man nu finder på - pointen er, at ved at frigøre sig fra noget, som a priori har en fast betydning, så kan man i stedet blive enige om en fælles relativ reference.
Godt - hvis vi nu lige for argumentet skyld lige antager, at der er helt styr på det med vurdere, hvor lang tid noget tager, så er der faktisk endnu en usikkerhed, som jeg tit oplever at man overser: nemlig hvor meget tid, som rent faktisk står til rådighed.
Det mentale trylletrick som oftest laves, er at antage at alle er der fuld tid, medmindre at de holder fri eller er på heldags kursus el.lign ... og det er faktisk ofte på langt sigt og i det store og hele et meget godt gæt (som så også er regnet ind i antagelsen om en 6 effektive timer på en dag). Men det er et gæt, på samme måde som vi ovenfor gættede på produktiviteten.
I og med at det er et gæt, så er det faktisk interessant at måle på den på samme måde som fremdrift måles. Skyldes den faktiske fremdrift f.eks. høj produktivitet kombineret med korte dage og sygdom, eller er det lav produktivitet med lange dage og en helt usædvanlig sygdomsfri periode?
Har man let adgang til løbende registrering af timeforbrug, så kan det derfor være interessant at plotte en kurve over et "faktisk effort burndown" plottet op imod det "planlagte effort burndown", som jo findes på alle burndowncharts. Og hvis adgangen til faktisk forbrug ikke er så let, så er det såmænd også meget fint bare at tage totalen med i de jævnlige revurderinger (f.eks. ifm. retrospektiv). For på samme måde, som det er interessant at diskutere, hvor megen "kompleksitet", som man nåede i forhold til planen, så er det også ganske interessant at diskutere, hvor god planen var. Er niveauet stabilt, så bliver der ikke så meget at snakke om, men ændrer det sig, så kan det være, at der er forhold som kræver opmærksomhed.
Opsummerende, så kan man sige, at spørgsmålet om, hvad man kan nå afhænger af (mindst) tre faktorer:
- Opgavens omfang (kompleksitet)
- Vilkårene for dens løsning (effektivitet, eller kompleksitet i forhold til forbrugt tid)
- Ressourceudnyttelse (efficiens, eller forbrugt tid i forhold til planlagt tid)
Abonner på:
Opslag (Atom)