Prosessrapport

Torbjørn Aase  Andreas Bertheussen  Rune Holmgren  Sigurd Holsen  Jostein Munz

30. april 2014

Innhold

2 Prosessrapporten skal beskrive hvordan gruppeprosessen har innvirket på prosjektarbeidet, og hva den enkelte har lært om samspillet i gruppa. Prosessrapporten er et refleksjonsskriv, og skal formidle hva den enkelte har erfart og lært av relevante situasjoner fra samarbeidet om prosjektet. Hvilke tanker, refleksjoner og atferdsendringer resulterer erfaringene i? Tanker og perspektiver fra den enkelte utgjør et mangfold i gruppa, og hvordan danner dette mangfoldet utgangspunkt for samhandlingen?

Prosessrapporten skal ta utgangspunkt i situasjonsfortellinger og refleksjoner over samarbeidet slik det utspiller seg i gruppa. På den måten skal prosessrapporten synliggjøre hvordan den enkeltes handlingsmønster og væremåte har innvirket på prosjektarbeidet.

Rapporten skal være inntil 25 sider

2-4 situasjoner, hvis de er fra forksjellige perioder i prosjektarbeidet kan de til sammen vise utvikling i gruppa.

temaer er oppgavefordeling og atferd, hvordan informasjon deles, hvordan beslutninger tas, hvordan vanskelige beslutninger/tema ble tatt tak i

1 Innledning

Denne prosessrapporten er skrevet av gruppe 3 i landsby "Instrumentering og styring over Internett". Prosessrapporten er én halvdel av det avsluttende arbeidet i emnet Eksperter i Team"ved NTNU, våren 2014.

Rapporten består av tre deler. I introduksjonen presenterer vi gruppas medlemmer, våre personlige egenskaper, vår faglige kompetanse og hvordan vi har jobbet sammen i løpet av semesteret. I seksjonen om siuasjoner tar vi for oss flere hendelser kategorisert innenfor to tema som har vært utfordringer for gruppa; rutiner og disiplin, og misforståelser. Vi beskriver og reflekterer rundt situasjonene som oppstod, og vurderer resultatet av tiltakene våre. I tredje og siste del tar vi for oss et sammendrag av vår utvikling og læringsutbytte, både individuelt og som gruppe. Vi vurderer gruppas ytelse i forhold til situasjoner som oppstod og ser på hvordan samarbeidsindikatorene våre har endret seg.

2 Introduksjon

2.1 Sosiale og faglige forutsetninger

Her presenterer vi gruppas medlemmer for å vise hvilke bakgrunner vi har, hvilke erfaringer vi har fra tidligere og hvordan vår innstilling til eksperter i team er.

Torbjørn Aase

Linje  Informatikk
Styrke  Erfaring med programmering og nettverk
Svakhet  Kan mangle initiativ

Erfaring fra teamarbeid Arbeidet mye i team gjennom flere lignende prosjekter tidligere, både større og mindre.

Innstilling til emnet før start Har hørt både gode og dårlige ting om faget fra studenter som har hatt det før. Omtrent like mye positivt som negativt, så forventingene er ganske nøytrale. Velger likevel å være håpefull når det kommer til læringsutbytte og trivsel i faget.

Andreas Bertheussen

Linje  Elektronikk
Styrke  Liker struktur og orden
Svakhet  Liker å gjøre ting på egen måte

Erfaring fra teamarbeid Har jobbet i tverrfaglige grupper med Bachelor hovedoppgave og i jobbsammenheng

Innstilling til emnet før start Hadde hørt mye negativt om emnet, men jeg startet med en positiv innstilling. Jeg håpet gruppa kom greit overens, og at alle kunne bidra.

Rune Holmgren

Linje  Datateknologi

Styrke Kreativ og initiativrik utvikler med bred erfaring innenfor mange felter av program- og hardwareutvikling.

Svakhet Sliter med å se styrkene i andres ideer, selv om de ofte kan være bedre løsninger.

Erfaring fra teamarbeid Har en rekke kurs og erfaringer rundt ledelse i idrettssammenhenger. Forøvrig er også en rekke verv i studentorganinsasjoner verdt å nevne.

Innstilling til emnet før start Jeg hadde hørt fra mange at faget var så dølt og kjedelig at jeg heller burde utveksle for å slippe det. Jeg hadde likevel gode forhåpninger da jeg kom inn i en landsby som virket interessant.

Sigurd Holsen

Linje  Ingeniørvitenskap og IKT - Marin Kybernetikk
Styrke  Strukturert og har mye erfaring med programmering
Svakhet  Litt lett for å avbryte folk

Erfaring fra teamarbeid Har hatt flere prosjekter i tidligere fag, men ikke med like mange deltagere

Innstilling til emnet før start Hørt både gode og dårlige ting ved faget. Har en ganske nøytral innstilling til faget, men er meget fornøyd med landsby.

Jostein Munz

Linje  Kybernetikk
Styrke  God kjennskap til robotikk, og kjent med nettverksprogrammering
Svakhet  Lett for å bli distrahert.

