Dziennik decyzji dla startupów
Startupy podejmują setki decyzji tygodniowo. Większość ginie w wątkach Slacka i zapomnianych spotkaniach. Zbuduj dziennik decyzji, który naprawdę działa.
By Ellis Keane · 2026-03-16
W 1986 roku prom kosmiczny Challenger rozpadł się 73 sekundy po starcie. Późniejsze śledztwo wykazało, że inżynierowie Morton Thiokol zgłaszali poprzedniej nocy obawy dotyczące uszczelek O-ring, argumentując, że zimna pogoda sprawia, iż start jest niebezpieczny. Kierownictwo odrzuciło te zastrzeżenia. Decyzja zapadła podczas telekonferencji, a choć istniały wykresy i zeznania, kluczowe uzasadnienie decyzji o odrzuceniu obaw było rozproszone między uczestnikami i nigdy nie dotarło rzetelnie do wyższych szczebli.
Nie porównuję decyzji produktowych waszego startupu do katastrofy promu kosmicznego (cóż, nie większości z nich). Jednak podstawowy wzorzec niepowodzenia jest dokładnie tym, co widzę w startupach każdego tygodnia – tylko przy mniejszej stawce: decyzja zostaje podjęta, jej uzasadnienie żyje w czyjejś głowie lub wątku na Slacku, który zaraz zniknie za ekranem, a trzy miesiące później nikt nie potrafi odtworzyć, dlaczego wybraliśmy podejście A zamiast B. Nie dlatego, że decyzja była błędna – czasem była doskonała – ale dlatego, że kontekst, który ją uzasadniał, wyparował.
"Decyzja zostaje podjęta, jej uzasadnienie żyje w czyjejś głowie lub wątku na Slacku, który zaraz zniknie za ekranem, a trzy miesiące później nikt nie potrafi odtworzyć, dlaczego wybraliśmy podejście A zamiast B." – Ellis Keane
Dziennik decyzji dla startupów to nie ćwiczenie biurokratyczne. To różnica między „próbowaliśmy tego i nie zadziałało" (przydatne) a „chyba kiedyś o tym rozmawialiśmy?" (bezużyteczne).
Anatomia zagubionej decyzji
Pozwolę sobie prześledzić jedną konkretną decyzję przez jej cykl życia, bo abstrakcyjna wersja tego problemu jest mniej przekonująca niż konkretna.
Jest wtorek w lutym. Wasz szef inżynierii i PM toczą dyskusję na Slacku – budować własny system powiadomień czy skorzystać z usługi zewnętrznej. Wątek ma 47 wiadomości (wiem, ale tak to bywa), a przy wiadomości 38. doszli do wniosku, że wolą opcję zewnętrzną, bo własne rozwiązanie zajęłoby trzy sprinty, a termin premiery jest za dwa.
PM tworzy zadanie w Linearze: „Integracja [Usługi X] dla powiadomień." Inżynier je podejmuje i zaczyna pracę. Wątek na Slacku nadal technicznie istnieje, ale nikt go nie zapisuje ani nie linkuje z zadania w Linearze.
Przenieśmy się do maja. Zewnętrzna usługa ma problem z niezawodnością. Ktoś pyta: „Dlaczego w ogóle nie zbudowaliśmy tego sami?" PM pamięta rozmowę, ale nie szczegóły. Szef inżynierii jest na urlopie rodzicielskim. Wątek ze Slacka gdzieś w kanale #engineering z lutego – nikt nie pamięta dokładnej daty, a wyszukiwanie w Slacku zwraca 200 wyników dla hasła „notification" (bo oczywiście każdy zespół ciągle omawia powiadomienia).
Zespół spędza 45 minut na spotkaniu, próbując odtworzyć pierwotne uzasadnienie. Ostatecznie dochodzą do tego samego wniosku – ograniczenie czasowe nadal obowiązywało – ale 45 minut jest stracone i wątpliwości pozostają. Pomnóżcie to przez dziesiątki decyzji, które startup podejmuje co miesiąc, a okaże się, że znaczna część czasu jest poświęcana na ponowne rozpatrywanie wyborów, które zostały już starannie przemyślane.
Dlaczego startupy są w tym szczególnie złe
Duże firmy (z całymi swoimi wadami, których nie brakuje) mają tendencję do kodowania pamięci instytucjonalnej w procesach: rejestrach decyzji architektonicznych, RFC, dokumentach projektowych przechodzących przez formalne cykle przeglądów. Decyzje mogą być pogrzebane w Confluence, ale przynajmniej są gdzieś zapisane.
Startupy nie mają tej infrastruktury, a jej budowanie wydaje się dokładnie takim rodzajem narzutu, którego należy unikać, gdy jest się małym i szybkim. Istnieje rozsądny argument, że „po prostu zapamiętamy" działa przy czterech osobach – i tak jest – aż do momentu, gdy dołącza piąta osoba, która nie ma żadnego kontekstu, dlaczego cokolwiek jest takie, jakie jest.
Tym, co sprawia, że śledzenie decyzji w startupach jest szczególnie trudne, jest też fragmentacja narzędzi. Decyzje zapadają wszędzie: w wątkach Slacka, podczas rozmów na Zoomie, w komentarzach na Notion, w dyskusjach w Linearze, w recenzjach PR na GitHubie, a coraz częściej w prywatnych wiadomościach, które nigdy nie trafiają do wspólnego kanału. Każde narzędzie przechwytuje fragment decyzji, ale żadne nie przechwytuje całości, a linki między nimi są utrzymywane przez ludzką pamięć – co jest (z całą życzliwością) najmniej niezawodną bazą danych, do której mamy dostęp.
Czego dziennik decyzji naprawdę potrzebuje
Jest pokusa, żeby to przeinżynierować. Widziałem zespoły budujące rozbudowane bazy danych w Notion z 15 właściwościami na wpis – typ decyzji, poziom wpływu, status przeglądu, interesariusze, powiązane OKR – które potem nigdy nie były używane, bo nakład pracy na wypełnienie wszystkich tych pól przy każdej decyzji był wyższy niż odczuwana wartość.
Dziennik decyzji dla startupów musi być na tyle lekki, żeby ludzie faktycznie z niego korzystali. Oto co ważne:
Sama decyzja. Jedno zdanie. „Używamy Usługi X do powiadomień zamiast budować własne rozwiązanie." Nie akapit – zdanie.
Kto ją podjął i kiedy. Imię i data. Brzmi oczywisto, ale to właśnie jest najważniejsze, gdy ktoś kwestionuje decyzję pół roku później. Nie chodzi o winę (no, w większości nie) – chodzi o to, żeby wiedzieć, do kogo zwrócić się o pierwotne uzasadnienie.
Jakie alternatywy były rozważane. Dwa lub trzy punkty. „Rozważano własne rozwiązanie (szacunek 3 sprinty, termin zbyt napięty)" i „Rozważano Usługę Y (cena nie skaluje się powyżej 10 tys. użytkowników)." To jest ta część, która zapobiega ponownemu rozpatrywaniu – jeśli alternatywy i ich kompromisy są udokumentowane, zespół nie musi ich ponownie odkrywać.
Gdzie toczyła się dyskusja. Link do wątku na Slacku, zadania w Linearze, komentarza na Notion – gdziekolwiek toczyła się rzeczywista debata. To najbardziej niedoceniane pole. Bez niego wpis w dzienniku jest twierdzeniem bez dowodów. Z nim każdy, kto chce pełnego kontekstu, może przeczytać oryginalną rozmowę.
Co zmieniłoby decyzję. To opcjonalne, ale niezwykle przydatne dla startupów, gdzie kontekst zmienia się szybko. „Wrócilibyśmy do tego, gdyby termin premiery przesunął się o więcej niż 4 tygodnie" lub „Zakładamy, że pozostaniemy poniżej 10 tys. powiadomień miesięcznie." Zamienia statyczny zapis w żywy.
Najlepszy dziennik decyzji dla startupu to taki, który zespół faktycznie wypełnia. Pięć pól, jedno zdanie każde. Jeśli zapisanie decyzji zajmuje więcej niż 90 sekund, system padnie w ciągu miesiąca.
Gdzie go umieścić
Widziałem zespoły wypróbowujące trzy podejścia – wszystkie mają swoje kompromisy.
Baza danych w Notion. Najpopularniejsze i działa całkiem nieźle. Utwórz bazę danych z pięcioma polami powyżej, dodaj szablon, żeby wypełnianie było szybkie, i połącz każdy wpis z odpowiednią stroną projektu. Wada: Notion to miejsce, gdzie żyją specyfikacje, a nie gdzie zapadają decyzje, więc polegasz na tym, że ktoś pójdzie do Notion po tym, jak decyzja zostanie podjęta gdzie indziej. Ten krok „po fakcie" to właśnie miejsce, gdzie pojawia się rezygnacja.
Bezpośrednio w Slacku. Niektóre zespoły używają dedykowanego kanału #decisions i publikują sformatowaną wiadomość dla każdej decyzji. To mniejsze tarcie (decyzja i tak prawdopodobnie została podjęta na Slacku), ale wyszukiwanie w Slacku utrudnia znajdowanie decyzji według projektu lub zakresu dat, a brak strukturyzowanych pól sprawia, że spójność z czasem się pogarsza.
Bezpośrednio w Linearze. Jeśli decyzja dotyczy konkretnego strumienia pracy, zapisanie jej jako komentarza do odpowiedniego zadania w Linearze pozwala trzymać decyzję blisko pracy, na którą ma wpływ. Wada: decyzje obejmujące wiele zadań lub projektów nie mają naturalnego miejsca.
Żadne z tych rozwiązań nie jest idealne, żeby być szczerym. Podstawowy problem polega na tym, że decyzje zapadają w wielu narzędziach, ale dzienniki żyją w jednym, więc zawsze jest ręczny krok, który ma wypełnić tę lukę. Ten ręczny krok jest pojedynczym punktem awarii każdego dziennika decyzji, jaki widziałem.
Co budujemy w Sugarbug
Podejście, które realizujemy w Sugarbug, polega na wykrywaniu decyzji w momencie ich podejmowania w różnych narzędziach, zamiast wymagania, żeby ktoś rejestrował je ręcznie.
Gdy wątek na Slacku dochodzi do konkluzji („OK, wybieramy Usługę X"), gdy dyskusja w zadaniu Lineara zostaje rozwiązana, gdy przegląd PR na GitHubie kończy się zatwierdzeniem – to wszystko są sygnały, że decyzja została podjęta. Sugarbug pobiera te sygnały, klasyfikuje je i łączy z odpowiednimi zadaniami i osobami w grafie wiedzy. „Dziennik decyzji" to nie oddzielna baza danych, którą ktoś musi utrzymywać – to widok decyzji już osadzonych w waszych istniejących narzędziach.
Nadal pracujemy nad dokładnością klasyfikacji (rozróżnienie „decyzji" od „zwykłej rozmowy" jest trudniejsze, niż się wydaje), ale zakład kierunkowy jest taki, że przechwytywanie decyzji u źródła, tam gdzie naprawdę się dzieją, jest bardziej niezawodne niż proszenie ludzi o ich powielanie w oddzielnym systemie.
Jeśli was to interesuje, sugarbug.ai zawiera więcej szczegółów. Ale ręczny system opisany powyżej sprawdzi się w większości startupów dopóki zespół nie urośnie na tyle, że wskaźnik rezygnacji z ręcznego rejestrowania stanie się prawdziwym problemem – w naszym doświadczeniu dzieje się to gdzieś przy 8–12 osobach.
Przestań tracić decyzje w szumie Slacka. Sugarbug przechwytuje je automatycznie z narzędzi, gdzie naprawdę się dzieją.
Q: Co powinien zawierać dziennik decyzji startupu? A: Minimum: sama decyzja (jedno zdanie), kto ją podjął, kiedy, jakie alternatywy były rozważane i gdzie toczyła się dyskusja. Ostatnie pole ma największe znaczenie – bez linku do oryginalnej rozmowy dziennik staje się twierdzeniem bez dowodów, a gdy ktoś zakwestionuje je pół roku później, znów odtwarzacie wszystko z pamięci.
Q: Czy Sugarbug automatycznie tworzy dziennik decyzji z istniejących narzędzi? A: To kierunek, w którym zmierzamy. Sugarbug pobiera sygnały ze Slacka, Lineara, GitHuba, Notion i innych narzędzi, klasyfikując je w graf wiedzy. Gdy wykryje decyzję – zatwierdzony PR, rozwiązaną dyskusję w Linearze, wątek na Slacku zakończony wyraźnym kolejnym krokiem – automatycznie łączy ją z odpowiednim zadaniem i osobami. Wciąż doskonalimy klasyfikację (rozróżnienie „decyzji" od „rozmowy" jest naprawdę trudne), ale pobieranie sygnałów i łączenie działają.
Q: Jak często startup powinien aktualizować dziennik decyzji? A: Idealnie decyzje powinny być rejestrowane na bieżąco, a nie gromadzone tygodniowo. Do piątku uzasadnienie decyzji z wtorku jest już niewyraźne, a szansa, że ktoś rzetelnie wypełni pole „rozważane alternatywy", szybko maleje. Przy ręcznym rejestrowaniu: zrób z tego 90-sekundowy nawyk zaraz po podjęciu decyzji. Przy użyciu narzędzia takiego jak Sugarbug celem jest przechwytywanie w czasie rzeczywistym z narzędzi, gdzie decyzje naprawdę zapadają.
Q: Czy Sugarbug może śledzić decyzje w Slacku, Linearze i GitHubie? A: Sugarbug łączy się ze wszystkimi trzema (i z Notion i Figmą) oraz utrzymuje graf wiedzy relacji między rozmowami, zadaniami i zmianami kodu. Gdy decyzja pojawia się w wątku Slacka, prowadzi do zadania w Linearze i generuje PR na GitHubie, Sugarbug łączy cały łańcuch, umożliwiając śledzenie decyzji od źródła do implementacji bez konieczności ręcznego tworzenia tych linków.
Q: Jaka jest różnica między dziennikiem decyzji a rekordem decyzji architektonicznej (ADR)? A: ADR to zazwyczaj formalny dokument dla istotnych wyborów technicznych – „używamy PostgreSQL zamiast MongoDB" – ze strukturyzowanymi sekcjami na kontekst, decyzję i konsekwencje. Dziennik decyzji dla startupów jest szerszy i lżejszy: obejmuje codzienne decyzje operacyjne (który dostawca, który termin, którą funkcję wyciąć), które ADR uznałby za zbyt małe, żeby je dokumentować. Oba mają wartość; dziennik decyzji pokrywa 95% decyzji, które nie wymagają formalnego ADR, ale nadal muszą być możliwe do prześledzenia.