Zwinna realizacja projektów fixed-price

Często przewija się w rozmowach z uczestnikami szkoleń, Scrum Masterami i Product Ownerami, pytanie o możliwość zastosowania metod zwinnych, na przykład Scruma, do realizacji projektów fixed-price. Nie da się na nie udzielić odpowiedzi innej niż „to zależy”. Z samego faktu, że technicznie możliwe jest użycie takiej czy innej metody jeszcze nie wynika sens jej zastosowania – krytyczne znaczenie ma bowiem kontekst tych działań. Spróbujmy odpowiedzieć na pytanie od czego „to zależy” i kiedy podejście zwinne do takich projektów może być uzasadnione.

Fixed-price

Projekty realizowane są w oparciu o różne formy kontraktów między zlecającym pracę i wykonawcą. Jeśli cena, jaką zapłacić ma zleceniodawca, jest z góry określona, mamy do czynienia z projektem fixed-price. Istnieje wiele sposobów konstruowania takich umów; niektóre dopuszczają możliwość negocjacji ceny i / lub zakresu prac w trakcie, inne nie.

Co oczywiste, nim kontrakt taki zostanie sporządzony, obie strony dokonują oszacowania ilości pracy i ryzyka związanego ze wszystkimi poczynionymi założeniami, które – gdyby okazały się błędne – mogą wygenerować dodatkowe koszty. W większości projektów, dominującym czynnikiem wpływającym na cenę jest koszt zatrudnienia ludzi, więc przed sporządzeniem kontraktu często określa się ile osób, o jakich kompetencjach i na jak długo trzeba będzie zatrudnić. Pojawia się konieczność precyzyjnego określenia jakie prace i w jakiej kolejności mają zostać wykonane. Cechą charakterystyczną większości projektów fixed-price jest więc to, że poza ceną, określają one z góry również zakres prac, nierzadko bardzo szczegółowo.

W domenach stabilnych (o niewielkiej zmienności) i przewidywalnych da się przeprowadzić skutecznie analizę wszystkich istotnych czynników i zaplanować niezbędne prace wiodące do osiągnięcia zakładanego celu. Tak jest na przykład w inżynierii lądowej: wybudowanie wieżowca nie jest zadaniem łatwym, ale dysponując ekspertami w zakresie projektowania i budownictwa oraz doświadczonymi ekipami budowlanymi można z bardzo dużym prawdopodobieństwem oszacować zarówno czas jak i koszt całego przedsięwzięcia. Model fixed-price sprawdzi się w takim przypadku zupełnie nieźle.

Są jednak domeny, w których mierzyć trzeba się z niestabilną złożonością i nieprzewidywalnością. Przykładem mogą być systemy informatyczne funkcjonujące w bankowości, ubezpieczeniach czy telekomunikacji. W złożonej domenie znajdą się też prawie wszystkie rozwiązania, do których zbudowania konieczne jest wytworzenie oprogramowania. Ba, nieprzewidywalność i złożoność czają się za rogiem nawet na tych, którzy budują „proste” aplikacje na urządzenie mobilne, bo nieustannie rośnie różnorodność urządzeń, na których te aplikacje będą instalowane, a jeszcze konieczne jest komunikowanie się poprzez internet z serwerami i innymi urządzeniami…

Nasuwa się oczywiste pytanie: dlaczego ktoś miałby decydować się na podejście fixed-price w przypadku domeny złożonej?

Jednym z powodów może być chęć ograniczenia ryzyka: zleceniodawca chce zabezpieczyć się przed nagłym wzrostem ceny, jeśli coś okaże się dużo trudniejsze / bardziej czasochłonne niż wykazały wstępne analizy; wykonawca chce związać klienta kontraktem, z którego nie da się ot tak po prostu wycofać.

