Dwa światy, trzy różnice

Pracownicy banków, firm ubezpieczeniowych czy telekomunikacyjnych budujący produkty cyfrowe nie różnią się szczególnie od osób zatrudnionych w nowym, internetowym biznesie. Mogą mieć podobne kompetencje, podejście i zaangażowanie. Jednak świat, w którym działają jest inny i to co osiągną w większym stopniu zależy od organizacji, niż od ich możliwości.

Porównały te światy dwa blogi: SVPG i Monday Note. Pierwszy opisał różnice między kulturą produktową i informatyczną, drugi zajął się światem mediów. Oba aspekty są mi bliskie, z czystym sumieniem mogę polecić te wpisy. U podstaw różnic, które wymieniają wydają się leżeć odpowiedzi na trzy kluczowe pytania. To jak na nie odpowiadaja organizacje nie jest czymś o czym zdecydowały. To raczej kwestia DNA. Tak wyewolułowały, nie wiedzą, że można inaczej. Nawet jeśli wiedzą, często nie potrafią.

Zacznijmy od starożytności. Do poprzedniej dekady informatycy nie interesowali się konsumentem. Komputer osobisty służył mu najwyżej do grania (nieco przesadzam, celowo). Sukcesy rynkowe i pieniądze w informatyce oparte były o sprzedaż dla przedsiębiorstw. Oba człony są ważne – wokół nich zbudował się biznes. „Sprzedaż” miała wpływ na sposób prezentacji oferty, oznaczała duże sumy i długie kontrakty. „Dla przedsiębiorstw” określało rodzaj rozwiązywanych przez intormatykę problemów. Po 2000 roku to się zaczęło zmieniać – dziś większe pieniądze wynikają z robienia rzeczy, których używają ludzie (gdyby ktoś miał wątpliwości: Google, Amazon, Facebook, Apple). 

Jakie są więc te fundamentalne różnice?

– Kto decyduje o sukcesie produktu? W informatyce o wyborze rozwiązania decydował kontrakt i sprzedaż, często na poziomie zarządu. Klikający nie miał wyboru. Prezes zamówił, księgowa musiała się nauczyć. Co więcej, opłacało się coś sprzedać, a do rachunku dopisać szkolenia. Nie była konieczna wiedza o użytkowniku końcowym, nie miały znaczenia użyteczność, wygoda i efektywnosć działania produktu. To są rzeczy w produktach cyfrowych ważne (choć nie wystarczające). Poza nimi jest jeszcze magia, związana choćby z budowaniem skali. Wpływ tego podejścia nie ogranicza się do wymyślania i budowania produktów. Obejmuje też takie sfery jak obsługa użytkownika. Obsesja na jego punkcie to wynalazek Amazona i podobnych. Oczywiście ich motywacją jest konkurencja, gdy jest niczym nie ograniczona, warto inwestowac w lojalnośc.

– Jak technologia zaangażowana jest w budowanie produktu? W podejściu tradycyjnym dział technologii buduje zlecone rzeczy. W produktowym – współtworzy je. Świetne jest porównanie SVPG do najemników i misjonarzy. Pierwszym mówi się co mają zrobić, drugich motywuje to, co budują. Chcą, żeby było jak najlepsze, rozumieją użytkownika, proponują rozwiązania i dbają o jakośc. W świecie cyfrowym biznes jest technologią, a technologia przewagą, której nie można pominąć. Tradycyjnie – jest czymś, co się zamawia. Jacyś informatycy to robią.

– Jak długo produkty się buduje? Tu mamy paradoks. W informatyce kojarzymy „bardzo długi kontrakt dla ZUS”, więc w zasadzie w nowym świecie powinno być „krótko i szybko”. Niestety prawda jest taka, że tu rozwój nie kończy się nigdy. W tradycyjnym rozumieniu działowi technologii się coś zleca, on to robi, potem jest to zrobione i koniec. Definicja-realizacja-wdrożenie-następny temat. W świecie produktów cyfrowych, wdrożenie to dopiero początek – zaangażowanie w rozwój produktu musi być długofalowe. To jak działa jest na tyle ważną przewagą, że osiąga się ją dopiero poprawiając coś działającego. Termin „zwalnianie zasobów” nie występuje. Nie występuje dlatego, że nic się nie zwalnia oraz nie ma zasobów. Ważniejsza od dowiezienia projektu jest umiejętnośc szybkiego rozwoju produktu.

