poniedziałek, 28 maja 2007

Innowacje a system

Dzisiaj trochę o tym dlaczego w ogóle w dużych, dobrze zarządzanych systemach innowacja może być problemem. Temat jest bardzo szeroki. Zacznijmy jednak od początku, czyli od pojęcia systemantyki. To pseudo-nauka, której celem jest opisanie w jaki sposób działają (czy też raczej nie działają) duże systemy. Choć w swej istocie i źródłach jest nacechowana dużą dozą ironii czy wręcz krytykanctwa to po głębszym zastanowieniu z większością tez trudno się nie zgodzić. Pisało o tym wielu różnych autorów, w sieci najlepszy tekst opublikował Bart Stewart, dostępny jest tutaj (http://www.draftymanor.com/bart/systems2.htm).

Jako, że mowa będzie o systemach trzeba mieć system, który można będzie zanalizować. Proponuję, żeby każdy wybrał sobie dowolny znany mu system tworzenia/wspierania innowacji. Może to być system wewnątrz korporacji/firmy czy też którykolwiek z rządowych (lub szerzej: publicznych) systemów tego typu. Zobaczmy jak takie systemy innowacji mają się do dwóch wybranych zasad systemantyki. (moje wolne tłumaczenie poszczególny zasad - po oryginały zapraszam do linku powyżej).

I.7 Systemy zwiększając swoją złożoność mają tendencję do przeciwstawiania się celowi dla którego zostały stworzone

Wydaje się bez sensu? A jednak. Najprostszy i najbardziej trafiający do umysłu przykład: system Urzędów Pracy, którego celem powinno być wyeliminowanie bezrobocia. Co się jednak stanie z tym systemem jeżeli nie będzie już bezrobotnych? Czy w interesie systemu jest wypełnienie celu dla którego go stworzono?

Jak to się ma do innowacji? Jeżeli celem stworzenia systemu jest zwiększenie innowacyjności to tak naprawdę rzadko ten system działa dla tego właśnie celu. Cele prawdziwe systemu są zupełnie inne. Zwykle to wsparcie jest wyrażone jakąś metryką, na przykład ilością pomysłów wygenerowanych albo ilością firm, którym udzielono wsparcie. Spełnienie celów opisanych daną metryką jest tym z czego będą rozliczani zarządzający systemem. I teraz czy aby na pewno spełnienie tych celów jest najprostsze poprzez wsparcie innowacyjności? Doświadczenie uczy, że w dużej części przypadków nie. Najprościej dla systemu i dla spełnienia jego prawdziwych celów jest wybrać coś nieszczególnie innowacyjnego. Dlaczego? Bo innowacja to ryzyko a system nie chce ryzykować, tylko spełnić wymagane od niego cele. A w cele i metryki w znakomitej większości przypadków nie uwzględniają ryzyka. Najprostsza więc droga do spełnienia celów postawionych przed systemem wiedzie przez ominięcie ryzyka i innowacyjności!!! Czyli system zaczyna działać przeciw celowi do którego go powołano. Oczywiście nie jest tak we wszystkich przypadkach i są chwalebne wyjątki.

Jaki z tego wniosek: konstruując system, który ma wspomagać innowacyjność postawcie dobre cele. Dobre to znaczy takie, które spełniają kryteria innowacyjności, w tym szczególnie wspomagają podejmowanie działań wysoce ryzykownych. Z drugiej strony jeżeli przystępujecie czy też chcecie skorzystać z tego typu systemu dokładnie sprawdźcie jakie są rzeczywiste (a nie deklarowane) cele takiego systemu i przemyślcie czy z punktu widzenia systemu droga do osiągnięcia celów aby na pewno wiedzie przez działania innowacyjne.

II.2 Elementy systemu nie robią tego, co system twierdzi, że robi
Trochę zagmatwane, ale w skrócie chodzi o to, że żaden z elementów działających w systemie mającym w swoim celu innowacyjność nie zajmuje się innowacyjnością. Ludzie pracujący w takich systemach zajmują się wszystkim innym, tylko nie tworzeniem innowacji. Tworzą raporty, oceniają idee, robią konferencje itp. ale na pewno nie tworzą innowacji samych w sobie. Najlepiej to widać na przykładzie wszelkich publicznych systemów czynienia gospodarki bardziej innowacyjną. Ich rezultatami prawie zawsze są stosy publikacji, konferencje, wykłady, raporty, analizy. Czy widzieliście gdzieś listę innowacji, które faktycznie zostały stworzone za pieniądze z takich programów? Jak ta suma pieniędzy ma się do sumy przeznaczonej na raporty, publikacje i konferencje? Podobnie w firmach dobrze jest sprawdzić jaka jest tak naprawdę efektywność wszelkiego typu programów innowacyjności. Ja osobiście jeszcze nie widziałem takiego systemu, który w sposób przejrzysty zapewniałby takie dane.

Wniosek jest taki, że jeżeli już koniecznie mamy skonstruować system to trzeba bardzo uważać na to aby faktycznie robił on to co powinien. Osobiście jestem zwolennikiem czystago rozliczania po efektach. Czyli na przykład sprawdźmy ile kosztuje rocznie utrzymywanie tej części Urzędów Pracy, która ma znajdować bezrobotnym pracę, po czym podzielmy to przez ilość bezrobotnych, która dzięki tym urzędom pracę znalazła. Zobaczymy jaka jest efektywność. Ta miara pozwoli stwierdzić jaka część naszego systemu tak naprawdę zajmuje się produkcją celów sysemu a jaka część przeznaczana jest na "działania wspierające i koordynujące".

Więcej przemyśleń na podanej stronie. Zachęcam do krytycznego przeczytania i porównania ze znanymi Wam systemami, zwłaszcza pobudzającymi innowacyjność.

I tak na koniec. Sam osobiście słyszałem jak jeden z prezesów pewnej miliardowej korporacji powiedział, że na polu innowacyjności on nie boi się żadnej innej wielomiliardowej korporacji - prawdziwym zagrożeniem dla jego firmy jest dwóch zapalonych młodzieńców w garażu. I to niech będzie morał dysputy o tym jak się mają duże systemy do innowacji.

czwartek, 10 maja 2007

Kontrakty na projekty zwinne - wg. PMI

To tylko zalążek bardzo ciekawego tematu. Prędzej czy później każda osoba, która ma do czynienia z projektami zwinnymi stanie przed pytaniem jak skonstruować kontrakt na taki projekt. Pełna odpowiedź na to pytanie jest zdecydowanie dłuższa niż ten post. Tutaj zajmę się tylko małą ciekawostką, którą znalazłem w książce "PMP Exam Prep" by Rita Mulcahy. Jak tytuł wskazuje książka omawia zarządzanie projektami według standardów PMI. W rozdziale o kontraktach (zarządzanie dostawcami) napisane jest tak (moje wolne tłumaczenie):

"Kontrakty gwarantujące zwrot poniesionych kosztów - [...] Ten typ kontraktów jest stosowany kiedy kupujący potrafi tylko opisać co jest wymagane a nie potrafi opisać co trzeba zrobić (p. kiedy kompletny zakres projektu nie jest znany, tak jak w sytuacjach kiedy kupujemy unikalną wiedzę)[...]
Kontrakty przewidujące stałą kwotę - [...] Ten typ kontraktów jest najbardziej odpowiedni kiedy kupujący potrafi dokładnie opisać zakres kontraktu [...]"
I jeszcze w innym miejscu w tym samym rozdziale:
"Zestawienie zakresu prac kontraktu:
- dla kontraktów gwarantujących zwrot poniesionych kosztów - w tym przypadku zakres prac opisuje tylko wymagania, gdyż kupujemy wiedzę ekseprcką "jak to zrobić". Kupujący może nie wiedzieć dokładnie co i jak trzeba wykonać.[...]
- dla kontraktów przewidujących stałą kwotę - zakres prac musi być całkowicie wyczerpujący, gdyż kupujemy "zrób to" a nie "jak to zrobić". Aby kupujący mógł ustalić cenę musi wiedzieć zawczasu o całym zakresie swojej pracy"
Z powyższego jasno wynika, że nawet tak szacowna i konserwatywna w swoim podejściu do zarządzania projektami instytucja jak PMI uznaje, że jak nie wiadomo jak dokładnie wykonać pracę i kupujemy unikalną wiedzę na ten temat to kontrakty typu fixed-price nie mają sensu. Rewelacja. Od dzisiaj na pytanie o to jakie kontrakty stosować w przypadku projektów zwinnych będę odpowiadał, że zgodnie ze standardami PMI w każdym przypadku kiedy kupujemy wiedzę ekspercką o tym jak wykonać pewną rzecz stosujemy kontrakty typu "zwrot kosztów" a nie "stała cena".

PS. I tak żeby wszystkim uzmysłowić. W przypadku oprogramowania nawet najdokładniejsza specyfikacja wymagań dostarczona przez klienta wcale nie jest "jak to zrobić" tylko nadal "co zrobić". Aby stosować (wg. powyższej definicji PMI) kontrakty "stała cena" w świecie IT trzeba by aby wykonawca dostawał od zleceniodawcy projekt techniczny. Tak robi się na przykład w budowlance. Jak wynajmujecie ekipę, żeby wybudowała dom, to robi ona wycenę na podstawie projektu architektonicznego a nie specyfikacji wymagań typu "chcę cztery okna, dwa pokoje a w kuchni ma być jasno".

wtorek, 1 maja 2007

"Zwinna" dokumentacja

Niejednokrotnie gdy rozmawiałem na temat metod zwinnych zarządzania projektami IT pojawiały się sugestie, że metody te to "wolna amerykanka" nie do zastosowania w "poważnych" sytuacjach. Jako jeden z głównych powodów podawano dokumentację. Od osób, z którymi rozmawiałem dowiadywałem się najczęściej, że metody zwinne zakładają brak dokumentacji projektu. Nic bardziej błędnego.

Metody zwinne (niektóre, żeby być całkowicie zgodnym z prawdą) zakładają brak zbędnej dokumentacji projektu. Ale żadna nie zakłada zrezygnowania całkowicie z dokumentacji. Wręcz przeciwnie, z tego co zauważyłem projekty realizowane metodami zwinnymi są dużo lepiej udokumentowane niż projekty prowadzone metodami standardowymi. Dlaczego? Hmm, żeby odpowiedzieć w pełni trzeba zacząć od zastanowienia się dlaczego dokumentacja (głównie techniczna wykonawcza) stanowi piętę achillesową wielu projektów w IT. Z mojego doświadczenia i rozmów z projektantami/programistami wynika, że wytłumaczenie braku dokumentacji lub jej szczątkowości jest następujące:
  1. Bo nam się nie chciało, co można rozbić na:
    1. Bo to jest za trudne
    2. Bo nie wiem po co to pisać
  2. Bo nie było czasu
Zastanówmy się nad przyczynami źródłowymi tych tłumaczeń i jak one wyglądają z punktu widzenia metod zwinnych.

1.1 Bo to jest za trudne. Trudne? Jakim cudem dla programisty, który pisze kod może być trudne pisanie dokumentacji do tego, co sam stworzył? To by przecież oznaczało, że nie wie co pisał??? No cóż, nie zawsze. Przyczyna może być bowiem również taka, że dokumentacja jest pisana dużo później niż sam kod. To dość częsty przypadek, kiedy kierownik projektu najpierw naciska na jak najszybsze skończenie pracy programistycznej a potem, po 6 miesiącach, kiedy software poszedł właśnie do testów i programiści nie za bardzo mają co robić rzucane jest hasło "to teraz dokumentujemy nasz kod". Faktycznie, pisanie dokumentacji do kodu pisanego 6 miesięcy wcześniej i wielokrotnie później przerabianego jest trudne. Jeżeli nie niemożliwe. W przypadku metod zwinnych kierownik projektu jest ograniczony jedną iteracją, czyli maksymalnie ośmioma tygodniami, w większości przypadków czterema. To oznacza, że programista nigdy nie będzie komentował kodu starszego niż średnio 4 tygodnie. Oczywiste jest, że będzie to dużo łatwiejsze. A w połączeniu z następnym punktem stanie się wręcz niezbędne.

1.2 Bo nie wiem po co to pisać. Duży uśmiech :-) W większości przypadków i projektów zarządzanych standardowo faktycznie programiści nie wiedzieli po co ta dokumentacja. Odgórne zarządzenie "teraz piszemy dokumentację techniczną" przychodziło zwykle w momencie kiedy system był już skończony. Co więcej przy założeniu, że to system pod konkretnego klienta i konkretne wymagania po co w takim momencie pisać dokumentację, skoro robota jest skończona? Z punktu widzenia programisty strata czasu. W przypadku metod zwinnych sprawa staje na głowie. Po pierwsze średnio co 4 tygodnie ma się ukazać gotowa wersja systemu. Łącznie z dokumentacją. Co już stanowi motywację do jej pisania. Jeszcze lepszą motywacją jest to, że w metodach zwinnych programista nie wie, co będzie realizował w kolejnej i następnych iteracjach. Skutkiem czego nigdy nie jest pewny kiedy będzie musiał wrócić do fragmentu kodu, który właśnie skończył pisać. To powoduje, że sam programista ma wielką motywację do pisania dokumentacji, dlatego że robiąc to robi dobrze sobie a nie kierownikowi czy komukolwiek innemu. Doświadczenie wskazuje, że najlepiej aby każdy z programistów na własnej skórze zobaczył co to znaczy pracować w n-tej iteracji na nieopisanym kawałku kodu stworzonym w iteracji n-3. Trochę kosztowny sposób nauki, ale skuteczność jest rewelacyjna. Po jednym takim przypadku nigdy nie będzie więcej problemów aby ten konkretny człowiek opisał to co robi.

