Analiza przez wdrożenie z wykorzystaniem technologii Low-Code

Cześć

Zapraszamy Was do lektury naszego kolejnego artykułu na blogu. Powstał on we współpracy z Hanią Gruzdowską z AnalizaIT.pl. Zachęcamy Was również do odwiedzania bloga Hani, na którym znajdziecie mnóstwo wiedzy i ciekawych informacji dotyczących analizy biznesowej. Poniżej udostępniamy nagranie z naszego wspólnego Live’a. Gościem Hani był starszy analityk biznesowy GoNextStage Stanisław Korwin-Kossakowski.

Wstęp

W świecie IT i wytwarzania oprogramowania istnieje wiele technik analizy biznesowej mających na celu skuteczne pozyskiwanie wymagań od Klienta. Są to m. in. takie techniki jak np. brainstorming, modelowanie procesów, modelownie danych, prototypowanie, scenariusze i przypadki użycia, SWOT, analiza reguł biznesowych i inne. Zebrane wymagania są następnie w różny sposób dokumentowane: w notacji BPMN, jako user stories, w formie mockup-ów, kart procesów (PDD), Business concept diagramu, czy też w bardziej systemowej notacji UML. Wszystko po to, żeby w jak najlepszy możliwy sposób zrozumieć i utrwalić co biznes ma na myśli, co kryje się pod enigmatycznymi zdaniami opisującymi poszczególne wymagania. I oczywiście po to, aby na końcu zespół wykonawczy wiedział co ma stworzyć. Ostatecznym celem pozostaje zbudowanie właściwej aplikacji, systemu, rozwiązania, które spełni oczekiwane stawiane przez Zamawiającego.

Mimo, że stosowanych jest powszechnie tak wiele technik, metod oraz narzędzi i tak zdarza się, że po zbudowaniu pierwszej wersji aplikacji, Klient stwierdza, że: „nie do końca o to mi chodziło…”. Kto z nas nigdy nie słyszał tego zdania? J

Klient nie zawsze wie czego potrzebuje, wie natomiast czego chce

Prawidłowa analiza biznesowa wychodząca od celów przez wymagania, aż do analizy szczegółowej/systemowej ma oczywiście zmitygować wspomniane ryzyko. Jednak jak trafnie opisuje w swej książce Michał Bartyzel – Oprogramowanie szyte na miarę: „Klient nie zawsze wie czego potrzebuje, wie natomiast czego chce”. Czyli Klient doskonale rozumie problemy, których doświadcza i ma konkretny pomysł na ich rozwiązanie. Natomiast pewna niewiedza o możliwościach technicznych sprawia, że sugeruje rozwiązania, które nie zawsze są trafne.

Dlatego dobrze, aby w toku prowadzonego projektu Klient jak najwcześniej mógł zobaczyć i poznać projektowane rozwiązanie, a nawet mieć możliwość jego testowania. Dzięki temu może szybko zrewidować postawione na samym początku wymagania.

Taką możliwość daje jedna z wymienianych technik analizy, czyli prototypowanie. Polega ona na wczesnym dostarczeniu modelu rozwiązania końcowego, dzięki czemu można zidentyfikować braki w wyspecyfikowanych wymaganiach już na początkowym etapie budowy systemu. Możemy rozróżnić dwa podejścia do tworzenia modeli:

• Modele tymczasowe (ang. Throw-away) – proste modele uzyskiwane z użyciem narzędzi do modelowania. Taki model ostatecznie ląduje w koszu i nie jest wykorzystywany do produkcyjnego rozwiązania.
• Modele ewolucyjne lub funkcjonale – są to prototypy, które po kilku iteracjach mogą przekształcić się w działające rozwiązanie, które następnie jest rozwijane do uruchomienia produkcyjnego.

Drugi z wymienionych sposobów, wymaga jednak odpowiednej technologii informatycznej.

Low-code jako sposób dostarczenia najlepszego rozwiązania

Aby możliwe było iteracyjne tworzenie aplikacji, potrzeba platformy, w której możemy sprawnie modelować, a następnie implementować model na działające rozwiązanie. Szybkość tworzenia powinno zapewnić wykorzystanie gotowych elementów aplikacji oraz programowanie na wyższym poziomie niż pisanie kodu od samego początku. Do tego potrzebujemy mieć możliwość wprowadzania szybkich zmian do uruchomionej już aplikacji (tzw. instant change). Takie możliwości zapewniają nam platformy Low-code. Istnieje wiele tego typu platform na rynku, są to między innymi Microsoft PowerApps, Salesforce, Mendix, Outystems oraz WEBCON BPS, z którego najczęściej korzystamy w naszych projektach.

Platformy Low-code pozwalają na iteracyjną budowę aplikacji i bardzo łatwe wprowadzanie zmian w trakcie jej powstawania. Dzięki temu np. formularz rejestracji danego obiektu biznesowego, zintegrowany z produkcyjnymi źródłami danych, możemy błyskawicznie dostarczyć końcowym użytkownikom i zweryfikować z nim oczekiwania biznesowe.

Standardowe metody programistyczne, mimo że dają większą elastyczność są dużo bardziej pracochłonne, jeżeli chodzi o zbudowanie pierwszej wersji aplikacji a tym bardziej wykonywanie większych zmian. np. w modelu danych, na formularzach, w zakresie integracji etc.

