Battle for Agility

Kontrakty o ustalonej cenie i zakresie - mitologia stosowana.

October 2nd, 2006 Marcin Niebudek

Niedawno przeczytałem wywiad z Paulem Klippem, jakiego udzielił on na łamach portalu IT w Krakowie. Zapytany o to, czy jego firma realizuje projekty dla klientów z Polski wykorzystując metody agile, odpowiedział między innymi:

“Dopóki polscy klienci nie zdadzą sobie sprawy z tego, że oferty o ustalonej cenie i ustalonym zakresie funkcjonalności im szkodzą i dopóki nie zaczną zwracać większej uwagi na jakość oprogramowania, nie będę miał zbyt wielu okazji realizować tutaj projektów z wykorzystaniem agile.”

Z jednej strony zgadzam się z tym całym sercem, ale z drugiej strony jak polscy klienci mają sobie zdać sprawę z tego co tak faktycznie dostają prosząc o kontrakt z ustalonym zakresem i ceną? Ostatnio wydawało się, że jeden z klientów firmy w której pracuję da się namówić na poprowadzenie projektu wg założeń agile, jednak po kilku dniach poprosił o kontrakt z ustaloną ceną i zakresem. Poniosłem osobistą klęskę, ale skłoniło mnie to do zastanowienia się nad tym z czym kojarzy się naszym klientom wykonanie projektu technikami agile (o ile w ogóle z czymś im się kojarzy), a jaka jest percepcja zamkniętych kontraktów? Z czego wynika ich obawa przed agile? A z czego wynika to poczucie bezpieczeństwa jakie odnajdują oni w zamkniętych kontraktach.

Miałem okazję uczestniczyć w wielu rozmowach z klientami, które prowadziły do stworzenia słynnego dokumentu “Specyfikacja Wymagań Systemowych”, a który następnie stawał się załącznikiem do umowy. Jakich korzyści dopatruje się klient w zamkniętym kontrakcie?

Według klientów najlepsze cechy kontaktów zamkniętych to zwykle:

1. Ustalony zakres kontraktu. Przedstawiam wykonawcy moje oczekiwania. On przygotowuje dla mnie zestawienie, może także dokładną specyfikację tego co zostanie wykonane. Wszystko to ma formę załącznika do kontraktu. Obaj wiemy co zostanie wykonane.
2. Ustalona cena kontraktu. Wykonawca na podstawie zakresu podał mi ile godzin zajmie wykonanie projektu. Na tej podstawie wyliczył cenę za wykonanie (W uproszczeniu liczba godzin x stawka za godzinę). Na samym początku wiem czy stać mnie na program czy nie. Mogę także porównać wiele ofert i wybrać tą najkorzystniejszą cenowo.
3. Ustalony termin wykonania. Przedstawiłem wykonawcy co chcę otrzymać (mam załącznik do umowy) i ten zakres projektu został wyceniony zarówno w godzinach jak i w kwotach. Wiemy więc także kiedy projekt zostanie zakończony.
4. Karne odsetki. O tak, jeśli wykonawca się spóźni, to za każdy dzień zwłoki zapłaci mi karne odsetki.

Brzmi pięknie prawda? A jak jest naprawdę? I dlaczego jednak w większej części przypadków wykonanie takich kontraktów kończy się frustracją klientów, managerów i programistów.

Ustalony zakres kontraktu
W grze pod tytułem “budowanie specyfikacji” biorą udział dwie strony (mam nadzieję, że nie jest to w naszych realiach nadmierny optymizm) - klient i wykonawca. Aby można było z czystym sumieniem powiedzieć, że możliwe jest ustalenie stałego zakresu projektu musiałyby być spełnione pewne warunki.

Po pierwsze klient musi dokładnie wiedzieć co chce otrzymać. Jak taki system ma wyglądać, żeby dokładnie spełniał jego wymagania? Jakie powinien mieć funkcje? Ale przecież klient przychodzi do nas i prosi o zbudowanie systemu, którego nie posiada, którego nie widział nigdy na oczy, albo widział coś podobnego, co spowodowało, że przyszły mu do głowy nowe pomysły. Jednym słowem przychodzi do nas z wizją czegoś co ma mu ułatwić życie. Czy wizję można zamknąć w sztywne ramy specyfikacji? Zamknąć zakres?

