Battle for Agility

Czas to pieniądz?

November 22nd, 2006 Marcin Niebudek

O blaskach i cieniach zamkniętego kontraktu już co nieco wiemy. Załóżmy na moment, że jednak udało się nam go uniknąć chociaż częściowo. Mimo to każdy kierownik projektu i tak stanie przed słynnym pytaniem ze strony swojego szefa, który z kolei na to samo pytanie musi odpowiedzieć klientowi. Pytanie brzmi:

“No dobrze, ale czy w tych Waszych zwinnych metodach kompletnie nie wiadomo ile to będzie mniej więcej kosztowało?”

Oczywiście odpowiedź jest i zależy od tego jak dobrze znamy nasz zespół, jak zgrana jest ta grupa ludzi, i od wielu innych czynników. O dochodzeniu do odpowiedzi na to pytanie może następnym razem. A dzisiaj choć trochę rozprawić chciałbym się z tym, co następuje chwilę po tym jak klient już pozna tę upragnioną odpowiedź… O jak drogo! Czy nie da się tego jakoś “przyciąć”…

No właśnie. W dużym skrócie zaczynamy od tego, że nasz zespół po wstępnych rozmowach z klientem stara się stworzyć pierwsze oszacowanie pracochłonności projektu. W tej chwili nie ma znaczenia czy będą to godziny, dni robocze, dni idealne, gumisie, czy cokolwiek innego. Koniec końców jesteśmy w stanie przeliczać te jednostki na inne. Każdy manager wie ile kosztuje dzień pracy jego zespołu (prawda, że to wiemy…?!). Z wiedzy na temat kosztów i wstępnego oszacowania zakresu można już w jakiś sposób prognozować (również bardzo wstępnie) koszt projektu. Klient dostaje pierwszą informację na temat tego, na co powinien być przygotowany decydując się na realizację projektu.

I tu zwykle kończy się racjonalne podejście. Powiem więcej - racjonalność staje się odwrotnie proporcjonalna do usztywnienia ram kontraktu. Załóżmy, że oszacowaliśmy (wstępnie - pamiętajmy o tym) zakres i mamy okrągłą sumę 1000 godzin. Stawka za godzinę w naszej firmie to 100 PLN. Klient dowiaduje się, że projekt będzie go kosztował 100 tys. PLN.

Oczywiście pierwsze co słyszymy to, że to drogo (w końcu nie należy przyjmować pierwszej oferty). No i dochodzi do podstawowego złamania zasad zdrowego rozsądku. Wieść wraca z powrotem do zespołu wraz z poleceniem… ponownego rozważenie swoich oszacowań, bo może uda się coś przyciąć. Wielokrotnie byłem postawiony w takiej sytuacji. Wielokrotnie też ulegałem swoim przełożonym. Do dzisiaj nie potrafię znaleźć ani jednego argumentu uzasadniającego taki podejście.

Ustalmy klika faktów. Jest początek projektu. W większości przypadków śmiało możemy powiedzieć, że na temat tego co projekt tak na prawdę kryje więcej wciąż nie wiemy, niż wiemy. Pewnym jest wobec tego, że nasze szacunki raczej są za niskie.

Szacując jakąś pracę zwykle podświadomie szacujemy w tak zwanych idealnych jednostkach, czyli np. w idealnych godzinach/dniach pracy. “Idealny” oznacza tutaj czas kiedy nikt nie będzie nas odrywał od pracy, zajmował nas innymi rzeczami. Co więcej kiedy sami nie będziemy się od niej odrywać. Praktycznie nie zdarza się, żeby idealne jednostki przekładały się na rzeczywisty czas pracy w stosunku jeden do jednego. Wniosek jest taki, że nasze szacunki są jeszcze mniej zbliżone do faktycznego czasu pracy, a tylko taki da się wycenić. Tutaj pojawia się pole do popisu dla kierownika, dla dobrej znajomości zespołu i tego czy kierownik potrafi przełożyć te szacunki na faktycznie poświęcony czas pracy. Czy jest to czas optymalny i jak bliski w swoich prognozach może być kierownik zespołu. Kluczowym elementem staje się wiedza na temat tego ile tych oszacowanych godzin/dni zespół jest w stanie wykonać w ciągu np. jednego 5-dniowego tygodnia pracy, bo to wprost przekłada się na koszty.

