Szacowanie kosztów realizacji projektów informatycznych. Skąd się biorą wyceny?

Spotify

Apple Podcasts

RSS Feed

Youtube

Uczestnicy

Piotr Lewandowski

CEO ImpiCode

Grzegorz Papaj

VP of Business ImpiCode

Opis odcinka

W dzisiejszym podcaście zapraszamy Cię do głębszego zrozumienia procesu szacowania kosztów w projektach informatycznych. Temat ten budzi wiele pytań, my zaś przedstawimy Ci perspektywę firmy programistycznej. Wyjaśnimy, skąd się biorą kwoty podawane w wycenie.

Przedstawiamy, skąd się biorą nawet 3-krotne różnice w wycenie. I że tak naprawdę każda firma może wyceniać inny projekt na podstawie tej samej specyfikacji.

Jak wybrać najlepszą opcję gdy staniemy przed wyborem gotowego rozwiązanie „z pudełka” a dedykowany projekt „pod klucz”? Przedstawiamy korzyści i pułapki związane z obiema ścieżkami.

Wyjaśniamy wpływ rozmiaru firmy klienta na wycenę. Dlaczego ten sam system dla firmy z 50 pracownikami kosztuje mniej niż dla firmy z 1000 pracownikami?

Wyjaśniamy również jak najlepiej wyjść z sytuacji gdy wycena zawiodła, a koszty projektu mogą znacząco przekroczyć oczekiwania.

POZOSTAŁE ODCINKI

Transkrypcja

[ 00:00:34] Piotr Lewandowski: Dzień dobry, Nazywam się Piotr Lewandowski, jestem CEO w ImpiCode. Moim gościem jest Grzegorz Papaj, nasz Vice President of Business. Witamy w kolejnym odcinku podcastu. Dzisiaj naszym tematem będzie: szacowanie kosztów realizacji projektów informatycznych.

[ 00:00:55] Temat dosyć gorący i emocjonujący, więc może zaczniemy sobie od najmniej zaskakujących spostrzeżeń. Jestem klientem. Zgłaszam się do kilku firm informatycznych, które znalazłem w Internecie. Proszę o wycenę. Wysyłam im specyfikację, którą przygotowałem, może odbyłem z nimi kilka rozmów, zlatują mi te wszystkie wyceny na maila. Otwieram.

[ 00:01:24] I pierwszy szok polega na tym, że tam jest wszystko, tzn. są wyceny, które opiewają na 5, 50 tysięcy złotych, pół miliona, 5 milionów, może nawet 10 milionów. A to wszystko na podstawie jednej i tej samej specyfikacji.

[ 00:01:41] Co się tu właściwie stało? Jak to interpretować?

[ 00:01:44] Grzegorz Papaj: W zasadzie jest to bardzo proste. Specyfikacja nie mówi wszystkiego o produkcie. I do tego się ten problem sprowadza.

[ 00:01:57] Można by to przez analogię przedstawić jako, zapotrzebowanie na samochód. Klient pisze: potrzebuję samochodu, ma mieć 4 koła, kierownicę, silnik, w środku, cztery fotele, może bagażnik na dachu, bo mam tu specjalne potrzeby. Jak takie zapytanie pójdzie do dystrybutora Opla. To dystrybutor Opla znajdzie coś w ofercie Opla. Jak to pójdzie do dystrybutora Ferrari, to dystrybutor Ferrari znajdzie coś w ofercie Ferrari. Jeszcze jeżeli się okaże, że kluczowy jest bagażnik na dachu, no to pewnie jest to customowe Ferrari, w tym wypadku.

[ 00:02:41] Czyli każda firma, która przedstawia swoją ofertę, tak naprawdę może podać dobrą wycenę. Natomiast myśląc o czymś zupełnie innym.

[ 00:02:55] Kluczowy problem jest taki, o czym myśli klient? Dlatego z reguły dobrze jest nie tylko bazować na dokumencie, ale też z klientem porozmawiać i ustalić, o co właściwie chodzi.

