niedziela, 2 sierpnia 2015

Metodyka a cel projektu.

Marcin Żmigrodzki z Octigo napisał post nt podejścia do realizacji projektu w różnych metodykach. Łatwo się czyta, ale też daje dużo do myślenia. Pierwsza myśl: kierownik opisanego tam projektu sztafety nie potrafi dobrać metodyki zarządzania do problemu, który przed nim stoi. Próba używania narzędzi w innym celu, niż zostały stworzone jest oczywiście możliwa, ale po co? Co oczywiście prowadzi do pytania: do jakich celów projektowych nadają się poszczególne metodyki? Jakim celom biznesowym najlepiej odpowiadają poszczególne metodyki? Poniżej kilka uwag, razem z obserwacją na koniec. Czy naprawdę czegoś nam brakuje?

Podejście kaskadowe
W metody tradycyjne skupiają się na tym, aby dostarczyć określony zakres w określonym czasie przy wykorzystaniu określonych zasobów. W przypadku biegu sztafetowego przekłada się to na postawienie celu "4 biegaczy ma przebiec 3000 metrów w 3 minuty". Nie ma co się rozpisywać, może poza stwierdzeniem, że żaden plan nie wygrywa starcia z rzeczywistością.

Agile
Jak to słusznie zauważył Marcin w swoim pierwszym poście, szeroko rozumiane metody agile a w tym SCRUM są metodami, w których zakres projektu nie sztywno określony. Innymi słowy w metodach agile mamy przy wykorzystaniu określonych zasobów, w określonym czasie dostarczyć zakres możliwie najlepiej realizujący cel projektu. Przekładając to na bieg oznaczałoby to postawienie celu "4 biegaczy ma w ciągu 3 minut dobiec jak najdalej".

Przy takim postawieniu celu metody agile nagle mają potężny sens. Jeżeli mam w 3 minuty dobiec jak najdalej to naturalnym sposobem postępowania jest patrzenie co 30 sekund gdzie jestem i zastanawianie się co zrobić, aby w kolejnych 30 sekundach przebiec dystans większy niż w poprzednich. Sensowne staje się też pytanie o to w którą w ogóle stronę biegniemy. Jeżeli celem jest tylko dobiec jak najdalej to jeżeli droga w prawo jest pod górkę a w lewo z górki to po co biec w prawo?

Może się jeszcze zdarzyć, że metody agile są używane w środowisku niepewności technologicznej. Wówczas cel byłby zdefiniowany w stylu "4 biegaczy ma w ciągu 3 minut znaleźć się jak najbliżej mety, przy czym nigdzie w okolicy nie widać toru biegowego". W takiej sytuacji zakładamy, że nie znamy drogi pomiędzy startem a metą (nie znamy technologicznego sposobu realizacji projektu). Wówczas równiej jak najbardziej sensowne jest podejście, w którym co 30 sekund stajemy, patrzymy się wokoło i wybieramy drogę, która w ciągu następnych 30 sekund doprowadzi nas najbliżej rzeczonego markera.

Łańcuch krytyczny
Metoda łańcucha krytycznego została stworzona aby zapewnić realizację projektu na czas i/lub w czasie możliwie najkrótszym. "Stosowanie metody łańcucha krytycznego ma sens tylko i wyłącznie kiedy istnieje realna korzyść biznesowa ze skrócenia czasu realizacji projektu" (cytat za Marek Kowalczyk). Czyli metodę łańcucha krytycznego stosujemy tam, gdzie mamy określony zakres, określone zasoby i potrzebujemy dostarczyć projekt jak najszybciej. Przekładając to na bieg sztafetowy "4 biegaczy ma przebiec 3000 metrów jak najszybciej".

