Im bardziej ostatnio zastanawiam się nad tym, czym się zajmujemy, tym bardziej dochodzę do wniosku, że nie powinniśmy bawić się „w zwinność”, tylko nazywać to po prostu optymalizacją procesów. I wcale nie powinno być to trudniej sprzedawać niż „agile”.
Co my właściwie robimy?
Nasz ulubiony proces Scrum nastawiony jest na rozwiązywanie złożonych problemów i dostarczanie produktów o wysokiej jakości. Tutaj optymalizujemy zadowolenie klienta, ale też jakość i wartość produktu. Z kolei w lubianym przez nas Kanbanie zależy nam na efektywności – realizowaniu tego, co trzeba, tak szybko (dobrze, precyzyjnie, dokładnie, itd.) jak się da. To oczywiście uproszczenia, ale patrząc z przymrużeniem oka, możemy uznać, że bierzemy sobie jakiś parametr i próbujemy go zoptymalizować.
Jakakolwiek zwinna transformacja powinna mieć z góry obrany cel i do tego celu dobierać odpowiednie środki. Pisaliśmy wielokrotnie, że jeżeli nasza firma sprzedaje swoje usługi realizując dokładnie to, co do nas przyjdzie jako zadanie, to prawdopodobnie model scrumowy nie będzie najszczęśliwszym. Podobnie, jeśli robimy powtarzalne rzeczy dla wielu różnych klientów i to jeszcze często w tym samym czasie.
Model działania dobieramy do potrzeb. Nigdy nie brniemy w Scrum, „bo wszyscy tak robią”. Wyrzućmy Scrum przez okno i najpierw ustalmy co chcemy osiągnąć naszymi „zwinnymi działaniami”, czy „transformacją”, a potem to zróbmy w najlepszy możliwy sposób.
Optymalizacja procesów w teorii i praktyce
Do dzisiejszego tekstu zainspirowała mnie kolejna wizyta w pewnym miejscu, które boryka się z problemem kolejek. Mówiąc bardziej precyzyjnie – nie boryka się z nim wcale, bo absolutnie nikt nigdy z nimi nic nie zrobił i prawdopodobnie nie zrobi. Irytuje to jedynie klientów, którzy tłoczą się w kilkunasto-kilkudziesięciominutowych kolejkach o każdej pełnej godzinie. Już na pierwszy rzut oka widać co najmniej kilka sposobów, na które można by lepiej zorganizować rejestrację, płatność, informację i kilka innych rzeczy, które powodują zatory. Tylko niestety obsłudze/właścicielom zupełnie to nie przeszkadza.
Bo żeby cokolwiek zacząć ulepszać, musi pojawić się potrzeba. Jeżeli „biznes się kręci”, to czasami nikogo nie interesuje, czy mógłby kręcić się lepiej. Ważne, że wszystko działa, przynosi pieniądze, po co coś więcej kombinować?
Dla każdego agile’owca taki sposób myślenia to jakaś herezja. My mamy we krwi robienie lepiej, efektywniej, skuteczniej i widzimy przestrzeń do rozwoju praktycznie wszędzie. Potem oczywiście przychodzi refleksja, że czasami takie ulepszanie na siłę może kosztować więcej niż potencjalny zysk. Ale nawet wtedy, przynajmniej wiemy, że opcja została przeanalizowana. Jeśli ktoś nie ma tego sposobu myślenia, to nawet nie podejmie próby. Ba, nawet nie pomyśli, żeby zatrudnić kogoś z zewnątrz.
Jak optymalizujemy?
Żeby cokolwiek optymalizować, trzeba się najpierw nad tym zastanowić. Co chcemy osiągnąć i jak się dowiemy, że nam się udało? Dlatego tak mocno podkreślamy empiryzm z jednej strony, a z drugiej pragmatyzm i takie zależności jak chociażby Prawo Goodharta. Ostrzega nas ono przed tym, żeby nie skupiać się na miernikach i wskaźnikach, bo wyjdzie nam to bokiem. Zamiast optymalizować to, o co nam chodzi, będziemy zajmować się „wykręcaniem wskaźników”.
Trudno się cokolwiek optymalizuje nie mierząc efektów, ale mamy też całą baterię rzeczy niemierzalnych albo trudno mierzalnych. Jak poprawić „przebojowość” naszego produktu? Łatwość obsługi? Miary drugiego i trzeciego rzędu są dokładnie tym, przed czym przestrzegałem w poprzednim akapicie. Zamiast skupić się na faktycznej łatwości obsługi, zaczniemy z uporem maniaka skracać liczbę kliknięć do każdej opcji. Gdzieś tutaj musi pojawić się sens i jakiś cel.
Pamiętajmy, aby nigdy cel nie zniknął nam z oczu. W Scrumie mamy Cel Produktu, który powinien być na tyle jasno określony, aby każdy wiedział dokąd zmierzamy i po co. Ponadto, Product Owner powinien mieć wizję, abyśmy wiedzieli o co nam tak naprawdę chodzi. Ale przede wszystkim – wszyscy musimy to po prostu czuć. Ale już wielokrotnie znęcaliśmy się nad błędami w budowie zespołów i chwilowo nie będę do tego wracał.
Przepis na ulepszanie
Nie oszukujmy się – nic nigdy nie będzie działało idealnie w długim terminie. Zmiany są nieuniknione. A zarówno kaizen, jak i scrumowe „wywoływanie zmian” przez wydarzenia mówią nam, że powinniśmy ciągle dopracowywać i dostosowywać sposób, w jaki działamy i pracujemy. Oczywiście, jeżeli nas interesuje rozwój. Jeśli nie, darujcie sobie dalsze czytanie tego tekstu, a może i nawet naszego zwinnego bloga.
Jeśli jednak jesteście w takiej sytuacji, że macie zarówno chęci jak i możliwości do ulepszania Waszego sposobu pracy, to nie ma na co czekać. Pamiętajcie, że wszystko zaczyna się od zbadania stanu bieżącego. Jeśli nie wiecie w jaki sposób działacie – narysujcie to. Może to być „profesjonalny” diagram procesu, może to być sterta karteczek na ścianie albo rysunek. Ważne, żeby na początku złapać „co się naprawdę dzieje”. Naprawdę, czyli zapominam o setkach stron procedur i regulaminów, tylko patrzymy jak faktycznie ludzie pracują. Bo to zwykle są dwa różne światy.
Jak już mamy stan bieżący, to przyglądamy się mu przez chwilę i weryfikujemy wszystkie nasze przypuszczenia. Niektóre nasze obserwacje to będą tylko wyjątki bądź przypadki szczególne. Nam chodzi o to, żeby złapać jak ta machina działa. Oczywiście, obsługa wyjątków jest jednym z procesów, ale musimy wiedzieć co tak naprawdę jest tym wyjątkiem.
Co zrobić dalej już doskonale wiecie. Trzeba ustalić, co chcemy osiągnąć i zmierzyć to, co jest do zmierzenia. Potem zacząć wprowadzać zmiany i modyfikacje, badając ich wpływ zarówno na nasze mierniki, jak i na nasz cel czy spodziewany efekt. I nie ustawać w działaniu, aż zadzieje się to, co chcieliśmy. A jeśli jest z tym jakichkolwiek problem, zawsze możecie zwrócić się do nas – naprawdę z chęcią pomożemy, bo uwielbiamy takie wyzwania.
