Ile naprawdę trwa tworzenie oprogramowania (i co je opóźnia)

Klient dostaje dwie oferty. Jeden zespół mówi trzy miesiące, drugi rok. Obie oferty opisują ten sam produkt. Kto kłamie? Może żaden. Może obaj.

To temat, o którym nie mówi się wprost. Szacunki się zawyżają, ale nie zawsze celowo. Przyjrzyjmy się, dlaczego tak jest i jak to wygląda w praktyce.

Jak wygląda rzeczywistość

W 2024 roku zbudowaliśmy Carivio — kompletną platformę dyspozytorską dla taksówek. Trzy aplikacje (web, iOS, Android), backend ze 128 000 linii kodu, 48 modułów funkcyjnych, 107 migracji bazy danych, 6 ról użytkowników, real-time przez SignalR. Dziś obsługuje to około 50 pojazdów w Pradze (transportprague.com).

MVP było gotowe w 4 miesiące.

Jeśli porównamy to ze standardowymi szacunkami dla porównywalnego zakresu, mieścimy się zwykle między 12 a 18 miesiącami. To 3 do 4 razy więcej. Nie chodziliśmy na skróty. Nie chodzi o to, że pracowaliśmy 80 godzin tygodniowo. Chodzi o to, że pewne rzeczy zrobiliśmy inaczej — i inaczej wcześniej.

Co naprawdę opóźnia projekt

Szybkość nie bierze się ze skróconych sprintów. Bierze się z tego, co zrobimy — lub nie zrobimy — na początku.

Brakująca specyfikacja. To zdecydowanie najczęstsza przyczyna. Programiści zaczynają bez jasnego zadania, implementują według domysłów, a potem wracają do tego. Każda przeróbka kosztuje 3 razy więcej czasu niż poprawna implementacja za pierwszym razem. Nie dlatego, że źle się kodowało, ale dlatego, że zmieniają się rzeczy, od których zależą inne rzeczy.

Decyzje architektoniczne odkładane na „później". Schemat bazy danych, model uwierzytelniania, sposób komunikacji real-time — to rzeczy, gdzie późna zmiana przepisuje dziesiątki plików. Gdy jest to rozstrzygnięte poprawnie na początku, reszta budowania jest mechaniczna. Gdy nie jest, każdy sprint dokłada dług techniczny.

Niespodzianki integracyjne. Bramka płatnicza, system państwowy, ERP — to miejsca, gdzie szacunek bywa najmniej realistyczny. Dokumentacja mówi jedno, rzeczywistość API mówi drugie. Bez wcześniejszego rozpoznania okazuje się to dopiero podczas implementacji.

Niezdecydowanie po stronie klienta. Tego nie mówi się głośno, ale to prawda: projekt zwalnia za każdym razem, gdy czeka się tydzień na odpowiedź na kluczowe pytanie. Szybki rozwój wymaga szybkiego decydowania po obu stronach.

Szybkość ≠ skróty

Najczęstsze błędne przekonanie: szybki rozwój oznacza zły kod. Jest odwrotnie.

Gdy fundament jest zaprojektowany poprawnie od początku, dodawanie kolejnych modułów jest proste. Przeciwnie — zły fundament spowalnia każdą następną funkcjonalność. Po sześciu miesiącach takiego projektu nie nadążasz nie dlatego, że masz złych ludzi, ale dlatego, że każda zmiana pociąga za sobą trzy kolejne.

W przypadku Carivio poprawnie zaprojektowana architektura od pierwszego dnia pozwoliła nam dodawać moduły funkcyjne bez przepisywania poprzednich. Gdyby fundament nie był poprawny, 4 miesiące nie wystarczyłyby nawet na połowę zakresu.

Ta sama zasada obowiązuje też przy innych rodzajach pracy. Dla jednego klienta przyspieszyliśmy generowanie umów z 2 godzin do 3 minut — to 40 razy — przepisując silnik szablonów, który był źle zaprojektowany od początku. Nie chodziło o optymalizację parametrów, chodziło o przepisanie podejścia. W innym projekcie skróciliśmy pipeline SAP z dni do około 4 godzin, przepisując zapytania SQL — o 80% mniej danych przesyła się przez sieć.