Oszacowanie projektu na 1000 godz. to nie tylko koszt projektu, to także termin. Oczekujemy od zespołu, że magicznie przyspieszy pracę i wykona pewne zadania w krótszym czasie (więc za mniejsze pieniądze z punktu widzenia klienta). Często faktycznie tak się zdarza, że niektóre zadania są przeszacowane, ale jednak wciąż więcej jest tych niedoszacowanych. Tymczasem zespół sam zawiązuje sobie pętlę na szyję. Bo wszyscy szybko zapomną, które oszacowania zostały przycięte, ale ci którzy zapomną najszybciej, pierwsi zjawią się aby dopominać się o realizację tych zadań w nowych terminach.

O co więc chodzi? O to, że z całą pewnością będziemy negocjować koszt projektu, ale metoda, którą przyjmuje wielu managerów jest co najmniej chybiona. Dlaczego tnie się plany projektu na lewo i prawo zamiast dokonać najprostszego pod słońcem cięcia w stawce jaką oferuje się klientowi?

Wróćmy do naszego przykładu. Cięcie oszacowań doprowadzi do następującego stanu. Wymusimy na zespole aby zrezygnował np. z 50 godzin (nadal nie pojmuję idei kryjącej się za tą techniką). Nowe oszacowanie będzie mówiło o 950 godzinach, co da 95 tyś PLN. Ale przy tym zespół straci ok. 2 tygodni czasu dla jednego ze swoich członków. Czym bardziej sztywny kontrakt tym gorzej będzie to nadrobić. Co ciekawe takie cięcie przerzuca na zespół ciężar realizacji zadania, bo manager jednoznacznie daje sygnał, że obiecał klientowi 5 tys. zniżki, ale oczekuje, że zespół pracując “szybciej” zapewni mu pierwotnie zakładany zysk z operacji (bo szybciej pracując zmniejszamy także koszty). Manager ma powód do dumy… to nic, że za pół roku dowie się, że jego zespół się nie wyrobił i odda klientowi jeszcze trochę pieniędzy w karach.

Cięcie stawki wyglądałoby następująco. Chcąc dać 5 tyś. zniżki klientowi, zaproponujmy mu stawkę 95 PLN za godzinę. Projekt nadal pozostaje 1000 godzinnym przedsięwzięciem. Klient zakłada wstępny koszt na 95 tyś. PLN. Co więcej może przyjąć, że jeśli projekt okaże się większy to generalnie wynegocjowana została korzystniejsza stawka. Kto więc stracił? Manager, bo zmniejszył marżę, zamiast zmuszać zespół do podkręcenia tempa. Ale czy stracił tak naprawdę? Przykład jest bardzo uproszczony, ale w prawdziwych projektach, jeśli projekt z okrojonym harmonogramem się nie powiedzie, mamy do stracenia dużo więcej niż tylko różnicę w marży. Z resztą i tak mądry manager pewnie zaczynał ze stawką dla niego bezpieczną.

Techniki agile dostarczają doskonałych narzędzi zarówno do poznania własnych zespołów i ich możliwości. Pomagają także dobrze kontrolować budżet przedsięwzięcia zarówno klientowi jak i wykonawcy. Idąc krok dalej i przestawiając się na myślenie stawkami zamiast zamkniętymi zakresami i cenami można dużo zyskać. Gdzieś po drodze zginęła ta ważna informacja, że wszystko to były wstępne szacunki. Cena nie powinna być ostateczna. Ostateczna powinna być stawka. Bezpieczeństwo przed naciąganiem da klientowi sam proces wytwarzania. Nigdzie nie jest także napisane, że w razie wzrostu zakresu projektu stawka nie zacznie nieco spadać - pierwsze 1000 godzin 95 PLN/godz. ale każde kolejne 100 w tym projekcie już 85 PLN/godz. Wydaje mi się, że mądra polityka cenowa może przełamać bariery psychologiczne pojawiające się na styku metod agile i pieniędzy klienta.

Z całą pewnością opisane przeze mnie podejście w wielu firmach (zwłaszcza większych) nie ma miejsca, ale niestety w tak dużej liczbie innych firma nadal ma miejsce! Tak więc drodzy managerowie. Nie negocjujcie ceny przy pomocy czasu, tylko pieniędzy. Będzie to oznaką dojrzałości waszych firm.

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

(3 votes, average: 4 out of 5)

 Loading ...