Skąd to podejście wynika? Wyewolułowało. Tradycyjne długie nieudane projekty zamieniono w branży na trwające w podobnym czasie serie małych, dużo bardziej udanych. To okazało się efektywne. Po drugie określają je warunki rynkowe. Ponieważ dystrybucja produktów jest tania, konkurencja jest nieustanna, rynek wymusza ciągły rozwój. Autorzy Monday Note sugerują, że przyczyną może być głębokość kieszeni. Inicjatywy cyfrowe wydawców nie mogą liczyć na takie finansowanie jak startupy. Choćby Vox media, który niedawno pozyskał 45 mln USD od inwestorów. Pytanie czy poziom zaangażowania wynika z finansowania, czy sposobu myślenia o rozwoju.

Podział nie jest już taki czarno biały: produktowe podejście dla userów i tradycyjne dla firm. Coraz więcej w nowym świecie powstaje rozwiąząń dla biznesu – już nie tylko internetowego. Przykładem niech będzie Box, w którym wyzwaniem jest połączenie organizacji sprzedażowo-usługowej z kulturą rozwoju rodem z Google czy Facbooka. Tak przynajmniej twierdzi szef startupu Aaron Levie. Box musi do swojej organizacji dodać – powiedzmy to – gorszą część kultury. Zdrowy fundament już ma. Inni mają gorzej, bo najtrudniej zmienia się kulturę. Podejście tradycyjne i „model IT” jest tak zakorzenione w organizacjach, że łatwiej im będzie wyginąć niż się zmienić.

Co jednak nie jest niemożliwe.

 Jeśli dotarłeś dotąd – dziękuję za uwagę. Miło mi będzie, gdy pstrykniesz like’a 😉

Szukając Pareto

Poszukiwanie prostoty jest wysiłkiem. Trzeba go podjąć, jeśli chce się zrobić tylko znaczące rzeczy. Ten paradoks okazał się najciekawszym wątkiem z poprzedniego wpisu „Reguła prostoty”. Co sprzyja takiemu poszukiwaniu, zwłaszcza w pracy zespołów? 

Rozmiar. Ma olbrzymie znaczenie, to oczywiste i nieoczywiste zarazem. Peter Drucker już w 1954 pisał, że dobry zespół to 3-4 osoby. Bardzo często się o tym zapomina. Z każdą dodatkową osobą, dowolna rzecz z tej listy będzie trudniejsza. Przyczyny? Społeczne, zwłaszcza związane z „komunikacją”, matką wszelkich korpo problemów.

Myślenie. Zalecane na każdym etapie, zwłaszcza przed. Niestety, wg aktualnych badań [HBR] myślenie grupom wychodzi słabo.

Słuchanie. Nie tylko własnego głosu, co jest jedną z najprzyjemniejszych aktywności. Również innych, zwłaszcza użytkowników. Nie trzeba, czasem wręcz nie wolno, robić tego co mówią. Warto wyłapywać informacje na temat ich potrzeb, sposobów korzystania z produktów i problemów jakie z nimi mają.

Otwartość rozmowy. Jeśli chcemy mieć różne głosy i opinie, trzeba sprawić, że się pojawią. Trzeba stworzyć klimat, który zapewni, że wypowiedzą się nawet introwertycy. Czesto to oni mają najwięcej do powiedzenia. Na retoryce krzykaczy w dłuższym terminie niewiele się buduje, wyniki bezlitośnie się z nią rozprawiają. 

Mierzenie. By znać wyniki, potrzebne są dobre miary. Takie pirackie, pokazujące, czy rzeczywiście coś zadziałało. Ich poszukiwanie nie jest banalne. Warto też zerkać na koszt i próbować mierzyć swój czas w złotówkach.

Pamięć. Jeśli coś działało kiedyś, jest szansa, że zadziała znowu. Jeśli nie działało, można spróbować to zrobić lepiej. Raczej nie ma sensu próbować tego samego, w ten sam sposób. Czasem jest to demotywujące, bo niestety niewiele rzeczy naprawdę działa.

