Ustal, co dostawca rzeczywiście wycenił
Przed oceną kwoty poproś o wersję wymagań, założenia, listę wyłączeń i sposób oszacowania nakładu pracy. Sprawdź, czy wycena obejmuje cały potrzebny etap, czy tylko jego wybrany fragment.
GAO Cost Guide opisuje m.in. podział prac, dokumentowanie założeń oraz analizę ryzyka i wrażliwości. Te zasady pomagają również przy ocenie ofert IT, choć przewodnik nie dostarcza cennika polskiego rynku.
W proponowanym przez Celor review oznaczamy każdą większą pozycję jako opartą na rozpoznanym zakresie, założeniu albo wymagającą dodatkowego sprawdzenia. Im więcej niewiadomych, tym ostrożniej należy interpretować precyzję łącznej kwoty.
Rozdziel nakład pracy, stawki i pozostałe koszty
Poproś o zestawienie etapów i ról zamiast samej sumy godzin. Analiza, projekt interfejsu, development, testy, uruchomienie i zarządzanie mogą mieć różne założenia oraz stawki.
| Element | Co sprawdzić |
|---|---|
| Zakres funkcji | Czy obejmuje scenariusze i wyjątki uzgodnione z biznesem? |
| Integracje | Czy uwzględnia przygotowanie, testy i obsługę błędów? |
| Dane | Kto odpowiada za migrację, oczyszczenie i weryfikację? |
| Jakość | Czy przewidziano testy, poprawki i odbiór? |
| Uruchomienie | Czy wyceniono konfigurację i wsparcie startu? |
| Koszty zewnętrzne | Jakie licencje, usługi i opłaty płaci klient? |
Sprawdź także, czy te same działania nie występują w kilku pozycjach oraz gdzie kończy się odpowiedzialność dostawcy.
Przykład hipotetyczny: przedział zamiast pozornej dokładności
Załóżmy nakład 800–1 100 godzin przy umownej średniej stawce 220 PLN netto. Daje to 176 000–242 000 PLN netto kosztu pracy. To wyłącznie przykład rachunku, nie benchmark ani rekomendowana cena.
Przedział nie obejmuje automatycznie licencji, infrastruktury, pracy zespołu klienta i późniejszego utrzymania. Jego sens zależy też od tego, skąd wzięło się 800 i 1 100 godzin. Zapytaj, które elementy powodują różnicę oraz co trzeba ustalić, aby ją zmniejszyć.
Sama informacja „stawka jest rynkowa” nie potwierdza zasadności budżetu. Wysoki nakład na niepotrzebny zakres nadal może oznaczać nieuzasadnioną inwestycję.
Powiąż rezerwę z konkretnymi niewiadomymi
Rezerwa powinna mieć wyjaśnienie: niepoznane API, jakość danych, zależność od zewnętrznego dostawcy lub zmienność wymagań. Zapytaj, które ryzyka uwzględniono w kwocie, a które mogą oznaczać dodatkową pracę. Nie dodawaj rezerwy drugi raz, jeśli została już ujęta w nakładach.
W rozliczeniu czasowym ustal sposób akceptacji prac, raportowania zużycia budżetu i reagowania na prognozowane przekroczenie. Przy cenie stałej doprecyzuj zakres i procedurę zmiany. Sama forma rozliczenia nie usuwa niepewności.
GOV.UK Service Standard zwraca uwagę na całkowity koszt technologii i możliwość późniejszej zmiany. Dlatego sprawdź również koszty po odbiorze projektu.
Zakończ ocenę listą rozbieżności i decyzją
Wynik weryfikacji powinien oddzielać: uzasadniony koszt, brakujący zakres, elementy opcjonalne oraz niewiadome do rozpoznania. Jeśli rozbieżność dotyczy rozumienia procesu, kolejna negocjacja stawki jej nie rozwiąże. Najpierw doprecyzuj rezultat.
Przygotuj pytania do dostawcy i poproś o zaktualizowaną wycenę po wyjaśnieniach. Dopiero wtedy porównuj warianty. Szerszą listę kryteriów znajdziesz w ocenie oferty software house’u, a wybór etapu opisujemy w PoC a MVP. Second Opinion obejmuje ocenę estymacji i ryzyk jako część niezależnego review projektu. Nie zastępuje szczegółowej wyceny wykonawczej na podstawie kompletnych wymagań.
Częste pytania
Czy da się sprawdzić cenę projektu bez dokumentacji?
Można wskazać pytania i oczywiste niewiadome, ale wiarygodność oceny będzie ograniczona. Do porównania potrzebny jest przynajmniej opis rezultatu, zakresu, integracji, jakości i obowiązków stron.
Czy niezależne review powinno wskazać jedną właściwą cenę?
Nie. Powinno ocenić spójność zakresu i estymacji, pokazać niepewność oraz elementy wymagające wyjaśnienia. Cena zależy także od sposobu realizacji i odpowiedzialności przyjętej przez dostawcę.
Źródła i dalsza lektura
- GAO: Cost Estimating and Assessment Guide
- GOV.UK Service Standard: Choose the right tools and technology
Źródła wspierają wskazane w tekście zasady. Listy kontrolne i przykłady to propozycje Celor do dopasowania do konkretnego projektu.