Współpraca citizen developerów i profesjonalnych programistów – skuteczny i efektywny sposób na zbudowanie aplikacji

Kim jest citizen developer?

Wraz z rosnąca popularnością platform low-code/no-code stale rośnie również zapotrzebowanie na programistów. Niejedna firma zastanawia się jak połączyć zapotrzebowanie biznesowe na nowe funkcjonalności z dostępnymi zasobami ludzkimi. W związku z tym, pomysł szkolenia pracowników nietechnicznych, aby mogli uczestniczyć w tworzeniu aplikacji, staje się coraz bardziej popularny. Podczas realizacji naszych projektów, rozmów z klientami i partnerami odnieśliśmy wrażenie, że jest to temat któremu zdecydowanie warto jest się przyjrzeć. Proces zwany citizen developmentem został przez nas sprawdzony w realnym projekcie, a przemyślenia i spostrzeżenia były na tyle ciekawe, że zdecydowaliśmy się nimi podzielić z szerszym gronem odbiorców. Szczególnie dlatego, że PEGA jest idealnym produktem do zastosowania tego typu podejścia.

Zacznijmy jednak od odpowiedzi na podstawowe pytanie – kim jest citizen developer? Otóż jest to pracownik z dużą wiedzą biznesową, ale bez przeszkolenia w branży IT, który jest jednak w stanie szybko się uczyć i budować aplikacje z wykorzystaniem platform typu low-code/no-code. Mówiąc prościej, jest to osoba, która nie jest zawodowym programistą, ale wykazuje w tej kwestii pewien talent.

Citizen development – dlaczego warto spróbować tego podejścia?

Ideą citizen developmentu jest połączenie światów biznesu i IT. Wbrew pozorom, nie jest to tylko utopijna myśl, ale celowe działanie, mające przynieść szereg korzyści. Przyjrzyjmy się bliżej niektórym z nich:

• stała współpraca programistów z użytkownikami biznesowymi;
• natychmiastowa ocena i odzew biznesu na zmiany w aplikacji;
• wzrost produktywności zespołu;
• naprawianie błędów logicznych na etapie pisania kodu;
• niższe koszty zespołu IT;
• więcej czasu dla profesjonalnych programistów na bardziej złożone zadania (prostsze zadania mogą być realizowane przez citizen developerów);
• pozyskanie wartościowych członków zespołu IT, bez konieczności zatrudniania zewnętrznych wykonawców (szkolenie własnych zasobów);
• przyjazna publiczność podczas pokazów nowych funkcjonalności (użytkownicy biznesowi, którzy oceniają aplikację częściowo biorą udział w jej tworzeniu).

Od czego zacząć i jak efektywnie wykorzystywać zasoby ludzkie?

Początki bywają trudne, szczególnie gdy ma się do czynienia z technologią, w której nigdy się nie pracowało. Mogę jednak mogę zapewnić, że citizen development jest podejściem zdecydowanie wartym spróbowania. Pierwszym wyzywaniem, dla członków zespołu spoza obszaru IT, jest nowe środowisko pracy. Muszą oni wyjść ze swojej strefy komfortu i spróbować nauczyć się programowania! Na szczęście PEGA jest platformą przyjazną dla początkujących – łatwo jest w niej stworzyć prosty proces po zaledwie kilku godzinach nauki. Jeśli do pomocy ma się jeszcze profesjonalnego programistę, to zdobywanie nowych umiejętności przebiega płynnie, a możliwości szybko rosną. Wyzwania stoją także po stronie PEGA developerów. Niezbędne jest zrozumienie potrzeb biznesowych oraz funkcjonalności, które mają zostać wdrożone. Przygodę z citizen developmentem musimy zatem zacząć od odpowiedniego zapoznania członków zespołu, wymiany niezbędnych informacji i wiedzy. 

