Pisało się o korporacji, pisało się o dziennikarzach i junior brand managerach. Nadszedł czas, żeby napisać coś o własnej branży.

IT – dzisiaj biorę się za ciebie.

Nie w całości oczywiście. Za dużo tego. Na początek coś z własnego podwórka czyli projekty i IT. Zobaczymy, czy tym wpisem nie ukręcę bata na samego siebie.

Tak zwany “biznes” często narzeka na IT i ich projekty. Że długie, że kosztują, że efekt nie jest oczywisty. I powiedzmy sobie szczerze:

TAK WŁAŚNIE CZĘSTO JEST! SZACH MAT, IT!

Zdjęcie: ixtussy via VisualHunt.com / CC BY-NC

Związane jest to z procesem sprzedaży produktów, usług i projektów: Panie dyrektorze, to oprogramowanie rozwiąże ten problem. Tak, wiem – ten problem stworzyło nasze poprzednie oprogramowanie, ale to właśnie go rozwiązuje.

Znacie to skądś? Ja tak. Może nie dosłownie, ale sens jest oddany.

Przyczyna może leżeć w kulturze organizacji i jej sposobie pracy (Oj! Właśnie w jednym takim projekcie uczestniczę), nieodpowiednich osobach przypisanych do nieodpowiednich zadań (cuda może uczynić osoba, niekoniecznie techniczna, która po prostu projekt “ogarnie”).

Dzisiaj jednak nie będzie stricte o tym, jak projekt jest prowadzony, jak zespoły działają i dostarczają. Będzie o czymś, co wszyscy znają, używają. ale czasem nie podejrzewają, że to może prowadzić na projektowe manowce.

Będzie o GODZINACH! Tak, o tych mitycznych stawkach godzinowych w IT (i już – konkurs anonimowy w komentarzach – kto jakie ma 🙂 ).

Godzinki

Tak, mówimy o tych wszystkich tajmszitach, raportach, arkuszach. Każdy konsultant czy developer prędzej czy później spotka się z koniecznością raportowania czasu i rozliczania go.

A co godziny mają do tego? Co się czepiasz!? Przecież jakoś trzeba mierzyć czas w projekcie.

Same w sobie nie są niczym złym. Jest to jakiś sposób mierzenia czasu spędzonego nad projektem i rozliczania się. To tylko narzędzie.

Problem zaczyna się, gdy o godzinach ktoś myśli jako o istocie projektu i tym, co ma dostarczyć. Czyli gdy zaczyna się coś, co nazywam PRZEPALANIEM.

Wszyscy raportują, nie widać wyniku, a głównym produktem całości stają się …GODZINY! Są raportowane, statusowane, podliczane i weryfikowane.

Negocjacje

Gdzieś w organizacji pojawia się problem. Problem wymaga rozwiązania. Przypadkowo może się okazać, że jego rozwiązaniem jest wykonanie jakiejś pracy projektowej.  A zdarza się to nawet często.

Co robi organizacja? Definiuje problem, opisuje go i wysyła zapytanie do swoich dostawców lub firm, które nimi mogą zostać. Proces ten odbywa się wewnętrznie lub – w przypadku organizacji posiadających większe środki lub kulturę organizacyjną (lub oba te elementy) –  zaprasza się kogoś innego: firmę doradczą, freelancera, osobę znającą się na tematyce.

Ten krok nie musi być tak głupi, jak powszechnie się uważa (przyjdą, powiedzą oczywiste rzeczy i zainkasują za to sporą kwotę). Oddelegowanie opisu problemu do kogoś, kto posiada odpowiednią wiedzę merytoryczną z tego zakresu, może wyjść na dobre. Spojrzenie z zewnątrz też potrafi zdziałać cuda.
Często pozwala uniknąć zabrnięcia w ślepą uliczkę już na samym początku. Brałem kiedyś udział w rozmowach związanych z zapytaniem z jednego z banków. Po kilku naszych pytaniach druga strona doszła do wniosku, że w zasadzie nie ma tematu i to, co próbowali zrobić może nie ma aż tak wielkiego sensu.

Kiedy problem jest już zdefiniowany, zostaje opisany, sformalizowany i wypuszczony w formie ER EF PE (RFP).  Dla tych spoza branży lub nie mających z tym styczności: Za ile nam to zrobicie, panie i panowie, bo my mamy problem, ale już wiemy jak go rozwiązać!

Zdjęcie: Mr.TinDC via Visual hunt / CC BY-ND

Potencjalni dostawcy zakasują rękawy, wykonują kaskadowanie w dół (w każdej branży jest odpowiednik junior brand managera) i wychodzą z propozycją. Jakąś. Jednym z elementów propozycji jest oczywiście KWOTA!

