poniedziałek, 22 września 2008

Dzielenie funkcjonalności raz jeszcze

Prawie dokładnie dwa lata temu napisałem post nt. wielkości funkcjonalności. Post był krótki i treściwy, ale po dwóch latach w sposób równie krótki i równie treściwy muszę dokonać pewnej modyfikacji tego, co w nim napisałem.

Otóż jak najbardziej prawdą jest, że w ramach iteracji powinniśmy realizować funkcjonalności, których wielkość jest nie większa niż jedna iteracja. Doświadczenie dwóch lat nauczyło mnie jednak, że nie jest optymalne mówienie, iż każda z tych funkcjonalności musi dostarczać wartość dodaną dla klienta. Powinno się mówić o tym, że każda z funkcjonalności (w tym takie po podziale) powinny dostarczać wartość dodaną dla właściciela produktu (Product Managera). Czy to robi różnicę? Subtelną, ale jednak robi. Różnica ta polega na tym, że właściciel produktu nie koniecznie jest klientem (aczkolwiek może nim być). Zdarzyło mi się w mojej praktyce spotkać się z przypadkami, kiedy klient końcowy jako wartość dodaną dla siebie widział tylko i wyłącznie coś, co jest efektem końcowym całego projektu. Po prostu z punktu widzenia klienta końcowego żaden z elementów pośrednich, będących efektami poszczególnych iteracji nie powoduje, że biznes klienta zacznie lepiej działać i przynosić lepsze efekty. Dlatego czasami trudno tu jest mówić o wartości dodanej poszczególnych iteracji. Z punktu widzenia klienta takowych po prostu nie ma.

Natomiast wartość dodana z punktu widzenia właściciela produktu może być trochę inną wartością dodaną niż z punktu widzenia klienta. Na przykład posiadanie części rozwiązania może być dla właściciela produktu wartością, bo wie, że jest bliżej całości rozwiązania. Natomiast z punktu widzenia klienta to nie ma żadnego znaczenia, bo jemu wartość przynosi tylko i wyłącznie rozwiązanie w całości.

Nauka z tego taka, że w planowaniu zwinnym jeżeli istnieje ktoś taki jak właściciel produktu to planowanie odbywa się z oparciu o jego definicję wartości i on odpowiada za definiowanie funkcjonalności. I to właściciel produktu odpowiedzialny jest za to, aby koniec końców produkt dostarczał wartość dla klienta ostatecznego.

Uwaga!!! Klient i właściciel produktu w niektórych przypadkach to może być jedna i ta sama osoba, wtedy oczywiście cały ten post i tłumaczenie ma mały sens.

I na koniec jeszcze jedno spostrzeżenie. Gdyby nie praktyczna próba zastosowania agile nigdy nie spotkałbym się z taką sytuacją i nigdy nie przypuszczałbym, że wartość dodana dla klienta może w pewnych wypadkach być tak trudna do zastosowania. Ale od czego jesteśmy zwinni (agile). W sposób agilowy dostosowaliśmy się do panujących warunków. Zastanawiam się tylko jak by się w takiej sytuacji zachowali reprezentanci nurtu "agile ortodoksyjny"?

poniedziałek, 15 września 2008

Zarządzanie innowacjami – podstawy

Dzisiaj kilka słów na temat, który nie był do tej pory często poruszany na tym blogu, a w przyszłości mam zamiar pisać o nim więcej. Dotyczy zarządzania innowacjami, czyli jakby nie patrzyć tytułowego problemu tego bloga.

Na początek trochę o podstawach. Wiele osób twierdzi, że zarządzanie innowacjami w ogóle nie jest możliwe. Jako powód podawane jest zwykle to, że innowacje są czymś tak nowym i kreatywnym, że w przypadku organizacji nie jest możliwe stworzenie systemów i narzędzi, które umożliwiłyby zarządzanie innowacją. Taki punkt widzenia oznacza traktowanie innowacyjności jako tego, co przytrafiło się Archimedesowi: czyli siedzenia w wannie i krzyczenia w odpowiednim momencie „eureka”. Na szczęście w przepadku przedsiębiorstw i firm dochodzenie do innowacyjnym rozwiązań odbywa się w zupełnie inny sposób, nie mający nic wspólnego z przedstawionym pojmowaniem innowacji.