Po drugie wykonawca musiałby wręcz czytać w myślach klienta, aby specyfikacja jaką stworzy w 100% odpowiadała temu co klient miał na myśli.

Oczywiście trzeba tu rozsądnie rozdzielić budowanie produktów w pewnym sensie innowacyjnych, dostosowanych do potrzeb klienta, od wdrożeń np. prostych stron internetowych czy gotowych rozwiązań. W tym drugim przypadku można oczywiście rozłożyć projekt na części pierwsze i powiedzieć, że będą konieczne określone elementy, zadania i zasoby. Jeśli taką pracę nasz zespół wykonywał już wielokrotnie i doskonale ją zna to ma to się nawet szansę udać. Postępujemy wtedy według schematu, więc i kontrakt może być schematyczny.

Ale czy klient przychodzący do nas z zapytaniem ofertowym o budowę np. systemu zarządzania pewnym procesem biznesowym w jego przedsiębiorstwie, w którym to procesie bierze udział kilkadziesiąt osób, jest nam w stanie powiedzieć jakiego dokładnie (z najdrobniejszymi szczegółami) oczekuje działania. Pewnie wielu z nas stwierdziłoby w tym momencie, że przecież od tego są analitycy i projektanci. Klient nie musi wiedzieć wszystkiego. Pomożemy mu dojść do tej wiedzy. Przeprowadzimy wywiady, będziemy projektować, modelować, rysować i pisać długie dokumenty. W optymistycznym wariancie na końcu tego długiego procesu otrzymamy faktycznie coś co będzie można nazwać szczegółowym zakresem oraz projektem systemu (osobiście jeszcze takiego dokumentu nie widziałem). Załóżmy nawet, że uda się określić co do godziny ile czasu zajmie każdy z elementów.

I co z tego ma klient? Spędził z nami tydzień, miesiąc. Ten czas zostanie mu oczywiście doliczony do ceny kontraktu, a cena analityka i projektanta akurat nie jest tutaj najniższa. I co dostanie w zamian… załącznik do umowy. Czy ten załącznik rozwiązał chociaż jeden z jego problemów biznesowych?

A co na to metody agile? Zaczynamy od krótkiego spotkania, może dwóch, na których identyfikujemy pewne wstępne priorytety, cele, pierwsze wymagania (nie ważne, czy będziemy tutaj posługiwali się user stories, przypadkami użycia, czy inną techniką). Najistotniejsze w tym wszystkim jest to, że wszystkie metody agile stawiają na rzeczy najważniejsze w pierwszej kolejności. Gwarantujemy, że zajmiemy się od razu tym co klient uznał za najistotniejsze z punktu widzenia jego biznesu.

Przy dużych systemach nie da się zwykle uniknąć tzw. “iteracji zerowej”, w trakcie której powstają pewne podwaliny dla architektury systemu. Ale słowo “powstają” jest tutaj kluczowe. Od pierwszych dni powstaje produkt, który będzie stanowił wartość dla klienta. Nie jakiś dokument opisujący jak będzie pięknie, tylko system, który można użyć, zobaczyć, mieć na jego temat jakieś zdanie. Drodzy klienci, czy nie lepiej zapłacić za coś co stanowi jakąś wartość zamiast za (bez)wartościowy dokument?

Co jeśli jednak klient po kilku tygodniach/miesiącach zmieni zdanie? Może zmieni się sytuacja biznesowa - konkurencja przecież nie śpi w tym czasie? A może po prostu ma już lepszy pomysł, bo w miarę upływu czasu przemyślał pewne rzeczy jeszcze raz. Co wtedy z naszym załącznikiem do umowy. Odpowiedź jest jedna - wchodzimy na mglistą ścieżkę procesu zmiany wymagań. A jest to ścieżka kręta i pełna niespodzianek. Umówiliśmy się przecież na początku co do zakresu projektu, a z niego wynikały koszty i terminy. Teraz trzeba to przeliczyć i dołączyć do umowy nowy załącznik. I co? Znowu dokument i koszty zamiast nowego kawałka systemu.

Wszyscy też doskonale wiemy co dzieje się z kosztem zmian wraz z upływem czasu. Całe szczęście jeśli klient będzie miał okazję zapoznać się z jakimś pośrednim stadium projektu zanim będzie za późno. Zwykle jednak przy kontraktach z zamkniętym zakresem produkt poddawany jest ocenie (tzw. testom akceptacyjnym) tuż przed jego finalnym oddaniem (programiści mogliby przytoczyć mnóstwo opowieści z okresu między rozpoczęciem tych testów a oddaniem projektu).

