Dziarski Dev

Zespołowa Baza Wiedzy – Wiki. Bardzo Jej Potrzebujesz.

Krzysztof Baranowski

14 sie 2023

Siema! 👋

Tym razem poruszę temat zespołowej bazy wiedzy i tego, co możesz zrobić w tym kierunku, żeby ożyła i była źródłem wartościowej wiedzy o procesach i zasadach panujących w zespole.

Co Cię czeka:

✅ Czym jest zespołowa baza wiedzy (wiki) i dlaczego jest ważna.
✅ Mój przykład zespołowej strony domowej.
✅ Przykłady wiedzy, które mogą być częścią bazy wiedzy.
✅ Lista argumentów, których możesz użyć w rozmowie z liderami lub zespołem, aby „przepchać” tę inicjatywę.

Jedziemy!

W zeszłym roku jakiś czas po awansie (wcześniej miałem błędne przeświadczenie, że to nie moja działka) uznałem, że posprzątam zespołową bazę wiedzy, czyli popularne wiki. Było tam mnóstwo bałaganu i nieraz kilka minut trzeba było spędzić, żeby coś znaleźć. Wiele stron było nieaktualnych, czasami opisujące procesy, które już od dawna nie mają znaczenia.

Sprzątnąłem. Jest lepiej. Złoto.

Pogadajmy dzisiaj o tym, co Ty możesz zrobić dla swojego zespołu.

🫵

Ważne jest, aby jakiekolwiek zmiany zaczynać od siebie. Jeśli widzisz, że możesz wpłynąć pozytywnie na otoczenie, to po prostu to zrób. Każda taka aktywność kumuluje się z czasem. Co w kontekście Twojej kariery przybliża Cię do awansu czy bycia po prostu bliżej ważnych wydarzeń.

Twoje zadanie na ten tydzień.

Masz bojowe zadanie w tym tygodniu Zaktualizuj, stwórz nową stronę wiki lub po prostu wrzuć ten pomysł do agendy waszego dev meetingu. Jeśli zdecydujesz się na własną inwencję, to przygotuj procedurę jakiegoś procesu (sam wiem, że nigdy nie ma na to czasu). Poświęć na jej przygotowanie nawet tylko 30 minut dziennie. Po kilku dniach a może nawet wcześniej będziesz miał coś, co pomoże Twojemu zespołowi.

Zastanawiasz się po co? Wszyscy pamiętamy, jak coś robić, dopóki robimy to regularnie. To tak, jak z treningiem na siłowni – jeśli przestajemy ćwiczyć, tracimy formę. Po pewnym czasie wszystko magicznie ulatuje. Wtedy taka procedura jest na wagę złota.

Co, jeśli mamy to gdzieś spisane? Wtedy jest sztosik. Otwieramy konkretną stronę, robimy coś krok po kroku. Nie ma nad czym się zastanawiać, więc zmniejsza się szansa na popełnienie błędów czy to, że o jakimś kroku zapomnimy. Innym plusem jest możliwość wdrożenia nowej osoby w konkretny proces bez udziału (lub z mniejszym udziałem) dodatkowych osób. Co oznacza, że np. dzięki temu możesz dodać nową wartość do procesu onboardingu nowych członków zespołu.

🚀 Na czym można się skupić?

Strona domowa zespołu.

Możesz przygotować stronę agregującą najczęściej wykorzystywane linki w zespole. Taka strona domowa. Można tutaj dodać adresy do najnowszych makiet UI, zasad pracy z kodem czy praktyk wykorzystywanych w zespole. Wszystko, co związane z codziennymi procesami może również się tutaj znaleźć.

Przykład strony domowej, którą przygotowałem.

Procedura przygotowania nowego release.

Opisz krok po kroku, co należy otworzyć, kliknąć, przesunąć, aby przygotować nowy build testowy czy produkcyjny aplikacji. Pamiętaj, że bardziej skomplikowane kroku uzupełnić o dodatkowe zrzuty ekranu.

