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.