a raczej jej brak…Bo taki tytuł powinien nosić ten post. Firmy produkujące oprogramowanie traktowane są często przez Klientów jak supermarkety, do których wchodzimy wybieramy produkt i wychodzimy….Przeanalizujmy właśnie wybór produktu z tej perspektywy, a później przenieśmy to na płaszczyznę bardziej techniczną…..

Zachorowaliśmy…… Mamy dwa wyjścia – albo sami dokonamy analizy swojego stanu zdrowia, albo pójdziemy od razu do lekarza….Analizując samodzielnie swój stan zdrowia wpisujemy pierwsze symptomy do wyszukiwarki i ku naszemu przerażeniu stawiamy sobie wstępną diagnozę, zamiast jednak wpadać w czarną rozpacz udajemy się do pobliskiej apteki przedstawiając nasze objawy w nadziei, że dostaniemy na nie antidotum….dostaliśmy zalecenia jak co i kiedy spożywać, stosujemy się do zaleceń farmaceuty, ale z dnia na dzień jest coraz gorzej….podwajamy sobie dawkę – bo być może farmaceuta nas nie zrozumiał…..stan się jeszcze pogorszył…..w ostateczności udajemy się do lekarza, który przeprowadza z nami wywiad, robi badania, na podstawie których stawia diagnozę, wypisuje receptę oraz dawkę leków….Po kilku dniach po chorobie nie ma ani śladu….. Po chorobie dochodzimy do wniosku, że w sumie od razu mogliśmy udać się do lekarza, nie dość, że zaoszczędzilibyśmy czas to również pieniądze…

Analogicznie jest z Klientami i udziałem Analityka w projektach… Niestety świadomość wartości analizy w projektach jest niedoceniania przez większość Firm, bowiem dla nich analityk to osoba, która ” coś tam pisze”, albo jeszcze gorzej: “wytwarza niesamowitą ilość ich zdaniem zbędnej dokumentacji”…Według wielu z nich prace szybciej byłyby wykonane, gdyby od razu przystąpił do nich programista, który niemalże przy nich pisałby kod a po spotkaniu powstałaby notatka”. Jest to jedynie pozorne przyspieszenie, bowiem programista nie będzie się zastanawiał co się stanie linijkę kodu dalej, czy aby przypadkiem nie należy w bazie danych dodać nowej tabeli, skąd w ogóle mają być pobierane dane, czy pisane przez niego rozwiązane ma coś wspólnego z ergonomią, no i w końcu czy tworzona funkcjonalność jest na tyle elastyczna, aby można było w prosty sposób ją modyfikować i rozwijać?

Programista po prostu pisze…..

Analityk musi patrzeć na funkcjonalność w szerszej perspektywie, przewidzieć wszystkie scenariusze na zasadzie, a co jeśli taki Użytkownik wpisze zamiast cyfry literę? A co jeśli będzie chciał usunąć parametr, który jest powiązany z 4 innymi parametrami? Może to wykonać? Czy ma się wyświetlić jakiś komunikat w systemie? Tego akurat nie przewidzi programista. Programista nie będzie dopytywał się na spotkaniu z Klientem – no dobrze, a co musi się stać z punktu widzenia biznesowego, aby proces mógł toczyć się dalej? Kto bierze udział w procesie? Co z uprawnieniami itp. Klient powie programiście: Użytkownik musi mieć możliwość usunięcia tego parametru….Programista w kodzie wstawi taką możliwość…..Analityk przed wpisaniem takiej funkcjonalności zacznie lawinę pytań wymuszających u Klienta zastanowienie się nad sensem i konsekwencjami działania takiej funkcjonalności. I nagle okazuje się, że musi pojawić się komunikat informujący o tym, że parametr jest powiązany z parametrem takim i takim i czy chce usunąć. Że po usunięciu parametru pojawi się komunikat, że parametr został usunięty poprawnie. No i w końcu, że usunąć dany parametr może tylko Użytkownik z uprawnieniami administratora, czyli nie każdy Kowalski…..

