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.

2 komentarze:

Konrad Karpieszuk pisze...

zabraklo mi opisu jak taką organizację "odkręcić" - czy zmienic sposob powolywania grup projektowych, czy samego zarzadzania projektem?

bartek pisze...

@Konrad chyba chodzi bardziej o zmianę kultury org. firmy niż o sposób zarządzania czy powoływania grup. Mnie takie podejście - projekty ponad zespoły - nie przekonuje z innego powodu. Osobiście nie wierzę, że zespoły powoływane per projekt zdążą uzyskać momentum pozwalające im na bycie *zespołem* a nie grupą. Tym samym nie ma wg mnie przestrzeni do innowacji.