Technologas #9: Kaip įvertinti, kada programuotojai dirba efektyviai?

Buenos dias! Naujasis #Technologas bus kiek kitoks, šįkart turiu tik vieną temą. Istorija prasidėjo paprastai – neseniai man paskambino vienas bičiulis iš ZealiD kompanijos ir uždavė tokį elementarų klausimą: o kaip jūs matuojate savo kompanijos programuotojų našumą? Prigautas nepasiruošęs, vietoje suimprovizavau greitą atsakymą apie kelias pagrindines taisykles, tačiau žinau, kad iš tikrųjų čia viskas gerokai sudėtingiau. Šiandien noriu surasti tą objektyviausią būdą (-us), kaip nustatyti, ar programuotojas dirba efektyviai.

Kartu kviečiu padiskutuoti ir pasidalinti savo patirtimi.

Pagrindinės žaidimo taisyklės

Visų pirma, našumo kriterijai turi būti aiškiai išreikšti skaičiumi, nes kitaip tai bus tik pasvaičiojimai. Svarbu neįsivesti dvejetainės sistemos: ar žmogus X gali dirbti našiai, ar ne. Atmetus ją, gilesniam vertinimui turiu tokius kriterijus:

  • Rezultatai gali būti pamatuojami ir iš anksčiau darytų sprendimų ar anksčiau įgyvendintų projektų (atkrenta visi kriterijai, susiję su estimates, epics ir burndown charts, nes ne visuose projektuose jie yra taikomi);
  • Rezultatas turi matytis iš karto;
  • Nereikia tikėtis, kad rasiu universalų matuoklį, kuris galės palyginti visus ir pagal viską.

Turėdamas tokius pamatus galvoje, ėmiau interneto platybėse tyrinėti, kaip našumą matuoja kiti. Suprantu, kad tai klausimas ne vienam prisėdimui, ir yra daugybė kompanijų, kurios savo veiklą grindžia vien šiuo aspektu (Pluralsite FlowGitHub InsightsWayDevLinearB). 

Našumo matavimo kriterijai

Na, bet visiems reikia nuo kažko pradėti (net Pele pradėjo savo karjerą nuo futbolo kamuolio, padaryto iš laikraščių). Tai pradėjau tikrinti, kas mūsų organizacijai tinka, o kas ne. Turiu tokius variantus:

  • LOC (Lines Of Code), commitai į versijavimo sistemą yra pakankamai banalus būdas matuoti produktyvumą, tad, jums leidus, judėsiu prie kitų;
  • Siūlymų apjungti išsišakojusias repozitorijas (pull request) kiekis. Tai != LOC != commitų kiekiui, nors ir panašu. Tai pasako, kiek funkcijų/vabalų (bugų) programuotojas sutvarkė. Aišku užduotis != užduočiai, funkcija != funkcijai, bet dirbant prie vieno kliento, darant tokias pačias užduotis turėtų gautis panašus rezultatas. Bet čia neįvertinama, kiek laiko užtruko padaryti tą užduotį, nes galima problemą išspręsti ir su 10-čia siūlymų, galima ir su vienu;
  • Galimybės (Opportunity) parodo, kiek laiko sutaupytume verslui automatizuodami vieną ar kitą procesą. Su šia metrika bėda ta, kad labai sunku tokią situaciją pritaikyti kiekvienam komandos nariui. Žinau daug galimybių ir jas galima įvardinti konkretiems žmonėms, tačiau visiems bendrai to padaryti, deja, nepavyks;
  • Dar vienas man patikęs matas – tai laiko, praleisto prie atitinkamos funkcijos, kiekis virš numatyto. Nesvarbu, kokia bus galutinė kodo kokybė, nesvarbu, ar nebus vabalų – klientas liks nepatenkintas, jei kodas nebus pristatomas laiku. Bet kaip visada, bėda su šiuo kriterijumi tokia, kad matuojamas ne pats našumas, o galimybė tiksliai numatyti laiką. Tai vienas iš vertingų kriterijų, bet toli gražu ne vienintelis;
  • Testuotojo grąžinimo santykis (QA Kickback Rate). Kai programuotojai pabaigia savo darbą ir galvoja, kad funkcija, kurią jų pakeitimas įgyvendina, yra baigta, jie perduoda savo darbą testuotojams. Jei testuotojas randa spragą, grąžina programuotojui. Skaičiuojant tokį santykį ir veikia ši metrika. Man ji patinka, bet kartu ją ir labai sunku išmatuoti. Ar matuoti pagal besikartojančius siūlymus apjungti šakas (pull request)? Bet kaip tuomet žinoti, kur yra funkciniai pasikeitimai, o kur programuotojo nedadaryta funkcija?
  • Kodo peržiūros (Peer Code Reviews) yra labai svarbus kriterijus tobulėjant programuotojo įgūdžiams. Kriterijus fainas, tik jo apibrėžti taip paprastai nepavyksta – vieni komentarai yra reti, bet labai gerai pataiko į taikinį, o kiti skirti tik stiliaus klaidoms pastebėti;
  • Klientų pasitenkinimas (Customer satisfaction) – tai ne tiek kiekvieno nario indėlis, kiek visos komandos. Jį galima pamatuoti pasitelkiant apklausas;
  • Code Churn: skaičiuojama, kiek kodo buvo pakeista. Labai įdomus kriterijus. Jį pritaikius gaunu labai intriguojančius rezultatus: paėmiau vieną projektą, nutryniau vardus ir priskyriau vieno mėn. rezultatus. Projekto vadovas atspėjo visus savo komandos narius.
  • Standup notes: labai išsamus kriterijus, bet priklauso ir nuo jį išgirstančių ausų.
  • Machine Learning – galima ir taip matuoti našumą. Neišbandžiau šio būdo, bet būtų laaabai įdomu. Bėda ta, kad naudojamas juodosios dėžės (black box) principas, kai gaunamas tik rezultatas, o procesas lieka neaiškus. Ir net jeigu rezultatas yra teisingas, tu negali pasakyti, kodėl ar kaip jis buvo apskaičiuotas.