Kwota ma to do siebie, że oddaje wiele rzeczy:

  • doświadczenie (lub jego brak) tego, kto opisał problem, jak i odpowiadającego,
  • ryzyko (lub jego brak) związane z wszystkimi czynnikami, jakie obie strony na podstawie swojego doświadczenia (lub jego braku) są w stanie zdefiniować,
  • warunki wykonania całości (I jeszcze żeby było na jutro!).

Idealną sytuacją byłoby, gdyby kwota miała odniesienie do wartości, jaką dany projekt ma dostarczyć.

Właśnie, a jaka jest wartość w tym projekcie dla klienta!? I wykonawcy?

Wartość projektu. Po co go robimy? Jakie będą korzyści? Niby oczywisty element, ale często niewidoczny.

Zamiast tego, na tym etapie pojawiają się prośby: Proszę o przedstawienie rozbicia projektu na ilość godzin dostarczonych przez poszczególnych członków zespołu.

Czas na wielkie pytanie!

CZY JEŻELI DOSTARCZĘ TO, CO STANOWI O WARTOŚCI PROJEKTU W CIĄGU JEDNEJ GODZINY / W CIĄGU TYSIĄCA GODZIN, TO ZMIENI TO KWOTĘ, JAKĄ JESTEŚCIE W STANIE ZAPŁACIĆ ZA ROZWIĄZANIE PROBLEMU?

Praktyka pokazuje, że nie. Pokazuje, że często kryterium wyboru jest ilość godzin i stawki za nie.

Wykonanie

Wartość projektu rozumiana jako korzyść z jego realizacji nie pojawiła się nigdzie wcześniej albo jest tematem pobocznym.

W wyniku tego, wykonanie projektu często jest ustawiane w kontekście zużycia czasu i budżetu.

Oczywiście, ustalane są też punkty milowe, kryteria obioru i produkty. Równolegle jednak obywa się proces raportowania i opłacania “godzin” zużytych dotychczas.

Przez te kilka lat różne rzeczy widziałem – były i projekty, w których ilość zaraportowanych godzin była używana jako miernik postępu projektu.

Jeżeli to jest cały proces, to często dochodzi do sytuacji, w której:

  • czas na realizację projektu mija, a na wyjściu pojawia się nic lub mało,
  • w projekcie pojawiają się i znikają kolejne osoby, które znalazły się tam głównie po to, żeby bilans godzin się zgadzał,
  • znika budżet konsumowany co miesiąc na podstawie dostarczonych raportów czasu.

A wyników wciąż brak!

W którymś momencie pojawia się problem. Pula godzin się wyczerpała. Są na to raporty, są na to tajmszity. Wszystko jest udokumentowane. Cóż, skończyło się, trzeba dosypać.
Rozpoczynają się negocjacje (albo i nie), poszedł już w to czas i środki finansowe, nikt nie przeczytał jeszcze o SUNK COST, marchewka w postaci ukończenia projektu jest tuż, tuż.

Jeszcze tylko dodatkowych 100 godzin konsultanta!

Karuzela kręci się dalej. Godziny się raportują.

Czy to, co miało być zrobione – jest zrobione? Ależ skąd, przecież wciąż płyniemy, wiosłujemy, raportujemy – do wspólnego celu!

Burning clock

Przesadzam? Zapewne trochę. I nawet celowo.

Co chwilę trafia się na firmę czy projekt, w którym widać jednoznacznie, że głównym celem jest zaraportowanie czasu i wygenerowanie związanej z nim płatności. Tyle.

Zdjęcie: sonear via Visual Hunt / CC BY-NC-SA

Terminy się przesuwają, konsultanci i programiści się zmieniają, stała jest tylko firma dostarczająca określoną liczbę godzin.

Firmy zamawiające usługi czy oprogramowanie same też taki tryb działania promują, zadając w procesie zakupu magiczne pytanie: Czy możemy prosić o rozbicie kwoty na stawki godzinowe? Tak jest łatwiej. Mamy kilka firm, mamy prosty algorytm – ilość godzin i stawka.

Gdzie tutaj miejsce na doświadczenie, wiedzę?

A to jest standard, jeżeli chodzi o rozmowy przy projektach.

Kiedy czas ma sens

Są sytuacje, kiedy podejście oparte tylko i wyłącznie o raportowanie czasu mają sens.

Teraz mały wykład o procesie, który z klientami i konsultantami przechodzę od czasu do czasu przez ostatnie 10 lat.
Jest problem. Aby go rozwiązać, trzeba wykonać mniej lub bardziej zdefiniowana pracę. Zarówno zlecający, jak i ten, kto się jej podejmuje – mają mniejsze lub większe pojęcie o tym, co będzie wykonane, jakie są warunki dostarczenia, otoczenie projektu (kultura firmy, uwarunkowania organizacyjne)

Wszystko to składa się na jeden czynnik – RYZYKO!

Zdjęcie: kyz via Visualhunt.com / CC BY

RYZYKO jest jednym z głównych elementów, który wpływa na cenę i tryb dostarczenia projektu.

