Jak nie doprowadzić do chaosu spowodowanego zmianami, pojawiającymi się w projekcie?

Technologiczna łatwość wprowadzenia zmiany i brak w oprogramowaniu naturalnych barier przeciwstawiających się zmianom niosą ogromne ryzyko utraty wszystkiego w jednej chwili, bez wnoszenia w ten akt totalnego zniszczenia nawet odrobiny wysiłku.

Technologiczna łatwość wprowadzenia zmiany i brak w oprogramowaniu naturalnych barier przeciwstawiających się zmianom niosą ogromne ryzyko utraty wszystkiego w jednej chwili, bez wnoszenia w ten akt totalnego zniszczenia nawet odrobiny wysiłku.

Wprowadzenie zmiany do oprogramowania jest niezwykle łatwe. Nie widać spoin, które nierozerwalnie wiązałyby ze sobą poszczególne komponenty składowe budowli. Trudno wskazać elementy nośne, których naruszenie może nieodwracalnie zburzyć całą konstrukcję. Nie ma utraty wartości materiału już wbudowanego w istniejącą konstrukcję. Oprogramowanie nie stawia w tym względzie naturalnych barier. Po prostu wyciągamy z repozytorium źródeł odpowiedni plik, wprowadzamy kilka drobnych poprawek, ponownie kompilujemy program i zmieniony produkt, nierzadko bardzo zmieniony, jest gotowy do użycia. Czy właśnie nie według tego schematu myślowego następuje najczęściej podjęcie decyzji o modyfikacji produktu?

Na ostatnią chwilę

Jeśli pogodzimy się z faktem, że oprogramowanie można zawsze i dowolnie zmienić, to pozostaje problem synchronizacji momentu pojawienia się propozycji zmiany w projekcie z terminem, w którym możemy ją przyjąć do realizacji. Jak często zdarza się wprowadzać zmiany do produktu tuż przed jego oddaniem? Jak często dodaje się nowe funkcje i oprogramowuje nowe algorytmy już po zamknięciu prac projektowych, bezpośrednio na etapie kodowania? Zdefiniowany cykl produkcyjny i wyróżnione w nim etapy nie są pomocne. Ponieważ tworzywem poddawanym obróbce są myśli, pozornie więc nie ma problemu, aby nowy pomysł wprowadzić do oprogramowania na każdym etapie jego produkcji. Ze strony zamawiającego, zwłaszcza decydentów nieświadomych procesu, pada w tego typu sytuacjach koronny argument: "Przecież rozmawiamy o dodaniu jednego, dosłownie jednego pola na formatce - to można zrobić w godzinę, a nie, jak proponujecie, w tydzień". Projekt może wtedy obronić jedynie kierownictwo firmy, które w zdefiniowanym cyklu wytwórczym będzie upatrywać wyższych wartości. Co można jednak zrobić, kiedy tuż przed oddaniem oprogramowania do użycia okazuje się, że bez dodatkowej funkcji - o której nikt wcześniej nie pomyślał - eksploatacja programu jest niemożliwa. Po prostu użytkownik nie będzie mógł wykonywać zadań przy użyciu oprogramowania. Przede wszystkim jest to lekcja, z której trzeba wyciągnąć wnioski, jak zmienić sposób zbierania i zatwierdzania wymagań. Ponadto trzeba reorganizować plan prac, aby naprawić niedopatrzenie.

Innym, równie częstym powodem reorganizacji naszych planów jest sytuacja, w której w wyniku powstania opóźnień w projekcie oraz niedotrzymania terminu realizacji trzeba zrezygnować z pewnych prac. Wtedy równomierne skracanie czasu potrzebnego na poszczególne fazy produkcji oprogramowania jest błędem. Jeszcze większym błędem jest rezygnacja z prac projektowych i rozpoczynanie kodowania. Oprogramowanie jest bowiem wymyślane i nie można tego procesu radykalnie przyspieszyć metodami administracyjnymi.

Niewzruszony tryb myślenia

Można przyspieszyć inne czynności, np. kodowanie, testowanie, instalację, choćby poprzez zwiększenie liczby programistów, automatyzację testów lub zwiększenie liczby testerów, automatyzację instalacji i całodobową pracę. Nie można natomiast radykalnie skrócić czasu potrzebnego na wykonanie dobrej analizy i poprawnego projektu. Zwiększenie liczebności pracowników niewiele zmieni, gdyż równoległe prowadzenie prac jest możliwe dopiero po wydzieleniu komponentów systemu i zdefiniowaniu interfejsów między nimi. Dopóki nie powstanie architektura systemu, dopóty wszyscy myślą nad tym samym odcinkiem. Procesu projektowania nie można zautomatyzować. Nie można także liczyć na ciągłą pracę projektantów, dwadzieścia cztery godziny na dobę. Tak więc, kiedy szukamy sposobu na wydanie w tym samym czasie oprogramowania o większej funkcjonalności niż zakładaliśmy i w wyniku opóźnień próbujemy ratować nasze terminy oddania produktu, szukajmy recepty w dobrym, przemyślanym i dopracowanym projekcie oraz zwiększonych zasobach przeznaczonych na jego wykonanie. Na projektowaniu nie wolno oszczędzać.

W trosce o wizerunek

