Angebot

Roboczodzień (MD): jak software house liczy wycenę

Marcin ChołaścińskiProject Manager, wcześniej COO software house'u

czerwiec 2026 · 2 min czytania

Gdy software house podaje wycenę, prawie zawsze liczy w roboczodniach (MD, man-day). Jeden MD to jeden dzień pracy jednego specjalisty.

Estymacje bywają podawane w roboczogodzinach – to ma sens przy krótkich zadaniach. Przy większych projektach rzadko się tak liczy; zakres wychodzi na tyle duży, że naturalnie mierzy się go już w dniach.

Budżet w pierwszym przybliżeniu to liczba MD × dzienna stawka wykonawcy. W polskim software house stawka to zwykle ok. 1600–2400 zł za MD dla programisty mid (stan na II poł. 2026, wg raportów stawek IT); senior i wąskie specjalizacje wyżej, freelancer bywa tańszy.

Skąd biorą się roboczodni

Dobra estymacja nie jest jedną liczbą bez rozbicia. Projekt dzieli się na moduły, a każdy moduł dostaje przedział: optymistyczny, najbardziej prawdopodobny i pesymistyczny.

Z tych trzech liczb wylicza się wartość oczekiwaną metodą PERT. To standard w szacowaniu, bo pokazuje niepewność zamiast ukrywać ją w jednej kwocie. Suma modułów daje bazę projektu.

Czysty kod to tylko połowa wyceny

Najczęstsze nieporozumienie dotyczy samego kodu. Implementacja funkcji to zwykle około połowy realnego budżetu.

Druga połowa to działania operacyjne, które są w każdym poważnym projekcie:

  • Zarządzanie projektem – koordynacja, planowanie, komunikacja z Klientem.
  • QA i testy – manualne i automatyczne, plus poprawki po testach.
  • Code review – utrzymanie jakości i spójności kodu.
  • DevOps, CI/CD i wdrożenie – środowiska, publikacja na produkcję.
  • Analiza i dokumentacja – doprecyzowanie wymagań, przekazanie projektu.
  • Bufor na ryzyko – margines na nieprzewidziane problemy.

W praktyce oznacza to, że typowy mnożnik na czysty development to ok. 2×. Jeśli funkcje wyceniono na 50 MD, realny projekt to bliżej 100 MD.

Jeśli sam kod pochłania ponad 70% wyceny, to sygnał ostrzegawczy. Ktoś prawdopodobnie pominął jakość albo zarządzanie.

Dlaczego to ważne dla ciebie

Gdy widzisz wycenę z samą bazą funkcji, jest zaniżona. Gdy widzisz wycenę bez rozbicia na MD, nie masz jak jej ocenić.

Patrz na dni robocze, nie tylko na końcową kwotę, i sprawdzaj, czy działania operacyjne są policzone. Więcej w tekście o tym, jak czytać wycenę software house'u.

Żeby zobaczyć takie rozbicie dla swojego pomysłu, wygeneruj wycenę w roboczodniach – z podziałem na moduły i działania operacyjne.

MC
Marcin Chołaściński
Project Manager, wcześniej COO software house'u

Od kilkunastu lat w software delivery – PM, a wcześniej Head of Operations i COO. Prowadzi projekty o szerokim spektrum: enterprise, sektor publiczny i AI. Wycenę projektu zna od briefu po odbiór – stąd Angebot.

Czytaj dalej