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:
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:
Reguli pentru listele de discuții:
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:
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 documentarea implementării, modul “liber”, nu există un sistem clar definit, dar următoarele reguli sunt, în general, bine de urmărit:
// 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();
// TODO: check data input
// increment i i++;
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:
În plus, organizatorul întâlnirii ar trebui să:
Înainte de începerea discuţiilor:
Pe parcursul întâlnirii:
La sfârșitul întâlnirii:
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:
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.
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.
Realizați o întrevedere în cadrul echipei în care discutați despre starea curentă a proiectului. Urmăriți recomandările pentru înâlnire. Aveți în vedere:
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 legat de î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.
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); }
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.