[ 00:03:14] Sam dokument stanowi bardzo, pobieżny zarys i nie mówi wszystkiego o problemie, który system ma rozwiązywać.

[ 00:03:24] Tak, oczywiście. Zdarzają się skrajne przypadki. Bardzo często się zdarza, że freelancerzy czy firmy z mniejszym doświadczeniem wyceniają coś na zasadzie: o, to największy projekt, jaki nam się zdarzyło robić, to musimy go wycenić najdrożej. I tutaj pada jakaś kwota, która jest np. dwukrotność największego dotychczasowego projektu realizowanego przez daną firmę. I zwykle jest tak, że te kwoty są mocno niedoszacowane, bo tego rodzaju firmy czy osoby wcześniej się nie spotkały z tak dużym systemem, który jest do zrealizowania. W związku z tym nawet nie wiedzą do końca, co szacują. Więc doświadczenie oczywiście też ma znaczenie w tym wszystkim.

[ 00:04:12] Natomiast tutaj wracając do sedna. Każdy dostawca oprogramowania dedykowanego coś sobie przelicza, na bazie własnych doświadczeń i też tego zakresu działań, który jest dla niego najbliższy i na tej podstawie podaje szacowanie.

[ 00:04:30] Jeżeli na przykład rozmawiamy z firmą, która chce zrobić e-commerce, jakiś system sklepowy. Jeżeli trafimy z szacowaniem do firmy, która po prostu zajmuje się wyłącznie customizacją jakiegoś gotowego rozwiązania e-commerce owego, to ona po prostu poda jakąś wycenę, bazując na swoich doświadczeniach, na wdrożeniu jakiegoś gotowego silnika.

[ 00:04:55] Jednocześnie jeżeli pójdziemy do firmy, która takich rozwiązań nie oferuje, taka firma automatycznie odczyta, że my chcemy zrobić całkiem nowy, customowe silnik sklepowy, który ma cały szereg funkcjonalności, normalnie rozwiązywanych przez jakiś framework i w związku z tym wycena będzie automatycznie odpowiednio wyższa.

[ 00:05:16] Piotr Lewandowski: Jak do tego podejść? To co ja powinienem chcieć tę wtyczkę, tańszą? Czy ten system zbudowany od podstaw, droższy?

[ 00:05:27] Grzegorz Papaj: To już zależy od sytuacji. To znów, jest kwestia gdzie jesteś ze swoim biznesem, czy np. już wiesz, że masz jakieś indywidualne potrzeby, gotowe rozwiązanie, bo np. już jakieś gotowe rozwiązanie wdrożyłeś, bądź używałeś kilka lat i znasz jego ograniczenia.

[ 00:05:48] Przejrzałeś rynek i wiesz, że nie ma rozwiązań, które by Cię w stu procentach satysfakcjonowały? W takiej sytuacji na pewno dobrze jest myśleć o rozwiązaniu dedykowanym, jeśli oczywiście masz na to budżet.

[ 00:06:03] Jeśli nigdy nie miałeś do czynienia z oprogramowaniem danej klasy, to najczęściej najlepszą opcją jest zacząć od czegoś gotowego, co jest na rynku. Chociażby po to, żeby się nauczyć, jak pewne procesy są realizowane przez oprogramowanie.

[ 00:06:20] Piotr Lewandowski: Generalnie sprawa może być złożona i jeszcze związana z tym, że jest za mało kontekstu od klienta, żeby stwierdzić, w jakie rozwiązanie podążać.

[ 00:06:31] I też nasz głos jako klienta jest tu bardzo ważny. Żeby określić, które z tych rozwiązań jest dobrym kierunkiem.

[ 00:06:41] Grzegorz Papaj: Jest jeszcze jeden aspekt. Jeżeli nasz klient pójdzie do dwóch dostawców, z których pierwszy zasadniczo robi rozwiązanie jakiejś klasy dla małych i średnich przedsiębiorstw, drugi zaś rozwiązania podobne, ale dla korporacji, to obaj dostawcy mają różną perspektywę.

