Programiści dostępni „od zaraz”? Sprawdź, dlaczego to pułapka i jak nie stać się bohaterem projektowej katastrofy. Część 1

Setki software house’ów walczą o uwagę klientów, licytując się na stawki, terminy i obietnice. Jednak za błyszczącymi prezentacjami handlowymi i zapewnieniami o "najwyższej jakości kodu" często kryje się brutalna rzeczywistość, która dla nieświadomego inwestora może oznaczać utopienie budżetu i stracone miesiące, a nawet lata pracy.

Z perspektywy Kodiwo, gdzie na co dzień zajmujemy się audytem i wsparciem w wyborze wykonawców IT, widzimy powtarzający się, niepokojący schemat. Klienci przychodzą do nas często "po szkodzie" - z niedokończonym kodem, z którym poprzedni wykonawca zniknął lub którego nie potrafi dalej rozwijać. Historie te, choć różnią się detalami, mają wspólny mianownik: brak odpowiedniej weryfikacji dostawcy na samym początku oraz zignorowanie sygnałów ostrzegawczych, które dla wprawnego oka są widoczne jeszcze przed podpisaniem umowy. W tym artykule przyjrzymy się anatomii nieudanej współpracy, rozkładając na czynniki pierwsze mechanizmy, które prowadzą do projektowych katastrof.

Matematyka porażki: Kiedy tania stawka staje się najdroższym kredytem

Fundamentem każdej katastrofy IT jest zazwyczaj iluzja oszczędności. Pierwszym i najbardziej jaskrawym sygnałem ostrzegawczym, który paradoksalnie najczęściej przyciąga klientów, jest rażąco niska stawka godzinowa. W biznesie naturalnym odruchem jest szukanie optymalizacji kosztowej, jednak w inżynierii oprogramowania zasada "tanio" niemal nigdy nie idzie w parze z "dobrze", a tym bardziej szybko. Wyobraźmy sobie sytuację, w której otrzymujemy trzy oferty. Dwie z nich oscylują wokół rynkowej średniej, a trzecia jest o połowę tańsza. Handlowiec taniego software house’u zapewnia, że niższa cena wynika z "efektywnej struktury firmy" lub "promocji na start". W rzeczywistości matematyka rynku IT jest nieubłagana. Doświadczeni programiści, którzy potrafią pisać bezpieczny, skalowalny kod i przewidywać błędy architektury zanim one powstaną, kosztują dużo. Jeśli firma oferuje stawkę, która ledwo pokrywa wynagrodzenie juniora, to z niemal stuprocentową pewnością Twój projekt będzie poligonem doświadczalnym dla osób, które dopiero uczą się zawodu.

Konsekwencje wyboru najtańszej oferty rzadko ujawniają się w pierwszym miesiącu. Początkowo postępy mogą wydawać się zadowalające. Problemy zaczynają się w momencie, gdy aplikacja musi obsłużyć większy ruch, gdy trzeba dodać nową funkcjonalność, a kod okazuje się "spaghetti" - nieczytelną plątaniną zależności, której nikt nie chce i nie potrafi naprawić. Dług technologiczny zaciągnięty na początku projektu poprzez zatrudnienie tanich wykonawców, spłaca się później z ogromnym procentem. Często koszt naprawy wielokrotnie przewyższa oszczędności poczynione na etapie wyboru stawki. Tani wykonawca to w rzeczywistości najdroższy kredyt, jaki może zaciągnąć startup lub korporacja.

"Startujemy jutro", czyli o desperacji ukrytej pod maską elastyczności

Równie niebezpiecznym sygnałem, co podejrzanie niska cena, jest natychmiastowa dostępność całego zespołu deweloperskiego. W branży IT, gdzie niedobór talentów jest problemem globalnym, dobre zespoły rzadko siedzą na tzw. "ławce", czekając bezczynnie na zlecenie. Renomowane firmy i freelancerzy planują obłożenie z wyprzedzeniem. Jeśli potencjalny partner na spotkaniu sprzedażowym deklaruje: "Mamy pięciu seniorów dostępnych od zaraz, możemy startować jutro", powinno to zapalić czerwoną lampkę w głowie każdego decydenta.

