Jak znaleźć stare decyzje w Slacku – gdy szukanie zawodzi
Jak znaleźć stare decyzje w Slacku, gdy wyszukiwanie zawodzi. Dlaczego decyzje znikają, logi decyzji nie działają i jak wygląda system świadomy decyzji.
By Ellis Keane · 2026-03-14
Szybkie pytanie: gdzie twój zespół zdecydował, żeby używać webhooków zamiast pollingu? Nie co zdecydowaliście – gdzie ta decyzja jest teraz zapisana, w miejscu, które ktoś dołączający w przyszłym miesiącu mógłby znaleźć?
Jeśli jesteście do nas podobni, szczera odpowiedź mieści się gdzieś między „w jakimś wątku na Slacku, pewnie" a „chyba było to w #eng-backend, może trzy tygodnie temu, i mniej więcej dwie lub trzy osoby były zaangażowane, ale naprawdę nie pamiętam które". Co jest fascynującym stanem rzeczy, jeśli się nad tym zastanowić – bo sama decyzja była na tyle ważna, że zmieniła sposób działania całego systemu, ale najwyraźniej nie na tyle ważna, żeby ktoś zapisał ją w miejscu, które nie jest strumieniem świadomości zorganizowanym według znacznika czasu. I to właśnie jest sedno problemu przy próbach znalezienia starych decyzji w Slacku – informacja jest w całości dostępna, tylko nie jest zorganizowana w sposób umożliwiający odtworzenie jej jako decyzji.
Przez jakiś czas zgłębiałem, jak znaleźć stare decyzje w Slacku, i im głębiej kopię, tym bardziej uważam, że podstawowy problem nie leży w dyscyplinie, nawykach ani żadnej z innych rzeczy, które ludzie obwiniają. To kwestia architektury. Wyszukiwarka Slacka powstała do znajdowania wiadomości, a decyzje nie są wiadomościami – to znaczenie, które zdarza się być wyrażone przez wiadomości. Ta różnica brzmi pedantycznie – aż do chwili, gdy spędzisz dwadzieścia minut, przewijając wyniki wyszukiwania w poszukiwaniu tego jednego spośród siedemnastu wzmianek o „webhookach", gdzie zespół faktycznie zdecydował się ich używać.
Jak naprawdę działa wyszukiwarka Slacka (i gdzie zawodzi)
Bądźmy precyzyjni, bo „wyszukiwarka Slacka jest zła" nie jest właściwą diagnozą – wyszukiwarka Slacka jest naprawdę dobra w tym, co robi. Problem polega na tym, że to, co robi, i to, czego potrzebujesz, gdy szukasz decyzji, to dwie zasadniczo różne rzeczy.
Slack indeksuje wiadomości jako tekst z metadanymi: znacznik czasu, nadawca, kanał i (jeśli masz płatny plan) pełny kontekst wątku. Gdy szukasz „webhook", Slack wiernie zwraca każdą wiadomość zawierającą to słowo, uszeregowaną według kombinacji aktualności i trafności. Możesz zawęzić wyniki za pomocą operatorów wyszukiwania – in:#eng-backend from:@sarah before:2026-02-15 – ale jedyne, co robisz, to filtrowanie tej samej płaskiej listy wiadomości według metadanych. To jest wyszukiwanie słów kluczowych i do znajdowania konkretnej wiadomości, którą ledwo pamiętasz, działa całkiem dobrze.
Ale decyzja nie jest słowem kluczowym. Decyzja to relacja między pytaniem, zestawem opcji, zestawem osób i momentem, w którym grupa zbiega na jedną opcję. Faktyczny tekst decyzji może brzmieć: „no to robimy webhooki, podejście z pollingiem zjada nasz limit zapytań" – co jest potoczne, kontekstualne i ma sens tylko wtedy, gdy już znasz wątek, w którym się pojawiło. Albo może brzmieć: „dobre, zaprototypuję to", co nie zawiera żadnych słów kluczowych związanych z techniczną decyzją, którą reprezentuje.
Na tym polega niezgodność architektury: Slack przechowuje wiadomości chronologicznie i pobiera je według słów kluczowych. Decyzje są semantyczne (dotyczą znaczenia) i relacyjne (łączą się z zadaniami, ludźmi i wynikami). Prosisz chronologiczny system przechowywania o wykonanie semantycznego pobierania danych, a on tego nie potrafi, bo nigdy nie był do tego zaprojektowany. Przepaść między „przeszukiwalny" a „możliwy do znalezienia" okazuje się być ogromna – każda wiadomość w historii Slacka jest technicznie przeszukiwalna, ale to nie znaczy, że decyzja, której potrzebujesz, jest możliwa do znalezienia w praktycznym sensie.
"Slack stworzył jedno z największych repozytoriów decyzji organizacyjnych w historii i prawie nic z tego nie można odtworzyć jako decyzje – każde słowo idealnie zachowane i prawie całkowicie niemożliwe do odnalezienia." attribution: Ellis Keane
Co się dzieje, gdy próbujesz znaleźć stare decyzje w Slacku
Tak wygląda ta niezgodność w praktyce. Powiedzmy, że trzy tygodnie temu twój zespół zdecydował się przejść z pollingu na webhooki dla integracji GitHub. Pamiętasz, że dyskusja odbyła się w #eng-backend i było w niej kilku inżynierów. Szukasz więc „webhook" w tym kanale.
Co dostajesz: każdą wiadomość, w której kiedykolwiek wspomniano webhooki w #eng-backend. Raporty o błędach sprzed sześciu miesięcy. Ktoś zadający pytanie o logikę ponawiania webhooków w zupełnie innym kontekście. Link udostępniony przez kogoś do wpisu na blogu o najlepszych praktykach webhooków (który, w pięknym przejawnie ironii, prawdopodobnie zajmuje wyższe miejsce w wynikach wyszukiwania niż faktyczna decyzja leżąca obok). Sama decyzja – odpowiedź w wątku, gdzie ktoś powiedział, że podejście z pollingiem uderza w limity zapytań – jest zakopana gdzieś na stronie trzeciej, wyglądając dokładnie jak każda inna wiadomość wokół niej.
I to jest scenariusz, w którym mniej więcej pamiętasz, jakich słów użyto. W połowie przypadków decyzje używają języka tak kontekstowego, że równie dobrze mogłyby być zaszyfrowane. „Idziemy z opcją B" nie zawiera słowa „webhook" w ogóle, chociaż opcja B była webhookami. „Dobre, zaprototypuję to" nie zawiera nawet słowa „opcja". Faktyczny moment decyzji jest często najkrótszą, najmniej bogatą w słowa kluczowe wiadomością w całym wątku – bo w tym momencie wszyscy w rozmowie mają już kontekst i tylko potwierdzają zbieżność.
Uważam to za naprawdę ciekawy problem architektury informacji (cóż, ciekawy i też trochę irytujący, gdy to ty szukasz). Slack stworzył jedno z największych repozytoriów decyzji organizacyjnych w historii i prawie nic z tego nie można odtworzyć jako decyzje – każde słowo idealnie zachowane i prawie całkowicie niemożliwe do odnalezienia.
Dlaczego logi decyzji to cmentarz z lepszymi drogowskazami
Standardowa rada, jeśli szukasz rozwiązań, to prowadzenie logu decyzji. Baza danych Notion, dedykowany kanał Slack (ironia tego zdaje się umykać osobom, które to polecają), strona wiki – jedno miejsce, gdzie decyzje są rejestrowane, gdy się pojawiają.
Próbowaliśmy tego. Wytrwało to około sześciu tygodni. Pierwsze dwa tygodnie były świetne – wszyscy byli zaangażowani, wpisy były szczegółowe, log był naprawdę przydatny. W trzecim tygodniu wpisy zaczęły być nieregularne. W piątym tygodniu tylko jedna osoba nadal to aktualizowała, pisząc rzeczy w stylu „zdecydowano coś o auth" bez linków, kontekstu ani wskazania, kto był zaangażowany ani jakie były alternatywy. W szóstym tygodniu cicho przestaliśmy udawać.
Problem nie polega na tym, że naszemu zespołowi brakuje dyscypliny (może i brakuje, ale to nie jest tutaj właściwy problem). Problem polega na tym, że logowanie decyzji nakłada podatek dokładnie w najgorszym momencie. Właśnie miałeś produktywną dyskusję, osiągnąłeś zbieżność, ktoś jest gotowy zacząć budować – i teraz musisz się zatrzymać, otworzyć inne narzędzie, napisać podsumowanie, oznaczyć odpowiednie osoby i dodać link do oryginalnej rozmowy. To od trzech do pięciu minut na decyzję, a dla zespołu podejmującego pięć do dziesięciu ważnych decyzji dziennie w różnych kanałach i wątkach, obciążenie kumuluje się do czegoś, czym nikt nie chce się zajmować.
A system działa tylko przy 100% przestrzeganiu. Log z 70% decyzji jest pod pewnymi względami gorszy niż brak logu, bo teraz sprawdzasz dwa miejsca, nie ufając żadnemu. Sprawdzasz log, decyzji tam nie ma, więc i tak szukasz na Slacku – i wracasz do punktu wyjścia, z tym że straciłeś dwie minuty sprawdzając log.
Decyzje nie są zdarzeniami – są gradientami
Częścią przyczyny, dla której ręczne logowanie zawodzi, jest założenie, że decyzje są dyskretnymi, identyfikowalnymi momentami. W rzeczywistości większość decyzji wyłania się stopniowo przez rozmowę, a „moment decyzji" jest często naprawdę niejednoznaczny.
Zastanów się, jak w praktyce przebiega typowa decyzja inżynierska. Ktoś zgłasza obawę w komentarzu Figmy: „ten wzorzec interakcji może nie działać na urządzeniach mobilnych." Inżynier odpowiada w wątku Slacka, tagując oryginalny komentarz: „tak, sprawdziłem – biblioteka komponentów tego nie obsługuje." Projektant sugeruje alternatywne podejście w tym samym wątku. Inżynier mówi: „dobre, zaprototypuję to." Dwa dni później pojawia się PR implementujący alternatywę, a zgłoszenie w Linearze zostaje zaktualizowane.
Gdzie zapadła decyzja? Czy był to komentarz w Figmie, który ujawnił problem? Wątek Slacka, gdzie zaproponowano alternatywę? Moment, gdy inżynier powiedział „dobre"? PR, który ją zaimplementował? W praktyce decyzja była rozłożona na wszystkie cztery te momenty, rozciągając się na dwa narzędzia i trzy dni. Nie było to zdarzenie, które można by zalogować – był to gradient, który rozwiązał się w wynik, a jedynym powodem, dla którego wiemy, że decyzja została podjęta, jest fakt, że kod się zmienił.
To jest (jak myślę) część, którą większość porad dotyczących „śledzenia decyzji" rozumie błędnie. Traktuje decyzje jak coś, co przechwytuje się, jak zapisanie numeru telefonu. Ale większość prawdziwych decyzji to coś, co rekonstruuje się – patrzysz na to, co się zmieniło, śledzisz wstecz rozmowy, które do tego doprowadziły, i składasz rozumowanie po fakcie. Co oznacza, że potrzebny ci system to nie log. To graf.
Co graf daje, czego log nie może
Graf łączy sygnały w narzędziach i w czasie. Zamiast żeby ktoś ręcznie pisał „zdecydowaliśmy się używać webhooków ze względu na limity zapytań", graf łączy wątek Slacka, w którym omawiano limity zapytań, zgłoszenie w Linearze, które śledziło prace integracyjne, PR implementujący webhooki oraz osoby zaangażowane w rozmowę. Decyzja nie jest zapisywana – jest możliwa do odtworzenia z połączeń między rzeczami, które i tak się już działy.
Praktyczna różnica ujawnia się w konkretnym scenariuszu. Trzy tygodnie po decyzji o webhookach dołącza nowy inżynier i pyta: „dlaczego używamy webhooków zamiast pollingu dla GitHub? Polling wydaje się prostszy." Bez połączonego systemu ktoś mówi „o, zdecydowaliśmy to jakiś czas temu", nikt nie pamięta, który kanał, ktoś spędza piętnaście minut przeszukując Slacka i albo znajduje, albo (co bardziej prawdopodobne) rekonstruuje rozumowanie z pamięci – co jest ryzykowne, bo pamięć jest zawodna, a pierwotne rozumowanie było prawie na pewno bardziej zniuansowane niż to, co ktokolwiek pamięta trzy tygodnie później.
Z grafem inżynier patrzy na zadanie integracji GitHub. Każdy sygnał, który dotknął tego zadania, jest połączony: oryginalna dyskusja o limitach zapytań, wątek, w którym porównywano polling z webhookami, PR implementujący zmianę. Pełny ślad decyzji, od początku do końca, bez szukania czegokolwiek i bez logowania czegokolwiek.
Przepaść nie leży między „dobrym wyszukiwaniem" a „złym wyszukiwaniem" – leży między pobieraniem według słów kluczowych a pobieraniem według relacji. Decyzje są definiowane przez połączenia z zadaniami, ludźmi i wynikami, a nie przez słowa użyte do ich wyrażenia.
Koszty, które nie pojawiają się na żadnym pulpicie
Jestem szczerze sceptyczny wobec każdego, kto twierdzi, że ma dokładne liczby dla takich miękkich kosztów (statystyki z gatunku „zespoły tracą X godzin tygodniowo" zawsze wyglądają jakby były odwrócenie wyprowadzone z pożądanego wniosku), ale oto, co zaobserwowaliśmy we własnym zespole.
Najbardziej oczywistym kosztem jest ponowne rozpatrywanie – gdy nikt nie może znaleźć oryginalnej decyzji, zespoły po prostu ją ponownie otwierają, czasem dlatego, że ludzie naprawdę nie pamiętają, a czasem dlatego, że nowy członek zespołu ma uzasadnione pytania, na które nikt nie może odpowiedzieć konkretnie. Regularnie ponownie rozpatrywaliśmy rozstrzygnięte kwestie, zanim mieliśmy sposób na śledzenie decyzji do ich źródła, a każde ponowne rozpatrywanie ma swój własny narzut: czas spotkania, emocjonalne zmęczenie wynikające z kłótni o coś, co – jesteś całkiem pewien – było już rozwiązane, natrętne podejrzenie, że pierwotne rozumowanie było bardziej zniuansowane niż to, co ktokolwiek pamięta.
Bardziej subtelnym kosztem jest to, co dzieje się podczas wdrożenia nowych pracowników. Każde pytanie „dlaczego zostało to zrobione w ten sposób?" od nowego członka zespołu przerywa kogoś, kto był przy oryginalnej decyzji, a odpowiedź jest rekonstruowana z pamięci za każdym razem, gdy ktoś pyta, odchodząc nieco dalej od pierwotnego rozumowania przy każdym przekazaniu – jak głuchy telefon, tyle że telefonem jest oprogramowanie dla przedsiębiorstw, a wiadomością jest „dlaczego architektura działa w ten sposób". I jest przepaść wiarygodności, która z czasem się pogłębia: „wybraliśmy webhooki" niesie mniejszy ciężar niż „wybraliśmy webhooki, bo polling zużywał 40% naszego limitu interfejsu API GitHub i podczas godzin szczytu przekraczaliśmy próg ograniczania". Rozumowanie jest tym, co pozwala przyszłym inżynierom ocenić, czy decyzja nadal obowiązuje w zmienionych okolicznościach, a to rozumowanie siedzi gdzieś w wątku Slacka, idealnie zachowane i praktycznie niewidoczne.
Przestań tracić decyzje w historii Slacka. Sugarbug automatycznie śledzi pełny ślad decyzji – od wątku Slacka przez zgłoszenie w Linearze po PR.
Q: Dlaczego tak trudno znaleźć stare decyzje w Slacku? A: Slack przechowuje wiadomości chronologicznie, nie według znaczenia. Decyzja zakopana w wątku wygląda identycznie jak każda inna odpowiedź – wyszukiwarka Slacka może dopasowywać słowa kluczowe, ale nie odróżni „zdecydowaliśmy się użyć Redis" od „czy powinniśmy użyć Redis?" bez przeczytania pełnego kontekstu rozmowy. Im więcej czasu mija, tym trudniej – bo tracisz wskazówki kontekstowe (kto był zaangażowany, który kanał, który tydzień), które pierwotnie umożliwiały wyszukiwanie.
Q: Czy Sugarbug automatycznie śledzi decyzje podjęte w Slacku? A: Tak. Sugarbug klasyfikuje przychodzące sygnały ze Slacka i innych połączonych narzędzi, identyfikując wzorce przypominające decyzje – wątki, które odwołują się do zadań, angażują przypisane osoby i skutkują zmianami statusu lub PR-ami. Są one łączone z odpowiednim zadaniem w grafie wiedzy, dzięki czemu możesz śledzić ślad decyzji z poziomu zadania, zamiast przeszukiwać historię Slacka.
Q: Jaka jest różnica między logiem decyzji a grafem wiedzy do decyzji? A: Log decyzji wymaga, żeby ktoś ręcznie zapisywał każdą decyzję, gdy się pojawia – zauważyć ją, zatrzymać się, podsumować, oznaczyć, powiązać. Graf wiedzy wnioskuje o decyzjach na podstawie sygnałów przepływających przez narzędzia i łączy je z zadaniami, ludźmi i rozmowami automatycznie. Jedno zależy od konsekwentnej dyscypliny każdego członka zespołu; drugie działa w tle na podstawie aktywności, która i tak się odbywa.
Q: Czy Sugarbug może wydobywać decyzje z narzędzi innych niż Slack? A: Sugarbug łączy się ze Slackiem, GitHubem, Figmą, Linearem, Notion, pocztą e-mail i kalendarzami. Decyzje często obejmują wiele narzędzi (komentarz w Figmie prowadzi do wątku Slack, który prowadzi do PR), a graf wiedzy łączy sygnały we wszystkich połączonych obszarach. Widzisz pełny ślad niezależnie od tego, w którym narzędziu zaczęła się rozmowa.
Q: Czym to różni się od korzystania ze wbudowanej wyszukiwarki Slacka? A: Wyszukiwarka Slacka znajduje wiadomości zawierające konkretne słowa kluczowe. Graf wiedzy znajduje relacje między wiadomościami, zadaniami i ludźmi. Gdy szukasz decyzji, rzadko szukasz słowa – szukasz momentu, w którym zespół wybrał jedno podejście zamiast innego, a ten moment jest definiowany przez połączenia z innymi sygnałami, a nie przez słowa użyte do jego wyrażenia.
---
Jeśli decyzje wciąż znikają w historii Slacka, problem nie leży w Slacku – chodzi o to, że żaden system nie obserwuje ważnych momentów i nie łączy ich z pracą, którą ukształtowały. To jest luka, którą budujemy Sugarbug, żeby wypełnić.