[ 00:07:02] Jeden robi rozwiązania na kilkanaście kilkadziesiąt osób.

[ 00:07:06] Drugi robi systemy, gdzie takim dolnym limitem jest 1000 użytkowników. I w momencie, kiedy rozmawiamy o rozwiązaniach na 1000 użytkowników, mierzymy się z zupełnie inną klasą problemów. Plus oczywiście całą masą otoczki. Poza systemowej, związanej z działaniem korporacji, z integracjami, dostosowaniem do standardów korporacyjnych.

[ 00:07:30] Tak więc dostawca dla małych i średnich firm, a dostawca dla korporacji mogą mieć zupełnie inną optykę i automatycznie zakładać, że skoro do nich przyszedłeś, to potrzebujesz rozwiązania takiej klasy, jakiej oni dostarczają.

[ 00:07:42] Czyli to może być bardzo duża rozbieżność, nawet 10 krotność chociażby, bo system do zarządzania urlopami dla firmy na 50 osób i na 5000 osób to jest zupełnie inna historia.

[ 00:07:56] Piotr Lewandowski: Tutaj wychodzą nam jeszcze dwa dodatkowe aspekty. Pierwszy to rozmiar i skalowalność aplikacji. Aplikacja przeznaczona dla 50 osób będzie mniej skalowalna niż aplikacja przystosowana do używania przez 5 tysięcy albo 50 tys. osób.

[ 00:08:14] Drugi aspekt, który tutaj mówisz to to, że jeżeli naszym klientem będzie korporacja, to z automatu liczymy się z jakąś ilością integracji z ich warstwą IT. I to też zmienia skalę problemu i rozmiar wdrożenia, koszty i integracje dostosowanie do pewnych standardów.

[ 00:08:35] Grzegorz Papaj: Korporacje mają swoje działy zgodności, takie czy inne działy bezpieczeństwa. To jest tak, że pracując z korporacją trzeba się liczyć z tym, że nagle wpadnie jakiś człowiek z jakiegoś działu i powie: teraz musimy najpierw załatwić nasze sprawy, zanim zaczniemy w ogóle myśleć o wdrożeniu tego systemu i upewnić się, że to, co proponujecie, jest zgodne z naszą polityką.

[ 00:09:03] I ta polityka czasem jest jasna, czasem jest mniej jasna, a czasem jest tak, że wdrożenie korporacyjne dla polskiego oddziału międzynarodowej korporacji jest dużo trudniejsze, bo oni sami muszą się dogadywać z centralą zagraniczną, która ma swoje widzimisię, czasem nie odpowiadające realiom polskim.

[ 00:09:22] Także skala klienta jest bardzo istotna w tym momencie. Tak odwracając trochę ten temat, skala zwykle realizowanych rozwiązań przez danego dostawcę, ma odzwierciedlenie w tym, jakie on po cichu sobie założenia czyni, przygotowując ofertę.

[ 00:09:47] Piotr Lewandowski: Czyli można spokojnie założyć, że firma, która buduje rozwiązania dla małych firm, jak się zderzy nagle z taką 500, 1000 osobową firmą, będzie próbowała dla niej zaprojektować system, szansa na to, że przestrzeli jest dosyć spora.

[ 00:10:04] Grzegorz Papaj: Tak. Jednocześnie firma, która zwykle robi wdrożenia dla korporacji. Jeżeli przyjdzie do niej osoba z małej firmy, poda wycenę, która wydaje się być kosmiczna, co czasem jest po prostu grzecznym powiedzeniem nie jesteście klientem dla nas.

[ 00:10:23] Co oczywiście nie jest nie realistyczną wyceną, ale po prostu odzwierciedla też sposób działania danego dostawcy z typowym klientem. W korporacjach niestety są bardzo duże narzuty związane z domykaniem tych wszystkich kwestii i formalnych i technicznych po to, żeby wejść z jakimś produktem, uruchomić go w infrastrukturze, w dużej organizacji.