Przy wykorzystaniu low-code, Klient na bardzo wczesnym etapie projektu wytwórczego ma możliwość np. wypełnienia formularza, przejścia przez poszczególne etapy procesu, podłączenia realnych dokumentów do systemu, zweryfikowania poprawności działania integracji systemów etc. To wszystko daje praktyczną możliwość weryfikacji, czy rozwiązanie spełnia jego potrzeby i pierwotne założenia projektu. Dzięki temu, pierwszą wersję aplikacji dostarczamy już w 2-3 tygodniu fazy realizacji i de facto dalej analizujemy wymagania, testując i budując kolejne wersje docelowej aplikacji.

Jak to wygląda praktyce?

Aby ta technika była jak najbardziej skuteczna w dojściu do pożądanego rozwiązania dla Klienta, powinna zostać oparta na zwinnym „frameworku” prowadzenia projektów np. Scrum czy DSDM (przynajmniej w warstwie wytwórczej). Dzięki temu Klient pracując na zdefiniowanym backlog (zakresie prac) może na bieżąco weryfikować postęp i kierunek prac oraz cyklicznie rewidować realizację poszczególnych wymagań poprzez testy rozwiązania.

Opisywana w tym artykule technika analizy i budowy aplikacji, pozwala też na praktyczną realizację drugiego punktu z manifestu agile (Manifesto for Agile Software Development): „Działające rozwiązanie ponad obszerną dokumentacje” (ang. Working software over comprehensive documentation). Należy jednak pamiętać tutaj o wyjściu od tak zwanych „solidnych podstaw” (5 z 8 pryncypium AgilePM „Build incrementally from firm foundations”). Dlatego, aby zacząć prototypowanie z użyciem low-code, powinniśmy mieć udokumentowane początkowe założenia: cele projektu, listę wymagań funkcjonalnych czy zamodelowany wstępnie proces biznesowy.

Po wstępnej analizie i utworzeniu „solidnych fundamentów”, stanowiących grunt do uruchomienia pierwszej fazy wykonawczej D&D (ang. Design&Develop), ustala się cykliczne spotkania np. raz na tydzień, podczas których prezentowane i omawiane są kolejne części zbudowanego systemu: formularze, etapy procesu, integracje z widokami, reguły biznesowe etc. Po kilku iteracjach, do testów angażujemy większą liczbę użytkowników systemu po stronie Klienta, który od tego momentu może „przeklikiwać” rozwiązanie. Tu najczęściej następuje magiczny moment, w którym Klient może zrewidować swoje wymagania, a nawet odkryć kolejne. Wszystko to wynika z naszej natury, bowiem dopiero gdy coś zobaczymy potrafimy to jednoznacznie ocenić i potwierdzić. Ten fragment projektu można nazwać właśnie – analizą przez wdrożenie.

Dzięki takiemu podejściu sprawnie dochodzimy do końcowego rozwiązania, które przekazywane jest już na formalne testy UAT (ang. User acceptance test) i ostateczne zatwierdzenie aplikacji przez Klienta. Dzięki temu, że interesariusze Klienta cały czas uczestniczą w iteracyjnych testach podczas budowy aplikacji, formalne testy UAT mogą być skrócone, co pozwala na szybsze uruchomienie produkcyjne systemu.

Częstsze interakcje z Interesariuszami zwiększają ich zaangażowanie w projekt i wzmacniają relacje między zespołem wytwórczym a biznesem Klienta. To daje ogromne korzyści, w perspektywie długofalowej współpracy w programach cyfrowej transformacji. Kolejnym pożądanym efektem jest łańcuchowa reakcja zgłaszania kolejnych pomysłów na rozbudowę systemu.

W wielu projektach istnieją różne „zagadnienia”, które implikując potrzebę wprowadzania zmian w tworzonym lub działającym już rozwiązaniu. Jest to np. polityka wewnętrzna firmy, zmieniające się kluczowe osoby w zespole Klienta, nowe wymagania pojawiające się w trakcie trwania projektu, nowi interesariusze etc. Dzięki low-code możemy lepiej i taniej zarządzać tymi zmianami, mając możliwość łatwego modelowania modyfikacji i udostępniani ich do testów, a następnie ich szybkiego przenoszenia na środowisko produkcyjne.

Wyjście od sprawdzonych wzorców

Jeżeli projekt polega na cyfryzacji procesów biznesowych, które są w pewnym sensie typowe dla danej branży, ważnym elementem jest również rozpoczęcie analizy od prezentacji interesariuszom pewnego przykładu, demo aplikacji, wzorca działającego na testowym środowisku. To pozwoli już od początku projektu „poczuć” przez Klienta projektowane rozwiązanie i może od razu dawać wkład do pierwszej wersji prototypu w fazie wytwórczej. W GoNextStage korzystamy z wzorców procesów biznesowych PBL (ang. Proven Business Logic) o których pisaliśmy w artykule: Proven Business Logic – wzorce projektowe dla procesów biznesowych wdrażanych bezpośrednio u Klienta już na etapie analizy.

Podsumowując

Celem każdego projektu informatycznego jest dostarczenie właściwego rozwiązania do Klienta. Klucz w tym, że słowo „właściwe” jest czasami bardzo trudne do zdefiniowania  na początku projektu i potrzeba iteracyjnego podejścia, aby je w pełni osiągnąć. Dzięki platformom low-code możemy błyskawicznie dostarczać działające fragmenty rozwiązania do praktycznego testowania. To pozwala Klientowi na bieżąco potwierdzać lub rewidować swoje wymagania i ostatecznie razem z wykonawcą zrealizować udany projekt cyfrowej transformacji.