Battle for Agility

Czas to pieniądz?

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.

2 comments November 22nd, 2006

Zamach na zespoły?

Od dłuższego czasu obserwujemy wzmożony wzrost popularności zjawiska nazywanego “leasingiem pracowniczym”. Mam nawet wrażenie (być może związane tylko z lokalnym rynkiem IT, z jakim mam kontakt), że firm wynajmujących programistów jest już więcej niż firm tworzących oprogramowanie na własne potrzeby. Wynajmują pracowników duże korporacje, wynajmują banki.

Kiedyś wystarczał “outsourcing” samej usługi do firmy zewnętrznej. Teraz firma IT ma fizycznie wstawić swoich pracowników do firmy klienta na kilka tygodni/miesięcy, żeby tam w ramach zespołu klienta wykonali (czy raczej podgonili) jakąś część projektu. Co to wszystko ma wspólnego z agile? No więc dla mnie agile to między innymi silne zespoły. Silne ze względu na swoją niezależność, samowystarczalność, zdolność adaptacji i utrzymania wysokiej jakości produktów - takie samojezdne, samonapędzające się machiny do zadań specjalnych. Tylko co dzieje się z zespołami kiedy zaczynamy fizycznie delegować naszych pracowników? Co z wydajnością takich zespołów. Co z jakością ich pracy?

Popularność leasingu/wynajmu pracowników ma kilka dość łatwych do odgadnięcia powodów. Od strony klienta to pewna mutacja outsourcingu z tą małą różnicą, że skoro wynajmuje firma IT, to woli dostać ludzi, nad którymi będzie miała kontrolę zamiast podpisywać kontrakty na wykonanie podsystemu i kontroli nie mieć. Posiadanie dodatkowych ludzi, których po skończonym projekcie/etapie można odesłać do ich własnej firmy pozwala ograniczyć koszty utrzymywania własnego rozbudowanego zespołu IT na stałe, ale także jest chyba mniej ryzykowne niż tradycyjny outsourcing.

Powodami ekonomicznymi kieruje się zapewne także firma wynajmująca swoich ludzi. Coraz trudniej jest znaleźć wykwalifikowanych i doświadczonych pracowników, więc wrosła cena pracy programistów, a skoro tak, to pojawiło się dużo firm, które z tej “górki” chcą w prosty sposób wziąć coś dla siebie. Często firmy działające jako tradycyjne software house są narażone na chwilowy przestój w zleceniach, co powoduje, że mają część zespołu, który przez moment może nie mieć co robić. Wtedy lepiej wynająć tych ludzi (i przy okazji na tym zarobić) niż ponosić koszty trzymania pracowników przez ten jałowy okres, czy zwalniać ich (bo potem będzie problem z odbudową zespołu).

Wydaje się, że nie ma co polemizować z takimi przesłankami. Ciekaw jestem tylko czy wynajmując programistów, osoby za to odpowiedzialne rozważają następujące czynniki:

• Czas aklimatyzacji programisty w zespole. Tworzenie oprogramowania nie jest czynnością mechaniczną tylko umysłową. Ĺťeby ją wykonywać człowiek musi mieć do tego odpowiednie warunki i predyspozycje. Pisali o tym już DeMarco i Lister w “Czynniku ludzkim” (ang. tytuł: Peopleware), przypominał także ostatnio na JDD2006 Bruce Eckel - programistów nie można dowolnie między sobą wymieniać. Ponadto każdy programista ma zupełnie inną wydajność w pierwszym tygodniu pracy, a inną po miesiącu. A czy wynajmując pracownika różnicuje się stawki w zależności od jego “stażu” w nowym miejscu pracy? Zatrudniając pracownika na stałe ponosimy koszt aklimatyzacji raz. Okresowo wynajmując pracowników koszt jest częstszy chyba, że mamy szczęście wynajmować za każdym razem tych samych ludzi.