Erfaring fra teamarbeid Har jobbet i grupper i tidligere prosjekter, men vanligvis i mindre grupper en dette

Innstilling til emnet før start Ganske positivt innstilt, med ønske om å få gjort noe praktisk. Har hørt forskjellige skrekkhistorier om andre som har tatt faget, men jeg tror at så lenge vi har en oppgave der vi kan bidra til så går det greit.

2.2 Kompetansetrekant

I løpet av første landsbydag, og starten på prosessen med å bli kjent, laget gruppemedlemmene en kompetansetrekant. Dette gjorde vi først ved å individuelt beskrive oss selv med tre punkter innenfor hvert av temaene: Personlige egenskaper, Praktisk kompetanse og Teoretisk kunnskap. Disse 9 punktene fra hver av deltakerne kombinerte vi så til en felles kompetansetrekant. Punktene som ble valgt er de vi trodde kom til å bli viktige for oss, før oppgaven ble valgt.

Figur 1: Kompetansetrekant

Valgte stikkord i kompetansetrekanten er åpent for forslag.

Ut fra gruppemedlemmenes faglige kunnskap, styrker og erfaringer mente vi gruppa hadde et godt grunnlag for å definere en oppgave der alle kunne bidra, og som ville gi et godt sluttresultat. Av felles kunnskap har alle på gruppen mye erfaring med programmering. Samtidig var alle i gruppa innstilte på å lage et produkt, noe som gav et godt grunnlag for å bli enige om en oppgave.

Fra kompetansetrekanten, og ved å se på hvilke linjer gruppemedlemmene kommer fra, ser vi at gruppen vår er forholdsvis homogen. Alle i gruppa er teknisk anlagte, og har et greit grunnlag for å forstå hverandres fagfelt. Med andre ord har vi en lav grad av tverrfaglighet.

Det kan forventes [?] at en homogen gruppesammensetning har lettere samhold, mindre konflikt og er best egnet for korttidsgrupper. Ulempen er at en homogen gruppe ofte er mindre innovativ og har tilgang til et mye mer snevert perspektiv enn en heterogen gruppe. Dette er gode nyheter for gjennomføring av prosjektoppgaven men ikke fullt så godt for prosessdelen av eksperter i team, fordi konflikter og håndteringen av dem er en viktig del av gruppedynamikk.

2.3 Arbeidsmetodikk

De første fire landsbydagene gikk med til diverse øvelser for å bli kjent, utarbeiding av en samarbeidsavtale (vedlegg ??), og forslag til problemstillinger presentert av to bedrifter. Etter vi var enige om hva vi skulle jobbe med på fjerde landsbydag, gikk vi gjennom systemet vi skulle lage for å bli enige om hvordan systemet vi ønsket å lage, skulle fungere. Systemet ble delt opp i flere delsystemer slik at vi hadde delsystemer vi hver var ansvarlige for, som vi kunne begynne å utvikle.

Prosjektoppgaven som vi valgte var forholdsvis programmeringstung, og alle delsystemene som vi skulle lage bestod av programvare. Dette ble valgt fordi programmering var en sentral kompetanse i gruppa. Implementasjon av programvaren (dvs programmeringen) er en oppgave som typisk alternerer mellom fokusert arbeid uten for mange avbrytelser, og kommunikasjon med de andre i gruppa for å stille spørsmål , diskutere idéer eller melde om hva status på arbeidet er.

I landsbydagene etter at oppgave var valgt, startet vi alltid landsbydagene med et kort morgenmøte. I dette møtet tok vi en runde på hvor opplagte vi var for jobbing. Vi tok også opp hva vi planla å jobbe med rent teknisk, og hvilke ting vi var usikre på der vi kanskje kunne trenge hjelp.

Hver landsbydag ble avsluttet med å skrive en grupperefleksjon. Utgangspunktet for vår refleksjonsprosess var SITRA-modellen [?]. Formålet med grupperefleksjonen er å bli bevisst på gruppas samarbeid ved å ta opp situasjoner, diskutere teori, reflektere og eventuelt vurdere om vi burde ta en aksjon. Grupperefleksjonene tok omtrent én time, der vi startet med å notere våre egne observasjoner og refleksjoner om oss selv, om andre og om gruppa. Deretter tok vi en gjennomgang der vi presenterte observasjonene/refleksjonene og noterte dem ned og grupperte dem i situasjoner. Til slutt reflekterte vi rundt hver situasjon, og skrev refleksjonsnotatet.

3 Situasjoner

Mulig denne overskriften er unødvendig og bør erstattes med en oveskrift for hver situasjon som beskrives

Hoveddelen er hvor innholdet i innledningen skal fylles med mening. Opplevelser i gruppa skal beskrives og reflekteres rundt. Der dere vever inn teori må dere være nøye med å referere, slik at leseren forstår hvor du har hentet ditt teoretiske perspektiv fra. Det bør være en logisk progresjon i hoveddelen mot de poengene som skal belyses. Hoveddelen inndeles ofte i ulike bolker som skilles fra hverandre med mellomoverskrifter.