Be tradicinių ir objektyvių „matuoklių“ yra ir keli alternatyvūs kriterijai, kuriais galime pasverti ne tik programuotojų darbą, bet darbuotojų dėkingumą ir darbo vertinimą. Pavyzdžiui, „ačiū“ pasakymas per tam skirtą Slacko kanalą.

Ne mažiau svarbūs alternatyvūs kriterijai

Be tradicinių ir objektyvių „matuoklių“ yra ir keli alternatyvūs kriterijai, kuriais galime pasverti ne tik programuotojų darbą, bet darbuotojų dėkingumą ir darbo vertinimą. Pavyzdžiui:

  • „Ačiū“ pasakymas per tam skirtą Slacko kanalą;
  • Geras žodis prie kavos aparato;
  • Paieška per el. paštą tokių žodžių kaip: ačiū, nuostabu, faina, smagu, puiku ir t.t.

Tai kokie matavimo metodai veikia geriausiai?

Kriterijų radome krūvą, metas juos sudėti į atitinkamas lentynas. Galime reziumuoti kelis pagrindinius principus:

  • Laiko, praleisto prie atitinkamos funkcijos, kiekis virš numatytoTestuotojo grąžinimo santykisKodo peržiūros ir Code Churn man pasirodė verti tolimesnio gilinimosi ir platesnių išbandymų praktikoje. Jie yra nesunkiai pamatuojami ir suteikia vertingos informacijos;
  • Ką matuosi, tą ir gausi. Skamba banaliai, bet nereikėtų šios elementarios tiesos pamiršti;
  • Beprasmiška lyginti nepalyginamus dalykus: skirtingos komandos + skirtingi projektai yra niekaip nesuderinami su šiomis metrikomis.

Taigi, didelę dalį informacijos, kurią čia išdėsčiau, verta atsinešti į artimiausią našumo vertinimo sesiją (performance review) ir ją aptarti ten. Vis tik, beieškodamas maksimalaus efektyvumo, labai NEnorėčiau, kad Adeo komandoje įgyvendintume tokį sprendimą, kuris motyvuotų atlikti štai tokius veiksmus:

O kaip jums, ar teko bandyti objektyviai įsivertinti savo produktyvumą? Galbūt neapžvelgiau kažkokio svarbaus metodo? Kokias našumo metrikas mums verta įsivesti Adeo Web darbuose?