tete Work-time Attendance Software T Kommunikaatiokäytännöt

Transkriptio

1 tete Work-time Attendance Software T Kommunikaatiokäytännöt

2 Version Date Author Description Miikka Lötjönen Ensimmäinen luonnos Miikka Lötjönen I1-vaiheen palautusversio. Lisätty osuus Etenemisraportti I Miikka Lötjönen I2-vaiheen palautusversio Miikka Lötjönen I3-vaiheen palautusversio Miikka Lötjönen DE-vaiheen palautusversio.

3 Sisällysluettelo Sisällysluettelo Mahdolliset kommunikaatiotavat Käytetyt kommunikaatiotavat Versionhallinta Trapoli Tapaamiset Muistiot Sähköposti WWW-sivu ICQ Helpompi käyttöönotto Vaivattomuus Ominaisuudet IRC:n hyviä puolia ovat puolestaan: Puhelin Muuta kommunikaatiota helpottavaa Templatet Kurinalaisuus Yhteydenpitohenkilö Coding conventions Edistyksen mittaaminen Etenemisraportti I Etenemisraportti I Etenemisraportti I Etenemisraportti DE Koko tutkimuksen tulokset... 11

4 9.1 Mittaustulokset sähköpostit bugzillaraportit Dokumentit muistiot koodikommentit Subjektiiviset tulokset Hyödyt projektille Henkilökohtaisia huomioita Lähteet... 12