Analysen av en situasjon bør inneholde:

- Det enkelte gruppemedlems opplevelse av egne og andres handlingsmønstre og væremåte i situasjonen

- Gruppas refleksjon over hvor hensiktsmessig de forskjellige handlingene i situasjonen var

- Gruppas refleksjon over hvordan gruppemedlemmene gav tilbakemeldinger til hverandre om situasjonen

Aksjoner for å bedre samarbeidet kan være:

- Gruppa endrer handlingsmønster som et resultat av refleksjon over en situasjon i gruppa

- Gruppa viderefører og forsterker et tiltak som stimulerer samarbeidet ut fra en analyse av hvorfor tiltaket fungerer i gruppa

Merk at evnen til å sette i verk aksjoner for å bedre prosjektsamarbeidet er et viktig moment i vurderingskriteriene. Å gjennomføre aksjoner er en nødvendig forutsetning for å oppnå karakteren A.

Prosessrapporten bør inneholde en refleksjon over hvordan dere la til rette for deling av egen kompetanse. Det er også viktig å påvise at dere hadde et samarbeidsklima i gruppa hvor alles fagkompetanse ble verdsatt.

I denne delen av rapporten ønsker vi å fokusere på konkrete hendelser og situasjoner som oppsto underveis i prosjektet. Situasjonene som blir presenterte her utgjør ikke en helhetlig representasjon av hendelsesforløpet i prosjektarbeidet, men er situasjoner som vi mener har vært med på å forme arbeidet vårt videre. De er valgt ut for å vise gruppas fremgangsmåte og tankegang i forhold til å reflektere over situasjoner og, på bakgrunn av dette, foreta aksjoner for å forbedre samarbeidet.

3.1 Rutiner og disiplin

3.1.1 Avsporinger og rot (andre og tredje landsbydag)

De første landsbydagene ble brukt til å bli kjent og til å definere en egnet oppgave. Oppgaven burde både dra nytte av hver vår individuelle kompetanse, erfaring og interesser, og burde være gjennomførbar på tiden vi har til rådighet.

Andre landsbydag gikk i stor grad bort til bedrifter som presenterte sine oppgaver, etterfulgt av omtrent tre timer der vi diskuterte mulighetene for prosjektoppgaven. Vi spilte ut forskjellige ideer til teknologier og mulige systemer vi kunne lage. Disse ideene diskuterte vi fortløpende. Alle i gruppa var ivrige på å finne noe moro å jobbe med som var artig å vise frem, og til å fortelle om artige prosjekter som vi hadde vært med på tidligere. I grupperefleksjonen ved avslutningen av tredje landsbydag kommenterte Andreas at "det har vært lett for gruppa å spore av". Resten av gruppa var enig, og vi forsøkte å forklare avsporingene ved at vi var trøtte og hadde lite vilje til å jobbe fokusert etter bedriftspresentasjonene som ikke vekket noen spesiell interesse.

Tredje landsbydag fortsatte vi med å finne en oppgave. Vi utelukket forslagene fra de to bedriftene, men fortsatte med samme måte å arbeide på. Ved slutten av denne dagen hadde vi lagt merke til det samme som forrige landsbydag. Andreas kommenterte:

Det har også i dag vært vanskelig å holde en felles fokus, det har vært rotete og vi har sporet av og ikke kommet back-on-track. Det som vi sporet av til var relevant til prosjektet og ting vi burde diskutere, men vi kom ikke tilbake til den opprinnelige diskusjonen, og vi tok ingen beslutninger.

Det var tydelig at vi ikke hadde vært bevisste på det vi kommenterte i forrige grupperefleksjon. I refleksjonsnotatet for tredje landsbydag skrev vi:

Under dette arbeidet slet gruppa litt med å være fokusert sammen på et tema av gangen uten å spore av. Ofte ville et eller flere medlemmer falle av i et sidespor av temaet, og da mistet gruppa fokus.

Å ta diskusjonen om oppgaven i plenum var et naturlig valg. Retningslinje 5 for effektive grupper fra [?, p. 25] sier at avgjørelser bør tilpasses til situasjonen, og at den mest effektive måten å nå en beslutning er ved konsensus i gruppa. Dette fordi det gir alle et eierskap til oppgaven og oppfordrer til samhold og engasjement.

Vi mente dette var et problem med disiplin. Når vi tok det opp i grupperefleksjonen, hadde alle i gruppa lagt merke til det, men ingen hadde tatt styringen. En årsak er at alle gav full fokus til den tekniske delen av prosjektet, og brukte liten tid til å vurdere hvordan vi jobbet. En annen årsake er at vi var usikre på hverandre og ikke ønsket å avbryte diskusjonen - det vi pratet om var jo relatert til prosjektet.

