Przejdź do treści

Dlaczego warto opisywać proces? O zaletach i rodzajach dokumentacji w czasie wdrażania systemów informatycznych

Oprogramowania informatyczne z założenia mają usprawniać procesy zachodzące w firmie, więc często najważniejszymi ich elementami, z punktu widzenia pracowników, są nowe funkcjonalności i użyteczność. W procesie wdrażania zdarza się, że dokumentacja i harmonogram pracy projektowej spychane są na dalszy plan. Jak zadbać o to, aby zapis współpracy z dostawcą oprogramowania działał na naszą korzyść i dla naszego bezpieczeństwa?

Dokumentowanie projektu – sposoby, charakter i zastosowanie

Trudno jest wskazać jedną, uniwersalną dla wszystkich systemów metodę dokumentacji projektowej. Jej ostateczny wygląd zależy od wielu czynników, takich jak: konkretne etapy projektu, charakter samego oprogramowania, czy też wcześniejsze praktyki firmy wdrożeniowej. Do takiej dokumentacji przynależeć mogą zarówno techniczny opis systemu (kod źródłowy), jak i wymagania oraz cele biznesowe Klienta. 

Dowolność form dokumentacji istnieje również na poziomie samego zapisu – może mieć postać komentarzy przypisanych bezpośrednio do linijek kodu, ciągłego tekstu w postaci dokumentu, a także wykresu, diagramu lub cyfrowego rejestru poszczególnych etapów i zadań. W przypadku ostatniej metody, jednymi z najpopularniejszych obecnie narzędzi są Jira lub Redmine, w których zapisywane są tzw. user stories

Każda z wymienionych wyżej form jest właściwa, o ile spełnia potrzeby i cele naszego przedsiębiorstwa. Dla poczucia bezpieczeństwa i lepszej organizacji późniejszej pracy, warto jednak rozważyć połączenie tych bardziej tradycyjnych, papierowych zapisów z dokumentacją cyfrową. 

Zanim zaczniemy – określenie specyfikacji

Przed rozpoczęciem procesu wdrażania, dla biznesu najważniejszymi elementami są: funkcjonalności oprogramowania, dopasowanie go do innych systemów informatycznych w organizacji, jego ograniczenia, a przede wszystkim – jego cele. Co powinno zatem składać się na taką specyfikację? 

  1. Cel – a w nim zawarte wszystkie niezbędne informacje o motywacji firmy, dlaczego zdecydowała się na wdrożenie systemu i jakie z jego pomocą kwestie chce rozwiązać.
  2. Informacje o aktorach systemu – czyli o użytkownikach, którzy w przyszłości będą korzystać z oprogramowania.
  3. Schemat infrastruktury i interfejsów – czyli otoczenie w jakim będzie funkcjonował nasz system.
  4. Scenariusze korzystania z systemu – przewidywane przypadki użycia oprogramowania.
  5. Wykaz funkcji – szczegółowo opisane wymagania dotyczące tego, jak system ma działać (samodzielnie i w korelacji z innymi programami).
  6. Inne wymagania dotyczące funkcjonalności – takie cechy systemu, które nie są wyrażone konkretnym działaniem (np. ogólne przyspieszenie pracy, umieszczanie danych w chmurze itp.).

Warto również zastanowić się nad tym, które z wymagań są dla naszej organizacji krytyczne, a z których możemy ewentualnie zrezygnować lub ich realizację przesunąć w czasie. 

Dokumentacja dotycząca wymagań zawiera w sobie często również schematy, diagramy i inne rysunki (zgodne z notacją UML, BPMN lub tworzone wedle uznania autora), które mają za zadanie doprecyzować treść umowy. Używając takich elementów warto zwrócić uwagę na ich dokładny opis, który nie może pozostawiać przestrzeni na błędne interpretacje przez którąś ze stron. 

Tworzenie specyfikacji wymagań powinno mieć miejsce jeszcze zanim rozpoczniemy procesy wdrożeniowe – to właśnie w niej zawarte są informacje o tym, jak system ma wyglądać i działać w ramach konkretnego przedsiębiorstwa. Specyfikację zazwyczaj dodaje się do umowy jako załącznik i stanowi ona gwarancję ustaleń między klientami a dostawcami oprogramowania. 

Etapy działania 

Niezwykle ważnym aspektem przygotowań do wdrażania oprogramowania jest określenie harmonogramu prac. Taki dokument powinien mniej lub bardziej szczegółowo opisywać etapy projektowe, a także ich powiązania i zależności. Dzięki terminarzowi zarówno klient, jak i wykonawca mają podstawę do dalszego działania, mogą więc kontrolować swoją współpracę i dotrzymywać wyznaczonych terminów. Pomocną formą takiego zapisu jest szeroko znany wykres Gantta, który ze względu na swoją graficzną reprezentację może być załączony bezpośrednio do umowy.

Cyfrowy rejestr zadań, czyli zwinna dokumentacja

Dostawcy oprogramowań (szczególnie w przypadku rozwiązań dedykowanych, tworzonych na potrzeby Klienta) coraz częściej pracują w ramach metodyk zwinnych. Dostawcy rozwiązań standardowych często dysponują natomiast wstępnie sparametryzowanymi i opisanymi modelami biznesowymi dla wybranych sektorów lub procesów, które w ramach wdrożenia są dostosowywane do potrzeb Klienta. Tego typu projekty wymagają trochę innego podejścia do dokumentacji. Można w nich użyć narzędzi cyfrowych tj. Jira lub AzureDevops, w których budujemy bazę wymagań, a następnie na bieżąco je aktualizujemy i dopasowujemy zadania pod konkretne etapy pracy projektowej. Popularną praktyką w tej branży jest więc odchodzenie od tradycyjnych form zapisu dokumentacji i harmonogramu. 

Zwinne podejście ma tę zaletę, że dokument może być na bieżąco edytowany i usprawniany w przypadku ewentualnych zmian i wymagań Klienta. Narzędzia elektroniczne ułatwiają też często wykorzystanie bazy wymagań w dalszych krokach realizacji projektu np. w fazie testów lub odbiorów, co pozwala podnieść jakość i efektywność realizowanych prac.

Każda metoda dokumentacji ma swoje wady, więc i te nowe, elektroniczne formy również je mają. Jedną z nich jest m.in. prawdopodobieństwo chaosu w zapisie, spowodowane przez wielu autorów tworzących jednocześnie oraz ogólny brak systematyzacji. 

Dokumentacja projektowa to niezwykle istotny element współpracy biznesu z dostawcami oprogramowań, pozwala określać ramy współpracy i unikać ewentualnych konfliktów. Daje poczucie stabilności procesu wdrożeniowego i może być realizowana na wiele sposobów – w zależności od celów i potrzeb Klienta. 

Jak wspomniano wyżej, jednym z bezpieczniejszych rozwiązań jest połączenie tradycyjnych sposobów dokumentowania z tymi zwinnymi, cyfrowymi. Nawet niezbyt szczegółowa specyfikacja wymagań oraz niedookreślony harmonogram działań w połączeniu z cyfrowym zapisem mogą być podstawą do stworzenia bezpiecznego i pełnego procesu wdrożeniowego w firmie.