Ile będzie kosztował projekt? O sztuce estymowania

 

Jeden z naszych zespołów deweloperskich założył ostatnio w swoim pokoju akwarium z rybkami. Ot, uprzyjemnienie pracy. Gdy pewnego razu pojawiło się kolejne, bardzo pilne zapotrzebowanie na wycenę dość złożonego projektu, ktoś rzucił hasło „zapytajmy rybek”.

Ten żart ilustruje, jak wiele niewiadomych stoi przed zespołem, który ma dostarczyć informację pozwalającą podać Klientowi cenę. Aby odpowiedzieć szybko, można nawet „zapytać rybek”. Skoro ośmiornica może typować wyniki meczów piłkarskich… Ale żarty na bok.

W pytaniu postawionym w tytule kluczowy jest czas przyszły. Projektu jeszcze nie ma i nie do końca wiadomo, co ma być jego przedmiotem. Od pierwszej wzmianki, że pojawia się perspektywa stworzenia nowego oprogramowania dla naszych Klientów do rozpoczęcia realizacji projektu droga jest dość długa. Praktycznie zawsze zagadnienie biznesowo i systemowo nie jest trywialne. Aby projekt mógł się rozpocząć, należy jednak z góry odpowiedzieć na pytanie „za ile”. To naturalne. Gdy przychodzimy coś kupić do sklepu, jednym z naszych podstawowych pytań jest pytanie o cenę. I w sklepie zawsze tę odpowiedź dostajemy od razu. W projektach informatycznych niestety tak nie jest. Nie pomaga podrapanie się w głowę ani pytanie rybek.

Estymowanie opiera się na metodach wnioskowania statystycznego, ale w projekcie informatycznym to za mało. Nie ma dwóch takich samych projektów. Nie ma dwóch takich samych kontekstów. Rzetelna odpowiedź wymaga wyceny, która wiąże się z analizą, niekiedy z dość żmudną, na którą nie zawsze jest dostatecznie dużo czasu w żywiole biznesu.

Nawet jeśli nasz Klient przychodzi do nas z projektem wymagań dla systemu – co zdarza się nie tak często – na etapie wyceniania poszukujemy optymalnego rozwiązania. Być może należy pójść ścieżką, której Klient nie zauważył. Dlatego nie ma dobrej wyceny bez dobrego zrozumienia, na czym polega problem Klienta i w jaki sposób przyszły produkt ten problem rozwiąże. Tego wymaga od nas profesjonalizm i uczciwość.

Gdy już znamy i rozumiemy potrzebę Klienta, który ma korzystać z naszego oprogramowania, przystępujemy do „rozbierania tematu na czynniki pierwsze”. Analiza funkcjonalna i techniczna powstająca w efekcie tej pracy jest swego rodzaju mapą na drodze do celu. Dopiero gdy trasa jest opracowana, można oszacować, jak długo potrwa podróż i ile będzie kosztować. Czasem po takiej analizie okazuje się, że rozwiązanie jest prostsze niż się wydawało i jesteśmy w stanie podać niższą cenę, mając pewność, że Klient wyda tylko tyle pieniędzy, ile to konieczne. Czasem przeciwnie – widzimy, że realizacja projektu wymaga, aby wziąć pod uwagę dodatkowe rzeczy, niewidoczne z perspektywy Klienta, a jednak niezbędne, aby system działał wg oczekiwań – dodatkowy serwer, migracja danych, architektura zapewniająca niższe koszty utrzymania systemu w przyszłości itd.

Idealnie, gdy jesteśmy w stanie po wycenie zdefiniować konkretne zadania oraz ścieżkę krytyczną. Wtedy wystarczy po prostu zrobić to co zostało wycenione i gotowe. W życiu przeważnie tak nie jest. Zmiana wymagań, czy generalnie: zmiana, jest jedyną stałą w projekcie. Sztuka estymowania polega na jak najbardziej elastycznym podejściu, przewidującym potencjalne scenariusze. Oczywiście przewidzieć wszystkiego się nie da i w tym cały urok biznesu.