Managementul Proiectelor Software

Laborator 5 - Comunicarea în cadrul proiectului

De adus

  • Documente de raportare
  • Kick-off code (structura directoarelor în cadrul repository-ului, CodingStyle, stabilirea framework-urilor, limbaje)
  • Utilizarea GitHub
  • Toate documentele de până acum puse pe GitHub

Comunicarea (15 minute)

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ă.
      • 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.

Comunicarea verbală

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.

Comunicarea în scris

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).

Liste de discuții & e-mailuri

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 :-) )

Change logs

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.

Comentarii cod

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 (10 minute)

Î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.

Programarea întâlnirilor

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.

Planificarea și organizarea unei întâlniri

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ă ia 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

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.

Decizii (10 minute)

Î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.

Decizia în grup

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ță

Riscul

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.

risc.jpg

CheckList

  • 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ță?

Rezolvarea conflictelor (5 minute)

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:

  • Abordarea directă/dictatorială
    • 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.
  • Negociere
    • 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.
  • Aplicarea regulilor
    • 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.
  • Ocolire
    • Î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.
  • Empatizarea
    • 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.

Exerciții

Exercițiu întâlniri (30 min)

În cadrul unui concurs de design software există 3 etape ale proiectului. Toate echipele trebuie să lucreze la rezolvarea problemei în cadrul unei etape. La sfârșitul unei etape soluția cea mai bună propusă de una dintre echipe va fi implementată și de restul echipelor.
Echipa voastră a fost desemnată câștigătoarea primei etape (Protocol de comunicatie).
Au fost cerute totuși câteva completări la protocolul de comunicație, și raportat un caz în care acesta nu va funcționa corect.

Programare

  • (5minute) Programați o întâlnire la care veți discuta planul de realizare a completărilor. Folosiți doodle.

PM-ul echipei va stabili 3-4 intervale, va distribui link-ul la toți membrii echipei și va lua la finală decizia asupra intervalului final.

Stabilire

  • (5minute) Stabiliți o agendă a întâlnirii. PM-ul va distribui agenda pe mail repectând regulile de comunicare scrisă enunțate anterior.

Întâlnire

  • (20minute) Simulați întâlnirea. Pentru a avea un subiect de discuție real, puteți folosi acest timp pentru a planifica activitățile reale pentru următoarea săptămână.

Atenție:

  • PM-ul va desemna o persoană care va lua notițe
  • PM-ul va desemnea o persoană care va fi responsabilă cu urmărirea agendei discuției
  • La sfârșitul discuției, veți trimite asistentului notițele întâlnirii.

Exercițiu team-building

(20 minute) Faceți parte dintr-o echipă de 8 oameni nou formată (să zicem o echipă tehnică) , și vreți să mergeți la munte în weekend.
Căutați pe net exerciții de team-building și realizați agenda unui excursii de 2 zile în care să folosiți exerciții specifice de team-building pentru a vă cunoaște mai bine, pentru a lucra mai eficient, pentru a comunica mai eficient.

Exercițiu Brainstorming

(10 minute) Lucrați în departamentul de Marketing al unui producător de mașini ecologice.
Directorul companiei v-a cerut să efectuați urgent o schimbare de brand. Aveți 10 de minute la dispoziție să propuneți 3 variante care să conțină:

  • nume mașină
  • slogan
  • logo

Exercițiu rezolvare conflicte

(15 minute) Fie două persoane, un bărbat și o femeie care încearcă să facă rost de un taxi. Se oprește o mașină și amândoi se îndreaptă către ea. Decideți (argumentat) cine va lua taxiul.
Ipoteze:

  • Nu mai există nici un taxi disponibil!
  • Amândouă persoanele au nevoie urgentă de taxi!
  • Nu pot să ia aceeași mașină!
  • Femeia - 40 ani; divorțată, cu 2 copii în întreținere; parteneră la o firmă de avocatură.
    • Trebuie să ajungă la un proces, unde este apărătoarea unui acuzat de crime în serie.
    • Ea știe că este vinovat, dar procesul pare să fie în favoarea ei.
    • Dacă pierde procesul, își pierde locul în cadrul firmei și implicit salariul care îi permite să pastreze copiii în fața soțului, care are o situație financiară mult mai stabilă, dar este alcoolic.
  • Bărbatul - 35 ani; broker;
    • Peste 2 săptămâni se însoară pentru a doua oară, cu o femeie cu 17 ani mai în vârstă, provenind dintr-o familie nobilă și fiind mult mai bogată decât el.
    • Pentru a-i demonstra ei și rudelor ei că nu se căsătorește cu ea pentru bani, ci pentru că o iubește s-a implicat în niște afaceri nu tocmai legale, a folosit banii clienților în investiții neprofitabile și a pierdut banii acestora.
    • Trebuie să ajungă la o întâlnire cu un personaj care ii poate oferi informații din interiorul unei companii, ale cărei acțiuni vrea să le speculeze la bursa sperând să câștige suficient încât să poată pune banii la loc.
    • Dacă nu ajunge la întâlnire la timp, pe de o parte, își pierde postul și poate intra la închisoare, și pe de altă parte pierde și respectul femeii pe care o iubește.

Extra

laboratoare/laborator-05.txt · Last modified: 2012/11/01 11:39 by andrei.maruseac