Współpraca Agile zamiast Fixed Price. Obniżenie kosztu projektu IT

Kolejną szansą na obniżenie ceny jest zmiana metody współpracy z Fixed Price na Agile.

Fixed Price – czyli szacujemy cenę całkowitą przed startem projektu.

Bardzo często zarząd przed podjęciem decyzji o realizacji projektu IT chce znać jego sumaryczną całkowitą cenę – niekiedy nawet w rozłożeniu na 48 miesięcy do przodu.

Generuje to, po pierwsze konieczność tworzenia rozbudowanej specyfikacji (patrz poprzedni artykuł), po drugie powoduje dokładanie przez SH abstrakcyjnych, niemożliwych do precyzyjnego określenia kosztów takich jak:
zakładanie pakietu godzin na przyszłość, szacowanie funkcjonalności na wyrost z uwzględnieniem zmian, poprawek, naprawy błędów w długim przedziale czasu.

Im bardziej nieprecyzyjna jest funkcjonalność, tym trudniej ją oszacować.

Paradoksalnie im bardziej precyzyjna, tym większa szansa, że będzie wielokrotnie zmieniana w cyklu życia projektu, w szczególności po pierwszym przedstawieniu jej użytkownikom.

Najlepszym rozwiązaniem, które udało nam się wypracować jest współpraca w ramach umowy Agile. Prowadzimy tak już projekty z większością naszych klientów.

Na czym polega współpraca Agile?

Główne założenia współpracy Agile, to:

podział pracy na krótkie, dwutygodniowe sprinty, podczas których realizujemy fragment funkcjonalności;
każdy sprint poprzedzony jest przeprowadzeniem planingu wspólnie z klientem, na którym ustalamy funkcjonalność, którą planujemy zrealizować oraz szacujemy (ze względu na rozmiar) dość precyzyjnie alokowany czas programistów;
po dwóch tygodniach prezentujemy wyniki na demo;
rozliczamy się z realnie przepracowanych godzin.

Czyli realizujemy projekt przyrostowo, decydując w trakcie, jak będą wyglądały ostatecznie funkcjonalności. Nie przywiązujemy się do specyfikacji. Czasami w ogóle nie realizujemy pewnych funkcjonalności, a zamiast tego projektujemy inne, lepiej dopasowane do potrzeb użytkowników i klientów.

Jakie są korzyści współpracy Agile?

Korzyści dla klienta:

realizacja głównych funkcjonalności w minimalnej cenie;
możliwość dodania funkcji, o których nikt nie pomyślał, podczas rozpoczynania projektu;
realizacja tylko tych funkcjonalności, które są istotne;
podczas rozwoju funkcji A może powstać kod, dzięki któremy zrobienie funkcji B będzie bardzo proste, co sprawi, że realny koszt implementacji będzie dużo niższy od pierwotnej wyceny;
możliwość łatwego rozwiązania umowy, lub obcięcia kosztów – wystarczy nie dorzucać nic do planu kolejnych sprintów.

Jakie są minusy?

Największym minusem jest oczywiście brak pewności odnośnie całkowitego budżetu potrzebnego do realizacji projektu.

Zawsze robimy oszacowanie widełkowe, ale ostateczny koszt projektu zależy od wprowadzanych funkcjonalności i zmian w trakcie sprintów. Także nie jesteśmy w stanie powiedzieć na 100% jaka będzie realna wartość projektu.

Kolejnym “minusem” jest konieczność regularnej współpracy z wykonawcą przez okres realizacji umowy Agile. W rzeczywistości jest to plus, który korzystnie wpływa na efekt końcowy projektu IT, jednak wymaga zaangażowania czasowego istotnych osób z zespołu zamawiającego.

Trzecim elementem jest mała popularność tego typu umów poza IT. Skutkuje to lękiem przed wypróbowaniem.
Lekarstwem na to jest dobre podejście do specyfikacji i planu projektu.

Warto podzielić sobie realizację na pewne fazy (Demo, MVP, Wersja 1.0). Można zacząć od realizacji bardzo podstawowej funkcjonalności Demo w modelu Agile.

Pozwoli to przekonać się niskim kosztem, czy jest to dobra droga i czy ten model współpracy nam odpowiada.

Cieszymy się, że doszedłeś do tego miejsca.
Jeśli rozważasz realizację ciekawego projektu IT i zastanawiasz się nad wyborem wykonawcy, chętnie zerkniemy na specyfikację. Może SmartShack okaże się dobrym wyborem 🙂 Zachęcam do kontaktu.