Laborator 5 - Comunicarea în cadrul proiectului

Ca în orice domeniu, comunicarea poate să aibă loc, fie pe cale verbală, fie pe cale scrisă.

Comunicarea verbală este interactivă, rapidă, dar nu ajunge la nivelul de detaliere posibil prin comunicarea scrisă. Comunicarea verbală transmite sensuri și simboluri mai curând decât informație exactă. De exemplu: daca toata lumea este de acord ca la forma “patrat” sa ii zica cerc atunci acesta este sensul general acceptat de catre toti. Capcana tipică este de a crede că toată lumea a înțeles același lucru. Detalii esențiale pot dispărea rapid din memorie. Fiecare persoana umple acele goluri existente intr-un mesaj cu elemente proprii din alte experiente.

Comunicarea trebuie sa fie exacta,specifica fara generalizari,omisiuni,ambiguitati. Tipic, o persoană poate reține circa 50% din ce s-a discutat în primele 20 de minute, iar după aceea procentul scade rapid (http://www.mtholyoke.edu/acad/intrel/speech/differences.htm). Comunicarea verbală este utilă în special în situații decizionale, când interlocutorii sunt deja familiari cu subiectul, și este recomandat să fie urmată de un rezumat scris.

Comunicarea scrisa este mult mai susceptibilă la erori de emisie și/sau recepție. Problemele pot apărea în funcție de formularea aleasă și de interpretarea dată de cititor. În lipsa posibilitătii de interacțiune în vederea lămuririi unui aspect, confuziile și erorile de comunicare pot apărea ușor.(vezi interpretari ale legilor). Ca avantaje, informația poate fi foarte detaliată, exactă și mai ales e stabilă în timp. Comunicarea scrisă este utilă pentru transmiterea efectivă de informație și fixarea informației schimbate în comunicările verbale.

Următoarele reguli sunt utile în cadrul comunicării verbale:

• Nu întrerupeți pe cel care vorbește la un moment dat.
  • Există 2 posibilități: aveți ceva valoros de zis sau doar o observație care nu ar aduce valoare discuției. În ambele cazuri, în afară de lipsa de politețe, și potențialele tensiuni create din partea persoanei respective, o să aduceți și un minus în termen de eficiență a discuției.
  • Soluția recomandată, pentru a nu întrerupe discuția, dar şi a păstra ideile bune care v-au venit, este să aveți un carnețel / laptop în care să notați aceste idei, pe care le puteți expune când vorbitorul a terminat ce avea de spus.
• Nu vorbiți mai mult de 5 minute fără pauză.
• Separați clar ideile distincte.
  • Spre deosebire de un material scris, unde ideile distincte pot fi separate ușor în mod vizual, folosind diverși despărțitori, în comunicarea verbală, trecerea bruscă de la un subiect la altul poate reprezenta o problemă.
• Nu stați cu spatele la cei cărora vă adresați.
• În cadrul grupului de lucru puteţi stabili un set de reguli suplimentare de comunicare.
  • O bună practică este să existe un set de semne stabilit pentru a facilita transmiterea de mesaje vorbitorului fără o întrerupere verbală. Exemple de mesaje pentru care pot fi transmise folosind anumite semne:
  • off-topic - pentru a avertiza vorbitorul ca a divagat de la subiect;
  • scurtează - dacă vorbitorul discută prea mult pe o singură temă;
  • vreau să iau cuvântul - pentru a cere o întrerupere, pentru a aduce un comentariu important;
  • subiect închis - dacă se consideră că subiectul este clar și se poate trece la următorul punct în discuție.
• Fiti asertivi.
• În cadrul discuției nu încercați să vă impuneți punctul de vedere și ascultați și părerile celorlalți încercând să înțelegeți argumentele lor.

Deși se preferă, în general, comunicarea verbală în cadrul dezvoltării unui proiect software (în special în cadrul metodologiilor Agile), există numeroase situații în care este necesară transmiterea unor informații în formă scrisă.

Întotdeauna când comunicați, trebuie să aveți în vedere respectul pentru timpul celorlalți. Acest lucru înseamnă că trebuie să comunicați ce aveți de transmis scurt și clar.

Înainte de a trimite un mesaj, fie că este vorba despre un e-mail sau despre un document cu un raport, puneți-vă următoarele întrebări:

• Ce vreau să transmit?
• Cui vreau să transmit? (persoanele de la HR probabil nu vor fi interesate de ce bug ați descoperit în kernel)
• Ce rezultat / ce răspuns aștept? (dacă PM-ul trimite un mail în care anunță că există un mare bug în aplicație, dar nu numește un responsabil / un deadline / nu propune o soluție, mesajul nu va fi eficient).

Reguli pentru listele de discuții:

• Folosiți subiecte clare, nu subiecte de forma “Urgent”, “Important”, “Ceva”, “Pentru mâine”, “Reply”. Nu transmiteți mesaje fără subiect.
• Folosiți etichete la început de subiect pentru a încadra domeniul mesajului: (Exemplu: [Testare] / [Debug] / [Intalnire Joi]
• Evitați subiecte de tipul “Re: Re: Re: Re: Re: […]”.
  • Exemplu de Subject prost: “Intalnire”
  • Exemplu de Subject bun: ”[Intalnire] Intrevedere luni, 15 noiembrie 2010, 16:00 pentru stabilire plan de testare”
• Scrieți mesaje scurte și la obiect; nu trimiteți mesaje gigant (nu le va citi nimeni) sau diluate (se va căuta ideea dorită în cadrul paragrafelor).
• Dacă sunt mai multe idei într-un e-mail, separați-le vizual cât mai bine (prin paragrafe noi, prin gruparea in liste).
• Dacă vreți să transmiteți două topic-uri diferite, trimiteți două mesaje.
• Dacă aveți un mail mai lung, puteți scrie un rezumat în prima parte, pentru ca cel care citește să înțeleagă contextul și ce urmează să citească.
• Dacă un e-mail are mai mult de 500 de cuvinte, cel mai probabil era nevoie de un fișier.
• Dacă răspundeți la un mail dintr-un lung șir de răspunsuri, ștergeți din când în când conținutul mesajelor vechi, pentru a nu ajunge la un mail de 2000 de rânduri din care doar 20 mai sunt de actualitate.
• Dacă răspundeți la un mail cu mai multe puncte, răspundeți între acele puncte.
• Dacă aveți link-uri lungi de inclus în mail, le puteți indexa cu [1] [2] [3] și include la sfârșitul mailului, pentru a nu intercala în mesaj linkuri lungi.
• Nu folositi ALL CAPS. ALL CAPS denotă un ton răstit, și nimeni nu apreciază asta.
• Evitați transmiterea de atașamente pe o listă. Încarcă inutil căsuța poștală a tuturor membrilor. Publicați-le pe un site și trimiteți link-ul aferent în e-mail.
• Dacă un mesaj se adresează numai unei minorități a membrilor unei de liste de discuție, trimiteți mesajul privat acelor membri. Nu trimiteți un mesaj unor persoane neinteresate de subiect ( nu trimiteți spam )

Este recomandat să existe o evidență a derulării unui proiect. Deși în general, există o motivație scăzută pentru evidența schimbărilor, este util să existe un set de fișiere de tip jurnal/log care să conțină date despre:

• bug-fix-uri;
• modificări efectuate;
• decizii de proiectare/alegere de componente.

Majoritatea aplicațiilor de (software) project management (inclusiv GitHub) conțin facilități de înregistrare a activității utilizatorilor, precum: adăugarea unui issue, rezolvarea unei probleme, posting-ul unui mesaj, editarea unei pagini wiki.

Există două moduri de a comenta cod: un mod “asistat” și unul “liber”.

Modul de comentare “asistat” este acela în care programatorul urmărește o sintaxă ce poate fi citită și interpretată de un sistem automat de generare de documentație.

• Pentru Java, un astfel de sistem de documentare a codului este http://java.sun.com/j2se/javadoc/
• Pentru .NET există o soluție similară: http://msdn.microsoft.com/en-us/library/b2s063f7.aspx
• Acest mod de comentare are totuși limitările sale, întrucât este conceput mai mult pentru a documenta clasele, interfețele, metodele, legăturile dintre acestea, parametrii care se transmit, în general informații care nu explică implementarea.

Pentru documentarea implementării, modul “liber”, nu există un sistem clar definit, dar următoarele reguli sunt, în general, bine de urmărit:

• Când vreți să explicați o linie, puneți comentariile înaintea liniei respective, nu în dreapta

  // un select simplu pentru a prelua din BD toate campurile din tabelul primit ca parametru
  ResultSet rs = st.executeQuery("select * from " + tableName);
  ResultSetMetaData metadata = rs.getMetaData();

• Dacă o bucată de cod este incompletă/neoptimizată și există șanse ca ulterior să se mai lucreze la ea, folosiți cuvinte cheie:
  • BUG/FIX: Pentru a marca un bug care nu a fost încă eliminat, sau un fix. De multe ori un fix introduce bug-uri noi, astfel este bine să documentați locurile în care ați făcut modificări și ați schimbat comportamentul programului.
  • TODO: Puteți folosi acest cuvânt cheie pentru a marca un punct din program unde se pot aduce îmbunătățiri/ unde mai trebuie completat ceva. Există medii de dezvoltare care pot chiar recunoște astfel de cuvinte cheie și pot crea o listă de TODO-uri.

    // TODO: check data input

• Comentați și explicați cât mai clar; nu mergeți pe ideea “lasă că știu eu ce am vrut să fac aici”.
• Nu exagerați cu diverse comentarii inutile. Exemplu:

  // increment i
  i++;

• La această adresă găsiți sfaturi legate de comentarea corespunzătoare a codului.

Pentru amuzament, consultați pagina What is the best comment in source code you have ever encountered?

Întâlnirile reprezintă un mod de comunicare vital pentru realizarea unui proiect, fiind folosite în special pentru a lua decizii în anumite situații, pentru a găsi soluții și pentru a analiza progresul actual al proiectului precum și planul de lucru pentru perioada următoare.

Ca regulă generală, pentru ca o întâlnire să fie eficientă, aceasta trebuie să fie cât mai scurtă și să implice doar oamenii direct interesați / în cunoștință de cauză. De exemplu, in metodologia SCRUM (metodologie de tip Agile), se recomandă întâlniri cu timp fix de 15 minute. Nu se permite depășirea timpului. Astfel, participanții au fiecare un timp limitat pentru a își expune ideile, și sunt astfel obligați să își structureze și rezume ideile înainte de întâlnire.

Întâlnirile SCRUM au doar caracter informativ. Astfel, fiecare participant prezintă statusul acțiunilor de care este responsabil fără să se dezbată eventualele probleme. Problemele ce nu pot fi rezolvate la sursă se scalează către superior.

Planificarea întâlnirilor trebuie să fie efectuată de comun acord, pentru a nu interfera cu programul celorlalți / pentru a nu apărea suprapuneri. Doodle este unul din cele mai cunoscute site-uri create pentru acest scop.

Se recomandă, de asemenea, folosirea aplicațiilor de tip calendar pentru stabilirea întâlnirilor și pentru notificarea participanților. Există aplicații Desktop precum Microsoft Outlook, Evolution, Mozilla Sunbird sau aplicații web precum Google Calendar. Mai multe informații despre aplicații de calendar sunt prezentate pe Wikipedia.

Pentru ca o întâlnire să fie eficientă, trebuie ca cel care organizează întâlnirea să înțeleagă răspunsul la următoarele întrebări, în funcție de care să iau deciziile aferente. Care este scopul întâlnirii? - Este important ca o întâlnire să aibă la bază un scop precis. Care este rezultatul scontat în urma întâlnirii și cum poate fi el cuantificat? - Este bine să existe un target clar stabilit, sub forma unui output ce trebuie să rezulte din întâlnire. La sfârșitul întâlnirii, situația proiectului trebuie să fie diferită decât la începutul întâlnirii: o decize luată, un set de probleme clarificate, un impas depășit, etc. Cine trebuie să participe la întâlnire? - Este vital pentru succesul unei întâlniri ca la aceasta să participe persoanele interesante / persoanele care au răspunsuri / persoanele care cunosc proiectul/aspectul care va fi discutat.

De asemenea, atât din respect pentru timpul celor implicați, dar și pentru a fi o întâlnire eficientă, este recomandat ca înainte de întâlnire, invitații să fie informați de:

• scopul întâlnirii
• aspectele ce vor fi discutate
• rezultatele așteptate
• durata estimată a întâlnirii

În plus, organizatorul întâlnirii ar trebui să:

• planifice o locație adecvată
• creeze o agendă de discuție

Înainte de începerea discuţiilor:

• O persoană trebuie să fie desemnată să noteze o minută cu cele discutate.
• Coordonatorul întâlnirii va enumera pe scurt ce urmează a fi discutat.

Pe parcursul întâlnirii:

• Coordonatorul întâlnirii trebuie să încurajeze discuția.
• Pentru a fi eficientă, discuția trebuie să fie axată pe argumente.
• Coordonatorul este cel ce va “arbitra discuția”.
• El trebuie să aibă și rol de “focus-man”, și anume să aibă grijă ca discuția să se concentreze pe temele importante, să nu se divage de la scop.
• Dacă se ajunge la un impas din lipsă de informații, se poate programa o întâlnire ulterioară, până la care anumiți membri ai echipei vor avea ca task obținerea informațiilor necesare.

La sfârșitul întâlnirii:

• Se trece prin agenda întâlnirii, pentru a verifica dacă au fost acoperite toate aspectele.
• Se trag concluziile.
• Minuta redactată pe parcursul întâlnirii este distribuită factorilor de interes / echipei.

Se recomandă existența unui document sau pagini wiki care să fie completată înainte, în timpul și după întâlnire. O posibilă structură a acestei pagini este:

* Topic întâlnire
* Dată/timp întâlnire

===== Agendă =====

-- se completează la planificarea întâlnirii
* item1
* item2

===== Participanți =====

-- se completează înainte de începerea discuţiilor
* participant1
* participant2

===== Discuții =====

-- minuta întâlnirii pe parcursul discuției
* Inițiale1: ...
* Inițiale2: ...

===== Decizii/concluzii =====

-- imediat după încheierea discuției
* ...
* ...

Link-ul la acea pagină sau documentul aferent este transmis participanților după încheierea întrevederii.

Brainstorming este o tehnică de grup creativă proiectată pentru a genera un număr mare de idei pentru soluția unei probleme.

Un set de utilitare precum FreeMind și Mind Manager sunt folosite pentru brainstorming/mind-mapping.

În orice proiect există momente de impas în care o decizie trebuie luată, dar există mai multe opțiuni, și membrii echipei au păreri distincte.

În aceste situații, cel mai important lucru de avut în vedere este faptul că în multe situații, o decizie greșită poate fi mai puțin dăunătoare decât un impas pe termen lung. Cu alte cuvinte, leader-ul trebuie să își asume uneori o decizie pentru a scoate echipa din impas. Chiar dacă decizia este greșită, o decizie luată în timp util poate fi corectată în momentul în care lucrurile merg prost; pe de altă parte, dacă echipa rămâne în impas, nu se ajunge nicăieri și proiectul nu înaintează. Mai rău, se poate ajunge în situația în care o decizie este impusă în momentul în care echipa nu mai are opțiuni din lipsă de timp.

Există mai multe metode prin care un grup poate să ajungă la o decizie, fiecare având avantajele și dezavantajele ei, în funcție de situație:

* Competiția ideilor - fiecare opțiune este combătută până când toată lumea ajunge la aceeași părere * Compromisul - este adoptată o idee de mijloc, care echilibrează avantajele și dezavantajele * Votul - utilă mai ales pentru decizii obiective (Exemplu: decizii de design) * Impunerea - utilă în caz de impas. Dacă proiectul stagnează, conducătorul trebuie să își asume decizia pentru a merge mai departe * Încrederea în persoana care cunoaște cel mai bine domeniul / are cea mai multă experiență

Uneori, o decizie greu de luat depinde de evaluarea unui risc. În cadrul unui proiect care “merge în necunoscut” apar o serie de riscuri. Unele variante prezintă anumite riscuri, alte variante de decizie prezintă alte riscuri. Problema este cum decidem ce variantă să alegem, pentru a minimiza riscul.

Riscul are în general 2 aspecte:

• probabilitatea - Care sunt șansele să aibă loc evenimentul?
• gravitatea - Cât de grav este dacă are loc?

O metodă general recomandată de analiză a riscului este de a aloca fiecărui risc identificat 2 note, una pentru probabilitate și una pentru gravitate. Riscul poate fi analizat fie grafic, fie ca o sumă a celor 2 note. Dacă folosim o scară de la 1 la 10, și un eveniment primește nota 16, în mod cert acesta trebuie considerat. In cazul in care se cunosc probabilitatea riscului si impactul pe care il are acesta in cadrul proiectului (numar de zile sau costuri), riscul va fi calculat ca produsul dintre probabilitatea de aparitie a riscului si efectul produs.

• Cât de importantă este decizia? Care sunt consecințele deciziei? Riscurile?
• Cât de clară este imaginea pe care o avem acum asupra problemei? Avem toate datele problemei?
• Au fost cercetate toate opțiunile?
• Au fost implicați / consultați membrii echipei cu cea mai mare expertiză în problema de față?

Deși, în general, se dorește evitarea conflictelor, uneori pot apărea divergențe între membrii unei echipe. Pentru bunul mers al lucrurilor, este recomandat ca aceste divergențe să fie discutate și aplanate cât mai din timp. Orice problemă de tip conflictual neabordată la timpul ei poate escalada și va avea tendința de a se manifesta în momentele critice ale proiectului, când un conflict este ultimul lucru de care are nevoie echipa.

În cazul în care apar divergențe între doi membri ai echipei, este responsabilitatea team leader-ului/PM-ului, eventual cu ajutor din partea unei persoane de la HR să aplaneze conflictul înainte ca acesta să afecteze echipa.

În cazul unui conflict manager - subordonat, lucrurile se complică, și un factor determinant în rezolvarea unui astfel de conflict este dat de maturitatea managerului.

Există mai multe modalități de abordarea a unui conflict

Deși este cea mai “incomodă” poate fi și cea mai eficientă. Presupune determinare din partea liderului și este necesar ca orice critică adusă în cadrul confruntării să fie constructivă. Această abordare se bazează pe un stil de abordare logic, ingineresc, de rezolvare a unei probleme. Problema este expusă direct, sincer, și liderul încearcă să prezinte soluția logică. Dezavantajul metodei este dat de nivelul de sinceritate și de exprimarea directă necesară, care uneori nu va fi privită bine de toți cei implicați.

Avantajul metodei este dat de faptul ca teoretic, prin negociere se poate ajunge la un compromis acceptat de toți factorii implicați. În realitate, de multe ori la final toți cei implicați pot ajunge nemulțumiți de ce au trebuit să cedeze.

Sunt cazuri în care un membru al echipei generează un conflict prin nerespectarea regulilor / standardelor. Uneori, nu este oportună regenocierea / schimbarea regulilor, și deși cu un cost mare de antipatie din partea liderului, trebuie impuse regulile echipei / companiei.

În cazul în care miza este prea mică / nu este ceva urgent, liderul poate alege fie să amâne rezolvarea, fie să accepte o soluție chiar dacă aceasta nu este optimă. Deși această abordare are dezavantaje evidente, este foarte utilă totuși în momentul în care echipa stagnează blocată pe o discuție pe un detaliu nesemnificativ.

Uneori, oamenii pot avea o idee similară, dar sunt blocați într-o discuție contradictorie pe detalii. În astfel de situații, liderul este cel care poate sublinia similitudinile între soluțiile propuse și le poate exploata pentru a sublinia că ideile nu sunt atât de diferite și, în final, poate negocia un consens.

Analizați următoarele situații în care sunt adăugate comentarii în cod. Care dintre ele trebuie evitate? Cum le-ați îmbunătăți?

 int d; // days until deadline

// if the student is at least 18 years of age
if (student.Age> = 18)
{
    // send meeting invitation to the student
    notificationService.SendMessageTo(student, meetingInvitation);
}
else // if the student is younger than 18 years 
{
    // sends a meeting invitation to the student's legal guardian
    notificationService.SendMessageTo(student.Parent, meetingInvitation);
}

// student is eligible for blood donation
if (student.Age >= 17 && student.Weight >= 58.0 && student.Height >= 1.55)
{
    ScheduleBloodDonatingSessionWith(student);
}

In cazul comunicarii verbale dintr-un proiect, a fi un bun receptor (“ascultator”) este la fel de important precum a fi un bun transmitator (“vorbitor”). Exercitiul urmator are rolul de a va ajuta sa va evaluati competentele de ascultare. Aveti 3-5 minute la dispozitie pentru a va aprecia aspectele urmatoare cu o nota de la 1 la 5 (unde 1 reprezinta probleme frecvente de ascultare in aria respectiva, iar 5 lipsa oricaror dificultati de ascultare). Fiti sinceri cu voi insiva! Repetati exercitiul in pereche cu un alt membru al echipei voastre de proiect, dandu-i note acestuia. Asistentul de laborator va va comunica interpretarea rezultatului.

Realizați o întrevedere în cadrul echipei în care discutați despre starea curentă a proiectului. Urmăriți recomandările pentru întâlnire. Aveți în vedere:

• Să țineți o minută a întâlnirii.
• Să stabiliți care au fost concluziile întâlnirii legate de starea proiectului.
• Să stabiliți care au fost deciziile pentru viitor.
• Să stabiliți care sunt sarcinile și responsabilitățile din timpul întâlnirii.

Publicați minutele întâlnirii într-un document Google sau pe o pagină de wiki și transmiteți-i-le asistentului. Cereți feedback asistentului legat de desfășurarea proiectului. Evaluați-vă și apoi cereți și asistentului evaluarea cu privire la încadrarea în timp, cât mai e până la termen, cât mai aveți în desfașurarea proiectului.

Să aveți în vedere o astfel de întâlnire la începutul fiecărui interval de laborator.

• Discutați intern în cadrul echipei de proiect și decideți ce veți documenta în cadrul proiectului, unde veți realiza acest lucru (wiki, pagină web, Google Doc) și cine se va ocupa din proiect de realizarea documentației.
• Discutați pe marginea organizării proiectului. Urmăriți crearea de activități, sarcini, cu reponsabilități și timeline în cadrul proiectului (pana in acest moment, ar trebui sa aveti deja un plan al acestora). Pentru aceasta puteți folosi un document spreadsheet, puteți folosi issue tracker pe GitHub sau puteți folosi soluții de realizarea de diagrame de tip WBS (Work Breakdown Structure).

Lucrați la proiect în conformitate cu planificarea realizată, urmărind sarcinile individuale. Puteți face brainstorming, puteți lua decizii, puteți scrie documentație, puteți scrie cod, puteți face code-review, puteți stabili noi sarcini (management), puteți face planificări, puteți face pair programming. Orice vă este util și important în buna desfășurare a proiectului.