Blog

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ą na podstawie różnych 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, zakresu prac lub obu tych rzeczy w trakcie, inne nie.

Co oczywiste, nim kontrakt 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 dużej przewidywalności) 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ą – są mocno zmienne i niewiele da się skutecznie przewidzieć. Przykładem mogą być systemy informatyczne funkcjonujące w bankowości, ubezpieczeniach czy telekomunikacji. W praktyce w złożonej domenie znajdą się 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ądzenia 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 domenie 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 lub 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ć, dzięki czemu nie pojawi się niespodziewany problem ze znalezieniem zajęcia dla ludzi zatrudnionych na potrzeby tej inicjatywy.

Innym powodem jest fakt, że kontrakty fixed price umożliwiają zażądanie od zleceniodawcy nieco wyższej ceny jako zabezpieczenia dla wykonawcy, który na siebie bierze ryzyko wykonania nieprzewidzianych, ale niezbędnych prac. Jeśli będzie ich mniej, niż oszacował wykonawca, da mu to dodatkowy zysk, którego nie byłoby przy zastosowaniu bardziej elastycznej formy rozliczania się.

A czasami o wyborze tej formy rozliczenia decydują kwestie organizacyjne: obsługa kontraktu fixed price w trakcie 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?

Podejście fixed price generuje kilka problemów i prowokuje obie strony kontraktu do ocierania się o granicę, 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.

Sam proces sporządzenia kontraktu generuje pokusy, by ugrać jak najwię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ć do siebie klienta. Ten będzie następnie przez wiele lat skazany na dalsze zamawianie kolejnych prac (rzecz jasna już nie po tak atrakcyjnej cenie) albo czeka go trudny i kosztowny proces zmiany wykonawcy.

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, co wymusza przeprowadzenie kompletnych analiz problemu, zaprojektowania rozwiązania i zaplanowania z góry poszczególnych etapów realizacji. W domenie 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 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 (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, wykorzystując kilka pierwszych pomysłów na produkt? Ano, można to zrobić zwinnie, zawierając specyficzny kontrakt 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 da się je 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 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, taki kontrakt często gwarantuje minimalną liczbę iteracji, które się odbędą, 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), a 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?

Ryzyko takiego zdarzenia jest ograniczone, 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 (klasyczny projekt) to mało realne bez płacenia kar, tu (podejście zwinne) będzie możliwe. Jeśli obie strony dojdą do wniosku, że kontynuowanie prac nie ma sensu, płatność ograniczy się jedynie do gwarantowanej liczby iteracji.

Dla odmiany wykonawca chciałby mieć pewność, że nie zostanie zmuszony do realizowania nieplanowanych prac w przypadku, gdy wstępne plany okażą się nietrafione i zakres zacznie się rozrastać. 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 dla którejkolwiek ze stron, ale w taki sposób, by nie narazić partnera na straty.

Wykonawca często decyduje się na umowę 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 mają 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 projekt 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ę o tym, 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 w ramach każdej zakontraktowanej iteracji robić jak najmniej? 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 szczegółowo 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. A jeśli zamawiający dostanie to, czego potrzebował w takiej cenie, jaką chciał zapłacić i przed upływem ustalonego czasu, ciężko mu uznać się za poszkodowanego w jakikolwiek sposób.

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. Tutaj zwinne podejście do umowy fixed price nie wnosi żadnego dodatkowego ryzyka, z którym zlecający pracę nie musiałby się liczyć w przypadku klasycznie realizowanych projektów.

Mamy więc do czynienia z kontraktem fixed price, 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, budując produkt lub usługę tak, by nie nadawała się do rozwoju przez żaden inny Zespół. Próba takiego działania stanie się widoczna już na wczesnych etapach współpracy, 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 Scrum w ten sposób, że Product Owner desygnowany zostaje przez zleceniodawcę, a Developerzy 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 to 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. Natomiast w porównaniu do czystego modelu time & material interesy obu stron są zabezpieczone gwarancją minimalnej inwestycji i określoną z góry ceną pojedynczej 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 oczywiście, jak bardzo stanie się on zaawansowany, 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 × 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ą. Oczywiście i tak nie daje to gwarancji powodzenia, za to 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ń, użycie Scruma wygeneruje koszty związane z utrzymaniem w działaniu procesu sprawdzania stanu spraw, po którym i tak nie dojdzie do żadnego dostosowywania planów. 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 adaptacyjne budowanie rozwiązań.

Natomiast nie jest prawdą stwierdzenie, że użycie Scruma w tak podły sposób eliminuje wszystkie korzyści, jakie mógłby przynieść. Jasne, nijak nie pomoże w zbudowaniu lepszego produktu, ale może pomóc w budowaniu go lepiej. Inaczej mówiąc, choć budżet, terminy i zakres wykute zostały w betonie i zmieniane być nie mogą, pozostaje wciąż niewielka przestrzeń na dokonywanie zmian w procesie developerskim, co podnosi szansę, że w ogóle uda się coś zbudować. No, chyba że i to zostanie zalane betonem i Developerzy dostaną rozpisane w szczegółach zadania – wtedy sięganie po Scruma byłoby absurdem.