Innowacyjność

Własność funkcjonalności

noreply@blogger.com (Szymon Włochowicz) — Sun, 18 Oct 2009 10:59:00 +0000

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.

Księga procedur a 15 minut

noreply@blogger.com (Szymon Włochowicz) — Sun, 13 Sep 2009 18:36:00 +0000

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.

Założenia to przekleństwo

noreply@blogger.com (Szymon Włochowicz) — Fri, 04 Sep 2009 03:43:00 +0000

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).

Metody realizacji projektów

noreply@blogger.com (Szymon Włochowicz) — Wed, 29 Jul 2009 04:16:00 +0000

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ę".

mBank antyinnowacyjny

noreply@blogger.com (Szymon Włochowicz) — Fri, 22 May 2009 08:50:00 +0000

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:

Nie wierz reklamom
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 ;-)
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.

PMO w sposób zwinny

noreply@blogger.com (Szymon Włochowicz) — Tue, 12 May 2009 09:12:00 +0000

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

Narzędzia efektywnego zarządzania mniejszymi projektami

noreply@blogger.com (Szymon Włochowicz) — Tue, 14 Apr 2009 20:19:00 +0000

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ą.

Innowacja zarządcza

noreply@blogger.com (Szymon Włochowicz) — Mon, 06 Apr 2009 06:55:00 +0000

Wśród wszystkich innowacji, które może wprowadzić firma jest jeden typ, który zajmuje miejsce szczególne. Tym typem są tak zwane innowacje zarządcze (mangement innovation).

Mianem innowacji zarządczej określa się innowację polegającą na odejściu od tradycyjnych paradygmatów zarządzania w danej branży lub danym rynku. W wyniku takiej innowacji powstają nowe procesy, praktyki czy też struktury zarządzania pozwalające firmie działać w sposób odmienny od całej konkurencji. Celem takiej innowacji jest to, aby firma po przekształceniach miała znaczącą przewagę konkurencyjną nad innymi uczestnikami rynku.

Przykłady? Każda firma pracująca w systemie projektowym jak ognia unika kar umownych za opóźnienie końca projektu. A co by się stało, gdyby pojawiła się firma, która sama dobrowolnie będzie chciała wpisywać takie kary do umów i to w kwocie znacznie przekraczającej to co do tej pory chciał zamawiający? Większość firm produkcyjnych produkuje pod prognozy sprzedaży, zwykle w perspektywie 6-12 miesięcy. Co by się stało, gdyby dostawca nie wymagał od sklepu prognoz sprzedaży, a i tak zawsze zapewniał mu dostępność towaru? “Wszyscy wiedzą”, że aby zacząć prace nad systemem informatycznym trzeba wcześniej dokładnie zdefiniować wymagania. A co by się stało, gdyby stworzyć proces, który tego nie wymaga? Jaką siłę na rynku miałyby takie firmy? Jak na ich oferty reagowaliby klienci?

Piękno innowacji zarządczej polega na tym, że zbudowana na jej podstawie przewaga konkurencyjna jest niezwykle trudna do skopiowania przez innych uczestników rynku. Z zewnątrz wszystko wygląda bowiem prosto i logicznie, tym niemniej dzięki temu, że jest to odejście od paradygmatu konkurencja nie może skopiować innowacji tylko poprzez skopiowanie praktyk czy procesów. Konkurencja musiałaby również zmienić swój paradygmat zarządzania. A to jest bardzo trudne. I wielu się nie udaje. Najlepszym przykładem są tutaj amerykańskie i zachodnioeuropejskie firmy produkcyjne, które próbują skopiować TPS (Toyota Production System). Niestety, mimo że TPS jest dość dokładnie opisany jego skopiowanie, rozumiane jako uzyskanie takich samych efektów biznesowych, idzie bardzo opornie i nawet jeżeli teraz możemy już mówić o jakichś sukcesach to zajęło to jakby nie patrzeć kilkanaście lat.

Tak więc innowacja zarządcza pozwala zbudować relatywnie trwałą przewagę konkurencyjną. Na tyle trwałą, aby można było bez pośpiechu przygotować kolejną innowację. Niestety ceną za taki komfort jest fakt, że innowacja zarządcza jest niesamowicie trudna do opracowania a jeszcze trudniejsza do wdrożenia. Dokładnie z tych samych powodów dla których tak trudno skopiować ją konkurencji. No ale cóż, tylko odważni i wytrwali zdobędą szczyty...

Jeżeli to kogoś zainteresowało to jedynym znanym mi systematycznym procesem pozwalającym na szukanie i weryfikację pomysłów na innowacje zarządcze są narzędzia myślowe oparte o TOC. Zaś implementacje takich innowacji można znaleźć opisane w Strategy & Tactic Trees opublikowanych przez Goldratt Institute Inc.

Co się działo?

noreply@blogger.com (Szymon Włochowicz) — Thu, 26 Mar 2009 11:00:00 +0000

Witam serdecznie po dłuższej niż zwykle przerwie. W jej czasie zdarzyły się dwa ciekawe wydarzenia. 19 marca prowadziłem dyskusje panelową nt. innowacji w ramach spotkania organizowanego przez SPMP we Wrocławiu. Natomiast 24 marca prowadziłem wykład na seminarium PMI dotyczący narzędzi internetowych wspomagających zarządzanie "mniejszymi" projektami.

Dla mnie szczególnie ciekawe było seminarium SPMP nt. innowacji i z tego miejsca jeszcze raz dziękuję p. Bogumiłowi za zaproszenie do dyskusji. Ciekawie było usłyszeć ekspertów prowadzących wykłady, jeszcze ciekawiej posłuchać dyskusji panelowej, której przebieg był zaskoczeniem dla wszystkich, łącznie z prowadzącym :-) Stało się tak głównie ze względu na bardzo aktywny udział publiczności. Najważniejsze dla mnie rzeczy, które pojawiły się w dyskusji zebrałem poniżej.

Po pierwsze, praktycznie każdy z prelegentów zauważył jedną bardzo ciekawą rzecz. Mianowicie w języku polskim traktujemy innowację jako coś, co musi być "duże". Innowacją jest na przykład wprowadzenie na rynek nowego produktu czy też opracowanie nowego materiału. W rzeczywistości natomiast tego typu innowacje stanowią zdecydowaną mniejszość. Większość stanowią innowacje "przez male i" czli drobne usprawnienia, które jednak wdrożone od pomysłu do wersji rynkowej powodują stopniowe zwiększanie się konkurencyjności konkretnych organizacji. Co więcej takie małe innowacje są dużo prostsze do przeprowadzenia, więc być może to właśnie na nich powinniśmy się skupiać zamiast na ciągłym myśleniu i planowaniu jednej, wielkiej, przełomowej innowacji, która kiedyś nadciągnie.

Po drugie po bardzo ciekawej dyskusji wśród publiczności nastąpił konsensus na temat tego, że z obserwacji wynika, że w Polsce nie ma żadnego problemu z kreatywnością i pomysłami na innowacje. Jest natomiast duzy problem dotyczący zarządzania innowacjami rozumianego jako zorganizowany sposób przekuwania pomysłu na wartość biznesową. Tutaj dużo nam brakuje i warto skupić się właśnie na tym elemencie.

Po trzecie ciekawy, aczkolwiek bardzo kontrowersyjny był wątek dotyczący edukacji i tego, czy przez przypadek sposób w jaki kształcimy dzieci i młodzież nie działa przeciw koncepcji budowania gospodarki opartej o innowacje. Czyli mówiąc wprost czy to nie jest tak, że szkoła zabija wszelką innowacyjność i kretywność "produkując" absolwentów, którzy potrafia bardzo dobrze wypełniać pewne reguły działania ale nie są zdolni do stworzenia nowych reguł. Ja mam na ten temat własne przemyślenia, ale na razie odeślę do rewelacyjnej prezentacji na TED o sugerującym tytule "Ken Robinson says schools kill creativity".