• Konflikt interesów. Cele pracownika wynajmowanego nie są zgodne z celami firmy klienta. W interesie klienta jest szybkie zakończenie pracy, ale dłuższy czas gra na korzyść firmy wynajmującej pracownika, bo przecież wystawi ona fakturę za czas wynajęcia a nie za zadania (zadania to już sprawa klienta). Oczywiście aby firma świadcząca usługi wynajmu programistów mogła się utrzymać u klienta i liczyć na kolejne zlecenia, musi zapewnić odpowiedni poziom kwalifikacji swoich pracowników. Wydaje mi się jednak, że siłą rzeczy nie osiągną oni w swojej pracy 100% tego co mogliby osiągnąć dla swojej firmy, w swoim zespole. A co jeśli będą mieli nawet polecenie “z góry”, żeby się specjalnie nie spieszyć, bo są w końcu zatrudnieni na godziny. Ten konflikt interesów wydaje mi się najpoważniejszą wadą w stosunku do tradycyjnego modelu outsourcingu, gdzie na czasie zależy zarówno zleceniodawcy jak i wykonawcy, a wszyscy pracują u siebie.

• Ograniczona odpowiedzialność. Wpuszczamy do firmy programistów z zewnątrz, którzy niedługo nas opuszczą i pójdą do innych firm. Siłą rzeczy ograniczamy im możliwość podejmowania jakichkolwiek istotnych decyzji, ograniczamy dostęp do pewnych krytycznych dla firmy zasobów itd. To ogranicza im swobodę tworzenia oprogramowania, do którego ich zatrudniliśmy. Taka sytuacja albo spowoduje przestoje w ich pracy, albo zaangażuje dodatkowo członków naszych rodzimych zespołów pogarszając ich wydajność. No bo skoro tamci nie mają prawa wykonać pewnych rzeczy, to ktoś inny będzie to musiał zrobić w ich imieniu. Czy w rachunku ekonomicznym bierzemy pod uwagę takie koszty? Jak je uwzględnić? Taka organizacja pracy przeczy zasadzie samo organizujących się zespołów (chyba, że ich kierownik w firmie klienta pozwoli im się organizować w ramach ich ograniczonych możliwości). Z resztą chyba najczęstszym podejściem zarządzającego takim zespołem będzie jednak ścisła kontrola poczynań jego członków. Widzę tutaj także istotny problem umotywowania takich ludzi do pracy, skoro są niejako pracownikami trochę gorszej kategorii.

• Podkopywanie własnych zespołów. Jeśli zamiast tworzyć z wynajętych programistów odrębnego zespołu wcielimy ich do istniejących u nas zespołów, to po pierwsze zadziałają efekty przytaczane przez Brooks’a w “Mitycznym osobomiesiącu” - nasi ludzie zamiast zajmować się pracą zaczną zajmować się nowymi ludźmi. Poza tym jeśli mamy w zespole programistów “tymczasowych”, to możemy mieć do czynienia z sytuacją, kiedy zespół nie będzie chciał wziąć odpowiedzialności za kod ludzi z zewnątrz. Z resztą tymczasowi pracownicy także nie są skłonni do przyjmowania celów grupy jako własnych. A wspólna własność kodu to jedna z ważnych i wartościowych zasad stosowanych w praktykach agile. Ludzie będą raczej mieli skłonność do obwiniania tych, których nie ma już w firmie, za wszelkie zło w projekcie. Oczywiście ta sama zasada wspólnej własności kodu mogłaby pomóc w tym przypadku, ale jakoś ciężko mi to sobie wyobrazić.

To pewnie tylko kilka sytuacji, jakie mogą się wiązać z nowym pomysłem na życie coraz większej liczby firm w naszej branży. Wydaje mi się, że jest to jeden z trybów pracy jaki wyjątkowo nie sprzyja używaniu agile. Ale może się mylę i da się agile pogodzić czy wręcz wykorzystać na korzyść leasingu programistów (o czym chętnie usłyszę). Tymczasem namawiam do inwestycji we własne zespoły, bo silny kilkuosobowy zespół da radę dużo większej liczbie często przypadkowych ludzi.

Dobrze byłoby gdyby przynajmniej rachunek zysku i strat nie ograniczał się wyłącznie do przeliczenia stawki godzinowej, ale uwzględniał także tą drugą stronę medalu.

7 comments November 6th, 2006