O mai bună colaborare prin introducerea designerilor în procesul de revizuire a codului

Publicat: 2022-03-10

Rezumat rapid ↬ Implicarea devreme a altor persoane, în special a persoanelor din alte discipline, poate fi înfricoșătoare. Inspirându-ne din recenziile de cod, putem îmbunătăți colaborarea atât în propriile domenii, cât și între discipline, fie că este vorba de design, UX, conținut sau dezvoltare.

Colaborarea netedă între dezvoltatori și designeri este ceva la care toată lumea aspiră, dar este notoriu de dificilă. Dar cu web-ul avansat de astăzi, este dificil – dacă nu imposibil – să construiești un produs cu adevărat grozav fără a colabora între discipline. Datorită gamei de tehnologii necesare pentru a construi un produs, produsul poate reuși cu adevărat numai atunci când toate disciplinele - dezvoltatori și designeri, creatori de conținut și strategii în experiența utilizatorului - sunt profund implicate încă de la primele etape ale proiectului. Când se întâmplă acest lucru, toate aspectele necesare pentru a construi un produs se reunesc în mod natural într-un întreg unificat și, prin urmare, într-un produs grozav.

Din această cauză, nimeni nu mai promovează cu adevărat procesele în cascadă. Cu toate acestea, implicarea devreme a altor persoane, în special a celor din alte discipline, poate fi înfricoșătoare. În cel mai rău caz, aceasta duce la „proiectare de către comitet”.

Mai mult, atât designerii, cât și strategii de conținut au adesea experiențe în domenii în care un singur geniu creativ este încă ideal. Dacă altcineva îți dovedește munca, poate fi o amenințare la adresa creativității tale.

Deci, cum poți implica oamenii devreme, astfel încât să eviți cascada, dar și să te asiguri că nu te pregătești pentru proiectare de către comitet? Mi-am găsit răspunsul când am aflat despre recenziile de cod.

Mai multe după săritură! Continuați să citiți mai jos ↓

Aha! Moment

În iulie 2017, am fondat Confrere împreună cu doi dezvoltatori și am angajat rapid primul nostru inginer (eu însumi nu sunt dezvoltator, sunt mai degrabă UX sau designer de conținut). Colaborarea noastră s-a desfășurat surprinzător de bine, atât de mult încât, la retrospectivele noastre, tema recurentă a fost că toți simțeam că „o facem bine”.

Trei oameni zâmbesc și stau unul lângă altul în jurul unui computer. De la stânga la dreapta, ei sunt Dag-Inge (CTO), Ida (CPO) și Ingvild (Sr. Engineer). — Dag-Inge (CTO), eu însumi (CPO) și Ingvild (Sr. Engineer). (Previzualizare mare)

M-am așezat cu colegii mei pentru a încerca să identific exact ceea ce „facem bine”, astfel încât să putem încerca să păstrăm acel sentiment chiar dacă compania noastră a crescut și echipa noastră s-a extins. Ne-am dat seama că am apreciat cu toții că întreaga echipă a fost implicată devreme și că am fost sinceri și clari în feedback-ul nostru unul față de celălalt. CTO Dag-Inge a adăugat: „Funcționează pentru că o facem ca colegi. Nu ești certat și primești doar o listă de defecte”.

Cuvântul „peer” este cel care mi-a dat momentul aha. Mi-am dat seama că cei dintre noi care lucrăm în UX, design și conținut avem multe de învățat de la dezvoltatori atunci când vine vorba de colaborare.

Evaluarea inter pares sub formă de recenzii de cod este esențială pentru modul în care este construit software-ul. Pentru mine, recenziile de cod oferă inspirație pentru îmbunătățirea colaborării în propriile noastre domenii, dar și un model de colaborare între domenii și discipline.

Dacă sunteți deja familiarizat cu recenziile codurilor, nu ezitați să omiteți următoarea secțiune.

Ce este o revizuire a codului?