Kontrola realizacji projektu w metodzie łańcucha krytycznego oparta o analizę bufora w tym wypadku też rewelacyjnie się sprawdzi. Jeżeli mamy jakikolwiek bieg czy wyścig to naturalnym jest, ze co pewien czas sprawdzamy jak nam idzie w porównaniu do innych w stawce. Jeżeli jesteśmy X sekund/minut z przodu - bufor zielony, jest ok. Jeżeli jesteśmy mniej więcej tak samo jak pierwszy poza nami to strefa żółta - tragedii nie ma, ale trzeba mieć plan co z tym zrobić. Jak do najlepszego brakuje nam X sekund/minut - strefa czerwona, sprężamy się.

Jeżeli akurat nie są to zawody tylko trening to nie porównujemy czasu z przeciwnikiem tylko z ustalonym przez nas celem. Który ma być agresywny (bo inaczej to nie jest wyzwanie). Przy czym agresywny wcale nie oznacza 50% estymacji wykonawcy. Agresywny oznacza po prostu agresywny. Na pewnym poziomie urwanie 1 sekundy to już bardzo agresywne podejście :)

Dygresja czyli metodyka XXX
Do napisania tego postu skłoniło mnie to, że po przemyśleniu tego co napisałem powyżej rzuciło się w oczy, że czegoś tu brakuje. Mamy w zarządzaniu projektami klasyczny trójkąt: zakres, czas, zasoby (plus czasami dodawana jakość). Patrząc się na powyżej opisane metodyki mamy metodykę skupiającą się na próbie wypełnienia wszystkich trzech parametrów (kaskadowa). Mamy metodykę skupiającą się na optymalizacji (maksymalizacji) zakresu przy stałym czasie i zasobach (agile). Mamy metodykę skupiającą się na optymalizacji (minimalizacji) czasu przy stałym zakresie i zasobach (łańcuch krytyczny). A co z metodą, która przy stałym zakresie i czasie zoptymalizuje nam zasoby? Innymi słowy: chcę jak najtaniej dostać dany zakres w danym czasie? Na usta cisną się metodyki Lean. Problem tylko w tym, że one nadają się bardziej do powtarzalnych procesów produkcyjnych a nie konkretnego, innowacyjnego projektu. Czeka nas za jakiś czas moda na kolejną,  nową super-metodykę optymalizującą zasoby?



poniedziałek, 12 listopada 2012

Efekt Guru


Efekt Guru

Nie pamiętam kto mi o tym powiedział i skąd pochodzi poniższa definicja, ale na początek chciałbym temu zapomnianemu przyjacielowi serdecznie podziękować za wprowadzenie do słownika nowego pojęcia. Czy jest Efekt Guru? Jest to sytuacja w organizacji, w której ludzie zamiast samemu pracować nad rozwiązaniem problemu wolą spytać się tego, kto wie (Guru). W praktyce polega to na tym, że ludzie w organizacji pracują normalnie do czasu napotkania problemu. Jak tylko taki się pojawi przerywają prace i kontaktują się z Guru w celu znalezienia rozwiązania tego problemu. Po kontakcie czekają na reakcję Guru i gotowe rozwiązanie, zwykle nie podejmując żadnych działań, bo przecież problem już jest rozwiązywany.

To jest bardzo niebezpieczny efekt i powinno się mu aktywnie przeciwdziałać.

