Automatyczne zarządzanie projektami - fantazja

Bogdan Bereza „Automatyczne zarządzanie projektami – fantazja czy okazja?”
Automatyczne zarządzanie projektami –
fantazja czy okazja?
W godnej polecenia książce Toma DeMarco „Zdążyć przed terminem”, akcję otwiera scena,
gdzie 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, o czym będzie to
szkolenie? Czy o tym, jak dobierać uczestników projektu? A może o tym, jak ich motywować?
Jak się porozumiewać, jak rozwiązywać konflikty? Nic z tego jednak - prowadzący wyjaśnia, że
szkolenie nauczy procedur, omówi dokumentację i procesy. 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 najbardziej nawet 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 Jobsa wystarcza im sprawny organizator.
Ja, robot: zalety automatycznego nadzoru
Zalety automatyzacji rutynowych, typowych, powtarzalnych i względnie prostych czynności
administracyjnych; czynności koniecznych, żmudnych, narażonych na pomyłki wynikające z
ludzkiego zmęczenia, nudy, emocji - te zalety 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, bo
po o usprawniać to, co działa? Bystrych inaczej, którzy boją się, że automatyzacja rutynowych
czynności pozbawi ich pracy. Ekologów, zielonych i wyznawców buddyzmu zen, którzy
twierdzą, że i tak zbyt wiele mamy w życiu stresu i pośpiechu (racja), zapominając, że
automatyzacja pozwala go zmniejszać; oraz tych wszystkich, co uważają, że cierpienie
uszlachetnia, więc grzesznym jest ułatwiać sobie życie.
Wielka tablica świetlna
Jak więc konkretnie można by zrealizować automatyczne zarządzanie projektem IT - w praktyce?
Wystarczy wielka tablica świetlna, na której każda żarówka odpowiadałaby jednemu
wymaganiu, które tworzony system ma realizować. Na początku projektu żaróweczki świeciłyby
się głównie na czerwono - nic nie jest jeszcze zrobione, i rzut oka na taką tablicę zastępowałby
Strona 1 z 5
Bogdan Bereza „Automatyczne zarządzanie projektami – fantazja czy okazja?”
kunsztowne wyliczenia dumnych posiadaczy MBA, listy kontrolne rycerzy feudalnego zakonu
PRINCE2, czy natchnione intuicje przywódców, liderów oraz innych organizacyjnych nieszczęść.
Praca każdej osoby w projekcie byłaby połączona niewidzialnym drucikiem z tą tablicą.
Deweloper zrealizował, dokonał analizy statycznej i skompilował kawałek kodu - jedna żarówka
zmienia swoją barwę z czerwonej na nieco żółciejszą! Udało się zintegrować, połączyć ze sobą i
nawet uruchomić razem wiele takich kawałków - i cała grupa żaróweczek zaczyna się palić
miłym, żółtym blaskiem! Ups - test jednostkowy modułu wykrył błąd, więc jedna żarówka, już
tak obiecująco żółta, na powrót czerwienieje.
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
zielono, coraz mniej - czerwono, tak, by w ostatnim rzędzie - odpowiadającym terminowi
ostatecznemu - móc spodziewać się, zgodnie z przyjętym kryterium, wszystkich, czy niemal
wszystkich, żarówek świecących zielono.
Nie wszystkie żarówki są tej samej wielkości! Są wszakże wymagania kluczowe, które warunkują
biznesowy sens całego przedsięwzięcia (wielkie żarówy), i wymagania mniej ważne - małe
żaróweczki1.
Jakie to proste! Wystarczy dobrze znać wymagania, ich wagę, ich powiązania ze sobą oraz z
zaprojektowanymi modułami kodu i testami, a te z kolei - z osobami, które te zadania wykonują!
To się nazywa śledzeniem powiązań wymagań (ang. requirements traceability) i rynek narzędzi
tak komercyjnych, jak i wolnych, oferuje ich bardzo wiele (zalecam wstukać w wyszukiwarkę
frazę „requirements traceability tools”, albo wziąć może udział w szkoleniu Certified
Professional in Requirements Engineering - IREB CPRE2).
Oczywiście, takie rozwiązania dostępne są też w chmurze (czego dziś nie ma w chmurze?).
Polecam jedno z wielu - wymienione tutaj zgodnie z moimi subiektywnymi preferencjami znakomite, proste i niedrogie narzędzie ReQtest (reqtest.com)3. Szwedzkie narzędzie, dodam,
bo to, zdaje się - sądząc z reklam blachy dachowej i rynien - dobry argument marketingowy.
Jak to - więc 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, co z przydzielaniem zadań różnym uczestnikom projektu?
Jak mierzyć stan realizacji projektu? Gdzie umieszczać plany, raporty, wyniki audytów i inne PMowe czary-mary?
Po kolei. Oszacowanie pracochłonności wymaga 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
1
Więcej na ten temat - w artykule „Tester's High Noon”, victo.eu/ENG/Papers/high_noon.pdf
Lista dostawców: www.ireb.org.pl/szkolenia
3
Zwłaszcza polecam łopatologiczny film:
http://www.youtube.com/watch?feature=player_embedded&v=xoapznj79rE
2
Strona 2 z 5
Bogdan Bereza „Automatyczne zarządzanie projektami – fantazja czy okazja?”
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
ścieżkach krytycznych. I patrzcie - wystarczyła analiza wymagań, nie trzeba było doktoratu z
zarządzania!
Harmonogram, kamienie milowe: tak, przyznaję - tego narzędzia do wymagań nie wspierają
wprost. Dlatego pobudowano narzędzia łączące świat PM oraz świat wymagań. Moim,
nadzwyczaj subiektywnym, zdaniem, znakomitym przykładem takiego narzędzia jest
„Concerto”4.
„Concerto” łączy ze sobą tradycyjnie osobne światy: śledzenie powiązań wymagań, zarządzanie
zadaniami, automatyczne zapobieganie błędom5, zarządzanie projektem, integrację. Pełny opis
wymagałby odrębnego artykułu.
Jeśli nawet udało mi się jakoś okiełznać (można pomarzyć...) zastrzeżenia tradycjonalistów, to
już słyszę nadciągającą, groźną falę zastrzeżeń ze świata agile, sprowadzających się, niezależnie
od szczegółów, niczym w małżeństwie, do narzekań typu „to jest zupełnie inaczej, niż myślisz”
oraz „ty mnie nie rozumiesz”. Cóż, 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ę. Patrząc szerzej, jak już pisałem we wcześniejszych artykułach,
agile nie jest anty-wymaganiowy, przeciwnie: on jest ultra-wymaganiowy! Nasza tablica świetlna
doskonale wpisuje się w agile-owe pojęcie rejestru zadań przebiegu (sprint backlog)...
Tak, wiem, jakie niedopuszczalne zdanie napisałem kilka akapitów wyżej: „wystarczy dobrze
znać wymagania, ich wagę, ich powiązania [...]”. No cóż, to naprawdę wystarczy, ale mało kto tę
oczywistą prawdę stosuje, bo wymagania są niemodne6. Tak samo z odchudzaniem: wystarczy
magiczna dieta ŻM („żreć mniej”) i odchudzanie działa... a mimo tego kolorowe pisma pełne są
szalbierczych diet równie skomplikowanych, co nieskutecznych.
Zarządzanie ryzykiem: to po prostu nie wypada!
Zarządzanie projektami, jeśli pojmować je nowocześnie, a nie w postaci ITIL-owej, COBIT-owej
7
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
4
www.parasoft.com/jsp/products/concerto
Artykuł „Między biurokracją a chaosem”, Computerworld, 21 sierpnia 2007,
www.computerworld.pl/artykuly/321693/Miedzy.biurokracja.a.chaosem.html
6
Tak bardzo niemodne, że nawet elegencką nazwę „inżynieria wymagań” wyparło niemal całkowicie
chronicznie nieprecyzyjne określenie „analiza”!
7
„Testowanie na podstawie ryzyka jako sposób zarządzania zagrożeniami w projekcie informatycznym”,
victo.eu/PL/Wiedza/test_na_podst_ryzyka.pdf
5
Strona 3 z 5
Bogdan Bereza „Automatyczne zarządzanie projektami – fantazja czy okazja?”
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. Czyli
popularne wśród młodych ambitnych twierdzenie - połączone z głośnym waleniem się w klatę –
„będziemy na pewno gotowi przed <wstawić datę>”, ma walor jedynie propagandowy, ale nie
zawiera żadnej informacji.
Porządne zarządzanie ryzykiem, aby nie odbywało się, jak wygląda powszechna praktyka,
metodą stosowania niedoskonałej, emocjonalnej intuicji kierownika projektu, lub jego
podwładnych, wymaga systematycznego przypisywania ryzyka poszczególnym wymaganiom, i
śledzenia jego zmian. Zastosowana w kilku projektach, taka praktyka pozwoli nie tylko na półautomatyczne szacowanie ryzyka w kolejnych projektach, ale także na udoskonalenie całego
procesu IT.
Jeśli to takie proste, czemu tego się nie robi?
Zetknąłem się ostatnio z nieznanym mi wcześniej zagadnieniem: audytem zarządzania
budynkiem użyteczności publicznej. Spadochroniarze sprawdzają, czy są dokonywane okresowe
kontrole techniczne? Czy jest instrukcja przeciwpożarowa? Czy właściwie - zgodnie z czymś tam
o zamówieniach publicznych - wykonywane są przetargi na rozmaite prace, w tym konserwację?
Zakres takiej kontroli jest olbrzymi, ale prawdziwy smak życia wynika dopiero z faktu, że nikt poza kontrolerami - nie wie dokładnie, jakie są wymagania! Obowiązkowa kontrola techniczna
powinna, okazuje się na przykład, obejmować coroczne sprawdzanie instalacji odgromniczej,
więc ja, naiwny, spytałem, skąd wiadomo, że nie, na przykład, instalacji zabezpieczającej przed
ewentualnym wybuchem wulkanu? Gdzieś tam jest to ponoć zapisane, w jakichś tajemnych
przepisach, ale znają je tylko wtajemniczeni, co przeszli kosztowne i czasochłonne kursy
zarządców nieruchomości.
Nawet tam, gdzie administrator - zarządzający ma wiedzę, co i kiedy ma być zrobione, musi
zadbać samemu, aby o tym pamiętać. Nie istnieje, okazuje się, żaden automatyczny system,
który o tym przypomni. Aż się prosi o taką automatyczną listę kontrolną - zadanie do realizacji
dla studenta 2 roku informatyki. Wtedy administrowanie budynkiem przestałoby być
nieustannym stresem i nieustannym pilnowaniem tysięcy drobnych szczegółów
administracyjnych - to robiłoby się automatycznie!
Ale nigdy tak nie będzie... zbyt wielu znakomicie okopanych, poważnych udziałowców
poniosłoby straty! Zbyt wielu ma z tego chaosu wymierne korzyści!