2. Bo nie było czasu. Tu sprawa jest najbardziej skomplikowana. Co to znaczy, że nie było czasu? Projekt był źle oszacowany. Albo źle oszacowano czas trwania zadań i dokumentacja jako najmniej ważny element została pominięta w celu terminowego skończenia funkcjonalności (co ciekawe mówią tak te same osoby, które zarzucają zwinnym metodom, że są złe bo nie ma dokumentacji). Albo sytuacja jest jeszcze gorsza i w ogóle nie wzięto pod uwagę czasu potrzebnego na wykonanie dokumentacji technicznej. Metody zwinne w prosty sposób nie pomogą, ale zwykle pomagają nie-wprost. Po pierwsze są krótkie iteracje z rozbiciem na zadania. W związku z tym łatwiej jest pokazać czas przeznaczony na pisanie dokumentacji i nikt zwykle nie ma wątpliwości, że to tam powinno się znaleźć. Łatwiej jest bowiem dodawać po 2 dni na aktualizację dokumentacji do każdej z 10 iteracji, każda trwająca po 4 tygodnie niż z 10-cio miesięcznego projektu jeden miesiąc roboczy (20 dni) przeznaczyć na dokumentację. Po drugie natomiast i ważniejsze z powodów opisanych w poprzednim akapicie sami programiści, czyli osoby wykonujące zadania będą miały dużą motywację do pisania dokumentacji i sami nie pozwolą kierownikowi zapomnieć o tym aspekcie. Oczywiście działając z bardzo niskich pobudek, bo dla ułatwienia sobie pracy, ale czy to ważne?