Jest tu pułapka. Często rozwiązanie realizowane jest źle i na podstawie wdrożenia wyciąga się wnioski, że jest nieskuteczne. Może powodować to detal, czasem „nie działanie” wynika z przyjętej miary. Jeśli w coś wierzymy, warto tego spróbować na 2-3 sposoby. 

Temat pamięci powiązany z tzw. budowaniem wiedzy w organizacji. „Uczenie się” jest częstą wymówką w projektach „wprawdzie się nie udało, ale wiele się nauczyliśmy”. To jest przereklamowane. Najczęściej wszyscy zachowują jakby coś było robione pierwszy raz. To o tyle dziwne, że do dyspozycji jest cały arsenał przypadków opisanych wokół, a podczas rozwoju stale buduje się jakąś historię.

I mówiąc szczerze jeszcze nie mam na to sposobu.

Elastyczność. Gdy coś zadziała, warto to drążyć i eksploatować szukając maksimum. Ścisłe trzymanie się z góry założonego planu utrudnia takie zwroty.

Autorefleksja. Podsumowania czyli Post mortem pomagają w budowaniu pamięci. To trudny do stosowania zwyczaj (nikomu się nie chce, gdy jest już po wszystkim). Ciekawą wersją jest „Pre mortem”, w którym próbujemy napisać podsumowanie projektu przed jego rozpoczęciem. Wymieniamy co się udało, oraz co poszło źle. To umożliwia odkrywanie niebezpieczeństw.

Małe kroki. To dośc oczywiste  —  każdego słonia trzeba jeść po po kawałku. Próbować i testować. Postęp jaki się uzyskuje zamykając małe etapy jest motywujący. Wszystkie wymienione tu przepisy lepiej działają w krótkich iteracjach. 

To warunki, które mogą wpłynąć na pracę zespołów w średnich i dużych organizacjach. Pewnie inaczej jest w start-upach na wczesnym etapie rozwoju. Praca indywidualna to odbrębny temat. Dla wszystkich, jest jedna wspólna reguła: ćwiczyć. Całe czytanie mądrości w internecie (choćby takich jak ten wpis) nie ma bez stosowania ich w praktyce większego sensu.

Wszyscy czytają to samo, sukcesy odnosi niewielu. 

Jeśli dotarłeś dotąd – dziękuję za uwagę. Miło mi będzie, gdy pstrykniesz like’a 😉

Pokochać proces

Gdy organizacja chce sprawnie tworzyć popularne produkty, potrzebuje do tego dobrych ludzi. Od pewnej liczby zatrudnionych to jednak za mało. Potrzebny jest dobry proces – powtarzalny sposób robienia rzeczy. Musi być na tyle sensowny, żeby ludzie go rozumieli i akceptowali. 

W prezentacji nt rozwoju produktów znanej, dynamicznej firmy internetowej natknąłem się na schematyczną prezentację procesu.

Wygląda tak:

proces_rozwoju_spotify

Choć jest to ładnie pokazane, widać, że ma sporo etapów, które trzeba zrozumieć, więc nie jest bardzo proste. Zaskakujący może być aktywny udział managementu w kolejnych fazach procesu.

Zawsze jest między nimi furtka – zespół, autonomiczny, samodzielny i agilowy musi uzyskać akceptację / decyzję z udziałem managementu, żeby pójść dalej.

Jak na organizację, której to dotyczy, wydaje się dość sformalizowane. Przykład jest w miarę świeży. 

Kilka lat temu prowadząc rozmowy nt. procesu prezentowałem przy różnych okazjach taki obrazek:

aol_52_product_devWidać, skąd pochodzi. Prezentacja nt. tego jak działa AOL została upubliczniona przez Business Insidera.

Obrazek niżej pochodzi z 2009, z dużej polskiej firmy internetowej. W jakimś stopniu po wdrożeniu ten proces został porzucony, nie mam obowiązujego obecnie. Prawdopodobnie ten był niezbędnym etapem na drodze do Agile.

proces_rozwoju_allegro

Ta firma to Allegro. Pokazywany był na branżowej konferencji informatycznej. Ze schematem z AOL łączy go podejście – kaskadowe. Na początku wymyślamy coś dużego, potem projektujemy coś dużego, potem długo to robimy. Na koniec okazuje się, że wszystko wyszło idealnie… No to akurat się rzadko zdarza.