Zacznijmy od oczywistości, czyli dlaczego taki efekt jest niebezpieczny. Z punktu widzenia kierownika projektu pierwszym i jednym z najważniejszych negatywnych efektów jest to, że prace dramatycznie się opóźniają. Wynika to z tego, że napotkane problemy rozwiązywane są tylko przez jednego człowieka. Spływają do niego wszystkie, co sprawia że często Guru ma tych problemów na głowie kilka albo kilkanaście. Oczywiście nie może się nimi wszystkimi jednocześnie zająć, więc tworzy się kolejka zadań do rozwiązania. Mówiąc językiem Teorii Ograniczeń pojawia się w systemie wąskie gardło i to co najgorsze w miejscu, którego nie widać na żadnym schemacie organizacyjnym. Głównie dlatego, że Efekt Guru jest elementem kultury pracy a nie systemu zarządzania. Zarządzanie takim "niewidocznym" ograniczeniem jest bardzo trudne/niemożliwe. Natomiast cały ten problem zarządczy wcale nie jest najgorszym skutkiem Efektu Guru. Dużo gorszy jest brak rozwoju w zespole. Jeżeli kultura pracy jest taka, że członkowie zespołu zamiast myśleć pytają i czekają na odpowiedź, to niestety ale zespół zaczyna rozwijać się bardzo nierównomiernie. Podczas gdy większość zespołu się nie rozwija (tylko czeka na rozwiązanie ich problemów) jedna osoba rozwija się niewspółmiernie szybko - właśnie dlatego, że rozwiązuje coraz więcej różnego typu problemów. Oczywiście można teraz by długo pisać na temat tego jaki zły wpływ to ma na zespół i organizację, ale pozwólcie, że cay ten wywód ograniczę do idealnie go obrazującego sparafrazowania pytania mojego kolegi: "A co się stanie z organizacją, jeżeli Guru jutro wpadnie pod tramwaj?". Czego oczywiście nikomu nie życzę.

Skąd się bierze Efekt Guru? Wbrew pozorom wcale nie z lenistwa ludzi. Wręcz przeciwnie :) W życiu dwa razy miałem okazję obserwować tworzenie się kultury Guru w zespole. W obu przypadkach wynikało to z bardzo dobrych chęci zaangażowanych osób. Zaczyna się od tego, że chcemy projekt zrobić szybko i "nie mamy czasu". Wówczas kiedy pojawią się problemy to zaczynamy szukać najszybszego sposobu rozwiązania tych problemów. Jaki jest najszybszy sposób? Dać je do rozwiązania najlepszemu człowiekowi z zespołu. No to je dajemy, a reszta w tym czasie robi te rzeczy, z którymi problemów nie ma. Efekt jest taki, że ta jedna osoba staje się coraz lepsza i ma coraz większe doświadczenie. Jeżeli pojawią się kolejne problemy i dalej mamy tą samą presję czasową to co zrobimy? Czy znów damy te problemy do rozwiązania najlepszemu z zespołu? Jeżeli tak, to jesteśmy na najlepszej drodze do stworzenia Efektu Guru. Tu by się musiał wypowiedzieć ktoś znający dogłębnie psychologię zespołu jak to dokładnie się rozwija, ale z doświadczenia po kilku lub kilkunastu tygodniach tego typu akcji zespół przechodzi automatycznie w tryb "problemy dajemy do Guru". I efekt mamy gotowy.

Jak przeciwdziałać Efektowi Guru? Metodyki agile mają kilka ciekawych propozycji, choć i tak wszystko koniec końców sprowadza się do zasad i kultury pracy danego zespołu. Dwa elementy, które osobiście widziałem w akcji, sprawdzały się dla konkretnych projektów w których pracowałem. Oczywiście wcale nie oznacza to, że będą sprawdzały się w każdej sytuacji. Pierwszym elementem utrudniającym powstawanie Efektu Guru jest nie-przydzielanie zadań do poszczególnych osób podczas planowania. Czyli postępowanie ściśle z wymaganiami metody agile. Warto natomiast dołożyć do tego aktywne sprawdzanie przez zespół i kierowników, czy ludzie nie mają tendencji do brania zadań tylko tych, które wydają się dla nich proste, czyli takich na których się znają. Ten sposób jest skuteczny, natomiast widziałem już wiele sytuacji, w których nie dało się go w prosty sposób wdrożyć. Drugi sposób, to oddziaływanie na kulturę pracy poprzez ustalenie konkretnych zasad. Kiedyś pracowałem w zespole, w którym ustaliliśmy standardowy sposób postępowania w momencie, kiedy ktoś napotykał na problem. Polegało to na tym, że jeżeli ktoś napotkał na problem to najpierw miał spróbować rozwiązać go samemu. Jeżeli po 15 minutach pracowania nad problemem pozostawał on nierozwiązany, osoba na głos mówiła wszystkim w zespole, że napotkała problem i jakiego on jest rodzaju (siedzieliśmy całym zespołem w jednym pokoju). Potem następowała wymiana zdań, której celem było ustalenie kto będzie najbardziej pomocny w rozwiązaniu tego konkretnego problemu. Ta osoba siadała ze zgłaszającym problem i we dwójkę (ale tylko we dwójkę) siedzieli nad problemem dopóki go nie rozwiązali. Dział ten sposób bardzo dobrze, bo z jednej strony zmuszał do własnego wysiłku (te 15 minut), z drugiej strony powodował uczenie się (przez tą drugą osobę), z trzeciej nie powodował zbyt dużego rozwalenia prac w zespole (tylko dwie osoby zaangażowane).

