niedziela, 18 października 2009

Własność funkcjonalności

W projektach informatycznych zdarza się bardzo często sytuacja kiedy projekty jest na tyle duży, że do poprawnego zdefiniowania wymagań potrzeba więcej niż jednej osoby. Po prostu wiedza dziedzinowa dotycząca projektu nie jest możliwa do zgromadzenia przez jedną osobę. W takim wypadku szczególnej uwagi nabiera kwestia tego, kto jest "właścicielem" poszczególnych funkcjonalności.

Przez właściciela funkcjonalności rozumie się osobę, która jest w pełni odpowiedzialna za zdefiniowanie danej funkcjonalności i zwykle będzie osobą używającą jej w przyszłości (odbiorcą korzyści biznesowej dostarczanej przez daną funkcjonalność). Zdefiniowanie takiej osoby jest niezmiernie ważne w kontekście mogących się pojawić wątpliwości dotyczących tego jak ma działać zdefiniowana funkcjonalność. Musi być ktoś, kto ma ostateczny głos w sprawie zdefiniowania pożądanego sposobu zachowania się systemu. W mniejszych systemach tą osobą jest właściciel produktu, w większych często właściciel produktu nie ma wystarczającej wiedzy aby decydować o każdej funkcjonalności i dlatego warto wyznaczać właścicieli poszczególnych funkcjonalności. Najlepiej właściciela po prostu zapisać na karcie funkcjonalności.

Powyższy system działa dobrze, do czasu kiedy nie zajdzie sytuacja w której dwie funkcjonalności zdefiniowane przez różne osoby stoją w konflikcie ze sobą. Wbrew pozorom często tak jest. Na przykład w systemach kompleksowo obsługujących przedsiębiorstwa proces sprzedaży zakłada zwykle udział działów sprzedaży, magazynu, księgowości a często także produkcji. Każdy z tych działów może mieć różną koncepcję tego jak proces sprzedaży wyglądać powinien. W takich sytuacjach osobą rozstrzygającą powinien być właściciel produktu. Niezależnie bowiem od właścicieli poszczególnych funkcjonalności musi istnieć ktoś, kto jest odpowiedzialny za całość definiowania wymagań i w związku z tym za ostateczny kształt projektowanego systemu. Tą osobą jest właśnie właściciel produktu. W przypadku dużych systemów, gdzie występuje wielu właścicieli funkcjonalności brak właściciela produktu jest bardzo często spotykanym błędem.

I na koniec: w takich sytuacjach jak opisana bardzo ważne jest, aby właściciel produktu był mocno "umocowany" w strukturze organizacji. Jest to konieczne, gdyż prędzej czy później będzie musiał on godzić wymagania różnych działów i forsować rozwiązania korzystne dla całości przedsiębiorstwa a nie dla poszczególnych kierowników. Osoba nisko stojąca w hierarchii, bez odpowiedniego autorytetu formalnego i nieformalnego nie ma szans w starciu z kierownikami "silosów". Wyznaczenie mało znaczącego właściciela produktu jest drugim bardzo często popełnianym błędem w opisywanych sytuacjach.

Etykiety: , , , ,

niedziela, 13 września 2009

Księga procedur a 15 minut

Dzisiaj będzie stricte o projektach IT. Kiedyś dawno temu przeczytałem, że programista pracując nad nowym kodem średnio co 15 minut podejmuje ważną decyzję technologiczną. Fakt ten przypomniał mi się w zeszłym tygodniu, kiedy zaangażowałem się w ciekawą dyskusję nad procedurami w firmie.

Ogólnie pytanie brzmi: jak dokładnie można opisać procedury, które powinien stosować pracownik. Istnieje pewna grupa przekonań, według których procedury mogą i powinny opisywać każdą istotną czynność wykonywaną przez pracownika. Założenie stojące za takimi stwierdzeniami jest takie, że można przewidzieć i opisać każdą jedną sytuację wobec której stanie pracownik. A jak już będzie to opisane to pracownikowi będzie łatwiej pracować, bo zamiast myśleć (?!) sięgnie tylko do odpowiedniej procedury. Hmm, ciekawe, ale na pewno nie w projektach IT. Być może w budownictwie, którego tradycje sięgają kilku tysięcy lat można skatalogować i opisać każdy jeden przypadek. Ale w programowaniu? Gdzie każdą rzecz można wykonać na przynajmniej kilka sposobów? Gdzie decyzje technologiczne podejmuje się co 15 minut? Nawet gdyby teoretycznie było to możliwe księga wzorców projektowych musiałaby liczyć tysiące stron. A gdzie procedury decydowania, który wzorzec użyć? Po pierwsze nikt nie byłby w stanie tego opisać, a jeżeli nawet to potem nikt nie byłby się w stanie tego nauczyć :-)

