4 Mity Wyceniania Projektów IT

Przedstawię ci cztery główne mity, które funkcjonują w świecie wycen projektów IT. Niektóre z nich są dość „kontrowersyjne”, więc mam nadzieję, że „ortodoksyjni wyjadacze” mnie nie zjedzą.

MIT 1: Wycenisz projekt z dokładnością do 100.00%

Wycena projektów to przepowiadanie przyszłości. Dlatego jest to takie trudne.

Uważam, że powinniśmy mieć nastawienie do wycen, nie żeby wycenić z dokładnością do 100.00%, ale żeby próbować pomylić się jak najmniej.

Życie pisze takie scenariusze, że nawet najdokładniejsza analiza przedwykonawcza nie jest w stanie przewidzieć każdego przypadku.

Oczywiście nie mam na myśli tego, że wycena powinna być „strzałem”. Powinniśmy bardziej rozpatrywać to jak rachunek prawdopodobieństwa.

Naszą wyceną powinien być ten wariant, który wydaje nam się najbardziej prawdopodobny.

Powinniśmy więc nauczyć się zarządzać zmianą w zakresie. Bo jesteśmy ludźmi i się mylimy. Klient może przekazać błędne wymagania, my możemy je błędnie opisać lub mogą okazać się niemożliwe podczas realizacji.

Są to rzeczy, które ciężko przewidzieć – może też zmienić się sytuacja na rynku i produkt będzie trzeba dostosować pod aktualne realia. Przykłady można mnożyć.

Najważniejsze z czym chcę cię zostawić to żebyś nie próbował wycenić projektu z dokładnością do 100.00% bo to nie możliwe. Radzę ci żebyś miał założenie, że powinieneś pomylić się jak najmniej.

Bo to, że czegoś nie przewidzisz jest prawie pewne. Nie ma sensu zakładać pewności na niepewność i łudzić się, że wszystkie elementy wyceniliśmy idealnie.

MIT 2: Zawsze trzeba wyceniać dokładnie

Wycena jest bardzo pracochłonna. Musimy dowiedzieć się od klienta jakie są wymagania, zbudować z nich wstępne rozwiązanie. Kolejnie przedyskutować je z zespołem technicznym.

Później następują dyskusje „sprzedażowo/biznesowe” – jaka marża, jaki bufor, jakie terminy realizacji.

To wszystko generuje dziesiątki godzin spotkań i rozmów. Stwierdzam więc bez wątpienia, że wycenianie jest drogie.

Czym bardziej chcemy żeby nasza wycena była dokładna, tym więcej musimy poświęcić na nią czasu. Truizm.

Podzielę się z tobą historią, która wyjaśni ci co dokładnie mam na myśli.

Bywały okresy, gdzie dostawaliśmy bardzo dużo zgłoszeń o nowe współpracę, które wymagały od zespołu wyceny projektu.

Średni czas jaki potrzebowaliśmy na wycenę był różny od 2 rbh – 16 rbh. Łatwo policzyć, że przy 2-3 zapytaniach tygodniowo wycenianie zajmowało pełne obłożenie etatowe pracownika. (Robię tu skrót myślowy, bo nie wyceniała projektu wyłącznie jedna osoba i natężenie zapytań bywało różne).

Mimo, że mieliśmy dużo zapytań i poświęcaliśmy dużo czasu na wyceny… to nie przekładało się to na liczbę realizowanych projektów.

Po pewnym czasie zacząłem dociekać dlaczego tak się dzieje i pytałem klientów o feedback.

Część z nich chciała tylko poznać „widełki”, nie była zdecydowana na realizację, a inni twierdzili, że nasze wyceny są bardziej pracochłonne o około 20-30% względem konkurencji.

Poszedłem o krok dalej i przeanalizowałem sytuację. Wniosek był taki, że przez to, że poświęcaliśmy dużo czasu na wyceny były one dokładniejsze bo przewidywaliśmy elementy, których nie przewidywały inne firmy.

Te „nieprzewidziane” elementy podnosiły pracochłonność. Jednak nie każdy klient zdawał sobie sprawę z jakości analizy, którą dawaliśmy „gratis”. Ważniejsze dla niego było to, że inna firma dała mniejszą wycenę.

Wciąż u klientów, którzy nie są „IT” jest niska świadomość. Uważają, że zespół to zespół i każda firma dostarcza taką samą jakość więc jedyny czynnik jakim się kierują jest finalna cena. Nie zdają sobie sprawy w jakim wielkim błędzie tkwią.

Firmy, które tego nie uwzględniły… i tak musiały później ponieść „koszt” nieprzewidzianych rzeczy podczas realizacji. Różnicą było to, że my przewidzieliśmy te elementy i mieliśmy je zabudżetowane, inne firmy żyły w „błogiej nieświadomości” co ich czeka.

Kończyło się to różnie. Czasami firmy rezygnowały w trakcie realizacji bo koszt ich przerósł (niedokładna wycena). Innym razem schodzili z jakości, żeby ukończyć większy zakres za pierwotnie ustalony budżet.

To na co chcę zwrócić twoją uwagę to to, że nie zawsze warto wyceniać dokładnie. Ja wychodzę z założenia, że trzeba wyceniać na tyle dokładnie na ile prawdopodobne jest, że będziesz realizować dany projekt.

