No to mamy ciekawostkę, … ale czy zaskoczenie :)?
W 2008 roku firma Jama Software przeprowadziła ankietę wśród 203 pracowników firm IT. Oto najciekawsze wnioski, które można wyczytać w raporcie stworzonym na postawie ankiet:
„Zdobycie umiejętności lepszego zrozumienia potrzeb klienta” oraz „dokumentowanie wszystkich wymagań” były wymieniane jako dwa najważniejsze wyzwania w badanych firmach. Przychodzi mi tu na myśl to o czym pisał ostatnio Seth Godin.
34% projektów zawiera od 100 do 500 wymagań, , 22% to mniej niż 100 wymagań, natomiast 19% projektów musi sobie radzić nawet z 1000 wymagań.
Zmiany w wymaganiach są powszechne: 37% uczestników badania stwierdziło, że każdego tygodnia muszą poświęcać od 10 do 15% czasu na radzenie sobie ze zmianami w wymaganiach, 24% poświęca mniej niż 10% swojego czasu, a 23% poświęca nawet 50% czasu w tygodniu na problem zmian w wymaganiach.
Jakie są najczęstsze problemy w nieudanych projektach? 70% to zmiany zakresu projektu, 66% to nieokreślone lub słabo udokumentowane wymagania, i podobnie 66% to nierealistyczne oczekiwania i harmonogramy. Jak widzicie pierwsze dwa problemy są ściśle związane z wymaganiami.
83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do zbierania wymagań i komunikacji z klientem.
67% zespołów chciało by zacząć korzystać z narzędzi do zbierania i zarządzania wymaganiami, 55% potrzebuje narzędzi do modelowania i wizualizacji wymagań.
Brzmi to dla Was znajomo? (źr. Raport Jama Sofware ? O wymaganiach).
Najciekawsze jest to, że im większa firma IT tym bardziej mam do czynienia z tym: „83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do zbierania wymagań i komunikacji z klientem.”
Teraz popatrzmy co nam dostarczają najwięksi liderzy naszego rynku IT w swoich projektach….
Jednak na szczęście poza takimi jak powyższe badania, mam przed sobą książki pisane przez „wielkich”. Coraz bardziej lubię książki pisane przez ludzi, którzy po np. 30 latach pracy jako programiści, projektanci, architekci piszą: można projektować i trzeba.
Twierdzenia, że nie da się inaczej, klienci nie wiedzą czego chcą, dokumenty tekstowe to jedyne możliwe opisy wymagań itp. są prostu nie prawdą, to usprawiedliwienia braku kompetencji albo zawyżania kosztów projektów (a raczej pokrywania braku kompetencji pieniędzmi z kieszeni klientów). Pewien znajomy, współwłaściciel pewnej firmy programistycznej, napisał mi niedawno: „korzyści z takiego dokumentowania wymagań są ogromne. Wykonawca, który potrafi pracować na modelach ma 2-3 krotnie niższe koszty i 1,5-4 krotnie krótszy czas wykonania. AMEN TO THIS:)” A co on miał na myśli?
O jakie dokumentowanie chodzi? O takie: http://modelowaniebiznesowe.biz.pl/. Ta cytowana firma to mój partner (albo ja jestem ich partnerem, sam już nie wiem ;))), efekty? Rok temu projekt wykonany razem (analiza, projekt, implementacja) tą metodą, był łącznie tańszy (po zakończeniu!) trzykrotnie niż inne oferty, trwał dwukrotnie krócej niż pozostałe oferty. Projekt został oddane w pierwotnym terminie i budżecie a nie był to trywialny projekt (powyższe przykłady to małe demo metody a nie kompletne projekty).
Na koniec kilka innych przykładów z innego źródła:
Czy to ma sens? Widać, że ma a kryzys zmusza do myślenia:
Według analityków firmy Panorama Consulting w 2010 roku firmy z większym niż wcześniej zaangażowaniem podchodziły do kwestii analizy przedwdrożeniowej, ustalenia celów biznesowych, wyboru systemu i dostawcy, a także do realizacji samego projektu wdrożeniowego. Zdaniem ekspertów to bezpośredni skutek załamania rynku oprogramowania biznesowego sprzed dwóch lat – większe zaangażowanie dostawców wymusiły przybierające na sile działania konkurencyjne, natomiast klienci zaczęli uważniej analizować wydatkowane środki, na bieżąco śledzić postępy prac i precyzyjniej definiować biznesowe cele projektów wdrożeniowych. (źr. Mniejsze budżety + krótsze wdrożenia = większe korzyści z systemów ERP? : ERPstandard.pl – systemy ERP, CRM, BI, wiadomości, porady, prezentacje.)
Na zakończenie
Kilka lat temu (ok. 2005 roku, niestety nie pamiętam dokładnej daty…) firma IBM opublikowała wyniki swoich badań na ponad 500. zakończonych projektach u klientów swoich i u przejętych firm. Co się okazało.
Praktyka pokazuje, że czas i środki poświęcone na analizę wymagań (obejmuje ona także projekt logiki biznesowej) istotnie skracają proces implementacji (która zawiera projektowanie szczegółów architektury implementacji). Głównym źródłem oszczędności jest wypracowany na początku i przetestowany model logiczny systemu dzięki czemu praktycznie unikamy pętli odkrywania nowych wymagań, nowych ?faktów? już na etapie implementacji. Nie ma miejsca zjawisko opisywane przez programistów: „klient nie wie czego chce, a my dostarczamy to co mamy”. Nie występują więc najbardziej kosztowne poprawki systemu, w tym poprawki modelu danych. W dobrze prowadzonym projekcie analiza jest powtarzana tylko w celu wytworzenia nowej wersji systemu. Korzyści odnoszą tu i klient i wykonawca:
- System jest tańszy i dostarczony w krótszym czasie – korzysta klient,
- Dotrzymane zakładane termin i pracochłonność to zachowanie pierwotnej planowanej marży ? korzysta wykonawca, w kontraktach fixed-price każde opóźnienie to utrata zysku,
- Ryzyko porażki projektu sprowadzone do minimum ? korzystają wszyscy.
Tak to wygląda:
Niestety powyższe obrazuje dlaczego tak wielu dostawców oprogramowania przekonuje swoich klientów do tezy, że analiza to zbędny koszt: ich pracochłonność – wartość kontraktu – maleje! Klient podpisując umowę, zna jej wartość ale nie zna szczegółów kalkulacji… dlatego podpisuje nie wiedząc, że wybrał wariant pierwszy na powyższym diagramie.
To także powód by nie pytać dostawców o wykonanie analizy bo jak widać będę one z reguły tańsze, rzetelna analiza i projekt nie leży w interesie dostawcy. Dlatego – podobnie jak w innych dziedzinach inżynierii – należy najpierw wykonać projekt analityczny a potem dopiero wybierać jego wykonawcę.
