Pod koniec stycznia rozpisałem sobie solidne zadanie: posprzątać bibliotekę.
Osiem punktów, każdy konkretny. Ponad pięćset miejsc z luźnym typowaniem.
Ponad pięćset zapomnianych console.log. Niespójne nazwy fabryk, porozrzucane
notatki „TODO” i „do poprawienia”. Razem oszacowałem to na jakieś osiemdziesiąt
godzin pracy.
Zadanie poleżało w kolejce. Kiedy w końcu po nie wróciłem i zrobiłem przegląd, co tu właściwie zostało — sześć z ośmiu punktów było już nieaktualnych.
Plan kontra stan faktyczny
Kiedy rozpisujesz zadanie, fotografujesz kod w jednym momencie. „Jest źle tu, tu i tu — to zajmie tyle a tyle.” Plan zakłada, że ta fotografia jest aktualna, dopóki nie usiądziesz do roboty.
Tylko że ja nie pracuję sam. Pracuję z AI, i to zmienia tempo, w jakim kod zmienia się poza planem. Połowa rzeczy z mojej listy poprawiła się mimochodem — przy okazji innych zmian, refaktorów, dodawania funkcji. Nikt tego nie zaplanował. Po prostu kod, który stale dotykasz, podnosi swój własny poziom.
Druga połowa była ciekawsza. Część „problemów” wcale nimi nie była.
Czego się nauczyłem o planowaniu
Estymata to nie obietnica, to hipoteza — i ma datę ważności. Im dłużej zadanie leży w kolejce, tym mniej mówi o tym, co naprawdę trzeba zrobić dziś.
Wyciągnąłem z tego prostą zasadę: zanim usiądę do większego zadania z kolejki, najpierw sprawdzam, ile z niego jeszcze żyje. Nie zakładam, że lista sprzed trzech tygodni opisuje obecny stan. Często połowy punktów już nie ma, a połowa tego, co zostało, to rzeczy, które przy bliższym spojrzeniu wcale nie wymagają ruchu.
Najtańsza praca to ta, której się nie wykona, bo okazała się niepotrzebna. Drugą najtańszą jest ta, którą odrzucisz na etapie planu, zanim w nią włożysz choćby godzinę.