Co do papierologii……Nie jestem jej zwolennikiem, jak również robienia z analizy biznesowo-systemowej powieści, którą dobrze się czyta jedynie do poduszki, ale w większości przypadków odbiorcami dokumentacji są osoby nietechniczne i przedstawienie im diagramu klas powoduje u nich wybałuszenie oczu wielkości co najmniej dwuzłotówek. Zatem staramy się opisywać funkcjonalności na tyle zrozumiale dla zwykłego Kowalskiego co i dla programisty….Stąd im większy system tym więcej szczegółów  i scenariuszy alternatywnych w dokumentacji co powoduje zwiększanie jej objętości….ale czy mamy inne wyjście? Na razie chyba nie….

Co musi się stać, aby świadomość analityczna Klientów była większa? Otóż praca analityczna musi mieć swoją cenę, zgodnie z zasadą, że jeśli coś jest drogie to widocznie jest wartościowe (oczywiście w gigantycznym skrócie)….zaraz pewnie pojawi się argument – Panie czemu tak drogo…..Wówczas można przeprowadzić wdrożenie bez udziału Analityka, ale koszty i tak ostatecznie będą większe, bowiem tak jak w przypadku lekarza, dopiero udział Analityka w projekcie uświadomi Klientowi, że niepotrzebnie wydał pieniądze na rozwiązania, które tylko na początku wydawałoby się, że są tym czego Klient szukał, jednak nie rozwiązywały źródła problemu, który wykrył Analityk…

Z początku wszystko wydaje się banalnie proste. Bo cóż jest trudnego w zrealizowaniu tego co zamawiał Klient. Siadamy jako Analitycy i piszemy…..i piszemy….i rysujemy…..myślimy….wymyślamy…znowu rysujemy a później opisujemy….i tak kółko. Na końcu powstaje opasły dokument, który w części przypadków nie spełnia potrzeb Klienta, dla którego został wytworzony. I zachodzimy ( o ile mamy w sobie trochę pokory w sobie) w głowę czemu się tak rozminęliśmy z potrzebami Klienta, przecież rozmawialiśmy z nim na początku- wszystko wydawało się jasne… No właśnie na początku….ale może po kolei…

Obecnie rynek rozwiązań proponowanych przez różnych dostawców oprogramowania dynamicznie się rozwija, a co z a tym idzie wzrasta konkurencja- co jest bardzo dobre z punktu widzenia Konsumenta, jak również potrzeby biznesowe Konsumenta (naszego Klienta) ulegają zmianie w czasie… Jeśli szybko nie będziemy na nie reagować podczas tworzenia dokumentacji czeka nas efekt jak to nazywam “czkawki”, ale o tym za chwilę….

Na całe szczęście coraz więcej Firm poszukuje Analityków, którzy są również swego rodzaju Konsultantami dla Klienta. Na całe szczęście, ponieważ część Analityków wysłuchuje Klienta, zadaje kilka szablonowych pytań i z takim arsenałem zasiada do pisania dokumentacji. Niewielu ( a być może się mylę- oby) fatyguje się, aby poświęcić czas na dokładną analizę procesu, który chce zmienić/usprawnić Klient. Dlaczego to takie ważne. Otóż wielu z nas pamięta, czym różni się Handlowiec od Analityka? Tym, że Handlowiec mając produkt będzie chciał za wszelką cenę wmówić Klientowi, że tego potrzebuje, natomiast Analityk będzie się zastanawiał czy ten produkt spełnia oczekiwania Klienta i zaspokaja potrzeby biznesowe. Zatem zabierając się do analizy wymagań biznesowych- nie tylko tych wypowiedzianych przez Klienta, zabieramy się za analizę kilku obszarów.

1. Analiza otoczenia rynkowego Firmy Klienta

Tak jak wspomniałam wyżej, ciągle trzeba śledzić kierunki rozwoju naszej konkurencji bezpośredniej, ale również potencjalnej. Z czym ważniejsza z punktu widzenia jest konkurencja potencjalna. Dlaczego? Aby zilustrować i wskazać zagrożenia wynikające z pominięcia potencjalnej konkurencji pozwolę posłużyć się przykładem: nowego portalu społecznościowego: Google+.

