PROMIS
Jak wdrożyć hurtownię danych w jednej z największych firm w Polsce? vol. 2
30 marca 2017
User Experience (UX) – każdy z nas jest badaczem użyteczności, codziennie, w każdym momencie
13 listopada 2017

Jak wdrożyć hurtownię danych w jednej z największych firm w Polsce? vol. 3

Jak utworzyć tablicę Kanban?

Dziś ostatnia część studium przypadku wdrożenia hurtowni danych w Poczcie Polskiej opisana przez naszego zaprzyjaźnionego Project Managera. Pierwsza część to podłoże powstania projektu. W drugiej części opisane są planowanie, zespoły projektowe i kluczowe czynniki sukcesu. Czas na opis transformacji agile, która zaszła w organizacji w trakcie realizacji projektu. Miłej lektury. Redakcja wyGRAmy

W poprzednich odcinkach pisałem o wyzwaniach, jakie stanęły przed POSTDATĄ podczas budowy hurtowni danych dla Poczty Polskiej. Czas na parę słów o realizacji.

Czy projekt może wymusić zmiany organizacyjne w realizującej go firmie? Oczywiście, że tak!
W którym momencie realizacji projektu? W każdym!
Wtedy gdy nastąpi taka potrzeba. A taka właśnie nastąpiła.

Kolejny etap projektu polegał na modyfikacjach wszystkich powiązanych systemów oraz na budowie hurtowni danych. Była to kluczowa faza projektu – coraz bliżej do rozwiązania docelowego. Po drugim etapie wyciągnęliśmy wnioski i zastanawialiśmy się nad zmianami organizacyjnymi.

PRACOWAĆ INACZEJ. ALE JAK?

Poprzednie etapy projektu dały POSTDACIE poczucie pewności co do tego, co wewnętrznie chciałaby zmienić. Zawsze może być lepiej. Są pola do poprawy, są zauważane problemy przy jednoczesnej realizacji wielu projektów. Jest w końcu obecny w organizacji duch kaizen i wieczna motywacja do nadążania za nowoczesnymi trendami w wytwarzaniu oprogramowania.
Jak robią to inni?

Nieśmiało pojawiają się inicjatywy „uzwinniające” procesy, chęć dostarczania produktów w przyrostach, z szybkim feedbackiem od klienta. Czuć było atmosferę zmiany, ten szum w organizacji, w której wszyscy wiedzą, że zaraz coś wybuchnie, ale w tym dobrym sensie – za chwilę „ruszymy bryły z posad świata”!

Menedżerowie zorganizowali swoje „Utah” (pamiętacie Manifest Agile?) w nadmorskim Rzucewie. Spotkali się i przedyskutowali problemy oraz sposoby ich rozwiązania. Opracowali plan działań.
I wrócili do firmy. Z wielką determinacją „ewangelizacji” wszystkich ku zmianie.

Zidentyfikowano produkty. Stworzono zespoły produktowe, które zastąpiły dotychczasowe zespoły kompetencyjne. Zespoły zaczęły organizować się i pracować przy wykorzystaniu elementów metodyk zwinnych (SCRUM, KANBAN). Zidentyfikowani zostali Scrum Masterzy oraz Product Ownerzy.

W projekt hurtowni danych zaangażowanych było kilka zespołów produktowych. Dużą rolę w zarządzaniu zasobami w projekcie odgrywały cykliczne spotkania (statusy). Podczas takich spotkań Kierownik Projektu uzyskiwał wiedzę na temat stanu prac w poszczególnych zespołach, ale mógł też na bieżąco reagować na zaistniałe problemy i rozwiązywać konflikty.

Powołany został zespół transformacji (przemiany) złożony z osób najbardziej w zmianę zaangażowanych, które od początku zmian chwyciły wiatr w żagle i poczuły, że chcą mieć na nią wpływ. „Iniemamocni” – bo tak się nazwali – sami pracowali w sposób zwinny. Zbierali informacje o pojawiających się w procesie problemach, sprawach do rozwiązania, opisania, wymyślenia i organizowali je w postaci swojego backlogu. Zespół ten miał swojego Scrum Mastera i Product Ownera wspieranego przez zespół złożony z menedżerów i przedstawiciela Zarządu firmy (zespół też wybrał sobie nazwę – „Brygada”). Można? Można!

źródło: http://animowany.pl/iniemamocni/

„Iniemamocni” mieli co robić – każda sprawa budząca wątpliwości w poszczególnych zespołach produktowych trafiała na listę „To Do”. To nie tak, że „Iniemamocni” rozwiązywali wszystkie problemy, ale to oni proponowali rozwiązania, albo sposoby podejścia do problemu, wskazywali ludzi, którzy mogli znaleźć odpowiedzi.

