Przeciętna firma informatyczna ma wymagania, historię śledzenia zadań, kody źródłowe (być może nawet z komentarzami w kodzie), instrukcje dotyczące typowych, ważnych i złożonych przypadków w produkcji, opis procesów biznesowych (od wdrażania po „jak iść na urlop”), kontakty, klucze dostępu, listy osób i projektów, opis obszarów odpowiedzialności - i mnóstwo innej wiedzy, o której prawdopodobnie zapomnieliśmy, a która może być przechowywana w najbardziej zaskakujących miejscach.
Wiedza =/= dokumentacja. Nie można jej wyjaśnić, trzeba ją zapamiętać.
Jak sprawić, by ci, którzy muszą się czegoś z tego dowiedzieć, wiedzieli, gdzie i jak tego szukać, a wszyscy, którzy muszą być świadomi poszczególnych rzeczy i ustaleń, mogli natychmiast i dokładnie dowiedzieć się o zachodzących w nich zmianach.
W ostatnim odcinku podcastu „Teamlead Will Call” ekipa Skyeng rozmawiała z Igorem o zarządzaniu wiedzą Tsupko jest członkiem komitetu programowego KnowledgeConf i „dyrektorem nieznanego” w firmie Flant.
Pełne nagranie jest dostępne jako , a poniżej zebraliśmy kilka interesujących wskazówek i linków do przydatnych materiałów, które zostały wspomniane w nagraniu audio lub rozszerzają informacje w nim zawarte. Byłoby wspaniale, gdybyście mogli również podzielić się hackami i grabiami swojego zespołu w komentarzach.
Hack 1: Nie musisz już wiedzieć, w którym systemie chcesz wyszukiwać
„Wziąłem nasze źródła wiedzy i przeprowadziłem ogólne wyszukiwanie: pojedyncze okno z systemem filtrowania, aby zmniejszyć obszar wyszukiwania. Tak, jednocześnie nadal musisz monitorować jego jakość, wypełniać bazy wiedzy, zwalczać duplikację i błędne informacje.
Jeden klip, aby znaleźć to wszystko
Ale już teraz około 60% inżynierów Flant używa tej wyszukiwarki co najmniej 1-2 razy dziennie - i zazwyczaj znajduje odpowiedzi na pierwszej lub drugiej pozycji. A jako dowód koncepcji jest indeksowanie dokumentów Google: wszystkich dokumentów, folderów, jednego dysku itd. - wszystko to jest również łatwo wprowadzane do wyszukiwania wewnętrznego."
Hack 2: Jak nie przegapić ważnych informacji w tłumie rozmówców
„Jeśli pracujesz w rozproszonym zespole, to prawdopodobnie spędzasz znaczną część dnia w Slacku – a gdy coś się dzieje, jesteś przyzwyczajony do robienia czegoś takiego: „@myteam, pomóż/spójrz na/wprowadź niezbędne…”. Ale jest problem z nadmiarem informacji – i osobna wzmianka może zostać pominięta wśród innych wiadomości.
W Skyeng mamy bota, który pozwala 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 on bez końca nękał, dopóki nie klikniesz przycisku „Przeczytałem” — nie możesz go pominąć ani zignorować.
Podchwytliwe pytanie: co zrobić z dokumentacją?
„Dużo wiedzy dostarczają specjaliści od technologii, ale nie każdy potrafi 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 wynik jest niezrozumiały, źle sformatowany i niekompletny. Oczywiście, nie powinieneś robić tego poprawnie, ponieważ ktoś przyszedł i powiedział „musisz” – robisz to dobrze dla siebie: za miesiąc lub dwa przeczytasz to i zrozumiesz. A inna osoba, otwierając dokument, nie zamknie go od razu na zawsze, zdając sobie sprawę, że jest bezwartościowy.
Fragment podcastu poświęcony pytaniu „Ile osób potrzeba, aby napisać dobrą dokumentację lub stworzyć przyzwoite demo”
Ale pytanie pozostaje: ile czasu należy na to przeznaczyć i jak można to zrobić efektywnie?
A jeśli istnieje uczciwa odpowiedź na to pytanie, chyba że zaangażowani są ludzie biznesu i empirycznie odczuwają zwrot z dobrej dokumentacji, istnieje ryzyko, że wysiłek przyniesie niewielki zwrot. To raczej historia o zmianie kultury.
W przeciwnym razie doświadczenie i mentoring cię uratują. Tutaj mogą być odpowiednie analogie programowania w parach, śledzenia postępów i przeglądu kodu – pokazywanie najlepszych praktyk, wytykanie błędów i, na koniec, nudne”.
Bonus: „No, daj spokój, powiem im w ten sposób, zrozumieją”.
Pytanie „ile czasu na to poświęcić i na jakim poziomie to zrobić” jest ważne nie tylko w ramach dokumentacji, ale ogólnie dla transferu jakiejkolwiek wiedzy. Dema są również świetnym przykładem wymiany informacji. Ale są niuanse: na przykład jak sprawić, by zajmowały jak najmniej czasu.
Kanał wymiany wiedzy w zespole programistów: wewnętrzne raporty, przydatne książki, artykuły itp. Ustrukturyzowane podsumowanie jest również przechowywane w Notion.
Te problemy są częściowo rozwiązywane przez praktykę wewnętrznych raportów. Raz w tygodniu poświęca się 40-60 minut w niezbyt pracowitym czasie - i chłopaki robią raport wideo dla kolegów z różnych projektów. Zespół front-end kluczowego produktu - Vimbox - o ich zestawie UI, który można dostosować do dowolnego innego projektu. Zespół ds. rozwoju marketingu — o bibliotece do śledzenia i rejestrowania żądań, która natychmiast zainteresowała kilka innych projektów. Zespół projektu „Mathematics” podzielił się swoimi doświadczeniami z przejścia z REST API na GraphQL. Zespół ds. zajęć grupowych myśli o opowiedzeniu, jak to oni jako pierwsi przeszli na PHP 7.4. I tak dalej.
Lista jest prowadzona od maja 2018 r. i zawiera ponad 120 wpisów.
Wszystkie spotkania są rozpoczynane za pośrednictwem firmowego Google Meet, nagrywane i w ciągu 1.5 godzin trafiają do folderu na współdzielonym Dysku Google, a linki do nagrań są duplikowane w tym samym Slacku. Oznacza to, że nie musisz przychodzić, jeśli się spieszysz, a następnie oglądać z prędkością 20 — zwykle sama prezentacja trwa do XNUMX minut, a dyskusja — jak się okazuje. Ale nie przekraczamy godziny)
PS Co się u Ciebie sprawdziło, a co nie?
Przydatne linki:
- Rodion Nagornov z Kaspersky Lab opowiada o i dlaczego to nie jest dokumentacja (dzięki za link do kanału Igora) (jest tego o wiele więcej).
- Igor Tsupko z Flant o w mojej firmie
- Aleksiej Katajew ze Skyeng (luki w wiedzy w zakresie technologii i określonych 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
