Na końcu 2014 roku podjęliśmy z Tomkiem decyzję, że nie będziemy nowych projektów IT realizować w modelu „fixed” (stała cena; stały termin; wodospoadowy model wdrożenia, gdzie po kilku miesiącach prac klient otrzymuje gotowy produkt w określonym na początku budżecie)Postanowiliśmy pracować tylko w modelu time & materials przy wykorzystaniu zwinnych metodyk (głównie w modelu SCRUM).

Byliśmy przekonani, że ta ważna decyzja będzie niosła ze sobą daleko idące, pozytywne, skutki dla naszych partnerów i całej firmy. Mieliśmy sporo doświadczeń przy prowadzeniu wdrożeń e-commerce w obu modelach i w rozmowach sprzedażowych. Dlatego, trochę baliśmy się reakcji naszych partnerów na stanowczą odmowę podejścia do projektów w stałym budżecie. Doświadczenie pokazało, że klienci z branży handlowej, w której działamy często bardzo silnie dążą do „zamknięcia budżetu” nowego przedsięwzięcia („muszę wiedzieć ile to kosztuje”). Czasami też są bardzo nieufni („musicie wziąć za to pełną odpowiedzialność”). Ostatnie 4 miesiące spędziłem w dużej mierze na rozmowach i „konwertowaniu” projektów w których rozmowy już trwały – z modelu fixed price do time & materials. Żaden klient nie zrezygnował. Powiem więcej: najwięksi sceptycy zdążyli wrócić i podziękować.  Ich projekty kończą się wcześniej i w lepszej jakości niż było to zakładane. Tomek napisał już dlaczego warto budować swój dział IT wraz z firmą wdrożeniową. Ja, swego czasu, napisałem dlaczego określenie zakresu prac w projekcie informatycznym nie jest możliwe. Chciałem napisać jeszcze o kilku argumentach za modelem time&materials, które pojawiły się w czasie tych rozmów.

Zrozumienie

Praca w time&materials wymaga zrozumienia tego modelu przez obie strony. Zwłaszcza dobrego zrozumienia przez klienta. Praca przy wykorzystaniu metodyki zwinnej zakłada zbudowanie i pracę zespołu składającego się z przedstawicieli obu stron przedsięwzięcia. U nas wygląda to tak, że w zespole SCRUM’owym mamy Product Ownera – który jest przedstawicielem klienta i podejmuje decyzje biznesowe o kształcie systemu. Poza tym projekt składa się ze specjalistów (głównie z naszej strony, ale mogą to też być osoby z zespołu klienta – programiści, project manager, analitycy itd.). Taki podział sił oznacza, że zlecający prace ma ciągłą i pełną kontrolę nad kształtem powstającej aplikacji.  Angażujemy klienta w planowanie zakresu prac.

Przed rozpoczęciem każdej iteracji prac (zazwyczaj sprinty trwają 2 tygodnie) odbywa się spotkanie, w czasie którego zespół planuje zakres kolejnego sprintu (planowanie) i podsumowuje poprzedni (retrospektywa). Zadania są estymowane z pomocą punktów funkcyjnych lub „idealnych godzin” (ile zadanie zajmie godzin gdyby programista nie był rozpraszany niczym innym). Po każdym sprincie obie strony wiedzą więc ile udało się zrobić względem tego, co było planowane (można wyznaczyć szybkość zespołu). To bardzo cenna informacja pod planowanie kolejnego sprintu. Po każdym sprincie odbywa się też demo gdzie zespół prezentuje zakończone funkcjonalności gotowe do testów klienta. Założenie jest takie, że po każdym sprincie powinna być możliwa publikacja i korzystanie z nowo powstałych funkcji. Klient bierze udział też w codziennych daily (15 minutowe spotkania, często na Google Hangouts – gdy klient jest poza naszą siedzibą) gdzie może reagować na bieżąco na wszystkie potrzeby informacyjne i wie o tym, co dokładnie jest/ było/ będzie robione. Udział klienta w projekcie oznacza, że w każdym momencie może on doprecyzowywać zakres prac – dodawać do kolejnych sprintów nowe zadania lub je usuwać (obecnego sprintu raczej nie powinno się modyfikować). Określać, czy jakość danej funkcji jest wystarczająca lub nie.

