Wycena to bardzo gorący temat w relacjach klientów z wykonawcami w praktycznie każdej branży, w tym też software house’ach. Nic w tym dziwnego - tworzenie czegokolwiek na zlecenie zazwyczaj jest spełnieniem marzeń zleceniodawcy lub po prostu ziszczeniem się jego długo skrywanego oczekiwania, a czar pryska, gdy w to wszystko wmieszane zostają pieniądze. Niestety, jest to smutna rzeczywistość, gdyż wykonawcy również muszą z czegoś żyć i nie ma co nad tym się rozwodzić, zwłaszcza, że wysokość wycen uwzględnia bardzo wiele czynników, o czym już kiedyś pisaliśmy.
Zajmijmy się zatem czymś innym - co sprawia, że software house jest w stanie lepiej ocenić pracochłonność zleconego zadania, a tym samym trafniej wyestymować czas oraz budżet potrzebny na jego wykonanie? Możemy zadać to pytanie jeszcze trochę inaczej - co musi dostarczyć zleceniodawca, aby firma IT lepiej oceniła, z czym będzie się mierzyć i dostarczyła bardziej realistyczne oszacowanie?
Wbrew pozorom, temat nie jest oderwany od rzeczywistości i nie jest to biznesowe lub coachingowe gadanie, jakich pełno w Internecie. Gdy pisaliśmy o procedurze, która ma miejsce po napisaniu do nas, podaliśmy przykład zapytania potencjalnego klienta o wycenę całego serwisu, przy czym opis zawierał się w jednym zdaniu. Tego, oczywiście, nie można dobrze wycenić. Ale tego typu sytuacje dotyczą nie tylko zupełnie nowych spraw - zdarzają się także w długotrwałych współpracach. Opowiedzmy sobie o tym, jak to wygląda ze strony software house’u.
Jak wygląda idealna wycena?
Pofantazjujmy trochę. Idealny materiał do wyceny to taki, który:
- zawiera wszystkie potrzebne informacje dot. oczekiwanej funkcji systemu lub potrzeby klienta, w tym np. atrybuty interesujących nas obiektów,
- wyjaśnia oczekiwane zachowanie w sytuacjach wyjątkowych,
- definiuje osoby lub role mające dostęp do nowego wymagania,
- zawiera uzasadnienie biznesowe wymagania,
- określa kwestie, na których klientowi zależy najbardziej, jak i wskazuje fragmenty, które są mniej priorytetowe.
Szczególnie ostatni punkt jest interesujący, gdyż zwłaszcza w bardziej złożonych wymaganiach wyceny zazwyczaj są tak duże, że dzieli się je na punkty wyceny, które następnie sumuje się lub określa warianty (o czym jeszcze dzisiaj sobie powiemy). Wówczas klient może wybrać najbardziej interesującą go opcję, jednak aby były one sensowne, zespół IT musi wiedzieć, na czym klientowi zależy najbardziej i jaka jest jego realna potrzeba biznesowa.
Kontynuujmy nasze marzenia - software house dostaje materiał do wyceny i jednocześnie klient zapewnia, że z chęcią dłużej poczeka na ofertę, jeśli będzie ona dobra. Wówczas członkowie zespołu IT:
- szczegółowo analizują dostarczone informacje, rozkładając je na czynniki pierwsze,
- przynajmniej wstępnie projektują architekturę oprogramowania pod rozważane zmiany,
- dzielą całe wymaganie na poszczególne, szczegółowe składowe, wyceniając każdą z nich osobno,
- uwzględniają czynniki pozatechniczne, kwestie wdrożeniowe i zarządcze,
- w przypadku wątpliwości (choć przecież mówimy o procesie idealnej wyceny, gdzie przecież nie powinno być niedomówień) układają pytania i szybko dostają na nie odpowiedzi,
- mają czas zaprezentować wizję (lub wizje, w liczbie mnogiej) na makietach,
- określają warianty wyceny, czyli różne opcje, jeśli jest to zasadne,
- wewnętrznie konsultują oszacowania w zespole, poznając różne punkty widzenia (wykorzystując do tego np. metodę Planning Poker),
- starannie opisują wszystko, co wycenili, w tym zachowanie w szczególnych przypadkach,
- oddają wycenę do konsultacji managerom projektu,
- wspólnie pieczołowicie ustalają nie tylko końcowy kształt wyceny, ale też możliwy deadline, biorąc pod uwagę trwające zadania,
- dostają szybką (i najlepiej pozytywną) odpowiedź klienta.
Brzmi jak cudowna sytuacja i… dosyć nierealistyczna. Mówiąc wprost, na wyceny zawsze jest mniej czasu niż się wydaje i trudno się temu dziwić. W końcu, gdy to my jesteśmy klientami i potrzebujemy oferty np. umeblowania kuchni czy samochodu, też nie oczekujemy, iż jej wystawienie potrwa np. dwa miesiące.
Jak to wygląda w rzeczywistości?
To nie jest jednak tak, że sytuacja opisana w poprzedniej sekcji nie zdarza się nigdy. Jeśli już się pojawia, to zwykle ma ona miejsce dla bardzo małych wycen (gdyż wtedy wszystko przebiega szybciej, jako że jest mniej kwestii do analizy) lub, paradoksalnie, dla bardzo dużych (kiedy po prostu trzeba wszystko drobiazgowo przeanalizować i klient też jest tego świadomy). Często też zdarza się, że mają miejsce wybrane pozycje takiego “perfekcyjnego procesu".
Tym niemniej, trzeba uczciwie przyznać, że wyceny zazwyczaj wiążą się ze ściskiem czasowym i to nie tylko z uwagi na oczekiwaną wartość końcową, ale też samym czasem dostarczenia oferty. Klient oczekuje, że software house szybko zareaguje, nawet jeśli realizuje właśnie dużo innych wymagań. To oznacza, że zespół zazwyczaj albo zatrzymuje zadania w toku w stabilnym stanie i pochyla się nad nowymi informacjami, albo przedłuża proces wyceny. Wszystko zależy od aktualnego statusu, stabilności projektu, liczności zespołu, trudności materiału do wyceny, a także oszacowania kosztu zmiany kontekstu (czyli przejścia z jednego zadania do drugiego).
Nie da się też ukryć, że nie zawsze klient dostarcza wszystkie potrzebne informacje. To oznacza, że zespół albo musi pewne rzeczy założyć (i wyraźnie zaznaczyć to w wycenie), albo - w bardziej złożonych przypadkach - zadać dodatkowe pytania, co może przerodzić się w spotkanie. Do tego jeszcze wrócimy. Dość jaskrawym przypadkiem tego typu są prośby o wyceny np. “standardowego modułu produkcyjnego". Przy czym, większość z nas się domyśla, że po prostu nie istnieje coś takiego jak “standardowy moduł produkcyjny" (każdy rozumie to pojęcie inaczej), a do tego sama funkcjonalność produkcji jest tak duża, że nie da się tego zamknąć w jednym zdaniu. To jednak skrajności.
Wreszcie, mimo różnych zabiegów, nie zawsze jest czas i sposobność przeanalizować wszystko w dokładny sposób i jeszcze skonsultować to z kilkoma osobami wewnątrz zespołu, ponieważ zleceniodawca czekałby zbyt długo. Wówczas zespół zwykle przyjmuje dodatkowy bufor, ale i tak bywa on niewystarczający, a na dodatek na etapie realizacji mogą pojawić się dodatkowe niejasności, które czasem przeradzają się wręcz w spory.
Co robi software house, gdy ma za mało informacji?
Jak wspomniałem w poprzednim akapicie, bywają sytuacje, w których osoba wyceniająca nowe wymaganie nie ma wystarczających informacji, a czuje, że może i musi je uzyskać. Czasem jednak nie jest to możliwe z przyczyn bardziej ekonomicznych, np. kiedy wymaganie jest bardzo niewielkie. Wówczas wyceniający najczęściej przyjmuje pewne założenia i wprost opisuje je w ofercie, informując tym samym klienta o fundamentach, na których stoi oszacowanie. W takich momentach klient może zareagować i rzucić nowe światło na sprawę.
Czasem jednak sprawa jest na tyle poważna, a wymaganie na tyle duże, że potrzebne jest dopytanie się o kilka kwestii. W tym momencie wychodzi też doświadczenie wyceniającego i umiejętność takiego zadania pytania, aby uzyskać odpowiedź, naświetlić nowe horyzonty zleceniodawcy, ale też pokazać swoją wiedzę oraz przenikliwość. To nie ma wpływu na samą wycenę, ale na pewno utrzymuje dobry wizerunek software house’u w oczach klienta, który widzi, że ma do czynienia z ekspertami. Warto przy tym wspomnieć, że pytanie lub wyjaśnienie nie musi mieć formy tekstowej - bywały u nas sytuacje, kiedy łatwiej było nagrać film i rzeczywiście popychał on sprawę do przodu.
Bywa jednak, że klient nie może (lub nie chce) odpowiedzieć mailowo lub kwestie są na tyle złożone i trudne do wyjaśnienia pisemnie, że trzeba zorganizować spotkanie. To jeden z tych momentów, w których w kontakt z klientem włączani są programiści, gdyż to oni, na równi z Product Ownerem, muszą mieć pełną wiedzę o funkcjonalności, którą prawdopodobnie będą implementować. Wynik takiego spotkania może być różnoraki, choć zazwyczaj kończy się wyjaśnieniem wszystkich wątpliwości lub przynajmniej prośbą o wycenę kilku opcji. Bywają też sytuacje, w których klient uświadamia sobie, że wymaganie faktycznie jest na tyle złożone, że najpierw sam musi je dobrze przemyśleć. A czasem zdarza się, że jedna wycena przeradza się w kilka wycen.
Dokładna wycena, warianty i pula godzin
Różne zadania wycenia się w różny sposób i jest to dość oczywiste. Natomiast dobrze wiemy, że w zarządzaniu projektami istnieją takie pojęcia jak Fixed Price czy Time and Materials. Krótkie przypomnienie:
- Fixed Price polega na tym, że zleceniodawca płaci za wycenę, niezależnie od tego, ile rzeczywiście zajęła praca,
- Time and Materials nie zakłada z góry liczby godzin spędzonych nad realizacją - zleceniodawca płaci tyle, ile praca rzeczywiście trwała.
Oba podejścia mają swoje zalety i wady. Natomiast z naszej perspektywy ważne jest to, że przy większych wycenach (np. zbioru zadań potencjalnie składających się na sprint) czasami miesza się te podejścia.
Najprostsza sytuacja jest przy zadaniach, których założenia są znane i zespół albo ma doświadczenie z implementacją wymagań danego typu, albo jest w stanie z niezłą precyzją ocenić pracochłonność. Wówczas mamy klasyczny przykład Fixed Price - robimy “zakład", iż realizacja danej części funkcjonalnej zajmie X godzin (lub w innej jednostce) i niezależnie od tego, jak bardzo się pomylimy, klient za tyle płaci. Ważne jest określenie założeń, które obowiązują podczas wykonywania zlecenia.
Ciekawiej robi się przy bardzo dużych zadaniach lub takich, gdzie istnieje dużo “dodatków", które klient może chcieć lub też nie. Są to tzw. wyceny wariantowe, gdzie istnieje pewna baza, natomiast można do tego dobrać kolejne opcjonalne funkcje - trochę jak wybór bonusów przy zamawianiu dania w restauracji. Wszystkie wyceny nadal są traktowane jako Fixed Price, jednak końcowa wartość jest sumą opcji wybranych przez klienta. Ma to zastosowanie w momencie, kiedy niektóre “odnogi" zadania są dużo bardziej skomplikowane i software house nie jest pewny, czy zleceniodawca rzeczywiście będzie je chciał po podanej cenie lub kiedy po prostu istnieje wiele dróg, którymi można podążyć. Ta wariantowość powstaje też często, kiedy zespół IT ma wątpliwości, ale kontakt z klientem w celu ich wyjaśnienia zajmie zbyt dużo czasu w stosunku do wyceny poszczególnych dróg rozwoju. Jest to też dobra technika, gdy wymaganie można zrealizować etapowo, niekoniecznie w jednym sprincie.
Natomiast są zadania “specjalne", które mają charakter bardziej analityczny, badawczy lub zespół nie wie, czego się spodziewać podczas realizacji. Nie jest to wstydliwe - istnieją takie funkcje, które wiążą się np. z integracją z zewnętrznymi systemami, gdzie nie zawsze łatwo jest określić trudności, które będą piętrzyć się po drodze. Czasem też zespół wie, że warunki mogą się zmienić podczas trwania sprintu lub nie wszystkie materiały są dostępne na początku, a zleceniodawcy bardzo zależy na rozpoczęciu zlecenia. Wówczas zakłada się tzw. pulę godzin, która jest bliższa Time and Materials. W takim zadaniu zespół ma górne ograniczenie godzin, które może wykorzystać i zatrzymuje pracę (oczywiście, w stabilnym stanie), gdy limit zostanie osiągnięty. Jednak, gdy zdoła zrealizować zadanie w krótszym czasie, to właśnie ta rzeczywista wartość stanowi podstawę do rozliczenia. Jest to zatem rozwiązanie, które pozwala założyć pewien budżet na rozpoczęcie (ważne z punktu widzenia klienta), ale niekoniecznie skończenie prac, co może również pomóc w określeniu, ile tak naprawdę czasu wymaga dana rzecz. Im bardziej jesteśmy niepewni, tym pula jest mniejsza, aby później, mając już dodatkową wiedzę, lepiej móc określić liczbę godzin potrzebną na dokończenie.
Co może zrobić zleceniodawca?
Od razu może powiedzmy, że zleceniodawca nic nie musi zrobić - w końcu jest zleceniodawcą. Natomiast każdej stronie zawsze zależy na tym, aby współpraca przebiegała możliwie gładko,a istnieją pewne kwestie, w których klient może pomóc zespołowi IT, ale też przede wszystkim sobie.
Przede wszystkim im więcej materiałów dostarczy, tym lepiej. Oczywiście, nie chodzi o to, aby “zawalić" software house kilkusetstronicowymi opracowaniami i formalnymi dokumentami, które wyłącznie luźno wiążą się z wycenianym zadaniem. Jeśli do prawidłowej wyceny potrzebna jest wiedza dziedzinowa, lepiej umówić się na spotkanie i wyjaśnić niedostatki wiedzy software house’u w danej dziedzinie. Tym niemniej, warto napisać wszystko, co chce się osiągnąć, w tym oczekiwane zachowanie w szczególnych przypadkach, punkt początkowy, punkt końcowy itd.
To, co jest często pomijane przez klientów, to wyjaśnienie rzeczywistego celu swoich działań. Bywało w naszej historii już tak, że klient prosił o wycenę wymagania, które wydawało się… No cóż - bezsensowne w znanym wówczas kontekście. Czasem utrudniało to podanie oszacowania, więc zespół miał dużo pytań do zleceniodawcy. Skutkowało to często tym, że po odkryciu rzeczywistych intencji klienta można było zaproponować dużo lepsze, a czasem i szybsze rozwiązanie napotkanego problemu. Software house’y są świadome, że klienci nie są specjalistami w zakresie IT (w końcu dlatego są potrzebne), więc nie muszą znać wszystkich opcji dostępnych na stole - to ten aspekt konsultingowy działalności takiego wykonawcy oprogramowania.
Jeśli klient posiada wizualizację pożądanej funkcji (wbrew pozorom, czasem się to zdarza, gdyż zleceniodawcy lubią wizualizować swoje pomysły), to nawet, jeśli jest ona bardzo podstawowej jakości, warto ją załączyć. Nie bez powodu mówi się, że obraz mówi tyle co tysiąc słów i nawet, jeśli makieta dostarcza więcej pytań niż odpowiedzi, to te pytania i tak zespół kiedyś by zadał, a lepiej zrobić to szybciej niż później. Jednocześnie warto mieć na uwadze to, że czasem software house odeśle swoją wizję i z nią też warto się zapoznać, a nie odrzucać z góry. Obu stronom zależy na dojściu do satysfakcjonującego rozwiązania.
I na koniec rada dość prosta, ale o której czasem się zapomina - warto dbać o język, którym posługują się obie strony w komunikacji, w tym także klient. I nie chodzi tutaj o savoir-vivre, tylko o staranne pisanie i świadomość, że nie wszystkie skróty i branżowe określenia mogą być tak samo rozumiane po drugiej stronie kabla. Znacznie lepiej wycenia się i w ogóle pracuje, gdy obie strony pokazują, że chcą się dogadać i unikają nieporozumień, czasem wynikających po prostu z niestarannego doboru słów lub ciągłego pośpiechu i pomijania przekazywania istotnych informacji.
Podsumowanie
Wycenianie to nie tylko gorący temat - to bardzo trudny proces, nie tylko z technicznego punktu widzenia, ale także biznesowego i komunikacyjnego. Na dobrej jakości oszacowań zależy wszystkim, gdyż każda strona chce dostać to, czego pragnie, a także utrzymać dobrą relację. Warto się zatem starać i wiedzieć, jak to wygląda z drugiej perspektywy.
Pozdrawiam i dziękuję - Jakub Rojek.