5 1 Mahdolliset kommunikaatiotavat Kommunikaatio on aiheena sinänsä hankala, että suurimmalta osin on päätetty jo projektin alusta lähtien, miten asioita hoidetaan. Vaikea on myös olla kertomatta itsestäänselvyyksiä, joita siihen liittyy, ja toisaalta selittää tarvittavat asiat riittävällä tarkkuudella. Kommunikaatio liittyy myös oleellisesti moneen muuhun projektin läpiviennissä oleelliseen asiaan. Paljon kommunikaatiosta menee esimerkiksi suoraan versionhallinnan alueelle. Ryhmätyötä avustavia järjestelmiä on internet pullollaan, alkaen java-pohjaisista virtuaaliyhteisöistä, päätyen täysmittaisiin yritysratkaisuihin. Edellämainitut mahdollistavat usein keskustelupalstan, tiedostonjaon, kalenterinjaon, virtuaalikokoukset jne. Rehellisesti sanottuna en löytänyt ainakaan Googlen Computers/Software/Groupware-kategoriasta ja siihen liittyvistä kategorioista yhtään järjestelmää, jonka näkisin oleellisesti parantavan kommunikaatiotamme verrattuna tässä esittämiini ratkaisuihin. Microsoft Exchange ja Microsoft Project yhdistelmä olisi yksi mahdollinen perusratkaisu. Tällöin kuitenkin rajaisimme itsemme pelkästään Windows-ympäristöön ja tähän ohjelmistoon ja olisimme tämän ratkaisun orjia. Microsoft on ilmeisesti itsekin huomannut tämän, sillä nykyään linkki Microsoft Project Microsoft Developer Networkissa viekin suoraan MS Office sivulle, jossa kerrotaan miten Office 2003:n uudet ominaisuudet auttavat kehityksessä. Lopulta saatta olla, että otetaan käyttöön aivan ylimitoitettu järjestelmä, vaikka paljon vähemmälläkin pärjättäisiin ja ylläpitoon/opetteluun kuluu enemmän aikaa kuin mitä järjestelmä säästää. Esimerkiksi ryhmä ei välttämättä tarvitse kalenterinjako-ominaisuuksia, eikä kukaan todennäköisesti edes vaivautuisi siihen tietojaan pistämään. Tällöin apumenetelmästä muodostuu ylimääräinen taakka. Toinen rajoite, mikä tulee nopeasti vastaan on raha. Olisi mukava kokeilla uusia työkaluja, mutta yrityskäyttöön tarkoitetut järjestelmät maksavat paljon. Olemme valinneet kehitystyökaluiksi vain ilmaisia ohjelmistoja. Yksinkertaisten ja yleisesti hyväksyttyjen menetelmien käyttö saattaa olla tehokkain tapa toimia tämänlaisessa projektissa. Muutenkin, jos jokin uusi menetelmä otetaan käyttöön, koko ryhmän tulisi hyväksyä se. Kommunikaatiovälineen toimivuuden ratkaisee se, miten sitä käytetään. Sanonnan mukaan: Paras kamera ei ole se, jolla saa parhaita kuvia, vaan se, joka on mukana kun jotain mielenkiintoista tapahtuu 2 Käytetyt kommunikaatiotavat 2.1 Versionhallinta Bitkeeper ( valittiin projektin versionhallintaan CVS:n sijaan sen kehittyneempien ominaisuuksien ansiosta. Lisäksi suurimmalla osalla ryhmästä CVS oli jo arkipäiväinen työkalu ja haluttiin kokeilla jotain uutta ja oppia. Versionhallinnan merkitys kommunikaatiossa on oleellinen. Dokumenttien luettavuus kasvaa huomattavasti ja kommunikaatio paranee, jos muutokset dokumentoidaan selkeästi. Kaikkien tulisi submitoidessaan uusia dokumentteja kuvata riittävällä tasolla, mitä on tehty missäkin muutoksessa. Oleellisesti versionhallintaan liittyy myös tieto siitä, mitkä osat ovat vielä työn alla, mitkä jo valmiita. Versionhallinnasta ja Bitkeeperistä lisää Tuomaksen esittelemänä.

6 2.2 Trapoli Trapoliin tunteja kirjaamalla pysyy projektin kokonaiskuva eheänä ja kaikki saavat käsityksen kulloisestakin tilanteesta. Left-kentän käytöllä voidaan kertoa arvioidusta jäljellä olevasta työmäärästä. 2.3 Tapaamiset Fyysiset tapaamiset ovat tehokkaita tiedonjaossa ja suurien linjojen suunnittelussa. Niilo varmasti pystyykin pitämään koko ryhmän statustapaamiset tiiviinä ja asiapitoisina. Kahdeksan ihmisen keskusteluryhmä ei ole paras paikka detaljitason suunnitteluun, ja näin ollen koko ryhmän tapaamisten lisäksi järjestetään työryhmien omia tapaamisia, joissa keskustellaan yksityiskohtaisemmin tietyistä aihealueista. Jokaisessa statuskokouksessa ryhmät sitten raportoivat mitä ovat miettineet, perustelevat ratkaisunsa ja selvittävät asian pääpiirteissään muille. 2.4 Muistiot Tapaamisissa on aina sihteeri, joka kirjaa ylös mitä on puhuttu. Tällä tavoin ihmiset, jotka eivät ole syystä tai toisesta tapaamiseen päässeet, saavat välttämättömimmän informaation lukemalla sen muistiosta, eikä sitä tarvitse jonkun erikseen kertoa. 2.5 Sähköposti Postilistalla päätettiin käyttää kaikkiin maileihin [76.115]-tunnistetta subject-rivin alussa, jolloin viestien tunnistaminen ja (automaattinen) lajittelu helpottuu huomattavasti. Postilistalle ilmoitetaan kun uusia dokumentteja tulee valmiiksi, sovitaan käytännön järjestelyistä ja kysytään jos on ongelmatilanteita. 2.6 WWW-sivu Sivu sijaitsee osoitteessa Kurssin kaikki materiaali on saatavilla netistä, johon se peilataan bitkeeper-repositoriosta. Tällöin kaikki asianomaiset pääsevät materiaalia katsomaan ilman bitkeeperiäkin. WWW-sivulle myös kootaan projektiin liittyviä uutisia ja päivitetään aikataulu. Sivulta löytyy myös kaikkien yhteystiedot ja tehtävänkuvaukset. Tämä on käytännössä tapaamisten lisäksi se kanava, mitä kautta asiakas ja mentor pysyvät tilanteen tasalla. 2.7 ICQ Projektin edetessä ohjelmointivaiheeseen alkaa varmasti tulla paljon tilanteita, joissa täytyisi konsultoida muita ryhmän jäseniä. Sähköpostilla vastauksen saaminen voi kestää tunteja tai päiviä. Jatkuva puhelimen käyttö taas maksaa paljon, ihmisiä voi olla vaikea saada kiinni, ja huonolla tuurilla saa soitella useille ihmisille ennen kuin asia selviää. Joku nopeampi yhteydenpitotapa koettiin tarpeelliseksi. IRC on perinteinen versio tällaisesta epämuodollisesta nopeasta viestinnästä. Ryhmälle voitaisiin perustaa kanava, jolla voisi keskustella aiheesta. Käyttöönoton kynnys kuitenkin on hieman korkeampi verrattuna instant messenger -vaihtoehtoihin. Vaihtoehtoja löytyy tähänkin, mm. ICQ, MSN Messenger, AOL Instant Messenger, Jabber jne. Itselläni ICQ on jo yhtä arkipäiväinen työkalu kuin sähköposti tai puhelin. Sekä IRC että ICQ ovat laitteistoriippumattomia, ICQ on saatavilla lähes kaikenlaisille laitteille ja käyttöjärjestelmille tekstipohjaisesta Linux-versiosta PDA-versioon. Tehokkaimmin se toimii standalone-

7 asennuksena, mutta ICQ2Go -versiota voidaan käyttää myös jokaisessa tietokoneessa, jossa on selain ja Java asennettuna. Seuraavassa perusteluja miksi pidän ICQ-pikaviestintä toimivampana vaihtoehtona henkilökohtaiseen viestintään kuin IRC: Helpompi käyttöönotto ICQ:n ottaa käyttöön asennustiedoston lataamisen jälkeen noin kolmessa minuutissa, eikä varsinaista konfigurointia liiemmin tarvita. IRC vaatii hieman konfigurointia ja ylläpitoa. Esimerkiksi tiedostonjako ei toimi suoraan, kanavan oikeuksista pitää pitää huolta jne. Täytyy ottaa selvää IRC-palvelimista ja niiden ominaisuuksista, esim. tuetaanko offline-viestejä Vaivattomuus ICQ käynnistyy automaattisesti käyttöjärjestelmän käynnistyessä ja on huomaamattomasti taustalla aina konetta käytettäessä niin kauan kuin sille tulee tarvetta. ICQ:ta ei tarvitse seurata, se ilmoittaa kyllä olemassaolostaan kun on sen aika. Myös offline-viestejä voi lähettää. IRC:n voi myös pistää taustalle. Kysymys onkin, tekevätkö kaikki näin joka kerta kun käynnistävät koneensa ja seuraavatko he, mitä kanavalla tapahtuu? Jos vastauksen saaminen kanavalla kestää kauan, on jo helpompi käyttää perinteistä sähköpostia, joka ainakin tavoittaa kaikki Ominaisuudet ICQ sisältää tiedostonsiirto- ja jako-ominaisuudet. Ainut ongelma on, jos toinen koneista sisältää vainoharhaisen palomuurin, joka ei suostu päästämään liikennettä läpi. ICQ:n viesti-ikkuna tukee RTF-dataa, joten sen kautta voidaan nopeasti jopa lähettää osia dokumenteista oikein muotoiltuna. Eräs kokeilemisen arvoinen ominaisuus ohjelmassa olisi ICQ phone, jota hyödyntämällä saataisiin puheyhteys kahden työtä tekevän ryhmäläisen välille maksamatta puhelinlaskua. SMS-palvelu. Suurimmalla osalla ryhmästä on Radiolinjan liittymä, jota ICQ voi käyttää ilmaisten tekstiviestien lähettämiseen ja vastaanottamiseen IRC:n hyviä puolia ovat puolestaan: Käyttöön tarvitaan vain Unix-shell, useimmiten irc on asennettuna valmiiksi. IRC on vakiintunut ja perinteinen. Ryhmätapaamiset ovat toimivampia kuin ICQ:ssa, joka on suunniteltu enemmänkin henkilökohtaiseen viestintään.

8 2.8 Puhelin Kun mikään muu ei enää auta, turvaudutaan vanhaan kunnon puhelimeen. 3 Muuta kommunikaatiota helpottavaa 3.1 Templatet Alusta lähtien olemme yrittäneet tehdä asioita tiettyjen mallien mukaan, niin kuin yleensä on tapana. Tämä säästää aikaa, ei tarvitse kiinnittää huomiota epäoleellisiin muotoseikkoihin, vaan voi keskittyä sisältöön. Esimerkiksi tämä dokumentti kaikkine muotoiluineen syntyi pelkästään lisäämällä sopivantasoiset otsikot. [versio 1.1 muutos] Ulkoasu ei kuitenkaan ole uuden dokumenttitemplaten mukainen. 3.2 Kurinalaisuus Fakta on se, että menetelmä on vain yhtä hyvä kuin sen käyttäjä. Kaikille ryhmän jäsenille tulee olla selvä, miten töitä tehdään ja myös noudattaa käytettyjä periaatteita johdonmukaisesti. 3.3 Yhteydenpitohenkilö On sovittu, että Niilo pitää yhteyttä asiakkaaseen ja mentoriin ja toimii heidän äänitorvena muulle ryhmälle. Tällöin ainakin joku on koko ajan selvillä tilanteesta, eikä viestit niin helposti katoa matkalle. 3.4 Coding conventions Dokumentissa process_guide.rtf on määritelty käytettävät ohjelmointikäytännöt. Suurimmalta osin noudatamme Sunin määrittelemiä Java-ohjelmointikäytäntöjä. 4 Edistyksen mittaaminen Kommunikaation toimivuudesta on hankala esittää selkeitä mittareita. Numerotietoa ei juurikaan sujuvuudesta synny, ja subjektiivisia arvioita ovat aina hankala kvantisoida. Mittaamiseen käytän kyselyä, joka tehdään ryhmälle iteraation päätteeksi. Kysymykset: 1) Miten kommunikointi ryhmän kesken on yleisesti sujunut tämän iteraation aikana? 2) Miten kommunikaatio on kehittynyt aikaisemmista iteraatioista? 3) Onko alussa sovittuja käytäntöjä noudatettu? 4) Onko esiintynyt ongelmia? Miten ongelmat ratkaistiin? 5) Mitkä työkalut olet kokenut tarpeellisimmiksi ja mistä ei ollut hyötyä? Miksi?