Często poruszanym argumentem przeciwko modelowi pracy bez określonego wymiaru prac jest obawa, że klient nie będzie w stanie kontrolować budżetu projektu a firma wdrożeniowa może realizować różne zadania wolno i w ten sposób bogacić się na nieświadomym kliencie :) Na pewno są firmy które tak próbują, ale to działanie na krótką metę, bo prędzej czy później kończy się utratą zaufania, brakiem efektów. Pierwszy wspólny projekt staje się ostatnim. Mało kto może sobie na to pozwolić, biorąc pod uwagę, że firmy IT w dużej mierze żyją ze sprzedaży usług obecnym klientom. Dobór firmy wdrożeniowej jest ważny – głównie trzeba popatrzeć na referencje i portfolio. Jestem tutaj przekonany, że tak jak nasza firma, inne poważne firmy nie oszukują swoich klientów. Jeśli przyjąć, że firma wdrożeniowa dąży do ustabilizowania jak najlepszego i najszybszego zespołu – udział klienta oznacza, że może on wdrożyć projekt szybciej zgadzając się na bieżąco na uproszczenia, może zadecydować o tym, żeby wdrożyć uproszczoną wersję MVP którą potem będziemy rozbudowywać. Może zrobić mnóstwo rzeczy.

Przejrzystość

W odróżnieniu od powyższego – w modelu fixed – po zakończeniu etapu analitycznego na projekt jest opuszczana kurtyna i zespół rozpoczyna prace. Nie jest na rękę dla firmy wdrożeniowej dopytywać klienta czy cokolwiek mu pokazywać bo może to spowodować rozbudowę zakresu prac. Nie ma idealnych analiz przedwdrożeniowych. Najczęściej prace są uruchamiane gdy efekty analizy są „wystarczająco dobre”. To znaczy, że na przykład opisują dokładnie działanie frontendu aplikacji nie opisując panelu administracyjnego.

Projekt IT to nie projekt drewnianej szafki, gdzie wszystko można omówić i rozrysować przed startem prac a potem tylko wymagać jakości. To wielomiesięczne przedsięwzięcie – bardzo często z nie do końca jasnym obrazem finalnego efektu prac. W czasie tych miesięcy wymagania również się zmieniają. Każdy brak w specyfikacji to świetna okazja dla firmy wdrożeniowej na „przyoszczędzenie” poprzez realizację funkcji w sposób najprostszy z możliwych. Większość firm ma w umowach zapisy, że w przypadku braku dokładnej specyfikacji funkcje nie będą realizowane lub realizowane najprościej. Jest to wykorzystywane zwłaszcza, gdy na innych elementach firma już dopłaciła (bo były źle wycenione)… Demo na bieżąco nie ma, bo po co. Są etapy – zazwyczaj 2-5 mc. Po nich klient otrzymuje produkt i zaczyna się walka o odbiór. Często produkt odbiega od wyobrażeń a czasami w ogóle nie spełnia swoich funkcji. Ale można dowieść, że jest zgodny ze specyfikacją i wymusić odbiór :) Nie jest to fajne podejście. Kiepska jakość potęguje niezadowolenie klienta, długie dyskusje nad protokołem odbioru psują relacje. Jako klient – cieszyliśmy się, że mamy pod kontrolą budżet ale w praktyce w momencie startu prac straciliśmy kontrolę nad kształtem projektu. W podejściu zwinnym takie sytuacje nie są możliwe. Dodatkowo oczywiście klient ma na bieżąco wgląd do systemu ticketowego gdzie są aktualizowane postępy (u nas jest to JIRA lub Redmine) i wgląd w kod źródłowy (poprzez Gitlab) gdzie nawet może prowadzić code&review jeśli będzie chciał.