Wyniki prac  „Iniemamocnych” były prezentowane „Brygadzie” w postaci zrealizowanych historyjek rozwiązujących określone problemy. Kierunki zmian i postępy prac były następnie przekazywane zespołom produktowym i wdrażane. Każdy miał prawo zgłaszać określone problemy, czy sprawy do rozwiązania, które według niego stawały się „blokerami” postępu zmian. Spowodowało to duże zaangażowanie osób, które chciały mieć wpływ na zmianę oraz wysoki stopień zrozumienia kierunków transformacji wśród pozostałych. Dzięki temu w trakcie transformacji objawiło się wiele nieznanych wcześniej w organizacji liderów, talentów i kompetencji. Wszyscy czuli, że mają, lub mogą mieć, wpływ na zmiany. Dużą wartością było samodzielne wzięcie przez zespoły odpowiedzialności za ich sposób pracy i współpracy z innymi zespołami jak również kierownikami projektów. Pomocna dla osiągnięcia takiego efektu okazała się zasada samoorganizacji zespołów.

Zarówno ”Iniemamocni” jak i Brygada na bieżąco monitorowali stan wdrożenia zwinnych metod pracy. Jedne zespoły wdrażały je szybciej, inne wolniej. Tym niemniej monitoring, pojawianie się obserwatorów na ceremoniach zespołów (planning, review, daily) oraz wdrażanie podobnych ceremonii w sposobie pracy innych, nieproduktowych zespołów (np. „Brygada”, zespoły back-office) dawały jednak poczucie konsekwencji i nieodwracalności wdrażanych zmian.

Wszystkie te działania poprawiły komunikację wewnątrz całej firmy, co dla tak integracyjnego projektu, jakim było stworzenie hurtowni danych, miało kolosalne znaczenie. Kierownik projektu wraz z zespołami szybko dostrzegli konieczność zapewnienia odpowiedniej komunikacji pomiędzy zespołami. Jednym z pierwszych efektów było skoordynowanie kalendarzy ceremonii zespołów w taki sposób, aby mogły one wypracowywać wspólnie rozwiązania. Pojawił się też Project Team, jako zespół złożony z Kierownika Projektu i Product Ownerów wszystkich produktów objętych projektem. Zespół ten uczestniczył w podejmowaniu kluczowych decyzji dla projektu, zarówno w sferze projektowej, jak również w zakresie rozwiązań technicznych i architektonicznych.

CO MA Z TEGO KLIENT?

Zmiana miała również wpływ na współpracę z klientem. Otrzymywał on teraz efekty prac zespołów w iteracjach. Poprawiło to komunikację, zarządzanie zakresem, jakością, ryzykami. Pojawiła się wspólna tablica kanbanowa z zadaniami, ryzykami i problemami w projekcie. Podczas spotkań z Klientem przygotowane produkty cząstkowe były prezentowane i wspólnie omawiane. Pod koniec realizacji tego etapu projektu klient na makiecie testowej otrzymywał dostęp do produktu cząstkowego (modyfikacja systemu), który następnie samodzielnie testował i zgłaszał uwagi, otrzymując szybki feedback. I vice versa – owocne przeglądy dawały szybką informację o poprawności przyjętych rozwiązań. Rosło wspólne zaufanie i satysfakcja z osiąganych efektów. Zespoły czuły rosnącą motywację i efekty zmiany sposobów działania.

kanban budowa tablicy

Powoli z kurzu i chaosu początku zmiany zaczęły się wyłaniać zarysy solidnych fundamentów i samej budowli nowej organizacji produkcji w firmie. Oczywiście nie tylko zespoły produkcyjne złapały bakcyla – pełna transparentność działań organizacji w tamtym czasie pokazała innym zespołom, np. wsparcia projektów czy kierowników projektów, że zwinny sposób działania przynosi widoczne efekty. Być może nie SCRUM, ale KANBAN, tablica historyjek i zadań, trzymanie się konsekwentnie zasady ograniczania prac w toku dawały odczuwalne efekty. Do tego pełna otwartość, transparentność i chęć zmiany. Była iskra do zmiany i był efekt. Po eksplozji, krótkim chaosie, tryby organizacji zaczęły krążyć w nowy, bardziej efektywny i świeży sposób.

„Iniemamocni” podjęli decyzję o samorozwiązaniu się. Zdecydowano, że transformacja przechodzi w fazę normalnej, operacyjnej działalności firmy.

Czy wszystko się udało? Pewnie nie. Czy transformacja się zakończyła? Też nie! Ale firma pokazała dojrzałość i elastyczność, możliwość dostosowania się do warunków wymagającego klienta i projektu. A to klucz do sukcesu. Kaizen…

Autor: Grzegorz Cysewski, POSTDATA S.A.

Wybierz szkolenie i podaj swoje dane

Wybierz szkolenie(wymagane)

Imię (wymagane)

Adres E-mail (wymagane)

Telefon (komórkowy)

X