Dlaczego niższa stawka godzinowa nie oznacza tańszego projektu?

Rozumiem, skąd to przekonanie. Ten klient działa w branży, w której konkuruje się ceną i tylko ceną, bo produkt jest w pełni opisany normą. Kupując stal, kupuje się półprodukt zdefiniowany co do grama – skład chemiczny, granica plastyczności, wszystko zmierzone i podpisane certyfikatem. Dwie oferty na tę samą stal różnią się właściwie tylko logistyką i marżą dostawcy. W takim świecie tańsza oferta to po prostu lepszy wybór. Problem w tym, że oprogramowanie nie działa według tych samych zasad, a kto przenosi logikę zakupu stali na zakup systemu IT, ten zwykle myśli, że oszczędza, podczas gdy w rzeczywistości przepłaca.

Spróbujmy pokazać normę na „seniora developera”. Otóż takiej normy nie ma. Pod tą samą etykietą kryje się rozpiętość produktywności, którą badania szacują nawet na

1:10, a w skrajnych przypadkach na 1:20.

Nie chodzi o to, że najlepsi inżynierowie piszą dziesięć razy szybciej – chodzi o to, że podejmują dziesięć razy lepsze decyzje, dziesiątki razy w ciągu jednego projektu. Każda z tych decyzji albo buduje system, który za pięć lat wciąż działa, albo taki, który po roku trzeba będzie reanimować. Porównując cenę godziny dwóch firm, w gruncie rzeczy porównuje się dwie liczby opisujące zupełnie różne rzeczywistości. To trochę jak wycenianie pracy chirurga według stawki za minutę spędzoną na sali operacyjnej – da się to policzyć, ale niewiele to mówi o tym, co naprawdę kupujemy.

Warto zapytać, bo „konkurencja” w takich zdaniach bywa zaskakująco nieokreślona. Najczęściej na stole leżą trzy zupełnie różne typy ofert, a żadnej z nich nie powinno się porównywać w jednej tabelce w Excelu.

Inny partner Microsoft

Na pierwszy rzut oka to najbliższe porównanie – ta sama platforma, ten sam certyfikat partnerski. W praktyce dwie firmy z tym samym logotypem mogą się różnić tak, jak kancelaria z dwudziestoletnim doświadczeniem w danej branży różni się od kancelarii, która „też obsługuje spółki”. Certyfikat potwierdza, że firma potrafi poprawnie skonfigurować narzędzia. Nie potwierdza, że zrozumie specyfikę Twojego biznesu, zanim zacznie go przerabiać na system. Warto zapytać, czy tańszy partner najpierw dopyta, jak działa Twoja firma, czy raczej przyjdzie z gotowym szablonem, który „na pewno zadziała”.

Inna technologia, inny framework

„Ci sami robią to w Javie, w PHP albo we własnym autorskim silniku, i taniej” – to może być prawda, tylko rzadko kto zadaje sobie pytanie, co dzieje się z takim systemem później. Pracownicy funkcjonują na co dzień w Teams, Outlooku, Excelu, SharePoincie. System zbudowany w ekosystemie Microsoft naturalnie się w to wpisuje. System napisany w niszowej technologii, nawet dobry, staje obok jak osobna wyspa. Nikt formalnie nie przestaje pracować, ale wszyscy pracują trochę wolniej – dane trzeba przepisywać ręcznie, logować się osobno do różnych miejsc, eksportować coś do Excela, bo system „tego nie umie”. Tej różnicy nie widać w żadnej tabelce ofertowej. Widać ją dopiero w czasie, jaki co miesiąc po cichu tracą ludzie.

Software house, który obiecuje napisać „dokładnie to, co chcesz”.

Brzmi kusząco, a bywa najdroższą z tych trzech opcji. Firma pisząca system od zera, w autorskiej technologii, dostarczy zamówioną funkcjonalność, ale zostawi też rachunek, którego nie widać w dniu odbioru:

• kod, który rozumie tylko ona, więc zmiana wykonawcy oznacza w praktyce przepisanie systemu od podstaw,
• architekturę, która nie integruje się z niczym innym,
• wsparcie, którego cena potrafi zaskoczyć.