Po ostatnie, aczkolwiek najciekawsze muszę powiedzieć, że bardzo pozytywnie zaskoczył mnie przedstawiciel firmy Elektrotim (niestety nie pamiętam nazwiska). Po pierwsze zdrowym podejściem a po drugie tym, że rdzennie polska firma ma tak fajne podejście do świata. Na przykład przeprowadza projekty badawcze z uczelniami. Ale anjbardziej ujęła mnie ta inicjatywa: Elektryzująca pasja. Cytując ze strony "Chcemy inspirować do rozwoju indywidualnej kreatywności i tworzyć podstawy pracy zespołowej. Dlatego też ważnym elementem naszego programu jest konkurs ,Elektryzująca Pasja, który ma na celu wyłonić i nagrodzić prawdziwe talenty. " I faktycznie z tego co opowiadał przedstawiciel Elektrotima takie talenty się znajdują. Dziękujemy i czekamy na więcej. Może w przyszłości polska X-Prize?

O narzędziach, o których mówiłem na seminarium PMI napiszę innym razem.

P.S. A na przyszłość obiecuję, że o wspomnianych wyżej wydarzeniach będę informował PRZED ich terminem a nie PO ;-)

Organizacja a miary

noreply@blogger.com (Szymon Włochowicz) — Wed, 11 Mar 2009 12:35:00 +0000

Poniższy tekst po redakcji będzie stanowił wstęp do skróconej wersji książki "Finanse do góry nogami".

Jednym z często poruszanych problemów zarządzania jest tzw. zarządzanie zmianą. Ten aspekt zarządzania najczęściej poruszany jest w kontekście kłopotów, które sprawia wprowadzenie zmian w zachowaniach ludzkich. Taki pogląd opiera się na popartej doświadczeniem obserwacji, że wprowadzenie dowolnej zmiany na poziomie zarządu czy kierownictwa firmy jest bardzo proste, wymaga zwykle jednego lub dwóch spotkań i ustalenia pożądanego kierunku. Natomiast dokonanie tego samego na poziomie zachowań wszystkich pracowników organizacji niespodziewanie staje się bardzo trudne. Pracownicy „nie chcą” się zachowywać zgodnie z wprowadzonymi zasadami.

Doświadczenie wielu organizacji stanowi jednak, że wbrew pozorom pokonanie tego pozornego oporu przed zmianą jest dość proste. Prostota wynika z zauważenia, że zachowania osób będących w organizacji są sterowane poprzez miary, które organizacja stosuje. Z tego powodu nie można oczekiwać prawdziwych zmian w organizacji, jeżeli nie zmieni się systemu miar. Z drugiej zaś strony, i to jest kluczowe spostrzeżenie, jeżeli zmieni się miary to organizacja dostosuje się do nich i zmiany będą albo samoistne albo bardzo łatwe do przeprowadzenia.

Na przykładzie zmian w organizacjach dotyczących wprowadzenia nowoczesnych metod zarządzania w miejsce zastałych wyodrębniono bardzo często popełniany błąd prowadzący wprost do zniweczenia całego procesu wprowadzania zmiany. Błędem tym jest skupienie się podczas wprowadzania zmiany tylko i wyłącznie na zmianie przekonań wyższego kierownictwa oraz na wprowadzeniu konkretnych praktyk nowego sposobu zarządzania. Zwykle polega to na przekonaniu przez konsultanta zarządu do nowej koncepcji oraz sprzedaniu odpowiedniej ilości segregatorów zawierających instrukcje jak swoją pracę mają wykonywać pracownicy. To jednak jest za mało aby odnieść sukces we wprowadzaniu zmiany – głównie ze względu na pojawiający się od razu „opór przed zmianą”. Odniesienie sukcesu gwarantuje tylko wprowadzenie rozwiązania całościowego, czyli oprócz zmiany przekonań i wprowadzenia praktyk powinno zmienić się także miary obowiązujące w organizacji. Prawidłowo przeprowadzony proces zaczyna się od zmiany przekonań kierownictwa. Te przekonania powinny posłużyć do zdefiniowania systemu miar w organizacji, który pozwoli mierzyć dostosowanie się organizacji do nowego sposobu zarządzania. Miary te jednocześnie powinny być tak skonstruowane, aby wspierać stosowanie nowych praktyk. Wdrożenie zaś praktyk to ostatnie co powinno zostać zrobione w procesie wprowadzania nowych metod zarządzania.

Pominięcie środkowego elementu powyższego procesu (czyli definiowania systemu miar) powoduje, że nowe praktyki stają często w sprzeczności ze stosowanym systemem miar. Ze względu zaś na to, że każdy z nas lubi jak się go docenia i jak uzyskuje dobre wyniki to podświadomie będzie starał się tak działać, aby wyniki w nadal stosowanym systemie pomiarowym były dobre. To zaś powoduje, że nie ma wsparcia dla nowych praktyk i są one bardzo szybko zastępowane starymi nawykami. Tymczasem zmiana stosowanych miar powoduje, że nawet jeżeli stare nawyki dalej pozostają, to nie są one wspierane przez system. Często wystarczy sama zmiana sposobu pomiaru, aby całkowicie zmienić zachowania w organizacji. Etap dystrybuowania segregatorów z nowymi instrukcjami można wtedy pominąć.

Rachunkowość przerobowa stanowi obecnie najprostszy i najskuteczniejszy system miar wspierający zmiany systemów zarządzania w organizacjach. Doświadczenia praktyków wskazują, że najbardziej pozytywną zmianą dla organizacji jest wprowadzenie nowego wskaźnika produktywności dla firmy, wyrażonego stosunkiem T/OE (przerób/koszty operacyjne). Ta miara zastępuje tradycyjny miernik efektywności kosztowej w firmie. Wskaźnik zdefiniowany w nowy, prosty sposób jasno uzmysłowia wszystkim w organizacji, że zwiększanie kosztów operacyjnych jest dobre – o ile zwiększa to przerób w sposób jeszcze bardziej znaczący. Zastosowanie takiego miernika, podobnie jak innych mierników rachunkowości przerobowej, bardzo szybko prowadzi do nastawienia całej organizacji na realizację jej celu głównego, czyli zarabiania pieniędzy teraz i w przyszłości.

Dyspozytor vs. Delegujący

noreply@blogger.com (Szymon Włochowicz) — Thu, 05 Mar 2009 10:53:00 +0000

Jak wiadomo instytucję szefa wymyślono między innymi po to, aby zarządzać zestawami zadań zbyt dużymi do zrealizowania przez jedną osobę. Istnieją dwie metody w ramach których szef może podzielić się swoim zadaniem. Umownie nazwijmy to byciem dyspozytorem bądź delegującym. Dyspozytor to osoba, która przekazuje konkretną instrukcję do wykonania. Rozdziela pracę rozumianą jako zadania do wykonania. To znaczy każdy z członków zespołu otrzymuje listę rzeczy do wykonania a następnie rozliczany jest z tego czy postąpił zgodnie z przekazaną instrukcją.

Delegowanie natomiast to zupełnie inne podejście. Zamiast przekazywać zadania przekazuje się odpowiedzialność. Czyli określa się pożądany cel i jego parametry jakościowe, natomiast nie przekazuje się wprost instrukcji jakie zadania i w jakiej kolejności należy wykonać, aby określony cel uzyskać. W tym podejściu zakłada się, że sposób dojścia do celu najlepiej znany jest osobom faktycznie wykonującym daną pracę a nie menedżerom. Rolą menedżera jest przekazać odpowiedzialność, zapewnić pracownikowi środowisko, w którym może wykonywać swoją pracę bez przeszkód a następnie odebrać prace sprawdzając czy założone cele zostały osiągnięte.