Na koniec zachęcam do przyjrzenia się samemu sobie i dokonania analizy, czy przez przypadek nie generujemy Efektu Guru w swoim zespole. Zupełnie nieświadomie oczywiście. A może to Ty sam jesteś Guru?

niedziela, 2 września 2012

O tym co robić, kiedy nie ma nic do roboty

Załóżmy, że jesteś Product Ownerem. Twój zespół realizuje projekt, który jeszcze chwilę mu zajmie. Oczywiście cały czas na bieżąco wspierasz zespół i przyglądasz się pracy, ale osiągnęliście już takie zrozumienie, że zajmuje Ci to nie więcej niż 30% Twojego czasu. Co robić z resztą?

Odpowiedź jest w zasadzie prosta: przygotowywać się do następnego projektu. Przecież on nadejdzie. I to zwykle szybciej niż się wszyscy spodziewają. To jest oczywiste i większość product ownerów to robi. Co jednak, jeżeli jest już stworzona lista historii użytkownika? Czy można sobie odpuścić? Moim zdaniem nie. Co więc robić? Na początek dwie odpowiedzi ogólne.

Pierwszym obszarem, którym powinien zająć się product owner jest odpowiednie zarządzenie ryzykiem projektu. Jeżeli projektu jeszcze nie ma a wiadomo już o czym będzie to warto zrobić sobie porządną analizę ryzyka, zdecydować jakie będzie podejście w ramach projektu do poszczególnych ryzyk i zacząć wprowadzać w życie elementy strategii zarządzania poszczególnymi ryzykami. Może się okazać, że do projektu dojdzie cała masa zadań, które trzeba zrobić nie dlatego, że stanowią jego zasadniczą treść, ale dlatego że będą efektem przyjętej strategii zarządzania ryzykiem. Aha, oczywiście ponieważ rozmawiamy tu o product ownerze, to ryzyka te będą ryzykami biznesowymi i takie też będą działania na nie odpowiadające. Przykład? Może w ramach projektu trzeba bardzo wcześnie zrobić release do klienta? Może trzeba zrobić MVP? Może trzeba zarządzić kwestią wydajności rozwiązania? Itp.

Drugą odpowiedzią ogólną jest pojęcie wzięte z teorii ograniczeń i nazywające się "full kitting". Na polskie nie mam pojęcia jak się tłumaczy. Generalnie koncepcja polega na tym, aby zapewnić osobom zajmującym się daną czynnością absolutnie wszystkiego, co jest im potrzebne do wykonania tej czynności zanim zaczną się prace. Chodzi o to, aby sama czynność została wykonana bez przestojów spowodowanych brakami. Czyli czas pracy był maksymalnie efektywnie wykorzystany. W teorii ograniczeń o full kittingu mówi się zwykle w kontekście zadania w projekcie, jednak samą koncepcję można przenieść o jeden logiczny poziom wyżej i przyłożyć do całego projektu. Chodzi o to, aby zespół mógł od pierwszego dnia spędzać czas w projekcie w pełni efektywnie. Przykłady? Czy w ramach projektu będzie potrzeby dostęp do jakichś systemów? Czy są jakieś dane biznesowe/marketingowe/operacyjne, które dane zespołowi spowodowałyby szybsze i sprawniejsze prace?