Autorzy obowiązujących zasad - bo o ileż łatwiej, przyjemniej i bezpieczniej posługiwać się
ezopowym językiem prawno-administracyjnym, niż formułować swoje wymagania w jakże
banalnej formie reguł, realizowanych przez jakieś - ohyda! - informatyczne narzędzie.

Kontrolerzy - oczywiście. Po automatyzacji, już ich wizyta nie budziłaby pobożnej trwogi,
utraciliby tę odrobinę nimbu groźnej władzy, jaki otacza ich działania.

Dostawcy kosztownych i czasochłonnych kursów zarządców nieruchomości - to jasne.
Narzędzie, aplikacja zarządzająca uczyniłoby ich kursy najzupełniej zbędnymi.
Strona 4 z 5
Bogdan Bereza „Automatyczne zarządzanie projektami – fantazja czy okazja?”

Doświadczeni administratorzy - zarządzający, którzy utraciliby przywileje wynikające z
posiadania wiedzy tajemnej, i byliby rozliczani ze swoich faktycznych umiejętności.

Wszyscy - nie byłoby już na co móc tak fajnie ponarzekać! Pogadać przez telefon o 7-ej
wieczorem! Pobałaganić, pochachmęcić - gdzie bez tego byłby słodko-kwaśny smak życia?
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 :-(
W samo południe: nadchodzi szeryf!
Na temat automatycznego zarządzania projektami i stosowanych do tego narzędzi, dowiemy się
więcej podczas międzynarodowej konferencji „Dobre Wymagania”, 18-19 kwietnia w
Warszawie (breq2013.wymagania.org.pl).
Bogdan Bereza, [email protected]
Strona 5 z 5