Метрика брзине која је тихо сломила нашег клијента
Ниједан стори поен није повређен током писања овог текста. Већ су били мртви.
Оснивач са којим радимо увукао нас је прошлог лета на састанак. На екрану је имао графикон. Завршени стори поени по спринту, две године уназад. Линија је упорно ишла навише.
„Погледајте ово“, рекао је. „Продуктивнији смо 40% него пре осамнаест месеци. Па зашто онда делује као да се све распада?“
Погледали смо графикон. Онда смо погледали његов систем за праћење багова. Онда одлив корисника у последњих шест месеци.
Графикон је лагао. Не намерно. Мерио је погрешну ствар.
Како број постане свето писмо
Овај клијент је почео да прати брзину тима (velocity) почетком 2024. Разумна ствар. Већина тимова који раде било шта налик Scrum-у то прати. Њихов VP инжењеринга ју је поставио, представио на месечном састанку борда, и борду се допало. Број расте, борд срећан.
Кад се број једном покаже борду, престаје да буде број. Постаје циљ.
VP је отишао шест месеци касније. Број је остао. Његов наследник је наследио контролну таблу, очекивање борда и неписано правило да брзина мора да настави да расте.
Ево шта нико у том тиму не би рекао наглас: сваки инжењер је тачно знао како да број порасте. Великодушно процењивати. Разбијати посао на мање тикете. Прескочити задатак чишћења. Не јављати се за гадан баг, јер квари просек спринта.
Графикон је наставио да расте. Сви су знали шта се дешава. Нико то није могао да заустави, јер је борд гледао.
Шта смо нашли кад смо заиста погледали
Провели смо два дана прелазећи њихов код и њихове тикете. Не контролну таблу, него стварни посао.
Тестови су се извршавали 47 минута. Пре осамнаест месеци, 9. Нико није имао времена да то поправи јер поправка није вредела ниједан стори поен.
Три од пет њихових кључних сервиса радила су на верзији Node-а којој је подршка истекла осам месеци раније. Тикет за надоградњу је постојао. У беклогу више од годину дана. Једанаест стори поена. Нико га није узео. Једанаест поена потрошених на три мале функционалности померало је графикон више него једанаест поена потрошених на то да се не сломи продукција.
Број багова је порастао 3x у односу на претходну годину. Али багове су процењивали на један или два поена, а функционалности на пет или осам. Па је тим технички „радио више“ док је испоручивао гори производ мањем броју задовољних корисника.
Број на графикону и здравље производа нису имали везе једно с другим. Штавише, кретали су се у супротним смеровима.
Зашто нисмо могли просто да им кажемо да престану
Рекли смо оснивачу: убијте метрику.
Погледао нас је као да смо му предложили да запали канцеларију.
„Борд види овај број сваког месеца. Не могу само да престанем да им га показујем. Чиме да га заменим?“
То је део о коме нико не прича кад вам каже да је метрика лоша. Не можете тек тако да уклоните метрику коју је управа навикла да гледа. Морате да је замените нечим чему више верују. А ако то немате спремно, заглавили сте.
У исту замку смо гледали како упадају сениор инжењери када се противе праћењу брзине. Аргумент им је добар, али немају чиме да је замене. Ништа се не мења и број наставља да расте док производ наставља да се квари.
Морали смо да изградимо замену пре него што смо смели да дирамо оригинал.
Чиме смо је заменили
Нисмо изабрали један број. Изабрали смо четири. Ниједан није савршен. Све их је теже изиграти него стори поене.
Прво: време од „баг пријављен“ до „баг затворен у продукцији“ за најгорих 10% багова. Не просек, јер просек лаже. Бол живи у дугом репу. Ако вашим најгорим баговима треба три месеца да се затворе, то вам говори да ли ваш тим заиста испоручује квалитетан посао.
Друго: број измена испоручених недељно које су дотакле код старији од годину дана. Ово смо украли од навике коју смо изградили интерно. Ако нико не дира стари код, ваш тим га или избегава или га не разуме. Обоје је лоше. Здрав тим се враћа старом коду, прави мала побољшања, брише ствари, рефакторише успут.
Треће: проблеми које пријаве корисници, по активном кориснику месечно. Не сиров број багова. Број багова расте кад испоручујете више функционалности. Проблеми по кориснику узимају раст у обзир. Ако овај број расте док расте и ваша корисничка база, имате проблем који брзина никад неће открити.
Четврто: поверење инжењера у код, како га они сами оцењују. Питамо једном месечно. Једно питање: „Колико сте сигурни у код који испоручујете овог месеца, на скали од 1 до 5?“ Анонимно. Саберемо и покажемо тренд. Кад поверење падне, нешто није у реду, и обично је то видљиво недељама пре него што било која друга метрика то ухвати.
Три месеца смо их борду представљали упоредо са старим графиконом брзине. Онда смо избацили брзину. Нико из борда није питао где је нестала.
Где смо ухватили сами себе
Ово не пишемо са неке безбедне позиције спољног стручњака.
Негде у четвртом месецу ангажмана приметили смо нешто непријатно у вези са сопственим праћењем у Norveon-у. Бројали смо спојене PR-ове недељно као груб пулс тимског учинка. Не за борд, не за било кога споља, само за себе.
Док смо копали по клијентовој историји, морали смо да погледамо и сопствени број.
Два инжењера су доследно спајала највише PR-ова. Они су уједно најчешће испоручивали малу поправку која две недеље касније сломи нешто друго. Један инжењер је спајао најмање PR-ова. Он је уједно био инжењер чији се код никад није враћао као баг, коме су други веровали да им прегледа посао, и који је током претходне године тихо поправио три најгора дела нашег кода.
Наш интерни број је награђивао погрешне људе. Не на неки крупан начин. Нико није добијао отказ ни унапређење на основу њега. Али обликовао је то како смо на ретроспективама причали једни о другима, и људи који су заслуживали више признања добијали су мање.
Убили смо га. Два месеца га нисмо заменили ничим док смо смишљали шта заправо желимо да знамо. Сад уопште не пратимо број PR-ова. Једном месечно сваки инжењер подели једну ствар коју је испоручио а на коју је поносан, и једну ствар у коду коју би волео да је имао времена да поправи. Мања прецизност. Више искрености.
Део који је тешко прихватити
Лоша метрика је гора од никакве.
Без метрике морате да се ослоните на процену, да разговарате са људима и гледате стварни посао. То је споро и не стаје на слајд. Лоша метрика значи да имате број, број делује објективно, и број вас тихо усмерава ка одлукама које вам штете.
Стори поени по спринту нису једини кривац. Видели смо да исто ради и проценат покривености тестовима. Линије кода. Учесталост пуштања у рад. Чак и доступност система кад се мери сама. Сваки број који је лако изиграти и лако представити на крају ће бити изигран и представљен.
Тест који сада користимо пре него што пристанемо да било шта пратимо: ако бисмо шест месеци агресивно оптимизовали за овај број, да ли би производ заиста био бољи? Или бисмо само били бољи у производњи броја?
Ако не можемо искрено да одговоримо, не пратимо га.
Где је тај клијент сада
И даље прате четири метрике. Дуги реп багова им је пао око 60% за осам месеци. Пали су и проблеми по кориснику. Број поверења се најспорије опорављао. Требало је скоро годину дана да се врати тамо где је био пре ере јурења брзине.
То кашњење нешто говори. Поверење које тим има у сопствени рад гради се годинама, а оштети за месеце. Ниједна метрика вас о томе не упозорава у реалном времену. Док контролна табла то ухвати, већ сте изгубили људе који би то поправили.
И даље им помажемо. Нису готови.
Тренутно помажемо другом клијенту да се одвикне од опсесије „учесталошћу пуштања у рад“. Питајте нас за шест месеци да ли је нова контролна табла преживела сусрет са бордом.
