Czasem nie trzeba więcej zasobów. Wystarczy spojrzeć na projekt świeżymi oczami.
To zdanie najlepiej podsumowuje sytuację klienta z pogranicza branży Retail i Martech. Projekt trwał, budżet się palił, a efekty nie przystawały do oczekiwań. Problem nie leżał w samym pomyśle — leżał w tym, jak projekt był prowadzony i przez kogo.
Punkt wyjścia — co zostało zastane
Projekt realizował 10-osobowy zespół po stronie firmy developerskiej, rozliczany w modelu Time & Material. Na papierze — wszystko się zgadzało. W praktyce — jakość rekomendacji biznesowych i rozwiązań technicznych była niewystarczająca, a kompetencje części zespołu nie odpowiadały skali i specyfice projektu.
Klient płacił. Zespół pracował. Projekt nie szedł do przodu tak, jak powinien.
Diagnoza — gdzie leżał problem
Po przeprowadzeniu szczegółowej analizy zidentyfikowano kilka kluczowych obszarów wymagających natychmiastowej interwencji:
- Brak odpowiednich kompetencji po stronie firmy developerskiej w zakresie przygotowania rekomendacji biznesowych
- Nieefektywna struktura zespołu — dublowanie ról, brak wyraźnej odpowiedzialności
- Chaos procesowy — współpraca między stronami odbywała się bez ustrukturyzowanej metodologii
- Jeden z developerów przez okres 2 miesięcy dostarczał pracę poniżej akceptowalnego standardu — bez żadnych konsekwencji
Rekomendacje i egzekucja — co zostało wdrożone
Interwencja trwała 2 miesiące — od diagnozy po nadzór nad egzekucją rekomendacji. Poniżej kluczowe zmiany.
Zmiana struktury zespołu
Zespół został zredukowany z 10 do 8 osób po stronie developera. Rola architekta została wyeliminowana jako nieadekwatna do etapu projektu. Jedna z ról została przeniesiona do wewnętrznego zespołu klienta — co zwiększyło jego kontrolę nad projektem i zmniejszyło zależność od zewnętrznego dostawcy.
Wprowadzenie Product Ownera
Do projektu została włączona dedykowana osoba w roli Product Ownera — jako pomost między biznesem a zespołem technicznym. Zmiana ta natychmiast poprawiła jakość komunikacji i priorytetyzację prac.
Wdrożenie metodologii Scrum
Proces współpracy zespołowej został ustrukturyzowany w oparciu o Scrum. Regularne ceremonie, jasne kryteria akceptacji, mierzalne sprinty — projekt zyskał rytm i przewidywalność.
Renegocjacja warunków umowy
Na podstawie analizy stawek rynkowych wynegocjowano obniżenie stawki godzinowej o 7%. Dodatkowo uzyskano rekompensatę w wysokości 50% stawki jednego developera za 2 miesiące pracy poniżej standardu.
Efekty — co zostało osiągnięte
- Redukcja kosztów zespołu — mniejszy, lepiej dobrany zespół + niższa stawka godzinowa
- Odzyskana rekompensata — 50% stawki developera za 2 miesiące złej pracy
- Wyższa jakość oddawanych elementów — widoczna już w kolejnym sprincie po zmianach
- Sprawniejszy proces testów — dzięki lepszej definicji gotowości i kryteriów akceptacji
- Realne terminy — projekt zyskał wiarygodny harmonogram zamiast przesuwanych deadline’ów
Wniosek
Model Time & Material bywa wygodny — ale bez regularnego audytu bardzo łatwo zamienia się w nieefektywne przepalanie budżetu. Zewnętrzne spojrzenie, znajomość realiów rynkowych i gotowość do trudnych rozmów z dostawcą — to narzędzia, które realnie chronią interesy klienta.