W zeszłym tygodniu opisaliśmy rózne problemy przy zarządzaniu wiedzą oraz słabo utrzymywanej dokumentacji. Skąd się biorą takie błędy w dokumentacji? Część może wynikać z kiepskiego jej napisania, ale część jest efektem działania znanego nam już parówkowego potwora – entropii. W momencie pisania dokumentacji wszystkie informacje w niej zawarte były prawdziwe, jednak z czasem zmiany w ciągle rozwijających się projektach, nawet nie związanych z tym konkretnym opisywanym w dokumentacji, a czasem nawet nie związane z samą firmą prowadzą do dezaktualizacji zapisanego słowa. Projekt pisany w Python2.7 kilka lat temu i dokumentacja uruchamiania go na maszynach pisana w tym samym czasie teraz sprawią użytkownikowi pewne problemy, ponieważ na nowszych systemach pytona 2.7 już nie ma. I aby przywrócić układ do stanu używalności, należy zaingerować w układ wiedzy i np. przygotować projekt pod Python3 wraz z dokumentacją.
Firma stawiająca na innowacyjność musi w tym momencie rozwijać pracowników w różnych specjalistycznych umiejętnościach. Kiedy mamy układ, w którym skład pracowników się nie zmienia, powinien następować stały wzrost ich umiejętności. Biorąc jednak pod uwagę że środowisko wiedzy w firmie się zmienia, np. ze względu na rozwój lub zaprzestanie świadczenia wsparcia usług przez środowiska zewnętrzne, to nadal może wystąpić sytuacja w której nasz układ wiedzy będzie niewydolny. Firma aby się rozwijać powinna ciągle przeznaczać część swoich zasobów na rozwój i przy założeniu, że te środki są dobrze lokowane, to ten nakład powinien się zwracać. Jednak jeżeli przy okazji tego rozwoju, nie zostanie on odpowiednio udokumentowany, to wymusi to tym samym na pracownikach, którzy normalnie tworzą coś nowego, przeznaczenie części swojego czasu, a więc zasobów firmy na cel niezwiązany z rozwojem. Tym samym przy często powtarzającej się takiej sytuacji nasz firma zacznie przegrywać na polu rozwoju. A w tym wypadku cięgle mówimy o tym że nie zmienia się skład osobowy. W pewnym sensie można ten problem rozpatrzeć od strony zadań do wykonania i pracowników do tego wykwalifikowanych. Patrząc na przykład naszych firm, załóżmy że w punkcie wyjścia firma ma głównie zadania utrzymaniowe związane z czynnością Koło Zębate, Śrubokręt i Komputer. W międzyczasie wprowadza nowe rozwiązania, do stworzenia których jest potrzebne Żarówka i Rakieta. W efekcie prac rozwojowych powstaje nowy produkt, który do utrzymania potrzebuje Komputera i Tarczy.
Skutkuje to tym, że chociaż nie zmienia się liczba dostępnych osób dla poszczególnych zadań (ciągle po dwie), to w przypadku drugiego zadania już nie jest w stanie zrobić tego druga osoba z utrzymania. Jeżeli jest to częste zadanie, najprawdopodobniej wystarczy przeszkolić dodatkowo pracowników utrzymania ruchu i problem powinien być rozwiązany. Przy dobrze prowadzonej dokumentacji i zmianach wprowadzanych w projekcie w odpowiedni sposób to rozwiązanie zadziała. Jeżeli jednak jest to rzadkie zadanie, to najprawdopodobniej pracownik bez odpowiedniej wiedzy, zgodnie z prawem entropii, będzie zapominał o tym jak rozwiązać dane zagadnienie. Może to też spowodować, że to zadanie będzie wykonywane tylko przez pierwszego pracownika utrzymania, co stanie się problematyczne jak tylko zrezygnujemy z założenia o braku zmian w składzie osobowym. Te zmiany to też nie muszą być sytuacje skrajne, takie jak zakończenie współpracy z firmą, czy śmierć, tak naprawdę wystarczy miesięczna choroba by już wprowadzić pewne zaburzenia, albo nawet dwutygodniowy urlop. Firma A może jeszcze opisać zagadnienia związane z tarczą i zadaniem do swojego archiwum, co powinno rozwiązać sytuację.
Popatrzmy jednak jeszcze na koszmarny wariant, czyli dokumentację słabą, lub w bardzo zaawansowanym stadium przeżarcia entropią. Dotychczas nasza firma wykonywała w utrzymaniu zadania typu Śrubokręt Koło Zębate, komputer, jednak doszło nam zadanie Komputer Tarcza, które zajmuje ok. ¼ zadań utrzymania. Mamy dokumentację, więc katastrofalny przypadek firmy B wydaje się być nam daleki. Ale! Na skutek rozwoju naszych rozwiązań nasza dokumentacja staje się nieaktualna, do jej użycia potrzebna jest również umiejętność Żarówka. Problem w tym, że taki zestaw ma tylko jeden pracownik i jest to drugi pracownik z Rozwoju. Tak więc przez znaczną część swojego czasu zajmuje się on utrzymaniem tego zadania i stara się wprowadzić pracownika nr 3 w te zagadnienia, aby był on w stanie również coś z tym zadaniem zrobić. Skutkuje to tym, że pracownik 1, właściwie sam robi zadania związane z rozwojem, co raczej nie jest dobrą praktyką, gdyż tworzy się wtedy ogarniacz, który magicznie tworzy różne rzeczy i mamy znowu Bus Factor dążący do 1. Z kolei pracownik 4 wykonuje zadania przede wszystkim z poprzednim zadaniem utrzymaniowym, a ponieważ pracownik 3 zajmuje się głównie nowym zadaniem z pracownikiem dwa, tutaj również na skutek naturalnego zapominania pracownika nr 3, bus factor zaczyna nagle dążyć do 1. A więc na skutek bałaganu w dokumentacji, bez zmian osobowych doszliśmy do sytuacji w której bus factor różnych czynności wszedł na alarmowy poziom 1.
Mając wszystkie te problemy w głowach firma Newterm od początku swojego istnienia zakładał odpowiedni system wymiany informacji. Jako podstawowe, ciągle działające elementy mamy listy mailingowe i system BTS, gdzie wiedza w firmie podzielona jest na wątki i zapisywane są różne informacje, od stricte technicznych, po takie mniej, jak kto po stronie klienta zajmuje się danymi sprawami. System ten działa całkiem dobrze, jednak nie jest najwygodniejszy do przeszukiwania nie do końca konkretnych zapytań. Dlatego też stworzyliśmy własną, firmową wiki, do której piszemy artykuły przy okazji różnych czynności, które wykonujemy. Od tworzenia backupu, stawiania nowego serwera przez listę najlepszych w okolicy restauracji, „How to” do naszych narzędzi na dokładnych instrukcjach tłumaczących architekturę i możliwości modyfikacji naszych systemów kończąc. Ten projekt ciągle się szybko rozwija i obecnie mamy co najmniej kilkadziesiąt różnych artykułów. Udało nam się wytworzyć system odpowiedniej ich redakcji oraz odpowiedniego oznaczania rzeczy nieaktualnych, dzięki czemu nie gubimy się w gąszczu tych informacji, jednak niestety utrzymanie wszystkich artykułów, szczególnie w przypadku zmian od nas niezależnych jest niemożliwe. Do utrzymania specjalistycznych projektów aktualizowaną dokumentację na Gitlabie.
Chyba podstawowym narzędziem, którego używamy jest linkowanie, głównie ze względu na mnogość stron na których opisujemy nasze rozwiązania. Większość naszego systemu połączona jest połączona właśnie w ten sposób, a centrum jego znajduje się w wiki. Dzięki temu łatwo odnaleźć niezbędne informacje. Sercem całego systemu jest jednak podejście do pracownika i dbanie o jego odpowiedni rozwój oraz przestrzeń wokół niego. Wszystkie poruszone wcześniej przykłady pokazują jednocześnie jak ważny jest człowiek. Wszystkie wprowadzone przez nas rozwiązania mają na celu z jednej strony przyspieszyć naszą pracę, ale również ją ułatwić i na swój sposób umilić. Chcemy też się rozwijać i korzystać z naszych osobistych doświadczeń, więc kilka lat temu uruchomiliśmy system recenzowania kodu. Jest o fenomenalne narzędzie pozwalające na szybki rozwój w zakresie programowania. Wszystkie nasze zmiany w kodzie przechodzą przez system recenzji, co ma dwie zalety. Po pierwsze więcej niż jedna osoba czyta każdą zmianę. Zwiększa się tym samym ilość osób, które wiedzą jak mniej więcej wszystko jest zbudowane. Po drugie, często pracując nad jakimś rozwiązaniem nie zdajemy sobie sprawy z innych, znanych już w firmie rozwiązań, które mogą się okazać lepsze. System recenzji pozwala nam dzielić się wiedzą i umiejętnościami w dynamiczny i skoncentrowany na zadaniach sposób.
… jeszcze nie to, ale chyba jesteśmy blisko. Z każdym rokiem przybywa nam doświadczenia w utrzymaniu naszych systemów i na jego podstawie go ulepszamy. Co pewien czas ktoś z nas znajduje jakieś ciekawe rozwiązanie i lubimy je przetestować. Mając na uwagę jednak nie przesadzenie z ilością systemów do utrzymania ciągle rozwijamy nasz system zarządzania wiedzą, tak aby informacje były zarówno szybkie do odnalezienia, jak i łatwe do wykorzystania.
Obrazki wzięte z: Tło zdjęcie utworzone przez jcomp - pl.freepik.com
Technologia plik wektorowy utworzone przez upklyak - pl.freepik.com
Tkanina plik wektorowy utworzone przez storyset - pl.freepik.com
https://pl.freepik.com/darmowe-wektory/transport-publiczny-autobus-trolejbus-4-ikony_3791851.htm
https://pl.freepik.com/darmowe-wektory/inzynier-grupa-mezczyzn-z-kaskiem-bezpieczne_5984913.htm