9 6) Onko jotain, mitä haluaisit parantaa tulevaisuudessa? 7) Muita kommentteja Saaduista palautteista kootaan vaiheen etenemisraporttiin tiivistelmä ja analyysi. 5 Etenemisraportti I1 Sovittuja käytäntöjä on noudatettu varsin hyvin. Suurempia ongelmia ei ole ollut. Kommunikaatiota on hankaloittanut lähinnä ihmisten kiireet. Tärkeisiin kysymyksiin ei välttämättä ole saanut vastausta nopeasti. Tähän mennessä kaikki ovat asentaneet ohjeiden mukaisesti ICQ-viestimen. Käyttöönotto sujui hyvin, mutta samalla todettiin, että ICQ ei ole omimmillaan ryhmäviestinnässä ja projektiryhmälle perustettiin IRCkanava #wtas ryhmätapaamisia varten. WWW-sivun käyttö tiedonjakokanavana on jäänyt vähäiseksi. Osittain siksi, että käytetään Bitkeeperiä ja dokumenttien jako hoituu samalla, osittain siksi, että sivut ovat jääneet pitkiksi ajoiksi päivittämättä. Tähän on kuitenkin tulossa muutos. Vaiheen I2 aikana tehdään ensimmäinen kysely, joka kuvattiin edellisessä kappaleessa. 6 Etenemisraportti I2 Mikään ei ole ratkaisevasti muuttunut edellisestä iteraatiosta. Ensimmäisen iteraation lopulla tein kyselyn, johon sain 7 vastausta. Yleinen havainto oli, että kommunikaation koettiin jalostuneen ajan kuluessa, eikä suurempia ongelmia oltu havaittu. Fyysisiä tapaamisia oli tässä iteraatiossa huomattavasti vähemmän, joten muun kommunikaation toimivuus korostui. Sähköpostia pidettiin vieläkin ylivoimaisesti tärkeimpänä kontaktimenetelmänä ja puhelinta nopeimpana. Yksityiskohtana mainittakoon, että projektipäällikön postilaatikosta löytyy jo yli 900 projektia koskevaa viestiä. Ristiriitaisimmat kommentit tulivat nopeaan viestintään tarkoitetuista keinoista, ICQ:n ja IRC:n käytöstä. Ihmiset, jotka olivat käyttäneet ICQ:ta, pitivät sitä hyödyllisenä ja IRC:n käyttäjät pitivät IRC:iä hyödyllisenä. Jotkut sanoivat, että ICQ:ta ei kannata käyttää, kun taas jotkut halusivat hyödyntää sitä enemmän. Subjektiivinen havaintoni oli, että korrelaatio ICQ:ssa oleskeluajan ja sen hyödyllisenä pitämisen kanssa oli melko täydellinen. Ihmiset ilmeisesti ovat jakaantuneet hieman kahteen leiriin, toiset ovat ICQ:ssa, toiset IRC:ssä. Parannettavaa löydettiin mm. ryhmän www-sivun päivitystiheydestä ja siitä, että ihmiset olisivat paremmin ICQ:n tai IRC:n äärellä koneella ollessaan. Toisaalta myös IRC-tapaamisia kritisoitiin tehottomiksi. Ratkaisu käyttää kaikissa dokumenteissa PDF/RTF/DOC muotoa www-sivun sijaan kyseenalaistettiin. Tarkempi analyysi kaikkien kyselyjen tuloksista tulee PSEA:n loppuraporttiin. 7 Etenemisraportti I3 Tämän iteraation kommunikaatiota hallitsi selkeästi etätyö. Fyysisiä tapaamisia ei ollut juuri nimeksikään, IRC -tapaamisiakin vain yksi. Sähköpostin käytön merkitys korostui. Toisallta sähköpostiakaan ei tullut mitenkään valtavasti yleiselle listalle, ilmeisesti ihmiset lähettelivät niitä keskenään. Tämä on johtanut

