Budżet projektu IT to trzy kwoty, a nie jedna: budowa, rezerwa na zmiany i utrzymanie. Planuj więc rezerwę 10–20% wartości projektu, utrzymanie 15–25% rocznie, a pierwszy etap ogranicz do MVP z jedną kompletną ścieżką użytkownika. Aktualne ceny AppCreo znajdziesz w cenniku. Niżej opisujemy budżetowanie projektu IT krok po kroku: od czego zależy koszt dedykowanego systemu, z czego składa się budżet, jak wybrać model rozliczenia i jak nie przekroczyć planu.
Jak zakres wpływa na koszt dedykowanego systemu IT?
Nie ma jednej ceny, ale zakres pozwala zacząć budżetowanie projektu IT jeszcze przed pierwszą rozmową z wykonawcą. Poniżej zakresy naszych projektów mobilnych i webowych z względnym poziomem kosztu.
| Zakres | Poziom kosztu | Czas budowy | Kiedy wybrać |
|---|---|---|---|
| MVP | Niski lub średni | 3–5 tygodni | Sprawdzasz pomysł na użytkownikach |
| Prosta aplikacja albo jedna funkcja | Niski | 3–5 tygodni | Jeden proces, mało ról |
| Aplikacja standardowa | Średni | 1,5–2 miesiące | Konta użytkowników, panel administracyjny |
| Aplikacja z integracjami | Wysoki | 2–3 miesiące | ERP, CRM, płatności |
| Platforma dla całej firmy | Najwyższy | 2,5–4,5 miesiąca | Wiele działów, ról i integracji |
Na przykład pełna aplikacja webowa zaczyna się od poziomu aplikacji standardowej. Różnica między ofertami software house’ów wynika częściej z liczby godzin niż ze stawki godzinowej.
Od czego zależy koszt aplikacji mobilnych, opisujemy w tekście ile kosztuje aplikacja mobilna, a zakres usług - na stronie cennika.
Z czego składa się budżet projektu IT?
Najczęstszy błąd to budżet równy cenie z oferty. Oferta obejmuje jednak tylko pracę wykonawcy, a projekt kosztuje więcej: czas Twojego zespołu, licencje, infrastrukturę i rok utrzymania po starcie.
- Analiza i warsztat: lista funkcji z priorytetami, mapa procesu i kryteria odbioru. Ten etap decyduje o dokładności reszty budżetu.
- Projekt UX/UI: ekrany i prototyp do zatwierdzenia przed kodem.
- Budowa: backend, aplikacja webowa lub mobilna, panel administracyjny.
- Integracje: ERP, płatności, systemy partnerów - każda wymaga pracy po obu stronach.
- Testy i wdrożenie: w tym migracja danych ze starych systemów, najczęściej niedoszacowana pozycja.
- Licencje i infrastruktura: serwery, usługi zewnętrzne, a także konta w sklepach z aplikacjami.
- Rezerwa na zmiany: 10–20% wartości projektu.
- Utrzymanie: aktualizacje, poprawki i monitoring, zwykle 15–25% wartości projektu rocznie.
- Czas Twojego zespołu: warsztaty, odbiory etapów, testy - w budżecie często go brak, choć to realny koszt.
Przykład: do ceny budowy z oferty dodajesz rezerwę 15%, a utrzymanie w pierwszym roku liczysz jako 20% wartości projektu. W efekcie budżet na pierwszy rok rośnie o około jedną trzecią w stosunku do kwoty z oferty.
Technologia wpływa na koszt w dwóch kierunkach. Tańszy start bywa droższy w utrzymaniu, dlatego budżetowanie projektu IT opieraj na koszcie w horyzoncie trzech lat, a nie tylko na cenie budowy. W przykładzie wyżej trzy lata to budowa, rezerwa 15% i trzy lata utrzymania po 20% - razem o trzy czwarte więcej niż sama budowa.
Fixed price czy time & material - który model rozliczenia wybrać?
Model rozliczenia zmienia rozkład ryzyka tak samo mocno jak zakres. W praktyce spotkasz dwa podstawowe modele i ich połączenie.
| Kryterium | Fixed price (kwota stała) | Time & material (za godziny) |
|---|---|---|
| Zakres na starcie | Opisany do poziomu ekranu i kryteriów odbioru | Cel, priorytety i pierwsze funkcje |
| Zmiany w trakcie | Aneks i osobna wycena | Zmiana priorytetów w kolejnym etapie |
| Ryzyko przekroczenia budżetu | Po stronie wykonawcy, wliczone w cenę | Po stronie zamawiającego, ograniczane limitem godzin |
| Cena końcowa | Znana przed startem | Znana po fakcie |
| Najlepszy dla | Dobrze opisanego MVP lub etapu | Rozwoju po wdrożeniu i utrzymania |
Kwota stała w umowie o dzieło to wynagrodzenie ryczałtowe. Wykonawca nie może żądać jego podwyższenia, nawet gdy nie przewidział rozmiaru prac (art. 632 § 1 Kodeksu cywilnego). Dlatego ryzyko jest wliczone w cenę.
Rozliczenie godzinowe pasuje natomiast do pracy zwinnej, która zakłada zmianę planu w trakcie. Manifest programowania zwinnego ceni reagowanie na zmiany bardziej niż realizację założonego planu - przy kwocie stałej każda taka zmiana wymaga aneksu.
Najczęściej sprawdza się model mieszany: stała cena za dobrze opisany etap albo MVP, a rozliczenie godzinowe za rozwój po wdrożeniu. Szczegółowe porównanie z tym samym projektem policzonym na dwa sposoby znajdziesz w tekście fixed price czy time & material.
Jak etapować projekt, żeby kontrolować budżet?
Etapowanie ułatwia budżetowanie projektu IT, bo dzieli ryzyko na mniejsze części. Każdy etap kończy się czymś, co można sprawdzić, zanim zapłacisz za kolejny.
- MVP: wersja z jedną kompletną ścieżką użytkownika, budowana w 3–5 tygodni. Sprawdza, czy produkt rozwiązuje problem.
- Kolejne moduły według danych: rozwijasz to, z czego użytkownicy naprawdę korzystają, a nie to, co było w pierwotnej liście.
- Dwutygodniowe etapy z odbiorem: po każdym działająca wersja na środowisku testowym. U nas płacisz etapami - zaliczkę przed każdym etapem, a nie z góry za całość.
- Rezerwa uruchamiana decyzją: 10–20% budżetu wydajesz tylko na zmiany, które zatwierdzisz na piśmie.
- Plan utrzymania od pierwszego dnia: utrzymanie w pierwszym roku wpisz do budżetu razem z budową.
Jak zaplanować pierwszą wersję produktu i od czego zależy jej koszt, opisujemy w tekście MVP aplikacji - koszt i czas, a terminy kolejnych etapów w tekście ile trwa zbudowanie aplikacji.
Opisz system w 3 zdaniach - odsyłamy przedział cenowy w 24 h w dni robocze. Przedział wystarczy, żeby zacząć budżetowanie projektu IT, zanim poprosisz o szczegółową wycenę. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.
Jakie ukryte koszty pojawiają się najczęściej?
Ukryte koszty to wydatki, których nie było w planie, choć dało się je przewidzieć. Najczęściej wynikają z pięciu źródeł:
- Rozrost zakresu: nowe funkcje dopisywane w trakcie, bez wyceny przed rozpoczęciem prac.
- Integracje odkryte w połowie projektu: system, o którym nikt nie wspomniał na warsztacie, a bez którego proces nie działa.
- Migracja danych: stare dane trzeba najpierw oczyścić, potem zmapować i przetestować.
- Utrzymanie po wdrożeniu: aktualizacje systemów operacyjnych, bibliotek i usług zewnętrznych.
- Czas zamawiającego: decyzje, testy i odbiory, które opóźniają projekt, jeśli nikt nie ma na nie czasu.
Pozycje, w których oferty ukrywają koszty, i pytania do wykonawcy zebraliśmy w tekście jak czytać wycenę software house’u.
Jak kontrolować budżet w trakcie projektu?
Budżet, którego nikt nie porównuje z postępem, przestaje być budżetem. Kontrola nie wymaga jednak zaawansowanych narzędzi, tylko stałego rytmu.
- Przegląd co etap: ile zakresu zrobiono, ile budżetu wydano, ile zostało - w jednym zestawieniu.
- Rejestr zmian: każda zmiana z opisem, wyceną i decyzją. W przeciwnym razie po trzech miesiącach nikt nie pamięta, skąd wzięła się różnica.
- Limit godzin przy rozliczeniu godzinowym: miesięczny pułap, po którego przekroczeniu wykonawca pyta o zgodę.
- Jedna osoba decyzyjna: po stronie firmy ktoś, kto akceptuje zakres i odbiera etapy.
Przy dłuższych projektach rozłóż płatności w czasie według harmonogramu etapów, żeby zachować płynność finansową. Przy rozliczeniu godzinowym poproś o miesięczny raport godzin z podziałem na zadania i porównuj go z rejestrem zmian - dzięki temu zobaczysz, która decyzja przesunęła budżet.
Jak oszacować budżet projektu IT w 7 krokach?
- Zdefiniuj cel biznesowy i zakres: jaki problem ma rozwiązać system i po czym poznasz, że działa.
- Ustal priorytety funkcji: konieczne, ważne, opcjonalne - dzięki temu wyznaczysz MVP i kolejne etapy.
- Wybierz technologię i model rozliczenia: dopasuj je do skali projektu i przewidywanych zmian.
- Oszacuj pracochłonność: przelicz zakres na godziny ról; po pomnożeniu ich przez stawkę wykonawcy zobaczysz rząd wielkości.
- Dolicz koszty dodatkowe, takie jak licencje, infrastruktura, integracje i migracja danych.
- Dodaj rezerwę: 10–20% na zmiany i niespodzianki techniczne.
- Zaplanuj utrzymanie: przynajmniej pierwszy rok, 15–25% wartości projektu.
Najczęstsze błędy, które psują budżetowanie projektu IT, to niedoszacowanie zakresu („to prosty projekt”), brak rezerwy i traktowanie wdrożenia jak końca inwestycji. Uniknięcie ich nie wymaga przy tym wiedzy finansowej - wystarczy spisać wszystkie pozycje z listy wyżej przed podpisaniem umowy.