Som et tiltak ble vi enige om å opprette rollen ordstyrer, som skulle passe på at felles diskusjoner ikke sporet av. Et resultat av dette er at vi også etablerer en norm om at det er greit å avbryte når man synes diskusjoner begynner å vingle. I de etterfølgende landsbydagene tok Sigurd, Jostein og Andreas rollen som ordstyrer. I flere tilfeller tok ordstyrer tak og korrigerte avsporinger. Etter hvert tok alle initiativ til å få diskusjonen tilbake på spor, uten å være utnevnt ordstyrer. Refleksjonen hadde gjort oss alle bevisst på problemet, og vi opprettet en norm om at denne typen avbrytelse er greit. Det å etterhvert gå bort ifra en eksplisitt utnevnt ordstyrer, var også mulig fordi prosjektarbeidet vårt endret karakter etter at planlegginsfasen var over. I begynnelsen foregikk all arbeidet i åpne gruppesamtaler, men etterhvert foregikk mer i undergrupper det det var mindre tendens til avsporing. Vi ser på tiltaket som meget vellykket, og har mange tilfeller der avsporinger raskt blir påpekt og gruppa blir satt tilbake på spor.

3.1.2 Lunsjtid (femte landsbydag)

De første ukene av faget hadde vi problemer med at vi manglet klare rettningslinjer for hvor lenge vi skulle ta lunsj. Vi innså ikke at dette var et problem i starten fordi folk gjorde jobben sin og vi fikk arbeidet gjort. Det var først under 5. lansbydag, da fasilitatorene ønsket å snakke med oss samlet at vi merket behovet for å ha kontroll på lunsjtider. Denne dagen hadde nemlig noen gruppemedlemmer tatt en kort lunsj, mens andre fra gruppa var andre steder på campus uten avtale om når vi skulle møtes. Dette resulterte i en liten halvtime der de som var tilstede var ute av stand til å redegjøre for resten av gruppa.

Dette var i utgangspunktet ikke noe problem da vi la merke til det, fordi alle jobbet godt, og fordi vi ikke var spesielt avhengige av hverandre for å jobbe denne dagen. Dette kunne lett bli et problem en annen dag, og vi ble derfor enige om å planlegge når vi skulle ta lunsj og når vi skulle være tilbake, en stund før vi faktisk gikk for å spise.

3.1.3 Forsentkomming (13. landsbydag)

I den første delen av prosjektet var punktlig oppmøte ikke et problem. Etterhvert som gruppemedlemmene begynte å ha arbeidsoppgaver der de ikke hadde behov for resten av gruppa, oppstod det imidlertid et litt mer avslappet forhold til det å komme noen minutter for sent. De første forsentkommingene var 10-15 minutter lange og ble forklart som enten at en forsov seg, ikke nådde bussen, eller at bussen var forsinket. Vi hadde ikke noen planlagt måte å håndtere forsentkomming, og vi lot det normalt gå fordi forsinkelsene var såpass korte. Typen arbeid vi hadde var også slik at vi hadde arbeid vi kunne gjøre individuelt, uten å være avhengige at alle var til stede. Det som ble forsinket var innsjekk-prosessen, men når alle hadde kommet var denne raskt unnagjort.

Det var på 13. landsbydag at både Rune og Jostein forsov seg en hel time. Andreas hadde meldt fravær i forkant, slik at Sigurd og Torbjørn satt alene. Først etter en halv time ringte Sigurd til Rune og Jostein. Rune var da på vei til skolen, mens Jostein sov.

Dette problemet ble tatt opp 14. landsbydag og det ble konkludert at dette var uakseptabelt, spesielt fordi prosjektet var i en kritisk fase der vi måtte jobbe tett sammen og kunne ikke miste tid. Som tiltak måtte de som visste de hadde lett for å forsove seg, gjøre tiltak for å sørge for at de våknet, og vi i gruppa skulle ringe de som manglet 5 minutter etter avtalt oppmøtetid. Vi bestemte også at de som visste at de kom til å bli forsinket, måtte sende en melding om dette, og når de regnet med å kunne komme.

Etter tiltaket, det ble merkbarte færre forsentkomminger. Det kan derimot diskuteres om denne aksjonen kom tidlig nok. Dette kan knyttes opp mot Schwarz grunnregel nr. 8 om diskutering av følsomme temaer. Forsentkomming er ikke like vanskelig å snakke om som eksempelvis dårlig ytelse/arbeid, men heller ikke noe lett tema. Det ble imidlertidig tatt fint av de det gjaldt, og det viste seg å være en produktiv samtale.

3.1.4 Lekser

Vi hadde i løpet av de første par ukene av prosjektet problemer med at folk ikke fikk gjort arbeid de var ment å skulle ha klart til uken etter. Dette problemet var størst på oppgaver som var relatert til prosess-delen av eksperter i team, og ikke den tekniske prosjektoppgaven vi hadde. Ofte var det ikke fordi noen med vilje hadde unlatt å gjøre det, men heller at de hadde utsatt og glemt det. Eksperter i team er arbeid som stort sett blir jobbet med med og unnagjort på den ene landsbydagen i uka, som gjør det lettere å mentalt parkere enn andre emner som er spredt over flere dager. Alikevel må vi forvente at vi gjør leksene våre, og som tiltak valgte vi å sende påminnelser om leksene våre litt før neste landsbydag.