10 ajoittaiseen epätietoisuuteen projektin tilasta. Monesti on joutunut kyselemään yksityisesti ihmisiltä, missä mennään. Osaaminen on kasvanut ja tässä iteraatiossa on voinut keskittyä paremmin oleellisiin asioihin. Bugzillan käyttö kommunikaatiovälineenä on ehkä hieman parantunut. ICQ:n käyttö on vähentynyt, mutta omakohtainen mielipiteeni on, että niiden kanssa, ketkä onlinena ajoittain ovat (Niilo, Marko, Jaakko joskus), keskustelu on ollut helpompaa. Suurempia ongelmia ei ole ollut, eikä näytä siltä, että mitään merkittäviä muutoksia tullaan enää tekemään. 8 Etenemisraportti DE DE-vaiheessa tehtiin kysely, jossa kartoitettiin projektin kommunikaatiota kokonaisuutena. Etenemisraporteissa olen kertonut, mitä iteraatioiden varrella on tapahtunut. Mitään kovin yllättävää ei esiintynyt. Tässä käytetyt kysymykset: 1) Miten kommunikointi ryhmän kesken on yleisesti sujunut? 2) Onko nähtävissä selkeitä kehitysaskeleita projektin kuluessa? 3) Onko alussa sovittuja käytäntöjä noudatettu? 4) Onko esiintynyt ongelmia? Millä alueilla ja minkätyyppisiä? Miten ongelmat ratkaistiin? 5) Mitkä työkalut olet kokenut tarpeellisimmiksi ja mistä ei ollut hyötyä? Miksi? 6) Mitä olet oppinut kommunikoinnista softaprojektissa? Mitkä taitosi ovat parantuneet? Ovatko jotkin ennakkoluulosi osoittautuneet oikeiksi tai vääriksi? 7) Minkä asioiden luulisit olevan helpompia, jos samalla porukalla tehtäisiin toinen projekti? 8) Minkä luulisit olevan paras tapa tehostaa ryhmän kommunikointia? 9) Kokemustesi perusteella, mitä pitäisit pullonkaulana tämän projektin kommunikaatiossa / yleensä? 10) Kuinka monta mailia liittyen projektiin a. vastaanotit? b. lähetit? 11) Kuinka suuri prosentti näistä oli yksityisiä (ei koko ryhmälle)? 12) Kuinka usein luit projektiin liittyviä maileja päivässä/viikossa? 13) Kuinka usein olit tavoitettavissa (en juuri koskaan, kuukausittain, viikoittain, muutaman kerran viikossa, päivittäin) a. IRC:ssä? b. ICQ:ssa? 14) Minkä luulisit olevan paras tapa mitata kommunikaation tehokkuutta?