W całym procesie bardzo ważną rolę odgrywa współpraca pomiędzy różnymi działami firmy, które zaczynają działać jako jeden zespół. Należy jednak przy tym pamiętać, że nie może być on zbyt liczny, dlatego aby wszyscy członkowie zespołu mogli się zaangażować i aktywnie uczestniczyć w wymianie wiedzy i umiejętności. W naszym przypadku zespół składał się z: jednego profesjonalnego PEGA developera, dwóch citizen developerów oraz kliku obserwatorów. Taki skład pozwolił na idealne połączenie wiedzy biznesowej i umiejętności technicznych. Wyróżnijmy zatem punkty, od których każda strona musiała zacząć:

PEGA developerzy: 

– zapoznanie się z kontekstem biznesowym projektu, czyli z potrzebami i planami dotyczącymi aplikacji, która będzie budowana; 

– poznanie „biznesowej” części zespołu, a szczególnie zalet i mocnych stron nowych współpracowników; dzięki temu, od samego początku będzie wiadomo, jak efektywnie im pomóc oraz jaką tematykę prac można przydzielić poszczególnym osobom; 

– przygotowanie i zebranie materiałów szkoleniowych dla citizen developerów.

Citizen developerzy:

• uzyskanie dostępu do środowiska;
• poznanie podstaw środowiska pracy (platformy PEGA); ukończenie szkolenia w PEGA Academy (kurs CSA);
• nauka o możliwościach PEGA: podstawowe funkcje APP i DEV Studio; obejrzenie filmów instruktażowych, zapoznanie się z przydatnymi artykułami zebranymi przez nadzorującego programistę PEGA; 
• nauka i wykorzystywanie wsparcia od programisty PEGA (bieżąca pomoc).

Projekt (wstępny) – przykład z życia wzięty

Zespół został dobrany, przekazanie podstawowych informacji biznesowych i wprowadzenie techniczne mamy również za sobą. Co dalej…? Nie ma potrzeby dalej czekać i skupiać się na teorii – możemy rozpocząć tworzenie aplikacji już teraz! Budując aplikacje zastosowaliśmy jedno ze zdefiniowanych przez PEGA podejść, czyli tzw. Microjourney. Na taką „mikro-podróż” składa się „seria interakcji pomiędzy klientem a organizacją, które mają miejsce, gdy klient dąży do osiągnięcia określonego celu”. W tym cytacie zawarta jest definicja „podróży”, jednak, aby szybciej osiągnąć zamierzony cel i lepiej zrozumieć potrzeby zespołu biznesowego, pracę podzieliliśmy na mniejsze części. Oczywiście nadal skupiamy się na stabilnej wersji produkcyjnej, ale będziemy do niej dążyć etapami. Microjourney polega na dostarczeniu mniejszych części w stosunkowo krótkim czasie, np.:

• Utworzenie nowego kanału;
• Utworzenie nowego typu sprawy biznesowej (case type);
• Utworzenie i reużycie komponentu w kilku miejscach;
• Utworzenie nowego typu klienta (persona).

Podsumowując opisaną metodę, ponownie zacytuję Pega Academy: „Microjourney to transakcja biznesowa, która skutkuje osiągnieciem celu pośredniego lub końcowego”. Ta „podróż” w naszym przypadku to po prostu implementacja typu sprawy (case type) wraz z modelem danych, zdefiniowanym bezpieczeństwem i kanałem komunikacji. Budując aplikację, stosując koncepcję microjourney, należy mieć dokładnie zdefiniowany zakres bieżących prac, co pozwoli przyspieszyć development. Ponadto, dzięki małym i dobrze zdefiniowanym modułom, łatwo jest przetestować aplikację i osiągnąć cele biznesowe o najwyższym priorytecie.

Przyjrzyjmy się zatem kolejnym krokom wstępnego projektu typu sprawy , który zbudowaliśmy w PEGA:

• gromadzenie danych i myślenie projektowe:

