Zleciłeś budowę aplikacji, zapłaciłeś za kilka sprintów, a zamiast działającego produktu masz serię wymówek i przesuwany harmonogram? Opóźnienia w IT to częsty problem – statystyki są bezlitosne: 80% projektów IT nie przetrwa dłużej niż kilka miesięcy. Ale to nie znaczy, że Twój projekt musi skończyć tak samo. Poniżej znajdziesz konkretną ścieżkę działania - od pierwszych kroków ratunkowych po wybór nowego partnera technologicznego.
Na skróty: co zrobić, gdy software house nie dowozi – 5 pierwszych ruchów
Wyobraź sobie sytuację z 2024 roku: startup B2B zamówił marketplace z integracją płatności. Software house obiecał MVP w cztery miesiące. Minęło osiem, a klient ma niedziałający frontend, brak środowiska testowego i zerową dokumentację. Budżet przepalony w 70%, a produkt nie nadaje się do pokazania pierwszym użytkownikom. Stres i frustracja rosną z każdym tygodniem.
W przypadku opóźnienia kluczowe jest zachowanie spokoju i podjęcie ustrukturyzowanych działań. Oto pięć ruchów, od których warto zacząć:
Zbierz fakty i dowody - maile, wiadomości na Slacku, historię zadań w Jira, umowę, ofertę, roadmapę. Wszystko, co dokumentuje obietnice i faktyczny stan realizacji projektu.
Wyślij oficjalny, eskalujący e-mail - opisz konkretne opóźnienia, brakujące funkcjonalności i oczekiwania. Formalne wezwanie do wykonania umowy powinno być pisemne.
Zażądaj planu naprawczego - z datami, zakresem i osobami odpowiedzialnymi za poszczególne zadania.
Skonsultuj się z prawnikiem lub niezależnym CTO - konsultacja z prawnikiem jest zalecana przed odstąpieniem od umowy, a fractional CTO pomoże ocenić stan techniczny.
Przygotuj plan B - niezależny audyt kodu i wstępna rozmowa z potencjalnym nowym wykonawcą.
Poniżej rozwijam każdy z tych kroków szczegółowo.
Diagnoza: czy software house faktycznie „nie dowozi", czy to tylko przesunięcia?
Zanim podejmiesz radykalne decyzje, musisz odpowiedzieć na kluczowe pytanie: czy masz do czynienia z realnym niedowożeniem, czy raczej z opóźnieniami wynikającymi z naturalnego scope creep i zmieniających się wymagań? Ciągła komunikacja jest kluczowa przez cały proces współpracy - jej brak często powoduje, że drobne przesunięcia eskalują w poważne problemy.
Pamiętaj: dwa na sto projektów IT przetrwają dłużej niż kilka miesięcy. To znaczy, że nawet „normalne" opóźnienia mogą być symptomem głębszych problemów.
Kryteria twardych problemów:
Brak działających funkcjonalności mimo rozliczonych sprintów
Niewywiązanie się z kamieni milowych zapisanych w umowie
Brak demo, środowiska testowego lub wersji do akceptacji
Brak regularnych raportów statusu i monitorowanie postępów jest niemożliwe
Kryteria miękkie, ale równie niepokojące:
Wysoka rotacja programistów w zespole (szczególnie seniorów)
Brak odpowiedzi na maile przez wiele dni
Ciągłe wymówki bez konkretnego planu naprawczego
Brak osoby decyzyjnej po stronie software house
Dobrą praktyką jest porównanie pierwotnej roadmapy (np. harmonogram z marca 2024) z faktycznymi funkcjami dostępnymi w sierpniu 2024. Sporządź krótki „raport sytuacyjny" po stronie klienta - 1–2 strony opisujące, co obiecano, co dostarczono, ile było sprintów, bugów i opóźnień. Dokumentacja opóźnienia jest kluczowa w przypadku sporów dotyczących dostarczenia projektu.
Sprawdź umowę: jakie masz prawa, terminy i zabezpieczenia?
Zanim podejmiesz emocjonalną decyzję, wróć do umowy z software house'em - to ona określa Twoje pole manewru. Ważne jest dokładne przeanalizowanie umowy i ustaleń projektowych. Oto co konkretnie sprawdzić:
Definicja zakresu prac i rezultatów - czy jest opisane minimum viable product? Czy załączono specyfikację funkcjonalną, makiety, dokument analityczny? Brak specyfikacji utrudnia wycenę projektu IT i późniejsze dochodzenie roszczeń.
Harmonogram - terminy etapów, release'ów, sprintów. Umowa powinna zawierać terminy, kamienie milowe oraz zasady odbioru prac.
Model rozliczeń - Time & Material vs fixed price. Przy fixed price sprawdź, czy płatności zależą od postępu prac i akceptacji przez klienta.
Postanowienia o opóźnieniach - w umowach mogą być przewidziane kary umowne za każdy dzień opóźnienia. Sprawdź, jakie warunki muszą być spełnione, by je naliczyć.
Prawa autorskie i własność kodu - kto jest właścicielem oprogramowania? Kiedy następuje przeniesienie praw majątkowych? Czy masz dostęp do repozytorium?
Procedury odstąpienia lub wypowiedzenia - możliwość odstąpienia od umowy może być przewidziana w umowie lub na mocy prawa cywilnego.
Zwróć uwagę na to, czy mowa jest o umowie o dzieło (obowiązek rezultatu) czy o świadczenie usług (obowiązek starannego działania) - ma to kluczowe znaczenie dla zakresu odpowiedzialności wykonawcy. Brak specyfikacji utrudnia wycenę projektów IT, dlatego sprawdź, czy zakres w umowie jest wystarczająco precyzyjny.
Przygotuj listę pytań do prawnika na podstawie zapisów umowy, zamiast wysyłać cały dokument bez kontekstu. Dokumentacja wszystkich ustaleń pomiędzy stronami powinna być przechowywana na piśmie.
Uporządkowana eskalacja: jak rozmawiać z software house'em, zanim „pójdziesz na wojnę"
Pierwszym krokiem po diagnozie powinien być uporządkowany proces współpracy i eskalacji - nie od razu wypowiedzenie umowy. Sprawne zarządzanie projektem wymaga indywidualnego podejścia, ale schemat eskalacji jest uniwersalny:
Przygotuj „status memo" z twojej strony - konkretne daty, ustalenia, log rozmów, lista niewywiązanych zobowiązań.
Zwołaj regularne spotkania statusowe z udziałem PM, tech leada i osoby decyzyjnej po stronie software house'u.
Przedstaw różnicę między planem realizacji projektu IT a aktualnym stanem - konkretne funkcje, daty, bugi, brakujące elementy.
Zażądaj pisemnego planu naprawczego na najbliższe 4–6 tygodni z datami, zakresem i odpowiedzialnymi osobami.
Ustal nowe, mierzalne KPI - liczba zakończonych zadań w sprintach, czas reakcji na zgłoszenia krytyczne, termin wydania MVP.
Po każdym spotkaniu wyślij podsumowanie ustaleń e-mailem z datą, zakresem i terminem odpowiedzi. To później przydaje się jako dowód w ewentualnym sporze.
W przypadku braku poprawy, możliwe jest rozwiązanie współpracy z wykonawcą. Brak reakcji lub nieprzestrzeganie planu naprawczego to wyraźny sygnał, by przygotować transfer projektu do innego partnera technologicznego.
Bezpieczeństwo projektu: dostęp do kodu, środowisk i wiedzy (zanim będzie za późno)
W 2023 roku klient firmy technologicznej nie miał dostępu administracyjnego do repozytorium. Po rozstaniu z software house'em został dosłownie bez kodu, dokumentacji i możliwości dalszego rozwoju aplikacji. Zabezpieczenie dostępu do kodu źródłowego i dokumentacji jest niezwykle ważne przed zakończeniem współpracy.
Elementy, które trzeba jak najszybciej zabezpieczyć:
Własność intelektualna - upewnij się, że masz przeniesienie praw majątkowych do kodu tworzonych w ramach twojego projektu.
Dostęp administracyjny - repozytorium (GitHub / GitLab / Azure DevOps), system zadań (Jira, Asana), środowiska: produkcja, staging, test.
Infrastruktura - kopie konfiguracji (Terraform, Ansible), dostępy do chmury (AWS, GCP, Azure), klucze API, ustawienia CI/CD.
Dokumentacja - architektura systemu, diagramy, integracje, kluczowe procesy biznesowe zaimplementowane w aplikacji, instrukcje wdrożenia.
Koszty wdrożenia mogą wzrosnąć przez brak dokumentacji - czasem nawet dwu- lub trzykrotnie. W razie napiętej relacji formalnie poproś software house o przekazanie pełnych dostępów i dokumentacji w określonym terminie (np. 7 dni), powołując się na zapisy umowy.
Brak kontroli nad tymi elementami znacznie utrudnia zmianę dostawcy i może realnie zablokować dalszy rozwój twojego projektu IT.
Audyt techniczno-biznesowy: sprawdź stan projektu przed podjęciem radykalnych decyzji
Audyt twojego projektu IT to obiektywna ocena kodu, architektury, jakości realizacji projektu oraz zgodności z celami biznesowymi ustalonymi na starcie. Niezależny audyt techniczny może pomóc ocenić stan projektu i jakość kodu - zanim podejmiesz decyzję o dalszych krokach.
Co powinien obejmować audyt:
Przegląd repozytorium - struktura kodu, standardy, dług techniczny. Testowanie oprogramowania obejmuje różne metody, w tym testy jednostkowe - sprawdź, czy w ogóle istnieją.
Ocena architektury - skalowalność, bezpieczeństwo, koszty utrzymania w chmurze. TCO, czyli całkowity koszt posiadania projektu IT, potrafi zaskoczyć.
Porównanie zakresu - realny stan funkcjonalności vs pierwotna roadmapa i zakres MVP.
Analiza ryzyk - zależności od konkretnych osób, użyte niszowe technologie, brak testów, brak monitoringu.
Ocena sensowności kontynuacji - czy obecny software house ma potencjał, czy lepiej myśleć o przejęciu projektu przez inny zespół.
Przejęcie projektu wymaga 20–25 godzin analizy kodu, a koszty przejęcia projektu zależą od stanu technicznego systemu. Audyt może przeprowadzić niezależny ekspert (np. fractional CTO) lub potencjalny nowy partner technologiczny - jak Michał Molenda / Code Apps - w ramach tzw. audytu zerowego.
Efektem audytu powinien być raport z rekomendacją: „kontynuować z poprawkami", „zmienić model współpracy" lub „zaplanować uporządkowane przejęcie projektu".
Plan naprawczy: jak uratować współpracę i dowieźć MVP zamiast zaczynać od zera
Nie zawsze trzeba zrywać współpracę. Dobry software house dostarcza spersonalizowane rozwiązania dostosowane do potrzeb klienta - czasem wystarczy reset oczekiwań i sprawne zarządzanie. Na sto projektów dwa mają szansę na dłuższe funkcjonowanie, więc warto walczyć o swój.
Elementy dobrego planu naprawczego:
Redefinicja zakresu na najbliższe 6–8 tygodni: skupienie na wydaniu minimum viable product zamiast pełnej wizji z prezentacji sprzedażowej. Proces współpracy zaczyna się od analizy potrzeb klienta - nawet na tym etapie.
Jasne priorytety funkcji - must-have vs nice-to-have, powiązane z konkretnymi celami biznesowymi (np. możliwość przyjmowania pierwszych płatności do 30.11.2024). W fazie projektowania powstaje makieta aplikacji - jeśli jej nie było, pora ją nadrobić.
Doprecyzowany proces - częstotliwość statusów, cotygodniowe demo, forma raportów (np. tygodniowy raport w poniedziałek do 10:00), monitorowanie postępów w czasie rzeczywistym.
Mierniki jakości - liczba krytycznych błędów, pokrycie testów, czas reakcji na zgłoszenia.
Zmiana składu zespołu - dołożenie seniora, zmiana PM, wzmocnienie kompetencji po stronie pracowników software house'u.
Plan warto spisać jako aneks do umowy lub oficjalny „Project Recovery Plan" zaakceptowany przez obie strony. Jeśli w ciągu 2–3 sprintów nie widać poprawy, wracasz do scenariusza zmiany wykonawcy.
Gdy trzeba się rozstać: zakończenie umowy i przygotowanie transferu projektu
Decyzja o rozstaniu z software house'em to decyzja biznesowa, nie osobista porażka. Praca nad starymi systemami często wiąże się z dużymi kosztami, ale kontrolowany transfer jest zawsze tańszy niż chaotyczny.
Aspekty formalne:
Wybór trybu zakończenia - wypowiedzenie vs odstąpienie, zależnie od typu umowy i konsultacji z prawnikiem.
Dotrzymanie okresów wypowiedzenia zapisanych w umowie.
Rozliczenie etapów prac na podstawie rzeczywiście dostarczonych rezultatów - demo, wdrożone funkcje, dokumentacja. Wdrożenie oprogramowania zapewnia integrację z istniejącymi systemami klienta - rozlicz tylko to, co faktycznie działa.
Aspekty praktyczne „exit planu":
Stworzenie listy zasobów do przejęcia: kody źródłowe, dokumentacja, dostępy, klucze API, konta w usługach zewnętrznych.
Ustalenie, kto i w jakich datach (np. w ciągu 14 dni) ma przekazać wiedzę techniczną nowemu zespołowi.
Zaplanowanie krótkiego okresu „nakładania się" starego i nowego dostawcy - np. 2 tygodnie wspólnych calli technicznych.
Spisanie protokołu zdawczo-odbiorczego projektu IT na zakończenie współpracy.
Unikaj palenia mostów - kulturalny, ale stanowczy ton komunikacji. Rozlicz zobowiązania, jasno określ oczekiwania co do wsparcia w transferze.
Wybór nowego partnera: jak uniknąć powtórki i dobrze zaplanować realizację projektu IT
Po złym doświadczeniu łatwo popaść w skrajność - wybrać tylko po cenie albo „z polecenia bez weryfikacji". Wybór software house może zająć kilka tygodni, ale tym razem warto podejść metodycznie. Klienci często obawiają się ujawnienia swoich pomysłów - dobry software house rozumie to i oferuje kompleksową obsługę z zachowaniem poufności.
Kryteria wyboru:
Doświadczenie w podobnych projektach - portfolio software house powinno zawierać zróżnicowane projekty z branży IT (SaaS, marketplace, aplikację mobilną, system wewnętrzny).
Umiejętność przejmowania istniejących systemów - audyt zerowy, plan przejęcia, radzenie sobie z długiem technicznym.
Transparentny proces współpracy - discovery, warsztaty, regularne demo, raportowanie, praca na wspólnych narzędziach. Dobry software house jest w stanie dostosować się do indywidualnych potrzeb.
Nacisk na potrzeby biznesowe - software house powinien umieć przełożyć wymagania biznesowe na roadmapę produktu i pomóc w osiągnięciu product-market fit.
Elastyczność - gotowość do startu od MVP i stopniowego skalowania zamiast od razu wersji enterprise.
Software house oferuje tworzenie aplikacji mobilnych i webowych, a usługi obejmują również automatyzację procesów biznesowych. Zwróć uwagę na to, czy technologie używane przez software house wpływają korzystnie na koszty i rozwój systemu w dłuższej perspektywie. Software house powinien dostarczyć pełną wycenę po analizie projektu.
Przed podpisaniem umowy poproś o przykładowy plan realizacji projektu na 3 miesiące, propozycję zakresu MVP i wstępne ryzyka z rekomendacjami technologicznymi.
Jak ułożyć nową współpracę, żeby projekt nie utknął ponownie?
Zmiana dostawcy to tylko połowa sukcesu. Współpraca z software house zwiększa efektywność biznesową, ale wymaga zdrowego procesu i klarownych zasad. Software house zapewnia wsparcie techniczne na każdym etapie projektu - pod warunkiem, że obie strony grają fair.
Kluczowe elementy dobrze ustawionego procesu:
Warsztaty startowe (Discovery) - jasne zdefiniowanie celów biznesowych klienta, grup użytkowników i KPI przed wyborem stacku technologicznego. Aktywny udział po twojej stronie jest niezwykle ważne.
Realistyczna roadmapa - najpierw MVP, potem kolejne releasy zgodne z priorytetami biznesowymi i założenia dopasowane do rynku.
Zaangażowanie klienta - kto decyduje o priorytetach, jak często bierzesz udział w przeglądach sprintów, jak szybko odpowiadasz na pytania w backlogu.
Przejrzystość budżetu - regularne raporty kosztowe, porównanie wyceny projektu do rzeczywistych wydatków, świadome decyzje o rozszerzeniu zakresu w każdym czasie.
Dokumentacja i IP od pierwszego dnia - repozytoria, dostęp, opisy architektury aktualizowane na bieżąco. Stworzenie tej bazy na wczesnym etapie oszczędza koszty w przyszłości.
Jako zewnętrzny dział IT lub fractional CTO, Code Apps może pilnować jakości zarządzania projektem z Twojej strony - nawet jeśli stworzenie kodu realizuje inny software house. To zwrócenie uwagi na proces, nie tylko na technologie, robi różnicę między projektem, który dowiezie produkt, a kolejnym, który utknie.
Podsumowanie: jak zamienić kryzys projektu IT w impuls do zbudowania lepszego produktu
Od diagnozy, przez zabezpieczenie zasobów, audyt, plan naprawczy, po ewentualną zmianę wykonawcy i lepsze ułożenie procesu - każdy krok ma znaczenie. Nawet jeśli pierwszy software house nie dowiózł projektu, nie oznacza to, że Twój pomysł lub cele biznesowe są złe. Często problem leży w procesie, komunikacji lub niedoszacowanym MVP. Jak uczy doświadczenie - porażka projektu to nie koniec drogi, lecz szansa na lepsze założenia.
Potraktuj sytuację jako okazję do uporządkowania strategii rozwoju produktu, budżetu i sposobu pracy nad kolejnymi wersjami systemu. Pozyskiwanie nowych klientów dla Twojego biznesu zależy od tego, czy dostarczysz im działający produkt - a nie od tego, ile sprintów rozliczył poprzedni wykonawca.
Jeśli potrzebujesz audytu istniejącego projektu, chcesz zaplanować minimum viable product albo szukasz wsparcia fractional CTO przy dalszej realizacji projektu IT - napisz do mnie. Jako Michał Molenda / Code Apps pomagam firmom wyjść z impasu technologicznego i zbudować produkt, który naprawdę trafia na rynek.