Co więc zamiast ścisłych procedur? Po pierwsze określone ramy postępowania, czyli np. pracownicy wiedzą co jest ważne w danym rozwiązaniu: elastyczność czy wydajność. Po drugie właściwi pracownicy, którzy potrafią użyć swojej inteligencji do wybrania spośród znanych im rozwiązań tego najlepszego akurat w zadanych ramach. Co 15 minut :-) Tu problem jest większy, ale cóż za to w końcu firma płaci programiście albo innemu administratorowi, żeby to ON się znał na rzeczy. Jeżeli firma uważa, że ON się nie zna, to czemu go jeszcze zatrudnia? Pracownik musi być na tyle inteligentny i proaktywny, żeby potrafić zastosować w danym momencie rozwiązanie najlepiej realizujące cel postawiony dla danego oprogramowania. Jeżeli firmie uda się zbudować taki zespół i ustalić wspierającą go strukturę zarządzania to będzie ona na pewno bardziej "agile" (zwinna) niż firmy starające się opisać każdą decyzję pracownika w opasłym tomie procedur.

Etykiety: , , , ,

piątek, 4 września 2009

Założenia to przekleństwo

Czasami warto jest się przyjrzeć głębiej powodom, dla których podejmowane są działania uważane przez wszystkich za oczywiste. Dla przykładu pierwsza z brzegu rzecz czyli planowanie. Wszyscy wiemy, że to jest ważne, jest podstawą pracy itd. Projekty z definicji są działaniami, które są innowacyjne, które zawierają w sobie pewien element niepewności. Dlatego też musimy je planować a nie działać automatycznie jak to się robi w przypadku procesów. Plan jest następnie realizowany, po czym, w dużej części przypadków, następuje brutalne zderzenie z rzeczywistością, które dla planu okazuje się być nie do przeżycia. Zwykle w wyniku nieprzewidzianych zdarzeń muszą nastąpić poważne zmiany w planie jak i w samych produktach projektu.

Interesujące jest co dzieje się dalej. W większości środowisk, z którymi miałem do czynienia podejmuje się natychmiastowe działania naprawcze skupiające się wokół generalnego twierdzenia "musimy lepiej planować". Przez "lepiej" w tym wypadku określa się zwykle dogłębniej, dokładniej i bardziej szczegółowo. Generalnie bardziej kosztownie. I tu pojawia się pytanie następujące. Jakie założenie stoi za twierdzeniem, że więcej zasobów poświęconych na planowanie automatycznie przekłada się na lepszą realizacje tychże planów w przyszłości?

Jak dla mnie założenia za tym twierdzeniem są następujące "planując dłużej uzyskujemy większą kontrolę nad przyszłością" oraz "dłuższe planowanie powoduje zmniejszenie liczby zmian w przyszłości". Czy te założenia są prawdziwe? Wątpię. Czy to oznacza, że planowanie jest zbędne. Oczywiście nie. Oznacza tylko, że nigdy nie możemy oczekiwać, że maksymalne wydłużenie analizy i planowania spowoduje automatyczny sukces naszego projektu. Tak się nie dzieje. Od pewnego momentu mimo przeznaczania coraz większych nakładów na planowanie "uzysk" dokładności jest minimalny. A im działanie jest bardziej innowacyjne tym to "wypłaszczenie" następuje szybciej.

Co z tym zrobić? Może zamiast brnąć w taki system oparty na błędnym założeniu skonstruować system, który dostosowuje się do rzeczywistości. Czyli zadać sobie pytanie "jak powinien wyglądać mój system realizacji projektów jeżeli założę, że zmiany na pewno nastąpią". Jeżeli uda się taki system zbudować i wprowadzić w życie to zamiast walczyć z rzeczywistością otrzymamy organizację potrafiącą w danej rzeczywistości idealnie zarządzać.

