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

Jak w ciągu 4 miesięcy zbudować i wdrożyć skomplikowany system do obsługi ubezpieczeń zdrowotnych? Goyello zmieściło się w czasie i w budżecie dzięki zastosowaniu podejścia Agile. Wyzwanie Otrzymaliśmy od klienta, firmy SKOK Ubezpieczenia, kilkanaście stron tekstu z technicznymi i funkcjonalnymi założeniami systemu, którego kluczowa część miała zostać wdrożona i uruchomiona w ciągu 4 miesięcy. Zaczęliśmy działać. Zdefiniowaliśmy kilkanaście grup użytkowników Systemu Obsługi Ubezpieczeń Zdrowotnych, pełniących różne funkcje i zadania, 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. Aby ograniczyć ryzyko niepowodzenia tak złożonego projektu, większość firm postawiłaby na tradycyjną metodę zarządzania, taką jak np. 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 przyzwyczajony wyłącznie do tradycyjnych metod zarządzania projektami nie zaakceptuje formy współpracy, jakiej wymaga metodologia Agile. Trzeba by zaangażować się w proces powstawania systemu, podczas gdy większość firm wolałoby przedstawić wykonawcy dokument z zakresem wymagań i poczekać na wynik końcowy. Cel projektu był jednak istotny dla obu stron: 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. Zakres działań Użytkownikami SOUZ mieli być zarówno pracownicy SKOK Ubezpieczenia jaki i użytkownicy zewnętrzni – dostawcy usług medycznych oraz klienci. Działania zespołu Goyello zakończył się powstaniem złożonego Systemu Obsługi Ubezpieczeń Zdrowotnych składającego się z centralnej bazy danych oraz z 8 modułów przeznaczonych dla różnych grup użytkowników. 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 do pierwotnych ustaleń. W projekcie zarządzanym tradycyjnie, każda zmiana funkcjonalności systemu w trakcie trwania projektu prowadzi zwykle do wzrostu kosztów 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ę, ż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 2 tygodniach prac mogliśmy pokazać pierwszy panel użytkownika. Po 2 miesiącach rozpoczęliśmy wdrażanie systemu, a użytkownicy zaczęli na nim pracować i korzystać z dostępnych funkcjonalności. 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 wymuszają zbytnią 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ą”. Autor: Peter Horsten – prezes zarządu polsko–holenderskiej firmy Goyello, zajmującej się outsourcingiem IT dla krajów Europy i Ameryki. Odpowiedzialny za podejmowanie strategicznych decyzji w zakresie sprzedaży, marketingu oraz struktury produktów w Goyello, skupia się głównie na gotowych rozwiązaniach biznesowych typu SaaS. Zwolennik metodyki zwinnej Agile. W 2009 roku wprowadził na stałe podejście Scrum do Goyello.     Fot. Flickr, oddharmonic na lic. CC BY-SA 2.0