Duże firmy też mogą być Agile! Business case.

Zdefiniowaliśmy kilkanaście ról użytkowników, pełniących różne funkcje i zadania w systemie, jednak danych nadal było za mało, aby w całości określić zakres projektu. Czas naglił i nasuwał się jeden wniosek: nie damy rady.

Wyzwanie

Z punktu widzenia maksymalnego ograniczenia ryzyka niepowodzenia tak znacznego projektu niejedna firma postawiłaby na jedną z tradycyjnych metod zarządzania, taką jak PRINCE2. My byliśmy jednak przekonani o tym, że tylko podejście zwinne (ang. Agile) da nam szansę na realizację projektu w wyznaczonym terminie, jednocześnie dostarczając nam niezbędnych narzędzi kontroli jakości. Goyello pracuje w oparciu o zwinną metodologię Scrum już od ponad 4 lat. Trzeba było jednak przyznać, że do tej pory projekty nie były tak duże i nie miały tak krótkiego czasu realizacji.

Obawialiśmy się, że nasz potencjalny klient, do tej pory przyzwyczajony wyłącznie do tradycyjnych metod zarządzania projektami, nie zaakceptuje formy współpracy, jakiej wymaga metodologia Agile, wymagająca dużego zaangażowania obu stron w proces powstawania systemu. Wiedzieliśmy z doświadczenia, że wiele firm woli przedstawić wykonawcy dokument z zakresem wymagań i poczekać na wynik końcowy.

Wymóg był jednak niepodważalny: termin i budżet nie mogły ulec zmianie. Nasze zasady gry były proste: projekt możemy zrealizować tylko w oparciu o Agile.

Decyzja naszego klienta: wchodzimy w to. Zwinnie i z pełnym zaangażowaniem.

Taki właśnie był początek współpracy dwóch firm: Goyello oraz SKOK Ubezpieczenia. Wyzwanie zostało podjęte.

Co jest do zrobienia?

SOUZ – System Obsługi Ubezpieczeń Zdrowotnych składa się z centralnej bazy danych oraz z 8 modułów przeznaczonych dla różnych grup użytkowników. Użytkownikami SOUZ są zarówno pracownicy SKOK Ubezpieczenia jaki i użytkownicy zewnętrzni – dostawcy usług medycznych oraz klienci. SOUZ został zintegrowany z portalem www.skokpozdrowie.pl, gdzie na bieżąco aktualizuje mapę dostępnych placówek oraz pozwala użytkownikom zewnętrznym na zalogowanie się do odpowiednich modułów systemu.

Umowa Agile: Jak to zdefiniować?

Czy racjonalnym jest zobligować się do terminu i budżetu, jeśli nie wiadomo, co dokładnie ma być w projekcie zrealizowane? Nieprecyzyjność zakresu przedsięwzięcia jest cechą charakterystyczną metodologii Agile i jednocześnie wyzwaniem, jeśli chodzi o sformalizowanie ustaleń w formie umowy.

Niestety niewiele jest dostępnych informacji na temat umów wspierających pracę w metodyce zwinnej. Zdecydowaliśmy się, w związku z tym, stworzyć „umowę zwinną” od podstaw. Tygodniami pracowali nad nią prawnicy obu firm. W tym samym czasie prace nad projektem już się rozpoczęły, bazując na obustronnym zaufaniu.

Aby móc stopniowo doprecyzowywać zakres prac, podzieliliśmy System na dziesięć Wydań. Każde z Wydań miało swój własny budżet, pochodzący z estymacji opowieści użytkowników. Za pomocą „story points” i kart do „planning poker” mogliśmy dość dokładnie określić czas potrzebny na wykonanie danego Wydania oraz liczbę zaangażowanych osób. W ramach tych cząstkowych budżetów prowadziliśmy rozmowy, uwieńczone tzw. dokumentem dotyczącym Wydania, stanowiącym tzw. backlog prac do wykonania. Na początku każdego Wydania SKOK Ubezpieczenia miały definiować tzw. Kryteria Akceptacyjne (definitione of done – DoD), będące przypadkami użycia, które powinny zostać spełnione przed zatwierdzeniem danego Wydania.