Znowu - co na to agile? Ha! Przecież “zmiany” to drugie imię technik agile. Stosując dowolne podejście agile zakładamy, że żadne z wymagań poza tymi, które weszły do bieżącej iteracji, nie jest trwałe i praktycznie w każdej chwili można je zmienić, przełożyć jego wykonanie, czy nawet zrezygnować z niego. Siła agile nie leży w tym, że metody te dają przyzwolenie dla częstych zmian. Powiedziałbym raczej, że metody te stwarzają dogodne warunki do dokonywania zmian i dają klientowi wolność wyboru, której nie ma kiedy podpisze kontrakt zamknięty i klamka zapadnie. Wynika to z nastawienia procesów agile na częste spotkania i prezentacje kolejnych zrealizowanych w pełni funkcjonalności oraz na krótkie etapy, w których tworzone są kolejne wersje systemu. Oczywiście proces ten ściśle angażuje klienta, ale w końcu chodzi mu o uzyskanie dobrego produktu - za to płaci.

Czy w takim razie zamknięcie zakresu projektu w kontrakcie chroni klienta? Sądzę, że to pierwszy z mitów jakie są związane z tego typu kontraktami. Oczywiście wykonawca będzie bronił jak lew takiego zakresu. Za to klient bardzo szybko dowie się, że drzwi, które cichutko zamknął zostały z hukiem zaryglowane z drugiej strony i otworzą się dopiero pod koniec projektu. Podejście agile wymagałoby wykluczenia z kontraktu zakresu i jedynie ustalenia budżetu oraz zasad wykonania kontraktu. Jednak pod tym pozornym brakiem zapisów umownych klient dostanie większą kontrolę nad tym za co faktycznie płaci.

Ustalona cena kontraktu.
Co tak faktycznie oznacza ona dla klienta? Nie oszukujmy się… cena w sztywnym kontrakcie, to cena jaką klient płaci za wykonanie zapisów załącznika do umowy stworzonego przez wykonawcę i zgodnie z tym jak go zrozumiał… właśnie wykonawca. Gdy nastąpi wreszcie ten sądny dzień oddania projektu obie strony, usadowione dotąd wygodnie w swoich okopach, wyjdą z nich i zaczną do siebie strzelać amunicją złożoną z zarzutów, argumentów i interpretacji tego nieszczęsnego dokumentu.

Dodatkowo do ceny kontraktu zostanie wpleciony koszt pracy jaka miała go zabezpieczyć, a która dała mu specyfikację wymagań systemowych w formie aneksu. Zamiast zapłacić za produkt sam sponsoruje sobie kaftan bezpieczeństwa w postaci aneksu do umowy.

Wspomniałem wcześniej o koszcie zmian przy kontraktach zamkniętych. Koszty te wynikają z faktu, że wykonawca wyczerpuje zwykle cały budżet zapewniony mu w kontrakcie dla wykonania pierwszej wersji, czyli zapisów załącznika z zakresem. Więc jeśli klientowi nie spodoba się osiągnięty efekt, to możliwości są trzy - albo dopłaci za zmiany, albo wyrzuci to co dostał do kosza, albo weźmie produkt taki jaki jest. W każdej sytuacji traci:

• dopłaca - przekracza automatycznie cenę kontraktu (a miał przecież wiedzieć ile zapłaci za swój system)
• wyrzuca do kosza produkt - czyli robi prezent wykonawcy, któremu i tak zapłaci, bo ciężko się będzie wycofać z zapisów umownych
• bierze to co jest - na chwilę usypia swoje sumienie (cena jest, jaka miała być) ale prędzej czy później i tak zgłosi się po zmiany (może w ramach kolejnego kontraktu z załącznikiem - tak czy siak cena zostanie przekroczona)

