Agile business analyst has the capability to keep the wheel rolling. They?re a transformative funnel through which a requirement passes down to the delivery path towards an expected outcome. This…
Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty "na żywioł". Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany "maintenance") niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.
A co mówią statystyki? Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com). Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych... Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających "kastomizacji" bo to (nowe funkcjonalności systemu) także projekt dedykowany.