O revizuire a codului se poate face în diferite moduri. Astăzi, cea mai tipică formă de revizuire a codului are loc prin așa-numitele solicitări pull (folosind o tehnologie numită git). După cum este ilustrat mai jos, solicitările de extragere le permit altor persoane din echipă să știe că un dezvoltator a completat codul pe care dorește să îl îmbine cu baza principală de cod. De asemenea, permite echipei să revizuiască codul: ei oferă feedback cu privire la cod înainte ca acesta să fie fuzionat, în cazul în care are nevoie de îmbunătățire.

Solicitările de tragere au roluri clar definite: există un autor și un evaluator(i).

Ingvild și Dag-Inge stau unul lângă altul și zâmbesc. O săgeată a indicat că Ingvild a trimis cod lui Dag-Inge. — Ingvild (autorul) solicită o recenzie de la Dag-Inge (recenziatorul). (Previzualizare mare)

De exemplu, să presupunem că inginerul nostru senior Ingvild a făcut o schimbare în fluxul de înscriere al Confrere. Înainte ca acesta să fie îmbinat în baza codului principal și să fie expediat, ea (autorul) creează o cerere de extragere pentru a solicita o revizuire de la CTO Dag-Inge (revizorul). El nu va face nicio modificare codului ei, ci doar adaugă comentariile lui.

Ingvild și Dag-Inge se așează unul lângă celălalt. O săgeată indică faptul că Dag-Inge a trimis comentarii despre cod înapoi către Ingvild. — Dag-Inge comentează codul lui Ingvild. (Previzualizare mare)

Depinde de Ingvild cum dorește să acționeze cu privire la feedback-ul primit în recenzie. Ea își va actualiza cererea de extragere cu modificările pe care le consideră potrivite.

Ingvild și Dag-Inge stau unul lângă celălalt. O săgeată indică faptul că Ingvild îi trimite înapoi codul lui Dag-Inge, după ce a căutat prin codul pe care el l-a comentat. — Ingvild își actualizează codul cu modificările pe care le consideră potrivite în lumina comentariilor lui Dag-Inge. (Previzualizare mare)

Când recenzenții aprobă cererea de extragere, Ingvild își poate îmbina modificările cu baza de cod principal.

Ingvild și Dag-Inge stau unul lângă celălalt. Pe recenzia codului pe care Dag-Inge a trimis-o lui Ingvild se afișează o apreciere. Și săgeata indică că ea împinge acest cod în depozitul principal. — După ce Dag-Inge dă degetul în sus, Ingvild poate împinge soluția la producție. (Previzualizare mare)

De ce să vă deranjați să faceți revizuirea codului?

Dacă nu ați efectuat niciodată revizuirea codului, procesul de mai sus poate suna birocratic. Dacă aveți îndoieli, iată o mulțime de postări pe blog și cercetări academice despre avantajele revizuirii codului.

Evaluările codului dau tonul pentru întreaga companie, conform căreia tot ceea ce facem ar trebui să fie deschis controlului altora și că o astfel de control ar trebui să fie o parte binevenită a fluxului dvs. de lucru, mai degrabă decât să fie văzută ca amenințătoare.

— Bruce Johnson, co-fondatorul Full Story

Revizuirea codului reduce riscul. Dacă cineva vă dovedește munca și, de asemenea, să știți că cineva vă va dovedi munca, ajută la eliminarea erorilor și la sporirea calității. În plus, asigură coerența și ajută fiecare membru al echipei să se familiarizeze cu mai mult din baza de cod.

Când este făcută corect, revizuirea codului construiește și o cultură pentru colaborare și deschidere. Încercarea de a înțelege și de a critica munca altora este o modalitate excelentă de a învăța, la fel și obținerea de feedback sincer cu privire la munca ta.

Dacă cel puțin doi oameni se uită întotdeauna la cod, reduceți, de asemenea, ideile despre codul „meu” și codul „dvs.”. Este codul nostru .

Având în vedere aceste avantaje, o revizuire nu ar trebui să fie doar pentru cod.