Na początku musieliśmy zebrać wymagania i stworzyć backlog, czyli uporządkowaną według priorytetów listę zadań (tematów), które chcielibyśmy zrealizować. Następnie należało skupić się nieco bardziej na strukturze danych, którą chcieliśmy zaprojektować i na tym jak będzie wyglądał cały proces. Do wizualizacji procesu nie jest potrzebna żadna technologia, można go narysować poza PEGA, nawet na kartce papieru (jednak jako firma informatyczna korzystaliśmy oczywiście z bardziej zaawansowanych narzędzi – takich jak Miro Board i MS Excel 😊).

• tłumaczenie wymagań biznesowych – historyjki użytkownika (user stories) przetłumaczone na typ sprawy (case type) PEGA

Kolejnym krokiem było przeniesienie naszego procesu biznesowego do cyfrowej postaci. W tym celu należało wziąć naszą „kartkę papieru” zawierającą model procesu i stworzyć coś podobnego w PEGA. Zaczęliśmy od prostego typu sprawy, ale – zanim się zorientowaliśmy – przekształcił się w znacznie bardziej złożony projekt. Poniżej przedstawiłem jak ten proces przebiegał u nas krok po kroku:

• definiowanie etapów i prostych kroków;
• implementowanie logiki związanej z zatwierdzeniami (approval smart shapes);
• dodawanie powiadomień (wysyłanie e-maili);
• rozszerzenie zadań manualnych (assignments) – np. zastąpienie kilku osobnych zadań, formularzem podzielonym na zakładki (screen flow) dla kwestionariusza inicjalizującego cały proces;
• dodawanie logiki wynikającej z akcji użytkowników;
• dodawanie alternatywnych ścieżek zakończenia procesu;
• budowanie integracji z systemami zewnętrznymi;
• (…) i coraz bardziej złożone rozszerzenia!

• I w końcu nasza kartka papieru stała się dość skomplikowanym procesem zaimplementowanym w PEGA:

Budowa aplikacji

Opisany powyżej proces wygląda na dosyć prosty i… to w pewnym sensie prawda! Osiągnięcie celu nie jest w cale takie trudne, jednak wymaga dobrego planu i odpowiedniego przygotowania (oraz oczywiście dobrze dobranego i współpracującego zespołu). Wspomniałem już o współpracy różnych działów firmy, a teraz skupmy się na tym o czym mowa w poprzednim zdaniu, czyli czym tak naprawdę jest dobry plan? Rozłóżmy to na czynniki pierwsze:

• Omówienie planu pracy i kalendarza spotkań

„Zorganizujmy spotkanie, aby omówić, w jaki sposób duża liczba naszych spotkań utrudnia wykonanie naszej pracy”. Bardzo podoba mi się ten żart – doskonale oddaje korporacyjny charakter branży IT. Ale przerażająca prawda jest taka, że… pewne spotkania są potrzebne. To trochę tak, jak w tym dowcipie – czasem trzeba się spotkać, żeby w przyszłości uniknąć kolejnych, niepotrzebnych spotkań. Musimy zaplanować naszą pracę, ustalić terminy konsultacji i regularne spotkania, aby monitorować postępy. Zwłaszcza, że celem jest nadzorowanie i nauczanie mniej doświadczonych programistów, którzy z upływem czasu mają działać jak najbardziej samodzielnie. Na początku pomoc może być potrzebna codziennie, jednak pod koniec projektu może się okazać, że profesjonalny programista będzie musiał udzielać wsparcia tylko raz w tygodniu lub tylko na kluczowych etapach, takich jak sprawdzenie i zatwierdzenie kodu lub przy bardziej złożonych zadaniach.

• Stworzenie backlogu i podział pracy na mniejsze, krótkoterminowe części. Priorytetyzacja zadań.

Uzupełnienie tego co zostało już powiedziane, dobry plan i priorytyzacja zadań znacznie usprawnia pracę i pozwala uniknąć chaosu

