Menedżerowie wiedzą najlepiej, ile czasu trzeba poświęcić na budowanie świadomości i potrzeb w organizacji, zanim możliwe jest rozpoczęcie zmiany. Sytuacja zmienia się o 180 stopni, kiedy potrzeba, bardzo mocna, uderzy znienacka i zażąda zmiany. W takich momentach brakuje nam przygotowania, a co gorsza, nie mamy pojęcia jak zaistniałą potrzebę zaspokoić. Ostatnio taka sytuacja miała miejsce w firmie, w której pracuję. Artykuł ten przedstawia historię naszej podróży w nieznane oraz jej podział na elementy kluczowe dla procesu zarządzania (nieplanowaną) zmianą.
Przygotowania do podróży rozpoczęliśmy od zidentyfikowania potrzeby, którą było wdrożenie nowej metody zbierania wymagań od klienta. Zależało nam, aby wybrana metoda szła w parze z modelem ułatwiającym tworzenie systemu informatycznego i wzmacniała współpracę z klientem. Chcieliśmy udoskonalić naszą pracę w projektach i tworzyć możliwie najlepsze systemy. Tak oto stanęliśmy przed ciekawym wyzwaniem: jak zdobyć nową wiedzę i zaimplementować ją odpowiednio w firmie, nie mając na to zdefiniowanego planu, czasu i zasobów?
Wykorzystaj powstałą potrzebę do zainicjowania zmiany
Zaczęliśmy od burzy mózgów. Zebraliśmy informacje zwrotne zarówno wewnątrz organizacji, jak i poza nią. Jednogłośnie wygrało podejście Domain-Driven Design, w skrócie DDD, które polega na projektowaniu systemów we współpracy z ekspertami domenowymi (na przykład z obszaru bankowości, transportu, księgowości czy dowolnej innej domeny). Pozwala wypracować nie tylko model przyszłego systemu, ale także zapewnia wspólny grunt do rozmów pomiędzy stroną biznesu (domenową) i programistami przez cały okres trwania projektu. Ścisła współpraca i wypracowany przez obie strony wspólny język (ang. ubiquitous language) to podstawa DDD.
W celu zaprojektowania pierwszego modelu biznesowego musieliśmy zapoznać się z szerokim zestawem technik, narzędzi i terminologii DDD. Siłą rzeczy przyszedł czas na zapoznanie się z „biblią” DDD, czyli książką Domain-Driven Design Erica Evansa. Jest to obszerna literatura omawiająca aspekty DDD zarówno bardzo ogólnie, jak i na poziomie technicznej szczegółowości. W tym miejscu trafiliśmy na pierwszą przeszkodę: czas i motywację do zgłębienia ciężkiej lektury. Dalsze promowanie nowego podejścia w firmie wymagało znalezienia innych źródeł wiedzy, tj. opisanych w internecie technik DDD, czy filmów przedstawiających tę tematykę w bardziej przystępny sposób. Po przejściu powyższego procesu nauki, dotarliśmy do jego kulminacji, czyli pierwszego otwartego warsztatu DDD. Mogły w nim wziąć udział wszystkie zainteresowane osoby, które miały za zadanie zrobić szkic modelu wymagań klienta z wykorzystaniem wybranej techniki: Domain Storytelling. Warsztat cieszył się dużym zainteresowaniem i pozwolił na wyselekcjonowanie grupy osób prawdziwie zaciekawionych tematem. W ten sposób powołaliśmy zespół ludzi chętnych do nauki i przecierania ścieżek podczas naszej podróży w nieznane – Klub DDD.
Powołaj zespół przewodzący zmianie
Pełni zapału stworzyliśmy prywatny kanał komunikacji i umówiliśmy się na cotygodniowe spotkania trwające jedną godzinę. Następnie, omówiliśmy założenia przebiegu naszej inicjatywy rozwojowej. Po pierwsze, postawiliśmy na naukę opartą na eksperymentowaniu. Po drugie, wybraliśmy małe projekty czekające na wycenę i nie posiadające określonego priorytetu. Dzięki temu mieliśmy wstępnie poznaną domenę oraz czas i przestrzeń na naukę. W kolejnym kroku zdecydowaliśmy się na symulację pracy z klientem. Etap poznawania nowego podejścia i technik chcieliśmy przejść sami, żeby – mądrzejsi o nowe doświadczenia – kompleksowo pracować z klientami w przyszłości. Jeden z członków klubu samodzielnie zbierał wszystkie wymagania i opis domeny od klienta, a następnie odgrywał jego rolę podczas warsztatów. Dodatkowo określiliśmy części projektu:
- Zbudowanie modelu domeny w oparciu o wybraną technikę DDD.
- Zbudowanie modelu technicznego UML.
- Przełożenie opracowanych danych na zadania w systemie zarządzania pracą.
- Estymacja pracy na podstawie wszystkich powyższych elementów.
Za cel obraliśmy zapewnienie dokładniejszej wyceny badanego projektu klienta, połączonej ze zmniejszeniem ryzyka błędów i nieprzewidzianych zdarzeń. Uzbrojeni w założenia, etapy i cel projektu ruszyliśmy w podróż pewniejsi i pełni nadziei na sukces.
Sformułuj wizję i strategię zmiany
Pierwszy projekt postanowiliśmy zrealizować przy pomocy wspomnianej techniki Domain Storytelling, którą poznaliśmy wcześniej na otwartym warsztacie. Ze względu na dominującą ilość osób technicznych w Klubie DDD, ta technika została zaadaptowana tak, aby jej rezultaty były prawie że odzwierciedleniem modelu UML. Oznaczało to, że pracowaliśmy głównie na elementach domeny i staraliśmy się powiązać je odpowiednimi relacjami. Kiedy udało nam się zakończyć ten etap, trafiliśmy na kolejną przeszkodę. Okazało się, że wiedza w zespole na temat modelowania diagramów UML wymagała odświeżenia pod kątem dopasowania do nazewnictwa i struktur używanych w DDD. Zostało to wyeliminowane szkoleniem przeprowadzonym przez jednego z bardziej zaangażowanych członków klubu. W ramach zadania domowego, każdy wykonał diagram samodzielnie, a na kolejnym warsztacie dzieliliśmy się wynikami. W ten sposób wspólnie zbudowaliśmy finalną wersję diagramu UML dla projektu.
Usuń przeszkody i zmobilizuj do działania
Zgodnie ze wcześniejszymi założeniami dokończyliśmy pozostałe części projektu, czyli podział na zadania i ich estymację. Jednak cały czas czuliśmy głód wiedzy. Pierwsza próba nie była dla nas w pełni satysfakcjonująca i mieliśmy przeczucie, że założony cel można osiągnąć w jeszcze lepszy sposób. W trakcie pracy z Domain Storytelling niejednokrotnie porównywaliśmy ją z inną techniką, z którą mieliśmy wcześniej styczność, czyli Event Stormingiem. Bardziej techniczne podejście do tematu na początku sprawiło, że rosła w nas potrzeba powtórzenia eksperymentu z wykorzystaniem prostszej techniki nastawionej na podejście biznesowe. Nie chcąc się zatrzymywać, wybraliśmy kolejny projekt na takich samych zasadach jak pierwszy i zaczęliśmy modelowanie domeny wykorzystując Event Storming. Ta technika okazała się strzałem w dziesiątkę. Określanie i poukładanie zdarzeń domenowych pozwoliło nam zbudować tzw. Big Picture, czyli pełny obraz działania systemu. Co więcej, już podczas pierwszego warsztatu ustaliliśmy wiele tzw. Hot Spotów, czyli kwestii wymagających doprecyzowania z klientem, które pozwoliły na dokładne określenie wszystkich wcześniej nieprzewidzianych aspektów.
Dzięki temu, finalnie mieliśmy bardzo dobrze opisane ścieżki dla wszystkich ról w systemie, a cały system udało się podzielić na kluczowe części. Na podstawie tej wiedzy, bardzo dobry model UML wykonaliśmy „od ręki”, a przełożenie wszystkiego na zadania okazało się wielokrotnie prostsze.
Osiągaj szybkie sukcesy
Co dalej przed nami? Przede wszystkim: dzielenie się wiedzą. W kolejnym kroku Klub DDD będzie pracował nad prezentacją naszej podróży w nieznane oraz określeniem najlepszych praktyk, które udało nam się wypracować po drodze. Następnie będziemy wykorzystywać te praktyki „w akcji”, czyli pracując wspólnie z kolejnymi klientami podczas warsztatów Event Stormingu. Bogatsi o nowe doświadczenia i wiedzę jesteśmy gotowi dalej się uczyć i doskonalić procesy DDD. Najcięższa praca dopiero przed nami, czyli utrwalenie nowego standardu w codziennej pracy i przełożenie zdobytych doświadczeń na rozwijanie kultury w firmie. Istnieje norweskie przysłowie mówiące, że „tylko ten, kto wędruje, odnajduje nowe ścieżki” – pamiętajmy jednak, żeby na końcu podróży zawsze dodawać te ścieżki do firmowej mapy.
Kontynuuj zmianę i utrwal ją w kulturze organizacji
Wprawne oko menedżera wychwyciło, że nasza podróż w nieznane w praktyce okazała się interpretacją własną modelu zmiany Kottera. Mimo, że czasem wydaje nam się, że to co przed nami jest zbyt trudne i obawiamy się nieznanego, to warto pamiętać, że każda podróż składa się ze znanych nam części (czy to z niewygodnych przesiadek, czy nadrabiania drogi). W przypadku firmowej podróży w nieznane pamiętajmy o metodzie 8 kroków zarządzania zmianą, która może stanowić dla nas wartościowy drogowskaz. Nie bójmy się podróżować, uczmy się po drodze, wprowadzajmy i utrwalajmy zmiany na lepsze, bo jak widać na przykładzie powyżej wszystko jest trudne, dopóki nie staje się łatwe.
Head of HR in Siili Auto, Agile Transformation & Change Management practitioner. In management, she focuses on working with people, using CliftonStrengths in everyday work, and continuous improvement of communication. She loves to train and be trained, cultivates inspection and adaptation processes, and from time to time she is eager to extinguish company fires.