Zarządzanie innowacjami w przedsiębiorstwach to wbrew pozorom ściśle zdefiniowany proces (tak, proces) mający swoje cele i mierniki. A tak dokładnie każda firma chcąca zarządzać innowacjami prędzej czy później będzie zmuszona do stworzenia systemowych rozwiązań pozwalających na dokonywanie trzech głównych grup działań:

  • Identyfikacja pomysłów
  • Ocena pomysłów
  • Wdrażanie rozwiązań

W organizacjach naprawdę skutecznych pod względem innowacji te trzy grupy działań są świadomie zidentyfikowane i opisane za pomocą procesów. Na czym polegają te grupy działań?

Identyfikacja pomysłów to wszelkie działania prowadzące do spisania pomysłów i koncepcji możliwych do wprowadzenia w organizacji. Mogą to być wszelkiego typu pomysły od tego jak usprawnić pracę na jakimś stanowisku po pomysły na nowe produkty. Co jest ważne, to zbieranie pomysłów musi być dokonywane w pewien standardowy sposób. Wbrew pozorom to da się zrobić i jest to w miarę proste. System powinien być skonstruowany tak, aby wręcz wymuszał myślenie o możliwościach innowacji w konkretnych punktach działania firmy, tam gdzie potencjał zauważenia możliwości innowacji jest największy.

Ocena pomysłów to działanie polegające na wyborze spośród zidentyfikowanych możliwości tych, które są najlepsze z punktu widzenia firmy. Tutaj najważniejsze jest, aby wiedzieć jakie są kryteria wyboru oraz jaki jest proces oceny. Chodzi o to, aby zapewnić sobie możliwość wskazania akurat tych, które naprawdę są najkorzystniejsze w taki sposób, aby mieć przejrzystość procesu. Brak przejrzystości prędzej czy później spowoduje spadek liczby generowanych pomysłów.

Trzecia grupa działań to wdrażanie rozwiązań. To nic innego jak projekty wprowadzania innowacji. I tutaj mała, ale bardzo ważna uwaga. Projekt wprowadzania innowacji nie powinny być realizowane w taki sam sposób w jaki realizujemy „zwykłe” projekty w firmie. Projekty innowacyjne mają zupełnie innych charakter i dlatego procesy według których są realizowane również powinny być inne.

Jak widać wszystkie trzy grupy działań są logiczne i mogą być w prosty sposób opisane procesowo. Do tychże procesów należy następnie przypisać odpowiednie miary i osoby odpowiedzialne za realizację. Później wystarczy je „tylko” wdrożyć i kontrolować. Wtedy będzie można powiedzieć, że dana firma faktycznie zarządza innowacjami. I nie ma to nic wspólnego z czekaniem na „eureka” dobiegające z wanny…

P.S. Po ponownym przeczytaniu tego, co powyżej zdałem sobie sprawę, że stopień prawdziwości zawartych wyżej stwierdzeń bardzo zależy od tego, w jaki sposób zdefiniujemy innowacje. Teraz już nie ma na to czasu, ale będzie to tematem któregoś z następnych wpisów.

poniedziałek, 8 września 2008

Jak upowszechnić ideę, czyli dlaczego zostanie tylko SCRUM

Witam po dłuższej przerwie wakacyjnej. W każdym razie żyję i teraz już postaram się wrócić do zwykłej częstotliwości pisania.

Na początek temat tylko z pozoru odległy od głównej tematyki tego bloga. W trakcie wakacji kilkukrotnie powróciło do mnie zagadnie czynienia nowej idei popularną. Chodzi o sytuację, kiedy mamy nową (innowacyjną) ideę i chcemy ją upowszechnić. Niektórzy puryści powiedzą w tym momencie, że to nic trudnego, po prostu trzeba tą ideę sprzedać używając „zwykłych” metod marketingu i sprzedaży, postępując podobnie jak z każdym innym produktem. Być może mają rację. A nawet mają ja na pewno. Ale ja się zacząłem zastanawiać nad czymś innym. Jaka powinna być konstrukcja systemu, w którym krąży rzeczona idea, aby tenże system był w stanie w sposób najbardziej skuteczny upowszechnić tą właśnie ideę wśród firm (uwaga to ważne: mówimy o upowszechnieniu wśród organizacji komercyjnych).