Innym powodem jest fakt, że kontrakty fixed-price umożliwiają zażądanie od zleceniodawcy nieco wyższej ceny jako rekompensaty / zabezpieczenia dla wykonawcy, który na siebie bierze ryzyko wykonania nieprzewidzianych, ale niezbędnych prac. A czasami o wyborze tej formy rozliczenia decydują kwestie organizacyjne: obsługa kontraktu fixed-price w czasie realizacji bywa prostsza niż innych rodzajów umów, w których konieczne jest dokumentowanie bieżących kosztów i rozliczanie się z nich na bieżąco.

Samo zło?

Fixed-price generuje kilka problemów i prowokuje obie strony do ocierania się o granice, za którą ciężko mówić o profesjonalizmie lub etyce w biznesie. Zdarza się, że wykonawca zaczyna obniżać jakość usług lub produktów jakie wytwarza, ponieważ w trakcie realizacji pojawiać zaczynają się nieprzewidziane koszty, a cena nie podlega negocjacji. Samo sporządzenie kontraktu obfituje w pokusy, by „ugrać” więcej kosztem drugiej strony; sporządzone umowy roją się od pułapek, które można wykorzystać w sytuacji, gdyby sprawy przybrały niekorzystny obrót. Niestety bywa i tak, że wykonawca celowo akceptuje niemożliwy do zrealizowania projekt tylko po to, by uwiązać klienta. Ten będzie następnie przez wiele lat skazany na dalsze zamawianie kolejnych prac (rzecz jasna już nie po tak atrakcyjnej cenie).

Pomijając wszystkie aspekty etyczne i kwestie profesjonalizmu warto podkreślić inną cechę projektów fixed-price, która czyni je co najmniej kłopotliwymi, jeśli nie szkodliwymi. Konieczność umówienia się na stałą cenę jest motywatorem do sztywnego określenia zakresu prac. A to wymusza przeprowadzenie kompletnych analiz problemu, zaprojektowania rozwiązania i zaplanowania z góry poszczególnych etapów realizacji. W domenie nieprzewidywalnej, pełnej niestabilnej złożoności, nie da się tego skutecznie zrobić, bo wszelkie ustalenia mogą przestać być aktualne tuż po tym, jak zostaną poczynione. To zwiększa ryzyko, że projekt tak realizowany zakończy się sromotną porażką.

Na pierwszy rzut oka, nie da się pogodzić podejścia fixed-price z budowaniem usług lub produktów zwinnie w krótkich cyklach i przyrostowo. Zapisany w kontrakcie i „podpisany krwią” zakres prac nijak ma się do idei żywego, ciągle zmiennego artefaktu jakim jest np. backlog produktu w Scrumie. A jeśli z góry wszystko wiadomo, to gdzie tu przestrzeń na empiryzm?

Da się

Rozważmy scenariusz, w którym zleceniodawca potrzebuje produktu lub usługi, za który może zapłacić określoną kwotę. Jej przekroczenie czyni całe przedsięwzięcie nieopłacalnym, dlatego skłania się ku kontraktom typu fixed-price. Zleceniodawca ten ma na razie jedynie mało precyzyjną wizję tego, co będzie wytwarzane, oraz zgrubne oszacowania możliwych kosztów, z których na razie (to ważne stwierdzenie) wynika, że inwestycja może być opłacalna.

Wytworzenie szczegółowych projektów i przeprowadzenie drobiazgowych analiz wydaje się co prawda wykonalne, ale będzie czasochłonne i kosztowne. Istnieje ryzyko, że pójście tą drogą skonsumuje istotną część budżetu (ograniczając lub nawet eliminując potencjalne zyski), a niewykluczone, że rynek ulegnie zmianie i całe przedsięwzięcie przestanie mieć sens jeszcze zanim analizy się zakończą.

Jak pogodzić pozornie sprzeczne potrzeby twardego limitowania kosztów z chęcią zaczęcia prac już, teraz, w oparciu o kilka pierwszych pomysłów na produkt? Ano, można to zrobić zwinnie, zawierając specyficzny kontrakt typu fixed-price.

