Zarządzanie projektami IT, czyli jak uniknąć piramidy software’owej

Proces programowania polega na tym, że na podstawie dokumentacji technicznej tworzony jest kod źródłowy. Z kodu powstaje narzędzie posiadające określone funkcjonalności i wygląd. Świętym Graalem programistów jest obecnie jedna z metod zwinnych (agile) – popularny Scrum. Zespół programistyczny koncentruje się w nim na planowaniu prac, tworzeniu oprogramowania (development), testowaniu i wdrożeniu cząstkowych funkcjonalności (deployment). Scrum minimalizuje ryzyko błędów oraz powoduje, że programiści wychodzą zza biurek i spotykają klienta (także wewnętrznego).

Jednak metodyki zarządzania IT w czystej postaci są raczej postulatami, niż twardym wymogiem. Ścisłe trzymanie się metodologii „wodospadowych” naraża projekt na ryzyko dużych błędów po zakończeniu prac. Natomiast czysty Scrum nie zawsze nadaje się do pracy z klientem zewnętrznym. Ponadto, aby osiągnąć dobre efekty stosując jakąkolwiek metodę zarządzania projektami, szacuje się że potrzeba budżetu rzędu milionów dolarów.

Nic dziwnego, że większość firm IT wybiera z dostępnych metod to, co najlepsze, rezygnując z ortodoksyjnego trzymania się założeń którejś z nich.

Znając oficjalne metody zarządzania projektami IT, oczekiwania klientów i sytuację wewnątrz zespołu programistycznego, można wypracować własne rozwiązania hybrydowe. Szczególnie dobrze sprawdzają się one w produkcji oprogramowania generycznego.

Co należy zrobić, aby wypracować elastyczne, a przy tym usystematyzowane podejście do zarządzania projektami IT?

• Pierwszym krokiem jest określenie, jakiego programu oczekują klienci.
• Następnie należy opisać ogólne założenia i szczegółowe wymagania, które stworzą konkretne funkcjonalności podstawowe i te rozwijane w przyszłości.

Cały proces warto podzielić na kamienie milowe, czyli milestones. Każdy z nich powinien zakończyć się odbiorem danego wymagania:

• funkcjonalnego (np. polegającego na generowaniu wyniku Y z raportu X) lub
• niefunkcjonalnego (np. określonej wydajności aplikacji).

Efekty prac wykonywanych w ramach milestones powinny być prezentowane klientom lub wdrażane u nich. Dzięki konfrontacji wyników z oczekiwaniami można zapobiec powtarzaniu błędów w kolejnych funkcjonalnościach.

Każdy kamień milowy powinien składać się z krótszych odcinków, będących odrębnymi etapami w ramach procesu wytwórczego. Każdy z odcinków:

• obejmuje prace realizujące fragment założeń, który na koniec etapu można będzie przetestować,
• powinien być na tyle krótki, aby ewentualne błędy nie niweczyły dużej ilości pracy programistycznej.

Nadzór nad pracami powinna sprawować osoba, która:

• bardzo dobrze zna oczekiwania i wymagania klienta,
• na bieżąco śledzi proces programowania,
• zareaguje w przypadku opóźnień lub niezgodności fragmentu prac z wymaganiami.

Zastosowanie jakiejkolwiek metody zarządzania IT powinno być poprzedzone analizą potrzeb biznesowych. Przyjęcie wybranego rozwiązania hybrydowego powinno nastąpić w drodze akceptacji przez kierownictwo, uczestników projektu i klienta. Działanie w oparciu o jasne reguły i poczucie realizacji wspólnego celu to podstawa sukcesu.

Więcej o tym, jak uniknąć piramidy software’owej w zarządzaniu projektami IT pisali Ernest Frankowski, Dyrektor i Paweł Hulewicz, Senior Technology Officer w Zespole Tax Management Consulting, Deloitte Doradztwo Podatkowe.