Podsumowując metody zwinne systemowo ułatwiają pisanie dokumentacji. Nie wymuszają, ale ułatwiają. I tak za stan dokumentacji na koniec projektu odpowiada kierownik. Bez jego zdecydowanych działań, ustalenia z zespołem jasnych reguł i ich późniejszego egzekwowania rezultaty będą dużo poniżej oczekiwań. Moje doświadczenie wskazuje, że projekty realizowane zgodnie z metodami zwinnymi były najlepiej udokumentowanymi jakie widziałem. Do tego stopnia, że ostatnio jak przekazywaliśmy do innego zespołu pewien projekt (niezbyt duży, jakieś 4000 roboczogodzin) razem z dokumentacją zrealizowany czystym SCRUMem okazało się, że w okresie wsparcia (2 miesiące) nie dostaliśmy ani jednego pytania dotyczącego kodu czy też spraw wykonawczych.


PS. Cały czas w tym wpisie mowa była o tzw. technicznej dokumentacji wykonawczej i zdecydowanie uwagi powyższe nie dotyczyły np. dokumentacji użytkownika.

SHITS

W nawiązaniu do opublikowanych wcześniej powodów dla których dobrzy managerowie nienawidzą innowacji znalazłem jeszcze jedną ciekawostkę. Tym razem nie jest to powód a taktyka działania. Opisana przez Guy'a Kawasaki w jego książce "Art of Start". SHITS to akronim od:
Show
High
Interest
Then
Stall