Kto policzył

Co wyszło

McKinsey-Oxford

Duże projekty IT przekraczają budżet średnio o 45%. 17% z nich zagraża dalszemu istnieniu firmy – nie chodzi więc o zwykłe opóźnienie, tylko realne ryzyko dla organizacji.

Flyvbjerg

Wśród projektów, które przebiły budżet o więcej niż połowę, średnie przekroczenie sięgnęło aż 447%.

CISQ

Zła jakość oprogramowania kosztuje amerykańską gospodarkę co najmniej 2,41 biliona dolarów rocznie. Skumulowany dług techniczny to 1,52 biliona dolarów.

Stripe

Przeciętny programista traci jedną trzecią czasu na walkę z bałaganem pozostawionym przez poprzedników, zamiast tworzyć coś nowego.

Te liczby nie oznaczają, że tanie projekty prowadzą programiści gorsi od tych droższych. Oznaczają raczej, że tam, gdzie brakuje analizy, zarządzania i testów, konsekwencje i tak się pojawią – tylko później, zwykle już po stronie klienta.

Wyobraźmy sobie projekt wyceniony na 500 000 złotych. Tańsza oferta jest niższa o 8%, czyli na papierze oszczędzamy 40 000 złotych. Wybór wydaje się prosty. Pół roku później okazuje się jednak, że integracja z systemem ERP „była poza zakresem”, dokumentacja jest szczątkowa, a każda kolejna zmiana wymaga analizy praktycznie od zera. Projekt trafia do kategorii, w której – zgodnie z cytowanymi wyżej badaniami – ląduje ponad połowa wdrożeń, i przekracza budżet o średnie 45%. W efekcie dopłacamy około 225 000 złotych, czyli więcej niż pięć razy tyle, ile wcześniej wydawało się, że udało się zaoszczędzić. To zresztą wariant optymistyczny, bo zakłada, że projekt w ogóle zostanie ukończony.

Druga oferta, ta droższa o 8%, kosztuje 540 000 złotych, ale kończy się systemem dostarczonym na czas, z porządną dokumentacją i architekturą, którą można dalej rozwijać. Za dwa lata dokładanie nowych funkcji do takiego systemu kosztuje ułamek tego, co trzeba by zapłacić, budując je na fundamentach pozostawionych w nieładzie.

Różnica między tymi dwoma scenariuszami wcale nie sprowadza się do 8%. W perspektywie pięciu lat może sięgać 300–500% – tylko że nikt nie jest w stanie pokazać tego wprost w ofercie.

Kupując stal, kupujemy materiał o ściśle określonych parametrach. Kupując oprogramowanie, kupujemy w gruncie rzeczy setki decyzji, które konkretni ludzie podejmą w kolejnych miesiącach – jak zaprojektować bazę danych, jak obsłużyć błędy, jak przygotować system na to, że firma za rok będzie większa. Każda z tych decyzji albo buduje przewagę firmy, albo ją osłabia, a żadnej z nich nie widać w stawce godzinowej.

Firma droższa o 8% może być droższa, ponieważ zatrudnia lepszych specjalistów, testuje rozwiązania przed wdrożeniem i nie oszczędza na dokumentacji ani architekturze. Może też być droższa bez żadnego uzasadnienia – i w takiej sytuacji warto dopytać, za co właściwie się płaci. To jednak zupełnie inne pytanie niż „dlaczego nie jesteście najtańsi”. Pierwsze świadczy o rozsądku. Drugie sugeruje, że ktoś próbuje porównywać oprogramowanie do stali, choć te dwie rzeczy rządzą się zupełnie innymi prawami.

Zamiast skupiać się na cenie godziny, warto raczej zapytać, co dokładnie otrzymujemy w ramach projektu i ile faktycznie będziemy za niego płacić w ciągu najbliższych pięciu lat. Odpowiedź na to pytanie mówi znacznie więcej niż jakiekolwiek porównanie stawek w tabelce.