Wycena projektu IT jest trudna, gdy zakres i wymagania nie są jeszcze dostatecznie określone: kalkulacja opiera się wtedy na większej liczbie założeń, a jej wynik pozostaje niepewny. Znaczenie ma też rozróżnienie między kosztem pracy zespołu a dodatkowymi wydatkami i ryzykiem projektu; zależnie od kompletności wymagań cena może być przedstawiona jako ustalona kwota albo szacunkowe widełki.
Zakres i wymagania jako punkt wyjścia do wyceny
Wiarygodna wycena zaczyna się od opisu tego, jaki produkt ma powstać, jakie funkcje ma zapewniać, w jakiej technologii ma być realizowany i jaki rezultat jest oczekiwany. Wymagania funkcjonalne opisują, co system ma robić, a niefunkcjonalne — jakie warunki jego działania trzeba uwzględnić. Im dokładniejsza specyfikacja tych elementów, tym mniej założeń trzeba przyjąć przy szacowaniu; braki zwiększają ryzyko niedoszacowania.
Materiały wystarczają do wstępnej oceny, gdy jasno określają zakres, oczekiwany produkt i rezultat. Jeśli wymagania pozostają niejasne, rozmowy discovery, konsultacje lub warsztaty mogą pomóc doprecyzować zakres, ramy czasowe i cel. Przy szczególnie niepełnej specyfikacji warsztaty, prototyp albo MVP mogą posłużyć do ustalenia, co powinno wejść do projektu.
Estymacja pracochłonności i kosztu pracy zespołu
Pracochłonność projektu IT szacuje się, rozkładając zakres na elementy, którym można przypisać konkretne zadania i nakład pracy. Najpierw powstaje backlog obejmujący funkcjonalności, zadania, historyjki użytkownika lub epiki. Następnie zespół ocenia czas realizacji poszczególnych pozycji, a suma szacunków daje łączną liczbę roboczogodzin.
- Podział zakresu — uporządkowanie wymagań w backlogu ułatwia ocenę poszczególnych części projektu.
- Estymacja zadań — osoby odpowiedzialne za dane funkcjonalności lub dziedziny szacują czas ich realizacji.
- Wspólna ocena — szacunki przygotowują osoby realizujące projekt albo doświadczeni przedstawiciele zespołu, co pozwala uwzględnić różne obszary pracy.
- Kalkulacja kosztu pracy — szacowane godziny poszczególnych specjalistów mnoży się przez ich stawki, a otrzymane wartości sumuje.
Do estymacji można wykorzystać ocenę ekspercką, analogię do podobnych projektów albo modele takie jak Use Case Points i COCOMO. Przy porównaniu z wcześniejszym projektem przydatne są informacje o jego rezultacie, iteracjach, velocity i wykresach spalania; podobny rezultat nie przesądza jednak o podobnym nakładzie na komunikację i naukę. Szacunki warto sprawdzić z inną osobą techniczną i zestawić z danymi historycznymi.
Koszty dodatkowe, ryzyko i rezerwa
Koszt projektu może obejmować nie tylko development, lecz także działania i zasoby potrzebne do przygotowania, sprawdzenia oraz wdrożenia rozwiązania. Uwzględnij je wtedy, gdy wynikają z zakresu i wymagań projektu:
- Dodatkowe role i działania — analiza, zarządzanie projektem, design, testy, administracja i wdrożenie.
- Narzędzia i środowisko — licencje oprogramowania, narzędzia, infrastruktura oraz jej utrzymanie, jeśli są potrzebne do realizacji lub działania rozwiązania.
- Wymagania niefunkcjonalne i integracje — na przykład testy obciążeniowe, automatyczne skalowanie, load balancing, dodatkowe serwery czy integracje zewnętrzne mogą zwiększyć zakres prac i koszty.
Rezerwę lub widełki uzasadniają niejasne wymagania, możliwe problemy techniczne, zmiany zakresu i poprawki. Powinny odzwierciedlać niepewności konkretnego projektu, a nie uniwersalny procent: gdy ich wpływu nie da się dokładnie określić, lepiej wyraźnie uwzględnić tę niepewność w szacunku.
Dobór modelu rozliczenia i określenie widełek cenowych
Wybór modelu rozliczenia zależy przede wszystkim od tego, jak dokładnie określono zakres i na ile może on się zmieniać. Im bardziej ustalone są wymagania, tym łatwiej z góry uzgodnić koszt; gdy projekt ma ewoluować wraz z potrzebami biznesowymi, większe znaczenie ma elastyczność rozliczeń.
| Model | Kiedy pasuje do zakresu | Jak przebiega rozliczenie |
|---|---|---|
| Fixed Price | Gdy zakres jest dostatecznie określony i poprzedzony szczegółową analizą funkcjonalno-techniczną. | Z góry ustala się koszt, harmonogram i płatności. |
| Time & Material | Gdy zakres może się zmieniać wraz z warunkami biznesowymi. | Rozliczane są wykorzystane godziny według uzgodnionych stawek. |
| Model hybrydowy | Gdy planowanie można oprzeć na analizie wysokopoziomowej, ale realizacja wymaga elastyczności. | Może łączyć widełki i priorytety z kamieniami milowymi oraz rozliczaniem T&M. |
Jeśli wymagania są niepełne, wycena pozostaje estymacją, a nie pewną ceną końcową. Widełki cenowe pokazują tę niepewność czytelniej niż jedna kwota sugerująca precyzję, której dostępne informacje jeszcze nie uzasadniają; ich wysokość powinna wynikać z warunków konkretnego projektu.
Jak przedstawić kalkulację w ofercie dla klienta
Przejrzysta oferta pozwala powiązać kwotę z konkretnym zakresem i pokazać, od jakich założeń zależy jej wysokość. Powinna też ułatwiać klientowi sprawdzenie, co otrzyma, w jakim terminie i jak będą rozliczane zmiany.
- Zakres prac: wymień funkcjonalności lub inne uzgodnione elementy projektu i wskaż, kiedy mają zostać dostarczone.
- Założenia i podstawa kalkulacji: opisz, na jakich informacjach opiera się wycena i czego dotyczy podana kwota lub przedział cenowy.
- Koszt: przedstaw go jako całość albo rozdziel na moduły lub etapy. Taki podział ułatwia kontrolę zakresu, harmonogramu i płatności.
- Harmonogram: pokaż plan realizacji, aby klient mógł odnieść koszt do przewidzianych prac i terminów.
- Zasady rozliczeń: określ, jak będą rozliczane poprawki, rozszerzenia zakresu, utrzymanie i wsparcie; wskaż też podział płatności, na przykład na zaliczkę, transze etapowe i rozliczenie końcowe.
