Specyfikacja, która łączy role

Parę miesięcy, a czasem nawet rok.

Tyle, według Kamila Cieślika z Erste Banku, potrafi zająć naprawdę dobremu analitykowi wdrożenie się w proces kredytu gotówkowego. Kamil nie chciał podawać dokładnych liczb, „żeby się nie wkopać”, ale sala dobrze wiedziała, o czym mówi. Wiedza o skomplikowanych procesach jest rozrzucona po narzędziach, notatkach i ludzkich głowach. Kamil nazwał ją „szamańską”.

Na konferencji „Analityk & Architekt w erze AI” Kamil kontynuował temat, który wcześniej poruszyli koledzy z Orange i Leroy Merlin, ale od innej strony. Mówił o pracy u podstaw.

„Musimy się zabrać za rzeczy, za które od dawna chcieliśmy się zabrać, ale nigdy nie mieliśmy na to czasu. Teraz w końcu jest właściwy moment. Jesteśmy pod ścianą”.

Programiści przyspieszyli, reszta nie nadąża

Kamil jest z wykształcenia programistą, więc wie, że programiści mają dziś najlepsze warunki do przyspieszania. Mają narzędzia na wyciągnięcie ręki, a w Erste działają już rozwiązania, w których pracuje wielu agentów naraz. Wewnętrznie nazywa się je „fabrykami”, choć Kamil przyznał, że nie lubi tego słowa.

Ale żeby klient szybciej dostał wartość, przyspieszyć muszą wszyscy, a nie tylko programiści. Tester musi wiedzieć, z jakimi systemami integruje się usługa, żeby je zasymulować w testach, a tego często nie ma w zadaniu, nad którym właśnie pracuje. Nowa osoba w zespole musi się wdrożyć w złożone procesy. Biznes powinien umieć sam sformułować ogólne wymagania, bez ciągłej pomocy analityka.

Jest też pytanie, które Kamil zadał wprost. Fabryki AI dają tym lepszy efekt, im lepsze dostaną dane na wejściu. Ile pracy musiał jednak włożyć analityk, żeby programiści mogli przyspieszyć? Celem jest zdjęcie z analityka części tej pracy, żeby mógł zająć się kolejnymi zadaniami. Pracy ma dziś i tak aż nadto.

Wiedza w jednym miejscu

Dziś wiedza o systemach w Erste jest rozproszona: w Enterprise Architect, w ustaleniach zespołów, w głowach ludzi, w katalogach API, w Confluence i w kodzie. Zespół Kamila chce to uporządkować tak, żeby każda rola mogła łatwo wziąć to, czego potrzebuje. Na początek zaczynają od współpracy analityka z programistą, potem dojdą testerzy, a z czasem także biznes i architekci.

Enterprise Architecta nie wyrzucają. Stare systemy i powiązania między nimi zostają tam, pod opieką architektów korporacyjnych. W nowych projektach zespół postawił jednak na specyfikację pisaną w Markdownie i trzymaną w repozytorium kodu.

Ważne jest to, od czego zaczęli. Nie od modnych narzędzi do pisania specyfikacji pod AI, o których jest dziś głośno, tylko od standardu. Najpierw ustalili, czego oczekują od dokumentacji i z jakich części ma się składać. Każdy dokument ma mieć jedno zadanie, żeby na każdym etapie projektu dało się wyciągnąć dokładnie to, co jest potrzebne. Standard opisali we wspólnej bibliotece, z której korzystają różne zespoły w banku.

Specyfikacja na kilku piętrach

Kamilowi brakowało jednej rzeczy w wystąpieniach o pisaniu specyfikacji dla AI (Spec-Driven Development). Zwykle prowadzą je programiści i zaczynają od chwili, w której programista bierze zadanie i rozbija je na mniejsze części. A co z tym, co dzieje się wcześniej?

W Erste specyfikacja ma kilka poziomów:

