Praktyczny przewodnik po budowaniu wewnętrznych narzędzi biznesowych: jak rozpoznać proces, który go potrzebuje, dlaczego większość wewnętrznych narzędzi zostaje porzucona, droga od chaotycznego procesu ręcznego do oprogramowania oraz jak zachować kontrolę zamiast dokładać kolejne narzędzie, którego nikt nie utrzymuje.
Zespoły operacyjne, kierownicy biura, założyciele i rosnące firmy, które prowadzą kluczowy proces na ręcznych krokach, wiadomościach na czacie i pamięci.
- Sposób na rozpoznanie, który proces ręczny naprawdę potrzebuje narzędzia
- Droga budowania od chaotycznego procesu do oprogramowania, któremu ludzie ufają
- Wewnętrzne narzędzie, które jest twoje i które możesz zmieniać, a nie kolejna pozycja w backlogu
Każda rosnąca firma opiera się na kilku procesach, które nigdzie nie mieszkają: zatwierdzenie, które dzieje się na czacie, przekazanie zadania, które istnieje tylko w czyjejś głowie, status, o który wszyscy pytają, bo nigdzie nie jest zapisany. Właśnie po to są wewnętrzne narzędzia. Powodem, dla którego tak mało z nich powstaje, nie jest już koszt; chodzi o to, że nigdy nie wyszły ponad kolejkę działu IT. Ten przewodnik jest o tym, jak samodzielnie zbudować to właściwe, żeby naprawdę powstało.
Narzędzia potrzebuje ten proces, o który ludzie ciągle dopytują się nawzajem, w którym praca staje w oczekiwaniu na przekazanie zadania i który obecnie trzyma się na wiadomościach z czatu i pamięci. Jeśli powtarzającym się pytaniem w twoim zespole jest jakaś wersja "jaki jest status X?" albo "kto ma teraz Y?", to pytanie jest specyfikacją: narzędzie istnieje po to, by odpowiedź była widoczna bez potrzeby pytania kogokolwiek.
Wewnętrzne narzędzia nie polegają na zastępowaniu ludzi; polegają na zdjęciu podatku od koordynacji, który rośnie razem z zespołem. Firma pięcioosobowa koordynuje się w głowie. Firma dwudziestoosobowa, która wciąż koordynuje się w głowie, wydaje coraz większą część każdego dnia na aktualizacje statusów, ściganie zatwierdzeń i ponowne tłumaczenie, jak stoją sprawy. Ten niewidoczny narzut to dokładnie to, co usuwa skoncentrowane wewnętrzne narzędzie, dlatego właściwe pierwsze narzędzie celuje w proces, który najbardziej krwawi czasem na koordynację.
Wybieraj według bólu, mierzonego uczciwie. Poświęć kilka dni na obserwowanie, który proces generuje najwięcej "szybkich pytań", najwięcej porzuconych przekazań, najwięcej "myślałem, że ty się tym zajmujesz". Zwycięzca rzadko jest najbardziej skomplikowanym procesem; to ten najczęściej koordynowany.
Wewnętrzne narzędzia zawodzą z przewidywalnych powodów, a znajomość ich z góry to w większości to, co utrzymuje twoje przy życiu.
Wewnętrzne narzędzie działa, gdy korzystanie z niego jest łatwiejsze niż niekorzystanie. Zanim dodasz jakąkolwiek funkcję, zapytaj, czy sprawia ona, że narzędzie jest szybsze w użyciu, czy wolniejsze. Większość porzuconych wewnętrznych narzędzi umarła z dobrych intencji: pola, które ktoś mógłby chcieć, kroki, które wydawały się skrupulatne, a wszystko to obciążało codzienną drogę, aż ludzie z niej zeszli.
Przejście od procesu w głowach ludzi do narzędzia biegnie według niezawodnej sekwencji. Pominięcie pierwszego kroku to powód, dla którego tak wiele narzędzi rozwiązuje niewłaściwy problem.
Najgorszym procesem zespołu logistycznego było wydawanie sprzętu: kto ma które urządzenie, od kiedy i czy jest przeterminowane, a wszystko to prowadzone na kanale czatu i w pamięci jednej osoby. Obserwowane przez tydzień, sprowadziło się do czterech rzeczy: zasoby, ludzie, wydania oraz stan zwrócone/przeterminowane. Wersja pierwsza pozwalała każdemu wypożyczyć urządzenie, pokazywała status całej floty na jednym ekranie i automatycznie oznaczała przeterminowane pozycje. Codzienne pytanie "kto ma skaner?" po prostu ustało, bo odpowiadał na nie ekran.
Różnica między wewnętrznym narzędziem, które żyje, a tym, które umiera, zwykle nie leży w funkcjach; leży w tym, czy zespół potrafi utrzymać je w zgodzie z rzeczywistością. Chronią je dwie rzeczy.
To tutaj opisanie procesu i zbudowanie narzędzia wokół niego wygrywa zarówno ze sztywnym szablonem, jak i z jednorazowym skryptem od programisty, który potem odchodzi. Dostajesz oprogramowanie skrojone pod twój prawdziwy przepływ pracy, które możesz dalej przekrawać w miarę jego ewolucji, bez ponownego dołączania za każdym razem do kolejki działu IT. Narzędzie pozostaje żywe, bo ludzie prowadzący proces mogą utrzymać je w zgodzie z prawdą.
Celuj w proces, o który ludzie ciągle dopytują się nawzajem i w którym praca staje na przekazaniach. Poświęć kilka dni na obserwowanie, który z nich generuje najwięcej "szybkich pytań" i porzuconych przekazań; najczęściej koordynowany proces, a nie najbardziej skomplikowany, to miejsce, gdzie narzędzie usuwa najwięcej zmarnowanego czasu.
Bo rozwiązują schludną wersję procesu zamiast tej prawdziwej, bo aktualizowanie ich jest wolniejsze niż wiadomość na czacie, którą zastąpiły, bo nie potrafią się zmienić, gdy zmienia się proces, albo bo stają się silosem danych. Rozwiązaniem jest najpierw obserwować prawdziwą pracę, uczynić narzędzie najszybszą drogą i umieć zmieniać je samodzielnie.
Tylko główną ścieżkę: utworzyć rekord, przeprowadzić go przez prawdziwe stany, zobaczyć jego status i przekazać dalej, plus role, które decydują, kto co robi i kto musi jedynie obserwować. Dodaj wyjątki, które naprawdę zaobserwowałeś, a nie wyobrażone, i zostaw całą resztę na czas, gdy ludzie już korzystają z narzędzia.
Już nie, a zbudowanie go samodzielnie daje prawdziwą przewagę: wewnętrzne procesy zmieniają się bez przerwy, więc narzędzie, które możesz edytować w miarę zmian procesu, pozostaje użyteczne, podczas gdy takie, które potrzebuje zgłoszenia do IT przy każdej zmianie, rozjeżdża się i zostaje porzucone. Opisz przepływ pracy i zachowaj możliwość jego zmieniania.