Dokumentacja robotyzacji: Na wejściu i na wyjściu

Nawet część z naszych Klientów sugeruje czasem, żeby przyspieszyć proces i zmniejszyć koszty robotyzacji poprzez ograniczenie dokumentacji. A to przecież im najbardziej powinno zależeć na udokumentowaniu krok po kroku, bit po bicie wprowadzonego procesu. O ile dane na wejściu są podstawą działania dewelopera RPA, to dane na wyjściu mają być skarbem zleceniodawcy. Dlatego pod żadnym pozorem przed pełną dokumentacją nie uciekamy, nawet dopuszczając, że na jej podstawie ktoś inny (mówiąc wprost – konkurent) będzie w przyszłości rozbudowywał system. Dokumentacja się po prostu należy, bo jest podstawą zapewniającą ciągłość działania rozwiązania. Trzymana w okładce, jak wejściówka na lotnisko (że podeprzemy się podpowiedzią z „Misia”) przez lata będzie służyć. Jako kompas, mapa i przewodnik po najbardziej interesujących miejscach.

 

Na wejściu

Identyfikacja potrzeb, opis zastanego zagadnienia do rozwiązania, analiza determinantów – tak jak w innych procesach, tak i w robotyzacji – pozwoli na stworzenie niejako osnowy geodezyjnej dla stworzenia mapy. Piszę o tej oczywistości, żeby podkreślić znaczenie osnowy dla procesu. Zakładam, że każdy ma świadomość, iż bez precyzyjnego podkładu (geodezyjnego albo biznesowego) nie można efektywnie budować. Ale podkreślam ten element, bo wyjaśnia to też naszą żądzę wiedzy i detali oraz wagę, jaką przykładamy do jakości ścisłej współpracy z prowadzącymi projekt po stronie klienta.

W procesie

Czy budowanie robota potrwa krócej, czy dłużej, nie ma znaczenia. Zawsze musi je poprzedzić zaprojektowanie rozwiązania na podstawie zgromadzonej dokumentacji. Na tym etapie można z ekspertem procesu rozstrzygnąć wątpliwości, z analitykiem przedyskutować warianty, ze strażnikiem budżetu uzgodnić dobór elementów składowych, np. licencji, które trzeba będzie kupić albo nie. A przecież liczymy się też z tym, że członkowie zespołu projektowego po obu stronach mogą się zmienić.

Po wdrożeniu

Korzystanie z rozwiązania powinno trwać dłużej niż proces jego budowania. Żarcik taki. Nieśmieszny szczególnie dla tych, którzy mają złe doświadczenia z wdrożeń. To inaczej: Korzystanie z rozwiązania będzie trwało długie lata, zwłaszcza jeśli odpowiednio będzie dbało się o jego modyfikację do zmieniających się potrzeb i wzbogacanie wraz z pojawiającymi się nowymi możliwościami technologicznymi. Bez dokumentacji rozwiązanie wzbogacać trudno nawet osobom, które projekt współtworzyły, bo ludzka pamięć nie jest tak pojemna jak komputerowa. A co jeśli tych osób – zarówno ekspertów dziedzinowych, jak i analityków biznesowych – zabraknie, bo wiatr przemian porwie je na pola innych aktywności? Szukaj wiatru w polu? Nie – łatwo znajdź podpowiedzi w dokumentacji.

Skrót kusi

Osoby negujące potrzebę przykładania dużej wagi do dokumentacji szermują argumentem, że dbałość o dokumentowanie nie ma sensu, bo kiedy wpisuje się „The End”, to dokumentacja jest nieaktualna. Takie stwierdzenie można by było uznać za prawdziwe, gdyby nie przyjąć do opracowania dokumentacji właściwej metodyki. Wiadomo, że wymagania beneficjenta wdrożenia mogą ewoluować i to kolejny argument przemawiający za potrzebą należytego dokumentowania. Przez „należyte” my w AmnisCode uważamy odpowiednie do metod zwinnego programowania Agile. Takie stosujemy i takie dokumentujemy. Niby jest cechą metod Agile, że stosowane w niewielkich zespołach nie wymagają tworzenia rozbudowanej dokumentacji kodu. Niby jest, ale niezmiennie stoimy na stanowisku, że pełny dokument się klientowi po prostu należy.

Poza tym zawsze przypominam sobie powiedzenie mojego dziadka Władka – „Chcesz pobłądzić – idź na skuśkę” albo myśl autora nieznanego – „Tam, gdzie warto jest dotrzeć, nie ma dróg na skróty”.