Może to oznaczać jedną z dwóch rzeczy: albo firma ma poważne problemy z płynnością i rotacją projektów, albo - co gorsza - "seniorzy", o których mowa, są w rzeczywistości naprędce rekrutowanymi freelancerami lub juniorami, których firma próbuje "upchnąć" w projekcie, byle tylko zacząć fakturowanie. Rozpoczęcie współpracy z firmą, która desperacko szuka zajęcia dla swoich ludzi, to proszenie się o kłopoty. Stabilny partner technologiczny to taki, który ma kolejkę zleceń, bo to świadczy o jakości jego usług i zaufaniu, jakim darzą go inni klienci.

Budowanie wieżowca na serwetce: Grzech pominięcia Discovery

Gdy już omówiliśmy kwestie zasobów ludzkich i finansowych, przejdźmy do samej metodyki pracy, a raczej jej braku. Jednym z największych grzechów, jakie popełniają niedoświadczone software house’y - często pod presją nieświadomego klienta - jest rozpoczęcie kodowania bez etapu Discovery. To moment, w którym wykonawca mówi: "Nie traćmy czasu na warsztaty i dokumentację, wiemy o co chodzi, siadamy do pisania kodu". Brzmi kusząco? Oczywiście. Każdy inwestor chce jak najszybciej zobaczyć efekt. Jednak budowanie zaawansowanego systemu IT bez fazy Discovery, w której rozbija się wizję biznesową na specyfikację techniczną i mapę procesów, jest jak budowanie wieżowca bez planów architektonicznych, polegając jedynie na szkicu narysowanym na serwetce.

Tylko podczas pogłębionej analizy wychodzą na jaw luki w logice biznesowej, sprzeczne wymagania czy techniczne ograniczenia, które mogą wywrócić projekt do góry nogami. Software house, który zgadza się (lub sam proponuje) pominąć ten etap, wykazuje się brakiem profesjonalizmu. Skutkiem takiego podejścia jest tzw. feature creep - niekontrolowany rozrost funkcjonalności w trakcie prac, ciągłe zmiany założeń i w efekcie - drastyczne przekroczenie budżetu i terminów. Zamiast precyzyjnego narzędzia biznesowego, powstaje chaotyczny zlepek funkcji, który często nie realizuje podstawowych celów biznesowych klienta, ponieważ nikt na początku nie zadał pytania: "Po co to w ogóle budujemy?".

Podsumowanie

Opisane powyżej mechanizmy - od pułapki nierynkowych stawek, przez pozorną dostępność zasobów „na wczoraj”, aż po ryzykowne pomijanie etapu analizy - to niestety tylko część grzechów głównych branży IT.

Niniejszy tekst stanowi pierwszą z dwóch części naszego przewodnika po sygnałach ostrzegawczych, których nie wolno ignorować. W kolejnym artykule przyjrzymy się równie krytycznym, choć często bagatelizowanym aspektom: braku transparentności w procesie (brak wersji demo), zagrożeniom płynącym z pracy „na słowo” bez umowy oraz niebezpieczeństwu izolowania klienta od zespołu technicznego.

Już teraz jednak wniosek nasuwa się sam: w świecie, gdzie błąd technologiczny potrafi kosztować fortunę, zasada ograniczonego zaufania jest Twoim najlepszym sprzymierzeńcem. Weryfikacja software house’u przed startem prac to nie zbędna biurokracja czy wyraz braku zaufania, ale fundamentalna higiena biznesowa i Twoja polisa ubezpieczeniowa. Skorzystanie z zewnętrznego audytu i profesjonalnego wsparcia w wyborze wykonawcy pozwala oddzielić marketingowe obietnice od realnych kompetencji, oszczędzając nie tylko budżet, ale i nerwy. Bądźcie czujni i wypatrujcie drugiej części naszego poradnika.