Drugi mózg firmy: od wiki po umiejętności – wszystko zależy od kontekstu8 min read

Dużo myślałem o całym szumie wokół „drugiego mózgu”. Rozmawiałem o tym z innymi osobami w tej dziedzinie i moimi kolegami, którzy albo budują drugi mózg, albo mają jego wersję.

Dla niewtajemniczonych: drugi ruch mózgowy rozpoczął się od pomysłu „Wiki” Andreja Karpathy’ego: uporządkowania osobistej wiedzy agenta w formie powiązanej struktury Wiki zawierającej lokalne pliki MD. Później rozszerzyło się to na organizowanie danych osobowych w znacznie szerszym formacie, a użytkownicy często używali Obsidianu do organizowania i wizualizacji notatek oraz dodawania danych ze spotkań (transkrypcje Granola/Whisperflow/Zoom) do Wiki.

bazy-wiedzy-karpatii rakietowych:start

bazy-wiedzy-rakietowejkarpatii:koniec

W miarę rozwoju Wiki stało się oczywiste, że dzielenie się zawartymi na niej informacjami ma prawdziwą wartość. W ten sposób zaczęły rozkwitać projekty „drugiego mózgu firmy”. Utopijna wersja drugiego mózgu umożliwia transkrypcję wszystkiego, co możliwe: rozmów telefonicznych na zoomie, spotkań F2F, nawet przypadkowych interakcji, e-maili, wiadomości typu Slack, dokumentów – a wszystko to do ogromnej bazy danych, takiej jak Snowflake. Wyobraź sobie, że każdy w firmie może zadać tej instancji Snowflake wszystko, czego chce i natychmiast uzyskać odpowiedź na każde pytanie.

Ups, to nie jest dobry pomysł. Po pierwsze, jest to bardzo drogie. Ilość danych przesyłanych do czegoś takiego jest po prostu szalona, ​​a odzyskanie z niej danych staje się niezwykle trudne, powolne i kosztowne. Bezpieczeństwo i segregacja danych stają się problemem. Jak zapobiec przedostawaniu się danych osobowych, danych finansowych, decyzji zarządczych, danych kadrowych, a nawet decyzji o rozwiązaniu umowy 1:1 do transkrypcji i dostępności. Nie wszyscy powinien wiedzieć wszystko…

Poza tym, komu to potrzebne, co nas to oszczędza i czy to w ogóle dobry pomysł?

Powiedziałbym ogólnie, że zawarta wersja tego jest dobrym pomysłem. W dużej mierze powodem istnienia kierownictwa średniego szczebla jest przeniesienie problemów na wyższy poziom i wyjaśnienie decyzji na niższym szczeblu. Wiele z tych czynności można teraz wykonać za pomocą drugiego mózgu.

Drugi mózg zespołów technicznych

Techniczny drugi mózg może być znacznie łatwiejszy w utrzymaniu. Wiele firm po prostu korzysta z katalogu Dropbox/Google Drive/OneDrive, w którym przechowywana jest wspólna wiedza, którą może podzielić się Claude/Codex. Automatyzacja wypychania tego do repozytorium Git jest dość prosta lub naprawdę możesz użyć Githuba do zarządzania tym również (myślę, że dla OpenAI/Anthropic jest to bardzo mały wysiłek, aby obsłużyć ten scenariusz bez konieczności instalowania niestandardowych umiejętności do zarządzania tego typu rzeczami). Źródłem prawdy staje się teraz repozytorium Github, a lokalne kopie to lokalne repozytoria Git.

Może to dodać wiedzę i możliwości, takie jak wspólne umiejętności, wspólne decyzje, projekty architektoniczne, projekty wizualne (na przykład decyzje dotyczące systemu projektowego) i różne inne decyzje dotyczące produktów firmy.

Małe zespoły tak naprawdę nie potrzebują wiele poza prostą synchronizacją wokół repozytorium, ale większe firmy z wieloma większymi zespołami bardzo szybko napotkają poważne ograniczenia. Najpoważniejsze problemy obejmują zatruwanie kontekstu, w przypadku którego konkretny użytkownik może podejmować lokalne decyzje sprzeczne z danymi drugiego mózgu, albo wprowadzając sprzeczne dane, albo nieumyślnie unieważniając decyzje firmy (w niektórych przypadkach może celowo?).

Utrzymywanie go w git i łączenie można wykonać za pomocą dedykowanego agenta, który wyszukuje konflikty i może ostrzegać użytkownika, jeśli wprowadzone przez niego zmiany są sprzeczne, rozwiązywać konflikty i łączyć wyniki.

Należy pamiętać, że nie jest to dobra metoda przechowywania dokumentacji projektowej. W tym celu lepszym sposobem jest włączenie wiki jako integralnej części samego projektu. Stworzenie go jest dość łatwe. Po prostu odwołujesz agenta kodującego i prosisz go, aby przejrzał projekt, dokładnie udokumentował go w folderze z dokumentacją, z podziałem według architektury, błędów, decyzji dotyczących produktu, decyzji technicznych i innych rzeczy, które, jak stwierdza, mogą być pomocne w małych plikach md, które można przechowywać. Kluczem jest poinformowanie go, aby upewnił się, że kod i plik readme.md wskazują na katalog dokumentów, aby mieć pewność, że wszędzie będą do niego odniesienia i będą traktowane jako część projektu, a nie zasób zewnętrzny. Kluczową rzeczą, o której musi wiedzieć agent, jest to, że celem jest umożliwienie szybkiego wdrożenia innego agenta do projektu, aby uniknąć pułapek, dziur i dziur technicznych…