W metodach zwinnych zarządzania projektami tak naprawdę możliwa jest do zastosowania tylko i wyłącznie metoda druga. Próba zastosowania metody pierwszej (dyspozytora) prowadzi bardzo szybko do powstania wąskich gardeł zarządczych na poziomie kierowników. W środowiskach agile za dużo rzeczy dzieje się zbyt szybko, aby kierownik mógł panować nad nimi na poziomie zadań do wykonania. Jeżeli chcemy aby w naszym środowisku osiągać szybko rezultaty to jedyną opcją jest przekazywanie odpowiedzialności. Fakt, menedżer traci kontrolę nad sposobem wykonywania pracy i musi swoim ludziom zaufać. Ale jednocześnie zyskuje możliwość osiągnięcia końcowego rezultatu wielokrotnie szybciej niż przy użyciu bardziej tradycyjnej metody dyspozytorskiej.

Należy tylko pamiętać, aby razem z odpowiedzialnością wydelegować uprawnienia. Najgorszą sytuacją, którą można zafundować swoim podwładnym jest dać im odpowiedzialność za coś, ale bez uprawnienia do decydowania o wszystkich zasobach i środkach potrzebnych do wykonania danej pracy. Stawiamy wówczas pracowników przed koniecznością wykonania pracy na którą nie mają wpływu. Nie mogą więc sami decydować o jej sukcesie bądź porażce. Taka sytuacja prowadzi wprost do dużej i narastającej frustracji osób zaangażowanych w projekty.

Last but not least wypadałoby jeszcze pamiętać o różnicach kulturowych. Ci z Was, którzy mieli przyjemność pracować z Hindusami dokładnie wiedzą, że zastosowanie znajduje tylko i wyłącznie jedna z opisywanych metod.

Przyczyna źródłowa

noreply@blogger.com (Szymon Włochowicz) — Thu, 19 Feb 2009 16:31:00 +0000

Pisząc o koncepcji Jidoka napisałem tak “[pracownik ma obowiązek] znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem [podjąć z powrotem pracę]”. Po zastanowieniu dochodzę do wniosku, że to jest świetny materiał na rozważania o tym, co powinno być elementem sesji retrospekcji i co leży w obowiązku kierownika projektu, zwłaszcza realizowanego metodami agile. Chodzi o to znajdowanie i eliminowanie przyczyn źródłowych problemów.

Jak się popatrzy na obecne środowisko pracy w wielu organizacjach to jedyną reakcją na problemy stosowaną przez wyższe kierownictwo jest coraz większy nacisk na to, aby problemów nie było. Jeżeli projekt przekracza deadline’y to kierownictwo wyznacza większe bonusy za dotrzymanie deadline’ów. Jeżeli jest za dużo błędów to grozi się obcięciem pensji za ponowne wypuszczenie błędnej wersji oprogramowania. Problem w tym, że takie podejście tak naprawdę konserwuje to, co jest. Bo zakłada, że wszystko robiliśmy dobrze, tylko się nie staraliśmy wystarczająco dobrze. Więc jeżeli następnym razem się postaramy bardziej to będzie dużo lepiej. Hmm, bardzo odważne założenie. W rzeczywistości będzie zapewne tak, że jak teraz przy tych metodach które mamy trochę nam nie wyszło to jak je zastosujemy jeszcze bardziej dokładnie to jeszcze bardziej nam nie wyjdzie.

Tak naprawdę rzadko kto podejmuje się zadania proponowanego przez Japończyków (choć nie tylko ich) czyli znalezienia przyczyny źródłowej takiego a nie innego stanu rzeczy. Wysiłek ten podejmowany jest rzadko, bo nie jest to zadanie proste. Przyczyna źródłowa oznacza zadawanie pytania “dlaczego” tak długo aż dojdziemy do odpowiedzi, której już dalej nie da się podzielić. Co więcej bardzo często znajdowanie przyczyny źródłowej polega na odkrywaniu i kwestionowaniu podstawowych założeń, na których oparta jest nasza organizacja i jej sposób działania.

Jeżeli popatrzyć na metodyki agile to najodpowiedniejszym miejscem do znajdowania przyczyn źródłowych problemów wydaje się być retrospekcja. Wówczas poza zastanowieniem się co się stało warto by też zastanowić się nad przyczynami źródłowymi problemów. Ponieważ nie jest to łatwe ani proste nie można się zastanawiać nad wieloma przyczynami źródłowymi jednocześnie. Raczej spośród wielu problemów nękających projekt należałoby wybrać jeden, który najbardziej boli i skupić się na jego rozwiązaniu. Czyli najpierw znaleźć jego przyczynę źródłową a dopiero potem wdrożyć rozwiązanie.

Aha i tutaj jedna uwaga. Przyczyny źródłowe problemów w projektach mają to do siebie, że często są tzw. przyczynami systemowymi. Czyli wynikają wprost z tego jak skonstruowany jest system, w tym wypadku system zarządzania w danej organizacji. Jeżeli przyczyna jest przyczyną systemową to aby permanentnie ją wyeliminować należy zmienić system. A to niestety często jest poza zasięgiem kompetencyjnym osób pracujących w projektach. Jedyne logiczne rozwiązanie w takiej sytuacji to rzeczony przypadek udokumentować oraz przedstawić odpowiednio wysokim menedżerom w firmie. A następnie mieć nadzieję, że zależy im na tym, aby ich system zarządzania działał sprawnie.

Dwa narzędzia, które mogą pomóc w znajdywaniu przyczyn źródłowych to na przykład A3 Problem Solving Method (bazująca na rozwiązaniach Toyoty) oraz Current Reality Tree (bazująca na narzędziach myślowych teorii ograniczeń).

Jidoka

noreply@blogger.com (Szymon Włochowicz) — Wed, 11 Feb 2009 12:24:00 +0000

Czytając wspomnianą tutaj już książkę “Implementing Lean Software Development” jeden element wybitnie wrył mi się w pamięć jako zupełnie dla mnie nowy. W ramach przedstawiania produkcyjnego lean’u i jego zasad autorzy opisali coś, co nazywa się po japonsku jidoka a po angielsku autonomation. Po polsku będzie chyba autonomizacja (?? choć po przemyśleniach nie wydaje mi się). Koncepcja jest tak prosta i tak oczywista, że wręcz dziwię się, że nigdy nie słyszałem o jej zastosowaniu do rozwoju oprogramowania.

W przypadku produkcji jidoka polega na tym, że każde odchylenie od pożądanego standardu jest natychmiast wychwytywane na bardzo niskim poziomie zarządczym a następnie usuwa się, uwaga, przyczynę powstania problemu a dopiero później powraca się do pracy. W praktyce oznacza to, że każdy z robotników pracujących przy taśmie jeżeli zauważy jakiekolwiek odchylenie od pożądanego stanu ma prawo i obowiązek natychmiast zatrzymać całą linię produkcyjną. Następnie znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem następuje ponowny rozruch linii. Ciekawe jest to, że te działania są podejmowane przez pracowników liniowych, bądź ich bezpośrednich przełożonych bez zwracania się o radę i decyzję do wyższego kierownictwa. Stąd termin autonomizacja - elementy organizacji uzyskują autonomię pozwalającą im podejmować działania podwyższające jakość bez konieczności czekania na decyzję wyższego kierownictwa.

Genialne. Głównie dlatego, że w ten sposób unika się powstawania wąskich gardeł decyzyjnych wyżej w strukturze firmy. Managerowie nie są zasypywani dużą ilością błahych i oczywistych spraw do rozwiązania, tylko mają czas myśleć nad rzeczami strategicznymi. A o jakość dbają ci, którzy są najbliżej czyli pracownicy.