Jeżeli RYZYKO bierze na siebie dostawca, zobowiązując się, że dostarczy daną pracę i WYNIK w określonym czasie, jakości i cenie – wlicza to w koszt projektu.

Ma działać za tydzień – proszę bardzo. Wiemy jak, ale jest to ryzykowne, musimy przerzucić na to odpowiednich ludzi. To wszystko was nie musi interesować, ale kosztuje to XXX.

W takim wypadku mówimy o dostarczeniu projektu fixed price, czyli zobowiązaniu się do wyniku za określoną kwotę:

  • jest określony zakres prac do wykonania, ale nie wszystko jest jasne,
  • wkładamy w to nasze know-how,
  • jeżeli w trakcie okaże się, że trzeba coś zmienić – będziemy zmieniać. Jeżeli wyjdzie to poza nasz margines RYZYKA, będziemy negocjować.

Inna sytuacja, gdy wymagania i sposób dojścia do celu nie są dobrze zdefiniowane. Wiemy, gdzie chcemy dojść, ale nie wiemy ,co może czekać nas po drodze. Nie wiemy, czy będziemy musieli tam dojść, dopłynąć, może nawet trzeba będzie zbudować sterowiec.

Możemy podejść do tego tak, jak powyżej, ale barierą przeważnie będzie KOSZT związany z dużym RYZYKIEM. Możemy też podejść inaczej – robimy swoje i rozliczamy się na bieżąco. W każdej chwili możemy skręcić, zawrócić lub zaprzestać wędrówki.

W tym drugim przypadku mówimy o podejściu typu time&material (T&M).

Przy takim podejściu, RYZYKO zmian ponosi zamawiający. I w tym przypadku najczęściej będziemy rozliczać się  właśnie na godziny:

  • idziemy do celu z określonymi kryteriami, ale nie wiemy jeszcze, jak tam dojść,
  • wymagania i otoczenie mogą się zmieniać,
  • w każdym momencie możemy skończyć projekt albo zmienić jego kierunek.

Oczywiście, najczęstsza sytuacja to taka, w której zamawiający oczekuje, że dostarczymy określoną rzecz przy określonych warunkach (czas, jakość) z dowolną możliwością zmian wymagań i zakresu po jego stronie. W tydzień. I to w określonym budżecie. 3-W-1. Z tym, że nikt nie każe nam się na takie podejście zgadzać.

Wartość głupcze!

Zapytacie, co z tym zabijaniem IT. Przecież to, co opisuję, to oczywistość, chleb nasz powszedni.

Praktyka pokazuje, że jednak nie jest to taka oczywistość. Praktyka pokazuje, że nadal IT dostarcza projekty, których głównym wynikiem są przepalone godziny, a głównym celem prowadzenia projektów jest ich raportowanie.  Praktyka pokazuje, że często głównym kryterium porównania ofert przy wyborze projektów jest ilość godzin lub ich koszt.

Każdy projekt, który służy głównie do wygenerowania raportu godzin, powoduje, że obraz IT jako studni bez dna na pieniądze się utrzymuje. Coś się dzieje, niby wszyscy gdzieś biegną, ale już od dwóch lat wyniku nie widać.

To nie tędy droga. IT przestało być magiczną dziedziną. Stało się już czymś powszechnym i łatwo dostępnym! Jeżeli to wszystko ma się dalej kręcić, to zamiast czasem, trzeba zacząć myśleć tym, co z tego czasu wynika. Jaka jest wartość tego, co dostarczamy.

WARTOŚĆ!

Zdjęcie: Thomas Hawk via VisualHunt.com / CC BY-NC

Definiując projekt, zdefiniujmy jego wartość dla organizacji. Zakomunikujmy to dostawcom. Może zamiast rozliczać się na godziny, rozliczajmy się z WYNIKU – ZREALIZOWANIA tego, co stanowi WARTOŚĆ projektu.

To byłoby o wiele ciekawsze!

Dlaczego tylko “byłoby”? Rzeczywistość skrzeczy.

Większość firm w tej chwili nie miałaby nawet procedury na zakupienie takiego projektu lub podpisanie umowy w tej formie. Przez lata zbudowaliśmy w branży pewien ekosystem, który będziemy teraz rozmontowywać. Pytanie, czy potrwa to tak samo długo, jak jego budowanie…
Wydaje mi się, że o wiele krócej. A przynajmniej taką mam nadzieję.

Ktoś musi być pierwszy. Może ty!?

Na koniec jeszcze link do artykułu, który może nie wprost, ale łączy się z tym, o czym pisałem: Stopping Self Harm in Corporate IT. Ostrzegam – DŁUGIE I TRUDNE (to się teraz źle sprzedaje ;)).

Zdjęcie główe: tj.blackwell via Visual Hunt / CC BY-NC

About Author

Leave A Reply

Share This

Share This

Share this post with your friends!