Agile vs Waterfall
Pracujemy w modelu przyrostowym, a rozliczamy się na zasadach Time&Material. Podejście tradycyjne (Waterfall) oparte na stałej wycenie (Fixed Price) nie sprawdza się w przypadku złożonych projektów IT.
Agile
🟩 Orientacja na cel. Skupiamy się na finalnym produkcie i wartości biznesowej dla Klienta.
🟩 Elastyczność. Klient w każdej chwili może zmienić koncepcję. Może zakończyć projekt, jeśli uzna, że to co otrzymał spełnia jego oczekiwania.
🟩 Szybki i częsty feedback. Klient jest częścią zespołu deweloperskiego. Jego feedback jest kluczowy.
🟩 Skuteczność. Dzięki ciągłej interakcji z aplikacją – Klient otrzymuje produkt, który spełnia wszystkie jego życzenia.
🟩 Szybki i darmowy start. Projekt nie wymaga szczegółowej specyfikacji – wystarczy ogólny zarys. Klient nie ponosi kosztów związanych z przygotowaniem wyceny.
🟩 Podejście fair. Wykonawca jest rozliczany za rzeczywistą ilość przepracowanych godzin. Nie ma presji czasu.
🟩 Entuzjazm. Dominuje poczucie zadowolenia i szacunku. Współpraca oparta jest na partnerskich relacjach i filozofii win-win.
Waterfall
🟥 Orientacja na plan. Skupiamy się na spełnieniu wymagań określonych w specyfikacji.
🟥 Sztywność. Klient nie może zmienić niczego względem przyjętej specyfikacji. Każda zmiana wymaga podpisania oddzielnej umowy lub aneksu.
🟥 Brak feedbacku. Rola Klienta ogranicza się w zasadzie do przygotowania materiałów. Jego feedback nie jest brany pod uwagę.
🟥 Nieskuteczność. Klient wchodzi w interakcję z aplikacją, dopiero po ukończeniu prac. Wtedy zwykle chce sporo pozmieniać.
🟥 Późny i płatny start. Projekt wymaga opracowania bardzo skrupulatnej specyfikacji i wyceny. Klient ponosi koszt przygotowania takiego dokumentu (nawet do kilku tysięcy).
🟥 Podejście nie fair. Rzeczywisty czas pracy Wykonawcy znacznie przewyższa ten oszacowany.
🟥 Niesmak. Wyjście poza specyfikację oznacza tarcia, a nawet zerwanie współpracy. Dominuje poczucie krzywdy i żalu po obu stronach.