Examinați principiile pentru toate disciplinele, nu doar cod

Cu recenzii, există întotdeauna un autor și unul sau mai mulți recenzenți. Asta înseamnă că poți implica oamenii din timp, fără a intra în proiectarea comisiei.

În primul rând, trebuie să menționez doi factori importanți care vor afecta capacitatea echipei dvs. de a face recenzii benefice. Nu trebuie neapărat să le fi stăpânit, dar, cel puțin, ar trebui să aspirați la următoarele:

Tu și colegii tăi respectați reciproc și disciplinele fiecăruia.
Ești suficient de sigur pe tine în propriul tău rol, astfel încât să simți că poți și să dai și să primești critici (acest lucru este, de asemenea, legat de siguranța psihologică a echipei).

Chiar dacă nu revizuim codul, există multe de învățat din cele mai bune practici existente pentru revizuirea codului.

În cadrul echipei noastre, încercăm să aderăm la următoarele principii atunci când facem recenzii:

Criticați opera, nu autorul.
Fii critic, dar rămâne amabil și curios.
Faceți diferența între a) Sugestii b) Cerințe, c) Puncte care necesită discuții sau clarificări.
Mutați discuțiile de la text la față în față. (Videoclipul contează)
Nu uitați să lăudați părțile bune! Ce este inteligent, creativ, solid, original, amuzant, drăguț și așa mai departe?

Aceste principii nu au fost de fapt notate decât după ce am discutat de ce colaborarea noastră a funcționat atât de bine. Cu toții am simțit că ni se permite și că ne așteptăm să punem întrebări și să sugerăm îmbunătățiri deja și că motivațiile noastre au fost întotdeauna să construim ceva grozav împreună, și nu să criticăm o altă persoană.

Deoarece eram clari cu privire la tipul de feedback pe care îl dădeam și, de asemenea, ne amintim să ne lăudăm reciproc munca bună, a face recenzii a fost mai degrabă o forță pozitivă decât una demotivantă.

Un exemplu

Pentru a vă face o idee despre modul în care echipa noastră folosește revizuirea în diferite discipline și pe parcursul unui proces, să vedem cum diferiții membri ai echipei noastre au schimbat rolurile de autor și de recenzent atunci când am creat fluxul nostru de înscriere.

Pasul 1: Colectarea cerințelor

Autor: Ida (UX)

Recenzători: Svein (strategie), Dag-Inge (inginerie), Ingvild (inginerie).

O tablă albă arată schițe brute ale unui formular de înscriere. Un bărbat (Svein) și o femeie (Ingvild) zâmbesc și discută. — Echipa s-a adunat în jurul tablei albe. Svein (CEO) la stânga, Ingvild (Sr. Eng), la dreapta. (Previzualizare mare)

Sesiunile de tablă albă pot fi epuizante dacă nu au nicio structură. Pentru a menține productivitatea și creativitatea, folosim structura autor/recenziator, chiar și pentru ceva aparent la fel de simplu precum brainstormingul pe o tablă albă. În acest caz, în care am venit cu cerințele pentru fluxul nostru de înscriere, eu am ajuns să fiu autorul, iar restul echipei și-a dat feedback și a acționat ca recenzori. Deoarece știau și că vor putea să examineze ceea ce am venit la pasul 2 (mai multe oportunități pentru ajustări, sugestii și îmbunătățiri), am lucrat rapid și am reușit să cădem de acord asupra cerințelor în mai puțin de 2 ore.

Pasul 2: Macheta cu microcopie

Autor: Ida (UX)

Recenzători : Ingvild (inginerie), Eivind (design), Svein (strategie).

O captură de ecran a unui document Google care prezintă un formular de înscriere cu comentarii de la membrii echipei Ingvild și Ida. — Prin ridicarea în Google Docs, este ușor pentru oameni din toate disciplinele să ofere feedback din timp. (Previzualizare mare)

