Inwestujcie w zespoły, nie w produkty

Fundament w rozwoju produktów to autonomiczne zespoły dobrych ludzi, których łączy wspólny cel. To jest tak ważne, że nie wiem jakim cudem jeszcze o tym nie napisałem.

Od kilku tygodni opisuję OKR-y, metodę zarządzania celami stosowaną między innymi przez Google. To dość uniwersalna i pojemna technika. Każdy szef może wykorzystać ją w pracy z podwładnymi. Można jej używać prywatnie, opisując cele osobiste (podziwiam ludzi, którzy to potrafią). Jednak w rozwoju produktów chodzi nam przede wszystkim o stawianie celów dla organizacji i działających w niej zespołów.

Trzeba pozbyć się naiwnej wiary, że praca zespołowa to coś łatwego. Nie wystarczy zorganizowanie spotkania, by rozwiązać problem i coś zrobić. Nie wystarczy zebranie grupy ludzi o różnych specjalnościach, by coś powstało. Nawet – uwaga – jeśli to będą najlepsi na świecie ludzie. Co więcej, zespół supergwiazd będzie działał raczej słabo. Typowe podejście tymczasem jest takie, że gdy jest coś do zrobienia, to trzeba zacząć od zebrania ludzi z różnych kawałków organizacji i zamknięcia ich w jednej sali razem z przewodnikiem zwanym szefem projektu albo podobnie. To za mało.

Zespoły zwykle tracą więcej czasu i dają gorsze wyniki niż powinny. Praktyka i badania pokazują, że praca grupowa bardzo rzadko jest efektywna. „Czysty” brainstorming razem z openspacem dawno już powinny być w pudełku z napisem „majaczenia”. Poczytajcie dobre źródła, choćby HBR (niżej tytuły). Jednym z powodów dysfunkcji zespołów jest tak zwane próżniactwo społeczne. Ludzie nie pracują tak ciężko jak mogą, gdy myślą, że mogą liczyć na innych. Gdy dwóch zawodników ciągnie linę, każdy z nich wkłada w to mniej energii niż gdyby ciągnął sam.

Mimo tego praca w zespołach jest nieunikniona. By działała, muszą obowiązywać pewne reguły. Członkowie grupy muszą mieć wspólny cel i odpowiedzialność oraz uzupełniające się kompetencje. Ważna nie tylko w rozwoju produktów zasada dotyczy rozmiaru. Wiadomo, że każdy nowy członek grupy dodaje jej mniej mocy i wprowadza więcej zamieszania niż poprzedni. Dlatego rozmiar powinien być ograniczony i w zasadzie nigdy nie powinien przekraczać 10 osób. W Amazon mają regułę: team powinno dać się nakarmić dwoma pizzami.

Jesteśmy jednostkami zachowującymi się wg ściśle określonych praw. Coraz więcej wiadomo o problemach jakie sprawiamy w grupie. Gdyby ich nie było, project managerowie, konsultanci i tzw. coachowie scruma nie mieliby nic do roboty. Są w grupach różne role i każdy powinien znać swoją. Inni powinni znać jego rolę. Nie powinno być ludzi, których wkład jest niejasny.

Warto wyróżnić dwie, niekoniecznie oczywiste, ale ważne role. Jedną będzie facylitator. Różnie się go nazywa, ale ktoś musi dbać, by zespół nie wypadł z torów. Ten człowiek ma zegarek i kalendarz i nie waha się ich użyć. Upraszczam, bo naprawdę nie chodzi tylko o pilnowanie czasu i agendy. Drugim powinien być dewiant. Dziwne słowo, ale oddaje sens. Nie możecie mieć zespołu złożonego z ludzi, którzy myślą tak samo. Ktoś musi stawiać wyzwania i myśleć inaczej niż reszta. Myślenie grupowe to powszechna zaraza. To jest temat na książkę i jest kilka ksiażek na ten temat.

I teraz: trzeba budować zespoły i inwestować w to jak działają.

Wszyscy – absolutnie wszyscy – którzy coś piszą sensownego o rozwoju produktów to powtarzają. Kris Gale, VP of Engineering w Yammer, mówi, że budowanie zespołów jest ważniejsze od budowania produktu. Nie powinno się skupiać na produkcie, tylko na działaniu organizacji, która skutecznie buduje produkt. Chris Fry z Twittera pisał, że budowanie zespołów powinno być głównym zmartwieniem w organizacji od kiedy przekracza 40 ludzi. Fry radzi, żeby najpierw inwestować w zespoły, potem im przydzielać zadania. Dopiero taka organizacja się skaluje. Lubię jego porównanie do rzymskich legionów, choć skala jest nieco inna.

