Dlaczego konflikt zaczyna się przed pierwszą linią kodu
Firma podpisuje umowę z dostawcą IT. Patrzy na cenę i termin. Rzadko pyta o to, co dostanie oprócz działającego produktu — dokumentację, kod źródłowy, specyfikację techniczną, plan na wypadek gdy coś się zmieni w trakcie.
Te pytania wydają się formalnością. Nie są. To one decydują, czy za rok firma będzie mogła swobodnie rozwijać system, czy będzie zależna od jednej osoby, jednego dostawcy, albo — w najgorszym przypadku — od niczego.
"Tanio i szybko" — co naprawdę kupujesz
Niska cena i krótki termin to nie problem sam w sobie. Problemem jest to, co zwykle idzie z nimi w pakiecie: brak specyfikacji, brak dokumentacji, brak zabezpieczeń, czasem brak nawet samego kodu źródłowego po stronie klienta.
To wygląda dobrze w dniu odbioru. System działa, faktura jest niższa niż u konkurencji, projekt zamknięty. Cena tej decyzji pojawia się później — gdy trzeba coś zmienić, naprawić błąd, albo dostawca po prostu znika.
Case: freelancer, który zniknął
Firma zleciła zbudowanie aplikacji freelancerowi. Produkt powstał, działał. Potem freelancer zniknął — zero kodu źródłowego, zero backupu, zero dokumentacji.
Zostało tylko to, co widać na ekranie.
Musieliśmy odtworzyć całą logikę aplikacji na podstawie obserwacji działającego produktu — bez dostępu do tego, co było "pod maską". Dwa tygodnie zajęło samo wgryzienie się w projekt, zanim mogliśmy zacząć naprawiać to, co nie działało.
Nie podaliśmy klientowi terminu na początku. Nie dlatego, że nie chcieliśmy — dlatego, że sami nie wiedzieliśmy, ile to zajmie. Odtwarzanie czegoś bez dokumentacji nie ma z góry znanego harmonogramu, bo nie wiadomo, na co się trafi, dopóki się tam nie wejdzie.
Finalnie się udało. Ale ten projekt kosztował więcej niż gdyby od początku istniała dokumentacja i kod źródłowy w rękach klienta, nie tylko u wykonawcy.
Zmiana zakresu w trakcie projektu — dlaczego to kosztuje
To jeden z najczęstszych punktów napięcia. Projekt jest w trakcie budowy. Klient widzi działającą część systemu i mówi: "a może dodamy jeszcze to" albo "czy moglibyśmy to zmienić".
Z perspektywy klienta to brzmi jak drobna korekta. Z perspektywy wykonawcy to zmiana zakresu — a umowa była podpisana na konkretny zakres, w konkretnej cenie.
Cena w ofercie nie jest ceną za "zrobienie czegoś podobnego". Jest ceną za dokładnie opisany zestaw funkcji. Dodanie nowej funkcji w trakcie budowy to nie jest korekta tej samej pracy — to dodatkowa praca, która wymaga dodatkowej wyceny.
To nie jest sposób na zarobienie więcej. To jest odzwierciedlenie tego, że zakres faktycznie się zmienił.
"To tylko jedna zmiana" — czemu trwa tak długo
Pozornie mała zmiana rzadko jest mała w praktyce. Zmiana jednego pola w formularzu może wymagać zmiany w bazie danych, w logice backendu, w trzech innych miejscach interfejsu, które z tym polem współpracują — i powtórzenia testów dla całej ścieżki, nie tylko dla tego jednego elementu.
Testy nie są formalnością do odhaczenia. Są sposobem na sprawdzenie, że zmiana w jednym miejscu nie zepsuła czegoś w innym. Im głębiej zmiana sięga w system, tym więcej miejsc trzeba sprawdzić ponownie.
Stąd różnica między tym, jak wygląda zmiana z zewnątrz ("to tylko jedno pole") i tym, ile faktycznie pracy wymaga w środku.
Więcej ludzi w projekcie = szybciej? Nie tak to działa
Klient widzi, że w projekcie pracują trzy osoby w określonej cenie. Chce, żeby było szybciej — pyta, czy dodanie czwartej osoby przyspieszy pracę.
Odpowiedź: tak, ale nie proporcjonalnie do kosztu, i nie od razu.
Nowa osoba w projekcie potrzebuje czasu, żeby zrozumieć, co już zostało zrobione, dlaczego podjęto konkretne decyzje techniczne, jak poszczególne części systemu się ze sobą łączą. Dodatkowo — więcej osób w zespole oznacza więcej komunikacji potrzebnej między nimi, żeby nie pracowały nad tym samym albo nie wchodziły sobie w drogę.
Cena rośnie, bo rośnie liczba osób do opłacenia. Tempo rośnie wolniej, niż intuicja by podsuwała — i to jest źródło nieporozumienia, gdy klient nie rozumie, czemu koszt poszedł wyraźnie w górę, a termin skrócił się tylko nieznacznie.
Dlaczego nie naprawiamy projektów po innych firmach
To zdarza się regularnie: robimy wycenę projektu. Klient wybiera firmę, która zaproponowała niższą cenę. Po jakimś czasie ten sam klient wraca z pytaniem, czy możemy to naprawić — bo tamta firma zostawiła projekt w stanie, który nie działa.
Odmawiamy.
Naprawianie cudzego kodu bez dokumentacji, bez znajomości podjętych wcześniej decyzji, bez wiedzy o tym, co było zamierzone a co jest błędem — to nie jest tańsza wersja tego samego projektu. To osobny projekt, z dodatkowym ryzykiem i dodatkowym czasem na zrozumienie tego, co ktoś inny zbudował.
Były sytuacje, w których — mimo odmowy — klient nie odpuszczał. W takich przypadkach podawaliśmy wycenę wyraźnie wyższą niż standardowa. Nie jako karę. Jako odzwierciedlenie realnego nakładu pracy, którego wymaga wejście w nieznany, niedokumentowany kod i doprowadzenie go do stanu, w którym można na nim bezpiecznie pracować dalej.
7 pytań, które warto zadać przed podpisaniem umowy z firmą IT
- Czy umowa precyzyjnie opisuje zakres prac — funkcje, nie tylko ogólny cel projektu?
- Jak wycenione są zmiany zakresu w trakcie realizacji — czy istnieje jasna zasada, nie tylko "ustalimy na bieżąco"?
- Czy po zakończeniu projektu otrzymam kod źródłowy i dokumentację techniczną — czy tylko działający produkt?
- Kto jest właścicielem kodu po zakończeniu współpracy?
- Jak wygląda proces testowania przed odbiorem — czy obejmuje całość systemu, czy tylko nowo dodane elementy?
- Co się stanie, jeśli zechcę przyspieszyć termin — jak to wpływa na cenę i jak to jest komunikowane?
- Czy firma ma doświadczenie w przejmowaniu i naprawianiu projektów po innych dostawcach — i czy wycenia to inaczej niż projekt od zera?
Jeśli szukasz konkretnych pytań do rozmowy z dostawcą — mamy też osobny przewodnik z 5 pytaniami, których większość prezesów nie zadaje.
Jak wygląda to u nas
Każdy projekt zaczynamy od bezpłatnej rozmowy kwalifikacyjnej — 45 minut, 0 zł. Jeśli ma sens, kolejny krok to płatny Zwiad: wizyta diagnostyczna, zanim podejmiemy jakiekolwiek zobowiązanie projektowe. Na tym etapie ustalamy realny zakres, dokumentujemy stan obecny i wskazujemy, gdzie mogą pojawić się koszty, które łatwo przeoczyć na etapie pierwszej rozmowy.
Zakres i cena zmian są jasne od początku — nie ustalamy ich "na bieżąco" w trakcie projektu. Dokumentacja i kod źródłowy trafiają do klienta, nie tylko do nas.
FAQ — najczęstsze pytania przed podpisaniem umowy z firmą IT
Czy firma IT może odmówić naprawy projektu zrobionego przez kogoś innego?
Tak, i to częsta praktyka w branży. Naprawa cudzego kodu bez dokumentacji wymaga najpierw zrozumienia, co zostało zbudowane i dlaczego — to dodatkowa praca, która nie była częścią pierwotnej wyceny.
Dlaczego zmiana zakresu projektu w trakcie realizacji kosztuje dodatkowo?
Bo cena w umowie odpowiada konkretnemu, opisanemu zakresowi prac. Dodanie nowej funkcji w trakcie budowy to dodatkowa praca, niezależnie od tego, jak małą wydaje się zmiana z zewnątrz.
Czy więcej osób w projekcie zawsze przyspiesza jego realizację?
Nie proporcjonalnie do kosztu. Nowa osoba potrzebuje czasu na wdrożenie się w projekt, a większy zespół wymaga więcej komunikacji wewnętrznej — to ogranicza realne przyspieszenie.
Co powinienem otrzymać po zakończeniu projektu IT, oprócz działającego produktu?
Kod źródłowy, dokumentację techniczną i specyfikację tego, co zostało zbudowane. Bez tego każda kolejna zmiana — u tego samego dostawcy albo u innego — będzie trudniejsza i droższa.
Czy tańsza oferta firmy IT zawsze oznacza wyższe ryzyko?
Nie automatycznie, ale często niska cena idzie w parze z ograniczonym zakresem dokumentacji, testów i zabezpieczeń. Warto sprawdzić, co konkretnie jest w cenie, zanim porówna się tylko liczby na końcu oferty.