Jak to się ma do rozwoju oprogramowania? Ano tak, że zgodnie z tą koncepcją każdy członek zespołu pracującego nad nowym oprogramowaniem miałby możliwość zatrzymania produkcji jeżeli tylko zobaczyłby, że nie spełnia ona jakościowych wymagań. Następnie miałby obowiązek znaleźć przyczynę wystąpienia tego odstępstwa oraz ją usunąć. Czyli na przykład jeżeli kodując funkcjonalność X przykładowy programista zorientuje się, że funkcjonalność Y nie działa zgodnie ze specyfikacją to ma obowiązek zatrzymać prace i zbadać dlaczego tak się stało. Może brakuje jakiegoś unit testu? To trzeba go dopisać, poprawić funkcjonalność Y i dopiero potem wrócić do pracy nad X. Oprócz unikania wąskich gardeł decyzyjnych ma to też taką oczywistą zaletę, że nie pozwala na zaniedbanie starszego kodu. Ma też tą wadę, że zakłada iż wymagania jakościowe są na tyle dobrze zdefiniowane, że każdy będzie w stanie wychwycić odchyłkę od normy. A to niestety często nie jest prawda. Niestety. Podkreślić tu bowiem należy, że niezależnie od przyjętej metody zarządzania projektem informatycznym te wymagania, które już weszły do produkcji muszą być na tyle dobrze zdefiniowane aby można było sprawdzić ich jakość. No ale to już temat na osobny post, który zresztą już chyba kiedyś się tutaj pojawił.

A jidoke zastosuję przy najbliższej nadarzającej się okazji :-)

Dług technologiczny

noreply@blogger.com (Szymon Włochowicz) — Thu, 05 Feb 2009 10:51:00 +0000

Koncepcja długu technologicznego jest stara jak agile a ostatnio natknąłem się na nią przy okazji robienia czegoś zupełnie innego. Co to jest dług technologiczny? Oto jak kiedyś mi to wytłumaczono: cokolwiek co czyni Twój produkt trudnym do zmiany w przyszłości jest długiem technologicznym - możesz albo zapłacić pełną cenę technologiczną teraz (zrobić od razu rozwiązanie elastyczne) albo zaciągnąć dług i spłacić go później (zrobić rozwiązanie szybkie ale nieelastyczne a przy pierwszej konieczności zmiany mieć trudność z brakiem elastyczności). Dług ma to do siebie, że generuje odsetki. To znaczy, że jeżeli dzisiaj nie poświęcimy dwóch dni na uczynienie naszego produktu elastycznym, to w przyszłości jeżeli będziemy chcieli przeprowadzić zmiany nie będzie kosztowało to dwa dni, tylko dwa dni plus odsetki. Odsetki te niestety przyrastają zdecydowanie szybciej niż w popularnych bankach. Efektem skrajnym jest kiedy produkt staje się tak niepodatny na zmiany, że prościej jest takowy produkt zrobić od nowa niż zmienić stary (sam byłem w takiej sytuacji).

W szczególności dług technologiczny dotyczy kodu oprogramowania. Tam jest bardzo łatwo zrobić rozwiązanie, które jest mało elastyczne ale bardzo szybkie we wdrożeniu (np. użycie nieudokumentowanych funkcji - kto z nas tego nie robił ;-)). Zdecydowanie trudniej jest napisać kod, który jest elastyczny. Co więcej często wprowadzenie zmiany sprawia, że kod staje się mniej elastyczny. Wówczas, aby nie zaciągać długu należy przeprowadzić refaktoryzację i zmienić kod tak, aby elastycznym był. Pominięcie refaktoryzacji spowoduje pogłębianie się długu, produkt będzie coraz trudniejszy do zmian. Prędzej czy później trzeba będzie za to zapłacić. Z tego punktu widzenia czas poświęcony na refaktoryzację to nie jest koszt. Jest to raczej inwestycja. Dzisiaj inwestujemy dwa dni pracy po to, aby w przyszłości nie musieć inwestować 5 dni w przeprowadzenie prostej zmiany.

Agile w sposób naturalny wspiera eliminację długu technologicznego. Poprzez iteracyjność oraz fakt, że nikt w zasadzie nie wie nad jakim kawałkiem produktu będzie pracował w przyszłej iteracji wspiera się aktywnie tworzenie rozwiązania bardzo elastycznego. W zespołach bardzo często tworzenie rozwiązań elastycznych jest przyjmowane jako jedna z głównych zasad pracy. Niestety nawet w przypadku takim jak ten, kiedy metodyka wspiera takie działania można cały ten efekt zepsuć. Najprościej dzięki mało kompetentnym kierownikom projektów, którzy nie pozwalają własnym zespołom na pracę dobrą a wymagają tylko pracy szybkiej. Jeżeli jesteście w takiej sytuacji to wytłumaczcie proszę zarządzającym koncepcję długu technologicznego i odsetek od niego. Moje ostatnie doświadczenia wskazują, że takie podejście skutkuje.

Obciążenie systemu

noreply@blogger.com (Szymon Włochowicz) — Sun, 25 Jan 2009 19:16:00 +0000

Ludzie instynktownie rozumieją, że jeżeli obciążymy serwer do 100% jego mocy spowoduje to nagły spadek wydajności, drastyczne zwiększenie czasu oczekiwania na odpowiedź oraz ogólnie rozumiany brak stabilności. Jednocześnie tak bardzo dziwią się jak Google może utrzymać krótki czas reakcji na zmiany na rynku, bardzo dużą wydajność pracy oraz stabilność, pozwalając swoim programistom na 20% pracy na rzecz zadań nie związanych z ich aktualnymi projektami.

Przecież to jest to samo. Tak jak serwer, aby utrzymać maksymalną wydajność i krótki czas odpowiedzi nie powinien być przeładowany pracą na więcej niż 80% tak samo pracownik, aby utrzymać maksymalną wydajność i krótki czas reakcji nie powinien być przeładowany powyżej 80% swojego czasu. Co ciekawe jeżeli obciążenie serwera zaczyna w zwykłej firmie oscylować w okolicach 80% to zwykle dyrektor działu IT natychmiast występuje z wnioskiem o zakup nowego serwera. Z drugiej strony jeżeli pracownik jest obciążony na 80% to w zwykłej firmie dyrektor (nawet ten sam) zwykle... dorzuci mu jeszcze jeden projekt. A potem bardzo się będzie dziwił, że czas oczekiwania na efekt gwałtownie rośnie a wydajność spada. Gdzie tu logika?

(temat zaczerpnięty z książki “Implementing Lean Software Development”)

Budowanie dla utrzymania

noreply@blogger.com (Szymon Włochowicz) — Mon, 12 Jan 2009 07:05:00 +0000

W nawiązaniu do tego, co kiedyś napisałem o wyzwaniach związanych z tworzeniem dokumentacji wdrożeniowej i utrzymaniowej oprogramowania napiszę jeszcze o jednym pokrewnym rozwiązaniu. W znanym tekście “The New New Product Development Game”* autorzy jako jeden z głównych powodów znaczącej poprawy efektywności producentów stosujących opisywane nowe metody tworzenia produktów podali korzystanie z zespołów wielofunkcyjnych. W szczególności w skład zespołów opracowujących nowe produkty wchodziły osoby z produkcji, czyli te, które później będą odpowiedzialne na wytworzenie w setkach tysięcy sztuk pomysłów inżynierów. Idea, która za tym stała była prosta i oczywista - często to, co jest optymalne z punktu widzenia inżyniera projektującego nowy produkt, wcale nie jest optymalne z punktu widzenia osoby, która ten produkt będzie musiała wykonać w tysiącach sztuk. Celem tworzenia takich zespołów miało być projektowanie takich nowych produktów, które nie tylko będą spełniały marzenia inżynierów (i marketingowców), ale jednocześnie będą proste w produkcji. Stąd zaangażowanie osób za nią odpowiedzialnych w rozwój produktu od samego początku projektu.