În calitate de autor, am creat o machetă a fluxului de înscriere cu microcopie. A avut sens fluxul de înscriere, atât din perspectiva utilizatorului, cât și din perspectiva ingineriei? Și cum am putea îmbunătăți fluxul din punct de vedere al designului și al front-end-ului? În această etapă, era esențial să lucrăm într-un format în care să fie ușor pentru toate disciplinele să ofere feedback (am optat pentru Google Docs, dar s-ar fi putut face și cu un instrument precum InvisionApp).

Pasul 3: implementarea fluxului de înscriere

Autor: Ingvild (inginer)

Revizor: Ida (UX) și Dag-Inge (inginerie).

Ne-am pus de acord asupra fluxului, câmpurilor de introducere și a microcopiei și, așadar, era la latitudinea lui Ingvild să le implementeze. Datorită Surge, putem crea automat adrese URL de previzualizare ale modificărilor, astfel încât persoanele care nu pot citi codul să poată oferi feedback și în această etapă.

Pasul 4: testarea utilizatorului

Autor: Ida (UX)

Revizor: Utilizatorii.

Două femei (Ida și un utilizator) stând una lângă cealaltă în fața unui laptop. — Ida testează utilizatorii cu un buget mic. (Previzualizare mare)

Da, considerăm testarea utilizatorilor o formă de revizuire. Am adus fluxul nostru de înscriere nou construit față în față cu utilizatorii reali. Acest pas ne-a oferit o mulțime de informații, iar cele mai semnificative schimbări în fluxul nostru de înscriere au venit ca urmare.

Pasul 5: Proiectare

Autor: Eivind (design)

Recenzători : Ingvild (inginerie) și Ida (UX).

O captură de ecran de la Slack. Eivind, designerul, a postat o captură de ecran, iar Ida răspunde cu entuziasm. — Prima versiune a fluxului de înscriere s-a bazat pe componentele de proiectare existente. În această etapă, Eivind a dezvoltat câteva componente noi pentru a ajuta la îmbunătățirea designului. (Previzualizare mare)

Când designul apare brusc aici în pasul 5, ar putea să arate mult ca un proces în cascadă. Cu toate acestea, designerul nostru Eivind a fost deja implicat ca recenzent încă de la pasul 2. El a oferit o mulțime de feedback utile în acea etapă și a putut, de asemenea, să înceapă să se gândească la modul în care am putea îmbunătăți proiectarea fluxului de înscriere dincolo de modulele existente. în sistemul nostru de proiectare. La acest pas, Eivind ar putea ajuta, de asemenea, la rezolvarea unora dintre problemele pe care le-am identificat în testarea utilizatorului.

Pasul 6: Implementare

Autor: Ingvild (inginer)

Revizor: Eivind (design), Ida (UX) și Dag-Inge (inginerie).

Și apoi ne întoarcem la implementare.

De ce funcționează recenzia

În rezumat, există întotdeauna un singur autor, evitând astfel proiectarea de către comitet. Implicand o serie de discipline ca recenzori de la început, evităm să avem un proces în cascadă.

Oamenii își pot semnala preocupările devreme și, de asemenea, pot începe să se gândească la modul în care pot contribui mai târziu. Rolurile clar definite mențin procesul pe drumul cel bun.

Proceduri de revizuire regulate

Inspirându-ne din experiențele de cod, facem, de asemenea, proceduri regulate de revizuire cu diferite puncte de vedere, ghidați de următoarele principii:

Trecerea se face împreună.
O persoană este responsabilă cu revizuirea și documentarea.
Ideea este de a identifica problemele , nu neapărat de a le rezolva.
Alegeți un format care să ofere cât mai mult context posibil, astfel încât să fie ușor să acționați mai târziu asupra rezultatelor (de exemplu, InvisionApp pentru recenzii vizuale, Google Docs pentru text și așa mai departe).

Am efectuat proceduri de examinare pentru lucruri precum audituri de accesibilitate, revizuirea solicitărilor de caracteristici, auditarea implementării designului și evaluări euristice de utilizare.