Klient potrzebuje produktu, który budować będzie zespół o określonych kompetencjach. Na razie (znów: to ważne stwierdzenie) nie da się przewidzieć wszystkich umiejętności jakich będzie potrzeba, by prace ukończyć, ale wiadomo, z jakimi prace da się zacząć. To pozwala sformować zespół, który rozpocznie wywarzanie pierwszych wersji rozwiązania, skupiając się na początek na tym, co jest najlepiej zdefiniowane i najbardziej potrzebne. Koszt pojedynczej iteracji (sprintu, jeśli użyty zostanie Scrum) takiego zespołu będzie co do zasady stały i przewidywalny. Oczywiście pojawią się inne wydatki, związane z narzędziami i niezbędną infrastrukturą – ale i te da się skutecznie oszacować, przynajmniej dla pierwszego etapu prac.

Co więc może zrobić klient? Umówić się z wykonawcą na realizację określonej liczby iteracji, z których każda będzie kosztować ustaloną cenę. Co w ramach tych iteracji zostanie wytworzone? Z racji tego, że nie ma sztywno określonego zakresu prac i detalicznych projektów czy planów, o zakresie prac każdej iteracji klient i wykonawca będą decydować wspólnie na bieżąco.

W miarę, jak prace będą posuwać się do przodu, coraz lepiej będzie można prognozować, które wymagania biznesowe są wykonalne i ile realizacja poszczególnych etapów projektu / wymagań potrwa (a zatem ile będzie to kosztować). Jednocześnie rafinacji ulegnie sama lista wymagań – coraz łatwiej będzie określić, co jest potrzebne, a co zbędne. Zamiast przeprowadzać kosztowną analizę z góry, obie strony skorzystać mogą z empirycznego podejścia by szybko zidentyfikować co warto zrobić, a co jest nieopłacalne lub niewykonalne.

Aby zadbać o interesy obu stron, kontrakt często gwarantuje minimalną liczbę iteracji, które zostaną zrealizowane, oraz cel biznesowy, nad którego realizacją obie strony będą pracować. W ten sposób wykonawca ma pewność, że na projekcie zarobi (a przynajmniej nie straci), zaś klient może elastycznie definiować zakres prac bez konieczności wielokrotnych renegocjacji kontraktu.

Koszty będą stałe do momentu, gdy okaże się, że konieczna jest rozbudowa zespołu lub istotne poszerzenie jego kompetencji albo listy narzędzi, jakich używa. Dopiero wtedy sytuacja może wymagać renegocjacji kontraktu. Jeśli klient nie zwiększy budżetu a koszt pojedynczej iteracji wzrasta, tych iteracji odbędzie się mniej niż zakładano na początku. Jest to jednak lepsze w porównaniu z modelem, w którym z góry umawiamy się na wszystko (cenę, terminy i zakres). Dlaczego? Bo ryzyko takiego zdarzenia jest jedynie potencjalne, a obie strony zaoszczędziły na przeprowadzaniu kosztownych analiz przed zawarciem umowy. W ostatecznym rozrachunku klient redukuje ryzyko, że przepłaci, a wykonawca, że straci na kontrakcie. Bonusem będzie możliwość wykonania większej ilości prac w ramach budżetu, który normalnie obie strony zużyłyby na przygotowania do zawarcia umowy.

Teoria czy praktyka?

Usłyszałem kiedyś, że takie podejście świadczyłoby o skrajnej naiwności jednej, drugiej lub obu stron. Że to rozwiązanie zwiększające ryzyko tak dla wykonawcy, jak i zlecającego. Że to żaden fixed-price, tylko zwykłe rozliczanie się w modelu time&material…