Przekładając to co zostało napisane na temat produkcji na rozwój oprogramowania wydaje się, że odpowiednikiem produkcji (wytwarzania) jest tutaj (wbrew pozorom) wdrożenie/utrzymanie. Sytuacja wygląda bowiem tak, że zespół rozwoju projektuje nowy system, który później trafia do zespołów wdrożeniowych i utrzymaniowych, które muszą zadbać o to, aby produkt działał bezbłędnie u każdego z klientów firmy. Podobnie jak produkcja w fabryce, tak wdrożeniowcy wytwarzają gotowe, działające u klient produkty firmy software’owej, oczywiście na bazie produktu stworzonego przez inżynierów odpowiedzialnych za rozwój.

Ciągnąc tą analogię dalej w niektórych projektach warte zainteresowania jest włączenie osób odpowiedzialnych za wdrożenia i utrzymanie (maintenance) do zespołów wytwarzających produkt, czyli zespołów rozwijających nowe oprogramowanie. Taka koncepcja wygląda na pierwszy rzut oka dość karkołomnie, ale im dłużej się nad tym zastanawiam tym większy ma sens. Wiadomo, że włączenie tych osób do zespołu spowoduje, że system będzie inaczej zaprojektowany. Zarówno te osoby, które muszą system zainstalować u klienta jak i te, które potem muszą odpowiadać na klienckie zapytania i/lub radzić sobie z błędami zgłaszanymi przez klienta będą miały mnóstwo pomysłów na usprawnia. Oczywiście jedną ze strategii jest je po prostu zbyć, ale... Ale tak naprawdę to one wystawiają swoją głowę klientowi na ścięcie i to od efektywności ich pracy zależy postrzeganie firmy przez organizację klienta. I nawet pomijając to jaki jest cel tej gry, to jak wiadomo każdemu z nas pensje tak naprawdę płaci... klient naszej firmy.

* Tekst znany jest głównie z tego, że w nim jako w pierwszym w literaturze pojawiło się określenie SCRUM na zespół pracujący zgodnie z metodami “lekkimi” - pojęcie agile jeszcze wtedy nie istniało. Sam artykuł ukazał się w Harvard Business Review, ale jak to kogoś interesuje to można go sobie wygooglać w formie PDFa. W tytule nie ma błędu.

Bardzo, bardzo dobra książka...

noreply@blogger.com (Szymon Włochowicz) — Sun, 04 Jan 2009 14:14:00 +0000

Implementing Lean Software Development - czytam i muszę powiedzieć, że jestem zaskoczony tym jak dobra jest ta książka. Stanowi ona zestaw prawd na temat zasad rządzących światem tworzenia oprogramowania. Zestaw ten poparty jest wieloma, naprawdę wieloma przykładami z doświadczenia własnego autorów.

Od dziś jest to dla mnie lektura obowiązkowa dla każdego menedżera zajmującego się rozwojem oprogramowania. Pewne koncepcje w niej zawarte na pewno przemyślę, przedyskutuję i podzielę się nimi na tym blogu.

Kosmiczne agilowe innowacje

noreply@blogger.com (Szymon Włochowicz) — Tue, 30 Dec 2008 20:24:00 +0000

W pierwszy dzień Świąt na TVN24 wyemitowano bardzo ciekawy reportaż dotyczący oryginalnego konceptu i historii przyznania X Prize. Dla niezorientowanych: nagrodę XPrize w wysokości USD 10 mln ufundował wówczas nieznany biznesmen a miała ona być przyznana pierwszej drużynie, której uda się skonstruować komercyjny statek kosmiczny, który w ciągu 2 tygodni dwukrotnie wyniesie na niską orbitę (100 km) dwie osoby. Miało to otworzyć drogę do kosmicznej turystyki. Nagrodę zdobył w 2004 roku zespół pod kierownictwem konstruktora Burta Rutana. Reportaż cały był arcyciekway, ja zwrócę uwagę na dwie rzeczy.

Jednym z zespołów startujących do XPrize, któremu nie udało się wtedy wygrać, był Armadillo Aerospace. Jego kierownik opowiadał o tym jak przygotowywali się do stworzenia pojazdu. Po pierwsze zespół składał się z ludzi o różnych zainteresowaniach i umiejętnościach, ale wspólnie stanowili całość, która była w stanie zaprojektować i zbudować pojazd. Po drugie pracowali i pracują głównie społecznie, bez znaczącego wsparcia finansowego, więc musieli wymyśleć jak najbardziej efektywny sposób pracy. Sposób ten polegał na tym, że co tydzień budowali prototyp, przeprowadzali próbę oraz następnie zbierali dane i wyciągali wnioski. W następnym tygodniu od nowa. Coś Wam to przypomina? I neich mi ktoś jeszcze raz powie, że agile to tylko software a i to nie każdy. Pewnym wytłumaczeniem skąd metody agile w projektowaniu pojazdów kosmicznych niech będzie fakt, że szefem firmy jest niejaki John Carmack- współtwórca Id Software (Wolfenstein, Doom, Quake, ...). Co ciekawe metody się sprawdzają. Zespół co prawda nie wygrał oryginalnej XPrize, ale za to dwa miesiące temu skasował nagrodę za tzw. poziom pierwszy Northrop Grumman Lunar Lander Challenge. I jako jedyny podszedł to poziomu drugiego, na razie niestety bez rezultatu (szczegóły w wideo na podanej stronie).

