Jak uniknąć piramidy software’owej – rzecz o zarządzaniu projektami IT

Jak uniknąć piramidy software’owej – rzecz o zarządzaniu projektami IT nkzs - sxc.hu

Wybór odpowiedniej metodyki realizacji projektu programistycznego to często najistotniejszy element całego przedsięwzięcia. Pytanie, który z dostępnych modeli zarządzania będzie dla nas najlepszy

Już starożytni Egipcjanie, budując piramidy, stosowali relatywnie złożone metody zarządzania, możliwe dzięki wynalezieniu pisma. Planowali prace, nadzorowali je i kontrolowali ich efekty. Programowanie również należy zaprojektować, aby na podstawie odpowiedniej dokumentacji technicznej twórcy kodu stworzyli narzędzie mające oczekiwane funkcjonalności i wygląd. Specyfika branży IT często wymaga jednak odejścia od tradycyjnych metod, w których inżynier produkuje kompleksową dokumentację techniczną, a programista sztywno trzyma się określonych tam wytycznych.

Programowanie jest stosunkowo młodą dziedziną, a mimo tego doczekało się już wielu metod prowadzenia projektów, od tradycyjnego Waterfall, przez zwinny Scrum, aż do skrajnie zdecentralizowanego Lean. Każdą z tych metodyk można porównać do określonej ideologii – ludzie dążą do realizacji ich postulatów, ale trudno wyobrazić sobie ich występowanie w czystej postaci.

Obecnie przyjęte jest, że najlepsze podejście do produkcji oprogramowania prezentują tzw. metody zwinne (agile). Popularny jest tu zwłaszcza Scrum, który koncentruje się na planowaniu, tworzeniu (development), testowaniu i wdrożeniu (deployment) cząstkowych funkcjonalności. Główną zaletą Scruma jest minimalizacja ryzyka związanego z błędami. Po latach stosowania tzw. metod tradycyjnych, Scrum wyprowadził programistów zza komputerów i wymusił większą interakcję z klientem (także tym wewnętrznym) i jego wymaganiami.

Idealny Scrum jest Świętym Graalem wielu programistów. Kiedy zapytać jednak, czy pracowali kiedyś w czystym Scrumie, nawet ci z dużym doświadczeniem zamiast odpowiedzieć wprost, oceniają, jak blisko lub daleko było do ideału.

Metodyka w postulowanej postaci często nie wytrzymuje w starciu z rzeczywistością projektową czy kliencką. Nic więc dziwnego, że menedżerowie projektów (czy też product ownerzy) odchodzą od ortodoksyjnego stosowania określonych doktryn zarządzania. Szacuje się, że do zadowalającego zastosowania zaawansowanych metod zarządzania projektem potrzebny jest budżet projektu rzędu 50 mln dolarów. Być może dlatego większość firm rezygnuje z ortodoksyjnego trzymania się poszczególnych metod i wybiera z nich to, co najbardziej odpowiada wyzwaniom biznesowym.

Wracając na poletko programistyczne, właśnie w produkcji oprogramowania generycznego dobrze sprawdzają się rozwiązania hybrydowe i elastyczne podejście do prowadzenia projektów. Podstawą tworzenia takich metodyk powinna być jednak dobra znajomość oficjalnych metod oraz intensywna analiza sytuacji wewnątrz grupy programistyczneji oczekiwań klientów.

Zacząć należy od dokładnego określenia celu, którym w tym przypadku będzie program oczekiwany przez klienta. Opis ogólnych założeń i szczegółowych wymagań powinien prowadzić do konkretnego określenia funkcjonalności podstawowych oraz tych, które będą rozwijane w drugiej kolejności i w przyszłości. To tak, jakby projektując luksusowy samochód, zacząć od płyty podłogowej i, jeśli będzie dobra, pomyśleć o implementacji reszty projektu.

Z perspektywy biznesowej cały proces warto podzielić na tzw. milestones, czyli kamienie milowe, zakończone przedstawieniem do odbioru danego wymagania: funkcjonalnego (raport X generuje wynik Y) i nie-funkcjonalnego (aplikacja ma mieć wydajność XYZ). W kontakcie z użytkownikami istotne jest, żeby efekty prac powstających w ramach kamieni milowych były prezentowane klientom, a jeśli to możliwe, od razu wdrażane. Już na tym etapie warto konfrontować rezultaty z oczekiwaniami klienta, aby nie powtarzać błędów w założeniach lub wykonaniu kolejnych funkcjonalności.

Kamienie milowe warto podzielić na mniejsze odcinki, stanowiące odrębne etapy procesu wytwórczego. Ich długość powinna być wystarczająca do realizacji założonego fragmentu prac możliwych do przetestowania pod koniec okresu. Testy muszą odbywać się na tyle często, aby ewentualne błędy nie niweczyły długiej pracy programistów.

Prace w ramach wspomnianych etapów powinna nadzorować osoba bardzo dokładnie znająca wymagania i oczekiwania klienta. Śledząc przy tym na bieżąco postęp prac i będąc blisko procesu programowania, jej rolą powinno być reagowanie na wypadek, gdyby założony fragment prac miał nie zostać dostarczony na czas lub gdyby miał odbiegać od wspomnianych wymagań.

Takie podejście „hybrydowe”, stanowiące kompilację najlepszych cech metodyk zwinnych i „wodospadowych”, chroni przed ryzykiem dużych błędów ujawniających się na koniec prac oraz uodparnia projekt na wiele ryzyk biznesowych. Jednocześnie pozwala zaplanować prace od A do Z i ustalić z góry termin ich zakończenia. Regularna prezentacja wyników klientowi zapewni mu poczucie komfortu i pozwoli skonfrontować funkcjonalności z oczekiwaniami rynku.

Przystępując do realizacji zadania programistycznego, warto ocenić, która metodyka jest najbardziej zbliżona do interesującego nas otoczenia biznesowego. Następnie, na jej fundamencie dokonać odpowiednich zmian, pozwalających spełnić wymagania i zabezpieczyć ryzyka występujące w danym projekcie. W ten sposób powinna powstać metodyka hybrydowa, która zostanie następnie w formie akceptacji i konsensusu przyjęta przez kierownictwo, zespół projektowy i klienta. Najważniejsze jest, aby wszyscy interesariusze tak złożonego procesu jak wytwarzanie oprogramowania działali w poczuciu realizacji jednego celu i wedle zasad wspólnie ustalonych, tak samo rozumianych i przez wszystkich przestrzeganych.

Autorzy:

Ernest Frankowski, Dyrektor (Tax Management Consulting)

Paweł Hulewicz, Senior Technology Officer (Tax Management Consulting)




Deloitte Doradztwo Podatkowe

Dalej

x

0 komentarzy

Nie udało się dodać komentarza, spróbuj ponownie za chwilę

Komentarz powinien być dłuższy niż 5 znaków

Prosze wprowadzić prawidłowy adres e-mail

Nick powinien być dłuższy niż 4 znaki