Projekty z automatu

Wystarczy jasno sformułować wymagania, by zarządzanie projektami stało się prostsze. Zawiłe scenariusze różnych metodyk można wtedy zastąpić zautomatyzowanymi działaniami.

W świetnej książce Toma DeMarco "Zdążyć przed terminem" akcję otwiera scena, gdy bohater książki, nieprawomyślny kierownik projektów IT w dużej firmie, stawia się na obowiązkowym kursie zarządzania projektami. Bohater pyta prowadzącego, czego będzie dotyczyć szkolenie. Jak dobierać uczestników projektu? A może jak ich motywować? Jak się porozumiewać, rozwiązywać konflikty? Nic podobnego! Prowadzący wyjaśnia, że szkolenie ma nauczyć procedur, będzie zawierać omówienie dokumentacji i procesów. Tak, to ważne sprawy - zgadza się bohater - tylko nazwa szkolenia jest wobec tego nieodpowiednia. Powinno się ono nazywać nie "Zarządzanie projektami", lecz "Drobne szczegóły administracyjne".

Jest w tym wiele prawdy, ale, moim zdaniem, tylko pod warunkiem, że te drobne szczegóły administracyjne są pod kontrolą. W przeciwnym razie nawet najbardziej charyzmatyczny przywódca zainspiruje uczestników do... entuzjastycznego i pracowitego udziału w marnotrawiącym zasoby chaosie. Natomiast projekt, w którym te drobne szczegóły administracyjne nie są problemem, nie potrzebuje ani Aleksandra Wielkiego, ani Steve’a Jobsa - wystarczy sprawny organizator.

Ja, robot: zalety automatycznego nadzoru

Zalety automatyzacji rutynowych czynności administracyjnych, żmudnych i obarczonych ryzykiem pomyłki wynikającej z ludzkiego zmęczenia, są oczywiste. Bez komputerowej automatyzacji nie mielibyśmy dziś kart płatniczych ani przelewów przez internet, telefonów komórkowych, hamulców ABS... Szkoda czasu i miejsca na dalsze wyliczanie!

Ta oczywista prawda ma, niestety, wielu przeciwników - wszelkiej maści konserwatystów, bystrych inaczej, którzy boją się, że automatyzacja rutynowych czynności pozbawi ich pracy.

Wystarczy wielka tablica świetlna

Jak więc konkretnie, w praktyce, można zrealizować automatyczne zarządzanie projektem IT? Wystarczy wielka tablica świetlna, na której każda żarówka odpowiada jednemu wymaganiu, które tworzony system ma realizować. Na początku projektu żaróweczki świecą się głównie na czerwono - nic nie jest jeszcze gotowe. Rzut oka na taką tablicę zastępuje kunsztowne wyliczenia dumnych posiadaczy MBA, listy kontrolne rycerzy zakonu PRINCE2 czy intuicję liderów.

Praca każdej osoby w projekcie jest połączona niewidzialnym drucikiem z tą tablicą. Deweloperowi udaje się zrealizować, dokonać analizy statycznej i skompilować kawałek kodu - jedna żarówka zmienia swoją barwę z czerwonej na nieco bardziej żółtą. Udaje się zintegrować, połączyć ze sobą i nawet uruchomić razem wiele takich kawałków? Cała grupa żaróweczek zaczyna się palić miłym żółtym blaskiem.

Kiedy testy systemowe i akceptacyjne idą do przodu, coraz więcej żarówek zielenieje. Jeśli cały projekt posuwa się sprawnie do przodu, to w kolejnych rzędach coraz więcej żarówek świeci się na zielono. Wreszcie, w ostatnim rzędzie, odpowiadającym ostatecznemu terminowi zakończenia projektu, można spodziewać się wszystkich czy niemal wszystkich żarówek świecących na zielono.

Ale nie wszystkie żarówki są tej samej wielkości. Są przecież wymagania kluczowe, które warunkują biznesowy sens całego przedsięwzięcia (wielkie żarówy), i wymagania mniej ważne (małe żaróweczki).

Jakie to proste! Wystarczy dobrze znać wymagania, ich wagę, powiązania ze sobą oraz z zaprojektowanymi modułami kodu i testami, a te z kolei powiązać z osobami, które dane zadania wykonują! To się nazywa śledzeniem powiązań wymagań (ang. requirements traceability). Na rynku jest wiele narzędzi, tak komercyjnych jak i darmowych, które to wspierają.

Oczywiście, takie rozwiązania dostępne są też w chmurze. Polecam jedno z wielu, znakomite, proste i niedrogie narzędzie ReQtest. Szwedzkie narzędzie, dodam, bo to - sądząc z reklam blachy dachowej i rynien - dobry argument marketingowy.

Bez wróżenia z fusów