Po zintegrowaniu go z samą strukturą projektu repo agent kodujący będzie go utrzymywał tak, jakby był kodem. Odczyta to tak, jakby był częścią kodu i jeśli coś się zmieni, dostosuje lub zmodyfikuje dokumentację (pamiętaj, że „dokumentacja to kod, który jest łatwy do odczytania i przejrzysty” lub „dokumentacja staje się nieaktualna w chwili, gdy opuszcza klawiaturę” – zaufaj sztucznej inteligencji, że ją utrzyma, więc nie są już prawdziwe).

Drugi mózg dla zespołów produktowych, marketingowych i nietechnicznych

Ten typ drugiego mózgu może być naprawdę fajny dla zespołów technicznych, ale zrobienie tego samego dla zespołów nietechnicznych będzie niezwykle trudne.

Weźmy na przykład zespół prawników. Mają oni bardzo specyficzny zestaw wiedzy, obejmujący pocztę elektroniczną, Slack, pliki Word i inne dokumenty. To samo dotyczy księgowych, sprzedaży, sukcesu klientów itp. Każdy z nich ma swoją własną wiedzę drugiego mózgu.

Co więcej, kierownictwo prawdopodobnie chce, aby dane były rozpowszechniane (niefiltrowane przez kierownictwo średniego szczebla), a zespół może potrzebować informacji wygenerowanych przez kierownictwo. Jak stworzyć skalowalny graf wiedzy, który jest zabezpieczony i oddzielony?

Istnieje kilka podejść, które mogłyby ułatwić sprawę, przynajmniej do czasu, gdy duzi chłopcy rozwiążą ten problem, miejmy nadzieję, że w sposób otwarty, ale raczej poprzez drogie, zamknięte rozwiązanie.

1. Osobisty drugi mózg – każda osoba, która tego chce, może transkrypować własne spotkania i utrzymywać swój własny drugi mózg. Obsidian jest do tego całkiem przydatny, każdy agent może go w zasadzie posortować i oczyścić. Wykorzystaj mechanizm uśpienia REM, aby go zoptymalizować – agent powinien budzić się w nocy, identyfikować wszystkie informacje zebrane w ciągu dnia, znajdować informacje krytyczne i ważne, aby zachować je na przyszłość i organizować je w łatwy do odzyskania sposób w folderach i plikach MD. Oznacza to, że jeśli rozmawiałeś z konkretnym klientem, plik md tego klienta zostanie zaktualizowany, zawierający informacje o nim, o których należy pamiętać, nad czym razem pracujecie itp. To samo dotyczy projektów. Będzie nakładanie się: nakładanie się jest dobre – dobrze, że informacja o konkretnym projekcie żyje zarówno w aktach osoby, z którą rozmawiałeś, jak i w aktach firmy i projektu. Pozwól agentowi zająć się tym za Ciebie. Jeśli masz pytania, ustaw to jako główne źródło danych dla swojego agenta. Możesz udostępnić swojego agenta swoim e-mailom/rozmowom/itp. – pamiętaj tylko, aby nie transkrybować rzeczy, których nie chcesz dokumentować (nie róbmy z tego reality show ani mydła).

2. Drugi mózg na poziomie zespołu – druga warstwa danych obejmuje dane znajdujące się albo w drugim mózgu człowieka, co do których agent ma 100% pewność, że są istotne dla całego zespołu, albo dane pochodzące ze spotkań na poziomie zespołu, które z natury są zespołowe. Agent może również zbierać dane dla tego drugiego mózgu z kanałów Slack Twojego zespołu — nie powinny one znajdować się w Twoich kanałach 1:1 ani w rozmowach Zoom. Po pobraniu danych agent może je uporządkować w czasie rzeczywistym lub co noc i wskazać niespójności, w których decyzje zostały unieważnione lub które nie odpowiadają decyzjom osobistym lub zarządczym. Należy je podkreślić i powiadomić osobę podejmującą niezgodną decyzję, aby mogła dokonać wyboru w sposób świadomy.

3. Drugi mózg na poziomie zarządzania – jest to w zasadzie drugi mózg na poziomie zespołu, ale ze względu na wrażliwość danych i podejmowanych decyzji należy z nim postępować w znacznie bardziej szczegółowy sposób. W tym miejscu należy udostępniać wyłącznie ostateczne decyzje i dane publiczne, aby uniknąć potencjalnych wycieków do reszty firmy. Dobrym pomysłem może być, aby człowiek przejrzał część danych, przynajmniej na początku, aby zapewnić bezpieczeństwo danych. Dobrym pomysłem jest także pozostawienie mózgu kierownictwa poza drugim mózgiem firmy.

4. Drugi mózg całej firmy – to jest najtrudniejsze i powinno zawierać tylko dane konkretne, informacyjne, które mogą mieć znaczenie dla całej firmy. Tylko raportowane wyniki finansowe, na przykład informacje o personelu (kto zajmuje jakie stanowisko).

Pomija to wiele danych, w tym na przykład dane dotyczące nastrojów, które kierownictwo chce usłyszeć od całego zespołu. Można go zbierać osobno lub z luzu i innych źródeł. Zbieranie tego typu danych bezpośrednio z mózgu firmy nie jest dobrym pomysłem.

Czego więc szukasz w drugim mózgu lub mózgu firmy, czy podejmowałeś próby jego zbudowania i jakie wnioski wyciągnąłeś?