• Podział zadań pomiędzy citizen i PEGA developerów

Bardzo ważny punkt. Początkowo wszystkie zadania zostaną prawdopodobnie przydzielone profesjonalnemu programiście. Należy jednak rozróżnić zadania, na takie które musi wykonać samodzielnie oraz takie, które można przypisać citizen developerom, po odpowiednim przeszkoleniu lub przy częściowym wsparciu profesjonalnego programisty. Z biegiem czasu citizen developerzy będą mogli brać na siebie coraz więcej obowiązków.

• Zaplanowanie spotkań: edukacyjnych, na analizę backlogu, na omówienie problemów napotkanych w procesie developmentu, a także regularnych spotkań statusowych

Tu należy zwrócić szczególną uwagę na to, by pamiętać o aktualizowaniu harmonogramu spotkań, w zależności od aktualnych potrzeb i nabytych umiejętności (rozwoju członków zespołu).

Codzienna praca i spotkania statusowe

Wstępny projekt typu sprawy powinien zostać wykonany przez doświadczonego programistę. Na początku citizen developerzy powinni pracować nad mniej skomplikowanymi zadaniami (np. projekt interfejsu użytkownika), a z czasem będą mogli przejść do coraz bardziej zaawansowanych problemów technicznych. Ktoś może zapytać: jak znaleźć czas na naukę, zachowując jednocześnie odpowiednie tempo pracy? Wszystko polega na ciągłym udoskonalaniu współpracy między członkami zespołu podczas budowy aplikacji. Cel ten można osiągnąć poprzez:

– organizowanie regularnych spotkań w celu przyspieszenia i sprawdzenia postępów pracy:

– zdobywanie i poszerzanie wiedzy (prezentacje wybranych tematów związanych z obecnymi zadaniami lub omawianymi wymaganiami);

– prezentowanie ostatnio opracowanych rozwiązań (z obu stron – PEGA i citizen developerów);

– zarezerwowanie czasu dla citizen developerów na zaprezentowanie swoich pomysłów i nabytych umiejętności;

– pokazanie, jak wykorzystać istniejące komponenty i rozwiązania PEGA OOTB;

– wskazanie i przygotowanie szkoleń i materiałów pisemnych dla citizen developerów, jako dodatek do regularnych spotkań 

Stosując takie podejście, udało nam się nie tylko zaoszczędzić niezwykle cenny czas, ale i podnieść umiejętności techniczne całego zespołu. Rozwój aplikacji postępował bardzo szybko, co pozwoliło osiągnąć nasz cel, którym było wdrożenie atrakcyjnego fragmentu kodu (zwanego naszą aplikacją) do użytku produkcyjnego! Poniższy diagram ilustruje kolejne kroki naszej pracy – od stworzenia pierwszego prostego typu sprawy, aż do dość złożonej aplikacji, która pomyślnie przeszła ocenę i akceptację kodu.

Postęp w rozwoju aplikacji – regularna rozbudowana i dodawanie nowych funkcjonalności do procesu

Kiedy potrzebna jest pomoc doświadczonego programisty?

Nie da się ukryć, że kluczowym elementem całego przedsięwzięcia jest rola profesjonalnego programisty. Aby aplikacja była dobrej jakości i aby cały proces przebiegał relatywnie szybko, niezbędne jest wsparcie doświadczonej osoby. Do głównych obowiązków i niezbędnych umiejętności starszego programisty należą:

– Dostrzeżenie możliwości wykorzystania narzędzi OOTB;

– Tworzenie (lub pomaganie w tworzeniu) reużywalnych komponentów;

– Posiadanie wiedzy na temat komponentów warstwy enterprise i umiejętność ich wykorzystania;

– Implementowanie bardziej zaawansowanych integracji z zewnętrznymi systemami;

– Analizowanie nowych elementów kodu napisanego przez citizen developerów;