W Spotify podstawową jednostką rozwojową jest squad. Działa on jak mini startup, jego członkowie siedzą razem (to bardzo ważne, muszą się znać i na sobie polegać). W idealnej sytuacji squad jest całkowicie autonomiczny. Niektórzy wręcz twierdzą, że produkt powinno się budować modularnie na tyle, by mogły go rozwijać niezależne zespoły. Chcesz szybszego rozwoju? Usuń zależności między zespołami. Bezcenna rada? Ograniczaj rozmiar zespołu. Tylko osoby, które coś robią, żadnych menedżerów. Jeszcze raz: żadnych menedżerów.

Lektury z HBR (należy zaznaczyć i googlać):

Why Teams Dont Work

Discipline of Teams

Six Common Misperceptions about Teamwork

Why Group Brainstorming Is a Waste of Time

Yes, You Can Brainstorm Without Groupthink

Bezcenne źródła nt. pracy zespołów:

Twitter Engineering SVP Chris Fry on the Power of Stable Teams

Scaling Agile at Spotify

Five keys to a successful Google team

Why Yammer believes the traditional engineering organizational structure is dead

Zarządzanie produktem jako źródło problemów społecznych

Co dwa tygodnie opisuję na tym blogu różne aspekty rozwoju produktów cyfrowych. Ta dziedzina ma coraz większy wpływ na naszą codzienność. W tym nietypowym wpisie chciałbym skupić się na społecznych skutkach niemądrych decyzji produkt ownerów. Niezbyt to poważne, ale poziom stresu w społeczeństwie będzie wzrastał jeśli nic się nie zmieni.

Złe działanie albo zmiana produktu, może być przyczyną frustracji. Jak dzieci się zachowują, gdy nie ma wifi? Twój puls przyspiesza, gdy coś co powinno działać nie działa (muzyka w Spotify, film w Netfliksie). Co się dzieje, gdy coś się zaktualizowało i wygląda lub zachowuje się zupełnie inaczej niż przedtem? Ta jedna kluczowa funkcja została przebudowana, schowana albo wręcz zlikwidowana? Te problemy pierwszego świata, dziś dotyczą głównie rozrywek, ale jutro…

Kiedyś rzeczy służyły latami. Odtwarzam płyty z gramofonu, który wyprodukowano w połowie lat 80 w Niemczech. Sądzę, że nie będę potrzebował następnego – nie ma tu grama automatyki, silniczek jest w zasadzie wieczny. Współczesne produkty też potrafią długo działać. Mam jeden z wczesnych odtwarzaczy mp3 walkman Sony. Ma interfejs z muzeum ale… znakomicie brzmi i można go podłączyć do wzmacniacza w trybie z sygnałem dostosowanym do line-in (tryb słuchawkowy to nie to samo). Rzadko go używam, ale pewnie pociągnie jeszcze ze sto lat wytrwale realizując swoją podstawową funkcję.

Coraz rzadziej rzeczy tak się zachowują. Poza materialną nietrwałością (wszystko się rozpada, trwa najwyżej 5 lat) mamy problem nietrwałości funkcjonalnej. Szklany, dotykowy interfejs się aktualizuje i zmienia. To co pod nim też, nie zawsze w zgodzie z interesem i potrzebą klienta / użytkownika. Dziś coraz trudniej powiedzieć, co w zasadzie kupujemy. Oto ekstremalny przykład: HP za pomocą aktualizacji oprogramowania uniemożliwił w niektórych modelach swoich drukarek korzystanie z alternatywnych wkładek z tuszem. Raczej nie w interesie użytkownika.

Rozwój produktów ma u podstaw potrzeby użytkownika. Produkt ownerzy starają się sprawiać, żeby więcej ludzi, chętniej i w określony sposób używało ich stron czy aplikacji. By to robić dobrze muszą tych użytkowników zrozumieć i dotrzeć do ich potrzeb. Przynajmniej powinni, bo o wiele łatwiej jest wypuszczać nowe wersje. Gdy produkują zmiany i funkcjonalności, widać, że coś robią. Problem w tym, że użytkownicy w zasadzie nie chcą nowych wersji.