Wiele zmian wprowadzanych do produktów ma na celu ich ulepszenie, ma usunąć niedopatrzenia powstałe na wcześniejszych etapach projektowych. Wydaje się, że wielu szefów projektów nie zastanawia się, co jest ważniejsze: stabilność produktu czy ich dobre imię. "Jak to będzie wyglądać? Co o mnie powiedzą inni, gdy zobaczą, że tak słabo to wymyśliłem?" Potencjalna negatywna ocena naszej osoby jest dla nas silniejszym bodźcem niż możliwe kłopoty z oprogramowaniem, spowodowane wprowadzeniem zmiany do produktu w końcowych etapach jego budowy. Wybieramy poprawianie. Dlaczego? Zauważony błąd został już popełniony - jest faktem. Stąd też prawdopodobieństwo negatywnej oceny naszej osoby z pewnością nie jest zerowe. Kłopoty z wprowadzeniem zmiany, potencjalna destabilizacja produktu, trudności z dotrzymaniem zaplanowanego terminu to tylko przypuszczenia. To wszystko nie musi się zdarzyć. Podświadomie zakładamy, że wytężona praca i zachowanie odpowiedniej ostrożności nie doprowadzą do perturbacji. Zapominamy o ogromnym bagażu doświadczeń, które wręcz krzyczą, że jeśli może się zdarzyć coś złego, to na pewno się zdarzy. Ponieważ najczęściej decydent to w jednej osobie kierownik, projektant, a często i główny programista, w trosce więc o własne "ja" podejmuje decyzję o wprowadzeniu zmiany. Jeśli dostrzeżony błąd rzeczywiście dyskwalifikuje produkt, to nie ma o czym rozmawiać. Taką zmianę trzeba wprowadzić. Jeśli jednak mamy do czynienia z ulepszaniem produktu, to należy zastanowić się, czy warto. Nie zapominać, że lepsze bywa wrogiem dobrego.

Porządek w kufrach

Zarządzanie zmianami staje się możliwe dopiero w uporządkowanym projekcie. Wizja w pełni uporządkowanego projektu informatycznego zakłada, że zebrane na początku procesu wymagania są odpowiednio oznakowane i pozwalają na śledzenie ich wpływu na pozostałe części systemu. Kiedy przychodzi zmiana wymagań, możemy jednym "pociągnięciem myszki" uzyskać raport, który wskaże nam, na jakie elementy systemu ma wpływ zmiana wymagań, i ocenić skalę i rozmiar zmian. Jeśli nie zadbamy o to, aby był utrzymywany aktualny obraz komponentów, które fizycznie istnieją i są elementami składowymi instalowanego systemu, pozostanie nam jedynie nasza, niestety, często zawodna pamięć. Dekomponując system, powinniśmy patrzeć, które z "kółek" i "prostokątów" będą stanowić realne byty, które z nich reprezentują przyszłe biblioteki, programy, bazy danych, pliki. Jeśli nasze diagramy przedstawiają jedynie koncepcję przetwarzania, ograniczają się do logiki biznesowej, to nigdy nie będą nam pomocne na poziomie kodu. Jest to jeden z powodów, dla których projekty często traktujemy jednokierunkowo, tzn. zajmujemy się nimi zanim powstanie kod. Później tracą swoją aktualność (nie opisują bytów rzeczywiście wytworzonych i podlegających dalszemu rozwojowi), toteż przestają być przydatne i z biegiem czasu zapominamy o nich.

Nagminne jest nieinformowanie o zmianach. Wprowadzając zmianę do komponentu, który nam podlega, nie zgłaszamy jej pozostałym osobom. Dzieje się tak, ponieważ albo uznajemy arbitralnie zmianę za niewielką, albo nie wiemy, kogo powiadomić. Poleganie wyłącznie na włas-nej pamięci przy ocenie rozległości wprowadzanej zmiany jest dobre, ale w małym projekcie, przy realizacji produktu, którego proces wytwórczy skupia się w rękach kierownika i jednego zespołu. Utrzymywanie bazy wiedzy o aktualnych produktach, ich wzajemnych powiązaniach, przypisanej im odpowiedzialności staje się nieodzownym elementem do skutecznego zarządzania zmianami. Praktycznie każdy element, jaki powstaje w procesie wytwórczym, musi być jednoznacznie identyfikowalny, począwszy od zwykłej notatki służbowej, skończywszy na każdej linii kodu.

Zarządzanie zmianami

Dojrzała organizacja decyzję o wprowadzeniu zmiany przekazuje powołanemu do tego celu komitetowi kontroli konfiguracji bądź grupie sterującej zmianami (Configuration/Change Control Board). Ta niezależna instancja jest potrzebna przede wszystkim do zobiektywizowania osądu wagi powodów, dla których jest wprowadzana zmiana. Jej zadaniem jest również dokonanie rozsądnej oceny skali i skutków wprowadzenia zmiany. Powinna dbać o to, aby jej wprowadzenie było zarządzane, tzn. by była odpowiednia analiza, projekt i plan przeprowadzenia zmiany oraz właściwy przepływ informacji między wszystkim zainteresowanymi, a także troszczyć się o stabilność tego, co już zostało osiągnięte. Technologiczna łatwość wprowadzenia zmiany oraz brak naturalnych barier w oprogramowaniu przeciwstawiających się zmianom niosą ogromne ryzyko utraty wszystkiego w jednej chwili, bez wnoszenia w ten akt totalnego zniszczenia ani odrobiny wysiłku. Któż z nas niemal nie wykonał "rm *" lub podobnej operacji nie w tym miejscu, w którym chciał? Warto o tych doświadczeniach pamiętać znacz-nie dłużej niż tylko do chwili odtworzenia z archiwum zawartości dysku.

<hr>

Włodzimierz Serwiński jest pracownikiem Prokom Software SA, kierownikiem projektu Oprogramowanie KSI ZUS.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200