Projekt z celem, nie jednorazowa naprawa: metodyka pracy z systemami organizacyjnymi
Baza wiedzy, automatyzacja albo nowe narzędzie nie są ukończone w dniu uruchomienia. Trzeba jeszcze wiedzieć, kto je utrzymuje, jak rozpoznać awarię i co zrobić, gdy zmieni się proces.
Zdefiniuj koniec
Przed rozpoczęciem zapisz stan obecny, oczekiwaną zmianę i test odbioru. „Będziemy mieć bazę wiedzy” nie jest wynikiem. „Nowa osoba znajduje instrukcję i wykonuje procedurę bez pomocy autora” już nim jest.
Dodaj warunek utrzymania: właściciela, częstotliwość przeglądu i sygnał, po którym wiadomo, że dokument albo automat trzeba zmienić.
Trzy zasady, które stosuję w każdym wdrożeniu
1. Opisuj decyzje, nie tylko efekt. Kiedy zapiszesz, dlaczego wybrałeś taką strukturę i co jeszcze rozważałeś, następna osoba zrozumie kontekst, zamiast ślepo powtarzać instrukcję.
2. Rób prosto, nie efektownie. Jasne kategorie i przewidywalne nazwy decydują o tym, czy ktokolwiek zajrzy tam za pół roku.
3. Tłumacz zasady, nie tylko obsługę. Zespół musi rozumieć, dlaczego proces wygląda tak, a nie inaczej. Inaczej utknie przy pierwszej sytuacji, której nie ma w instrukcji.
Nie kończ na wdrożeniu
W jednym z długotrwałych wdrożeń nie skończyło się na dniu uruchomienia. Kolejne zmiany techniczne i organizacyjne pokazały, że dokumentacja, testy oraz odpowiedzialność za utrzymanie są częścią rozwiązania, a nie dodatkiem na koniec.
Test przekazania
Pytania do zadania przy każdym wdrożeniu:
- Co się stanie, jeśli osoba, która to wdrożyła, zniknie z organizacji jutro?
- Czy ktoś inny w zespole rozumie, dlaczego system działa w ten sposób?
- Czy istnieje dokumentacja decyzji, nie tylko instrukcja obsługi?
- Kto jest odpowiedzialny za aktualizację systemu, kiedy organizacja się zmieni?
- Czy wyznaczona osoba potrafi wykonać test, przywrócić poprzednią wersję i znaleźć historię decyzji?
- Czy wiadomo, jakie usługi zewnętrzne, konta i opłaty podtrzymują działanie?
Przekazanie nie jest prezentacją. Daj rozwiązanie osobie, która go nie budowała, i poproś o wykonanie zwykłego zadania oraz obsługę jednego błędu. Dopiero wtedy wyjdzie, czego brakuje w dokumentacji.