Când facem evaluările trimestriale de accesibilitate, consultantul nostru în accesibilitate Joakim parcurge mai întâi interfața și documentele și prioritizează problemele pe care le-a găsit într-o foaie Google partajată. Joakim ne prezintă apoi cele mai importante probleme pe care le-a identificat.

Întâlnirea față în față (sau cel puțin pe video) pentru a analiza problemele ajută la crearea unui mediu de învățare, mai degrabă decât a sentimentului de a fi supravegheat sau microgestionat.

Trei oameni pe o canapea s-au adunat în jurul unui laptop. Ei discută și zâmbesc. — Analiza accesibilității: Joakim (dreapta) îi prezintă pe Ingvild și Dag-Inge prin problemele de accesibilitate pe care le-a găsit în auditul său. (Previzualizare mare)

Dacă vă simțiți mereu legat de ceva ce urmează să fie lansat sau dacă remediați orice se află în partea de sus a căsuței dvs. de e-mail, recenziile vă pot ajuta să remediați acest lucru. Dacă rezervați o jumătate de zi obișnuită pentru a revizui munca pe care ați făcut-o deja, puteți identifica problemele înainte ca acestea să devină urgente. De asemenea, vă poate ajuta să vă reorientați și să vă asigurați că prioritățile dvs. se mențin pe linia corectă. Poate că echipa dvs. nu ar trebui să înceapă să construiască acea nouă caracteristică înainte de a fi sigur că funcțiile existente se ridică la standardele dvs.

Testarea utilizatorilor este o formă de revizuire

O motivație importantă pentru revizuirea codului este reducerea riscului. Făcând acest lucru de fiecare dată când introduceți o schimbare sau adăugați ceva nou produsului dvs. și nu doar atunci când bănuiți că ceva nu este la egalitate, reduceți șansa de apariție a erorilor sau a funcțiilor necorespunzătoare. Cred că ar trebui să privim testarea utilizatorilor din aceeași perspectivă.

Vedeți, dacă doriți să reduceți riscul de expediere cu probleme majore de utilizare, testarea utilizatorilor trebuie să facă parte din procesul dumneavoastră. Doar ca designerii tăi UX să revizuiască interfața nu este suficient. Mai multe studii au descoperit că chiar și experții în utilizare nu reușesc să identifice toate problemele reale de utilizare. În medie, 1 din 3 probleme identificate de experți au fost alarme false - nu au fost probleme pentru utilizatori în practică. Dar și mai rău, 1 din 2 probleme pe care utilizatorii le-au avut de fapt, au fost trecute cu vederea de către experți.

Omiterea testării utilizatorilor este un risc la fel de mare ca și trecerea peste revizuirea codului.

Revizuirea înseamnă moartea creativității?

Oamenii care lucrează în design, experiență de utilizator și conținut au adesea medii educaționale din școli de artă sau poate literatură, în care singurul creator sau geniul artistic creativ este salutat drept ideal. Dacă te întorci în istorie, acesta a fost cazul și pentru dezvoltatori. De-a lungul timpului, acest lucru s-a schimbat prin necesitate, pe măsură ce dezvoltarea web a devenit mai complexă.

Dacă te agăți de ideea creativității care vine de undeva din adâncul tău, ideea de revizuire s-ar putea simți amenințătoare sau înfricoșătoare. Se amestecă cineva în munca ta pe jumătate terminată? Ai. Dar dacă te gândești la creativitate ca la ceva care poate izvora din mai multe surse, inclusiv dialog, colaborare sau orice formă de inspirație (fie din exterior, fie dintr-un loc din interiorul tău), atunci o recenzie este doar un atu și o oportunitate.

Atâta timp cât construim ceva pentru web, nu există nicio modalitate de a colabora cu alți oameni, fie în domeniul propriu sau al altora. Și o idee bună va supraviețui revizuirii.

Să creăm ceva grozav împreună.