P.S. Oczywiście powyższe wywody nie dotyczą pewnej klasy systemów, np. takich gdzie gra idzie o życie ludzkie (projektowania samolotów).

Etykiety: , , , ,

środa, 29 lipca 2009

Metody realizacji projektów

Poniżej moje autorskie, przygotowane w konkretnym celu i dla konkretnej okazji, o której tutaj nie będę pisał, porównanie metod realizacji projektów. Można używać do woli, pod warunkiem podania źródła.

Metoda ścieżki krytycznej + EVM
Motywacja historyczna:
W dużych projektach rządowych chciano wiedzieć, na którym ciągu zadań powinien skupiać się kierownik, aby zapewnić realizację projektu w czasie.

Typowe rezultaty wdrożenia metody:
  • Projekt zobrazowany jako lista prac do wykonania na osi czasu
  • Ustalona odpowiedzialność za zadania
  • Zmniejszone ryzyko opóźnienia projektu
  • Możliwość formalizacji planowania i zarządzania projektami
  • Iluzja pełnej kontroli (daty rozpoczęcia i zakończenia każdego zadania)
  • Realna możliwość oceny efektywności prac zakończonych (EVM)
Typowe przeszkody we wdrożeniu
  • Metoda tak stara, że teoretycznie nie powinno być, ale:
  • Wymusza dużą formalizację projektów
  • Nie daje szybkich wygranych
  • Generowane są dane a nie informacje
  • Łatwo skupić się na przerzucaniu formularzy zamiast zarządzaniu projektem

Łańcuch krytyczny (CCPM)
Motywacja historyczna:
Dla przedsiębiorstw komercyjnych kluczowe stało się realizowanie projektów w pierwotnie planowanym terminie przy ograniczonej liczbie zasobów


Typowe rezultaty wdrożenia metody:
  • Projekt zobrazowany jako sieć połączonych zadań
  • Ustalona odpowiedzialność za zadania
  • Minimalne choć bardzo intensywny proces nadzorowania projektów
  • Brak przeciążenia zasobów
  • Maksymalizacja prawdopodobieństwa oddania projektu na czas (do 95%)
  • Możliwość proaktywnego nadzorowania realizacji
Typowe przeszkody we wdrożeniu
  • Brak jest jasnego uzasadnienia biznesowego wdrożenia
  • Wymaga zmiany kultury pracy i mierników
  • Pełne wdrożenie wymaga zgody wszystkich szczebli i działów
  • Metoda na tyle skomplikowana, że wymaga wdrożenia zintegrowanego systemu IT
  • Postrzeganie jako wdrożenia tylko systemu IT
  • Metoda nieodporna na zmiany sieci projektu w trakcie trwania


Metody zwinne (agile)
Motywacja historyczna:
Branża informatyczna zauważyła, że konieczność planowana całości projektu przed jego rozpoczęciem nie sprawdza się w środowisku, gdzie zmiany bardzo łatwo się wprowadza – zastosowano podejście radykalnie różne od dotychczasowych


Typowe rezultaty wdrożenia metody:
  • Projekt rozpisany jako lista funkcjonalności produktu
  • Szybkie dostarczanie najbardziej wartościowych funkcji
  • Nowe wersje dostarczane regularnie
  • Łatwe dostosowywanie produktu do zmian
  • Można pracować mimo braku pełnego planu
  • Zdrowe relacje w zespołach

Typowe przeszkody we wdrożeniu
  • Zbyt proste – wszyscy myślą, że zrozumieli
  • „Cieńka czerwona linia” między chaosem a agile
  • Wyższe szczeble zarządzania chcą „ciężkich” procesów
  • Kierownicy produktu nie trzymają się założeń
  • Wymaga zmiany kultury pracy i mierników

Na koniec drobna uwaga:
Odpowiedzialnością każdego specjalisty, w tym kierownika projektów, jest znać jak najwięcej różnych narzędzi i stosować te, które najlepiej spełnią cele postawione w danej sytuacji. Jak to kiedyś ujął mój kolega "chroń mnie Panie przed człowiekiem, który przeczytał tylko jedną książkę".


Etykiety: , ,

piątek, 22 maja 2009

mBank antyinnowacyjny