Jeżeli zaś chodzi o szczegóły to poniżej kilka czynności, które mi szczególnie utkwiły w pamięci, a które wykonywałem w "czasie wolnym" kiedy aktualny projekt nabrał już rozpędu a do następnego było całkiem dużo czasu:

  • rozmowy z architekatmi - generalnie jeżeli pisałem user stories zawsze starałem się pokazać je architektom zanim zobaczył ją zespół. Dlaczego? Żeby się upewnić o ich technicznej wykonalności. Architekci też, to zwykle bardzo inteligentni ludzie z zupełnie inną perspektywą spojrzenia na projekt i produkt. Warto ich posłuchać. Jak nie ma architektów to zawsze warto się zwrócić do senior programistów czy kogokolwiek technicznego, kto rozumie stronę biznesową.
  • doszczegóławianie user stories - tak, to nie zawsze jest zgodnie z duchem metod agile, ale z praktyki wynika, że doszczegóławianie user stories często pomaga. Jeżeli na etapie przed projektem wyjdzie, ze user stories są niejasne albo zbyt ogólne, to nie ma co się łudzić - jak projekt ruszy i tak trzeba będzie to doszczegółowić. Po co czekać? Jeżeli jest czas można to zrobić wcześniej.
  • projekty graficzne - doświadczenie wskazuje, że jeden obraz jest wart więcej niż tysiąc słów. Generalnie pokazanie rozwiązania na projekcie graficznym (albo nawet na wystarczająco szczegółowej makiecie) powoduje, że product owner musi sobie przemyśleć dużo więcej rzeczy niż jak tylko stosuje opis słowny. Po drugie natomiast wprowadzenie dodatkowego projektu powoduje, że osoby, które będą wykonywały projekt mogą zobaczyć wizję w postaci obrazka. I bardzo często zgłosić trafne uwagi na temat wykonalności tej wizji.
  • zapewnienie dostępów - tzw. krótka piłka: jeżeli potrzebny jest do czegoś dostęp, to trzeba go załatwić i tyle. Im większa organizacja tym trwa to dłużej. Choć są wyjątki potwierdzające tę regułę. Wyjątki w obie strony.
  • zapewnienie zasobów współdzielonych - jeżeli będą potrzebne jakieś zasoby, czy to ludzie czy sprzęt, które nie są normalnie "na stanie" zespołu to trzeba się odpowiednio wcześniej zatroszczyć, aby były dostępne. I potem odpowiednio często się dopytywać i potwierdzać, czy to aby na pewno jest zagwarantowane. To typowa część "full kittingu" przedprojektowego...

Na koniec jeszcze jedna sprawa. Jeżeli zespół pracuje teraz nad projektem n, to szczegółowe przygotowania warto prowadzić tylko dla projektu n+1. Projekty n+2, n+3 i kolejne, mogą być opisane i przygotowane na dużym stopniu ogólności. Nie ma sensu zajmować się nimi w szczegółach. Dlaczego? Ano dlatego, że do ich rozpoczęcia jest jeszcze dużo czasu. I w tym czasie mogą pojawić się zmiany, które wymuszą kolejne, dokładne planowanie. Tak więc szczegółowe przygotowania dzisiaj mogłyby się obrócić w czysty przypadek waste, czyli straty. Czerpiąc znów z teorii ograniczeń można powiedzieć, że do projektów powinno się szczegółowo przygotowywać tak późno jak to jest możliwe, ale nigdy nie później.

niedziela, 22 lipca 2012

Agile w produkcji iPhone'a(?)

Z obserwacji wynika, że mało osób wie o tym, że ruch agile zaczął się w... środowisku produkcyjnym. Pierwszym artykułem opisującym jak "agilowo" zarządzać projektami jest artykuł opublikowany w styczniu 1986 roku w Harvard Business Review. Autorami są Hirotaka Takeuchi i Ikujiro Nonaka a artykuł jest zatytułowany "The New New Product Development Game" (nie podaję linku, bo mam wątpliwości co do legalności jego przedruków - zainteresowanym polecam samodzielne wyszukanie).