Czyli sytuacja wyjściowa jest następująca: mamy nową, dobrą ideę, czyli na przykład agile project management i chcemy, żeby koncepcja ta przedostała się do świata firm i była tam używana. Jaki system zbudować, aby to było możliwe?

Jeden z modeli takowego systemu, który służy upowszechnianiu idei został mi zasugerowany przez Marka Kowalczyka. Po drobnych zmianach system ten, nazwany przeze mnie „modelem guru”, wygląda mniej więcej tak:


W centrum tego modelu stoi „guru” – osoba, która jest niekwestionowanym autorytetem jeżeli chodzi o daną koncepcję, czy też ideę, najczęściej jej twórca. Osoba ta najczęściej przekazuje swoje idee poprzez książkę swojego autorstwa, która zawiera jedynie właściwą wykładnię tego, co jest treścią idei. Książka najczęściej nie jest jedna, tylko robi się z tego cykl, każda następna prezentująca kolejną odsłonę idei. Książka jest głównym nośnikiem marketingowym, pozwalając dotrzeć do masowego odbiorcy za bardzo sensowne pieniądze (dla odbiorcy). Te osoby, które po przeczytaniu książki zainteresuje idea są następnie zachęcane do odbywania spotkań z „guru” lub osobami przez niego wskazanymi, na których to spotkaniach można zgłębić kolejne tajniki wiedzy. Całą tą machinę aktywnie wspiera sieć społeczna zbudowana wokół idei. Sieć taka zwykle opiera się o jakąś formę portalu webowego lub sieć stowarzyszeń/klubów w których spotykają się osoby zainteresowane tą właśnie ideą. Sieć ta ma zwykle jakiś sposób na wyróżnienie swoich członków spośród innych ludzi. Takim sposobem są na przykład wszystkiego typu gadżety reprezentujące idee: teczki, koszulki, kubki, zakładki do książek, etc. Zwykle sprzedawane po cenach absurdalnie wysokich.

Model powyższy został w praktyce zaimplementowany i sprawdza się znakomicie w pewnych przypadkach. Przykładami „guru” i stojących za nimi idei rozpowszechnianych w takim modelu są między innymi: Stephen Covey (7 nawyków skutecznego działania), Robert Kiyosaki (Bogaty Ojciec), Anthony Robbins (The Power Within) czy w końcu David Allen (GTD). Wymienione przykłady dowodzą, że model ten działa i w oparciu o niego można skonstruować sprawnie działający mechanizm szerzenia idei i (przy okazji) zarabiania pieniędzy.

Wymieniony model ma jednak dość znaczącą wadę. Otóż nigdzie nie ma dowodów na to, że pozwala on w sposób efektywny sprzedawać idee do firm. Wszystkie wymienione koncepcje są nakierowane na sprzedaż dla jednostek a nie dla organizacji. Mimo, że może nawet wystąpić sytuacja kiedy to firma płaci za seminarium GTD czy dowolne inne to nadal cały czas ta idea jest sprzedawana poszczególnym osobom w ramach organizacji. Czy ktoś kiedyś słyszał, żeby firma działała według 7 nawyków, aby według GTD albo czegoś podobnego? Nie. Firmy działają według Lean, CMMI, SixSigma, ISO, PMI czy Prince2 . W tym momencie mnie tknęło. Następnym logicznym pytaniem jest bowiem: czy te wszystkie koncepcje też mają wspólny model wokół którego się obracają? Analiza wykazała: mają.

„Model standardu” jest drugim modelem upowszechniania idei, który sporządziłem próbując dokonać reverse engineeringu na koncepcjach odnoszących największe sukcesy w firmach. Takich, które zostały już wielokrotnie wdrożone i które są znane większości osób zaangażowanych w daną działkę przemysłu. „Model standardu” prezentuje się w sposób następujący:

