Zarządzanie projektami, zespołem i analiza IT

Analiza IT

Dlaczego dokument analityczny powinien opisywać projekt w negatywnym świetle?

Dokument analityczny to ważny element projektu. To jak zostanie napisany decyduje o satysfakcji klienta. W tym wpisie opisałem swoje doświadczenia i przemyślenia wraz z odpowiedzią na pytanie „dlaczego dokument analityczny powinien przedstawiać projekt w negatywnym świetle”. Zapraszam do lektury!

Dokument analityczny nie sprzedaje produktu!

Często czytając dokumenty analityczne mam wrażenie, że projekt, który został w nich opisany jest idealny i zbawi świat. Każda funkcja jest opisana w samych superlatywach. Dzieje się tak dlatego, że autor w dalszym ciągu próbuje sprzedać produkt. W większości przypadków jeśli powstaje dokument analityczny to projekt jest już „sprzedany” – czyli został wstępnie oszacowany kosztowo i ta cena została zaakceptowana przez odbiorcę. Cel tworzenia dokumentu analitycznego jest zupełnie inny – po jego stworzeniu ma być wyklarowana finalna wizja projektu – jego efekt końcowy. Wszystkie funkcje powinny być uzasadnione, a ich realizacja powinna zostać zaplanowana używając jak najmniejszego nakładu pracy. Im szybciej coś wykonamy, tym taniej nas to wyniesie, dokument analityczny nie powinien nadmuchiwać „balonika cenowego” – od tego jest dział sprzedaży, którego działanie powinno poprzedzić etap analizy przedwykonawczej.

Satysfakcja z realizacji

Moim zdaniem nie ma lepszego marketingu niż rekomendacja zadowolonego klienta. Warunkiem koniecznym w uzyskaniu satysfakcji przez klienta jest to, że finalny produkt będzie wyglądał dokładnie tak jak oczekiwał/wyobrażał go sobie. Moment, w którym klient uświadamia sobie jak będzie wyglądał projekt po realizacji następuje po przeczytaniu dokumentu analitycznego i ostatecznemu zatwierdzeniu go – że to jest dokładnie to, czego chciał. Właśnie dlatego dokument analityczny powinien opisywać projekt w negatywnym świetle. Używając sformułowania „negatywne światło” mam na myśli to, że dokument powinien zawierać przede wszystkim:

  • ograniczenia funkcjonalne – czyli to czego nie będziemy mogli robić w systemie. Często to nie jest dla klienta jednoznaczne, zwłaszcza jeśli buńczucznie nazywamy małe funkcjonalności wielkimi słowami. Z mojego doświadczenia często spotykałem się z rozjazdem w „Raportach”, które brzmią ciekawie, a często zrealizowane raporty nie dostarczają tego co klient oczekuje.
  • planowane niedociągnięcia funkcjonalne – często niektóre z funkcjonalności zawierają planowane niedociągnięcia. Np pominięcie weryfikacji wprowadzania danych przez administratora ponieważ to administratorowi będzie zależało na wprowadzeniu poprawnych danych. Dzięki temu można zredukować roboczo godziny pracy. Kluczowe jest żeby nie tworzyć nieprzemyślanego systemu poprzez „niedociągnięcia funkcjonalne” tylko je zaplanować i zastosować tam gdzie można – oczywiście informując o tym klienta.
  • problemy, których nie rozwiązuje – tworząc dokument analityczny często próbuję „wcielić się w klienta” – to pozwala mi na wymyślenie alternatywnej interpretacji funkcji projektu. Te alternatywne interpretacje, trzeba zanegować – musimy mieć pewność, że rozmawiamy o tym samym. Dzięki temu unikniemy komentarzy klienta w stylu: „myślałem, że to również wykona za mnie XYZ, nazwa jest podobna, pewnie byście to zrobili w kilka minut!”.
  • sytuacje, w których projekt jest awaryjny – każdy system jest awaryjny, tylko niektóre z nich mają nieokreślone zakresy awaryjności – przez co ich autorzy mylnie uważają je za bezawaryjne. Moim zdaniem należy skupić się na określeniu sytuacji, w których poprawnie zaimplementowane funkcje projektu przestaną działać. Wbrew pozorom może okazać się, że sytuacje, w których system będzie awaryjny są kluczowe dla klienta. Jeśli tego nie odkryjesz na etapie analizy – nie uzyskasz satysfakcji klienta, bo dla niego produkt okaże się nieprzydatny.
  • fragmenty, których rozbudowa będzie trudna – projekty IT mają to do siebie, że są rozbudowywane i powinny być skalowalne. Określ klientowi fragmenty funkcji, których rozbudowa będzie trudna/droga lub wręcz niemożliwa. Wbrew pozorom dla osoby nietechnicznej (jaką jest często klient) nie jest to łatwe do przewidzenia. Taki akapit w analizie może wiele wyjaśnić. Rzuć okiem na mój wpis o tym gdy klient mówi „ale przecież miało być napisane elastycznie!!!!” – analizie przedwykonawczej.

Jeśli opiszesz te „negatywne strony” projektu, możesz uniknąć wielu zmian zakresu podczas realizacji. Prawdopodobnie unikniesz też rozczarowania klienta i uda ci się uzyskać jego satysfakcję. Klient dostanie „to czego chciał”.

Analiza przedwykonawcza
Analiza przedwykonawcza

Podsumowanie

Osoba odbierająca projekt (klient) powinien czuć satysfakcje z odbieranego dzieła – dlatego powinieneś mu je przedstawić ze wszystkimi niedociągnięciami, które wchodzą w jego skład. Nie robiąc tego – tworzysz produkt, który ładnie wygląda tylko „na papierze”. Komunikacja z klientem to jedna z najtrudniejszych rzeczy, stosując się do wskazówek z tego artykułu wciąż nie masz pewności, że „mówicie o tym samym” z klientem. Jednak zastosowanie się do tych porad minimalizuje to ryzyko. Pamiętaj też, żeby nie tworzyć dokumentu z myślą o sprzedawaniu projektu – ten etap powinien być zrealizowany przez dział sprzedaży i ukończony przed podejściem do analizy.


Dziękuję, że przeczytałeś ❤️

Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.