Krajobraz systemów i powiązania między nimi zostają w Enterprise Architect, u architektów korporacyjnych. Poziom funkcjonalny (L1) tworzą analitycy i architekci na początku projektu: wstępna analiza, ogólne wymagania biznesowe, wstępny zarys architektury. Ten poziom jest pisany z myślą o biznesie. Poziom systemowy (L2) powstaje przy dopracowywaniu szczegółowych zadań: integracje, API, kolejki, modele danych. Poziomy L3 i L4 należą do programisty. Bierze dokumentację, rozbija problem na mniejsze zadania, planuje, pisze testy i kod.

Poziomy L1 i L2 mają być jak najmniej związane z kodem. Opisują produkt, a nie jego implementację.

Dokumentacja jak kod

Każdy dokument ma na początku metadane, czyli opis tego, czym jest i z czym się łączy. To ten sam pomysł, który znają użytkownicy Obsidiana. Dzięki metadanym dokumenty da się ze sobą powiązać i szybko przeszukiwać, także przez agentów AI.

W portalu dokumentacji widać karty dokumentów, strukturę ekranów, zasady działania interfejsu, modele danych (łączące pojęcia biznesowe z technicznymi) i diagramy przepływów. Widać też historię zmian i powiązania. Kiedy w zadaniu programisty pojawia się zmiana, dzięki tym powiązaniom agent dostaje razem z nią wszystko, co ważne.

Jest też ukłon w stronę analityków. Przy przeglądzie zmian w GitLabie analityk nie musi czytać surowego Markdowna. Dostaje gotowy, czytelny podgląd dokumentacji. W ten sam sposób zespół zapisuje decyzje architektoniczne (ADR) i buduje ich rejestr.

Mniej tokenów, ta sama trafność

Zwykłe wyszukiwanie po słowach to według Kamila za mało. Zespół chce, żeby model dostawał dokładnie ten fragment wiedzy, którego potrzebuje, bez marnowania tokenów i bez zmyślania. Dlatego buduje indeks kodu i graf wiedzy, czyli mapę powiązań między dokumentami.

Kamil pokazał wyniki ich testów. Zapytanie korzystające z indeksu kodu i grafu wiedzy było:

4,4 razy krótsze, 3,3 razy tańsze, zużyło 4,6 razy mniej tokenów,

a trafność pozostała na poziomie 100%, bez żadnego pominięcia.

Zaja, czyli wirtualny zespół

Na koniec Kamil przedstawił Zaję, wirtualny zespół analityków i architektów złożony z agentów AI. Zaja działa już w banku i wspiera różne role. Dziś agenci przygotowują głównie dokumenty potrzebne w procesie wytwarzania oprogramowania. Znają ten proces, ale brakowało im uporządkowanej wiedzy o samym produkcie.

Następny krok to połączenie obu światów: Zaja ma korzystać z nowego standardu dokumentacji. Wtedy wiedza o produkcie spotka się z pracą agentów, a nad całością nadal będzie czuwał człowiek.

Pytania z sali

Jan Maria Kowalski, MBA zapytał, jak zespół dba o to, żeby baza wiedzy była aktualna. Kamil odpowiedział, że to wyzwanie, dlatego wprowadzili automatyczne sprawdzanie: skrypty w Pythonie pilnują struktury dokumentów i poprawności powiązań między nimi. Przyznał, że biznes jeszcze bezpośrednio z tego nie korzysta, bo to wczesny etap. Docelowo chodzi o to, żeby analityk przestał być „głuchym telefonem” między biznesem a IT.

Padło też pytanie, czy przeszkodą nie jest to, że różne zespoły dokumentują inaczej: jedni w Jirze, drudzy w Confluence, a kod jest w różnych technologiach. Kamil odpowiedział, że nie, bo ich standard nie zależy od technologii.

Andrzej Sobczak zapytał też, czy praca w Markdownie i Gicie nie odstrasza analityków, którzy przez lata pracowali w Enterprise Architect, a pewnie najchętniej pisaliby w Wordzie. Kamil przyznał, że opór się pojawił. Zespół zrobił serię warsztatów i wielu analityków „złapało bakcyla”, bo docenili Markdown i wersjonowanie w Gicie. Sceptycy oczywiście też są i trzeba ich dalej przekonywać. Największe wyzwanie dopiero przed nimi: przeniesienie do nowego podejścia starych systemów.