[ 00:10:49] Piotr Lewandowski: I to wszystko w jakiś sposób jest wliczone w to szacowanie, w tę wycenę.

[ 00:10:56] Grzegorz Papaj: Przy czym zwykle to nie jest też tak, że tutaj są bardzo duże rozbieżności w tych oszacowaniach, nasi klienci czasem nam podają jakieś przykłady, czasem się dowiadujemy, że tutaj jest dwa albo trzy razy oferta tańsza od tej najdroższej.

[ 00:11:15] Rzadko kiedy te widełki są większe. No chyba, że temat trafia do jakiegoś freelancera. Freelancerzy często w ogóle nie rozumieją skali projektów, z którymi się mierzą. Właśnie z tymi nawet poza technicznymi aspektami, które też mają istotny wpływ na czasochłonność realizacji projektu.

[ 00:11:35] Piotr Lewandowski: OK, czyli tak jak w skokach narciarskich, najlepiej tych najbardziej skrajnych opinii nie brać pod uwagę.

[ 00:11:42] Grzegorz Papaj: Zwykle tak, ale tutaj ponownie, żeby wycena była miarodajna, na pewno nie można się opierać tylko na dokumentach i tylko na specyfikacji.

[ 00:11:51] To też jest warte podkreślenia, bo czasem mamy klientów, którzy podchodzą do tematu tak: teraz rozsyłamy zapytania ofertowe do 10 firm. Nie chcemy z nikim rozmawiać, bo każdy ma mieć równe szanse. Wyślijcie nam wycenę. Wszyscy wysyłają wycenę, bazując na tym samym.

[ 00:12:10] I tak jak mówiłem na początku. To nie jest dobre podejście, bo dokument jak by szczegółowy nie był nie jest nigdy kompletnym opisem systemu. I to jest jedno ze źródeł rozbieżności w wycenach. Brak właściwego zrozumienia problemu.

[ 00:12:27] Jeżeli nie ma tego właściwego zrozumienia to każdy zgaduje w mniejszym lub większym stopniu, domniemywa. Czego właściwie klient oczekuje?

[ 00:12:38] Piotr Lewandowski: OK. Kolejny temat już związany z zespołem wewnętrznym klienta. Są takie sytuacje, że klient ma wewnętrzny zespół. Ten wewnętrzny zespół albo jest obciążony, albo nie do końca ma kompetencje w jakimś obszarze, albo jeszcze jest jakiś inny powód i jakąś funkcjonalność, albo jakiś system chcemy zbudować na zewnątrz, używając zewnętrznej firmy.

[ 00:13:06] Wysyłamy wycenę do takiej zewnętrznej firmy. Porównujemy to z wyceną naszego zespołu. No i te wyceny się różnią. Podejrzewam że najczęściej będą się różniły.

[ 00:13:20] Jak taki fakt zinterpretować? Jak do takiego problemu podejść?

[ 00:13:26] Grzegorz Papaj: Rozumiem, że tutaj mówimy nie tyle o wycenie, co bardziej o ocenie czasochłonność realizacji, co ma bezpośrednie przełożenie na wycenę w którymś momencie. Natomiast wewnętrzny zespół raczej nie podaje kosztów, tylko podaje czas realizacji.

[ 00:13:39] Z czego to wynika? Przede wszystkim z tego, że wewnętrzny zespół z reguły zdecydowanie lepiej niż dostawca wie, co jest do zrobienia.

[ 00:13:48] To może powodować odchylenia w obie strony. Jeżeli spytamy zespół wewnętrzny, ile by kosztowało zrobienie modułu X do naszej aplikacji, to oni będą w stanie podać jakieś oszacowanie, które pewnie będzie w większości przypadków zdecydowanie niższe niż powie to samo dostawca z rynku. Bo dostawca z rynku musi brać pod uwagę to, że jakiś czas musi poświęcić na wejście w istniejący system.

[ 00:14:16] I to system nie tylko od strony technicznej, ale też właśnie od strony biznesowej. Na zrozumienie, co ma dana funkcjonalność realizować i jak ma funkcjonować w otoczeniu biznesowym.