– Pomaganie w zgłaszanych problemach, takich jak: 

• projektowanie portali użytkowników, 
• definiowanie landing pages;
• walidacje; 
• strategia odświeżania sekcji; 
• czyszczenie i uzupełnianie danych na podstawie wykonanej akcji przez użytkownika; 
• ustawienia bezpieczeństwa (grupy dostępu, role, persony itp.).

– Dbanie o dobrą jakość kodu;

– Przeglądanie, aktualizacja i nadzór nad dokumentacją;

– Konfigurowanie dostępu;

– Przeprowadzanie instalacji (deployment);

– Nadzorowanie testów;

…i punkt ważny przede wszystkim na początku (ale nie tylko):

– Prezentowanie wykorzystania możliwości platformy PEGA.

Jakie zadania mogą być realizowane przez citizen developerów?

Analitycy biznesowi i citizen developerzy są cennymi zasobami ludzkimi już od samego początku – dobrze zatem wiedzieć, jak można ich wykorzystać w najbardziej efektywny i wydajny sposób. W naszym przypadku mniej doświadczeni członkowie zespołu wykonywali wiele różnych zadań, takich jak:

– Implementacja nowych kroków procesu;

– Przygotowanie danych importowanych dla typów danych;

– Wstępne przygotowanie paczek do instalacji;

– Wykonywanie testów;

– Wsparcie i poprawki bieżącej wersji aplikacji;

– Dostosowywanie interfejsu użytkownika;

– Personalizacja landing pages i portali użytkowników;

– Tworzenie prostych walidacji;

– Definiowanie tabel decyzyjnych;

– Tworzenie data transform, reguł when, atrybutów, prostych data page’y i raportów;

– Modyfikacja istniejących procesów, na przykład: nowe kształty decyzjne, zmiany w routingu itp.

Należy jednak pamiętać, że nawet gdy citizen developerzy staną się samodzielni, dobrze jest mieć w każdym projekcie bardziej doświadczoną osobę do oceny jakości kodu i nadzoru postępu prac.

Korzyści i zagrożenia citizen development’u – kilka przykładów

Wnioski i podsumowanie

„Wszystko, co ma początek, ma swój koniec”. Gdybyśmy ten cytat z „Matrixa” uzupełnili o kilka dodatkowych warunków opisujących jak osiągnąć „koniec”, to byłoby to bardzo dobre podsumowanie naszej podróży. Oczywiście nadrzędnym celem było zbudowanie wysokiej jakości produktu w możliwie jak najkrótszym czasie. Konsekwentnie trzymając się obranego przez nas podejścia, udało nam się przy tym uzyskać też wiele dodatkowych korzyści, które z pewnością zaprocentują w przyszłości. I dlatego przyszedł mi do głowy kolejny cytat. Już po początku tego podsumowania można zauważyć, że jestem miłośnikiem kina, ale tym razem posłużę się cytatem z serialu telewizyjnego „Dark”: „Początek jest końcem, a koniec początkiem”. Profesjonalny programista PEGA musi myśleć całościowo. Rozpoczynając pracę nad projektem, musi już mieć opracowany plan działania, aby osiągnąć ostateczny cel. Wdrożenie produkcyjne może i oznacza koniec bieżącego projektu, ale to z kolei dla citizen developerów jest to dopiero początek w świecie PEGA. Zdobyli wiele nowych umiejętności technicznych i mają większą pewność siebie w tworzeniu aplikacji. Mogą teraz pracować nad coraz trudniejszymi zadaniami, przy coraz mniejszym wsparciu. Być może niektórzy z nich wkrótce odkryją nowe powołanie i nie tylko zaczną czerpać jeszcze większą satysfakcję z pisania kodu, ale udokumentują to kolejnymi certyfikatami PEGA? A może pójdą jeszcze o krok dalej i w pewnym momencie zaczną tworzyć własne zespoły, w których będą nadzorować i wychowywać nowych citizen developerów? I tak proces się zapętla, a to co wydawało się końcem jest tak naprawdę początkiem kolejnego etapu. To tylko pokazuje, że nie tylko stworzyliśmy bardzo dobry jakościowo produkt, ale także zwiększyliśmy umiejętności i wszechstronność zespołu. 