W tym artykule - przypominam z roku 1986 - autorzy opisują nowe procesy zarządzania projektami rozwoju produktów. Generalna idea jest taka, aby odejść od wcześniej stosowanego modelu liniowego. Model liniowy ten zakładał, że nad produktem pracują sekwencyjnie działy marketingowy, projektowy, produkcja i serwis. Tymczasem autorzy opisują bardziej "holistyczne" podejście do tematu, które zakłada że nad produktem pracują przedstawiciele wszystkich specjalności jednocześnie, poszczególne fazy się nakładają a członkowie zespołu "niczym zespół rugby podają piłkę między sobą jednocześnie jako zespół przesuwając się ku końcu boiska". W tym właśnie artykule jako opis tego procesu po raz pierwszy pojawia się określenie SCRUM.

Czemu o tym piszę? Otóż 26 lat później, wczoraj, udało mi się trafić na notkę How Apple Creates Such Great Products w Business Insider, w której czytamy (w wolnym tłumaczeniu):
Apple nazywa to równoległą produkcją. Wszystkie grupy - projektanci, produkcja, inżynierowie, sprzedaż - spotykają się nieustannie przez cały cykl rozwoju produktu, wspólnie rozmyślając, wymieniając się pomysłami i rozwiązaniami, ustalając strategie dotyczące kluczowych zagadnień i ogólnie utrzymując otwartą komunikację ze wszystkimi zainteresowanymi grupami - pozwala to uniknąć typowego problemu pomijania spłycania dobrych pomysłów, w miarę jak przechodzą one przez proces rozwoju produktu.
Czyli dalej działa :) Apple stosuje procesy agilowe opisane ponad 20 lat temu. Co tylko oznacza, że tam gdzie mamy do czynienia z innowacyjnym produktem agile może być stosowany - nawet jeżeli produkt to nie jest sam software. Oczywiście techniki i narzędzia są zapewne inne, ale zasady pozostają te same niezależnie czy mówimy o rozwoju hardware, software czy biznesu.

poniedziałek, 9 lipca 2012

Dopasowanie organizacyjne

W poprzednim wpisie wypisałem 6 mitów według artykułu z Harvard Business Review. Jednym z tych mitów było "Im więcej funkcjonalności będziemy mieli w produkcie, tym więcej klientów będzie go chciało". Oczywiście w sposób kluczowy odnosi się to do starej prawdy o tym, że w innowacjach nie chodzi o to, aby dodawać jak najwięcej funkcjonlaności tylko aby wyrzucić wszystko, oprócz rzeczy absolutnie niezbędnych ((C) Steve Jobs). Omawiając to zjawisko można dużo pisać o podejściach, teoriach, Lean Startup, MVP, itp. Ja natomiast chciałbym się odnieść do realiów życia i przypadku kiedy mit powyższy był podtrzymywany głównie dzięki... strukturze organizacyjnej firmy.


Wyobraźmy sobie firmę, która jest idealnym kandydatem do wprowadzenia metod opartych o Lean czy też Agile. Firma produkuje głównie produkt wirtualny, na rynku liczy się najbardziej time-to-market. Produktem w firmie zarządzają kierownicy produktu - osoby odpowiedzialne za wymyślenie i wprowadzenie do oferty nowego produktu bądź też zmianę istniejącego. Produkt jest mierzony dzięki zestawowi obiektywnych wskaźników. Ze względu na bardzo dużą bazę użytkowników/klientów firma teoretycznie może dowolnie prowadzić eksperymenty produktowe na wybranych grupach. W takim przypadku najsensowniejsze z punktu widzenia zarządzania produktem byłoby oprzeć się o jakieś połączenie iteracyjnego procesu z testami i strategicznym zarządzaniem produktem (właśnie proces Lean Startup, MVP, wsparte przy wytwórstwie metodykami agile). 


