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.

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.

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

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


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.

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

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

poniedziałek, 6 kwietnia 2009

Innowacja zarządcza

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.

czwartek, 26 marca 2009

Co się działo?

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

środa, 11 marca 2009

Organizacja a miary

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.

czwartek, 5 marca 2009

Dyspozytor vs. Delegujący

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.

czwartek, 19 lutego 2009

Przyczyna źródłowa

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

środa, 11 lutego 2009

Jidoka

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

czwartek, 5 lutego 2009

Dług technologiczny

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.

niedziela, 25 stycznia 2009

Obciążenie systemu

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

poniedziałek, 12 stycznia 2009

Budowanie dla utrzymania

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.

niedziela, 4 stycznia 2009

Bardzo, bardzo dobra książka...

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.