sobota, 22 października 2011

Kontrakty - co zrobić z fixed?

Ostatnimi czasu pokazało się kilka dość ciekawych postów na temat kontraktów agile, na przykład tutaj. Ja sam też kiedyś ten temat poruszałem tutaj. Od tego czasu wiele się jednak zmieniło, warto więc dołożyć trochę uwag wzbogaconych doświadczeniem.

Oczywiście idealną sytuacją jest kiedy możemy pozwolić sobie na zaawansowany i opierający się na zaufaniu kontrakt typu Capped T&M czy Cost Targeted. Niestety w dużej części  przypadków w świecie realnym jest tak, że z różnych powodów jedynym akceptowanym przez zamawiającego kontraktem jest fixed price (stała cena za wykonane prace). Takie ustawienie sprawy teoretycznie od razu wyklucza podejście agile, bo w tym momencie pierwsze co robi dostawca to domaganie się zdefiniowania fixed scope (stały zakres). Jak już mamy stały zakres i stałą cenę to gdzie tu miejsce na agile? Miejsca jest wbrew pozorom dość dużo.

Pierwsza rzecz to podejście iteracyjne do wykonywania projektu. Ten element jest dość często pomijany, natomiast wbrew pozorom bardzo ważny dla zamawiających. Chodzi o ograniczanie ryzyka. Jeżeli nie można wyeliminować ryzyka kontraktu (jest stała cena, więc i tak pojawią się koszty) to można chociaż próbować ograniczyć ryzyko produktowe. Czyli spróbować zapobiec sytuacji, kiedy klient dostanie coś, czego (w jego przekonaniu) wcale nie zamawiał. Z punktu widzenia zamawiającego jest ważne czy produkt projektu zobaczy dopiero raz, na samym końcu projektu czy będzie go widział często, mogąc go testować w trakcie. Zgodnie bowiem z panującym powszechnie przekonaniem klienta interesuje tylko efekt końcowy, ale przy okazji chciałby on osiągnąć go przy optymalnym ekonomicznie ryzyku. Dlatego wbrew powszechnie panującym przekonaniom klienta interesuje to, w jaki sposób dostawca realizuje projekt i jak ta realizacja wpływa na ogólne ryzyko całego projektu. Agile natomiast zmniejsza to ryzyko.

Kolejnym tematem jest wciągnięcie klienta w projekt. Zgodnie z wartościami agile interakcje między ludźmi są ważniejsze niż procesy i narzędzia. I to działa niezależnie od typu kontraktu. Znane mi są przypadki, kiedy dostawcy w sposób aktywny ograniczali dostęp zespołu wykonawczego do klienta. Co więcej kontakt z klientem ograniczał się do regularnych spotkań "na szczycie". Innymi słowy każda informacja przekazana przez klienta przechodziła przez trzy osoby zanim trafiła do programisty. Skutki można dość łatwo przewidzieć. Wszyscy działali w najlepszej wierze a klient i tak dostał nie to co chciał i za co myślał, że zapłacił. Tak więc komunikacja, komunikacja i jeszcze raz komunikacja. Oraz aktywne włączenie klienta w prace.

Trzecia natomiast rzecz to elastyczność w przejściu w tryb "variable scope". To najlepiej wytłumaczyć na przykładzie. Załóżmy, że realizujemy kontrakt typu fixed (stała cena, stały zakres). W połowie projektu klient orientuje się, że chce zmienić jedno z wymagań. Zwykle dlatego, że w jakiś sposób zmieniły się warunki prowadzenia biznesu. Co w takim wypadku może zrobić dostawca? Pierwsza opcja to przyjąć i wycenić "change request" (żądanie zmiany). Bardzo często po stawkach wyższych niż oryginalny projekt (jak to wpływa na jego wizerunek w oczach klienta?). Druga opcja to przyjść do klienta i powiedzieć mu, że może zrealizować tą zmianę w ramach obecnego kontraktu, ale konsekwencją jej zrealizowania będzie nie zrealizowanie całego wcześniej zakontraktowanego zakresu. Takie podejście to właśnie dążenie do projektu "variable scope". Oczywiście na wszelkie tego typu zmiany muszą istnieć później odpowiednie dokumenty (bo to w końcu zmiana warunków kontraktu). Zapewne zależy to od klienta, ale takie podejście może się spotkać z zaskakująco dobrym przyjęciem. Oczywiście również dlatego, że najważniejsze z punktu widzenia klienta funkcjonalności zostały zrealizowane na początku projektu, więc konsekwencje zmiany zakresu nie będą miały na nie wpływu, prawda?

Brak komentarzy: