precyzja specyfikacji

dostarczamy <baczność> klientowi </baczność> specyfikacje nowych rozwiązań dla naszego super-systemu. Specyfikacje zawierają rozbudowany opis rozwiązania, od wymagań technicznych poprzez specyfikację biznesową do procedur testowych (później taka specyfikacja trafia do klepaczy kodu). Jednym z najważniejszych wskaźników jest estymowana ilość czasu, jaka będzie wymagana do wdrożenia danej funkcjonalności. Biorąc taką dokumentację do ręki, <baczność> klient </baczność> akceptuje rozwiązanie o danym koszcie (każda godzina to koszt) lub nie (jeśli uzna że to zbyt dużo). Dlatego oczekuje, że później w trakcie implementacji ilość godzin nie przekroczy wartości wpisanej w specyfikacji. So far - so good. Z drugiej strony atakują nas wskaźniki precyzji specyfikacji. Wskaźnik taki określa, w jakim stopniu trafnie określamy czas podany w specyfikacji. Cel - precyzja specyfikacji równa 100%. Nasza szklana kula do wróżenia jest w serwisie, a fusów w kawie nie mamy - firma poi nas rozpuszczalną. Z tego powodu nie zawsze da się poprawnie wyznaczyć ilość godzin. Jeśli wyznaczymy za mało - jest dym bo przecież było x a tymczasem wdrożenie wymagało x+y. Wskaźnik precyzji leci na łeb. A co dzieje się w przypadku, gdy wyznaczyliśmy x, a wdrożenie zajęło wiele mniej czasu? (wierzcie mi, takie sytuacje w projektach IT się zdarzają;) ) Wtedy obciąża się <baczność> klienta </baczność> na x godzin, by nie psuć wskaźnika precyzji. Gdyby pominąć ten głupi wskaźnik, <baczność> klient </baczność> często płaciłby mniej, ale wskaźniki czegoś-tam są zawsze najważniejsze.