Przy okazji spisywania procesu, może się okazać, że w procesie jest coś, co warto zoptymalizować.

Strona onboardingu.

Tutaj nie chodzi mi o to, żebyś spisał w pełni wszystko, co może być pomocne dla nowej członka zespołu. Sugeruje jednak, żebyś przygotował (lub przynajmniej zapoczątkował) spisanie listy problemów, które nowe osoby napotkały podczas pierwszych dni w pracy – może sam pamiętasz, co było problematyczne? Możesz pogadać z nowymi kolegami i koleżankami i zapytać ich o opinie oraz sugestie.

👍

Pamiętaj jednak, aby wcześniej porozmawiać z liderem zespołu (manager, team lead) odpowiedzialnym za zatrudnianie i zarządzanie ludźmi w zespole.

Kilka przykładowych pomysłów na stronę onboardingu:

Link do strony z listą narzędzi wykorzystywanych w zespole.
Opis używanego procesu wytwarzania oprogramowania (czyli np. jak wygląda scrum w Twoim zespole).
Link do strony z zespołowymi praktykami pracy kodem.
Link do glosariusza (więcej w kolejnym punkcie).
Link do strony ze strukturą zespołu.
Zadania do wykonania w pierwszych dniach pracy.

Glosariusz.

Spis terminów, akronimów i żargonu używanego w zespole wraz z dodatkowym wyjaśnieniem. Świetna rzecz dla nowych osób w zespole oraz przypominajka dla obecnych.

U mnie w zespole istnieją skrótowce takie jak: CE, CFO, KVP, PPE, WL. Warto je spisać i zwięźle wyjaśnić. Oprócz tego wyjaśnienia pojęć, którymi się posługujecie na co dzień, będą również pomocne. W projekcie warto używać tego samego języka. Dlatego, jeśli widzisz, że biznes (klient) i zespół developerski używają różnych określeń na tę samą rzecz, to oznacza, że warto ustalić jedną wersję i zapisać to w glosariuszu.

🧠

Używanie wspólnego języka zmniejsza ryzyko nieporozumień i ograniczają obciążenie kognitywne (poznawcze), więc to dobra optymalizacja.

Tabelka może być dobrym punktem wyjścia. To po prostu musi być czytelne.

🦉

Swoją drogą wspólny język (ang. Ubiquitous Language) – czasami tłumaczony jako wszechobecny język – jest jedną z praktyk, które są częścią koncepcji Domain-Driven Design (DDD).

Ogólnie DDD to zbiór wielu koncepcji i technik, które pomagają w projektowaniu złożonych modeli systemowych i poszukiwania (jak również implementacji) relacji pomiędzy nimi. Mówiąc prościej: pozwala na lepsze zrozumienie tego, co chcemy zaimplementować (domeny) oraz odpowiednie odzwierciedlenie tego w kodzie.

Katalog narzędzi, skryptów

Lista narzędzi, z których korzysta zespół wraz z linkami do nich. Możesz dodać tutaj istotne portale, które składają się na firmowy intranet (zamawianie licencji czy sprzętu). Jeśli w projekcie korzystacie z własnych skryptów, to można dodać informacje o tym, jak z nich korzystać. Często taka wiedza przewija się podczas rozmów czy czatów z członkami zespołu. Spisana raz, zmniejszy niepotrzebną komunikację: wysyłasz link i po robocie. 👌

🙏

Anonimowa ankieta, w której możesz wyrazić opinie o treściach, które do Ciebie wysyłam. Mega pomoc dla mnie, więc będę wdzięczny za sugestie.
https://forms.office.com/r/yH2en10max

Strony, z rozwiązaniem konkretnych problemów

Być może w swoim projekcie są typowe, powracające problemy, które nadal nie są rozwiązane z różnych powodów. Warto spisać sposób na ich rozwiązanie. Tak jak w przypadku skryptów taka wiedza żyje często na czatach, więc warto ją spisać w jednym miejscu.

Inne pomysły