Czy narzędzie do zarządzania wymaganiami może wystarczyć do zarządzania projektem? A co z oszacowaniem pracochłonności, co ze ścieżkami krytycznymi, co z kamieniami milowymi, z harmonogramowaniem, przydzielaniem zadań różnym uczestnikom projektu? Jak mierzyć stan realizacji projektu? Gdzie umieszczać plany, raporty, wyniki audytów?

Po kolei. Do oszacowania pracochłonności potrzeba przede wszystkim i niemal wyłącznie dobrych wymagań. Tak jak pracochłonność wykopania dołu jest względnie prostą funkcją jego objętości oraz twardości podłoża, tak pracochłonność projektu IT jest względnie zawiłą funkcją sumy jego założeń - systemowego odpowiednika objętości dołu. Istnieje szereg naprawdę dobrych metod szacowania pracochłonności projektów na podstawie wymagań, na przykład na podstawie punktów funkcyjnych albo punktów UML, czyli z modeli wymagań. Inne metody to wróżenie z fusów.

Ścieżki krytyczne są funkcją hierarchii wymagań. Jeśli realizacja ważnych wymagań X, Y i Z wymaga realizacji wymagania A, to owo A grzecznie nam się układa na trzech ścieżkach krytycznych. I patrzcie: wystarczyła analiza wymagań, nie trzeba było doktoratu z zarządzania!

Harmonogram, kamienie milowe... Tak, przyznaję, to są rzeczy, których narzędzia do zarządzania wymaganiami nie wspierają wprost. Dlatego zbudowano narzędzia łączące świat PM oraz świat wymagań. Moim zdaniem znakomitym przykładem takiego narzędzia jest Concerto. Łączy ze sobą tradycyjnie osobne światy: śledzenie powiązań wymagań, zarządzanie zadaniami, automatyczne zapobieganie błędom, zarządzanie projektem i integrację.

Jeśli nawet udało mi się jakoś okiełznać zastrzeżenia tradycjonalistów, to już słyszę nadciągającą falę zastrzeżeń ze świata Agile, sprowadzających się do narzekań - "jest zupełnie inaczej, niż myślisz" oraz "ty mnie nie rozumiesz". Rzeczywiście, proponowana przeze mnie tablica świetlna odebrałaby nieco chaotycznego romantyzmu "młynom" (scrum w agile’owym dialekcie, czyli - mówiąc po ludzku - codzienne spotkania zespołu), bo przestałyby one służyć tak mocno wzajemnemu informowaniu się. Jednak nasza tablica świetlna doskonale wpisuje się w agile’owe pojęcie rejestru zadań przebiegu (sprint backlog).

Jeśli to takie proste, to dlaczego się tego nie robi

Zetknąłem się ostatnio z nieznanym mi wcześniej zagadnieniem: audytem zarządzania budynkiem użyteczności publicznej. Zakres takiej kontroli jest olbrzymi, ale prawdziwy jej smak wynika dopiero z faktu, że nikt - poza kontrolerami - nie wie dokładnie, jakie są wymagania! Okazuje się na przykład, że obowiązkowa kontrola techniczna powinna obejmować coroczne sprawdzanie instalacji odgromowej.

Nawet jeśli administrator budynku wie, co i kiedy powinno być zrobione, musi sam zadbać, aby o tym pamiętać. Nie istnieje żaden automatyczny system, który o tym przypomni. Aż się prosi o taką automatyczną listę kontrolną - zadanie do realizacji dla studenta drugiego roku informatyki. Wtedy administrowanie budynkiem przestałoby być nieustannym stresem i nieustannym pilnowaniem tysięcy drobnych szczegółów administracyjnych. To wszystko robiłoby się automatycznie!

Ale pewnie nigdy tak nie będzie. Pomyślałem: jaka straszna jest ta branża, administrowanie budynkami publicznymi, prawda? Bo u nas, w świecie IT, jest przecież zupełnie... tak samo.

Zarządzanie projektem to zarządzanie ryzykiem

Zarządzanie projektami, jeśli pojmować je nowocześnie, a nie w postaci ITIL-owej, COBIT-owej czy PRINCE2-owej rąbanki, to przede wszystkim zarządzanie ryzykiem. Jak to znakomicie opisują w swojej książce "Walzing with Bears" Tom DeMarco i Tim Lister, oszacowanie terminu realizacji projektu jest w istocie ćwiczeniem z oceny prawdopodobieństwa: im późniejszą datę się podaje, tym mniejsze jest ryzyko, że projekt przed jej upływem nie zostanie ukończony.

Aby porządne zarządzanie ryzykiem nie odbywało się metodą stosowania niedoskonałej, emocjonalnej intuicji kierownika projektu lub jego podwładnych, konieczne jest systematyczne przypisywanie ryzyka poszczególnym wymaganiom i śledzenie jego zmian. Taka praktyka, zastosowana w kilku projektach, pozwoli nie tylko na półautomatyczne szacowanie ryzyka w kolejnych projektach, ale także na udoskonalenie całego procesu IT.

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

TOP 200