Niestety jest jedno "ale". Firma, chcąc oczywiście być bardzo nowoczesną, działa w całości w strukturze projektowej. Czyli zespoły są powoływane do zrealizowania konkretnego projektu, natomiast po projekcie są rozwiązywane. W praktyce wygląda to tak, że kierownicy produktu za każdym razem, kiedy mają pomysł na zmianę produktu lub wprowadzenie nowego zanim jeszcze zaczną implementację, muszą zrobić dwie rzeczy. Najpierw przekonać "komitet produktowy" do danego pomysłu i dostać zielone światło. Jak już ten krok zostanie wykonany, muszą (posługując się mandatem danym przez komitet produktowy) poczekać na "uwolnienie zasobów" i sformowanie grupy projektowej posiadającej umiejętności pozwalające na przeprowadzenie projektu. To oczywiście trwa, bo zwykle wszyscy specjaliści są zaangażowani w jakieś projekty i na własną kolejkę trzeba czekać. Projekty są wpuszczane do realizacji biorąc pod uwagę ich "ważność". Grupa jak już wspomniałem powoływana jest tylko do realizacji danego projektu i zaraz potem jest rozwiązywana.


Jakie to ma konsekwencje dla działania kierowników produktu? Na logikę powinni oni tworzyć małe, inkrementacyjne zmiany produktowe, testować je na małej ilości klientów i dopiero po uzyskaniu odpowiednich rezultatów wdrażać je wszystkim. Co zaś się dzieje? Ponieważ grupa projektowa jest powoływana tylko na czas danego projektu i zaraz potem rozwiązywana, naturalną tendencją kierownika projektu jest stworzenie zakresu... jak największego. Dlaczego? Ano dlatego, że dany kierownik projektu nie ma pewności kiedy będzie miał kolejną szansę rozwinąć dany projekt. Więc w naturalny sposób dąży do  tego, żeby jak już dostanie możliwość realizacji zrealizować możliwie jak najwięcej. Po drugie na logikę powinno się nowe produkty uruchamiać na małej próbce klientów i testować. W tym konkretnym przypadku co by się stało, jeżeli którykolwiek z kierowników produktu przyznałby się do tego, że będzie uruchamiał produkt tylko dla 5% wszystkich klientów (a dla reszty tylko jeżeli wyniki będą zadowalające)? Otóż taki projekt zostały potraktowany jako mało "ważny" - na pewno ważniejsze wydają się te, które są tworzone od razu dla wszystkich klientów. Jak się można domyśleć projekt jest też tym ważniejszy im jest większy. Opis konsekwencji takiego działania pominę - każdy niech sobie wyobrazi a potem przyjmie do wiadomości, że w firmie mogło być jeszcze gorzej.


Morał z tej historii jest taki, że nie wystarczy znać teorii i wdrażać jednego procesu. Czasami takie rzeczy jak kultura czy w tym wypadku organizacja firmy mogą działać przeciw zdrowym praktykom. Ludzie dość szybko przystosowują się do dziwnych systemów i działają w nich nawet jeżeli nie ma to sensu. Dlatego też jeżeli chcesz zaimplementować nawet najlepszą i najbardziej oczywistą zmianę działania, najpierw sprawdź czy system, w którym ta zmiana ma być wprowadzona, jest gotowy na nią i wspiera ludzi w implementacji tejże zmiany.

czwartek, 28 czerwca 2012

Bo nie jednej inicjatywie na imię Projekt...

Witam po przerwie. Na początek rzecz o projektach jako takich. W maju amerykański Harvard Business Review (HBR) opublikował rewelacyjny artykuł pt. "Six Myths of Product Development". Można go sobie przeczytać w całości tutaj (po darmowej rejestracji). Bardzo zachęcam.

