Suhtlusest projektides

Suhtlus on tähtsal kohal projektis. Suur osa probleeme, mis tekkivad, on tingitud vähesest suhtlusest. Sellest pikemalt või lugeda eelnevast postitusest “Miks projektid ebaõnnestuvad”. Selle postituse raames vaatlen, millised suhtluse liigid on ja mis nende eripärad on.

Esimese hooga võib suhtlust liigitada kaheks: sünkroonne ja asünkroonne. Scott W. Ambleri artiklis oli toodud ära suhtluse efektiivsuse kurv, mis algas e-postiga ja lõppes näost näkku suhtlusega tahvli juures. Kui x-teljel vahetada suhtluse rikkalikus ära sünkroonsusega, siis see näeks sama välja.

Sünkroonne suhtlus

Programmeerimises on sünkroonsed meetodi väljakutsumised tavaline nähtus ja ka elus eneses kasutame seda kõige rohkem. Lihtsalt seletades seisneks see selles, et küsimusele jäetakse vastust ootama ning ei toimetata teiste asjadega. Näost näkku suheldes on teema palju arutlevam, vähemalt probleemide lahendamise osas. Kasulik on sellist suhtlust kasutada plaanimisel (arhitektuuri, projekti olukorra jne). Kuna see on aktiivne viis, siis on seda raske jälgida/dokumenteerida seetõttu ei tasuks kasutada seda dokumentatsiooni loomise vahendina. Kindlasti olete näinud koosolekutel inimesi protokollimas ning hiljem sellele kinnitust küsimas, mis illustreerib hästi jälgitavuse raskust.

Sünkroonne suhtlus lisab iga meeskonnaliikmega juurde ka keerukust. Seda võib vaadata graafina, kus liikmed on tipud ja nende vahelised seosed kommunikatsiooni kanalid. Mida rohkem on inimesi, seda rohkem on ka kanaleid ning see kasvab eksponentaalselt. Sellest tingitult ei ole võimalik ka projekti tööaega jagada inimeste arvuga ning reaalselt valmis saada (9 naist ei sünnita ka last kuuga).

Asünkroonne suhtlus

Vastupidiselt sünkroonsele suhtluse, pärast küsimuse esitamist tegeletakse muude asjadega ning vastuse saamine on pole nii kiireloomuline (vähemalt ei tohiks olla). Peamine vorm on e-kirjade saatmine. Juurde võiks tuua veel wiki, SMS-ide saatmine ja ka instant messenger (IM) variandid. Viimane neist võib minna ka sünkroonse alla, sest seal saab küllaltki aktiivselt teise inimesega vestelda, kuid olemuselt on see siiski asünkroonne, sest sa ei pea vastama niipea kui IM teavitab uue sõnumi kohale jõudmisest.

Kiirelt vastust loota sellise suhtlemise puhul loota pole (v.a. kui vastaspool on “aktiivne” Outlooki kasutaja ) , seega tugevat arutelu siin loota pole. Proovida võib, kuid see võtab liiga palju aega.

Kuna asünkroonne suhtlus vajab abivahendeid, siis on see hästi jälgitav, mis teeb sellest paljudele juhi positsioonidel olevatele inimestele meeldivaks, sest süüdlase leiab ajaloo järgi lihtsalt üles.

Asünkroonse suhtluse kuulub veel eripärane avalda/telli (publish/subscribe) suhtlus.

Avalda/telli

See seisneb selles, et keegi avaldab mingit sisu ja sellest huvitunud inimesed saavad uuest kirjatükist teada. Elavad näited sellest on ajaveebid (RSS) ja ka paljude lemmik Twitter. Viimast varianti pole kohanud väga palju projektide haldamise osas. Muidugi RSS-i kasutamist võib täheldada, sest paljud süsteemid pakuvad muudatustest teavitamist. Twitteri laadsed projektipäevikut pole eriti kohanud. Selle kaudu on hea viis infot jagada paljudele korraga ning teavitada muudatustest.

Praeguseks on olemas Yammer privaatse siutsumise võrgustiku loomiseks.

Kokkuvõte

Projektis suhtlemise puhul tasuks kasutada plaanimisel peamiselt sünkroonseid suhtluse variante, dokumenteerimisel ja kinnituste küsimusel asünkroonset ning muudatustest teavitamisel avalda/telli suhtlust.

Lisaks võite lugeda Juregn Appelo postitusi “Communication = Information * Relationships”, “Optimize Communication, Throw the Boss Out”.