W obu przypadkach nie chodziło o więcej pracy, ale o inaczej zaprojektowaną pracę.

Gdzie AI naprawdę pomaga

AI-assisted development zacząłem stosować systematycznie mniej więcej dwa lata temu. Odkryłem jedną prostą zasadę: pomaga tam, gdzie problem jest dobrze zdefiniowany.

Boilerplate, testy do istniejącej logiki, dokumentacja, proste transformacje — tam AI oszczędza godziny dziennie. To nie hiperbola, to mierzalne.

Tam, gdzie AI nie pomoże: zawiła integracja legacy, gdzie nikt nie wie, co kod właściwie robi. Części wrażliwe na compliance, gdzie błąd kosztuje więcej niż zaoszczędzony czas. Decyzje architektoniczne, gdzie zły wybór przepisuje tygodnie pracy. Tu potrzebujesz doświadczenia, nie narzędzia.

AI przyspiesza tam, gdzie jest dobre zadanie. Złego zadania nie uratuje nawet najlepsze narzędzie.

Uczciwie: 4 miesiące nie zawsze są możliwe

Byłoby nieuczciwe powiedzieć, że każdy projekt idzie tak szybko. Zależy to od trzech rzeczy.

Jasny zakres. Carivio miało od początku zdefiniowane MVP — co jest w nim, a co nie. Bez tego zakres rozrasta się na bieżąco i żaden szacunek się nie utrzymuje.

Decydowanie w czasie rzeczywistym. Klient był dostępny, odpowiedzi przychodziły szybko. Gdzie czeka się na decyzję, tam czeka cały zespół.

Fundament za pierwszym razem. Czas zaoszczędzony na specyfikacji i architekturze odbija się w każdym kolejnym sprincie. Skrócenie tej fazy jest co prawda kuszące, ale zwykle wychodzi trzy razy drożej.

Gdy te trzy rzeczy nie są spełnione, projekt się wlecze. Niezależnie od narzędzi, frameworków czy wielkości zespołu.

Co z tego wynika

Szacunki zawyżają się najczęściej z dwóch powodów: albo liczy się z przeróbkami (bo brakuje specyfikacji), albo dodaje się poduszkę na wypadek problemów (bo integracje są nierozpoznane). Oba są racjonalne w kontekście, w którym klient nie przychodzi z gotowym zadaniem.

Rozwiązaniem nie jest naciskanie na programistów, żeby szacowali mniej. Rozwiązaniem jest przyjść przygotowanym: z jasnym zakresem, kluczowymi decyzjami podjętymi i gotowością do szybkiego decydowania także w trakcie.

Wtedy szacunki się zmieniają — nie o procenty, ale o rzędy wielkości.

---

FAQ

Dlaczego jeden szacunek mówi 3 miesiące, a drugi rok?

Bo każdy z nich liczy się z inną ilością niewiadomych. Zespół, który szacuje rok, prawdopodobnie kalkuluje przeróbki, niepewność integracyjną i czekanie na decyzje. Zespół, który mówi 3 miesiące, albo ma doświadczenie w eliminowaniu niewiadomych z góry, albo niedoszacowuje zakres i nie zdąży. Bez przeczytania zadania i sposobu pracy obu zespołów nie odczytasz tego z samej liczby.

Czy AI przyspieszy rozwój?

Zależy, co robisz. Przy dobrze zdefiniowanej pracy — testy, boilerplate, dokumentacja — tak, znacząco. Przy decyzjach architektonicznych, integracji legacy czy logice compliance nie. AI nie zastąpi złego zadania. Jeśli nie wiesz dokładnie, czego chcesz, AI szybciej wygeneruje ci to źle.

Czy MVP w 4 miesiące jest możliwe zawsze?

Nie. Zależy od jasnego zakresu, szybkiego decydowania klienta i poprawnie zaprojektowanego fundamentu. Jeśli jednej z tych rzeczy brakuje, 4 miesiące realnie nie wystarczą. Co jednak obowiązuje zawsze: czas spędzony na specyfikacji i architekturze na początku zwraca się w każdym kolejnym sprincie. Pominięcie go to najdroższy skrót, jaki projekt może zrobić.