Zleceniodawca decydujący się na zlecenie projektu fixed-price chce przede wszystkim tego, by cena za osiągnięcie zdefiniowanych na początku celów biznesowych była z góry określona. I tak się stanie, chyba że budowane rozwiązanie okaże się niewykonalne (lub dużo droższe, niż przewidywano). W tym przypadku zleceniodawca chciałby mieć możliwość wycofania się z inwestycji bez konieczności płacenia za całość. W typowym modelu fixed-price to mało realne bez płacenia kar, tu będzie możliwe. Jeśli obie strony dojdą do wniosku, że kontynuowanie prac nie ma sensu, płatność ograniczy się jedynie do „gwarantowanej” ilości iteracji.

Dla odmiany wykonawca chciałby mieć pewność, że nie zostanie zmuszony do realizowania nieplanowanych prac w przypadku, gdy wstępne szacunki okażą się zaniżone. W podejściu tradycyjnym do fixed-price zapewniał sobie poduszkę bezpieczeństwa podnosząc stosownie do ryzyka cenę. Tu nie musi tego robić, bo obie strony dopuszczają możliwość przerwania działań, jeśli staną się one nieopłacalne.

Wykonawca często decyduje się na fixed-price w obawie o wycofanie się klienta z inwestycji w trakcie jej trwania. Zbudowanie zespołu i zapewnienie mu środowiska pracy to koszt, nie mówiąc już o problemie jaki stanowić będą ludzie, dla których z dnia na dzień nie będzie pracy. Ustalenie minimalnej liczby iteracji, która odbędzie się na pewno (albo mówiąc precyzyjniej: za które klient na pewno zapłaci), ogranicza lub eliminuje ryzyko, na jakie naraża się wykonawca.

Zarówno wykonawca jak i zlecający prace ma zazwyczaj obawę, że druga strona lepiej oszacowała zakres prac i wykorzysta to na swoją korzyść. Dodatkowo, zlecający może obawiać się, że pracujący na jego rzecz zespół będzie minimalizował koszty po stronie wykonawcy, przez co jakość wytworzonych rozwiązań będzie niska. Klasyczny fixed-price często prowokuje do takich mało profesjonalnych (i nieetycznych) działań i nie sprzyja przejrzystości. Jeśli mimo tego, że cena jest z góry ustalona, posłużymy się metodą zwinną, w interesie obu stron staje się zapewnienie pełnej przejrzystości postępu prac i wszystkich trudności, jakie się ujawniły. A mając wiedzę jaki jest prawdziwy stan spraw, można podjąć rozsądne decyzje uwzględniające potrzeby i klienta, i wykonawcy.

Nasuwa się pytanie: jaki interes wykonawca będzie miał w tym, by nie przeciągać prac tak, by zarobić jak najwięcej? Cóż, takie działanie jest możliwe – bo nie ma metod, które skutecznie radzą sobie z nieetycznymi działaniami. Swoistą gwarancją tego, że zespół nie będzie świadomie spowalniał swych działań jest nieustanne zaangażowanie klienta w decydowanie o zakresie prac realizowanych w poszczególnych iteracjach. Inną gwarancją jest określenie celów, jakie mają w ramach ustalonej ceny zostać osiągnięte; o ile nie jest detalicznie zdefiniowane jakie rozwiązania mają być zbudowane, o tyle wciąż niezbędne jest osiągnięcie wspomnianych celów i często to jest warunkiem dokonania płatności.

To rodzi kolejne pytanie: co jeśli zleceniodawca stwierdzi, iż cele nie zostały osiągnięte (wszak to on je definiuje) i płatności odmówi? Znów: podobnie jak w tradycyjnych kontraktach każdy z takich celów może zostać opisany przez stosowne kryteria, które pozwalają zdeterminować, czy został osiągnięty, czy też nie. Mamy więc do czynienia z kontraktem typu „fixed”, ale to zafiksowanie nie jest sprowadzone na absurdalnie niski poziom opisu konkretnych rozwiązań. Jeśli „kryteria akceptacji dla celów biznesowych” zostaną zawarte w kontrakcie, a nie zostaną osiągnięte w ustalonym czasie, wykonawca może zostać obłożony stosownymi karami.