[ 00:14:29] Również na zrozumieniu samego kodu, z który trzeba pracować. Standardów przyjętych w danej firmie. To wszystko to są pewne narzuty, które trzeba brać pod uwagę przy takim oszacowaniu kosztów.

[ 00:14:44] Może się też zdarzyć, że zewnętrzny dostawca oszacuje coś powiedzmy na miesiąc, a własny zespół szacuje, że to jest minimum 3 miesiące i nie ma opcji, żeby zrobić to szybciej. To też jest jak najbardziej możliwe. Zwykle oznacza to tyle, że zewnętrzny dostawca nie do końca jest świadomy, z czym się mierzy.

[ 00:15:09] Czyli może się okazać, że system jest bardziej złożony niż to zostało przedstawione. Czy problem jest bardziej złożony, niż to zostało przedstawione? Albo dostawca wie na przykład, że ten system, z którym przyjdzie pracować, jest w rozsypce, fatalnej jakości. Gdzie się coś nie ruszy, to się zawsze coś psuje. Więc dodanie nowej funkcjonalności to nie będzie tydzień na jedną nową funkcjonalność. To nie będzie tydzień, a miesiąc, bo przez tydzień się zrobi, a potem przez kolejne trzy tygodnie naprawia to, co się przy okazji zepsuło.

[ 00:15:39] Więc na pewno można tutaj bazować w jakimś stopniu na wycenie zespołu wewnętrznego. Zakładamy, że jest rzetelny, solidny i potrafi to oszacować dobrze. Natomiast nie ma co się dziwić, że zewnętrzny dostawca przedstawia koszty nieco wyższe, bo musi uwzględnić ten bufor na wejście w projekt.

[ 00:16:03] Piotr Lewandowski: W temacie wycen widełkowych często jest tak, że dostajemy wycenę i ona opiewa na jakiś zakres, czyli np. od 150 do 200 tys. zł bez podania konkretnej kwoty. Od czego zależy dokładność takiego szacowania?

[ 00:16:22] Czy możemy to jakoś zawęzić? Czy musimy się pogodzić z tym, że ta wycena do końca będzie już widełkowa? Jak to wygląda?

[ 00:16:31] Grzegorz Papaj: Wycena zawsze jest obarczona jakimś stopniem niepewności, którego nie da się wyeliminować.

[ 00:16:38] Wynika to z wielu czynników. Przede wszystkim z tego, że nie da się w stu procentach uzgodnić, co jedna strona ma na myśli, kiedy rozmawia z drugą stroną. Takie pełne zrozumienie jest ideałem, do którego można dotrzeć, który można osiągnąć współpracując ze sobą dłużej.

[ 00:17:04] Natomiast czy da się zawęzić? To zależy od sytuacji. Są takie zakresy prac, które są obarczone większym ryzykiem niż inne.

[ 00:17:18] Na przykład wiemy, że mamy się zintegrować z jakimś zewnętrznym systemem i wiemy, że 10 lat temu ktoś zrobił jakieś API i dało się z nim integrować. Wiemy, że od tego czasu system był zmieniony. Czy API zostało zaktualizowane, to w sumie nikt nam nie potrafi powiedzieć.

[ 00:17:37] Więc szacując musimy brać tego typu czynniki pod uwagę. Było jakieś API działało. Czy będzie działać teraz? W sumie nie wiemy. Jak zaczniemy to robić to pewnie się dowiemy. Nawet jeśli było zmienione, to nie oznacza, że to nam wykluczy czy utrudni pracę. Może nie, może będzie dokładnie odwrotnie.

[ 00:17:59] Ale powstaje jakiś obszar niepewności, czegoś, co nie jesteśmy w stanie kontrolować.