Nasze osiągnięcia można podzielić na dwie kategorie:

Z punktu widzenia produktu, osiągnęliśmy:

– Wysokiej jakości aplikację, przygotowaną do rozbudowy w przyszłości;

– Możliwość ponownego wykorzystania całych modułów w oparciu o zaimplementowane komponenty;

– Dużą elastyczność biznesową;

– Dobrą identyfikowalność postępu prac.

Z perspektywy zespołu, osiągnęliśmy:

– Rozwój osobisty – zdobywanie nowych umiejętności technicznych i poszerzanie wiedzy biznesowej;

– Zwiększenie pewności siebie wśród członków organizacji, zespół mierzył się z całkowicie nowymi technologiami;

– Doskonała równowaga pomiędzy zespołami biznesowymi i działami IT;

– Zwiększona produktywność dzięki wykorzystaniu citizen developerów.

Jakie są plany na przyszłość?

– Wdrażanie innych procesów;

– Zwiększenie złożoności bieżącej aplikacji;

– Zwiększanie zaangażowania zespołów biznesowych w proces budowy aplikacji;

– Zachęcanie innych działów w firmie do podążania podobną ścieżką.

Czy wszystko przebiegło sprawnie i zgodnie z naszymi oczekiwaniami? Skłamałbym, gdybym powiedział, że tak było. Oczywiście zmierzyliśmy się z pewnymi przeszkodami. Oto kilka przykładów:

– Konieczność skupienia się citizen deweloperów na swojej codziennej pracy (przed startem naszego projektu to oni musieli ręcznie wykonywać zadania, które teraz zautomatyzuje PEGA);

– Konieczność skupienia się na niektórych problemach dłużej, niż początkowo zakładaliśmy,. Było to niezbędne, aby je w pełni wyjaśnić i przenalizować, co miało pomóc zespołowi samodzielnie uporać się z podobnymi problemami w przyszłości.

Pomimo napotkanych problemów udało nam się zbudować, przetestować i wdrożyć aplikację. Pierwsze wrażenia menadżerów, którzy zdecydowali się zainwestować czas i budżet swojego zespołu, są bardzo pozytywne. Co więcej, doszyły nas słuchy, że w planach są już kolejne aplikacje mające zastąpić ręczne procesy. Ciężko o lepszą ocenę naszego eksperymentu niż takie działania i myślę, że to najlepsza odpowiedź na pytanie: czy warto iść w tym kierunku.

To, że citizen developerzy znacznie rozszerzyli swoje horyzonty wydaje się oczywiste, ale może pojawić się jeszcze jedno pytanie: co z deweloperami PEGA? Czy zmarnowali czas? Czy może mogli wykorzystać go na bardziej ambitne zadania, w trudniejszych projektach? Tak się składa, że programistą, który pełnił taką rolę jestem akurat ja. I w związku z tym, mogę bez wahania na to pytanie odpowiedzieć i rozwiać wszelkie wątpliwości. Nie tylko poszerzyłem swoją wiedzę biznesową i udoskonaliłem umiejętności miękkie, ale także nauczyłem się wielu nowych rzeczy czysto technicznych. Uczenie innych zawsze wymaga bardzo dokładnego opanowania materiału; uczniowie mają tendencję do zadawania pytań, których nauczyciel nigdy by sobie nie zadał 😉 Pojawiają się wyzwania techniczne, które muszą zostać rozwiązane w najlepszy możliwy sposób. Z całą pewnością mogę powiedzieć, że była to nie tylko ciekawa przygoda, ale także świetna okazja do nauki i rozwoju.