Nie wiem, ile czasu oszczędza mi mój system – bo żaden pomiar oszczędzonego czasu, który dotąd robiłem, nie przetrwał konfrontacji z rzeczywistością. Piszę o automatyzacji własnego życia od miesięcy, mam działające pętle w ośmiu dziedzinach, a na najprostsze pytanie – „ile minut dziennie to zwraca?” – nie mam odpowiedzi z pomiaru. Mam tylko szacunki, a szacunek własnego dzieła jest najsłabszym rodzajem dowodu, jaki istnieje.
Ten tekst jest o tym, dlaczego czterokrotnie próbowałem to policzyć i czterokrotnie nie wyszło. Nie ma tu liczby na końcu. Jest metoda i cztery konkretne przeszkody, bo każda z nich wystąpi u każdego, kto spróbuje zmierzyć własną automatyzację.
Co właściwie chciałem zmierzyć
Jedna tabela na osiem dziedzin
Zaczęło się od skromnego założenia: jedna tabela, osiem wierszy. Po jednym na dziedzinę – finanse, trening, spiżarnia, zdrowie, cyfrowy bliźniak, nauka, logistyka, kariera. W każdym wierszu: ile operacji system wykonał sam w danym miesiącu, ile minut zajęłaby mi każda z nich ręcznie, iloczyn tych dwóch liczb.
Jak te osiem dziedzin jest u mnie poukładane – co jest mózgiem, co ciałem, a co pamięcią – opisałem w tekście mój cyfrowy bliźniak: dlaczego to nie jest agent AI.
Dane na to wyglądały na gotowe. Każda zatwierdzona decyzja zapisuje się w bazie razem z wynikiem i powodem – zbudowałem to tak od początku, żeby móc cokolwiek cofnąć. ActivityWatch zbiera u mnie czas pracy przy komputerze równie długo. Czyli: historia działań systemu jest zapisana, historia mojego czasu jest zapisana, pozostaje je zestawić.
Przeszkoda pierwsza: zapytanie, które nie kończy się w czasie
Osiem baz, osiem zapytań, zero wyników
Osiem dziedzin to u mnie osiem oddzielnych baz danych, nie osiem tabel w jednej. To nie jest problem zapytania, tylko architektury. Zapytanie, które liczy całą tabelę naraz, musi wejść do wszystkich ośmiu, policzyć w każdej operacje po typie i po miesiącu, a potem to złożyć. Dlaczego jest ich osiem i co ten podział kosztuje, rozpisałem w tekście osiem baz danych, jedna droga dostępu.
Zadanie, które to robi, ma u mnie twardy limit dziesięciu minut na jedno uruchomienie. Trzy kolejne podejścia przekroczyły ten limit i zostały przerwane. Przerwane zadanie nie zapisuje częściowego wyniku, więc po trzech próbach miałem dokładnie tyle, ile przed pierwszą: zero wierszy.
Pouczająca jest tu nie technika, tylko to, skąd ten limit się wziął. Limit dziesięciu minut nałożyłem sam, celowo, żeby żadne pojedyncze zadanie nie zablokowało kolejki na godzinę. Zabezpieczenie zadziałało dokładnie tak, jak miało. Po prostu żadne z moich zadań nigdy wcześniej nie potrzebowało tyle czasu, więc nie wiedziałem, że ten limit jest też granicą tego, co potrafię o sobie policzyć.
Przeszkoda druga: nie wiem, z czym porównuję
Brak punktu odniesienia zamiast liczby
Nawet gdyby zapytanie przeszło, dostałbym liczbę operacji, a nie liczbę oszczędzonych minut. Druga liczba wymaga punktu odniesienia: ile zajmowało mi to, zanim system to przejął.
Tego punktu nie mam dla niczego, co zbudowałem przed rozpoczęciem pomiarów. ActivityWatch zna stan „po”, nie zna stanu „przed”. Przy automatyzacjach z ostatnich lat nie ma do czego odjąć – nie zmierzyłem ich ręcznego wariantu, bo wtedy nie przyszło mi do głowy, że kiedyś będę chciał pokazać różnicę.
Da się to obejść dwiema drogami i obie są uczciwe, ale żadna nie jest pomiarem historii. Pierwsza: zmierzyć ręczny wariant teraz, raz, z zegarkiem, i tę jedną liczbę przemnożyć przez liczbę wykonań. Druga: wyłączyć jedną automatyzację na tydzień i zmierzyć, co wraca na mnie. Druga jest dokładniejsza i dlatego kosztowniejsza.
Przeszkoda trzecia: własna dokumentacja się nie zgadza
Kiedy zacząłem przygotowywać to zestawienie, trafiłem na coś, czego nie oczekiwałem. Struktura systemu jest opisana jawnie w architekturze projektu, a mimo to liczba wykonawców – komponentów, które realnie uruchamiają działanie po zatwierdzeniu – jest w moich własnych notatkach podana dwa razy i obie liczby są różne: 27 zarejestrowanych w jednym miejscu, 16 używanych w drugim. Do wyjaśnienia przyjąłem 16 jako liczbę roboczą, a 27 potraktowałem jako rozmiar rejestru, nie liczbę pracujących rzeczy.
To nie jest zły stan systemu – jedna liczba liczy wpisy w rejestrze, druga liczy to, co rzeczywiście dostaje zadania. To jest zły stan opisu systemu. I jest to dokładnie ten rodzaj błędu, który unieważnia pomiar: gdybym policzył oszczędzony czas, mnożąc przez liczbę wykonawców, dostałbym wynik zawyżony o 70 procent i nie miałbym powodu tego zauważyć.
Mam natomiast liczby, których jestem pewien, bo pochodzą wprost z konfiguracji, a nie z notatek: 39 polityk, z tego 33 włączone i 6 wyłączonych. Jak te polityki decydują o tym, co system robi sam, a o co pyta, opisałem w tekście miesiąc, w którym system przestał pytać.
Przeszkoda czwarta: liczba, której nikt nie sprawdzi, puchnie
Liczba, której nikt nie przycina
Najtrudniejsza przeszkoda nie jest w bazie danych. Żaden pomiar oszczędzonego czasu, którego nikt nie weryfikuje, nie jest pomiarem. Przez cały czas, kiedy nie miałem pomiaru, miałem szacunki – i te szacunki rosły. Nie przez nieuczciwość, tylko dlatego, że nic ich nie przycinało. Liczba, której nikt nie weryfikuje, zawsze rośnie w kierunku, który jest wygodny dla osoby, która ją podaje.
To jest powód, dla którego ten tekst istnieje w tej formie. Wolę opublikować „nie mam tej liczby” niż opublikować liczbę, której nie potrafię obronić w odpowiedzi na jedno pytanie o metodę.
Co zmieniłem w podejściu
Mniej precyzji, większa powtarzalność
Po trzeciej nieudanej próbie przestałem naprawiać zapytanie i zmieniłem zakres. Dobry pomiar oszczędzonego czasu musi być powtarzalny, zanim będzie dokładny. Zamiast jednej tabeli na osiem dziedzin – jedna dziedzina na jedno uruchomienie. Pierwsze w kolejce są finanse, bo tam operacje są najlepiej opisane i najłatwiej policzalne. Sześć linii, trzy konkretne odczyty, nic więcej.
Jeśli finanse wrócą z liczbą w ciągu jednego uruchomienia, pozostałe siedem dziedzin idzie tą samą drogą. Jeśli nie wrócą, zostaje jedno wyjście, które odkładałem: podnieść limit dziesięciu minut na tę jedną rzecz i przyjąć konsekwencje dla kolejki.
Czego ta historia nie dowodzi
Pomiar oszczędzonego czasu, którego nie mam, nie jest argumentem przeciw automatyzacji. Nie dowodzi, że system nie oszczędza czasu. Dowodzi, że ja tego nie zmierzyłem – to dwie różne rzeczy i mieszanie ich byłoby takim samym nadużyciem jak szacunek podany jako pomiar.
Nie dowodzi też, że pomiar jest niemożliwy. Dane są na dysku i zbierają się dalej; nie zostały zapytane, a nie: nie istnieją. Różnica między „nie wiem” a „nie da się wiedzieć” jest tu całkowita i jestem po pierwszej stronie.
Jedna rzecz z tego jest dla mnie pewna i warta powiedzenia komuś, kto zaczyna. Zmierz ręczny wariant, zanim go zautomatyzujesz. Jedno uruchomienie z zegarkiem, zapisane w notatce z datą. To kosztuje pięć minut raz i jest jedyną rzeczą, której nie da się odzyskać później – kiedy automat już działa, stan „przed” przestaje istnieć. Zbudowałem osiem dziedzin automatyzacji i nie zrobiłem tego ani razu. Które z nich zostały u mnie na stałe, a które wyłączyłem, spisałem osobno: 10 automatyzacji, które faktycznie działają.
