Przeciętna firma IT ma wymagania, historię trackerów zadań, źródła (być może nawet z komentarzami w kodzie), instrukcje dotyczące typowych, ważnych i skomplikowanych przypadków w produkcji, opis procesów biznesowych (od onboardingu po „jak jechać na wakacje” ”), kontakty, klucze dostępu, listy osób i projektów, opisy obszarów odpowiedzialności - i cała masa innej wiedzy, o której pewnie zapomnieliśmy, a którą można przechowywać w najbardziej niesamowitych miejscach.
Wiedza =/= dokumentacja. Tego nie da się wytłumaczyć, trzeba o tym pamiętać
Jak mieć pewność, że ci, którzy muszą coś z tego wiedzieć, rozumieją, gdzie i jak to znaleźć, a każdy, kto potrzebuje świadomości poszczególnych rzeczy i ustaleń, może błyskawicznie i trafnie dowiedzieć się o zmianach w nich.
W ostatnim odcinku podcastu „Team Lead Will Call” chłopaki ze Skyeng rozmawiali z Igorem o zarządzaniu wiedzą Tsupko jest osobą w komitecie programowym KnowledgeConf i „dyrektorem nieznanego” w firmie Flant.
Pełne nagranie jest dostępne jako , a poniżej zebraliśmy kilka ciekawych wskazówek i linków do przydatnych materiałów, które zostały wspomniane w audio lub rozwinęły zawarte w nim informacje. Byłoby wspaniale, gdybyś podzielił się w komentarzach trikami i trikami swojego zespołu.
Pierwszy hack: nie musisz już wiedzieć, w którym systemie szukać
„Wziąłem nasze źródła wiedzy i przeprowadziłem ogólne wyszukiwanie: jedno okno z systemem filtrowania, aby zawęzić obszar wyszukiwania. Tak, jednocześnie nadal trzeba monitorować jego jakość, uzupełniać bazę wiedzy oraz walczyć z powielaniem i błędnymi informacjami.
Jedna kartka papieru do znalezienia i to wszystko
Ale już około 60% inżynierów Flant korzysta z tego wyszukiwania co najmniej 1-2 razy dziennie - i zwykle znajduje odpowiedzi na pierwszej lub drugiej pozycji. Formą dowodu słuszności koncepcji jest indeksowanie dokumentów Google: wszystkich dokumentów, folderów, dysków samochodów dostawczych itd. – wszystko to można łatwo uwzględnić w wyszukiwaniu wewnętrznym”.
Drugi trik: jak nie przegapić niezwykle ważnych rzeczy podczas wielu rozmów
„Jeśli pracujesz w rozproszonym zespole, prawdopodobnie znaczną część dnia spędzasz na Slacku – w takim przypadku jesteś przyzwyczajony do robienia czegoś takiego: „@myteam, pomóż/poszukaj/wprowadź właściwy… ”.” Jest jednak problem z nadmiarem informacji – a wśród innych wiadomości można pominąć osobną wzmiankę.
W Skyeng pomaga nam bot, za pomocą którego możesz napisać wiadomość i oznaczyć dowolną liczbę osób lub grup. Używamy go w przypadkach, gdy naprawdę ważne jest, aby ludzie przeczytali lub zareagowali: będzie napierał bez końca, dopóki nie naciśniesz przycisku „Czytam” – nie będziesz mógł go pominąć ani zignorować.
Pytanie, na które należy odpowiedzieć: co zrobić z dokumentacją?
„Duża wiedza pochodzi od techników, ale nie każdy wie, jak ją dobrze opisać.
W końcu nie masz żadnego kompilatora ani lintera, który powiedziałby Ci, czy robisz to dobrze, czy nie - a często otrzymujemy niezrozumiały, źle sformatowany i niekompletny tekst. Oczywiście trzeba to zrobić normalnie, a nie dlatego, że ktoś przyszedł i powiedział „trzeba” – robisz to dobrze dla siebie: za miesiąc lub dwa przeczytasz i zrozumiesz. A inna osoba, otwierając dokument, nie zamknie go od razu na zawsze, zdając sobie sprawę, że jest bezużyteczny.
Część podcastu poświęcona pytaniu „Ile osób potrzeba, aby napisać dobrą dokumentację lub zrobić normalne demo”
Pozostaje jednak pytanie: ile czasu na to przeznaczyć i jak to zrobić efektywnie?
I jeśli jest tu uczciwa odpowiedź: jeśli nie zaangażują się w to ludzie biznesu i nie doświadczą empirycznie wpływu dobrej dokumentacji, istnieje ryzyko, że wysiłek ten przyniesie niewielki zwrot. To bardziej opowieść o zmianie kultury.
Co do reszty, doświadczenie i mentoring Cię uratują. Odpowiednie mogą być tutaj analogie z programowaniem w parach, śledzeniem postępów i przeglądami kodu – pokazując najlepsze praktyki, wytykając błędy i w efekcie nudno.”
Bonus: „OK, powiem im tak, zrozumieją”
Pytanie „ile czasu na to poświęcić i na jakim poziomie to zrobić” jest istotne nie tylko w kontekście dokumentacji, ale w ogóle w kontekście przekazywania jakiejkolwiek wiedzy. Demo jest także doskonałym przykładem dzielenia się informacjami. Ale są niuanse: na przykład, jak upewnić się, że zajmują one minimum czasu.
Kanał wymiany wiedzy wśród deweloperów: raporty wewnętrzne, przydatne książki, artykuły itp. Ustrukturyzowany ekstrakt jest również przechowywany w Notion.
Częściowo problemy te można rozwiązać poprzez praktykę raportów wewnętrznych. Raz w tygodniu poświęca się 40–60 minut w mniej zajętym czasie, a chłopaki nagrywają raport wideo dla kolegów z różnych projektów. Zespół frontendowy kluczowego produktu - Vimbox - o zestawie interfejsu użytkownika, który może mieć motyw dla dowolnego innego projektu. Zespół ds. rozwoju marketingu mówił o bibliotece do śledzenia i rejestrowania żądań, co od razu wzbudziło zainteresowanie kilku innych projektów. Zespół projektowy Mathematics podzielił się swoimi doświadczeniami związanymi z przejściem z REST API na GraphQL. Zespół zajmujący się lekcjami grupowymi myśli o podzieleniu się informacjami o tym, jak jako pierwszy przeszedł na PHP 7.4. I tak dalej.
Lista prowadzona jest od maja 2018 roku i liczy ponad 120 wpisów
Wszystkie spotkania rozpoczynają się poprzez firmowy Google Meet, są nagrywane i w ciągu 1.5 godzin pojawiają się w folderze na współdzielonym dysku Google, a linki do nagrań są powielane w tym samym Slacku. Oznacza to, że nie musisz przychodzić, jeśli jest coś awaryjnego, ale obejrzyj później przy prędkości 20 - zwykle sam raport trwa do XNUMX minut, a dyskusja - jak to się skończy. Ale nie przekraczamy godziny)
PS Co zadziałało, a co nie dla Ciebie?
Przydatne linki:
- Rodion Nagornow z Kaspersky Lab na temat i dlaczego to nie jest dokumentacja (dzięki kanałowi Igora za link , jest tego dużo więcej).
- Igor Tsupko z Flant o tym w moim towarzystwie
- Alexey Kataev ze Skyeng (luki wiedzy w zakresie technologii i konkretnych obszarów) w rozproszonym zespole.
- Sergey Goncharuk z Flant o przekazywaniu informacji - , jeśli napotkasz problem w rozproszonym zespole.
Źródło: www.habr.com