Gdy klient mówi "chciałbym elastyczny system…" – czyli analiza przedwykonawcza

W ostatnim czasie sporą część dnia pracy zajmuje mi robienie analiz IT. Zazwyczaj uczestniczę w całym procesie powstawania produktu: spisanie wymagań klienta => opracowanie dokumentu analitycznego => development. Dzięki temu, że jestem obecny we wszystkich procesach, jestem świadkiem wielu „zabawnych” (z perspektywy czasu 😉 ) sytuacji o tym jak mimo ustaleń, oczekiwania i wyobrażenia klienta o finalnym produkcie mogą odbiegać od wcześniejszych założeń – to będzie tematem dzisiejszego wpisu. Zapraszam do lektury.

Według mnie analiza przedwykonawcza ma największy wpływ na terminowość projektu. To jak dogłębnie dotrzemy do (faktycznych) potrzeb klienta wpłynie na ilość końcowych poprawek i satysfakcję. Jeśli podczas analizy nie uda nam się dotrzeć do faktycznych potrzeb to pozostałe etapy czyli prowadzenie projektu, implementacja (development) są z góry skazane na porażkę. Klient nie zaakceptuję czegoś, czego nie chciał – tym samym rozpocznie się seria poprawek i zmian w zakresie. Efektem jest to, że obie strony narzekają na współpracę, bo „klienta ponosi fantazja”, a wykonawca „nie potrafi zrobić dobrze swojej roboty”. Żadna ze stron nie ma racji – przyczyną jest złe ustalenie celu projektu. Cel projektu może być źle ustalony m.in. wtedy gdy analityk zamienia się w dyktafon – słucha i spisuje, bez kwestionowania poprawności i zasadności. Bo zawsze można się tłumaczyć słowami –  „przecież dokładnie to powiedziałeś”. Analityk zapomina w tym momencie, że klient nie musi myśleć analitycznie – on płaci nam za to, żebyśmy to my tak myśleli.

Dobry analityk nie powinien dopuścić do tego, żeby klient opowiadał o tym jak należy wykonać projekt. On ma opowiadać o tym, co chce osiągnąć po jego realizacji. 

Wpis o rozróżnianiu celu i zakresu jest najczęściej linkowanym przeze mnie wpisem – bez poprawnego zrozumienia tej kwestii można popełnić wiele błędów. Klient musi opowiedzieć o celu projektu (potrzebach), a nie o sposobie realizacji (zakresie). Sposób realizacji projektu (zakres) powinien być dobrany na podstawie potrzeb projektu (celu). Jeśli dzieje się inaczej, jesteśmy świadkami funkcjonalności, których nikt nie używa, a zajęły mnóstwo czasu programistów. Poniżej umieściłem „oklepany” obrazek, który pokazuje realne skutki złej analizy przedwykonawczej.

Na temat prowadzenia analizy przedwykonawczej szykuję odrębny wpis, więc nie będę go dalej rozwijał w tym miejscu.

Podczas przeprowadzania analizy z klientem, często słyszałem zdanie „chciałbym, żeby to zostało napisane elastycznie…”. Z mojego doświadczenia wiem, że jeśli pada to zdanie to w procesie analizy został popełniony błąd.

1. Klient opowiada o sposobie realizacji (zakresie), a nie celu (korzyści z ukończenia)
2. W ustach klienta „napisać elastycznie” znaczy „żeby było można to przerobić w coś zupełnie innego, bo jeszcze nie jestem pewien czego chce„. Jeśli klient nie wie czego chce, to trzeba mu pomóc to znaleźć – inaczej utoniemy w gąszczu poprawek, projekt straci rentowność, a wszystkim przybędą siwe włosy.

„Pisanie elastycznie” bardzo często bywa zostawianiem sobie furtki do zmian, bo przecież było powiedziane, że ma być elastycznie, więc „jak to nie możemy przerobić tej strony WWW w aplikację desktopowa w 2 dni?” – to oczywiście bardzo jaskrawy przykład, żeby zobrazować co mam na myśli 🙂 Często wracając do spisanych wymagań i na nowo je kwestionując dochodziłem do faktycznych potrzeb klienta, wtedy nie czuł potrzeby żeby system był napisany elastycznie – nie potrzebował „furtki do zmian” bo odkrył czego chce i jest pewien, że to co ustaliliśmy będzie przydatne. Ja dzięki temu minimalizuję ryzyko poprawek – win:win.

Podsumowanie

Analiza przedwykonawcza jest najważniejszym etapem realizacji projektów IT. To od niej zależy jakim ryzykiem obarczona jest terminowość projektu. Czym więcej uda nam się zaplanować przed realizacją tym zakres będzie bardziej stały. Staraj się nie dopuścić by klient opowiadał o tym jak zrealizować projekt, skup się na tym czego potrzebuje – kwestionuj każde wymaganie. Z mojego doświadczenia (twoje może być inne 😉 ) wynika, że jeśli klient mówi o „elastyczności systemu” świadczy to o tym, że nie jest pewien finalnej wizji produktu – pomóż mu ją określić. Są też oczywiście przypadki beznadziejne, kiedy nie jesteśmy w stanie tego zrobić – zobacz więc jak wycenić projekt IT w 10 minut.