Pasakų taškai

Sprinto planavimas. Komanda ginčijasi, ar ši užduotis verta penkių, ar aštuonių taškų. Susitaria – aštuoni. Ir tada vadovas, visai geranoriškai, paklausia: „tai čia maždaug kiek dienų?“
Va čia ir baigėsi visa pasaka apie story points. Tašką ką tik pavertei pažadu.
Kai leptelėjimas virsta pažadu
Pradinis sumanymas buvo visai racionalus. Jei darbus vertini valandomis, kiekvienas įvertinimas akimirksniu tampa įsipareigojimu: pardavimai parduoda valandas, finansai dalina žmones pagal valandas, nustatomi terminai. Taškai buvo bandymas nuo to pabėgti: sukurti atskirą matą pastangoms, ne laikui, ir leisti komandai sąžiningai pasakyti „mes nežinom, kiek tiksliai užtruks“.
Pastangos, trukmė ir kada bus padaryta tikrai nėra tas pats, tad taškai iš pirmo žvilgsnio makes sense. Ši mintis taip gerai atrodo, kad sukurta visa industrija jai palaikyti.
Yra tik nedidelė problemytė, kad viskas aplink tave kalba valandomis. Sąskaita klientui, sutartis su rangovu, ataskaita valdybai, kitų metų biudžetas, naujų žmonių samdymas – nei vienas iš jų nemoka už „taškus“. Anksčiau ar vėliau kažkas tuos taškus vis tiek paverčia valandomis. Kiekvieną sprintą, kiekvienoje įmonėje. Tą patį vertimą iš naujo išranda kas antras vadovas ir konsultantas.
Vienetas nieko neišgelbėjo
Galėtum tikėtis, kad taškai bent pagerina prognozių tikslumą. Nepagerina.
Iš 37 tūkstančių užduočių 37 projektuose story points rodė stiprų ryšį su realiomis darbo sąnaudomis vos 7 % projektų. Likusiuose – vidutinį arba silpną.1 Kitaip tariant, „aštuoni“ beveik nieko nepasako apie tai, kiek dienų užtruks.
Ir čia teisingai paprieštarausi: juk būtent tame ir esmė. Taškai tyčia neprilipdyti prie laiko – jie matuoja santykinį dydį, ne valandas. Nemalonus klausimas kitas: jei vienetas sąmoningai nieko nesako apie laiką, kodėl visi juo atsakinėja į klausimą „kada“?
Ir tai dar ne viskas. Pažiūrėk, kaip skaičius išvis pasirenkamas. Daug kas, žiūrėdamas į užduotį, mintyse atsako ne į klausimą „kiek pastangų“, o į visai kitą: „ar spėsiu per šį sprintą?“ Tada ranka pati siekia penkių arba aštuonių – nes arba sunku ir privalau baigti iki sprinto galo, arba kiek lengviau, bet vis tiek reikia baigti iki sprinto galo. Visa graži Fibonačio skalė tyliai susitraukia į du skaičius, kurie reiškia tą patį: „taip, imuosi“. Vienetas, kuris turėjo matuoti pastangas, ima matuoti tik tai, ar darbas telpa į dvi savaites.
Atskiras tyrimas su šimtu profesionalių programuotojų parodė dar linksmiau: vertinimas taškais buvo ne tikslesnis už vertinimą valandomis, o dar ir užtruko ilgiau.2
Tikroji bėda – ne vienetas, o ta, kad žmogus, žiūrėdamas į konkrečią užduotį, sistemingai įvertina per mažai. Tai net turi vardą – planning fallacy. Vertindami konkretų darbą atidžiau, matome jo dalis ir mintyse jas sudedame. Ir nuosekliai nuvertiname laiką, kainą ir riziką – neretai net tada, kai sąmoningai pridedame atsargą. Blogiausia, kad to neištaiso net žinojimas: žmonės, kuriems parodydavo jų pačių istoriją – „štai, praeitą kartą prognozavai 34 dienas, užtrukai 55“ – kitą kartą prognozuodavo lygiai taip pat optimistiškai.3
Įskaitant mane. Aš irgi pridėdavau šiokį tokį rezervą „dėl visa ko“, ir vis tiek nespėdavau.
Kodėl buferis – ne melas
Štai čia visa diskusija „taškai ar valandos“ ir prasilenkia su esme. Ginčijamasi dėl įrankių, nors problema visai kitur.
Juk jei įvertinimas baudžiamas – jei „nespėjai per tris dienas“ virsta pokalbiu prie performance review – bet kuris sveiko proto žmogus į skaičių įdės atsargą. Programuotojai „nemoka prognozuoti“ lygiai tiek, kiek tu baudi už tiesų atsakymą.
Kai įvertinimas tampa įsipareigojimu, jis nustoja būti įvertinimu ir tampa derybomis.
Ir kadangi šis polinkis nuvertinti glūdi pačiame žmoguje, spėjančiame apie konkretų darbą, jo nepanaikins joks naujas matas. Pakeisk taškus valandomis, valandas t-shirt dydžiais – tą patį optimizmą tik kitaip pavadinai. Nepamiršk, kad dirbi su žmonėm, kurie mintinai verčia dešimtainės sistemos skaičius į dvejetainę, aštuntainę ir šešioliktainę – koks skirtumas, ar tai bus marškinėlių skalbimo dažnumu remta skaičiavimo sistema, dar lengviau.
Vienintelis realiai veikiantis kelias – nebeklausti žmogaus. Žinau, kaip skamba: pasakyk vadovui „nebeklausk, kiek užtruks“ ir iškart matai ištįsusį veidą – ką??? Bet kalba ne apie tai, kad nustotum domėtis data, bet apie tai, iš kur ją imti, kaip ją nustatyti. Kai kurios komandos nebeklausia žmogaus, o remiasi tuo, kiek darbų komanda iš tiesų užbaigia per savaitę. Iš to skaičiaus ir gaunama prognozė. Data lieka – tik nebėra ištraukta iš drebančio piršto. Užtenka maždaug dvidešimties baigtų darbų, kelių sprintų. Prognozė iš tikro srauto vienoje studijoje klydo apie 20%, o pačių programuotojų spėjimai – 134%.2
Net „devyniasdešimt procentų pasitikėjimo“ intervalai pataiko gal į du iš trijų atvejų. O lietuviškų ar mažos įmonės duomenų, kurie tai patvirtintų vietoje, tiesiog nėra. Bet kryptis aiški: skaičiuok, ką pabaigei, ne ką žadi.
Tad kitą kartą, kai komanda „nemoka prognozuoti“, neklausk, kaip ją išmokyti tiksliau. Paklausk savęs, kas nutiktų tam žmogui, jei jis pasakytų tikslų skaičių – ir suklystų.
m
P.S. Buferis — ne gudravimas, o vienintelis racionalus atsakas į sistemą, kuri baudžia už tiesų atsakymą. Tu nesutaisysi įvertinimo, kol pats įvertinimą laikai įsipareigojimu (Tu sakei, kad užtruks tik 3 dienas!!).
-
V. Tawosi, R. Moussa, F. Sarro, „On the Relationship Between Story Points and Development Effort in Agile Open-Source Software“, ESEM 2022 – 37 440 user stories, 37 projektai. ↩
-
M. Jørgensen, „Relative estimates of software development effort: Are they more accurate or less time-consuming to produce than absolute estimates…“, Information & Software Technology 143 (2021); E. Miranda, J. P. Faria, „An analysis of Monte Carlo simulations for forecasting software projects“, SAC 2021 – ~20% vs ~134% vidutinė paklaida. ↩↩
-
R. Buehler, D. Griffin, M. Ross, „Exploring the ‘planning fallacy’: Why people underestimate their task completion times“, Journal of Personality and Social Psychology 67(3), 1994; D. Lovallo, D. Kahneman, „Delusions of Success“, HBR, 2003. ↩