Moja druga obserwacja z całego tego reportażu jest natomiast zupełnie inna. Reportaż otworzył mi oczy na to jakie gospodarcze znaczenie miała X Prize. Powstało kilkadziesiąt firm, setki ludzi podjeło wyzwanie i stanęło do walki o nagrodę. Ilość wytworzonej w ten sposób wiedzy, innowacji i produktów naprawdę wysokiej technologii jest nie do przecenienia. Oczywiście były i sukcesy jak i porażki - parę firm zbankrutowało, parę innych bardzo słabo sobie radzi. Jednak patrząc się na całość nie mogę odeprzeć wrażenia, że skutki były więcej niż pozytywne. To wszystko zostało spowodowane przez sumę 10 mln dolarów amerykańskich, czyli mniej więcej 30 mln PLN. To tyle, ile mniej więcej kosztuje wyremontowanie 1 km ulicy w mieście. I znowu pojawia się u mnie to pytanie: dlaczego u nas tak nie można??? Czy nas naprawdę nie stać na te 30 mln, czy też chodzi o co innego? Za wskazówkę niech świadczy fakt, że w Google Lunar X Prize starują obok drużyn z USA taże Włosi, Niemcy, Duńczycy, Szwajcarowie, ale także... Malezyjczycy i ..... Rumuni. Polacy nie :-(

Wdrożenia nowych metod - zadanie domowe

noreply@blogger.com (Szymon Włochowicz) — Sun, 21 Dec 2008 19:51:00 +0000

W środowisku osób zajmujących się wdrożeniami systemów zarządzania projektami (chodzi tu o systemy rozumiane jako zestawy procesów a nie oprogramowanie) do rangi anegdoty kultowej urosło podobno prawdziwe zdanie, wypowiedziane przez jednego z konsultantów pod koniec długiego i kosztownego projektu wdrażania nowej metody zarządzania projektami w pewnej firmie (XXX - nazwa metody zarządzania projektami):

“Jak na dziś to wszyscy już rzygają tym naszym XXX, w związku z czym wdrożenie uważam za w pełni zakończone sukcesem!!!”

Hmm. Przypadek wręcz kliniczny, który przypomniał mi się w ramach kolejnej rundy rozważań nad pewnym nieudanym wdrożeniem metod agile. Pytanie brzmi następująco. Jeżeli wdrażamy coś (cokolwiek) nowego w organizacji i jako efekt dostajemy aktywne niezaangażowanie osób do których adresowane było wdrożenie tego czegoś, to o czym to świadczy? Hipoteza jest taka, że po prostu nie odrobiliśmy pracy domowej i wdrożyliśmy rzecz, która jest absolutnie niepotrzebna z punktu widzenia osób zaangażowanych lub mimo, że rzecz jest potrzebna, to sposób jej wdrożenia jest nieadekwatny. Przez rzecz niepotrzebna rozumiem nie pozwalająca jednostkom na osiąganie lepszych rezultatów. Rezultatów mierzonych w sposób taki w jaki się je mierzy dla każdego konkretnego człowieka w tej konkretnej organizacji. Innymi słowy, mówiąc kolokwialnie z wprowadzonej przez nas zmiany człowiek “nic nie będzie miał”.

Oczywiste pytanie to czy każdy musi z tego wdrażanego rozwiązania coś mieć. Jasne, że tak! Bo skoro organizacja jako całość ma na danej nowości zyskać, to dlaczego nie mieliby zyskać poszczególni uczestnicy tej organizacji? Wszyscy uczestnicy. Z jakiego powodu tak często zakładamy, że wdrożenie czegoś nowego musi być robione przeciw ludziom a nie z ludźmi? Czy naprawdę jeżeli wdrażamy coś nowego to musi być tak, że ktoś będzie "rzygał" tym rozwiązaniem? Moja hipoteza jest taka, że absolutnie nie. Jeżeli rozwiązanie jest dobre dla całości organizacji, to musi być sposób, aby skonstruować je tak, aby było dobre dla wszystkich osób w nią zaangażowanych (odwrotnie nie działa). Powtarzam wszystkich. Tylko trzeba ten sposób znaleźć, dokładnie analizując sytuację.

Przed wdrożeniem trzeba odrobić pracę domową i zobaczyć jak zmiany proponowane przez agile mogą pomóc wszystkim innym interesariuszom projektów w organizacji. Ta pomoc musi zwłaszcza być sprawdzona w odniesieniu do miar, którymi mierzona jest efektywność pracy poszczególnych kierowników. Chodzi o to, aby tak skonstruować system zarządzania, że wprowadzenie nowych reguł spowoduje z punktu widzenia poszczególnych jednostek zmiany pozytywne. Bo na przykład będzie łatwiej osiągać właściwe cele lub choćby prezentować wyniki. Jeżeli nie zadbamy o to, aby wszystkim ważnym interesariuszom było łatwiej to osiągniemy efekt podobny do wyrażonego w przytoczonym cytacie. I osoby aktywnie niezaangażowane we wdrożenie, powodujące realne zagrożenie jego powodzenia.

Stąd, jak już kiedyś pisałem, jednym z większych błędów jakie można zrobić przy wdrażaniu agile jest wdrożenie samych tylko procedur. Trzeba zmienić jeszcze także inne elementy organizacji. A to jak je zmienić i na jakie, tak aby spowodować z jednej strony akceptację, a z drugiej zakładany efekt biznesowy to już jest zadanie domowe dla tych, którzy agile wdrażać będą. I gwarantuję dwie rzeczy:

nie jest to proste
nie ma gotowych rozwiązań (porównaj).

Innowacyjność po polsku...

noreply@blogger.com (Szymon Włochowicz) — Fri, 19 Dec 2008 15:30:00 +0000

Niestety tym razem chodzi tylko o to, że przetłumaczona na język polski. Jakiś czas temu napisałem tu wpis "Dlaczego nie u nas?" na temat tworzenia w USA wysoce innowacyjnych projektów z budżetem ~50 USD.

Ostatnio dostałem od Radka informację (dziękuję), że opisana tam sesja z TED jest już dostępna z polskim tłumaczeniem. Razem z informacjami o innych ciekawych projektach umieszczona jest na mindblowing.pl: http://mindblowing.pl/?p=81

Innowacje organizacyjne

noreply@blogger.com (Szymon Włochowicz) — Fri, 12 Dec 2008 19:08:00 +0000

Na początek trochę teorii i rozważań "podstawowych".

Świat jest przez nas opisywany za pomocą pewnych reguł. Stałych i niezmiennych. Te reguły określają to w jaki sposób działa świat (np. masy się przyciągają). Na podstawie reguł, które naszym zdaniem opisują świat, tworzymy pewnego typu metody i procedury, które są niczym innym jak zastosowaniem tychże reguł do konkretnego środowiska (np. szklankę stawiamy na stole a nie obok stołu - bo spadnie, co wynika wprost ze wspomnianej wcześniej reguły).

Przy takim spojrzeniu na organizacje działające w świecie rzeczywistym możemy założyć, że są dwie metody wprowadzania innowacji w organizacji. Pierwszy to zmiana metod i procedur. Po prostu jak chcemy wprowadzić coś nowego to zaczynamy od tego, że zmieniamy sposób działania ze starego na nowy. Następnie sprawdzamy czy nowy sposób działa lepiej czy gorzej, oczywiście względem pewnego konkretnego wskaźnika, który powinniśmy wyznaczyć zanim cokolwiek zaczniemy zmieniać. Ten sposób nazywa się często z angielska learning-by-doing.

Jest też drugi sposób wprowadzania innowacji, który o ile dobrze kojarzę nazywa się learning-by-understanding. Ten sposób zakłada, że zanim zaczniemy zmieniać cokolwiek w metodach i procedurach powinniśmy przeanalizować reguły, które rządzą danym kawałkiem rzeczywistości. W tym zwłaszcza upewnić się, czy to co wydaje się nam regułą opisującą daną rzeczywistość na pewno nią jest. Można tu zastosować metodę naukową. Dopiero jak mamy wystarczająco dobre reguły, to na ich podstawie konstruujemy metody i procedury. Tak aby wypełniały te zidentyfikowane reguły w konkretnym środowisku.

Powyższe uwagi są uwagami ogólnymi, ale jak najbardziej stosują się do agile a tak konkretnie do wdrażania metod zwinnych w organizacjach. Wielkim błędem jest wdrażanie metod "bo tak wszyscy robią", czy z innych tego typu powodów. A tak niestety często się dzieje. Niestety. To jest typowe podejście zmiany procedur i metod oraz później modlenia się o rezultaty. Stosując nielubiane przez mnie porównania wojskowe jest to podobne do radzieckiego "rozpoznania bojem". Ze względu na historycznie przetestowany poziom strat własnych podejście jest bardzo niezalecane. Zalecane jest za to sprawdzenie jakie reguły obowiązują w danym wycinku rzeczywistości, w którym porusza się dana organizacja. Dopiero na tej podstawie można skonstruować zestaw metod i procedur, które wdrożone przyniosą dokładnie taki efekt jak spodziewany.

To, co opisałem powyżej jest jedną z przyczyn dla której nie słyszałem o udanym wdrożeniu metod zwinnych, które było przeprowadzone ściśle według książki. Po prostu książki opisują pewną wiedzę ogólną a każda z organizacji działa w trochę innym otoczeniu, więc zestaw praktyk i metod musi być inny (choć reguły mogą, ale nie muszą, być takie same). I stąd właśnie do wdrożenia metod zwinnych często firmy potrzebują pomocy z zewnątrz - aby ktoś bezstronny "obejrzał" daną organizację i pomógł zdefiniować właściwe działania.

User Acceptance Tests

noreply@blogger.com (Szymon Włochowicz) — Mon, 17 Nov 2008 17:06:00 +0000

Ostatnio prowadziłem szkolenie z agile, podczas którego padło bardzo logiczne pytanie: „a co z User Acceptance Tests (UAT – testy akceptacyjne)? kiedy je się wykonuje i jak zapewnia się, że podczas ich trwania ma się dostęp do grupy wykonawczej, aby ewentualnie naprawić zgłoszone przez użytkowników błędy?”. Pytanie jak najbardziej logiczne, dobre i odpowiedź powinna gdzieś być do znalezienia. Niestety po przeszukaniu dostępnej w mojej biblioteczce literatury okazało się, że odpowiedzi na to pytanie nie ma w posiadanej przeze mnie literaturze agile. Dlatego napiszę co ja na ten temat sądzę i jak ta sprawa była rozwiązywana w firmach, w których widziałem duże wdrożenia metod zwinnych. I przy okazji: jak ktoś gdzieś ma opis w literaturze takiego lub podobnego rozwiązania to bardzo proszę o podanie mi źródła.

„Problem” z User Acceptance Tests wynika z faktu, że według procesów agile grupa wykonawcza, pracująca nad projektem powinna cały czas w ramach iteracji dostarczać kolejne działające inkarnacje produktu. Tymczasem w tzw. świecie realnym, w którymś momencie przychodzi moment, kiedy taki działający produkt należy pokazać klientowi, który to klient powinien się zdecydować czy produkt spełnia jego wymagania czy nie. Ta właśnie procedura nazywa się testami akceptacyjnymi (UAT) i zwykle trwa jakiś czas- na pewno nie jeden czy nawet dwa dni. Co więcej z punktu widzenia firmy produkującej oprogramowanie jest to czas, który jest krytyczny. W trakcie testów akceptacyjnych musi być stały dostęp do zespołu, który wytworzył dany produkt aby bardzo szybko reagować na ewentualne błędy (pamiętajmy, że testuje to już klient – użytkownik ostateczny). Jak to więc zrobić, aby mieć dostęp do grupy wykonawczej w środowisku agile?

Ano bardzo prosto. Tylko trzeba się wznieść na „poziom wyżej”. Tak jak już kiedyś pisałem poziom iteracji i poziom wersji rządzi się trochę innymi prawami jeżeli chodzi o planowanie. Przypomnę tylko, że w ramach jednej wersji może być kilka iteracji. Wersja natomiast oznacza wersję produkcyjną, która zostaje zainstalowana u klienta ostatecznego w jego środowisku produkcyjnym. W ramach danej wersji następujące po sobie iteracje stanowią pewną całość i odbywają się jedna po drugiej, bez przerw. Nikt jednak nie powiedział, że tak samo musi być z wersjami. Często jest to w ten sposób rysowane w różnej literaturze (prace nad kolejną wersją rozpoczynają sie natychmiast po zakończeniu prac nad poprzednią), ale praktyka często weryfikuje takie podejście. W praktyce jest tak, że po zakończeniu pracy nad jedną wersja produkcyjną danego produktu następuje jej wypuszczenie i wdrożenie (deployment) w środowisku klienta. Natomiast prace nad kolejną wersją tego samego produktu zaczynają się zwykle z pewnym opóźnieniem (na przykład 2-4 tygodnie). W trakcie tego „opóźnienia” odbywają się dwie rzeczy. Po pierwsze klient przeprowadza UAT wersji, którą dostał. Jako, że w tym czasie nie ma prac rozwojowych nad wersją kolejną to w przypadku jakiejkolwiek awarii zespół wykonawczy jest w stanie bardzo szybko zareagować na ewentualne problemy. Jednak zespół wykonawczy nie przeznacza tego czasu tylko na bycie w gotowości. Oprócz tego, ten czas przeznaczany jest na przygotowanie do rozpoczęcia prac nad kolejną wersją. Zwykle oznacza to w praktyce przejrzenie z kierownikami produktu wszystkich funkcjonalności mających wejść w skład następnej wersji, nadanie im priorytetów oraz przeprowadzenie wstępnej estymacji. I nie jest to wbrew zasadom agile – wręcz przeciwnie, powtórzę po raz kolejny, że agile to nie chaos i kierownicy produktu powinni na początku prac nad wersją wiedzieć co chcą w jej ramach dostać. Zwłaszcza jeżeli chodzi o funkcjonalności o wysokich priorytetach, które wejdą do produkcji w pierwszych iteracjach pracy nad nową wersją.

Na koniec podsumowując w jednym zdaniu: praktyka wskazuje, że User Acceptance Tests w projektach agile przeprowadza się w „przerwie” pomiędzy pracą nad kolejnymi wersjami produktu.

Metoda Uwe K.

noreply@blogger.com (Szymon Włochowicz) — Sat, 01 Nov 2008 18:47:00 +0000

Jakiś czas temu pracowałem dla naszych sąsiadów zza Odry i Nysy Łużyckiej a moim szefem był niejaki Uwe K. Miał on bardzo ciekawą metodę zarządzania zadaniami. Otóż dzwonił codziennie o godzinie 16.15 do mnie, jako do swojego pracownika i przekazywał ustnie zadania do wykonania. Następnego dnia często dzwonił o godzinie 8.00 z pytaniem gdzie może obejrzeć rezultaty mojej pracy. Najwięcej zadań oczywiście było przekazywane w piątek o 16.15, tylko po to, aby oczekiwać, że będą zrealizowane do poniedziałku do 8.00. Bardzo ciekawa metoda zarządzania to była. Szczególnie w kontekście tego, że życie nie składa sie jedynie z pracy. Jak się zapewne domyślacie dość szybko zacząłem aktywnie działać w kierunku zwolnienia Uwe K. z funkcji mojego szefa...

Historia powyższa przypomniała mi się gdy rozmawiałem w zeszłym tygodniu z pewną osobą, której nie udało się wdrożenie zwinnych metod zarządzania w średniej wielkości polskiej firmie informatycznej. Teoretycznie firma była idealna do wdrożenia. Produkty cechujące się dużą niepewnością funkcjonalności, bardzo duża możliwość testowania niepełnego produktu przez klientów ostatecznych, projekty na tyle małe, że można je robić jednym zespołem, więc odpadają wszelkie typowe problemy ze skalowaniem metod zwinnych. Niestety wdrożenie zostało wyłożone. Co się stało? Zacznijmy od tego, że wdrożenie agile project management zostało umotywowany tym, że "firma zbyt wolno reaguje na potrzeby klienta". Celem było więc stworzenie systemu, który pozwoli szybko reagować na zgłaszaną przez klienta informację zwrotną o produktach firmy. O ile osoby zajmujące się programowaniem dość szybko zrozumiały o co chodzi w nowym systemie pracy, to zrozumienie metod zwinnych po stronie osób zarządzających produktem (product managerów) było cokolwiek powierzchowne. Doprowadzono do sytuacji, w której dano product managerom pełną dowolność zmian funkcjonalności produktu bez liczenia się z opinią kierowników projektów realizacyjnych. Bardzo szybko spowodowało to pojawienie się syndromu opisanego powyżej. Objawiało się to wpisywaniem przez menedżerów produktu na listę funkcjonalności niezdefiniowanych rzeczy podczas spotkań planujących iterację. Realizatorzy prosili o uszczegółowienie takich wymagań, co następowało zwykle na trzy dni przed końcem iteracji. Na innym poziomie było wrzucanie do ostatniej iteracji przed wypuszczeniem wersji zmian fundamentalnych, wymagających zmian w architekturze - oczywiście tłumaczone nagłą potrzebą klienta. A także inne kwiatki, których nie mogę opublikować. Jak się domyślacie oczekiwanie było, że na koniec każdej iteracji będzie dostępny działający produkt. A już wersja to koniecznie musiała być, bo przecież obiecana klientowi. Jakiekolwiek tłumaczenie od strony realizatorów, że taka praca jest nieoptymalna menedżerowie produktów kwitowali krótko: "no jak to, czy to znaczy, że nie jesteście wystarczająco agile?". Dość szybko ludzie z zespołów realizacyjnych zaczęli myśleć dokładnie to, co ja myślałem o moim szefie.

Nauka z tego taka, że zwinność zwinnością, ale i tak zawsze trzeba pamiętać, że istnieje gdzieś niepisana cienka linia, której przekroczenie spowoduje zabicie metody. Najpierw na poziomie elementarnego poziomu i trzymania się zasad. Chwilę potem na poziomie ludzkich relacji i chęci dalszej współpracy. Napiszę jeszcze raz to, co już tu wielokrotnie wprowadzałem: agile to wprowadzanie porządku w chaos. Agile to nie jest zarządzanie bez reguł.

I na koniec taka refleksja. Nie wiem dlaczego, ale zaczyna u mnie dominować przekonanie, że wdrożenia metod agile są najbardziej zagrożone nie od strony realizacji, ale od strony zarządzania produktem. Właśnie ze względu na błędne zrozumienie, że agile oznacza "wszystko nam wolno". A co ciekawe firmy praktycznie nigdy nie chcą aby im szkolić menedżerów produktów...

Zarządzanie innowacją - skąd się biorą pomysły?

noreply@blogger.com (Szymon Włochowicz) — Tue, 21 Oct 2008 08:08:00 +0000

Dzisiaj krótko, ale na temat bardzo interesujący. Wszyscy wokoło chcą teraz nagle zarządzać innowacjami. I fajnie. Niech się gospodarka rozwija nie tylko w oparciu o doskonałość operacyjną, ale także o nowe rozwiązania. Problem jaki widzę jest taki, że podejście do innowacji nawet w poważnych firmach jest dość mało poważne. Najlepiej widać to na przykładzie procesu zbierania pomysłów na nowe innowacje. Zwykle sprowadza się to do powołania jakiegoś "oficera innowacji", którego zadaniem jest zbieranie pomysłów od pracowników. Ta sama osoba odpowiedzialna jest za zorganizowanie mniej lub bardziej formalnej oceny przysyłanych pomysłów oraz późniejsze wdrażanie w życie tych, które ocenę przeszły pozytywnie. Czy to działa? Tak, i nawet są jakieś efekty - zwykle w postaci dziesiątek, jeżeli nie setek pomysłów od pracowników, które nigdy nie zostały wdrożone.

Przedstawione podejście, poza oczywistą taką zaletą, że działa, ma jeszcze dwie poważne wady. Po pierwsze nie ukierunkowuje pracowników na szukanie rozwiązań konkretnych problemów. Zgłaszane pomysły zwykle proponują usprawnianie wszystkiego po kolei zamiast tych rzeczy, które najbardziej bolą i uniemożliwiają rozwój. A takich rzeczy jest relatywnie mało. Według Teorii Ograniczeń zresztą tylko jedno. Ukierunkowanie całej kreatywności pracowników w jedno tylko miejsce będzie miało zdecydowanie lepszy rezultat niż zbieranie, czy jeszcze gorzej realizowanie, pomysłów na ślepo. Wyzwanie jakie tu się kryje to konieczność przeprowadzenia wnikliwej analizy przedsiębiorstwa przed wytyczeniem tematyki, w której miałyby nastąpić innowacje. A to jest trudne. Dużo trudniejsze od wyznaczenia "oficera innowacji".

Druga wada jest z zupełnie innego poziomu. Otóż chodzi w skrócie o to, że zbieranie pomysłów jest dużo bardziej efektywne nie na zasadzie "pomysły luzem", ale na zasadzie reakcji na konkretne wydarzenia. Na przykład takim wydarzeniem jest... nieoczekiwany sukces. Jeżeli organizacja odniosła sukces, który nie był spodziewany to należy się jak najszybciej zainteresować powodami, dla których ten sukces został osiągnięty. Ostatnio leci taka reklama z pralkami: firma sprzedaje dużo pralek w Indiach i pracownik jedzie na miejsce zobaczyć dlaczego, okazuje się, że Hindusi w tych pralkach mieszają soki. Teraz można oczywiście obśmiać Hindusów, jacy oni głupi, ale można też lekko zmienić projekt urządzenia i wprowadzić mieszarkę do soków. A następnie zarobić krocie. Cała sztuka polega na tym, żeby to było odpowiednio zapisane w procesach firmy. tak, aby tego rodzaju innowacje nie stanowiły szczęśliwego trafu, ale były efektem skodyfikowanego, powtarzalnego procesu.

Dokumentacja wdrożeniowa i administracyjna

noreply@blogger.com (Szymon Włochowicz) — Tue, 14 Oct 2008 10:56:00 +0000

Ostatnio pojawiło się bardzo dużo, bardzo ciekawej pracy. Stąd przerwy w pisaniu na blogu. Będę próbował się poprawiać :-)