[ 00:18:03] Nie jesteśmy w stanie kontrolować klienta. Klienci mają to do siebie, że kiedy się im pokazuje jakieś prototypy, pierwsze wersje systemów, to klienci lubią wprowadzać zmiany w projekcie, bo zobaczyli na własne oczy coś, co nam opisali. Teoretycznie jest to to, co chcieli, ale już teraz widzą, że coś należałoby zmienić, zmodyfikować. Taka zmiana oczywiście jest czasochłonna. Jest to dodatkowy koszt.

[ 00:18:36] Tak więc ta niepewność, ten rozstrzał widełek jest odzwierciedleniem, naszych doświadczeń, tego, że wiemy, że klienci nie są w stanie do końca wyspecyfikować, co ma być zrobione, czego potrzebują i dopiero jak zobaczą coś w działaniu, wtedy ta specyfikacja się konkretyzuje Wtedy są w stanie nam podać konkretne informacje jak coś powinno być zrobione i wtedy to dopiero jest przekładane na jakąś rzeczywistą pracę przez nas wykonaną.

[ 00:19:12] Nie wiem czy się tutaj wyrażam jasno w tym temacie. Ale tego nie jesteśmy w stanie uniknąć. Klienci lubią wprowadzać zmiany w trakcie realizacji systemu. To jest jeden z obszarów rozstrzał tych widełek.

[ 00:19:37] Piotr Lewandowski: Czy wycena takiego systemu informatycznego jest przygotowywana za darmo i też czy według Ciebie powinna być przygotowywana za darmo? Czy taka darmowa wycena coś na czym możemy polegać?

[ 00:19:51] Grzegorz Papaj: To może ja powiem jak my to robimy. Tak naprawdę taka wycena jest częściowo za darmo, częściowo nie. Zależy o czym rozmawiamy.

[ 00:20:00] W momencie, kiedy przychodzi do nas klient z projektem, to zwykle oczekuje od nas określenia kosztów, żeby ustalić, czy to co my jesteśmy w stanie zrobić jest zgodne z jego budżetem.

[ 00:20:15] Więc my jesteśmy w stanie poświęcić kilka godzin na rozmowy z klientem, na oszacowanie kosztów. I to jesteśmy w stanie zrobić bezpłatnie. Klient za to nie będzie musiał nic zapłacić. Po prostu z nim porozmawiamy, spróbujemy ogarnąć temat.

[ 00:20:36] Natomiast musimy tutaj też zauważyć, że to będzie wstępne oszacowanie. Czyli to właśnie będą jakieś tam widełki. Mogą być dosyć szerokie w zależności od przedmiotu realizacji.

[ 00:20:48] Czyli podajemy przykładowo, że to będzie między 200 a 300 tysięcy. I to z reguły jest ten moment, w którym klient już wie mniej więcej, czy to pasuje do jego budżetu.

[ 00:21:01] Jeżeli pasuje do jego budżetu, no to wtedy rozmawiamy dalej. Wtedy przechodzimy do analizy. Ten pierwszy etap realizacji każdego projektu to jest analiza funkcjonalna, projekt techniczny. To jest ten moment, w którym my już szczegółowo omawiamy zakres funkcjonalny i na podstawie tego robimy projekt wstępny, szacujemy czasy realizacji i przygotowujemy kosztorys.

[ 00:21:29] I w tym momencie następuje zawężenie. Już wtedy wiemy, że to nie będzie między 200 300 tys. tylko między 250 a 280 tys., bo sobie wszystko byliśmy w stanie przedyskutować, przeanalizować, przeliczyć. Więc takie zawężenie jak najbardziej jest możliwe. Przy czym to już oznacza konkretną pracę dla nas. Czas na analizę raczej się liczy tygodniami niż dniami. Więc to już jest płatna usługa. Natomiast w ramach tej usługi, rozmawiamy z klientem, mamy serię warsztatów, klient jest zaangażowany w ten proces.

[ 00:22:08] To jest też tak, że często odkrywamy razem z klientem, co jest do zrobienia, bo też nie zawsze klient do końca sobie zdaje sprawę, jaki jest zakres projektu. Co więcej, jeżeli już opracowujemy kosztorys, to też zwracamy uwagę na budżet klienta. W szczególności zwracamy uwagę na rzeczy, które są nie kluczowe dla całości działania systemu.

