Decyzja

Punktem wyjścia dla budżetu oprogramowania jest praca, którą ludzie muszą wykonać, w tym wyjątki. Liczba stron ukrywa trudne części: uprawnienia, importowane rekordy, systemy zewnętrzne, odzyskiwanie po awarii i dowody potrzebne przed wydaniem. Dwa produkty z pięcioma ekranami mogą zatem wymagać bardzo różnych ilości pracy.

Przykład roboczy

Rozważ przykładowy portal dostawcy. Załóżmy, że 8 dni na odkrycie i projekt, 15 na główny przepływ pracy, 6 na integrację, 5 na weryfikację i 3 na przygotowanie wydania: 37 osobodni. Są to wymyślone założenia dotyczące planowania, a nie wycena ani wskaźnik rynkowy. Mnożenie ich według uzgodnionej stawki dziennej prowadzi do oszacowania siły roboczej; hosting i bieżące wsparcie pozostają odrębne.

Zmień szacunki w rejestr zakresu

Dokonać kontroli szacunkowej poprzez oddzielenie każdego strumienia pracy od obiecanego wyniku, założenia, właściciela i dowodów akceptacji. Dla portalu dostawcy "integracja" jest zbyt szeroka, aby dokonać przeglądu. Lepszy wpis mówi, że zatwierdzone zamówienie dociera do dostawcy raz, otrzymuje zewnętrzne odniesienie i pozostaje widoczne, gdy dostawa zawiedzie. Obok niego należy określić, czy dostawca oferuje rachunek testowy i kto go dostarcza. To zapobiega niskiemu oszacowaniu, w zależności od niezapłaconej pracy przez kogoś innego. Poproś każdego oferenta o taką samą strukturę, tak aby można było porównać różne ceny z tymi samymi obowiązkami.

Cena wyjątków tak celowo jak głównej trasy

Wybierz kłopotliwe zamówienie i przejść przez rejestr: jeden element jest wycofany, adres dostawy zmienia się po zatwierdzeniu, a dostawca odpowiada późno. Która praca jest już w oszacowaniu? Które założenie jest teraz fałszywe? Przydatny przegląd zmienia raczej konkretny kierunek niż ponowne otwarcie całego wniosku. Jeśli brakuje dowodów, uzgodnij małe dochodzenie i decyzję, która zostanie otwarta. Nie myl sytuacji awaryjnej z pozwoleniem na rozszerzenie produktu: sytuacje awaryjne obejmują niepewność w ramach obietnicy, podczas gdy nowa obietnica wymaga decyzji w zakresie.

Utrzymać koszt uwolnienia oddzielony od kosztów własności

Po pierwszym wydaniu, ktoś musi sprawdzić kopie zapasowe, zastosować aktualizacje, zbadać nieudane transfery i odpowiedzieć na pytania operacyjne. Zdecyduj, czy te obowiązki należą do przedsiębiorstwa, studia lub innego dostawcy i opisać przekazanie między nimi. Zapytaj, w jaki sposób wniosek o wsparcie staje się autoryzowanym rozwojem, zamiast zakładać, że wszystkie przyszłe zmiany zostaną uwzględnione. Przed zaakceptowaniem oszacowania należy zweryfikować test akceptacji próby, wymienione wyłączenia, opłaty zewnętrzne, własność rachunków oraz postępowanie w przypadku niewykorzystanych środków awaryjnych. Celem nie jest przewidywanie każdej przyszłej faktury; jest to podejmowanie późniejszych decyzji, które można ustalić w porozumieniu, które obie strony mogą zrozumieć.

Alternatywy warte ważenia

Poproś o zakres, w którym niepewność jest prawdziwa. Udokumentowany dostawca API pozwala na węższą ocenę integracji niż nieudokumentowany wywóz. Niewielkie płatne odkrycie może rozwiązać tę niepewność; stały zakres może działać, gdy przykłady akceptacji i zależności są już znane. Żaden model ustalania cen nie eliminuje potrzeby określenia odpowiedzialności.

Gdzie plan się psuje

Nie należy ukrywać czyszczenia danych wewnątrz projektu ani traktować testów jak pozostałego czasu. Zapis tego, co szacunkowe wyklucza i które decyzje klientów mogą ją zmienić. Dodać nieprzewidziane ryzyko, takie jak brakujące referencje, a nie niewyjaśniony procent.

Przed zleceniem pracy

Przed uruchomieniem, zapytaj, kto dostarcza przykładowe dane, kto zatwierdza zasady dostępu i co liczy się jako zakończona transakcja. Przynieś te odpowiedzi na niestandardową dyskusję o oprogramowaniu. Przydatne oszacowanie wyjaśnia jego założenia i kolejne dowody, które mogą je zmienić.

Usługi

Oprogramowanie na zamówienie

Oprogramowanie dopasowane do sposobu działania Twojej firmy.

Porozmawiaj o tej usłudze