Dzisiaj jak nigdy będzie osobiście, aczkolwiek nawiązanie do tematyki bloga na koniec się pojawi. Szerszy kontekst opisanej niżej sytuacji pochłaniał mnie przez ostatnich kilka tygodni. Mimo to nie napisałbym tego posta, gdyby nie fakt, że instytucja, o której mowa naśmiewa się w reklamach z konkurencji przedstawiając ją jako “bankozaury” i jawnie sugerując, że to ona właśnie jest ta nowa i innowacyjna. Więc chyba normalnym jest oczekiwanie, że będzie miała innowacyjny na rynku sposób podejścia do klienta. Spróbowałem.

Historia zaczęła się od tego, że potrzebowałem kredyt. Nie jakiś super bardzo duży, ale jak sobie policzyłem i tak dla banku będzie to zysk w wysokości ładnych kilku średnich krajowych. Ze względu na to, że jestem stałym klientem mBanku (między innymi dlatego, że mam alergię na przebywanie w oddziałach bankowych i stanie w kolejkach) pierwsza próba to oczywiście mBank. Prośba o kontakt wysłana przez stronę www, konsultantka oddzwania wtedy, kiedy powinna. Super. Mina zrzedła mi po 2 minutach rozmowy. Okazało się, że mBank nie przyjmie mojego wniosku kredytowego. Dlaczego? Bo za krótko prowadzę działalność gospodarczą. Za krótko o 7 dni, żeby być dokładnym. Za tydzień wniosek mógłbym złożyć, teraz nie. I to był koniec rozmowy. Nieważna była kwota, przeznaczenie, dochody, nic. “Pan zadzwoni za 7 dni to będziemy z Panem rozmawiać, teraz nie.” Ręce mi opadły. Rozumiem, jakby bank przyjął wniosek, rozpatrzył i przysłał mi odpowiedź w stylu przepraszamy, ale ten kredyt jest obarczony zbyt dużym ryzykiem/nie ma Pan zdolności czy cokolwiek innego. Ale odmówić przyjęcia wniosku?

Absurd całej sytuacji polega przede wszystkim na tym, że mBank nie chciał rozmawiać ani sprawdzić jaki to kredyt ani jak on się ma do aktywów czy dochodów. Czyli odmawiając nie mieli pojęcia o jakim zysku dla nich przy jakim ryzyku rozmawiamy. Poza tym, tak naprawdę na TERAZ to ja potrzebowałem decyzję kredytową, pieniądze mogliby mi wypłacić nawet nie 7 a 21 dni później. Tylko o to oczywiście też nikt się nie spytał, lepiej i prościej było powiedzieć, że wniosku ode mnie nie przyjmą "bo taka jest procedura". Dodatkowo zostałem postraszony, żebym nie próbował nawet złożyć wniosku samodzielnie przez internet bo jak to zrobię to złamię jakieśtam regulaminy i mBank na 3 miesiące odmówi mi jakichkolwiek usług kredytowych (czy coś podobnego). W tym momencie zupełnie już odechciało mi się z nimi rozmawiać.

Ok, super-innowacyjny bank ewidentnie nie chce, więc idziemy do “bankozaura”. Druga próba to Santander Consumer. Oni zaczęli bardziej logicznie, czyli od pytania na co kredyt i w jakiej kwocie. Wstępne wyliczenie rat kredytu dostałem od ich konsultanta mailem jakieś 4 godziny od wyrażenia zainteresowania. Nie byłoby w tym może nawet nic dziwnego, gdyby nie fakt że ten mail został wysłany o godzinie 21:46 - trochę mi szkoda p. Krzysztofa, który musiał pracować po godzinach, ale poczułem się doceniony. Wniosek o kredyt - jedna kartka A4, wypełnienie jej przy pomocy konsultanta zajęło jakieś 15 minut. Konsultant popatrzył się na parametry kredytu i po porównaniu wartości “inwestycji”, kwoty kredytu i dochodu netto od razu zaproponował procedurę uproszczoną - sprowadza się do złożenia jednego podpisu. Decyzję kredytową miałem 3 godziny później - otrzymałem ją telefonicznie. Całość trwała niecałe 24 godziny a podejrzewam, że gdyby nie fakt, że w międzyczasie zajmowałem się również innymi rzeczami, można ten czas jeszcze skrócić. Rewelacja.