[ 00:22:33] Z reguły dzielimy takie funkcjonalności na kilka klas na zasadzie musi być zrobione, może być zrobione, fajnie żeby było. Podajemy osobne szacowania dla poszczególnych modułów w takim projekcie.

[ 00:22:50] Wtedy klient robiąc analizę w zasadzie ryzykuje tylko jakąś część budżetu, którą poświęca na dokonanie tej dokładniejszej wyceny. W efekcie ma już w miarę bezpieczne oszacowanie kosztów realizacji. My też ze swojej strony jak już pracujemy produkcyjnie z klientem i wiemy jakie ma założenia budżetowe, to staramy się pilnować tego budżetu razem z klientem.

[ 00:23:20] Czyli jeśli widzimy, że coś się zaczyna wymykać spod kontroli, jakieś funkcjonalności, powiedzmy są niekoniecznie kluczowe, a klient chce je robić, no to czasem tego klienta możemy wstrzymać, powiedzieć ok, ale to pamiętaj kliencie, to jest coś, o czym rozmawialiśmy, że jest niekoniecznie pierwszej potrzeby. Może odłóżmy to na później, bo budżet nam się może nie domknąć.

[ 00:23:49] Piotr Lewandowski: Czy takie szacowanie albo wycena mają jakąś datę ważności i kiedy mogą się zmienić?

[ 00:24:02] Grzegorz Papaj: Zasadniczo mają datę ważności. Czasem jest to wskazane wręcz w dokumencie, który przedstawiamy.

[ 00:24:09] Z czego to wynika? Pierwszy czynnik to po prostu inflacja. Ciężko nam obiecać, że jak klient wróci do nas po trzech latach, to cena realizacji projektu będzie dokładnie taka sama jak wcześniej szacowaliśmy. Przez te 3 lata wzrosły koszty, wzrosły pensje programistów. Więc ta wycena jest nie do utrzymania po tak długim czasie.

[ 00:24:42] Natomiast to są rzadkie przypadki w większości większości sytuacji. Jeżeli klient przychodzi do nas po dwóch, trzech miesiącach, pół roku, to podtrzymujemy te pierwotne szacowania.

[ 00:24:56] Piotr Lewandowski: Jak szykujecie zadania przy bieżącej współpracy, która już się rozpoczęła z miesiąca na miesiąca? Jak to wygląda w praktyce?

[ 00:25:07] Grzegorz Papaj: OK, czyli zakładamy, że pracujemy już z systemem, który znamy?

[ 00:25:11] Piotr Lewandowski: Tak, pracujemy z systemem, który znamy. Pojawiają się nowe zadania do wykonania. Jak ten proces wygląda?

[ 00:25:22] Grzegorz Papaj: W zdecydowanej większości przypadków klient do nas przychodzi, czy komunikuje nam w taki czy inny sposób. Tworzy jakąś listę zadań do zrobienia. My do każdego zadania jakieś szacowanie godzinowe dajemy.

[ 00:25:40] Robimy to po to, żeby klient miał świadomość, ile będzie go kosztować realizacja poszczególnych zadań i potem z reguły na podstawie tej informacji klient decyduje, co idzie na pierwszy ogień, co ma dla niego znaczenie.

[ 00:25:55] Może rzeczy, które są szybkie do realizacji, a zatem tanie i kluczowe, to powinny być realizowane priorytetowo. Rzeczy drogie i nie kluczowe mogą być odłożone na później.

[ 00:26:11] Tak na bieżąco podajemy oszacowania do każdych zadań, które mamy do realizacji. I klient sobie wybiera.

[ 00:26:24] Czasem jest też tak, że mamy po prostu wolną rękę. Sami realizujemy zadania według naszego uznania, według naszej kolejności, bo wiemy, że klient po prostu i tak chce, żeby wszystko zostało zrealizowane.