Trzeba to ubrać odpowiednio komunikacyjnie z klientem, żeby wiedział, że nasze wyceny są szacunkowe (w przypadku gdy jest małe prawdopodobieństwo realizacji). To o ile „smaczna” jest różnica pomiędzy wyceną szacunkową, a finalną już poruszałem na blogu.

MIT 3: Klient wie czego chce

To co często słyszę to, że osoby wyceniające bezkrytycznie przyjmują to co mówi im klient. Twierdzą, że klient w 100% wie czego chce.

Objawia się to tym, że zamiast analizować to co mówi klient pod kątem możliwości wykonania i logiczności procesu… zapisują co usłyszą i starają się to bezkwestionowania wycenić.

Kończy się to tym, że później powstają aplikacje-gnioty, lub zespół grzebie się w morzu poprawek.

Dzieje się tak, ponieważ klient nie jest analitykiem. On mówi to co wydaje mu się, że jest poprawne. Niekoniecznie to co jest słuszne/potrzebne/poprawne.

Ma w pełni do tego prawo – bo to zespół realizacyjny jest specjalistami, którzy powinni mu powiedzieć gdy zaczyna „odlatywać”.

Dlatego to co mówi klient, trzeba przepuszczać przez sito. Klient nie wie czego chce, ale doskonale wie czego nie chce.

Problem jest taki, że zgłosi nam czego nie chce gdy zobaczy co zrobiliśmy. Wtedy zazwyczaj posypią się uwagi w stylu:

• to myślałem, że zrobicie inaczej. Chodziło mi o coś takiego…
• to w sumie powinno działać inaczej, bo pracownicy najpierw robią XYZ – możemy to zamienić?

itp itd. Mam nadzieję, że wiesz co mam na myśli.

Mechanizm tego zjawiska opisałem dokładniej w wpisie z pewną historią z analizy przedwykonawczej. Polecam ci rzucić okiem.

Nie możesz bezkrytycznie przyjmować to co mówi ci klient. Zawsze należy przesiać to przez sito logiczno-funkcjonalne. Klient rzadko kiedy wie czego chce. W większości przypadków wie czego nie chce i mówi nam o tym gdy zobaczy to, co zrobiliśmy. Rodzi to wtedy niepotrzebne dyskusje kto i dlaczego ma zapłacić za zmiany.

Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯

MIT 4: Projekt się opóźnił bo daliśmy zbyt mało czasu

Słyszałeś powiedzenie, że „spóźniłem się bo miałem za dużo czasu„? No właśnie.

Moim zdaniem główną przyczyną tego, że wyceny są niedokładne nie jest to, że daliśmy zbyt mało czasu na poszczególne zadania.

Przyczyną jest to, że musieliśmy zrealizować zadania, których nie przewidzieliśmy na etapie wyceny. Z mojego doświadczenia wynika, że to właśnie jest największym zabójcą harmonogramów i budżetów.

To, że większy czas na realizację wcale nie podnosi „poziomu bezpieczeństwa” już opisywałem na blogu. Chodzi o prawo studenta i prawo Parkinsona. Szerzej wyjaśniałem to zjawisko w wpisach z serii Dlaczego twój projekt się opóźnił? – polecam ci rzucić okiem.

Dlatego twierdzę, że często (bo nie zawsze) większe wyceny zadań nie pomagają kończyć ich w terminie. Uważam również, że bardziej niebezpieczne dla twojego projektu są rzeczy, których nie przewidziałeś na etapie wyceny, niż te, które wyceniłeś niedokładnie.

Podsumowanie

Nie jesteś w stanie wycenić projektu z dokładnością do 100.00%. Klient, ty i zespół jesteście tylko ludźmi, którzy popełniają błędy. Nie da się przewidzieć wszystkiego. Potraktuj wycenianie jako rachunek prawdopodobieństwa. Staraj się pomylić jak najmniej. Twója wycena powinna wynosić tyle, ile wydaje ci się najbardziej prawdopodobne, że wyniesie pracochłonność projektu.

Nie zawsze staraj się wyceniać dokładnie. Często klient chce jedynie zrobić rozeznanie na rynku ofert. Wyceniaj tak dokładnie, na ile jest prawdopodobne, że będziesz dany projekt realizował. Nie ma nic złego w wycenianiu „niedokładnym” – musisz pamiętać, że trzeba to odpowiednio rozegrać komunikacyjnie z klientem. Mam tu na myśli wycenę szacunkową i wiążącą.

Klient w większości przypadków nie wie czego chce. To co od niego usłyszysz jest myśleniem życzeniowym. Powinieneś przesiać to przez swoje sito doświadczenia zawodowego. Klient często wie czego nie chce, ale dowiesz się o tym dopiero wtedy gdy pokażesz mu co zrobiłeś. Dlatego warto makietować, budować wstępne rozwiązania i dyskutować je z klientem. Taniej jest coś zmienić na papierze niż przebudować aplikację.

Jeśli uważasz, że podniesienie wyceny x2, x3 rozwiąże problem niedowiezionych projektów to jesteś w błędzie. Z mojego doświadczenia wynika, że nawet gdy projekt się opóźnia, to mieliśmy wystarczająco czasu na jego realizację. Problemem jest to, że wykorzystywaliśmy go (czas) nieproduktywnie, robiliśmy niektóre feature, które okazały się nieprzydatne bo klientowi zmieniła się koncepcja. Twierdzę, że zwiększenie czasu w większości przypadków nie rozwiąże problemu opóźnionych projektów. Może go natomiast rozwiązać dokładna analiza przedwykonawcza.