Ile kosztują zmiany kiedy stosujemy metody agile? Najczęściej zmiana wynika z tego, że klient podczas kolejnego spotkania i obejrzeniu swojego systemu wybiera inny kierunek prac niż ten pierwotnie planowany. Taka zmiana nie kosztuje nic a daje jedną podstawową przewagę nad procesem funkcjonującym za kontraktem o ustalonej cenie i zakresie. Taka zmiana jest po prostu możliwa, bo klient nie czekał do zakończenia kontraktu, kiedy okazało się, że można było zmienić kilka rzeczy w połowie drogi. Pomiędzy iteracjami klient ma wręcz możliwość zmiany zakresu. Chcę tu jasno podkreślić, że nie jest to żadne magiczne napełnianie worka bez dna. Możemy zmienić zakres, ale nie poszerzać go. Natomiast klient być może będzie musiał poświęcić jakieś mniej istotne szczegóły na rzecz tych kluczowych. To on decyduje, które są które i co zostanie wykonane najpierw a co potem.
Oczywiście często zdarzy się, że klientowi nie spodoba się efekt iteracji, i trzeba będzie wprowadzić poprawki z tym co do tej pory zostało zrobione. W zależności od wagi zmian, albo wykonujemy je od ręki albo tworzymy z nich nowe zadanie do zaplanowania w kolejnej iteracji (zepchnie ono automatycznie jakieś inne mało istotne z końca listy). Pamiętajmy jednak, że iteracje są możliwie krótkie więc nie ma zbyt dużych możliwości stworzenia implementacji znacząco odbiegającej od oczekiwań, czego nie można powiedzieć o efekcie kilkumiesięcznej pracy, jaki ogląda klient podczas odbierania projektu z kontraktu zamkniętego. Więc zmiany w wykonanych funkcjach będą zwykle niewielkie.
Jak w takim razie określić cenę kontraktu jeśli chcemy użyć technik agile. To chyba moment, który budzi największe obawy klienta - nie określać ceny! Możemy przyjąć stawkę dzienną, godzinową lub inną, wg. której będziemy się rozliczać. Możemy także ustalić budżet, tylko nie w odniesieniu do konkretnych zadań i zakresu projektu, ale w odniesieniu do np.ilości idealnych dni programistycznych wg jakich estymujemy funkcjonalności (to dość szeroki temat wart osobnego artykułu).

Chyba największym nieporozumieniem jakie wiąże się z kontraktami i technikami agile, jest przeświadczenie, że nie można określić i kontrolować kosztu takiego projektu. Wydaje mi się, że można to zrobić dużo dokładniej niż przy projektach z ustaloną ceną. Oczywiście nie powiemy klientowi pierwszego dnia, że program będzie kosztował dokładnie X złotych. Ale możemy przecież już na początku określić wstępnie jak duży jest projekt i ile może kosztować (określić jakieś rozsądne granice), co da klientowi pojęcie czy to jest to, czego się spodziewał i czy go na to stać. Poza tym techniki agile w żadnym wypadku nie stoją na przeszkodzie skrupulatnej kontroli budżetu. Za to dokładnie wiemy za co zapłaciliśmy i wiemy także, że wydaliśmy pieniądze najlepiej jak mogliśmy, bo z każdą iteracją dostajemy produkt co do którego mamy pewność, że ma to czego chcieliśmy i nić ponad to, za co wcale nie chcieliśmy płacić.

Każdy kto chce wydać pewną kwotę na oprogramowanie, powinien zadać sobie pytanie co dostanie w dniu wyznaczonym jako data zakończenia projektu przy kontrakcie z ustaloną ceną i zakresem, a co przy kontrakcie bez ceny, ale opartym na metodach agile? Moim zdaniem nie wiadomo co dostanie przy zamkniętym kontrakcie i mało prawdopodobne aby klient był z tego w pełni zadowolony. A co klient dostanie od firmy używającej agile? Dostanie produkt lepszy niż ten o którym myślał kiedy rozpoczynaliśmy projekt. Z każdym tygodniem powinien też być o to spokojniejszy. Możliwe, że zdarzy się tak, iż do tego samego terminu nie zostanie wykonana pewna funkcjonalność, ale przecież te, które zostały to samo sedno produktu. Być może to o czym myślał na początku w ogóle nie było potrzebne.

Dochodzimy tym samym do ostatniego elementu. Do terminu.

Ustalony termin wykonania.
Techniki agile kompletnie nie przeszkadzają w ustaleniu konkretnego terminu zakończenia projektu. Wręcz przeciwnie - wszystko co w agile robimy, wykonujemy przy dużej samodyscyplinie i w konkretnych terminach. Nie przeciągamy iteracji, nie ma w połowie wykonanych elementów. Wszystko jest z góry ustalone. Paradoks? Wcale nie. Agile uwielbia ten stały rytm pracy, to dzięki niemu możemy coraz dokładniej udzielać odpowiedzi na pytanie co i kiedy.

