Dlaczego dwa software house’y potrafią wycenić ten sam projekt IT z różnicą nawet 100 tysięcy złotych?
W tym odcinku wyjaśniamy, co naprawdę wpływa na koszt i termin realizacji projektu i dlaczego sama specyfikacja nie wystarczy, by przygotować rzetelną wycenę.
Grzegorz Tabor dzieli się praktycznym doświadczeniem z wielu wdrożeń IT i pokazuje cztery kluczowe obszary, które decydują o tym, czy budżet zostanie utrzymany, czy przekroczony już w połowie prac. Wyjaśnia model rozliczeń (Time & Material vs Fixed Price), w znaczeniu analizy procesów biznesowych, składzie zespołu i realnym podejściu do priorytetów. Ten odcinek pomoże Ci zrozumieć, jak patrzeć na oferty software house’ów oczami CTO, zanim podejmiesz kosztowną decyzję.
Porozmawiajmy, jak to zweryfikować.
PorozmawiajmyDlaczego dwa software house'y mogą wycenić ten sam projekt IT z różnicą nawet 100 tysięcy złotych? Albo obiecać realizację w 3 miesiące, gdy w praktyce zajmie to co najmniej rok? Pokażę Ci dziś 4 nieoczywiste rzeczy prosto z mojego doświadczenia, które mają ogromny wpływ zarówno na koszt jak i na termin i o których rzadko się mówi wprost podczas etapu wyceny. A jeśli interesują Cię takie tematy, koniecznie zasubskrybuj nasz kanał, żeby nie przegapić kolejnych odcinków. Cześć, dzień dobry.
Witam Cię serdecznie na kanale IT i Biznes, w którym dzielę się historiami, doświadczeniami i wskazówkami, które pokazują jak technologia naprawdę działa w biznesie. Wyobraź sobie, że masz na biurku 3 oferty. Każda jest od innego software house'u. I teraz pytanie, w jaki sposób je porównać? I w ogóle, co wziąć pod uwagę, żeby je porównać?
Pierwsza, podstawowa kwestia, na którą najprawdopodobniej zwrócisz uwagę, to sposób rozliczenia. Software house'y stosują z reguły 2 najpopularniejsze modele.
Pierwszy z nich, czyli time and material, to model, w ramach którego rozliczamy się za przepracowane godziny.
Drugi, fixed price, to model, w ramach którego firma deklaruje to, że przygotuje pełny zakres projektu i według tego zakresu podaje ci wycenę. Już nazwijmy to wycenę końcową. Na pierwszy rzut oka wygląda to jak proste porównanie. Mamy jedną wycenę, mamy drugą i trzeba zwyczajnie porównać ceny. Natomiast w praktyce okazuje się, że to dopiero początek pytań.
Prawdziwy koszt zależy od tego, jak projekt będzie się zmieniał w trakcie realizacji. A nie ma co się oszukiwać. W średnich i dużych projektach IT zmiany zawsze będą. I tu dochodzimy do sedna. Jak przewidzieć przyszłość? Jak przewidzieć, czy wycena, którą otrzymałeś, ma cokolwiek wspólnego z finalnym kosztem projektu? Jak przewidzieć, czy wycena, którą otrzymałeś, ma cokolwiek wspólnego z tym, co otrzymasz na końcu, z finalnym kosztem projektu?
Proces przygotowania ofert to według mnie kluczowy punkt, który znacząco wpływa na to, czy wycena, którą otrzymaliśmy na początku, będzie faktycznym kosztem, w którym nasz projekt IT zostanie zrealizowany. 80% zapytań, które do nas wpada, wygląda w bardzo podobny sposób. Witam, jesteśmy firmą X, planujemy wdrożyć system Y. W załączeniu przesyłamy specyfikację, prosimy o wycenę. I teraz co robią firmy? Software House z reguły dzwoni, dopytuje o kilka rzeczy, o wielkość firmy, o liczbę użytkowników, jakie systemy już są w firmie, w jakiej technologii zostały napisane. I to są oczywiście sensowne pytania. Ale czy wystarczą, żeby wycenić projekt rzetelnie? Z mojej perspektywy i doświadczenia, absolutnie nie.
Wycena samej specyfikacji, którą otrzymamy od klienta, to oczywiście jedna z rzeczy. Ale jeśli w specyfikacji pominiemy integrację z innymi systemami, nie zmapujemy kluczowych procesów, które w firmie się dzieją, nie zastanowimy się, które z tych procesów działają dobrze, a które już na etapie procesów trzeba zmienić, to i tak to wyjdzie, tylko, że w trakcie realizacji. I to właśnie wtedy okazuje się, że projekt, który miał kosztować te tytułowe 100 tysięcy, finalnie kosztuje 200.
Proces przygotowania oferty, to jak planowanie podróży. Z Wrocławia do Gdańska samochodem dojedziesz w 5 godzin. Rowerem? No, już zmienia się to. Co najmniej w kilkanaście. A jeśli planujesz przystanki po drodze, to potrwa to oczywiście jeszcze dłużej. I tak samo jest z projektami IT. Jeśli nie uwzględnisz wszystkich przystanków i nie wybierzesz właściwego środka transportu, to prognoza czasu i kosztów będzie kompletnie nietrafiona. Im większy projekt realizujemy, tym dokładniejsza powinna być ta praca planowania podróży, czyli ta praca przed wyceną.
Druga kwestia, to dobór technologii i koncepcji projektu. W IT jest tak, że do jednego problemu biznesowego można podejść na wiele różnych sposobów. Można na przykład wykorzystać oprogramowanie tak zwane SaaSowe, czyli dostępne w formie abonamentowej. Można wykorzystać oprogramowanie open source'owe. Można też napisać oprogramowanie dedykowane zupełnie od podstaw. Co ciekawe, można też w ramach czwartej koncepcji w jakiś sposób połączyć te różne oprogramowania ze sobą, tworząc jeden spójny system składający się właśnie z kilku różnych klocków. I teraz każdy z tych wariantów oczywiście ma swoje plusy i minusy i zupełnie inne koszty początkowe oraz te długoterminowe.
Weźmy sobie na przykład platformę B2B, która w modelu SaaS będzie na start znacznie tańsza niż budowa dedykowanego systemu. Ale jeśli w twoim biznesie często wprowadzasz zmiany, to szybko zauważysz, że każda modyfikacja jest kosztowna i ograniczona. Dużo trudniejsza do wdrożenia niż w przypadku rozwiązań otwartych, tak zwanych open source'owych, czy dedykowanych, napisanych w 100% pod ciebie. Więc koniec końców trzeba brać pod uwagę nie tylko samą cenę, ale przede wszystkim to, z jaką koncepcją przychodzi dany software house. Z jakim rozwiązaniem na twój problem biznesowy. I porównanie oferty także na poziomie tego, jakie mają wady i zalety owe koncepcje. Bo nie chodzi tu tylko o koszty takie tu i teraz, czyli te bieżące i samo powiedzmy wdrożenie, tylko ważne są też koszty w perspektywie dwóch, trzech lat, czyli już od etapu tego wdrożenia. I to, co wydaje się na początku tańsze, w długim terminie może okazać się znacznie droższe, przez ograniczenia, różne trudne modyfikacje, czy konieczność zwyczajnej późniejszej migracji z tej platformy, którą mamy, na jakąś nową w przyszłości.
Kolejna sprawa i stosunkowo często niebrana pod uwagę to skład zespołu. Często software house'y pokazują różne case study, które są bardzo podobne do projektu, który chcesz zrealizować. I od razu pojawia się myśl, skoro dany software house zrobił to już wcześniej, to u nas przecież też dadzą radę. Ale i tu należy zadać kilka dodatkowych pytań. Po pierwsze, czy osoby, które realizowały ten konkretny projekt będą też w twoim zespole? Case study tego niestety nie gwarantuje.
Po drugie, kto będzie dokładnie w twoim zespole? Czy będą to tylko programiści, czy także testerzy i być może project manager? Dlaczego wspominam o tych dwóch konkretnych rolach? Bo one bardzo mocno wpływają na wycenę. Jeżeli nie ma tych osób, nie ma tego project managera czy testera, oferta zwyczajnie będzie tańsza, cena będzie niższa. Ale brak tych osób w projekcie oznacza zwyczajne kłopoty. Mogą pojawić się problemy komunikacyjne. Zadania mogą wracać z błędami, bo nikt ich nie przetestował. I wtedy o ten proces jakości i organizację projektu te obowiązki będą spadały na ciebie, klienta. Tyle, że ty masz milion innych spraw na głowie i IT jest tylko jednym z wielu wątków. Więc to na to bym tutaj zwrócił uwagę, jeżeli chodzi o kwestię zespołu.
Czwarta kwestia to podejście do priorytetów i zakresu projektu. Czy ktoś doradza wam konkretne priorytety realizacji zadań i ograniczenie zakresu prac na start? Tak, żeby jak najszybciej zweryfikować z rynkiem, z użytkownikami końcowymi, czy też zespołem, który faktycznie będzie z tego rozwiązania korzystał. Bardzo często na etapie wycen zakres jest sztucznie podbijany. No bo umówmy się, im większy zakres, który jest zlecony na raz, tym większy projekt, no i wyższa też wycena jego realizacji. Natomiast w IT najlepsze projekty realizuje się małymi krokami. Krok po kroku, etapami. Jeżeli ktoś na etapie wyceny nie przewiduje tego, że można by zrobić najpierw jakąś rzecz A, potem zrobić rzecz B, a potem rzecz C i wdrażać je też w takiej kolejności produkcyjnie, no to myślę, że też zastanowiłbym się nad tym, czy to na pewno będzie najlepsza oferta. I wycena projektu na podstawie samej specyfikacji nigdy nie będzie rzetelna, jeśli nie weźmie się pod uwagę tych czterech dodatkowych czynników. Dobra wycena wcale nie jest prosta. Czasem trzeba przeprowadzić kilka solidnych rozmów, a czasem nawet pojechać do firmy i sprawdzić jak coś wygląda w praktyce, żeby podać rzetelną kwotę i rzetelny szacunek czasowy, czyli tym lepiej tą przyszłość przewidzieć. I dlatego upewnij się, że rozmawiasz z dostawcą o ryzykach i etapach projektu, a nie tylko o końcowej cenie czy samej specyfikacji.
A jeśli współpracowałeś lub wdrażałeś projekt IT w swojej firmie, koniecznie daj znać, czy zakończył się w zakładanym budżecie i w zakładanym czasie, czy jednak zostały one przekroczone. I nie zapomnij zasubskrybować ten kanał, bo słyszymy się w kolejnym odcinku już za tydzień.


Dołącz do newslettera i otrzymuj regularne porcje wiedzy o technologii, biznesie i strategiach, które pomogą Ci rozwijać firmę. Zero spamu – tylko konkretne wskazówki, inspiracje i nowości z podcastu.