Co w tym artykule jest takiego rewelacyjnego? Otóż autorzy zauważyli prawdę oczywistą, ale dość często pomijaną w dyskusjach o zarządzaniu projektami. Otóż "projekt" w dzisiejszej rzeczywistości może oznaczać inicjatywy skrajnie różne. Od wybudowania 1423. domku w stylu kanadyjskim do wymyślenia i wprowadzenia na rynek Google Glass. W związku z tym metody zarządzania tymi inicjatywami powinny różnić się od siebie! Na dzień dzisiejszy nie istnieje jedna, uniwersalna nauka o Zarządzaniu Projektami, bo Projekty nie są ani jedne ani uniwersalne. We wspomnianym artykule w HBR autorzy zastanawiają się akurat nad projektami rozwoju nowych produktów, które ze względu na zainteresowania zawodowe są mi szczególnie bliskie. I pokazują, które z "mitów" dotyczących zarządzania projektami w rzeczywistości są przeciwskuteczne w tym konkretnym środowisku. Warto podkreślić właśnie sprawę środowiska, bo te same "mity" (zasady, przekonania) w zupełnie innym środowisku dają dobre rezultaty.

Te sześć przeciwskutecznych mitów/zasad/przekonań, o których piszą autorzy to:

  1. Wysokie wykorzystanie zasobów polepsza efektywność
  2. Pracowanie na dużych kawałkach "wsadu" (batches) poprawia efektywność procesu
  3. Nasz plan jest wspaniały, musimy się tylko niego trzymać
  4. Im szybciej rozpoczniemy projekt, tym szybciej go skończymy
  5. Im więcej funkcjonalności będziemy mieli w produkcie, tym więcej klientów będzie go chciało
  6. Odniesiemy większy sukces, jeżeli uda się nam za pierwszym razem
Po szczegóły odsyłam do wspomnianego artykułu. Już po samych tytułach widać, że autorzy czerpali garściami z TOC, Lean i Agile. Natomiast najwięcej czerpali z własnego doświadczenia - ponad 50 lat doradzania firmom rozwijającym produkty. Na bazie tych doświadczeń okazuje się, że powyższe mity są szczególnie szkodliwe właśnie dla rozwoju nowych produktów.

Jednocześnie jeszcze raz warto podkreślić, że w środowiskach innych niż rozwój produktu, te mity/zasady mogą być prawdziwe. Dla przykładu jeżeli budujemy most to wolałbym, żeby nikt nie kwestionował mitu/zasady nr 6. Most musi działać poprawnie za pierwszym razem i odniesiony sukces musi być niekwestionowalny. 

To wszystko oznacza tylko, że dzisiejszy Kierownik Projektów musi orientować się nie tylko w konkretnym narzędziu, ale także w tym do czego dane narzędzie należy zastosować. A także powinien znać kilka innych narzędzi razem z ich potencjalnymi zastosowaniami. Przywołując mój ulubiony przykład. Jeżeli macie problem z samochodem i pojechalibyście do mechanika, który w swojej szafce z narzędziami ma tylko młotek, i twierdzi, że ten młotek naprawi każdą usterkę w Waszym samochodzie, to co pomyślelibyście o takim mechaniku? Dokładnie to samo powinni pomyśleć menedżerowie, do których zgłaszają się kierownicy projektów, znający jedną metodę/sposób zarządzania i twierdzący, że rozwiąże on wszystkie problemy. Tak się stało, że problem zarządzania projektem w obecnym świecie wyszedł ze stadium bryczki i coraz częściej przypomina napakowany elektroniką samochód. I dlatego do jego obsługi nie wystarczy jedno tylko narzędzie, niezależnie od tego jak dobre/skuteczne byłoby.

wtorek, 24 kwietnia 2012

Lean Startup warsztaty i przerwa

Z cyklu ogłoszenia: przez kilka tygodni na blogu będzie działo się raczej nic. Spowodowane jest to urlopem okołodługoweekendowym ale także faktem, że jestem w trakcie przygotowywania warsztatu z szeroko pojętej tematyki Lean Startup. Przygotowania te pochłaniają mi m.in. ten czas, który poświęcałem na pisanie postów. Tak więc nowe teksty po przygotowaniu warsztatów czyli zapewne w czerwcu. Odpowiadając na ewentualne pytania: pierwszy warsztat będzie dla studentów WSB we Wrocławiu, później zobaczymy. Postaram się w miarę spływania informacji przekazywać je też na tym blogu.