Zawsze lubiłem porównywać proces wprowadzania zmiany do systemu do efektu okręgów na wodzie, które powstają po wrzuceniu kamienia. Wpływ na system jest największy w miejscu uderzenia i rozchodzi się po całej powierzchni systemu jak fala.

O ile większość (wy)twórców oprogramowania jest w stanie poprawnie ocenić bezpośredni wpływ zmiany i przetestować dany obszar, to dalsze okręgi na tafli wody są często miejscami, gdzie powstają błędy, bo umykają uwadze.

Kolejna kwestia to rozmiar tafli. Mały system to tafla ograniczona np. dziecięcym wiaderkiem. Wraz ze wzrostem rozmiarów systemu zmiany zachodzą już na powierzchni sporych rozmiarów sadzawki. Pokazuje to też, dlaczego koszt i czas realizacji zmiany w istniejącym systemie może rosnąć z każdą przebudową.

No i teraz dochodzimy do kwestii jakości systemu, który zmieniamy i co się dzieje, jeśli jest ona niska. Tutaj mam wrażenie wykorzystywane przeze mnie porównanie lekko traci swoją wymowę. Pracując z jednym z systemów, który odziedziczyliśmy po innym dostawcy przyszło mi na myśl, że doświadczenie wprowadzania w nim zmian jest bliższe wrzuceniu uzbrojonego granatu do szamba:

• duża doza zaskoczenia
• skutki są dużo bardziej rozległe niż ktokolwiek byłby w stanie oszacować
• sporo sprzątania
• nikt nie wyjdzie z tego bez uszczerbku na zdrowiu

Jak sprawić, by zmiany w oprogramowaniu można było wprowadzać w sposób bardziej przewidywalny?

1. Dokumentacja

Dokumentację rozumiem zarówno jako spis i opis procesów biznesowych realizowanych przez system informatyczny, ale także jako dokumentację techniczną, która będzie zawierała informacje o architekturze rozwiązania, technicznych sposobach realizacji wymagań, czy też sposobu utrzymania systemu w sprawnym działaniu.

Niestety bez dokumentacji wiedza o systemie, po co został zbudowany, dlaczego posiada określone funkcje, dlaczego określone funkcje zostały zrealizowane w taki a nie inny sposób (czasami przeczący intuicji ze względu na różne uwarunkowania) ucieka z organizacji razem z osobami pracującymi przy systemie.

Niewiele osób lubi tworzyć dokumentację, a jeszcze mniej aktualizować ją na bieżąco, ale funkcjonowanie bez niej na dłuższą metę jest jako chodzenie po omacku w bardzo ciemnym pokoju. Zanim nauczymy się co gdzie stoi porozbijamy sobie głowę o nisko wiszący żyrandol i złamiemy wielokrotnie palce u stopy uderzając o kant szafki. A jak już się nauczymy, to każą zmieniać pokój (nowe projekty, nowe zdania), albo idziemy do innego mieszkania (zmiana pracy).

Ja rozumiem, że czasami jest ciężko wykonać dodatkową pracę związaną z "robotą papierkową", zwłaszcza jeśli szybko rozwijamy jakiś produkt, jest bliska współpraca pomiędzy użytkownikiem a np. programistą (w małych zespołach i małych projektach budowanych wewnątrz organizacji), ale jeśli w projekcie nie jest przewidziany czas na udokumentowanie wykonanej pracy to jest to nie tylko niezgodne ze sztuką (jakby ktoś się tym przejmował ;), ale przede wszystkim generuje wyższe koszty z perspektywy średnio- czy długoterminowej inwestycji we wdrażane oprogramowanie.

Jeśli tak jak w opisywanym przeze mnie przypadku, następuje zmiana dostawcy usług programistycznych (tutaj było o tyle trudniej, że zmienił się równocześnie właściciel biznesowy / product owner) i obydwie strony niejako muszą zaczynać od zera (bo nie było okresu przejściowego), to uwierzcie mi, że ilość granatów, która wybuchła nam w rękach była dosyć spora.

2. Proces zapewnienia jakości

Jeśli firma zatrudnia zewnętrzną organizację (software house), która specjalizuje się w produkcji oprogramowania, to zakłada, że zewnętrzny dostawca zna się na swojej pracy. I założenie to trzeba przyjąć, żeby rozpocząć współpracę (zakładam, że wcześniej toczyły się jakieś rozmowy, gdzie dostawca był w stanie zaprezentować swoje doświadczenie, wiedzę). Nie zwalania to jednak zamawiającego z obowiązku (tak OBOWIĄZKU) zabezpieczenia swojej inwestycji przez wykonywanie zadań związanych z kontrolą jakości.

Dostawca oprogramowania powinien mieć oczywiście zaplanowany etap testów i weryfikacji rozwiązania (niezależnie od przyjętej metodyki zarządzania projektem), ale odbiorca musi być w stanie zweryfikować, czy system został zrealizowany zgodnie z ustaleniami kontraktowymi (i ew. zmianami, które się pojawią w trakcie trwania projektu). Co więcej, taki proces zapewnienia jakości również powinien wyprodukować dokumentację testów, która w późniejszych etapach będzie służyć np. do testów regresji przy kolejnych wdrożeniach, czy jako wsad do automatyzacji testów (czy to wewnętrznie, czy po stronie dostawcy oprogramowania).

Jeśli (jako klient) chcielibyście mieć większą kontrolę nad jakością dostarczanego kodu, żeby zapewnić, że oprócz tego, że realizuje zadania na dzisiaj, będzie również rozszerzalny w kontekście potencjalnych wyzwań w przyszłości warto rozważyć wynajęcie kogoś, kto jest w stanie spojrzeć z boku na tworzony kod i zweryfikować jego poprawność, sensowność, czy zgodność ze standardami. Najczęściej ta odpowiedzialność jest po stronie dostawcy oprogramowania i powinna spoczywać na doświadczonych członkach zespołu implementującego dane rozwiązanie Jeśli jednak z jakichś powodów korzystasz z usług mniej doświadczonych programistów warto posiłkować się taką osobą, żeby zminimalizować ryzyko związane z niską jakością dostarczonego systemu.

Podsumowanie

Wytworzenie i wdrożenie oprogramowania, które (jakoś) działa jest tylko częścią projektu i jednym z przystanków w całym cyklu życia systemu. Oprogramowanie będzie dalej żyło razem z organizacją, powinno się też z nią rozwijać i adresować nowe potrzeby, które wraz z tym rozwojem się pojawiają. Jeśli jednak nie zostaną przypilnowane pewne elementy / etapy jak dokumentacja czy zapewnienie jakości, to im dalej, tym będzie trudniej to oprogramowanie utrzymywać i rozwijać. To jest trochę jak z narzędziami, których używa stolarz do wykonywania swojej pracy - jeśli nie będą utrzymywane w sprawności, nie będą wystarczająco ostre, nie będą prawidłowo czyszczone i konserwowane, to praca z nimi nie tylko nie będzie należeć do przyjemności, ale w końcu staną się bezużyteczne lub będą wręcz szkodzić temu, kto ich używa (może z tą różnicą, że jak system CRM jest uszkodzony, to nie wystrzeli w kierunku użytkownika 50 cm drzazgi).