Wśród wielu portali społecznościowych w Polsce największą popularnością cieszyła się :NK (obecnie w mniejszym stopniu- ale to omówię przy okazji), grono.net (kiedyś potentat na rynku, obecnie zaledwie udział w 15% rynku), eplus oraz Facebook. Z czego ten ostatni święcił triumfy do czasu pojawienia się nagle nowego portalu: Google+. Po jego pojawieniu się zdania były podzielone: jedni twierdzili, że Google przespało okres, kiedy rodziły się na rynku portale społecznościowe aby mógł odnieść większy sukces, oraz drudzy, do których ja się zaliczam, że było to celowe działanie, aby stworzyć portal będący kompilacją najlepszych rozwiązań oferowanych obecnie na rynku. I czy tak nie jest? Niedawno mogliśmy zaobserwować oddziaływanie nowego portalu społecznościowego na potrzeby biznesowe Konsumentów poprzez podjęcie kroków przez Facebook umożliwiających ulepszenie ustawień prywatności, które są lepiej rozwiązane w Google+. Zatem nowy gracz na rynku- co jest oczywiste zaczyna kreować potrzeby biznesowe, a doskonale wiemy jak się to kończy. Większość Konsumentów zaczyna wymuszać na dostawcach rozwiązań określone rozwiązania.

Oprócz konkurencji nie można przespać tendencji rozwojowych samego rynku. Bowiem może okazać się, że technologia, w której tworzymy nasze rozwiązania zostaje wypierana przez inne lepsze- albo może lepiej to ujmę- bardziej pożądane przez Odbiorców-rozwiązania.

2. Analiza procesów występujących w Firmie Klienta

Wycinek procesu, który został wydelegowany do “poprawy” nie daje nam pełnego obrazu sprawy. A co za tym idzie, być może jego słaba wydajność zależy od innych procesów występujących w Firmie. Dlatego zapoznanie się z całym łańcuchem procesów jest takie istotne. Dodatkowo jeśli Klient jest pod naszą opieką jesteśmy w stanie zaproponować mu rozwiązanie będące usprawnieniem większości procesów bez udziału oprogramowania.

3. Zakres wsparcia oprogramowania w Firmie Klienta

Po analizie procesów występujących w Firmie znamy już, które z nich będą wymagały wsparcia od strony oprogramowania, a które jedynie usprawnienia samego procesu poprzez rekomendowanie rozwiązań typu: skrócenie okresu oczekiwania na decyzję itp.

4.Przepływ danych w Firmie Klienta

Dokument jest stworzony. Zawarte w nim są omówione wyżej etapy i nagle programista zgłasza problem. Otóż nie wie jakiego typu dane uczestniczą w danym procesie. Czy są jakieś wyjątki, jak wygląda przesyłanie oraz przetwarzanie tych danych w kolejnych procesach, skąd wychodzą i gdzie wchodzą owe dane…..

Na czym polega efekt czkawki? Tak jak w życiu- szybkie picie albo jedzenie dużych partii produktu powoduje czkawkę. Jak to się przekłada na oprogramowanie? Otóż bardzo prosto. Chcąc szybko skonsumować materiał dostarczony przez Klienta w postaci wymagań, bez solidnego prześledzenia procesów oraz danych w nich uczestniczących po pewnym czasie- zazwyczaj już na etapie implementacji- dostajemy czkawki.

Co zrobić aby się jej pozbyć? W życiu pomaga- wolne picie małych partii wody… Musimy po prostu wrócić do źródła i kawałek po kawałku wolno i solidnie konsumować procesy i śledzić zachowanie danych w danym procesie.

Kiedy zaktualizować pozyskane dane od Klienta? Najprostsze rozwiązania są zazwyczaj najlepsze. Wystarczy bowiem na początku współpracy ustalić regularne odstępy czasowe, w których będziemy podsyłać kolejne partie dokumentacji w celu wstępnej akceptacji założeń.

  “Jeśli coś jest dla wszystkich to jest dla nikogo”- takim stwierdzeniem powinny rozpoczynać się spotkania między Analitykami a sferą biznesową odpowiedzialną za stworzenie profilu Klienta. Niestety biznes rządzący się swoimi prawami staje się bardzo podatny na żądzę zwiększenia zysku podczas tworzenia profilu Klienta docelowego. I tak do wspólnego worka trafiają Klienci z różnych branż mający całkowicie różne procesy funkcjonujące w ich Firmach. Biznes na swoje decyzje ma przygotowany odpowiedni pakiet odpowiedzi i solidnych argumentów świetliście przedstawiający rozwój Firmy tworzącej oprogramowanie, która niemalże wykosi pozostałą konkurencję na rynku. Ba!!! Nie tylko wykosi, ale będzie przodownikiem pracy twórczej zadowalającej wszystkich Odbiorców oprogramowania. Dlaczego tak się dzieje? Odpowiedź jest prosta: Chęć szybkiego zysku, przy niskich kosztach wytworzenia dobrego produktu w krótkim czasie…. Jeszcze nie udało mi się spotkać takiego produktu… Chęć szybkiego zysku i zbudowania dużej aplikacji zadowalającej wszystkich Klientów na rynku staje się opaską na oczy Biznesu, który nie bacząc na konsekwencje swych działań doprowadza do samozniszczenia… Bardzo często przywołuję w takich przypadkach przykład komunikatora Gadu-Gadu.