11 15) Muuta? Mitä tahansa kommentteja aiheeseen liittyen? Esimerkiksi Niilo voi varmaan raportoida kasvaneesa puhelinlaskustaan ;) Kyselyn tulokset ovat kerättynä tiedostoon PSEA_Miikka_tuloksetDE.xls. 9 Koko tutkimuksen tulokset 9.1 Mittaustulokset Kommunikaation määrää voi laskea kvantitatiivisesti tai kvalitatiivisesti. Käytännössä tämä usein tarkoittaa lähes samaa kuin objektiivisesti ja subjektiivisesti. Lukumäärät sellaisenaan ilman sisällön analysointia ovat melko harhaanjohtavia, mutta antavat vähintäänkin suuntaa kommunikaation määrästä: sähköpostit sähköposteja ihmisille kertyi vaihtelevia määriä, kuudesta sadasta projektipäällikön noin tuhanteen. Viestejä lähetettiin vielä vaihtelevammissa määrin, muutamasta kymmenestä muutamaan sataan bugzillaraportit Bugzillaraportteja kertyi yhteensä 174 kappaletta. Näistä 148 korjattiin, 26 jätettiin jatkokehitystä varten. Monissa raporteissa oli selkeää keskustelua, ja ne korvasivat erillisten sähköpostien lähettämisiä Dokumentit Yhteensä 49 palautettua dokumentta, monia tilapäisiä ja matkan varrella paljon variaatioita niistä muistiot Yhteensä 22 muistiota erilaisista tapamisista (fyysinen, IRC, asiakastapaaminen) koodikommentit Yhteensä 159 riviä. Tapaamiset. Muistioiden määrästä voi huomata, että tapaamiset eivät olleet aivan viikoittaisia niin kuin oli sovittu. Tämä toisaalta tehosti ajankäyttöä, mutta rajoitti projektin edistymisen seuraamista. 9.2 Subjektiiviset tulokset Yleisesti ottaen ihmiset olivat tyytyväisiä projektin kommunikaatioon. Hieman oli loppuvaiheen etätyön tuloksena ilmassa tunnetta, että kaikilla ei ollut oikein enää selkeää kuvaa, missä projekti oli menossa. Monista kanavista huolimatta ihmisiä oli myös vaikea välillä saada kiinni heidän menojensa takia. Monet