Zgodnie z nazwą w centrum modelu jest standard. Koniecznie spisany, dostępny albo za darmo, albo (częściej) w postaci płatnego wydawnictwa. Standard ten jest oficjalnie opracowany i utrzymywany przez pewną organizację, która jest zwykle pomysłodawcą idei. Ta sama organizacja zajmuje się certyfikacją, która jest kolejnym elementem modelu. Organizacja, która wymyśliła ideę rości sobie prawo do oceniania i certyfikowania z zakresu propagowanej idei. Odbywa się to zwykle dwutorowo. Po pierwsze organizacja może przetestować i certyfikować poszczególne osoby/organizacje pod kąte tego jak dobrze znają one dany standard. W ten sposób powstają wszystkie dyplomy, certyfikaty, stopnie dojrzałości itp. Drugi zakres działania organizacji certyfikującej jest jeszcze ciekawszy: dotyczy certyfikacji organizacji, które mogą propagować standard dalej. Czy organizacja, która wymyśliła pierwotną ideę, daje swoistą licencję innym organizacjom na propagowanie tej właśnie idei. Zauważyłem zresztą, że bardzo rzadko ta organizacja, która wymyśliła ideę sama dostarcza np. wiedzę z jej zakresu. Ona wynajmuje do tego „niezależnych”, certyfikowanych dostawców. Cudzysłów jest dlatego, że ci dostawcy są w 100% zależni od organizacji certyfikującej, gdyż brak ich uznania, cofnięcie certyfikatu w większości wypadków skutkowałby natychmiastowym wypadnięciem z rynku. Na koniec jako element propagowania idei jest jeszcze coś takiego jak sieć kontrahentów. Chodzi tu o to, że organizacje certyfikujące poprzez swoich „niezależnych” dostawców często wymuszają na przedsiębiorstwach, że w momencie implementacji standardu będą „namawiać” swoich partnerów do przyjęcia tego samego standardu. „Właśnie wdrożyliśmy ISO i aby utrzymać wymaganą jakość oczekujemy, że za 6 miesięcy wszyscy nasi dostawcy też wdrożą ISO”. Działa rewelacyjnie, zwłaszcza jak pierwszym podmiotem, który tak mówi jest organizacja rządowa udzielająca zleceń (przypadek PMI, Prince2 czy CMMI).

Jaki jest powód tego, że „model standard” jest znacznie skuteczniejszy w sprzedawaniu idei do firm niż „model guru”? Według mnie klucz leży w modelu potrzeb Maslowa a konkretnie w drugiej kluczowej potrzebie każdego człowieka, czyli potrzebie bezpieczeństwa. W tym wypadku bezpieczeństwa zawodowego menedżera, który podejmuje decyzje o wdrożeniu danej idei. W przypadku „modelu guru” idea taka nie jest dla niego bezpieczna, gdyż opiera się o konkretnego, jednego człowieka. Czy jakikolwiek wysoki szczeblem menedżer pozwoli, żeby jego firma opierała się o idee jednej jednostki, jednego człowieka? Nie. Zupełnie inaczej natomiast wygląda sytuacja, kiedy mamy wdrożyć znany na rynku standard wspierany przez „niezależną” instytucję certyfikującą i „niezależnych” dostawców wiedzy. Zresztą tych dostawców jest wielu w odróżnieniu od „modelu guru”, gdzie zwykle dostawca jest jeden (firma założona przez twórcę idei).

I tak na koniec. Dlaczego piszę o tym na tym właśnie blogu? Otóż próbowałem przeanalizować sobie w jaki sposób próbuje się upowszechniać koncepcje agile project management. Wydaje mi się, że do tej pory wszystkie koncepcje agile były upowszechniane w sposób przypominający „model guru”. Dwa najbardziej jaskrawe przypadki to Alistair Cockburn z jego metodami Crystal oraz Ken Schwaber i SCRUM. Upowszechnianie idei w ten sposób jakoś szło. Ken Schwaber, Mike Cohn oraz Esther Derby, jako jedyni spośród „guru” agilowych, zdecydowali się jednak powołać Scrum Alliance. „Niezależną” organizację trzymającą pieczę nad standardem oraz certyfikującą „niezależnych” dostawców. Jeżeli moje rozważania są poprawne oznacza to, że prędzej czy później, ale raczej prędzej SCRUM upowszechni się jako jedyna słuszna metoda zwinnego zarządzania projektami.