Polecane książki, kursy czy miejsca w sieci z wiedzą (możesz dodać tam link do tego mailingu 😎).
Instrukcje dotyczące konfiguracji środowiska developerskiego.
Procedury i zasady dotyczące HR – tutaj bardziej temat dla Twojego managera.
FAQ – odpowiedzi na najczęściej pojawiające się pytania.

Wiesz, nie musisz tego robić samodzielnie.

Możesz po prostu zaproponować pomysł o zmianach w wiki (czy jej stworzenie, jeśli jeszcze nie istnieje) liderom zespołu, czy na dev meetingu. Skorzystaj z poniższych argumentów:

✅ Oszczędność czasu. Coś spisanego raz, będzie wykorzystywane wielokrotnie. Nie musimy zajmować czasu innych członków zespołu.
✅ Łatwiejszy onboarding nowych osób. Dajesz im link z listą podstawowych informacji o zespole i projekcie. Potem wystarczy, że uzupełnimy je dodatkowymi spotkaniami, które doprecyzują całość.
✅ Spisanie procedur zwiększa stabilność tego, czego dotyczą. Rzeczy wykonujemy krok po kroku, a nie bazując na tym, co nam się wydaje czy pamiętamy.
✅ Wiedza członków zespołu jest ulotna. Jesteśmy nadal ludźmi, a nie dyskami twardymi, więc często zapominamy. Wiedza spisana w wiki, nie zniknie, gdy ktoś z zespołu, kto nią dysponował do tej pory, odejdzie z projektu. Zresztą, być może doświadczyłeś sytuacji, że podczas wpisywania tego samego od miesięcy hasła do komputera nagle go zapominasz. Dlatego nawet utarte procesy, które realizujemy na co dzień, mogą pewne dnia być w takiej czy w innej formie błędnie zrealizowane. Dlatego proces spisany czarno na białym ma duże znaczenie.

Zrób to w tym tygodniu.

Jeśli czytasz to punktualnie w poniedziałek, to masz nadal pełny tydzień, aby ruszyć temat zespołowego wiki. Nawet jeśli członkowie Twojego zespołu nie będą skakać z radości, z tego powodu (większość osób woli skupiać się na kodzie, dlatego Ty wchodzisz tutaj cały na biało), to z pewnością z wielką wdzięcznością będą korzystać z wiki, kiedy pojawi się u nich paląca potrzebna przypomnienia sobie działania danego skryptu, czy procesu.

Ja w ostatnim czasie kilkukrotnie swoim koleżankom i kolegom z pracy podsyłałem linki do stron z naszej bazy wiedzy, jako odpowiedź na ich pytanie. Cholerna oszczędność czasu. ⏱️

🚀 Powodzenia! Daj znać, na jaki pomysł wpadłeś i jak zareagował zespół.

Jeśli podobają Ci się treści, które tworzę, to podeślij informację o moim newsletterze innym osobom. Dziękuję!

👉 Anonimowa ankieta, w której możesz wyrazić opinie o treściach, które do Ciebie wysyłam. Mega pomoc dla mnie, więc będę wdzięczny za sugestie.https://forms.office.com/r/yH2en10max

👉 Podcast "Pierwsze Kroki w IT"
Jakiś czas temu byłem gościem Mateusza Bogolubowa z jego podcaście "Pierwsze Kroki W IT". Pogadaliśmy o apkach mobilnych – mega przeżycie. Odcinek ujrzy światło dzienne 18 sierpnia.

Listę odcinków i info o podcaście znajdziesz tutaj. Może akurat przypadnie Ci do gustu. Znajdziesz tam treści nie tylko skierowane do osób początkujących.https://devmentor.pl/bc/podcast
.

👉 Moja książka o Flutterze.
Moja książki "Flutter. Podstawy" ujrzy światło dzienne na jesień tego roku. Trwają ostatnie szlify po stronie wydawcy. Jeśli Flutter Cię interesuje, to odsyłam Cię na stronę wydawnictwa Helion, gdzie już teraz możesz zapisać się na listę oczekujących.