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.

Analiza przedwykonawcza
Analiza przedwykonawcza

 

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.

Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterzeLinkedIn lub subskrybuj mój kanał YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).

 

Advertisements

7 komentarzy do “Gdy klient mówi „chciałbym elastyczny system…” – czyli analiza przedwykonawcza

  1. Ciekawy wpis! Dobrze, że ta tematyka jest poruszana. W mojej w sumie ponad 10-letniej pracy w IT zauważam przede wszystkim (pomimo wykonywania studiow wykonalnosci, analiz przedwdrozeniowych, dokumentacji i projektu systemow) trudność ze zrozumieniem pojęcia „elastyczność aplikacji/kodu/oprogramowania”. Nawet w firmach o mocnej podstawie IT, jeśli zmiany w oprogramowaniu są wyceniane na więcej niż te przysłowiowe 2 dni często spotykamy się z odpowiedzią – „ale przecież zamawialiśmy oprogramowanie elastyczne a teraz na zmiany potrzebujecie 2 tygodnie”. W sumie cały czas się zastanawiam jak dobrze zdefiniować tą „elastyczność” aby obie strony (a nie tylko jedna) wiedziały co to dokładnie znaczy i w jakich to się mieści granicach.

    Liked by 1 osoba

    • Dzięki za komentarz.
      Ja staram się jak najwięcej informacji przekazać w dokumencie analitycznym, w którym staram opisać się projekt „w negatywnym świetle” – żeby klient miał świadomość wszystkich restrykcji, które z sobą niesie.
      Ostatnio sprawdziło mi się ciekawie podejście, w którym przed realizacją omówiłem z klientem na ile będzie można system modyfikować i ile czasu zajmą zmiany. W skrócie był to system do przeprowadzania ankiet – wytłumaczyłem od podstaw, że edycja treści pytania nie stanowi problemu, ale np dodanie nowego typu pytania z „wodotryskami” jest już kłopotliwe, ale możliwe. Po tej rozmowie było dużo prościej wyciągnąć mi edytowalne rzeczy w panel administratora – klient określił co na przestrzeni czasu prawdopodobnie ulegnie zmianie, a co zostanie stałe. To pozwoliło dobrać „elastyczność” projektu.
      Moim zdaniem elastyczność projektu to możliwość wprowadzania „szybkich” zmian, dopasowanych pod klienta.

      Liked by 1 osoba

      • Dziękuję za odpowiedź! Mój case ostatnich tygodni był taki, że klientowi wprowadzaliśmy system abonamentowy dla jego usługi on-line. System polegał na obciążaniu klienta w ramach czasowych (czyli kupujesz abonament na rok, a jak kupujesz na 2 lata to masz np. 20% taniej). Klient mial od nas zapewnienie, że system jest elastyczny i w razie zmiany np. częstotliwości pobrań opłat na miesięczne – będzie to prosta i szybka zmiana. Tyle w teorii. Po paru miesiącach faktycznie wrócił do nas z prośbą o zmiane, jak to ujął „kosmetyczną”. Teraz klienci mieli płacić nie abonament w ujęciu czasowym ale za konkretne usługi premium w serwisie w formie jednorazowej a niektóre automatycznie odnawialne.

        Nawet ciężko mi teraz opisać ile czasu i energii poświęciliśmy na wytłumaczenie klientowi, że to nie jest kosmetyczna zmiana i wiąże się ze zmianą logiki dość sporej części aplikacji i nie da się tego zrobić w 1 dzień.

        Klient z branży (więc powinien zrozumieć) ale nawet przy tak oczywistym przypadku system automatycznie został oceniony jako „nieelastyczny”. 😉

        Lubię

  2. Problem tkwi w tym, że klient nie jest osobą techniczną. Często oceniają prachochłonność poprzez część wizualną. Czyli jeśli dodamy button, który wykonuje 50 operacji to będzie „proste i szybkie zadanie” bo przecież dużo się nie zmieniło w programie/stronie.
    W twoim przypadku myślę, że mogłoby się sprawdzić ciekawie, gdyby przed wykonaniem projektu określić klientowi elementy, które będzie łatwo modyfikować. Np. zmianę 20% na 18% czy 30% będzie stosunkowo łatwo wprowadzić, ale zmianę logiki kupowania to czasami przepisanie na nowo.

    Lubię

      • Dokładnie – to o czym rozmawiamy to teoretyczne przyczyny. Czasami niestety ograniczenia biznesowe sprawiają, że nie jesteśmy w stanie wprowadzić tych założeń w życie. Mimo to warto o nich wiedzieć i rozumieć jak to działa – pomoże nam to przeciwdziałać i gasić mniejsze pożary 🙂

        Lubię

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s