Zawsze zdumiewało mnie, jak bardzo ich nie chcą. Nawiasem mówiąc, żeby to wiedzieć, trzeba mieć produkt, który uzależnia i jakiś kontakt z użytkownikiem. To był problem już w dawnej branży softwarowej. Firmy tworzyły nowe oprogramowanie a klienci pozostawali przy starym. W cyfrowych produktach masowego rażenia jest to samo. Fejs wdraża jakieś dodatkowe przyciski, ludzkość zostaje przy lajku. Gdyby lajka przy tym rewolucyjnym ruchu na coś wymienić, kto wie czym by się to skończyło. Pół świata nie wiedziałoby co robić w wolnym czasie. Sam tego doświadczam. Gdy Deezer zabrał skrót do szukania z podstron aplikacji w telefonie przeżyłem rozterkę użytkownika (^#@*&!) oraz profesjonalisty (po co? po co?).

Lajki i aplikacje do muzyki to mały problem. Tu produkty mogą służyć do rzeczy ważnych (muzyka) ale wiele od nich nie zależy. Jeśli jednak używamy aplikacji banku, a ona się zaktualizuje i nie wiemy jak zapłacić… to już może być problem. Co będzie gdy pewnego dnia kuchenka, pralka czy lodówka z inferfejsem nowoczesnym zacznie się zachowywać po swojemu? Kłopot z przyrządzeniem śniadania może mieć trudne do przewidzenia skutki społeczne. Prowadzić do rozpadu rodzin czy też rozmaitych manifestacji.

Robienie zmian i nowych wersji tak, by użytkownicy z wygodą i przyjemnością korzystali dalej to sztuka. Nielicznym wychodzi, ale to taki stan w rozwoju tego zawodu, że firmy i ludzie głównie się uczą. Pozytywną ewolucję w tym zakresie obserwuję w produktach Google. Trudno dziś ich nie używać. Był taki okres, kiedy po zmianach regularnie przychodziła mi do głowy refleksja „jak można mieć tylu zdolnych ludzi i robić takie idiotyzmy”. A to typografię na liście wyników spieprzyli. A to pozmieniali w mapach i nie wiadomo było jak włączyć korki. Nawet na to zdarzyło mi się narzekać, choć to wiele nie wnosi. Dziś mam wrażenie, że nadal dużo zmieniają lecz nie wprowadzają nowych rzeczy masowo, tylko testują i wypuszczają tylko sensowne rzeczy. Tak działa dobry produkt management. To jest rodzaj ewolucji, którego potrzebujemy, bo uzależnieni od software’u zwariujemy. A jeśli kiedyś nasze dzieci będą integrować sobie oprogramowanie z mózgiem to już naprawdę….

Daty i harmonogramy przeszkadzają w rozwoju produktów

Trudno cokolwiek robić, nie ustalając na kiedy będzie i ile wysiłku pochłonie. Niestety tak to robimy, że najczęściej jest to strata czasu.

Biznes kocha daty i terminy (np. odbiorcy mleka kochają). Pytanie „na kiedy” jest fundamentem podręcznika szkoleń kierownika. Obok pytania „co proponujesz” jest przekazywane już na pierwszych lekcjach. Obu relatywnie łatwo się nauczyć i używać bez większego zrozumienia skutków. W rozwoju produktów cyfrowych pytanie „na kiedy” może być bardzo szkodliwe.

Nie kupuję harmonogramów, takich złożonych z wielu elementów, obejmujących kilka kwartałów. Pokazujących powiązania między rozmaitymi działaniami, w których powstają składowe jakiejś wspaniałej całości. O ile przedmiotem projektu jest produkt cyfrowy a nie most, albo dom (z którymi też różnie bywa), tworzenie takiego dzieła jest najczęściej stratą czasu.

Jest kilka poziomów zrozumienia tematu terminu realizacji projektu, w którym pisze się oprogramowanie. Na podstawowym rozmowa wygląda tak: po ogólnym ustaleniu co chcemy zrobić padają jakieś oceny, które zamieniają się w zobowiązanie. Z przekazu z łatwością znikają słowa „zgrubny szacunek” zostaje data.

Drugi poziom pojawia się, gdy zauważamy, że za często trzeba przesuwać terminy i prowadzić rozmowy na temat powodów. To te rozmowy i przekładanie są największą stratą energii. Dyskusja o tym, co trzeba napisać i w jakiej kolejności, może być dobrym ćwiczeniem poprawiającym planowanie…. Bo planować warto. Żadna bitwa nie została wygrana… żaden plan nie przetrwał konfrontacji itd. (prawdy nt. planowania wydają mi się powszechne znane, ale bardzo często się mylę w sprawie tego, co jest powszechnie znane).

Trzeci poziom jest ponadczasowy i uniwersalny. Gdy dochodzimy do poziomu głębokiej kompetencji wtedy wiemy, że nic nie wiemy i rozumiemy dlaczego. Że jeśli w projekcie powstaje kod, odpowiedzialnie jesteśmy w stanie rozmawiać tylko o tym, co poznaliśmy już bardzo bardzo głęboko. To, co ma mieć miejsce dalej niż za miesiąc – dwa, pozostaje fantazją. W ledwie liźniętych tematach, o skali wyzwań można mówić tylko w przybliżeniu. Rozumiemy, że wypisywanie dat dotyczących rzeczy, które mają się zdarzyć za więcej niż pół roku to bardziej prognozowanie niż planowanie.

Dziesiątki lat temu Peter Drucker stwierdził, że plan aby był sensowny i przejrzysty nie powinien sięgać dalej niż półtora roku do przodu (polecam książkę „The Effective Executive”). Było to w epoce przed-softwarowej, kiedy zwykle ludzie zajmowali się rzeczami złożonymi z powtarzalnych, znanych składników. Najczęściej każde coś robili po raz któryś i wiedzieli z czego się składa. Normą było planowanie wieloletnie, więc półtora roku było bliskim terminem. Dziś wszystko zmienia się co najmniej siedem razy szybciej. Kwartał może być rozsądną perspektywą. Potem już obowiązuje inny cytat z Druckera: „planowanie długoterminowe dotyczy przyszłości obecnych decyzji”. Nie warto podejmować decyzji na temat odległej przyszłości, bo przyzwyczaimy się do nich i będziemy się musieli z nimi mierzyć. A – znowu Drucker – jedyne co wiemy o przyszłości to to, że będzie inna.

Rozwój produktu najlepiej prowadzić w podejściu zwinnym, którego osią sa samodzielne zespoły i dobrze określona odpowiedzialność. W ich pracy od harmonogramów ważniejsze są priorytety i tempo. Trzeba wiedzieć co jest najważniejsze w najbliższym czasie i o tym wiedzieć wszystko. O tym, co się stanie za dwa miesiące, można wiedzieć mniej. Warto zakładać zmianę i nieprzewidywalność. Również po to, by zachować zdolność do zmiany kursu. Ona zawsze jest trudniejsza, gdy zainwestowaliśmy w planowanie.

Niestety czasem naprawdę potrzebujemy terminów. Powodem może być zbliżające sie wydarzenie np. wybory, święto, albo wejście w życie przepisu, do którego trzeba się dostosować. Czasem przedmiot działań jest na tyle duży, że wymagają koordynacji w różnych miejscach. Czasem po prostu opłaca się ustawić datę graniczną – bo robienie czegoś dłużej nie byłoby dobre dla biznesu.

Jak sobie radzić gdy terminów nie można uniknąć? Jak prowadzić rozmowę, gdy partner nie rozumie tego, co powyżej? O tym za dwa tygodnie.

Produkt to więcej niż interfejs i funkcje

Serwisy muzyczne to dziś jeden z ciekawszych przypadków rozwoju produktów cyfrowych. Dopiero walczą o pozycje na rynku, zmieniają sposób słuchania i poznawania muzyki i są bardzo złożone. Rozkładając je na czynniki pierwsze można zobaczyć, z czego składa się zarządzanie produktem cyfrowym i które rzeczy mają znaczenie.

Spotify, Deezer i Tidal to relatywnie nowe produkty. Deezer wszedł do Polski pod koniec 2011 roku. O takiej usłudze fani muzyki mogli kiedyś tylko marzyć: wszystkie płyty dostępne legalnie w cenie jednej miesięcznie. No, może nie wszystkie, ale i cena mniejsza. W 2012 abonament Deezera premium (dostęp do płyt bez reklam) kosztował 29,99 PLN. Po roku – i wejściu Spotify – staniał do 19,99. Można mieć dostęp taniej „na osobę” jeśli np. skorzysta się z opcji rodzinnej Spotify płacąc 30 zł za połączone konta. Tidal wszedł na rynek w zeszłym roku i zmiany cen nie wywołał. W ramach abonamentu w sieci Play działa natomiast promocja, która daje darmowy dostęp do premium przez dwa lata.

To istotny element strategii produktu: kształtowanie ceny i pozyskiwanie użytkowników. Właściciele Tidala założyli, że opłaca się wydać ponad 500 zł na osobę w imię jej przyszłych opłat. To pokazuje jak cenny dla serwisu jest każdy użytkownik i jak istotna jest promocja czy konwersja –  budowanie rozwiązań, które sprawią, że osoba zrozumie co oferuje serwis i zacznie z niego korzystać. Nie definiują one tego, jak działa produkt, ale wpływają na to, czym budując go się zajmujemy.

Liczba powracających i płacących użytkowników może zdecydować o sukcesie produktu. Aktywni użytkownicy są cenni, bo ich związek z produktem jest trwały. Przyzwyczajają się i nie jest im łatwo zmienić usługę na inną – jeśli czegoś w niej radykalnie nie zepsuje właściciel. W „spotifajach” tworzymy swój świat – mamy tam playlisty, kolekcje muzyki i inne powiązania np. ludzi, których śledzimy. Przyzwyczajamy się do funkcjonalności i sposobów ich działania. 

Surrealistyczna oferta cenowa Tidala jest też po to by dotrzeć do mas ludzi, które nie mają pojęcia, że taka usługa istnieje. Przy nowych produktach zawsze największa jest grupa „nieklientów”, nie używających żadnej z usług danej kategorii. Popytajcie znajomych, którzy słuchają muzyki, ale nie znają rynku produktów internetowych a poza Fejsem czy portalami rzadko gdzieś bywają. Zaskoczy was ilu znajdziecie takich, którym nazwy serwisów muzycznych nic nie mówią.

Zapewniliśmy atrakcyjną cenę, zajęliśmy się konwersją, pora na zawartość. Zapewne nie słuchacie Kanye Westa, więc możecie nie wiedzieć, że jego ostatnia płyta po premierze była dostępna wyłącznie w Tidalu. Potem to się zmieniło i jest w Spotify i w Deezerze. W tym drugim serwisie nie znajdziecie Radiohead, od wydania ostatniej płyty. Płyty grupy na chwilę przed premierą zniknęły zewsząd – poza Tidalem. Serwis, którego inwestorami są artyści stara się podtrzymywać aurę wyłączności. Gdy weźmiemy pod uwagę polską muzykę to tylko w Tidalu są niektóre płyty Marii Peszek i najważniejsze płyty Marka Grechuty z Anawą (kiedyś dostępne w Deezerze). W wielu przypadkach widać tam komunikat „Właściciele praw uznali, że część lub cała dyskografia tego artysty nie będzie dostępna w serwisach streamingowych. Deezer dokłada wszelkich starań, aby udostępnić Ci ją jak najszybciej.” 

Tych różnic jest więcej i nie wszystkie są na korzyść Tidala. Nie da się tego zmierzyć liczbą dostępnych piosenek, bo na świecie są miliony rzeczy, których nikt nie chce słuchać. Nie ma znaczenia, kto ma większy katalog, ważne jest pokrycie w najbardziej interesujących częściach. One same są olbrzymie. Żeby nie było łatwiej – nie wystarczy się skupić na hitach – wiele nisz, które pozostają niszami, jest ważnych dla różnych fanów muzyki.  

Pozyskiwanie użytkowników i zawartość (zasobność katalogu, lub treść) łączy to, że nie mają związku z tym jak używa się samego produktu, są niezależne od rozwiązań funkcjonalnych, a dramatycznie wpływają na jego powodzenie. „Budowniczy” produktu musi je względniać zajmując się choćby stronami konwersji czy ekspozycją treści i służącymi do tego rozwiązaniami. Pytanie jak dobry produkt trzeba robić, by drobne różnice repertuarowe nie wpłynęły na decyzje użytkowników jeśli przegrywamy w kluczowych obszarach? Tu zaczyna się m.in. rozmowa o jakości. O niej, i o tym co jeszcze ma znaczenie – za 2 tygodnie.