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 Flow, GitHub Insights, WayDev, LinearB).
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.