Dette tiltaket fungerte ganske godt. Ved å sende en påmindelse hver uke ble vi gjort mer oppmerksom på hva som måtte gjøres og vi kom litt ut av den mentale parkeringen. Nest landsbydag hadde alle gjort alt de skulle. ok?

3.2 Misforståelser

3.2.1 Misforståelse mellom Andreas og Jostein (sjette landsbydag)

Da vi var enige om oppgaven fjerde landsbydag, hadde vi satt i gang og definert hvordan hele systemet skulle teknisk sett løses. Dette gjorde vi i plenum der vi fikk ansvar for en del av systemet og foreslo mulige løsninger. Denne delen av arbeidet var preget av at vi var ivrige, og følte at vi hadde dårlig tid. Andreas hadde foreslått teknologivalget for nettverkslaget i systemet vårt, og Andreas og Jostein skulle begynne å få henholdsvis klient- og serverdelen av systemet til å fungere. For å spare tid var det ønskelig å finne et programvarebibliotek som innoholdt det vi hadde behov for, fremfor å utvikle noe selv.

Fra femte til sjette landsbydag skulle Jostein forsøke å finne et bibliotek som passet, og brukte lang tid på et bibliotek som viste seg å ikke være brukbart. Dette oppdaget vi først midt i sjette landsbydag, og kom av en misforståelse av hvordan teknologiene vi hadde valgt skulle fungere i system.

Vi tok opp misforståelsen under grupperefleksjon, men reflekterte ikke så mye om det, utover at Jostein sa han ikke hadde satt seg nok inn i teknologien. Misforståelsen oppstod veldig tidlig i arbeidet, og vi tok den ikke så alvorlig. Da Andreas og Jostein hadde avklart hvordan det skulle fungere, fortsatte Jostein med sin del av nettverkslaget, og Andreas fortsatte med den andre.

3.2.2 Misforståelse mellom Jostein og Sigurd (niende landsbydag)

Nettverkslaget til Jostein (med hjelp fra Andreas) skulle kombineres med driveren som Sigurd jobbet med. Dette arbeidet ble startet niende landsbydag. Det viste seg raskt at det var en misforståelse mellom Sigurd og Jostein på hvordan delarbeidet deres skulle kombineres - om Jostein sitt arbeid skulle bli en del av programmet til Sigurd eller motsatt. Det var også misforståelse om hvorvidt Sigurd skulle implementere en bit av nettverkslaget og Jostein skulle lage resten - eller om Jostein skulle lage alt relatert til nettverk. Denne misforståelsen kom både av at vi ikke hadde gått gjennom disse detaljene i plenum da vi planla systemet og Andreas foreslo teknologien. Vi var blitt enige om hvor hva vi skulle starte å jobbe med, men vi hadde ikke diskutert hvordan delsystemene skulle kombineres.

Sigurd hadde i utgangspunktet trodd at han skulle jobbe med en bit av nettverkslaget, og sa:

Jeg synes ikke vi har en dårlig løsning, men diskusjonen valg av teknologien hadde vært interressant å bli med på.

Andreas mente heller at det største problemet som førte til misforståelsen ikke var valget av teknologi, men heller hvor detaljert vi gikk gjennom den foreslåtte teknologien. Andreas bemerket:

Vi foreslo jo teknologier som vi var kjente med og som vi visste vi kunne få til å fungere. Det større problemet var at vi ikke diskutere hvordan de fungerte i detalj før vi satte i gang.

Misforståelsen ble på kort sikt løst etter Andreas gikk igjennom hvordan teknologien fungerte med Jostein og Sigurd, og Sigurd og Jostein ble enige om hvordan deres systemer skulle kombineres i ett.

3.2.3 Håndtering av misforståelser (12. landsbydag)

Etter mer fremdrift i arbeidet måtte resten av systemene vi jobbet på kombineres og testes. Denne delen av arbeidet krevde at alle i gruppa jobbet sammen, fremfor inndelingen i undergrupper som vi hadde tidligere. Sigurd tok initiativ til at vi alle satte oss ned og diskuterte arkitekturen til systemet for å sjekke at alle hadde en korrekt forståelse av systemet. Med tanke på tidligere misforståelser, var alle enige om at dette var et godt tiltak. Det hadde tidligere kommet frem at kanskje ikke alle hadde helt lik forståelse av produktets oppbygning. Under møtet skisserte vi den overordnede arkitekturen til produktet, hvor hver enkelt fortalte om sitt delsystem og forklarte hvordan det fungerte og hang sammen med resten av systemet. Her kom det blant annet frem at Torbjørn og Rune hadde gjort ulike antagelser om hvordan deres moduler skulle integreres med hverandre, der Torbjørn antok at Runes del skulle være en undermodul i hans eget system, og omvendt for Rune. Denne misforståelsen ble heldigvis fanget opp tidlig nok til at det ikke resulterte i betydelig ekstraarbeid.