Morały z tej historii są trzy:
  1. Nie wierz reklamom
  2. Reklamuj tylko to, co masz w rzeczywistości a nie to jakim chciałbyś być. Bo potem będziesz wyprzedzany przez dinozaury z własnej reklamy. I ktoś to jeszcze na blogu opisze ;-)
  3. Głębsza refleksja: podczas seminarium SPMP, o którym pisałem wcześniej, panowała zgoda, że innowacje to głównie innowacje przez “małe i”. W tym konkretnym wypadku na przykład innowacje dotyczące procesu i instrukcji obsługi wniosków kredytowych. To, że Santander wykazał się innowacyjnością (czy też w zasadzie zdrowym podejściem) oznacza, że to on właśnie zarobił. Drugi stracił. Przez tak dziwną bzdurę jak ewidentnie błędnie skonstruowany proces obsługi wniosków kredytowych. Takie drobne, małe innowacje w procesach operacyjnych jak widać mogą stanowić o traceniu lub przyciąganiu klientów.

Etykiety: , ,

wtorek, 12 maja 2009

PMO w sposób zwinny

Rok temu opublikowałem tutaj posta na temat wprowadzania zmian w organizacjach metodami zwinnymi:
http://www.wlochowicz.com/blog/2008/05/zwinne-zarzdzanie-zmian-w-organizacji.html

Natomiast parę dni temu znalazłem na PM Hut posta na temat... wprowadzania PMO w organizacji własnie dzięki metodom agile. Cytat:
If you’re building a PMO and have a 3 year plan – drop it now! [...] As you’ve guessed by the article title I am going to suggest that we steal a technique from the software development industry. While I am not an agile expert by any means, there are some very successful practices that you can employ while building and growing your PMO.

Czyli da się. Jest to możliwe nawet do wprowadzania zmian tak rozległych jak PMO w organizacji.

Całość do przeczytania na PM Hut:
http://www.pmhut.com/the-agile-project-management-office-pmo

Etykiety: , , , ,

wtorek, 14 kwietnia 2009

Narzędzia efektywnego zarządzania mniejszymi projektami

Tytuł tego postu to jednocześnie tytuł mojego wystąpienia na seminarium PMI we Wrocławiu 24 marca. Poniższą treść można traktować jako handout tej krótkiej prezentacji.

Na początek zdefiniujmy sobie co to jest ten “mniejszy projekt”. Metodą Alberta Einsteina mniejszy projekt to dla mnie projekt, dla zarządzania którym użycie MS Project jest zbyt skomplikowane / powoduje zbyt duży narzut zarządczy. W organizacjach takich jak je znam jest realizowanych wiele, bardzo wiele projektów, z których znacząca część to projekty małe. Ot choćby zmiana jednej czy drugiej procedury obsługi klienta, zorganizowanie spotkania dla klientów czy też wydanie nowej wersji katalogu firmowego. Tego typu aktywności często charakteryzują się wszystkimi cechami projektu, z tą właściwością, że ich złożoność jest o kilka rzędów wielkości mniejsza od złożoności projektu budowy nowego biurowca czy stworzenia systemu informatycznego. W związku z tym narzędzia informatyczne konstruowane z myślą o zarządzaniu projektami wielkości budowy biurowca nie mogą być wykorzystywane w sposób efektywny do tych mniejszych projektów. Głównie ze względu na swoje skomplikowanie, które powoduje, że narzut czynności zarządczych, które trzeba wykonać jest nieproporcjonalny do wielkości projektu.

Dla takich mniejszych projektów efektywne narzędzia wspierające zarządzanie nimi powinny być też mniejsze i zdecydowanie inaczej konstruowane. Na czym powinny się skupiać? Według PMI, i jest to niewątpliwie prawda, znacząca większość czasu pracy kierownika projektu jest poświęcona na komunikowanie się. W tym w szczególności na komunikowanie się z zespołem projektowym na temat poszczególnych zadań, ich statusów oraz postępu prac. W związku z tym jeżeli mówimy o efektywnym zarządzaniu projektami to podstawową funkcją, którą muszą wspierać narzędzia jest komunikacja.

