Zmiany technologiczne postępują bardzo szybko, transformacji ulega także sposób zarządzania projektami i ludźmi, a także samo podejście do produktu. Dlatego tak ważna jest optymalizacja na każdym kroku. Warto więc spojrzeć na analitykę w wymiarze innowacyjnym, właśnie przez pryzmat dokumentacji biznesowej.
W procesie przygotowywania aplikacji także można zaobserwować zmiany. Nastąpiła ewolucja od podejścia waterwallowego, gdzie najpierw jeden etap się kończy, aby mógł zacząć się kolejny, aż po SCRUM. Natomiast w samej analizie biznesowej, owszem używa się nowych metod i narzędzi, ale sam proces dokumentacji przebiega tak samo już od wielu, wielu lat.
Jak można robić analizę lepiej, a tym samym lepiej dokumentować i wizualizować? Niezmiernie ciekawie jest zawsze spotkać się z interesariuszami, dowiadywać się jak ma wyglądać system i ustalać, jakie mają być efekty pracy. Wyzwaniem okazuje się tworzenie dokumentacji, na podstawie której zostanie stworzony nowy system. Dokumentacja bardzo często jest mało przejrzysta, bardzo duża i mało osób lubi ją zarówno pisać, jak i czytać.
Dlatego zapraszamy w krótką podróż po analizie biznesowej z punktu widzenia dokumentacji. Przejdziemy sobie krok po kroku, jak wygląda analiza biznesowa, sprawdzimy gdzie mamy do czynienia z dużymi wyzwaniami, zwłaszcza w zakresie dokumentacyjnym, gdzie ta dokumentacja jest problematyczna oraz przejdziemy przez kilka metod na to, jak można dokumentować lepiej, lżej, szybciej, wygodniej, czyli jak tworzyć dokumentację biznesową dla leniwców.
6 kluczowych kroków na ścieżce analizy biznesowej
Ścieżka analizy biznesowej składa się z sześciu podstawowych kroków, które pokrywają się z metodą rozwiązywania problemów.
#1. Analiza sytuacji: gdzie jesteśmy, w jakim kontekście organizacyjnym, czy biznesowym się obecnie znajdujemy, z jakiego powodu znajdujemy się na jakimś momencie projektowym – czy mamy do czynienia z nowym produktem, czy też z nieoptymalną sytuacją, gdzie musimy coś poprawić. Analiza sytuacji daje nam dodatkowy sposób dostosowania się do sytuacji, w której działamy. Badając nasz kontekst organizacyjny, jesteśmy w stanie lepiej dobrać metody analityczne, zapoznać się z tym, co jest potrzebne, wyłuskać wymagania od naszych interesariuszy.
#2. Akceptacja perspektyw, czyli rozumienie naszych interesariuszy: patrzymy na różnych interesariuszy, których już mamy zidentyfikowanych i analizujemy, w jaki sposób oni postrzegają sytuację bieżącą, jak chcieliby postrzegać sytuację przyszłą, jak możemy ich zaangażować, aby nasz projekt był jak najbardziej efektywny i przyniosło nam jak najmniej frustracji, a jak najwięcej sukcesów.
#3. Analiza potrzeb: zastanawiamy się nad tym, co jest kluczem analizy biznesowej. Pamiętajcie, aby nie popełnić tego błędu i nie zaczynać od analizy potrzeb, bo to jest dopiero punkt trzeci! W tym miejscu zastanawiamy się czego potrzeba naszym interesariuszom i czego oni chcą. Nie spisujemy tylko wymagań, które są nam dyktowane, ale wchodzimy głębiej w temat. Służą nam do tego warsztaty, na których rozmawiamy z ludźmi, zastanawiamy się, jak działają systemy i jak wyglądają procesy. Około 30% swojego czasu pracy analityk poświęca na warsztaty. Coraz częściej także pracujemy z zespołami rozproszonymi, a także interesariuszami z różnych krajów. Wspierać nas może np. narzędzie miro (można ustawiać karteczki na tablicy podczas warsztatów).
#4. Ocena opcji: za każdym przypadkiem, kiedy coś jest komuś potrzebne stoi też możliwość rozwiązania. W związku z tym, naszym zadaniem jest rozpatrzyć te różne rozwiązania. To nie znaczy, że już kierujemy się do finalnego rozwiązania. To raczej analiza opcji, jak dany problem można rozwiązać.
#5. Definicja wymagań: jak opcje mają być rozwiązane, czyli właśnie definiujemy wymagania. To jest nasza analiza. To moment, który jest szczególnie wrażliwy w całym procesie. W przypadku analizy sytuacji, jeżeli nie zbadamy naszego kontekstu lub nie zbadamy go poprawnie, nie skodyfikujemy i nie udokumentujemy go poprawnie, będziemy mieć bardzo małą możliwość odwołania się do niego w późniejszych etapach, a co za tym idzie – będziemy mieć małą możliwość skorzystania z niego w naszej pracy.
#6. Dostarczenie zmiany: wszystko, co robimy w naszej pracy, służy temu, aby oddać gotowy software, procesy czy zmienić organizację na lepsze.
Ścieżka analizy ma jeszcze dwa dodatkowe punkty, jakimi są planowanie oraz monitoring i usprawnienia. Faza planowania powinna wystąpić na samym początku. Reguły i zasady planowania ujęte są w BABOK (Business Analysis Body of Knowledge), do których należy się stosować. Natomiast monitoring i usprawnienia zadziewają się na samym końcu. Wspiera nas w tym SCRUM, retrospektywa, współpraca z zespołem, która oznacza nawet codzienne spotkania, które dają nam do zrozumienia oraz podpowiadają, co możemy i gdzie powinniśmy zmieniać.
Jak wygląda tradycyjna dokumentacja?
W najlepszym wypadku tradycyjna dokumentacja sprowadza się do dokumentu Volere, która jeszcze przed wypełnieniem ma 20 stron, a po wypełnieniu urasta do rozmiarów książki. Powoduje to, że tradycyjna dokumentacja nie zdaje egzaminu.
Narzędzia, które usprawnią pracę nad dokumentacją biznesową
Narzędzie #1: Business Objective Model
Model Business Objective opiera się na modelu z sektora publicznego, wykorzystywany np. przez Komisję Europejską. Widać na nim dwa elementy: problemy i cele biznesowe. Każdy problem biznesowy jest zestawiony z celem. Każdy cel, którego nie możemy rozwiązać lub wdrożyć w trybie natychmiastowym – prowadzi do kolejnego problemu. Finałem takiego modelu jest dojście do jak najniższego poziomu i odpowiedzenie sobie na pytanie: do czego chcemy dojść w projekcie, czyli kontekstu co będzie sukcesem, a co nim nie będzie. W tym wypadku cele biznesowe są przetumłaczone na wizje produktu, czyli tego, co robimy i co będziemy oferować w ramach nowej platformy.
Narzędzie #2: Prototypowanie
W tradycyjnej dokumentacji opisujemy te ekrany tekstem. Można to jednak zrobić trochę inaczej. Jeżeli nasz prototyp opiszemy tzw. labelkami, odpowiednimi numerami, przypisując do każdego elementu na ekranie unikalny numer, a następnie opiszemy, jak nazywa się ten element, kiedy się pojawia i w jakich przypadkach się go używa oraz jak się zachowuje (czy można w niego kliknąć, co się dzieje, jak się kliknie, czy trzeba mieć uprawnienia, aby kliknąć, itp). A to znacznie krótsza i bardziej przystępna alternatywa dla dokumentacji biznesowej w formie 200-stronicowej książki.
Narzędzie #3: Drzewo funkcjonalności
Dokumentacja analityczna składa się z diagramu z celami biznesowymi i produktowymi, historyjek użytkownika rozpisanych z prototypem i wizualizacjami, a także modeli danych czy diagramów statusów. To wszystko powiązane ze sobą jest w najlepszym przypadku procesem. Jeśli jednak patrzymy bardziej systemowo, najlepszą opcją połączania tych dokumentacji jest drzewo funkcjonalności. Każda „porcja” software, która jest zorientowana na dany obszar, jest osobną gałązką, tworzącą strukturę. W ten sposób widać wyraźnie, co jest z czym powiązane oraz kiedy będziemy się odnosić do danych elementów.
Narzędzie #4: Mapa aplikacji
Jeśli mówimy o aplikacji front-endowej, w której mamy strony, przez które będzie przechodził użytkownik, możemy użyć do tego mapy aplikacji. Można ją też użyć jako spis treści. W tym modelu mowa jest zarówno o ekranach, które widoczne są jako pojedyncze prostokąty, jak i o funkcjonalnościach, które są niezbędne, aby do tych ekranów można było się dostać. Dzięki takiej mapie będzie można zapoznać się i przeczytać wybrane elementy z mapy, a klikając w jeden z jej elementów, zostaniemy przekierowani do miejsca, gdzie znajdzie się więcej informacji na ten temat.
Narzędzie #5: Building blocks
Dysponując dokumentacją atomową, wiemy, jak wygląda struktura. Jednak mając na uwadze, że nasza organizacja jest tradycyjna staramy się iść bardziej w kierunku building blocks, czyli dekompozycji funkcjonalnej. Ten sposób dokumentowania pozwala na podzielenie całego systemu na mniejsze elementy np. funkcjonalności. To także świetna mapa, czyli raport wizualny.
Pomiędzy poszczególnymi funkcjonalnościami i portalami są przepływy informacji, sekwencje, które muszą być zrealizowane lub są już zrealizowane, lub wciąż w analizie, albo w developmencie, albo zaraz będą testowane, czyli stwarzamy sobie plan działań. Mamy tu możliwość raportowania nie tylko na poziomie konkretnej funkcjonalności, procesu, ale także na poziomie konkretnych błędów. Mimo atomowej dokumentacji, mamy pełen ogląd sytuacji systemowej, również ze stanem bieżącym oraz jak tym, jak wesprzeć klienta w podejmowaniu decyzji wdrożeniowych.