12 kaipasivat sitä, että ihmiset olisivat jatkuvasti samassa paikassa ja paremmin saavutettavissa, mikä toisaalta jo kuulostaa ihan työpaikkaympäristöltä. 9.3 Hyödyt projektille Alussa sovitut kommunikointitavat antoivat suuntaa koko projektille, tietty kurinalaisuus, tehokkuus ja läpinäkyvyys syntyy jo lähes pelkästään sovittuja tapoja noudattamalla. Kommunikaatiomenetelmissä kuitenkin tapahtui selkeää evoluutiota, ihmiset hylkäsivät tehottomina pitämiään välineitä ja toimintatapoja, ja siirtyivät niistä mielekkäämpiin. Näin asian mielestäni täytyykin olla, pelisäännöt täytyy olla, mutta niistä pitää pystyä tarpeen tullen joustamaan. Mitään aivan mullistavaa ei kuitenkaan tapahtunut, sähköposti ja puhelin olivat silti tärkeimmät yhteydenpitovälineet. Sähköpostia kaikki tarkastivat vähintään kerran päivässä. Lähdimme liikkeelle perinteisellä linjalla. ICQ/IRC olivat ainoat perinteisistä tavoista poikkeavat varsinaiset kommunikaatiovälineet. Tavallaan kokeilu epäonnistui, koska työkalun täyttyä hyötyä ei saavutettu. Osa käytti mahdollisuutta hyödykseen lähes päivittäin, osa kokeili muutaman kerran koko projektin aikana. Voisin kuitenkin väittää, että siltä osin kun pikaviestimiä käytettiin, niistä oli paljon hyötyä. Tämä tulee esille myös kyselyissä esiin tulleissa kommenteissa, ICQ:n hyödyllisyyttä pidettiin positiivisena yllätyksenä. Ihmiset oppivat valtavasti ryhmätyöskentelystä. Jos nyt tehtäisiin uusi projekti, kommunikaatio olisi huomattavasti sujuvampaa ja tehokkaampaa. Osattaisiin puhua oikeista asioista niiden oikeilla nimillä ja kysyä suoraan oikealta ihmiseltä. Alusta lähtien suunnittelemamme kolmeen osaan jaettu kommunikaatio toimi mielestäni hyvin. On henkilökohtaista kommunikaatiota, muuttuvien pienryhmien kommunikaatiota ja koko ryhmän kommunikaatiota. Kommunikaation yksityiskohtaisuus laskee ensimmäisestä viimeiseen mentäessä. 10 Henkilökohtaisia huomioita Sanoisin, että tarkkailtuani kommunikaation toteutumista käytännössä projektin kuluessa, ensimmäinen havainto on, että kommunikaatio toimi hämmästyttävän hyvin, ottaen huomioon että fyysisiä tapaamisia ei juuri pidetty. Viimeiset kuukaudet ovat menneet käytännössä ilman muiden näkemistä, lukuun ottamatta project review tilaisuuksia. Etäprojekti vaatii kuitenkin tiettyä kurinalaisuutta, tapaamiset pitää korvata jollain tavalla. Mielestäni 11 Lähteet Process automation and collaboration: C-Business Sivuilla käyty BrightWork - Solutions - Software Development with MSF (Microsoft Solutions Framework Sivuilla käyty

13 ICQ.com - ICQ@Work Sivuilla käyty Microsoft Exchange Server Sivuilla käyty Google Directory - Computers > Software > Groupware Sivuilla ja monilla sen alasivuilla käyty ja Juraj Hudek Communication metrics for Software Development Dokumentti haettu Vera Zaychik Capturing Communication and Context in the Software Project Lifecycle Dokumentti haettu