TheTarPit

Czyj to plan?

Przedsięwzięcie programistyczne, tak jak każdy inny przejaw zorganizowanej działalności zespołowej, nie może się obyć bez konkretnego planu działania. To z pozoru banał. Jednak wniknięcie w szczegóły powstawania planów lub harmonogramów na typowym grzęzawisku ujawnia znacznie mniej oczywiste zależności i konsekwencje.

Specjaliści piszą o tym tak:

Plan przedsięwzięcia może być postrzegany na kilka różnych sposobów, w zależności od tego, czyj on jest.

• Ich plan. [...] plan tworzy dział marketingu lub badawczo-rozwojowy i przekazuje go menedżerowi przedsięwzięcia do implementacji. To ich plan, a od niego oczekuje się jego realizacji. Nie dziwi zatem fakt, że większość z nich pozostaje niewykonana. Ci, którzy te plany tworzą, interesują się tylko osiągnięciem zysków i nie biorą na siebie odpowiedzialności za samą dostawę. Składają obietnice, których menedżer nie jest w stanie spełnić.

Murray Cantor

Jak kierować zespołem programistów.

Z planem stworzonym przez handlowca spotkałem się wielokrotnie. Taki plan zawsze można poznać na odległość — po prostu pęka w szwach od nagromadzonych w nim niedorzeczności, niedomówień, nierealnych rozwiązań i bzdurnych terminów. Zadaniem handlowca jest podpisanie umowy i typowy przedstawiciel tego fachu nie cofnie się przed niczym aby osiągnąć cel — obieca wszystko, czego klient zażąda, a najlepiej jeszcze doda coś „pomysłowego” od siebie. Niestety z moich smutnych doświadczeń wynika, że ludzie sprzedający systemy informatyczne (zwłaszcza tworzone na zamówienie) nie mają pojęcia o możliwościach współczesnego oprogramowania i kosztach potencjalnego rozwiązania, a równocześnie są zbyt zadufani w sobie, by się do tego przyznać. Dla nich wszystko jest wykonalne i nie powinno trwać dłużej niż kilka godzin. W efekcie składają obietnice, pod którymi nie podpisałby się nikt, kto ma choćby mgliste pojęcie o programowaniu. Chyba najlepsze, co może zrobić KP postawiony przed zadaniem realizacji takiego planu, to szczerze powiedzieć zespołowi wykonawczemu kto ten plan stworzył. Jeżeli będzie próbował przedstawić go jako swój, to tylko straci zaufanie zespołu. Taki projekt to zawsze jest marsz ku klęsce i chyba lepiej powiedzieć to jasno już na samym początku.

• Twój plan. Nie ma niczego lepszego dla menedżera niż ustalenie planu przedsięwzięcia i narzucenie go zespołowi. Kiedy pracownikom przekazuje się po prostu informacje o zawartości, koszcie i harmonogramie, mogą się oni z nimi nie zgodzić. Widzą, że to Twój plan, a nie ich.

ibidem

Taki plan teoretycznie może być całkiem dobry, w praktyce jednak najczęściej jest kiepski. Aby menedżer stworzył sensowny i realny harmonogram, musi się znać na wytwarzaniu oprogramowania z wykorzystaniem aktualnych technik. Najczęściej po prostu nie wie o tym tyle, ile powinien — albo się nie zna na programowaniu w ogóle, albo znał się dawno temu i w zupełnie innych warunkach. Wbrew tradycyjnemu modelowi kariery (programista -> projektant -> kierownik) umiejętności wymagane od menedżera są zupełnie inne niż umiejętności dowolnego członka zespołu wykonawczego. Dlatego menedżer (niezależnie od jego ambicji i doświadczenia typu „robiłem takie rzeczy kiedy wyście byli jeszcze w kołyskach”) najczęściej nie umie sam stworzyć realnego harmonogramu.

• Plan zespołu. Kolejną możliwością menedżera jest poproszenie zespołu o stworzenie planu, a następnie ścisłe jego przestrzeganie. Kierownik może również pomóc zespołowi w sformułowaniu planu na drodze wzajemnych uzgodnień. Będzie to plan zespołu, ale poprawiony. Pracownicy będą bardziej skłonni zobowiązać się do jego wykonania, jeśli będzie on osiągalny.

ibidem

Stworzenie „planu zespołu” wymaga wzajemnego zaufania, a już samo to jest czasem trudne do osiągnięcia. W praktyce jest tak, że „poprawienie” planu polega na wciśnięciu go w ramy wymagań politycznych. Polityka najczęściej, a marketing zawsze, dąży do zmniejszenia kosztów i równoczesnego zwiększenia funkcjonalności, wiec dyskusja nad tak tworzonym harmonogramem obfituje w wymianę zdań typu „nie zdążymy — musimy”, „potrzebuję tyle — nie masz tyle” itp. Jednak mimo wszystko uważam, że jest to dobry sposób. Nie idealny, ale najlepszy na jaki nas stać. Jeżeli tylko poprawienie planu zespołu nie oznacza jego bezwzględnego zniszczenia, a jedynie nagięcie go do granic wytrzymałości, to jest to codzienna walka idealnie wpisana w krajobraz tego smolistego grzęzawiska jakim jest przedsięwzięcie programistyczne.

• Nasz plan. To najlepsze i jedyne akceptowalne rozwiązanie, ale zarazem najtrudniejsze do osiągnięcia. [...] Wszyscy udziałowcy muszą się z nim zgodzić. Każda osoba zaangażowana w przedsięwzięcie musi uznać, że jej żądania zostały uwzględnione i osiągnięto optymalny stan równowagi między zawartością, kosztem i harmonogramem. [...] Powstały w wyniku [...] rozmów plan i leżące u jego podstaw założenia powinny być stale rewidowane z udziałem wszystkich zainteresowanych grup.

ibidem

Utopia. Jeżeli by uznać, że jest to faktycznie „jedyne akceptowalne rozwiązanie”, to żaden projekt by nie ruszył z miejsca. Oczywiście założenie, że istnieje „nasz plan”, jest zgodne z teorią prowadzenia projektów (nie tylko informatycznych), jednak praktycznie nie występuje w przyrodzie. Zadaniem KP jest uprawianie takiej polityki, aby nie tyle uwzględnić żądania każdej ze stron, co raczej przekonać wszystkich do odpowiedniej modyfikacji wymagań. Nie ma nawet sensu dążyć do tego, aby każdy uznał, że dostał to, co chciał. Jeśli wszyscy uznają, że są w stanie przyjąć to, co dostają (czyli, że Sponsor zapłaci za to, co Użytkownik dostanie, oraz że programiści napiszą tyle, ile muszą w danym czasie i za dane pieniądze), to już jest sukces całkowicie wystarczający. Nie powiedziałbym jednak, że to „nasz plan”, najwyżej „nasz wielki kompromis”.

Komentarze

Brak komentarzy do tego wpisu.