# Wycena 24 godziny, wykonanie 46,5. Jak czytam rozliczenia software house'u

> Dwa zadania: 24 → 46,5 godziny i 40 → 59,5. Pokazuję, jak porównuję zakres, wycenę i wykonanie oraz o co pytam przy rozliczeniu.

W dwa miesiące software house rozliczył u klienta, z którym stale współpracuję, około 670 godzin. W zestawieniu znalazłem zadania, które zajęły wyraźnie więcej, niż zakładała wycena.

Piszę z perspektywy osoby, która po stronie klienta trzyma backlog i odbiera prace. Interesuje mnie zakres i wyjaśnienie różnic. Sama suma godzin nie odpowiada na pytanie, skąd wzięło się przekroczenie.

## Dwa przykłady

Optymalizacja wydajności sklepu była wyceniona na 24 godziny, a zamknęła się w 46,5. Karta produktu miała zająć 40 godzin, zajęła 59,5.

Nie piszę tego, żeby kogoś wytykać palcami. Przy takich zadaniach przekroczenia się zdarzają: w starym sklepie wychodzą rzeczy, których nie widać w wycenie, a wymagania zmieniają się w trakcie, także z naszej strony. Gorzej, jeśli dowiadujesz się o nich dopiero z faktury.

## Godziny według rodzaju pracy

| | |
|---|---:|
| Programowanie | 494 h |
| Zarządzanie projektem | 82 h |
| Testy | 74 h |
| Projektowanie | 21 h |

Zaokrąglone godziny z dwumiesięcznego rozliczenia dostawcy.

## Co sprawdzam co tydzień

1. **Wycenę i wykonanie każdego zadania osobno**, a nie sumę z miesiąca. Suma potrafi wyglądać dobrze, bo jedno zadanie poszło szybciej, a dwa inne trwały dwa razy dłużej.
2. **Zmiany w backlogu.** Robię zrzut z Jiry i porównuję go z poprzednim. W tych dwóch miesiącach zgłoszeń przybyło ze 109 do 120. Część to nasze nowe pomysły, część wyszła w trakcie prac. Płacimy za obie, ale tylko o pierwszych decydujemy świadomie.
3. **Proporcje godzin.** Programowanie, zarządzanie projektem, testy, projektowanie. Jeśli zarządzanie rośnie szybciej niż programowanie, warto zapytać dlaczego.
4. **Przedpłatę i zużycie.** Ile zostało z puli i na ile tygodni wystarczy przy obecnym tempie.

> **Pytanie, które zadaję najczęściej**
>
> „Co się zmieniło od wyceny?” Zwykle odpowiedź jest konkretna i wtedy decydujemy, czy robimy dalej, czy nie. Gorzej, gdy brzmi: „nic, po prostu wyszło więcej”.

## Specyfikacja przed wyceną

Przy systemie zestawów produktowych napisałem specyfikację, która z góry odpowiadała na pytania, o które programista i tak by zapytał. Jak dzielić rabat między produkty w zestawie? Co z dyrektywą Omnibus? Co z zamiennikami i kilkoma magazynami? Jak zestaw ma wyglądać w Google Merchant Center i na Allegro?

Dzięki temu dostawca wycenił kolejne etapy w trzech wariantach, od 162 do 258 godzin, i mogliśmy wybrać, za co płacimy. Bez specyfikacji wycena byłaby jedną liczbą, a każde pytanie w trakcie prac kończyłoby się nowymi godzinami.

## Po co to wszystko

Nie liczę każdej minuty i nie traktuję dostawcy jak przeciwnika. Dobry software house sam woli, żeby po stronie klienta ktoś wiedział, czego chce, i szybko odpowiadał na pytania. Każde przekroczenie wyjaśniamy, zanim trafi do rozliczenia.

Jeśli macie podobny układ, a w firmie nikt nie ma czasu tego pilnować, mogę się tym zająć.