Etter noen runder rundt bordet, og litt løs diskusjon, kom vi frem til at vi alle var enige om at vi som regel hadde jobbet godt i undergrupper, og planlagt hver enkelt del av systemet godt. Problemene våre oppsto der hvor de enkelte delene skulle samhandle med hverandre. Jostein uttrykket et ønske om at vi skulle ta flere møter, samt hyppigere ta opp ting i plenum. Vi sa oss alle enige i dette, og vedtok i fellesskap at flere ting bør bli tatt opp med hele gruppa samlet. Dette inkluderte også avgjørelser som ikke påvirket alle sitt ansvarsområde direkte, da vi mente at det likevel var nyttig å kunne trekke på hele gruppens kompetanse på dette stadiet i prosjektet.

Som sagt hadde vi tidlig en klar arbeidsfordeling. Hver av oss, enten alene eller med en annen, hadde ansvar for en del av systemt. Dermed, hvis vi hadde innspill knyttet til hvordan en annens del skulle fungerte, vist vi hvem vi skulle snakke med. Dette var ikke noe vi hadde tatt opp i plenum, men etter litt diskusjon på landsbydag 12, var det dette som best beskrev samarbeided i denne fasen. En positiv resultate av dette er at det ville bli lite avbrytelser og avsporinger. Hvis det var en diskusjon rundt et delsystem man ikke var avhengig av, trengte man ikke ta del i diskusjonen, og kunne jobbe videre.

De misforståelsene vi har hatt, tyder på at denne måten å samarbeide på ikke har fungert så godt som vi har håpet. Det første symptomet har vært at kommunikasjonen ikke har vært godt nok, noe misforståelsene er et klart eksempel på. I vårt tilfelle ble alle misforståelser tatt opp på et tidspunkt før det fikk stor betydning, men vi ser at det hadde vært bedre for prosjektet om misforståelsene hadde blitt tatt opp før.

