Analiza Biznesowa

Głównym zadaniem analizy biznesowej jest wyłonienie konkretnego rozwiązania spośród mnogości abstrakcyjnych idei i zadań, które stawiają przed projektem jego zleceniodawcy. Najlepszym sposobem osiągnięcia tego celu jest zrozumienie potrzeb na które ma odpowiadać oprogramowanie oraz ich źródła. Skąd się biorą? Jak możemy je zaspokoić? Jakimi, akceptowalnymi dla zleceniodawcy możliwościami dysponujemy i jaki wpływ na aspekty techniczne, ryzyko niepowodzenia przedsięwzięcia, koszty oraz czas realizacji projektu będzie miał wybór każdej z tych dróg.

Myśl oddolnie i odgórnie

Położenie nacisku na spójny, wysokopoziomowy opis zagadnienia nie oznacza, że funkcjonujemy w świecie abstraktów - ostatecznie, to szczegóły liczą się najbardziej. Wartość dobrego projektu polega na tym, iż dostarcza on rozwiązań dla określonych problemów biznesowych. Z drugiej strony, zajmowanie się detalami bez wcześniejszego wytyczenia ogólnych założeń, nieuchronnie prowadzi do niepotrzebnego rozproszenia energii. To właśnie dlatego nieustannie zmieniamy nasz «pułap lotu», naprzemian wznosząc się i opadając. Znając wszystkie istotne szczegóły, a jednocześnie nie tracąc z pola widzenia obrazu całości, bez przerwy porównujemy rzeczywisty stan projektu z założonym wcześniej planem.

Myśl krótko- i długookresowo

Upewnij się, że krótkoterminowe rozwiązania nie przeistoczą się w długoterminowe problemy.

Wiemy, że nie da się przewidzieć przyszłości i dlatego też nie jesteśmy w stanie z góry odgadnąć wszystkich możliwych wymagań i problemów, które pojawią się w trakcie realizacji projektu.

Mimo to, wybierając dane rozwiązanie, zawsze zastanawiamy się, czy sprawdzi się ono w najbardziej prawdopodobnych scenariuszach, mogących zaistnieć w bliższej lub nieco dalszej perspektywie. W ten sposób upewniamy się, że krótkoterminowe rozwiązania nie przeistoczą się w długoterminowe problemy.

Kochamy tworzyć koncepty

Tworzenie konceptów pozwala zebrać myśli (od łac. concipere, bezokolicznika czasu teraźniejszego strony czynnej concipiō (“podjąć, zebrać, uchwycić”), przelać je na papier i zorganizować

Przelane na papier koncepty pozwalają na (jak sugeruje to etymologia słowa) sformułowanie i klarowne wyrażenie pomysłów, które pojawiają się podczas procesu analizy. Z tego względu tego typu dokumenty są naszym ulubionym narzędziem do nakreślania, porządkowania oraz prezentacji różnorodnych opinii i oczekiwań osób zlecających wykonanie projektu.

Zazwyczaj, bezpośrednio po pierwszych spotkaniach z klientem sporządzamy ogólny zarys systemu - pomaga nam to w uzyskaniu pełnego obrazu sytuacji. Początkowo, zarys ten pełni przede wszystkim funkcję narzędzia komunikacji ze zleceniodawcą, służy do sondowania w jakim stopniu nasza oferta spełnia oczekiwania jego i przyszłych użytkowników aplikacji. Pomaga nam też w dogłębnym zrozumieniu stojącego przed nami problemu. Może być również wykorzystany do zebrania od programistów pierwszych uwag dotyczących widocznych już w tej fazie ograniczeń i trudności technicznych, które będziemy musieli przezwyciężyć w procesie implementacji.

Zapisane w postaci dokumentu koncepty są pierwszymi krokami, które stawiamy w wirtualnym świecie projektu. Mówimy: postaw na piękno, zrób różnicę. Bądź podekscytowany, starając się opisać coś tak zwięźle, jasno i czytelnie, jak to tylko możliwe.

Lepiej zmierzyć się z problemami na papierze niż w trakcie implementacji

O wiele tańsze jest napotkanie małych (lub nawet większych) przeszkód i pułapek w fazie koncepcyjnej niż podczas implementacji. Niespójności, nie dające się ze sobą pogodzić wymagania, założenia wymagające weryfikacji – wszystkie one często towarzyszą początkom projektu. O wiele lepiej zmierzyć się z nimi jeszcze przed przystąpieniem do kodowania.

Staramy się od samego początku dopracowywać specyfikację projektu, czasem bardzo głęboko wchodząc przy tym w szczegóły. To właśnie analityk odpowiedzialny jest za wykonanie pracy koncepcyjnej i stworzenie precyzyjnego opisu zagadnienia.

Model danych jest naszym Świętym Graalem

Jeśli zepsujesz model danych, zepsujesz też cały projekt.

Krótko po określeniu wysokopoziomowych założeń projektu, przystępujemy do pracy nad modelem danych. To bardzo istotny krok - jeśli zepsujesz model danych, zepsujesz też cały projekt. Nie zapominajmy, że tworzymy systemy informacyjne: cokolwiek się w nich wydarzy, musi zostać odzwierciedlone w strukturze danych reprezentującej nasze wyobrażenie świata zewnętrznego. Jeśli to wyobrażenie jest niekompletne, wewnętrznie sprzeczne lub mgliste, stworzenie dobrego modelu danych jest niemożliwe. Dlatego przed przystąpieniem do realizacji lepiej dwa razy przemyśleć całą koncepcję. Uporządkować wszystko na samym początku.

Analizuj - zniszcz to i odbuduj!

Naszym celem jest stworzenie takiej atmosfery w zespole, która pozwoli wszystkim jego członkom, zarówno analitykom jak i programistom, głośno wypowiadać swoje uwagi, sprzeczać się jeśli to konieczne i wspólnie opracowywać różne sposoby rozwiązania danego problemu. Jeśli coś stworzysz, potem zniszczysz z jakiegoś ważnego powodu, a następnie znowu zbudujesz, mając na uwadze doświadczenie uzyskane przy pierwszej dekonstrukcji, wtedy bardzo prawdopodobne, że ostatecznie powstanie coś lepszego.

Dlatego właśnie nie boimy się niszczyć i od podstaw tworzyć rozwiązań tak długo jak to konieczne – istnieje przy tym jedna bardzo ważna zasada: robimy to na papierze i w naszych głowach – jeśli robi się to na żywym kodzie, trzeba być gotowym na poniesienie astronomicznych kosztów! Unikanie tego bolesnego procesu nie jest żadnym wyjściem – rzeczywistość dopadnie Was prędzej czy później. Najgorzej, jeśli stanie się to w fazie wdrożenia oprogramowania.

Oczywiście, szlifowanie szczegółów nie może trwać w nieskończoność. Od perfekcyjnej dokumentacji jeszcze daleko do działającego projektu. Dlatego wiemy, kiedy należy przestać analizować i przejść do działania.