Wracając do tematu, spotkałem się z bardzo ciekawym człowiekiem, który pisze pracę magisterską z dziedziny agile. Konkretne na temat dokumentacji w projektach realizowanych metodami zwinnymi. Ja już kiedyś swoje zdanie na ten temat wyraziłem (tutaj). W trakcie rozmowy wyniknął jednak jeden ciekawy problem.

Kto bowiem w zespole pracującym zgodnie z metodami zwinnymi jest odpowiedzialny za pisanie dokumentacji wdrożeniowej i administracyjnej? Na początek ustalmy pojęcia. Dokumentacja wdrożeniowa obejmuje opis procesu, który trzeba zastosować, aby system został uruchomiony w środowisku klienta i poprawnie funkcjonował z innymi systemami wcześniej tam obecnymi. Dokumentacja administracyjna obejmuje opis procedur, które muszą być stosowane przez osoby obsługujące systemy (bardzo często są to pracownicy naszego klienta) aby zapewnić utrzymanie systemu. Często dokumentacja administracyjna obejmuje też instrukcję radzenia sobie z najczęstszymi problemami.

W przypadku dokumentacji technicznej oraz dokumentacji użytkownika sprawa jest dość prosta. Odpowiadają za nią członkowie zespołu, którzy jednocześnie piszą kod bądź testują oprogramowanie. Z dokumentacją wdrożeniową, a już zwłaszcza administracyjną, jest jednak inaczej. Otóż w najczęściej spotykanych przypadkach jest tak, że osoby zajmujące się wdrożeniami systemu (czy też integracją systemów) nie są bezpośrednio członkami zespołów agilowych. Wynika to z faktu, że w większość znanych mi firm (nie mówię tu o sytuacji super-idealnej wziętej z książki któregoś z guru) osoby zajmujące się rozwojem produktu oraz osoby zajmujące się jego wdrożeniem i później ewentualnie administracją pracują w różnych działach, często nie mających ze sobą nic wspólnego. Dlatego w znanych mi zespołach nie było osób z kwalifikacjami potrzebnymi do napisania tego typu dokumentacji.