Budżet całościowy projektu był sumą poszczególnych budżetów cząstkowych. Goyello zobowiązało się do dotrzymywania terminów oraz zakresu. Wiedząc jednak, że pracując zwinnie, parametry często się zmieniają, zostawiliśmy pewną furtkę. Mianowicie w przypadku odchylenia od budżetu całościowego, strony miały się podzielić oszczędnościami bądź dodatkowymi kosztami po połowie.

Zwinność i elastyczność w projekcie, a koszty pod kontrolą – czy to możliwe?

Częsta interakcja pomiędzy stronami oraz regularne testowanie powstających elementów Systemu sprzyjają potrzebie wprowadzania zmian w stosunku do pierwotnych ustaleń. W projekcie zarządzanym tradycyjnie, każda zmiana funkcjonalności Systemu w trakcie trwania projektu zwykle prowadzi do wzrostu kosztów zleceniodawcy bądź do długich dyskusji na temat tego, czy dana kwestia została wcześniej dobrze zdefiniowana.

W projekcie Agile trzeba działać szybko i zgodnie. Dlatego już na etapie tworzenia umowy należało dokonać potrzebnych ustaleń, dotyczących zmian i dodatków w stosunku do pierwotnych wymagań.

Obie strony zgodziły się na rozwiązanie pozwalające na utrzymanie elastyczności, a jednocześnie pozwalające na trzymanie kosztów pod kontrolą. Ustaliliśmy, że tylko rozszerzenia funkcjonalności lub potrzeba stworzenia dodatkowych funkcjonalności będą prowadzić do wzrostu kosztów. Aby jednak trzymać się budżetu docelowego, umożliwiliśmy zamiany funkcjonalności na inne o podobnym zakresie w trakcie trwania projektu.

Rezultat

Dzięki podejściu zwinnemu, już po dwóch tygodniach prac mogliśmy pokazać pierwszy panel użytkownika. Po dwóch miesiącach rozpoczęliśmy wdrażanie systemu, a użytkownicy zaczęli wprowadzać dane produkcyjne. Był to przełomowy moment oraz nowe wyzwanie, gdyż od tej pory musieliśmy włączyć do projektu dodatkowe osoby, odpowiedzialne za obsługę uwag i pytań.

Użytkownicy dostarczyli nam cennego materiału do usprawnienia systemu. Jednocześnie byli bardzo pozytywnie zaskoczeni tym, że ich uwagi faktycznie zostały wysłuchane i wdrożone.

Dzięki użytej metodologii zwinnej, system był dostarczany naszemu klientowi fazowo i na bieżąco testowany. Całość została przekazana do odbioru przed uzgodnionym terminem, a zakres ewentualnych poprawek był ograniczony dzięki temu, że poszczególne wydania już w poprzednich fazach były poddane dogłębnym testom.

Dlaczego nam się udało?

Podstawową zaletą zwinnego podejścia do projektu jest skupienie na wyniku. Z naszego doświadczenia oraz obserwacji wynika, że tradycyjne metody zarządzania zbyt wymuszają koncentrację na organizacji, dokumentacji oraz dostarczeniu rozwiązania w ramach budżetu i ram czasowych. Takie podejście często oznacza ryzyko niepowodzenia projektu z powodu niezrealizowania tego, co klient „miał na myśli”.

Wspomniany wynik jest bezpośrednio uzależniony od stopnia zaangażowania wszystkich ważnych osób, łącznie z późniejszymi użytkownikami systemu, w trakcie całego projektu. Należy jednak wspomnieć, że poświęcenie zespołu po stronie Goyello i użytkowników po stronie SKOK Ubezpieczenia nie byłoby nic warte bez odpowiedzialnej i bardzo zaangażowanej postawy właściciela produktu (ang. Product Owner) i pozostałych członków zespołu i dyrekcji po stronie klienta.

Ogromne znaczenie dla powodzenia tego projektu miała również formalna jego strona, nie przytłaczająca jednak całego projektu swoim ogromem. Bardzo dobrze przygotowana umowa, dokładnie określająca sposób prowadzenia projektu miała tu kluczowe znaczenie. Każda faza (ang.Sprint) i każde Wydanie opatrzone były odpowiednią dokumentacją, aby wykluczyć jakiekolwiek wątpliwości co do zużytego budżetu i wdrożonych funkcjonalności. Dzięki temu ostateczna akceptacja projektu przebiegła gładko i bez zastrzeżeń, a SKOK Ubezpieczenia korzystają z systemu, którego jest „współtwórcą”.

Peter Horsten prezes zarządu Goyello