Pamiętać trzeba, że wykorzystanie Agile spowoduje, że wszelkie decyzje czy to wykonawcy, czy zleceniodawcy, są jawne i widoczne dla drugiej strony. Nawet przy niskim poziomie zaufania, profesjonalizmu i etyki obu stron nie tak łatwo wtedy „rozegrać” problemy na swoją korzyść w sposób niezauważalny.

Ma to dalsze konsekwencje: maleje ryzyko, że wykonawca zbuduje rozwiązanie w sposób, który „przywiąże” klienta na stałe, bo produkt / usługa nie będzie nadawała się do rozwoju przez żaden inny zespół. Próba takiego działania stanie się widoczna już na wczesnych etapach budowania produktu / usług, o ile zleceniodawca rzeczywiście aktywnie uczestniczył będzie w przedsięwzięciu od samego początku.

Fixed-price w Scrumie

Typowym rozwiązaniem jest sformowanie zespołu scrumowego w ten sposób, że Product Owner desygnowany zostaje przez zleceniodawcę, a zespół developerski oraz Scrum Master są pracownikami wykonawcy. Kontrakt zawierany jest z określeniem ceny pojedynczego sprintu i ustaleniem minimalnej ich ilości, oraz jednego lub kilku celów biznesowych wraz z terminami, do których muszą one zostać osiągnięte.

W ten sposób klient decyduje o kolejności prac, ale musi robić to z uwzględnieniem realnych możliwości ich przeprowadzenia. Działanie na szkodę drugiej strony (przez przeciąganie prac lub realizowanie wymagań nijak niezwiązanych z ustalonymi w umowie celami) po ujawnieniu jest podstawą do zerwania umowy i naliczenia określonych na taką okoliczność kar.

Podstawową różnicą w stosunku do klasycznego projektu fixed-price jest zachowanie dużej elastyczności w kwestii zmiany zakresu prac. Zaś w porównaniu do czystego modelu time&material interesy obu stron są zabezpieczone gwarancją minimalnej inwestycji i określoną z góry ceną iteracji.

Największą zaletą tego rozwiązania jest to, że niezależnie od tego jak dobrze czy źle przebiegało będzie przedsięwzięcie, na pewno powstanie jakiś produkt. Niewiadomą pozostaje, co zdąży powstać, nim wyczerpany zostanie budżet określony dla projektu. Możliwość reagowania na ujawniające się problemy i „łapania” pojawiających się okazji w istotny sposób zwiększa szansę powodzenia inwestycji.

3 x fixed

A co z projektami, w których z góry określone są tak cena, jak i zakres prac oraz terminy? Cóż, jeśli takie podejście zastosowane zostanie do wytworzenia czegokolwiek w domenie niestabilnej złożoności, gdzie ciężko o skuteczne przewidywanie przyszłości, szanse na powodzenie są niewielkie. Można je zwiększyć jedynie przez uwzględnienie wszędzie, gdzie to możliwe, dodatkowych środków na radzenie sobie z nieprzewidywalnością. Choć nie daje to gwarancji powodzenia, dramatycznie podnosi koszt realizacji projektu.

Czy da się w takim modelu użyć Scruma? Odpowiedź oczywista: nie, ponieważ metoda ta zakłada możliwość dostosowania planów działania za każdym razem, gdy jest to niezbędne. Jeśli istnieje z góry ułożony i niezmienny harmonogram działań, zastosowanie Scruma będzie generować koszty związane z utrzymaniem w działaniu procesu, który niczemu nie będzie służył. Równie nieracjonalne w takim przypadku byłoby użycie jakichkolwiek innych metod zwinnych, ponieważ i one zakładają ciągłą ewolucję planów i inkrementalne / adaptacyjne budowanie rozwiązań.