Oferty i wyceny w firmie IT i software house

Software house i firma wdrożeniowa sprzedają coś, czego w chwili podpisania umowy jeszcze nie ma. Klient chce znać cenę, wykonawca zna co najwyżej przybliżony nakład. Z tego napięcia biorą się zaniżone oferty, przekroczone budżety i trudne rozmowy w połowie projektu. Organizację całej firmy opisuje strona dla firm IT i software house'ów.

Skąd biorą się błędne wyceny

• Zakres w trzech zdaniach. „Aplikacja do rezerwacji z panelem administratora”.
• Szacunek jednej osoby. Zwykle najbardziej doświadczonej, która liczy własnym tempem.
• Pominięte prace towarzyszące. Konfiguracja środowisk, testy, wdrożenie, dokumentacja, spotkania.
• Nieznane integracje. Cudzy system bez dokumentacji potrafi pochłonąć więcej niż własny kod.
• Presja sprzedażowa. Kwota dopasowana do budżetu klienta, a nie do pracy.
• Brak porównania z historią. Nikt nie sprawdza, ile trwały podobne projekty.

Trzy poziomy wyceny

Poziom	Na czym się opiera	Dokładność	Do czego służy
Orientacyjna	Rozmowa, podobne projekty z przeszłości	Szerokie widełki	Sprawdzenie, czy budżet i oczekiwania się spotykają
Wstępna	Lista funkcji, główne założenia	Widełki węższe, z listą ryzyk	Decyzja o rozpoczęciu analizy lub pierwszego etapu
Szczegółowa	Analiza: wymagania, makiety, integracje	Kwota za etap lub limit budżetu	Podstawa umowy

Kłopoty zaczynają się, gdy wycena orientacyjna trafia do umowy jako cena stała.

Jak szacować

1. Rozbij zakres na elementy, które da się wyobrazić: ekrany, operacje, integracje, role.
2. Szacuj każdy element w trzech wariantach: gdy wszystko pójdzie gładko, typowo i z problemami.
3. Dodaj prace towarzyszące jako osobne pozycje, nie jako ukryty narzut.
4. Oznacz niewiadome. Przy każdej pozycji, czego nie wiesz.
5. Porównaj z historią. Ile godzin zajęły podobne projekty wobec ich szacunków.
6. Daj do sprawdzenia drugiej osobie. Najlepiej tej, która będzie to wykonywać.

Punkt piąty wymaga ewidencji godzin na projektach. Jak ją prowadzić, opisuje artykuł ewidencja czasu pracy na zleceniach.

Scenariusz: integracja, której nikt nie wycenił

Scenariusz jest zmyślony. Firma z dwunastoma programistami wyceniła dla sieci serwisów samochodowych aplikację do umawiania wizyt. Oferta obejmowała aplikację, panel dla serwisów i „integrację z systemem magazynowym klienta”. Ta ostatnia pozycja dostała w szacunku kilka dni pracy.

W trakcie okazało się, że system magazynowy jest stary, nie ma interfejsu do wymiany danych, a jego dostawca odpowiada na pytania po dwóch tygodniach. Integracja pochłonęła więcej czasu niż cała aplikacja. Umowa na stałą cenę nie zawierała założeń, więc firma pokryła różnicę sama.

Od następnego projektu oferty wyglądają inaczej. Każda integracja jest osobną pozycją z założeniem zapisanym wprost: „system udostępnia udokumentowany interfejs, a klient zapewnia kontakt techniczny”. Jeśli założenie nie jest spełnione, pozycja jest wyceniana ponownie. Przed stałą ceną za projekt z integracjami firma proponuje krótki płatny etap rozpoznania. Scenariusz pokazuje, że zawiodła nie stawka, tylko brak zapisanego założenia.

Co powinna zawierać oferta

Sekcja	Po co
Cel biznesowy	Wspólne rozumienie, co ma się poprawić u klienta
Zakres z listą funkcji	Wiadomo, co powstanie
Poza zakresem	Wiadomo, co nie powstanie
Założenia	Warunki, przy których szacunek jest aktualny
Etapy i odbiory	Kontrola postępu i płatności
Cena lub widełki	Z modelem rozliczenia
Procedura zmian	Jak zgłasza się i wycenia nowe wymagania
Obowiązki klienta	Osoba decyzyjna, czas odpowiedzi, dostęp do danych
Utrzymanie	Co po wdrożeniu i za ile

Jak te same kwestie wyglądają z perspektywy zamawiającego, pokazuje artykuł umowa wdrożeniowa: na co zwrócić uwagę.

Zmiany w trakcie projektu

• Każda zmiana zapisana. Krótki opis, szacunek, wpływ na termin.
• Akceptacja przed pracą. Nie po fakcie.
• Jedna osoba po stronie klienta uprawniona do zatwierdzania.
• Rejestr zmian dostępny dla obu stron.
• Drobne zmiany w puli. Niewielka rezerwa godzin w cenie ogranicza liczbę aneksów.

Po projekcie

Każdy zamknięty projekt powinien zostawić po sobie trzy liczby: godziny szacowane, godziny rzeczywiste i przyczynę różnicy. Po kilku projektach widać, które rodzaje prac firma regularnie zaniża. To najtańszy sposób poprawy wycen. Jak czytać wynik projektu, opisuje strona rentowność zleceń w firmie IT, a prowadzenie rozmów i ofert strona CRM dla firm IT. Zasady sprzedaży zbiera przewodnik sprzedaż i obsługa zapytań, a pozostałe tematy baza wiedzy.