Takimi właśnie narzędziami są pojawiające się ostatnimi czasy platformy internetowe oparte o technologi szumnie nazywane Web 2.0. Wiele z tych narzędzi było wręcz pisane jako nie-MS Project z nastawieniem na obsługę projektów mniejszych. Co ciekawe znacząca większość tych narzędzi kładzie nacisk właśnie na aspekty komunikacji w zespole i stara się rozwiązać ten problem poprzez udostępnienie wspólnej dla wszystkich interesariuszy platformy komunikacyjnej. Narzędzia te mają ze sobą wiele wspólnego. Do wspólnych cech zaliczyć należy przede wszystkim (oprócz dostępu przez internet z dowolnego miejsca na świecie a często także z dowolnego urządzenia mobilnego) nastawienie na maksymalne uproszczenie funkcjonalności i uczynienie doświadczenia użytkownika z pracy z narzędziem jak najbardziej pozytywnym. Poza tym, twórcy tych narzędzi garściami czerpią ze Steva Jobsa i zazwyczaj umieszczają w nich tylko i wyłącznie niezbędne funkcje, co czyni te narzędzia prostymi i efektywnymi w użyciu. Przykładowymi, choć istnieje o wiele więcej, narzędziami tego typu są BaseCamp i ActiveCollab.

Narzędzia te zbudowane są wokół koncepcji realizacji projektu poprzez osiąganie kolejnych kamieniu milowych, które to znowu są osiągane poprzez realizację zestawów zadań. Choć różni się to w szczegółach pomiędzy narzędziami to większość z nich pozwala na zdefiniowanie dla projektu dat osiągnięcia kamieni milowych. Następnie dla danych kamieni tworzy się listy zadań, przypisując odpowiedzialności do członków zespołów. Realizacja zadań jest wspomagana poprzez udostępnienie miejsca na dyskusje (coś w rodzaju forów internetowych), przechowywanie plików oraz inne dodatki zależne od konkretnego narzędzia. Śledzenie postępu przez kierownika odbywa się poprzez skondensowane dashboard’y prezentujące na jednym ekranie przeglądarki stan tego co dzieje się w projekcie. Jest to zwykle bardzo ciekawie zorganizowane, bo pokazuje stan komunikacji (co, kto, kiedy powiedział/wysłał/zaraportował) a nie jakiś wyimaginowany procentowy stan zaawansowania pracy. Takie podejście powoduje umieszczenie w jednym miejscu wszystkich informacji z realizacji projektu a także bardzo dobry pogląd na to, co się z tym projektem od strony wymiany tejże informacji dzieje.

Narzędzia te oczywiście mają także wady. Zaliczyć należy do nich głównie fakt, że czasami, zwłaszcza w sytuacjach kiedy bardzo zależy nam na czasie, mimo wszystkich uproszczeń ich użycie jest zbyt skomplikowane. Głownie dlatego, że mimo najnowszej technologii powiedzenie czegoś w bezpośredniej rozmowie jest nadal najbardziej efektywną formą komunikacji i nigdy chyba nie dorobimy się innej równie efektywnej. Drugą dużą wadą jest dla mnie to, że mimo wprowadzenia centralnego miejsca przechowywania informacji większość z tych narzędzi nie zapewnia kontroli wersji notatek, które tam się znajdują. To znaczy, że jeżeli ktoś wprowadzi jakąś informację to później można ją edytować i nie pozostawia to żadnego śladu. Takie zachowanie może wprowadzić szybko chaos komunikacyjny, zwłaszcza jeżeli osoby nie pracują w tej samej lokacji fizycznej. Kolejną wadą, czy też w tym przypadku raczej cechą, jest to że trzeba być bardzo świadomym wybierając to a nie inne narzędzie. Nie do każdego projektu one się nadają i realizacja nie każdego może być aż tak uproszczona. Ze względu na brak możliwości wymuszania sekwencji wykonywania zadań bardzo duża część projektów nie będzie mogła być efektywnie zarządzana.

Na koniec wypada tylko dodać, że jest to kolejna klasa narzędzi, którą warto znać. I używać wtedy i tylko wtedy kiedy ma to sens i jest właściwe dla danej sytuacji. Zdrowy rozsądek musi w pracy kierownika projektów odgrywać rolę pierwszoplanową.

Etykiety: , , ,