Czyli okaż duże zainteresowanie a potem zastopuj. Po chwili zastanowienia można dojść do wniosku, że takie zachowanie jest prostym skutkiem powodów o których pisał Leadbeater. Zacznijmy od tego, że każdy manager wie, że innowacje są potrzebne. Bo taka jest moda, bo tak piszą w książkach, etc. Jednocześnie każdy stara się wykonywać to co od niego oczekują i od czego zależy jego premia. Jak wiadomo premia managerów zależy w znakomitej większości przypadków od bieżących zysków firmy. Aby zaś dbać o bieżące zyski firmy należy dbać o aktualne operacje/bieżące potrzeby. Każde działanie, które nie jest poświęcone zarabianiu pieniędzy teraz jest działaniem, które potencjalnie obniża premię managera. Jakie więc jest poparcie dla takich działań?

Nakładając na siebie dwie odmienne postawy: świadomość tego, że innowacje są potrzebne "na przyszłość" oraz fakt, że wynagrodzenie zależy w większości wypadków wyłącznie od bieżącej zyskowności co się stanie jeżeli jakiś pracownik przyjdzie do dobrego managera z innowacyjną ideą? Otóż na pewno wyrażone zostanie duże nią zainteresowanie. Zainteresowanie wynika z faktu, że przecież innowacje są wpisane w strategię firmy, wszyscy wiedzą że są potrzebne itp. Zainteresowanie ma też jeszcze jedną zaletę: nie kosztuje. Kosztują natomiast następne etapy: eksploracji i rozwoju idei, przekształcania jej w produkt lub usługę. Czy dobry manager pozwoli sobie na przesunięcie części zasobów pracujących na bieżący zysk firmy do takich działań? W większości przypadków nie od razu - chce mieć pewność, że nikt nie będzie miał pretensji do tego, że jego zyski w krótkim terminie mogą zacząć spadać. Zacznie się więc szukanie sponsorów u wyższego managementu, czekanie na kolejny cykl planowania, odwoływanie się do działów centralnych z prośbą o dodatkowe zasoby, sprawdzanie zgodności pomysłu ze strategią firmy. Jednym słowem stopowanie innowatora, który jest już bardzo podekscytowany wyrażonym wcześniej zainteresowaniem. SHITS w czystym wydaniu.

Ciekawe, czy którykolwiek z tych dobrych managerów zastanowił się czasami jak czuje sie taki innowator, któremu najpierw okazano duże zainteresowanie a potem zrzucono na barki tysiące powodów dla których na wdrożenie idei trzeba "poczekać". Ile razy wytrzyma taki cykl zanim dojdzie do wniosku, że lepiej się nie stresować i nie przychodzić z ideami? Ile może stracić firma na utraconych korzyściach.

I na koniec pytanie do wszystkich wyższych managerów w organizacjach komercyjnych: w jakim stopniu Wasze systemy motywacyjne i zarządzania wspierają zarabianie przez Waszą firmę pieniędzy dzisiaj i w przyszłości?