Silosy danych między inżynierią a produktem
PM-owie i inżynierowie używają różnych narzędzi, języka i harmonogramów. Oto jak powstaje silo – i co naprawdę rozwiązuje ten problem.
By Ellis Keane · 2026-03-16
Gdzieś po drodze „wyrównanie produktowo-inżynieryjne" stało się tytułem stanowiska zamiast czymś, co po prostu się dzieje, gdy kompetentni ludzie pracują razem. Firmy zatrudniają teraz dedykowanych ludzi, których jedynym celem jest upewnienie się, że dwie grupy mądrych osób – które siedzą w tym samym workspace'ie Slack, uczestniczą w tych samych standupach i teoretycznie pracują w kierunku tych samych celów – mogą faktycznie rozumieć, co robi druga grupa. Silosy danych między inżynierią a produktem, które to umożliwiają, nie są problemem ludzi. Są problemem narzędzi.
PM-owie i inżynierowie komunikują się dość dużo. Problem polega na tym, że pracują w zupełnie różnych systemach, a silosy tworzące się między tymi systemami są strukturalne – wbudowane w architekturę sposobu, w jaki nowoczesne zespoły dobierają narzędzia. Żadna ilość „wyrównujmy się częściej" nie naprawia problemu, w którym same narzędzia nie mają o sobie nawzajem żadnej wiedzy.
Dwie rzeczywistości
Czerpię tu z naszego własnego doświadczenia przy budowie Sugarbug, ponieważ żyjemy tym każdego dnia i uważam, że szczegóły są bardziej użyteczne niż abstrakcja.
Strona PM-owa (w naszym przypadku to głównie ja) żyje w Notion. Specyfikacje są tam pisane, priorytety śledzone, rozmowy z klientami logowane, prośby o funkcje katalogowane na listach rosnących z tygodnia na tydzień. Notion to miejsce, gdzie żyje „dlaczego" – dlaczego coś budujemy, co klient naprawdę powiedział, jaki kontekst strategiczny stoi za daną decyzją. Jest chaotyczne, rozległe i to tam dzieje się większość ważnego myślenia zanim zostanie napisana choćby jedna linia kodu.
Tymczasem nasi inżynierowie żyją w Linear i GitHubie. Linear trzyma zadania, cykle sprintów, łańcuchy zależności i blokujące zadania. GitHub ma kod, pull requesty, wątki przeglądów, gdzie ludzie konstruktywnie (miejmy nadzieję) kłócą się o szczegóły implementacji. Tam żyje „jak" i „kiedy" – jak coś jest budowane, kiedy zostanie wydane, co stoi na przeszkodzie.
Obie rzeczywistości są dokładne, obie niezbędne i są całkowicie odłączone od siebie nawzajem. Luka między nimi to miejsce, gdzie wymagania się dezaktualizują i zaczyna się gromadzić konieczność poprawek.
Jak faktycznie tworzą się silosy danych między inżynierią a produktem
Kuszące jest myślenie, że to celowy wybór – że ktoś zdecydował, żeby trzymać informacje osobno. W praktyce silo tworzy się poprzez całkowicie rozsądne zachowanie, które nikt nie zamierzał czynić szkodliwym.
PM pisze specyfikację w Notion, linkuje ją na Slacku do kanału inżynieryjnego i uważa przekazanie za zakończone. Inżynier czyta specyfikację, tworzy z niej trzy zadania w Linear i zaczyna budować. Na razie wszystko działa.
Ale potem specyfikacja się zmienia – rozmowa z klientem przesuwa priorytety albo zmienia się kontekst biznesowy. PM aktualizuje dokument w Notion i zostawia notatkę na Slacku o zmianie. Inżynier, głęboko zanurzony w sesji kodowania, nie widzi wiadomości na Slacku przez wiele godzin. Do tego czasu zbudował już dwie z trzech funkcji według starej specyfikacji, a trzecie zadanie w Linear nadal odwołuje się do wymagań, które już nie istnieją.
Nikt tu nie był niedbały. Nikt „nie zdołał się komunikować." Informacja żyła w jednym systemie, a praca działa się w innym, a tkanką łączącą między nimi była wiadomość na Slacku, która została zakopana pod innymi wątkami zanim właściwa osoba ją zobaczyła.
Dzieje się to wielokrotnie – przy każdej specyfikacji, każdym sprincie, każdym kwartale – i odchylenie się kumuluje. Luka między tym, co produkt myśli, że się dzieje, a tym, co inżynieria faktycznie buduje, poszerza się przy każdym przekazaniu, które polega na tym, że człowiek zauważy wiadomość w odpowiednim czasie.
Dlaczego „lepsza komunikacja" tego nie naprawia
Brałem udział w retrospektywach, gdzie punktem działania było „komunikować zmiany bardziej proaktywnie" i (z czułością) jest to organizacyjny odpowiednik mówienia komuś, żeby był po prostu bardziej zorganizowany. Brzmi jak coś, co można zrealizować, sprawia, że strona Confluence wygląda produktywnie i nie zmienia absolutnie niczego w systemie, który spowodował problem. Przeprowadziliśmy ten sam punkt działania z retrospektywy trzy razy – sprawdziłem.
Powód, dla którego lepsza komunikacja nie rozwiązuje silosów danych między inżynierią a produktem, jest taki, że komunikacja już się odbywa – dane istnieją, decyzje są podejmowane i zapisywane. Są po prostu zapisywane w narzędziach, które nie mają o sobie nawzajem żadnej wiedzy.
Notion nie wie, że specyfikacja została rozłożona na trzy zadania w Linear. Linear nie wie, że wymagania stojące za zadaniem zmieniły się w Notion dwie godziny temu. GitHub nie ma pojęcia, że przeglądany PR implementuje funkcję, której priorytet właśnie został obniżony w tablicy Notion PM-a. Każde narzędzie działa dokładnie tak, jak zostało zaprojektowane – po prostu nie zostało zaprojektowane do współpracy z innymi.
„Jest pewna mroczna komedia w spędzaniu poniedziałkowego poranka na potwierdzaniu, że narzędzia, za które płacisz, nie odeszły po cichu od rzeczywistości przez weekend." – Ellis Keane
Więc co się dzieje: PM-owie ręcznie powielają zmiany z Notion do Linear gdy specyfikacje się zmieniają, inżynierowie pingują PM-ów na Slacku pytając „czy to nadal plan?", a liderzy spędzają poniedziałkowe poranki na krzyżowym sprawdzaniu tablic pod kątem odchyleń. Obserwowaliśmy jak sami spalamy kilka godzin tygodniowo na tym, co sprowadza się do ręcznej synchronizacji danych między narzędziami, które teoretycznie powinny już o sobie wiedzieć.
Jak faktycznie wygląda naprawienie systemu
Instynkt, gdy widzisz lukę między dwoma narzędziami, to zbudowanie mostu – automatyzacja Zapier, webhook, skrypt synchronizacyjny. W przypadku prostych, przewidywalnych przepływów pracy (gdy zadanie w Linear przechodzi do „Gotowe", zaktualizuj status w Notion) to działa dobrze.
Ale silosy danych między inżynierią a produktem obejmują kontekst, nie tylko status. PM nie zmienił tylko pola statusu; przepisał akapit w specyfikacji, który zmienia znaczenie „gotowe" dla dwóch z trzech zadań Linear. Proste webhooki statusu pomijają zmiany na poziomie wymagań, chyba że doda się na wierzch logikę diff i semantyczne mapowanie, czego większość zespołów nigdy nie dochodzi do budowania.
To, czego faktycznie potrzebujesz, to coś, co rozumie relacje między danymi w różnych narzędziach – nie tylko „ta strona Notion jest połączona z tym zadaniem Linear", ale „ta sekcja specyfikacji opisuje wymagania dla tego zadania i ta sekcja właśnie się zmieniła". Celem jest automatyczne mapowanie edycji specyfikacji do zadań, których to dotyczy, zamiast polegania na tym, że ktoś to zauważy i przekaże.
To jest różnica między warstwą synchronizacyjną a grafem wiedzy. Warstwa synchronizacyjna kopiuje dane między narzędziami. Graf wiedzy śledzi, jak dane są ze sobą powiązane, wykrywa, gdy te relacje się zmieniają, i wyświetla zmiany osobom, które muszą wiedzieć.
Budujemy Sugarbug, żeby działał w ten sposób – łącząc narzędzia, których PM-owie i inżynierowie już używają (Notion, Linear, GitHub, Slack, Figma) w graf wiedzy, który utrzymuje relacje między specyfikacjami, zadaniami, kodem i rozmowami. Jesteśmy jeszcze na wczesnym etapie (szczerze, wciąż jest dużo, czego nie rozgryźliśmy jeśli chodzi o to, jak niezawodnie wykrywać semantyczne różnice w skali), ale podstawowy graf działa i już wychwycił sytuacje ze zdriftowanymi specyfikacjami, które zamieniłyby się w poprawki.
Silosy danych między inżynierią a produktem tworzą się, ponieważ narzędzia są strukturalnie odłączone, a nie dlatego, że ludzie komunikują się słabo. Rozwiązanie polega na połączeniu danych na poziomie relacji, a nie dodawaniu kolejnych kanałów komunikacji.
Co możesz zrobić w tym tygodniu
Nie zamierzam udawać, że jedyną odpowiedzią jest „używaj Sugarbug". Są rzeczy, które możesz zrobić teraz, z dowolnymi narzędziami, których już używasz, żeby zmniejszyć najgorsze skutki silosu danych produktowo-inżynieryjnego.
Twórz wzajemne odniesienia w sposób jawny, dwukierunkowy i z właścicielem. Każda specyfikacja w Notion powinna mieć sekcję „Zadania Linear" na dole z linkami do zadań, które z niej powstały, a każde zadanie w Linear powinno linkować z powrotem do swojej źródłowej specyfikacji. Przypisz jedną osobę na specyfikację do zarządzania wzajemnymi odniesieniami – nie cały zespół, jedną osobę, z jej imieniem. Próbowaliśmy wersji „wszyscy są odpowiedzialni" i (przewidywalnie) nikt nie był. Linki i tak będą z czasem dryfować, ale posiadanie nazwanego właściciela oznacza, że jest ktoś do pingowania gdy dryf zostanie zauważony.
Ustanów rytuał „zmiany specyfikacji" z wyzwalaczem, a nie przypomnieniem. Gdy specyfikacja zmienia się materialnie (nie literówki – faktyczne zmiany wymagań), PM aktualizuje połączone zadania Linear przed zamknięciem zakładki Notion. Nie później, nie „gdy będę miał czas" – przed zamknięciem zakładki. Komentarz przy każdym zadaniu, którego to dotyczy, powinien mieć jedną linię: co się zmieniło, link do zaktualizowanej sekcji i czy kryteria akceptacji zadania są nadal ważne. Stwierdziliśmy, że powiązanie aktualizacji z fizyczną czynnością (zamknięciem zakładki) działa lepiej niż poleganie na pamięci kogokolwiek, ponieważ pamięć jest dokładnie tym, jak silo powstało w pierwszej kolejności.
Przeprowadź 15-minutowe piątkowe sprawdzenie dopasowania priorytetów. Jedna osoba (rotacyjnie co tydzień) wyciąga 5 najważniejszych priorytetów PM-a w Notion i 5 najważniejszych w sprincie inżynieryjnym w Linear, obok siebie. Pytanie nie brzmi „czy są identyczne?" – nie będą i to jest w porządku. Pytanie brzmi „czy którekolwiek z tych aktywnie sobie zaprzeczają?" Jeśli priorytet #1 PM-a nie ma go nigdzie w sprincie, to jest rozmowa do przeprowadzenia w poniedziałek, a nie aktualizacja statusu.
Są to procesy ręczne i mają datę ważności. Przy pięciu inżynierach i dwóch PM-ach są żmudne, ale działają. Przy piętnastu inżynierach, trzech PM-ach i zespole projektowym dodającym Figmę do miksu, relacje między narzędziami mnożą się szybciej niż ktokolwiek może śledzić ręcznie. Ale nauczą cię, gdzie faktycznie są twoje najgorsze luki w wyrównaniu produktowo-inżynieryjnym – i ta wartość diagnostyczna jest warta wysiłku nawet jeśli ostatecznie zautomatyzujesz całość.
Niezależnie od tego czy długoterminowym rozwiązaniem jest Sugarbug czy coś innego (oczywiście uważamy, że budujemy właściwą rzecz, ale jestem stronniczy), problem współpracy między zarządzaniem produktem a inżynierią rozwiązuje się tylko wtedy, gdy same narzędzia są połączone na poziomie semantycznym, a ludzie mogą skupić się na podejmowaniu decyzji zamiast przerzucać kontekst między aplikacjami.
Jeśli twoje ręczne wzajemne odniesienia się sprawdzają, używaj tego tak długo jak wytrzyma. Jeśli ciągle masz te same punkty działania z retrospektyw dotyczące komunikacji, problem nie leży w twoich ludziach. Leży w twojej architekturze danych.
Połącz Notion, Linear, GitHub i Slack w jeden graf wiedzy – żeby zmiany specyfikacji automatycznie trafiały do właściwych inżynierów.
Q: Ile czasu zajmuje skonfigurowanie Sugarbug dla zespołu produktowo-inżynieryjnego? A: Wstępne połączenie z każdym narzędziem zajmuje kilka minut – uwierzytelniasz Linear, GitHub, Notion, Slack i Figmę przez OAuth, a Sugarbug natychmiast zaczyna budować graf wiedzy. Graf staje się naprawdę użyteczny po jednym lub dwóch dniach, gdy pobierze twoje istniejące dane i zacznie mapować relacje między specyfikacjami, zadaniami i rozmowami. Wciąż dopracowujemy przepływ onboardingu, ale celem jest to, żebyś nie musiał niczego konfigurować poza połączeniem swoich kont.
Q: Czy Sugarbug zastępuje Linear, Notion lub którekolwiek z naszych istniejących narzędzi? A: Nie. Sugarbug działa obok twoich istniejących narzędzi i je łączy – nie zastępuje żadnego z nich. Twoi PM-owie nadal piszą specyfikacje w Notion, twoi inżynierowie nadal pracują w Linear i GitHubie, a Sugarbug utrzymuje relacje między nimi, żeby kontekst nie gubił się w trakcie przekazywania. Pomyśl o tym jako o tkance łącznej między narzędziami, których już używasz.
Q: Czy Sugarbug może wykryć zmianę w specyfikacji Notion i powiadomić właściwych inżynierów? A: To jest kluczowa część tego, co budujemy. Gdy specyfikacja zmienia się w Notion, Sugarbug identyfikuje, które zadania Linear są z nią połączone i wyświetla zmianę inżynierom pracującym nad tymi zadaniami. Wciąż iterujemy nad częścią dotyczącą semantycznego wykrywania (ustalanie, które zmiany są materialne w porównaniu do kosmetycznych), ale łączenie narzędzi i podstawowe wykrywanie zmian działają.
Q: Jaka jest różnica między narzędziem synchronizacyjnym a grafem wiedzy w przypadku tego problemu? A: Narzędzie synchronizacyjne kopiuje zmiany statusu między aplikacjami – gdy zadanie Linear przechodzi do „Gotowe", zaznacz pole wyboru w Notion. Graf wiedzy śledzi, jak dane są ze sobą powiązane: ta specyfikacja opisuje wymagania dla tych trzech zadań, a kryteria akceptacji zmieniły się, co dotyczy dwóch zadań, które jeszcze nie zostały wydane. Różnica ma największe znaczenie gdy zmiany są semantyczne, a nie tylko na poziomie statusu.
Q: Czy wyrównanie produktowo-inżynieryjne to problem komunikacyjny czy problem z danymi? A: Z naszego doświadczenia wynika, że prawie zawsze jest to problem z danymi błędnie diagnozowany jako problem komunikacyjny. Zespoły komunikują się – robią to po prostu za pośrednictwem narzędzi, które nie mają o sobie nawzajem żadnej wiedzy. Naprawienie przepływu danych między tymi narzędziami ma tendencję do rozwiązywania problemów z wyrównaniem, których żadna liczba retrospektyw ani spotkań synchronizacyjnych nie była w stanie naprawić.