Pierwszy proces ma fazy, ale różni się treścią. Inaczej wymyśla się w nim rzeczy, robi się o wiele taniej, głównie po to, żeby sprawdzić pewne teorie. Dopóki coś jest projektem i koncepcją, pozostaje teorią. Prawdziwe liczby i użytkownicy bez większego wysiłku stale takie teorie obalają.

Pierwszy proces to Spotify. Dość dokładnie opisany jest tutaj. Wszystkim, którzy się zajmują tematem [czyli pewnie jakimś 10 osobom w pl 😉] polecam uważną lekturę.

Zagrajmy w ustalanie priorytetów

Pisałem już jak ważne w rozwoju produktu jest priorytetyzowanie rzeczy, którymi się zajmujemy. Niedawno natknąłem się na niezły przepis na ten proces. Jego autorem jest Tom Conrad, który odpowiadał za rozwój Pandory, jednej z ważniejszych na rynku aplikacji muzycznych.

W tym podejściu wybór rzeczy do realizacji przypomina grę. Jej fazy są takie:

  1. Każdy zgłasza swoje pomysły odpowiadając na sprytnie postawione pytanie: czego głupotą byłoby nie zrobić w najbliższych trzech miesiącach. Czyli nie „co moglibyśmy zrobić” tylko „czego nie możemy nie zrobić”. Już to wymusza refleksję. 
  2. Wszystkie pomysły opisuje się w podobny sposób – za każdym razem na takim samym slajdzie podając o co chodzi i jakie korzyści ma to przynieść produktowi.
  3. Szacuje się ilośc pracy potrzebną do zrealizowania każdej rzeczy.
  4. Tu zaczyna się praca grupowa. Tworzy się wirtualną walutę (np. papierowe dolary), które dostają osoby decydujące. Ich ilośc odpowiada liczbie dostępnych dni pracy ludzi, którzy są potrzebni, żeby to wszystko zrealizować.
  5. W czasie sesji głosuje się „wydając” przydzielone pieniądze na poszczególne funkcjonalności / zmiany. To co zostało sfinansowane trafia do realizacji.

Warto poczytać dokładnie tekst Conrada, ale kilka rzeczy w tym podejściu jest wartych omówienia.

Całość upraszcza proces analiz i wymiarowania pomysłów. Metoda jest zwinna, oparta na zdrowym rozsądku. W innych podejściach każde zadanie można modelować na różne sposoby i wrzucać do exceli, z których na koniec nic mądrego nie chce wyjść. Tu logika jest prosta – albo jesteśmy jako zespół / startup / organizacja do czegoś przekonani i to finansujemy, albo nie. By to zadziałało, w grupie decydujących warto.. mieć decydentów. Byc może nawet dając im trochę więcej pieniędzy niż pozostałym.

Ćwiczenie wymusza uczestnictwo i wciąga zainteresowanych. Dobrze zrealizowane zapewnia, że kluczowe dla produktu osoby aktywnie uczestniczą w decyzjach. Identyczna prezentacja wymusza myślenie o tym, co określona rzecz da. Nic nie dzieje się pod stołem – każdy krok jest omówiony, a równocześnie nie zajmuje to dużo czasu. Przy okazji rozmowy o kosztach i korzyściach wszyscy mogą lepiej zrozumiec proces rozwoju. Gra wspiera też tworzenie kultury priorytetyzacji w załodze.

Dośc kluczowy jest szacunek kosztów i ocena czasu pracy jaki mamy do dyspozycji. Tu najczęściej popełniamy błędy. Mylimy się szacując ile coś zajmie, dlatego trzeba to robić z uwagą, ale też dzielić rzeczy na takie (czytaj: względnie nieduże), by ich ocena była możliwa. Z drugiej strony nie można zakładać, że miesiąc pracy człowieka to pełne 20 dni na rozwój. Ludzie chorują, chodzą na urlopy, a przede wszystkim robią całą masę rzeczy, które zżerają ten czas. Utrzymanie, zebrania i maile zabierają więcej niż wam się wydaje. To warto liczyć i posługiwać się danymi zbliżonymi do historycznych.

Niedawno przećwiczyliśmy to w praktyce m.in. planując dalszy rozwój nowego Blox.pl. Zachęcam do próbowania w startupach i przedsiębiorstwach wszelakich.

BTW – świetnie się pisze w tym nowym edytorze Blox.pl