[ 00:26:38] Piotr Lewandowski: Co jeżeli w trakcie takiej współpracy wydarzy się coś niespodziewanego? Wyszacowaliśmy coś, nagle się okazuje, że znaleźliśmy jakąś bombę gdzieś podłożoną. Jak wygląda w praktyce reagowanie na takie sytuacje?

[ 00:26:56] Grzegorz Papaj: Jednym z największych strachów klientów, którzy z nami współpracują, jest to, że budżet zostanie znacząco przekroczony i co więcej zostanie znacząco przekroczony, a klient się o tym dowie za późno.

[ 00:27:10] Więc żeby te obawy rozwiać. To, co my robimy, to w sytuacji, kiedy mamy choćby podejrzenia, że na jakimś tam zadaniu budżet nam się rozjedzie z szacowaniem, informujemy o tym klienta.

[ 00:27:26] To jest pierwsza i najważniejsza rzecz, żeby klient miał świadomość, co się dzieje w projekcie.

[ 00:27:32] I jeżeli klient już tę świadomość ma, to rozmawiamy z nim, z reguły przechodzimy z konkretnymi propozycjami na zasadzie możemy zrobić tę funkcjonalność X. No ale tu mamy jakieś tam wynikające z niezależnych przyczyn problemy. Może się okazać, że zajmie to zdecydowanie więcej czasu, a możemy z tego zrezygnować np. albo odłożyć na później, bo są pilniejsze sprawy, albo możemy poświęcić trochę czasu znaleźć jakieś obejście tego problemu. Czyli dostaniesz funkcjonalność, którą chciałeś, ale nie będzie ona w stu procentach taka być może wystarczająco dobra.

[ 00:28:06] Żeby do takiego czegoś dojść, to przede wszystkim musimy klientowi zakomunikować problem, omówić z nim możliwości i razem w zasadzie podjąć decyzję, w którą stronę idziemy, co z tym tematem robimy?

[ 00:28:20] Bo ryzyko takie, że trafimy na jakąś minę, jakąś niespodziankę jest niezerowe w każdym projekcie, bo możemy czegoś nie zrozumieć w oczekiwaniach klienta. Czasem klient sam może nie wiedzieć jakie ma oczekiwania.

[ 00:28:38] Takimi tematami i obszarami podwyższonego ryzyka są też oczywiście wszelkiego rodzaju integracje z zewnętrznymi systemami czy w ogóle obszary trochę bardziej nieznane.

[ 00:28:47] To co zdarza nam się robić, czyli przejmowanie systemów po innych dostawcach. Gdzie coś mamy dokończyć, na pierwszy rzut oka, po inspekcji kodu wydawało się, że to zajmie powiedzmy tydzień, a potem się okazuje, że nie, to nie było takie proste. Jak zaczęliśmy z tym pracować, to wychodzi, że to będzie miesiąc. Więc takie sytuacje też się mogą zdarzyć.

[ 00:29:10] W takiej sytuacji na pewno to, czego nie robimy, to nie zamykamy się gdzieś tam i nie zaczynamy rozwiązywać problemu, żeby potem przejść z rachunkiem do klienta.

[ 00:29:20] Wręcz przeciwnie. Komunikujemy klientowi problem, mówimy gdzie jesteśmy, jakie są ryzyka, jakie są potencjalne koszty.

[ 00:29:29] Aktualizujemy nasze szacowanie, w związku z tym. Ewentualnie proponujemy jakieś scenariusze alternatywne.

[ 00:29:35] Oczywiście, to dotyczy zadań o pewnej skali. Jeżeli coś szacowaliśmy na 8 godzin, a wyszło 9, to raczej to nie jest coś, co jest szczególnie istotne w większości przypadków mówimy tu o jakichś większych tematach.

[ 00:29:51] Piotr Lewandowski: Myślę że tematowi, o którym wspomniałeś, czyli o przyjmowaniu systemów poświęcimy osobny odcinek.

[ 00:29:59] Na dzisiaj dziękuję.

[ 00:30:03] Grzegorz Papaj: Dziękuję.

Rozwiń całość