Rozkładając na czynniki pierwsze budowanie tego komunikatora można dostrzec właściwą drogę postępowania Biznesu. Wybrano grupę Klientów, do których będzie kierowana Aplikacja. Była to jedna grupa Odbiorców mimo, iż była zróżnicowana pod kątem wieku miała jedną potrzebę: chęć komunikowania się z innymi w szybki sposób bez korzystania z telefonu. I co wówczas się stało: zbudowana podstawową Aplikację zaspakajającą potrzebę Odbiorców. W kolejnym iteracjach Aplikacja się rozrastała umożliwiając również wysyłanie plików, później samo wysyłanie zmieniło formę, bo również można było podejrzeć w oknie rozmowy zawartość wysyłanego pliku, dodatkowo wbudowane radio, umożliwienie rozmowy przez komunikator budowało potęgę komunikatora. Dlaczego lubię przywoływać ten przykład? Bo gdyby Biznes Gadu-Gadu czekał na zbudowanie Aplikacji w obecnej formie na rynku nie mieliby czego już szukać….

Idąc dalej tym tropem… Niektóre z firm, chcące wprowadzić nowy produkt na rynek wypuszczają już Aplikacje nawet nie przetestowane, jeszcze w wersji beta, aby Odbiorcy testowi mogli już się zapoznać z ich możliwościami, również wspierając w budowie samej Aplikacji co stanowi niesamowite wsparcie dla zespołu projektowego, jeśli brak pełnej wiedzy dziedzinowej z danego obszaru potrzeb biznesowych. Czemu to służy? Klient, który został wybrany do testów nie tylko oczekuje na możliwość korzystania w pełni funkcjonującej Aplikacji, ale również staje się twórcą niej samej. Dodatkowo Firma udostępniając swoją Aplikację atakuje rynek wyprzedzając konkurencję, która zawsze będzie. Mało tego w szybkim czasie po wdrożeniu Aplikacji równocześnie jak grzyby po deszczu urosną konkurencji oferujący podobny produkty w niższej być może cenie. W przypadku, jeśli Biznes był na to przygotowany, w momencie wejścia konkurencji wypuści kolejną iterację dostarczającą kolejne funkcjonalności jednocześnie będąc o dwa kroki przed konkurentami. Tutaj widzimy, jak wielki wpływ na powodzenie projektu ma etap przygotowania się do analizy, czyli określenie Odbiorcy i strategii rozwoju Aplikacji…

Recepta?

1. Jeśli chcesz eksplorować rynek najpierw Odbiorców podziel na grupy docelowe, do których będziesz kierował swój Produkt.

2. Ustaw kolejność grup, do których będziesz kierował swój Produkt.

3. Zbadaj potrzeby rynkowe i główne zagrożenia dla grup Odbiorców, aby przypadkiem nie okazało się, że rynek już wyznaczył kierunek rozwoju podobnych Aplikacji dla konkretnej grupy Odbiorców.

4. Przemyśl strategię rozwoju Produktu- które funkcjonalności są determinujące? Które są jedynie ułatwieniem dla Użytkownika?

5. Czy masz plan B w przypadku, kiedy konkurencja również wdroży na rynku podobny Produkt?

6. Pamiętaj o trójkącie: nie da się osiągnąć wszystkich trzech stanów jednocześnie.

    Jeśli chcesz zrobić dobry produkt niższym kosztem- potrzebujesz dużo czasu

    Jeśli chcesz zrobić dobry produkt szybko- potrzebujesz dużo kasy

    Jeśli chcesz zrobić szybko i tanio produkt- będzie on marnej jakości