Terminy

Jeśli chodzi o terminy – tutaj również przejrzystość jest kluczowa. Przez sposób funkcjonowania modeli zwinnych zazwyczaj firmy wdrożeniowe przydzielają do nich na stałe, na pełen etat, cały zespół projektowy. Taki zespół nie jest odrywany do innych projektów i pracuje najszybciej jak to jest możliwe. Klient jest codziennie na daily, więc może to obserwować (chociażby po ilości realizowanych zadań). W modelu fixed price firmy wykorzystują to, że mają ustalony termin. Najczęściej jest on założony z buforem. Bufor bywa wykorzystywany na … realizację innych projektów lub gaszenie pożarów. O ile w zwinnym podejściu to klient decyduje kiedy uruchomić projekt – i  będzie to zrobione najszybciej jak to możliwe – w podejściu fixed, projekt nie będzie uruchomiony przed określonym terminem w umowie. Dokładnie wtedy, lub niestety jak pokazuje praktyka, później (przez błędne szacunki na starcie prac).

Estymacje są realne

W modelu fixed do wycen zawsze dodawane są bufory. W praktyce są to bufory na poziomie 40-100% per funkcja. Najgorsze co może zrobić klient to wymagać wycen bez przeprowadzenia analizy. Wbrew pozorom takie sytuacje zdarzają się całkiem często (zawsze odmawiamy startu do projektu przy takich założeniach – to samobójstwo). W time&materials nie ma sensu dodawać buforów do wycen – firma wdrożeniowa nie boi się, że „dopłaci do projektu” bo klient płaci za wszystkie realnie przepracowane godziny. Nieprzekonanych klientów zapraszamy czasami do wzięcia udziału w warsztacie z zespołem wdrożeniowym, gdzie są estymowane i dyskutowane funkcje. W takim układzie klient ma 100% pewność co do tego co zostało wycenione (Czy może jakieś założenia zostały pominięte? A może niektóre są na wyrost?). Projekty w time&materials są tańsze. Jedynym wyjątkiem są sytuacje, gdzie projekt jest naprawdę bardzo skomplikowany – R&D. W takich projektach nie ma z czym porównać czasów realizacji. W modelu fixed price będzie wrażenie, że byłoby taniej. Dlatego, że projekt byłby sponsorowany przez firmę wdrożeniową. Firma wdrożeniowa sponsorująca projekt to nie jest dobry partner. Prędzej czy później (zazwyczaj w etapie utrzymania projektu) dopłacimy do realizacji dokładnie tyle, ile firma dopłaciła nam przy wdrożeniu.

Czy to jest dla każdego?

Wdrożenia IT nie są dla każdego. Jeśli nasz partner nie jest gotowy zazwyczaj bardzo się broni przed rozliczaniem time&materials. Na przykład nie ma działu IT który mógłby ocenić naszą pracę i .. budować zaufanie („tak, dobrze robią, to tyle zajmuje, widziałem kod”). Nie ma kierownika projektu o wiedzy technicznej który mógłby zostać product ownerem. Nie wie co chce uzyskać i jego firma nie wspiera projektu (zazwyczaj wdrożenia wymagają zaangażowania wielu działów).

Podsumowanie

Wszystkie największe wdrożenia realizowaliśmy lub docelowo doszliśmy do realizacji w modelu Time & Materials. W taki sposób pracujemy dla TIM S.A. (sklepem który sprzedaje za > mln zł dziennie). Tak pracujemy dla CDP.pl. Tak pracowaliśmy dla Reserved.com. Tak pracujemy dla wszystkich zagranicznych klientów. Jeśli Twój projekt jest dla Ciebie ważny, kierujesz się merytoryką i jakością – to powinieneś wybrać model zwinny. On daje najlepsze efekty, najszybciej przy minimalizacji kosztów.