Jak więc sobie z tym poradzić? Długo się zastanawiałem i wymyśliłem dwa sposoby. Pierwszy jest „ortodoksyjny”. To znaczy zespół agilowy jest odpowiedzialny za stworzenie i tej dokumentacji. Przy czym oznacza to wprowadzenie do zespołu osoby, która się na tym zna. Oznacza to, niestety, że zespół się rozrośnie, bo tak jak to wspomniałem wcześniej rzadko zdarza się, żeby osoby pracujące nad rozwojem produktu miały wiedzę i umiejętności potrzebne do napisania takiej właśnie dokumentacji. Drugim rozwiązaniem, bardziej praktycznym, jest… odpuszczenie sobie tej dokumentacji na poziomie prac wykonywanych w poszczególnych iteracjach. Dokumentacja wdrożeniowa i administracyjna powinna pojawiać się wówczas jako element wypuszczanej wersji a nie produkt iteracji (o różnicach w planowaniu wersji i iteracji pisałem tutaj). Wówczas będzie działać to tak, że zanim wersja zostanie uznana za gotową do wypuszczenia do klientów jako warunek konieczny pojawi się „dostępna dokumentacja wdrożeniowa i administracyjna”. Pracę tą można wykonać na przykład podczas iteracji synchronizującej (tutaj). Ma to też sens patrząc się ze strony działów wdrożeń, których pracownicy będą się musieli uczyć zmian w systemie raz na wersję a nie raz na iterację. Z ich punktu widzenia to akurat bardzo duże ułatwienie.