Idealnie jest, kiedy jako Analityk nie jesteś ograniczony czasem podczas tworzenia analizy do funkcjonalności, bądź też zbiorem funkcjonalności do wytworzenia nowego Produktu. Jak wszyscy wiemy sytuacji idealnych nie ma, zatem musimy umiejętnie dysponować czasem, który został nam przydzielony na analizę. Po otrzymaniu informacji o roboczo-dniach, bądź roboczo-godzinach jakie mamy na stworzenie dokumentacji pojawia się pytanie: I co ja mogę zrobić w tak krótkim czasie?

Jeśli źle zaplanujemy sobie zadaniach w ramach przydzielonego czasu wówczas będziemy uczestnikami, a nawet autorami dwóch sytuacji:

a) wytworzymy masę stron w dokumencie w większości traktujące funkcjonalności pobieżnie,

b) obudzimy się z tzw. ręką w nocniku, bo przygotowując się do zbierania wymagań okaże się, że czas nam się skończył.

Jak zatem zapobiec takim sytuacjom?

Po otrzymaniu informacji o przydzieleniu czasu na dane zadanie od razu musimy zabrać się do działania, czyli niemalże od razu przejść do zebrania wymagań. Konsekwencją zebrania wymagań jest stworzenie chociażby Use Case i diagramu aktywności, który posłuży nam jako punkt wyjścia do ewentualnego stworzenia dokumentacji. Najlepszym rozwiązaniem w przypadku, kiedy mamy niewiele czasu na analizę jest stworzenie Use Story, które w jasny i klarowny sposób będzie przedstawiał programiście wymagania.

Co daje nam Scenariusz Przypadków Użycia? Analitykowi- perspektywiczne spojrzenie na cały proces z uwzględnieniem wszystkich możliwych sytuacji z wykorzystaniem danego działania oraz Aktora, Programiście- ułatwi zaprogramowanie danej funkcjonalności w oparciu o przypadki szczególne, które być może uznałby (bez korzystania ze stworzonych scenariuszy) jako poprawne działanie, bądź też błąd. Bez konkretnego wskazania co jest możliwe w podstawowym scenariuszu, a co w scenariuszu alternatywnym, na poziomie testowania pojawia się podstawowe pytanie Testera: YyYY, to tak miało działać?

Zatem brak czasu nie jest równoznaczne z brakiem dokumentacji. Powinniśmy wystrzegać się natomiast ciągłego dążenia do tworzenia niezliczonych stron dokumentacji, która czasem przysparza problemów samemu Programiście, który zniechęcony czytaniem takiej opasłej książki stworzonej przez Analityka staje się ofiarą własnych wyobrażeń poprawnego działania danej funkcjonalności.