Tidligere misforståelser ser vi som et symptom på at vi ikke var flinke nok til å sjekke våre egne antakelser (Schwarz grunnregel 1 for effektivt samarbeid [?]. Antakelsen til Andreas var at Sigurd og Jostein kjente til teknologiene han foreslo. Sigurd og Jostein, samt Torbjørn og Rune hadde antatt hvordan systemet som de jobbet med skulle kombineres, uten at dette var diskutert. At tiltaket med å gjennomgå systemet i plenum avdekket en annen misforståelse før den ble et problem, tydet på at tiltaket fungerte og var verdifullt.

4 Gruppens utvikling

Avslutningen skal oppsummere de viktigste poengene fra hoveddelen. Den skal være en sammenfatning av det mest vesentlige. Det skal ikke komme ny relevant informasjon i denne delen av rapporten, men den kan fortelle om hvor veien går videre. Hvilke erfaringer tar du med deg?

Gruppens utvikling ?

Individuelt læringsutbytte ?

For å beskrive gruppas utvikling har vi valgt å bruke på Tuckman og Jensens gruppeutviklingsmodell [?]. Denne deler arbeidet teamarbeidet inn i fem stadier; forming, storming, norming, performing og adjourning. For å samtidig vurdere gruppas ytelse har vi laget tidslinje der vi viser både stadiene fra Tuckman og Jensens gruppeutviklingsmodell, sammen med gruppas ytelse slik vi har oppfattet den. Den er vist i figur ??.

Forming Da gruppearbeidet startet kjente vi ikke hverandre og vi visste ikke hva slags oppgave vi kom til å jobbe med. Diverse bli-kjent øvelser og kompetansekartlegging gjorde at vi raskt fant felles interesser og fikk orientert oss. Alle i gruppa var engasjerte for å gjøre det beste ut av emnet. Det meste av tiden gikk med til prosessøvelser, og vi fikk lite tid til å arbeide med selve prosjektoppgaven.

Storming Stormingsfasen vår foregikk i andre til tredje landsbydag. Her startet vi idémyldring for å forsøke å finne en oppgave som alle kunne gå inn for. Vi hadde alle hver våre idéer Figur 2: Tidslinje for prosjektarbeidet. Stiplet horisontal linje indikerer ytelsesnivå sammenliknbart med arbeid i en tradisjonell arbeidsgruppe.

om hva vi burde jobbe med, og følte et tidspress for å få valgt oppgave slik at vi kunne begynne å jobbe. Vi var også bekymret over mengden tid som kom til å gå med til prosess-øvelser, og at en for stor oppgave ville både påvirke prosjekt og prosessarbeidet negativt.

Ytelsen vår i denne perioden var dårligere enn ønsket, hovedsaklig på grunn av avsporinger og digresjoner som hindret oss å jobbe koordinert mot et felles mål.

Norming Norming foregikk i fjerde og femte landsbydag. Vi klarte å holde felles fokus på det å utarbeide en oppgave, og endte dagen med enighet rundt hva vi skulle jobbe med, og hvordan vi skulle dele opp arbeidet. Ikke minst hadde vi klart å definere en oppgave der alle kunne bidra og føle eierskap til prosjektet.

Gruppas oppførsel begynte å endre seg fra å være en pseudogruppe til en tradisjonell arbeidsgruppe, og det er på dette punktet at ytelsen begynte å fobedre seg.

Performing Fra sjette landsbydag kunne vi begyne å komme ordentlig i gang med arbeidet. Samarbeidet i denne fasen foregikk som oftest mellom to eller tre av gruppemedlemmene av gangen, med sporadiske diskusjoner felles i gruppa om tekniske spørsmål. Her ble det oppdaget noen misforståelser underveis (kap. ??), som gjorde at ytelsen til gruppa ble noe redusert, men misforståelsene ble oppdaget i tide til å holde oss i performing-fasen. Generelt har vi hatt solid ytelse i denne fasen, som har stabilisert seg over de siste dagene.

Adjourning Avslutningen av prosjektet er gitt av varigheten til emnet. Prosjekt- og prosessrapportene skal leveres i slutten av april, før eksamensperioden starter.

4.1 Samarbeidsindikatorer

I løpet av prosjektet, som en del av arbeidet med prosess, har vi gjennomført øvelser der vi individuelt besvarer spørsmål i et avkrysningsskjema, og hvor våre svar blir behandlet og kombinert til fem samarbeidsindikatorer. En slik øvelse ble gjennomført på 4. og 11. landsbydag. En visualisering av disse indikatorene er vist under, i figur ??.

Figur 3: Samarbeidsindikatorer fra to tidspunkter i prosjektarbeidet.

I stiplet blå linje ser vi gruppas indikatorer etter forming- og stormingsstadiet. Vi hadde allered vært bevisste på indikatoren nede til høyre, for lite struktur og svak disiplin", og vi hadde iverksatt et tiltak for dette. Et punkt vi var mindre bevisste på, var hvilken grad vi "ikke forholder oss til hverandre og det som skjer i gruppa". Dette mente vi var en naturlig ting for en gruppe i forming/stormingstadiet, og gjorde ikke noe spesielt utover å si at det var viktig å opprettholde god kommunikasjon og å tørre å si ifra om eventuelle problemstillinger.

Ellevte landsbydag gjennomførte vi øvelsen på ny. Resultatene er vist i sammediagram med heltrukken blå strek. Vi ser en tydelig forbedring på struktur og displin (nede til høyre), som følge av at vi ble bevisste på avsporinger og gjorde et vellykket tiltak for å forbedre fokus til gruppa.

På punkte om hvorvidt vi forholder oss til hverandre og det som skjer (oppe til venstre) ser vi også en tydelig forbedring. Dette mener vi både kommer av at vi har blitt enige om en oppgave, jobbet en del sammen og gått bort fra å være en pseudogruppe

Indikatoren om gruppas medlemmer er for snille og forsiktige med hverandre (nede til venstre), scoret vi høyt på i begge testene. I grupperefleksjonene rundt denne indikatoren hadde vi først vanskelig for å finne hvordan denne indikatoren ble slik den ble, da vi alle var enige om at vi ikke var for snille og forsiktige med hverandre. Av den grunn ble det ikke gjort noe tiltak, og vi fokuserte derfor på de to andre indikatorene der vi alle var enige om at vi hadde en utfordring.

En mulig forklaring for den høye scoren er at vi ikke har hatt noen konflikter i gruppa utover tekniske uenigheter som har blitt løst saklig. Vi har i tidligere prosjektarbeid med tilfeldige medlemmer vært vant til mer konflikter, og mangelen på konflikt kan gjøre at vi antar at andre i gruppa er for snille og forsiktige uten at dette er tilfellet.

Mangelen på konflikt tror vi kommer av at gruppa vår er homogen, og vi har klart å finne en oppgave som alle kunne bidra til og føle et eierskap til.

4.2 Individuelt læringsutbytte

Torbjørn Aase

Eksperter i team har vært en unik opplevelse i forhold til tidligere gruppearbeider, grunnet det store fokuset på å faktisk reflektere over hvordan hvordan arbeidet har foregått. I starten opplevde jeg det som litt vanskelig å umiddelbart se nytten av alt fokuset rundt det å studere selve prosessen, men etter hvert ble det stadig mer tydelig at det var forbedringspotensiale i det å være mer klar over hvordan gruppa samarbeider og hvordan medlemmene påvirker hverandre.

Det viktigste jeg har lært i løpet av dette prosjektet er nok hvor viktig det er å ha hyppig kommunikasjon og oppdateringer i gruppa. Å ha en fri flyt av informasjon hindrer misforståelser og unødvendige antagelser, samtidig som at det lar gruppa ta tak i potensielle problemer før de oppstår. Det var en tankevekker for meg at selv om jeg mener kommunikasjonen innad i gruppa var god, så var det fremdeles rom for forbedringer.

Andreas Bertheussen

Jeg har hatt mer utbytte av eksperter i team enn jeg hadde forventet. Tidligere har jeg hatt mange dårlige erfaringer med gruppearbeid i tilfeldige grupper, men eksperter i team har vært et unntak. Dette tror jeg kommer av at vi tok oss tid til å prate om hvordan samarbeidet fungerer, som er noe jeg vil ta med meg videre i andre gruppearbeid. Emnet har også fungert som en introduksjon til begreper og teori knyttet til gruppedynamikk, som har gjort det lettere å prate om og beskrive hvordan gruppa fungerer.

Rune Holmgren

Mangler

Sigurd Holsen

Tidligere gruppearbeider har båret preg av mest selvstendig arbeid der arbeidet har blitt oppdelt og delegert. I eksperter i team har jeg fått undersøkt hvordan dette har fungert på et større prosjekt med større krav til samhandling. Jeg har erfart at på større prosjekter er det enda viktigere å bekrefte antagelser for å unngå misforståelser. En annen erfaring er selv mindre avgjørelser kan ha nytte av å bli diskutert i plenum for å utnytte gruppen kompetanse.

Teorien i faget har også vist seg å være svært interessant da det kunne koples direkte opp mot gruppesamarbeidet.

Jostein Munz

Jeg var i starten kritisk til å bruke så mye tid på å diskutere gruppedynamikk fremfor å jobbe med produktet. Det viste seg dog etter hvert at et samarbeid jeg selv trodde var velfungende ikke alltid var så bra som jeg hadde intrykk av. Dette var da mest med tanke på misforståelser og for lite hyppig kommunikasjon. Jeg har opplevd at det er viktig med regelmessige sjekker på at alle partene i en gruppe har samme oppfattelse av mål for prosjektet. Spesielt med tanke på at målene for prosjektet gjerne endres underveis. Det har i tidligere prosjekter vært stor terskel for å ta opp konflikter, men i løpet av EIT har perspektivet mitt på dette forandret seg med tanke på dette. Jeg tror at jeg i fremtidige prosjekter vil hurtigere ta opp til diskusjon ting som jeg opplever som problematiske. I løpet av EIT har jeg også lært meg å identifisere hvilke momenter i et samarbeid som kan legge grunnlag for konflikter og hvordan man burde takle disse.

4.3 Sammendrag

[Retningslinjene for studentgruppenes sluttarbeider i EiT krever at prosessrapporten skal inneholde en oppsummering på om lag 200 ord. I denne oppsummeringen skal gruppa reflektere over sine erfaringer fra samspillet sett i lys av læringsmålene i EiT. Oppsummeringen kan enten plasseres før innledningen, eller i sammenheng med avsluttningen. Husk at det må være forskjell på oppsummeringen, forord og innledning. Hvis den samme informasjonen kommer flere ganger på rad blir det langtekkelig å lese.]

I løpet av prosjektarbeidet har vi gjort oss følgende erfaringer;

• Det er viktig å dobbeltsjekke vår tekniske forståelse med andre i gruppa, selv om vi tror man har forstått noe.

• Det er viktig å diskutere tekniske valg man tar, i gruppa, selv om det bare angår ditt ansvarsområde.

• Produktive normer for disiplin, rutiner og orden bør etableres tidlig.

De to første punktene tar vi med oss fra vår erfaring med misforståelser. Misforståelsene vi har støtt på kunne unngås på to forskjellige måter. Ved å ta oss bedre tid til å gjennomgå systemet i større teknisk detalj, kunne vi sørget for at medlemmene i gruppa fikk en bedre (korrekt) forståelse av hvordan systemet fungerte. På denne måten ville misforståelsene ikke oppstått. Det andre måten innebærer å oftere teste våre egne antakelser, og utfordre andres antakelser. Resultatet vil være at misforståelser oppdages raskere. Det å ta en teknisk gjennomgang underveis i prosjektet hjalp oss med å oppdage en annen misforståelse før den ble et problem.

Det andre punktet er relatert til det første. Gruppa vår hadde mye kompetanse innenfor programvareutvikling. Dette gjorde det lett for oss å ta individuelle tekniske valg innenfor ansvarsområdene våre, som var gode nok, uten å drøfte dem i gruppa. For å dra nytte av erfaringen av resten av gruppa har vi merket at vi bør mer aktivt søke innspill fra de andre i gruppa på hvordan en har valgt å løse et problem, fordi vi vet ikke når noen har en god idé før behovet oppstår, og vi spør.

Problem med avsporinger og ufokusert jobbing var noe vi oppdaget og håndterte tidlig i prosjektet, med et vellykket resultat. Gruppa støtte også på problemer med forsentkomming og lekser som ikke ble gjort. I disse tilfellene burde vi innført et tiltak raskere.

Det var både fordeler og ulemper med den homogene gruppesammensetningen vår. Gruppa bestod utelukkende av teknologer med kompetanse på programmering, noe som gjenspeiles i produktet vårt. Et eksempel på dette er brukergrensesnittet vårt, som har fungert godt for oss, men som ikke nødvendigvis er intuitiv for en ikke-teknolog. Med en mer inhomogen gruppesammensetning ville trolig dette fått mer fokus, men dette kan gå på bekostning av produktivitet, ettersom det er programmeringsjobben som har tatt det meste av tiden vår.

A Samarbeidsavtale

19