Przy zamkniętym kontrakcie ustalamy na początku zakres oraz termin wykonania i potem zespół przystępuje do pracy. Przypomina to bardzo ciężką lokomotywę, która rozpędza się powoli zanim osiągnie swoją optymalną prędkość. Wiadomo - termin zakończenia projektu jest tak odległy, że na pewno zdążymy - spieszymy się więc powoli. Zespół dobiera sobie zadania w wygodnej dla niego kolejności, co zwykle nie idzie w parze z priorytetami klienta. Ale przecież klient oceniać będzie efekt końcowy, więc kolejność po drodze nie ma znaczenia. I co się dzieje pod koniec projektu, kiedy okazuje się, że zostało więcej zadań niż czasu? Przecież wykonawca nie będzie płacił karnych odsetek. Jest łatwiejsze rozwiązanie. Kończymy wszystko byle jak, ale w terminie. Ważne, żeby podczas odbioru wszystko dobrze się zaprezentowało, a potem się zobaczy. Poświęcamy jakość. W końcu klient będzie płacił za support.
W projekcie agile nie ma zbyt dużo miejsca na taki scenariusz, bo klient na bieżąco określa kierunek i dba o to, aby powiedzieć zespołowi o swoich bieżących priorytetach. Efekt jest taki, że kiedy zbliża się termin określony w kontrakcie, wtedy mamy pewność, że mamy produkt, który zaspokaja możliwie najwięcej potrzeb klienta (nawet jeśli pewne drobne, mało istotne elementy nie zostały wykonane).

Jest tutaj miejsce na jeszcze jedną rzecz, na którą chciałbym zwrócić uwagę. Często okazuje się, że pewne zadania zajęły mniej czasu niż miały (tak… mimo panującej opinii, ze projekty informatyczne nie kończą się zwykle w ustalonym terminie). Chodzi o to, że tak wypracowany zysk zabierany jest później przez pracochłonne i niepotrzebne funkcje, które zespół wykona żeby spełnić wymagania załącznika do umowy. Albo po prostu klient nie dowie się o tym, że coś trwało krócej. Ilu z nas widziało kiedyś, aby firma IT na koniec projektu powiedziała klientowi, że umawialiśmy się co prawda na pewną kwotę ale poszło nam szybciej więc cena będzie niższa? Projekt agile w moim przekonaniu powinien być oparty na wzajemnym zaufaniu i zrozumieniu. Klient musi być przygotowany na to, że nie jesteśmy jasnowidzami i pewne rzeczy zajmą więcej czasu niż mogliśmy początkowo przypuszczać, ale dołożymy wszelkich starań żeby dostał to czego potrzebuje. Będzie miał za to zawsze szansę zdecydować, czy zmiana pracochłonności nie stanowi dla niego podstaw do obniżenia priorytetu zadania i przesunięcia go na później. Ale z drugie strony klient musi mieć pewność, że jeśli uda się nam skończyć coś wcześniej to wtedy zespół skontaktuje się z nim w celu wciągnięcia do iteracji jeszcze jakiegoś elementu z planu kolejnych etapów. Zamknięte kontrakty zawsze zakładają jedynie wzrost ceny jeśli coś pójdzie gorzej.

Na koniec chciałbym wyjaśnić, że dokonałem tutaj pewnego uproszczenia zakładając, że za kontraktem o stałej cenie i zakresie jest ukryty proces podobny do kaskadowego. Wiele osób pomyślało już na pewno, że można zastosować etapy pośrednie wykonując zamknięty kontrakt aby zminimalizować ryzyko nie trafienia w oczekiwania klienta. Jednak szybko dojdziemy do wniosku, że taka minimalizacja ryzyka przerodzi się prędzej czy później w coraz większe adaptowanie technik agile w tego typu projekcie (o tym może niedługo). Być może nawet finałem tej adaptacji będzie podpisanie kontraktu bez załącznika z zakresem projektu i ceną, a zespół (łącznie z Zarządem) stwierdzi, że jest jest już bardziej agile niż jeszcze pół roku temu…

Czego sobie i wszystkim Wam życzę :-)

Kategorie: Agile dla managerów, Agile dla klientów

(No Ratings Yet)

 Loading ...