Czasem zdarza się, że Analityk nie zdaje sobie sprawy z powagi swojego stanowiska, a raczej z odpowiedzialności jaka na nim ciąży. Wynika to z wielu czynników: w większości przypadków niekompletna dokumentacja powstaje bo termin nas goni i nie da się go przesunąć- wówczas należałoby się zastanowić nad tym kto szacował czas na analizę i czemu nie można ponownie oszacować czasu jeśli wkradły się nam w czas pracy czynniki niezależne od nas samych. Niemniej robienie po tzw. ” łebkach” powoduje, że oddajemy dokumentację myśląc, że możemy dopisać albo jeszcze gorzej- przekazać ustnie pewne ustalenia pomiędzy nami a Użytkownikiem końcowym. Co to powoduje? Oczywiście efekt domino. Jeśli taką niekompletną dokumentację dostanie programista- wiadomo co powstanie…… Niekompletna dokumentacja powstaje również z samej winy Analityka, bo źle zrozumiał Klienta, albo nie daj boże chciał na siłę go uszczęśliwić i zamiast zbierać wymagania według maksymy A.Einsteina: „WSZYSTKO NALEŻY ROBIĆ TAK PROSTO JAK TO MOŻLIWE, ALE NIE PROŚCIEJ”, staramy się wybiegać przed Klienta co powoduje wytworzenie systemu, który Klient później wykorzysta jedynie w 40 %. Zilustrowaniem efektu domina i błędów na każdym etapie jest dobrze znany rysunek (rysunek mojego autorstwa wygenerowany za pomocą aplikacji umieszczonej na jednej ze znanych stron: http://www.projectcartoon.com/)

Wiele firm z branży IT obecnie poszukuje ANALITYKA. Z przerażeniem przeglądając ogłoszenia na to stanowisko zastanawiam się czy kiedykolwiek osoba, która redaguje takie ogłoszenie pofatygowała się aby dowiedzieć się po pierwsze: Jakie cechy powinien posiadać taka osoba? Jaki zakres obowiązków powinna wypełnić na takim stanowisku?

Szukałam porównania stanowiska Analityka do jakiegoś bohatera, aby łatwiej można było przedstawić jego cechy. Najbliżej według mnie Analitykowi jest do AGENTA 007. Dlaczego? W dalszej części postaram się krótko odpowiedzieć na to pytanie.

Analityk powinien:

1. POSIADAĆ ZDOLNOŚĆ ANALITYCZNEGO MYŚLENIA I ŁĄCZENIA FAKTÓW

Ta cecha stanowi warunek konieczny w tym zawodzie. Bez tej umiejętności nawet mimo bardzo dobrego warsztatu nie uda się powiązać ze sobą funkcjonalności a przez to stworzona dokumentacja będzie jedynie zapisem przedstawionych wymagań przez Klienta, które nie zostały odpowiednio zanalizowane.

Jednocześnie brak analitycznego myślenia powoduje, że osoba, która jest Analitykiem w momencie kiedy pojawia się problem, bo np. Klient nie do końca sprecyzował problemu, albo go nawet nie dostrzegł, wówczas osoba taka załamuje ręce zamiast zanalizować problem pod kątem jego zrozumienia.

2.POSIADAĆ ZDOLNOŚĆ ABSTRAKCYJNEGO I PLASTYCZNEGO MYŚLENIA

Ta umiejętność najczęściej się przydaje podczas pracy z Klientem, który wymyśla system, który oprócz parkowania samochodu Klienta robi niemalże wszystko Umiejętność plastycznego i abstrakcyjnego myślenia umożliwia nam chociaż częściowe zilustrowanie przedstawianych przez Klienta funkcjonalności w systemie.

3.BYĆ DOCIEKLIWYM

Bardzo ważne jest, aby podczas rozmowy z Klientem dopytywać, zgłębiać temat i zagadnienie, próbować zrozumieć zasadę działania oraz konsekwencje z nich wynikające. Jeśli tego nie zrobimy wówczas zebrane wymagania nie będą uszczegółowione, co wywoła w trakcie etapu implementacji  lawinę błędów, którą będzie ciężko powstrzymać, bądź też wskaże lukę, którą wykorzysta programista do samowolnego zaproponowania rozwiązania i zaimplementownia go bez konsultacji.

4.BYĆ KONSEKWENTNYM, BYĆ OPANOWANYM I NIE DAĆ SIĘ SPROWOKOWAĆ

Analityk przygotowując się do spotkania zazwyczaj dokłada wszelkich starań, aby spotkanie przyniosło jak najwięcej owoców. Aby po spotkaniu mógł spisać wymagania w dokumencie analitycznym. Jednak nie zawsze to wystarcza, aby spotkanie się powiodło. Zdarzają się bowiem sytuacje, kiedy Klient nie rozumie naszego stanowiska- szczególnie często jest to spotykane w sytuacjach, kiedy rozbudowujemy już istniejącą aplikację, bądź też prowadzimy Integracje. Wówczas przykładowo osoba odpowiedzialna za wymagania po stronie Klienta będzie chciała jak najwięcej odpowiedzialności przerzucić na nasze barki, aby później móc powiedzieć:” Ja chciałem inaczej, ale Analityk się uparł przy swoim rozwiązaniu”. Aby uniknąć takich sytuacji należy być opanowanym i nie dać się sprowokować rozmówcy. Owszem czasem wyjdziemy z pogryzionym językiem z takiego spotkania, bo boimy się wybuchnąć na spotkaniu, aby nie zrazić do siebie Klienta. Jednocześnie musimy z uporem maniaka przypominać osobie będącej przedstawicielem Klienta jaki jest zakres obowiązków każdej ze stron i jaki jest zakres odpowiedzialności.

5.BYĆ PRZEWIDUJĄCYM, BYĆ SKONCENTROWANYM, MIEĆ PODZIELNOŚĆ UWAGI

To jedna z najważniejszych cech. Bardzo często Klient nie zdaje sobie sprawy, że niewielka zmiana (według niego) może spowodować lawinę błędów w całej aplikacji. Dlaczego? Otóż Klient nie widzi bebechów naszej aplikacji, a jedynie GUI. Zatem skąd ma wiedzieć, że jeśli powie, że chce aby teraz pole e-mail było pole obowiązkowym, a dotychczas nie było to spowoduje to przykładowo zawieszenie aplikacji. I tutaj stajemy przed niezaprzeczalnym faktem, iż dobry Analityk musi chcąc nie chcąc mieć wykształcenie techniczne ze wskazaniem na kierunek informatyka, bądź pokrewny umożliwiający poznanie różnych zależności czy bazodanowych, czy technologicznych. Czy osoba bez takowego wykształcenia ma szanse być analitykiem? Odpowiem: Tak, ale będzie jej trudniej, bowiem gdyby każdy mógł być przykładowo fizykiem, to po co otwierać studia fizyczne. Bez studiów owszem będziemy znali fizykę w jakimś tam zakresie, ale nie będzie specjalistą.

6.UMIEĆ SŁUCHAĆ, BYĆ KOMUNIKATYWNYM

Chyba większość z Was się z tym zgodzi. Jak bowiem rozmawiać z Klientem, jeśli nie potrafimy być komunikatywni Jeśli chodzi o umiejętność słuchania i znalezienia granicy między mówieniem do Klienta a słuchaniem odpowiedzią niech będą słowa G.K.Chestertone’a : “You have two ears and one mounth.I suggest that you use them in that proportion”

7.WYKORZYSTYWAĆ NIESTANDARDOWE METODY W PODEJŚCIU DO KLIENTA

Wśród wielu technik podejścia do Klienta (temat na osobny post, który ukaże się niebawem) większość z Analityków ma ulubioną technikę. Jednak część z Analityków tworzy własne techniki niestandardowego podejścia do Klienta. Ważne, aby osiągnąć cel, jakim jest zebranie wymagań od Klienta.

8.KRYTYCZNIE PATRZEĆ NA POMYSŁY KLIENTA I PROPONOWANE ROZWIĄZANIA

Tutaj należy rozróżnić podejście : Podchodzę na NIE do wszystkich pomysłów prezentowanych przez Klienta i Staram się znaleźć wzajemne wykluczenia prezentowanych pomysłów. O co tak naprawdę chodzi? Otóż… Kiedy Klient niczym rwąca rzeka porywa nas w świat pełen swoich coraz bardziej rozbudowanych funkcjonalności musimy być czujni, aby później nie okazało się, że podczas etapu zarządzania wymaganiami nagle dostrzeżemy, że te świetne pomysły zaprezentowane przez Klienta wzajemnie się wykluczają

9.MIEĆ ŚWIADOMOŚĆ KONSEKWENCJI W PRZYPADKU ŹLE WYKONANEGO ZADANIA

Najważniejsza umiejętność. Nie jest tak, że jako Analityk możesz pisać sobie dokumentacje nie biorąc pod uwagę jak duża odpowiedzialność na Tobie ciąży. Niedokładna dokumentacja powoduje, że efekt końcowy będzie prostopadły do zamierzonego. Nie mając tej świadomości możemy PRODUKOWAĆ dokumentację a nie ją TWORZYĆ. Twórca bowiem dba o jakość swojego produktu i stara się, aby spełniał wszelkie normy i oczekiwania Klienta.

W pewnej Firmie zapomniano o wpisaniu wymagań niefunkcjonalnych (o ważności tych wymagań również osobny artykuł). W trakcie wdrażania okazało się, że zostały zakupione dyski o dużo mniejszej prędkości niż jest przeznaczona dla macierzy dysków.  Analityk musiał ponieść konsekwencje swojego niedopatrzenia co się równało z tym, że po zakupieniu właściwych dysków musiał pokryć różnicę cenową.

10. BYĆ POKORNYM.

Nikt z nas nie jest omnibusem, dlatego ciągle musimy się doszkalać, rozwijać ze względu na to, że technologie i metodyki stosowane w analizie nie są rozdziałem zamkniętym. Jeśli pracujemy z kilkoma analitykami a wśród nich jest któryś posiadający większe doświadczenie czy wiedzę w zakresie analizy to tym lepiej dla nas, bowiem możemy się uczyć właśnie od nich.