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.

Co musi umieć produkt owner?

Skąd brać takich ludzi – ktoś zapytał, gdy wymieniałem jakie rzeczy robi i co musi umieć produkt owner. Coś w tym jest, być może dlatego niewielu jest naprawdę dobrych produkt ownerów i taki jest na nich ostatnio popyt.

W dyskusji pod wpisem na LinkedIn padło pytanie o ścieżkę kształcenia dla właściciela produktu. Trudne pytanie, ale nie chodzi chyba o ścieżkę kształcenia. Wymagania wobec produkt ownera są dość renesansowe. Nie tylko wiele rzeczy trzeba umieć i znać, ale szybko potrafić się uczyć nowych. Trochę już o tym pisałem.. 4 lata temu. Pora na szerszą wyliczankę, być może do pogłębienia w kolejnych wpisach.

Po pierwsze potrzebna jest wiedza z dziedziny znanej jako UX. Z moich obserwacji wynika, że ponadprzeciętne wyniki uzyskują projektanci, którzy trafili do zarządzania produktem. Mają wiedzę o użytkowniku, jego potrzebach, analityce, budowaniu interfejsów i procesach wspierających wartość produktu. UX daje też metody ułatwiające zdobywanie wiedzy o prawdziwych reakcjach użytkownika na produkt. Tę dziedzinę należy uzupełnić o orientację w sprawach biznesu. Nie zawsze jest tak, że to, czego chce użytkownik, dobrze wpływa na wyniki.

Po zerowe. Produkt owner musi przede wszystkim umieć myśleć. To tak fundamentalne, że o tym zapominamy. Z drugiej strony tak rzadkie, że nie wiem dlaczego.

Drugie: rozumienie technologii. To rzecz fundamentalna. Będąc produkt ownerem trzeba wiedzieć, z czego się składa i jak działa to, co stanowi produkt. Bez tej wiedzy nie da się dobrze podejmować decyzji i trudno zyskać autorytet u programistów. Mówimy cały czas o produktach cyfrowych, jednak one pojawiają się już w każdej dziedzinie działalności. Wkrótce, mówiąc szerzej, trudno będzie zostać menedżerem czegokolwiek dużego bez wiedzy o tym jak działa technologia.

Trzeci element – umiejętności komunikacyjne. Chodzi m.in. o to, żeby u różnych ludzi budzić zaufanie. Produkt owner pracuje z biznesem i z programistami musi więc bardzo dobrze mówić co najmniej dwoma językami. Jest też taki aspekt komunikacji, który ma związek z eliminacją niedomówień i niejasności – pełno ich w świecie projektów i rozwoju produktu.

Czwarta, powiązana z powyższym jest wiedza o procesie rozwoju, orientacja w różnych metodykach budowania oprogramowania. Nie trzeba mieć certyfikatu scrumowego Produkt Ownera (czy dowolnych innych obecnych i przyszłych), ale trzeba rozumieć esencję i funamentalne zasady, które rządzą procesem rozwoju. Żeby m.in. wiedzieć, że gdy programista deklaruje coś na czwartek, to co to może oznaczać a czego to nie znaczy na pewno.

Piąty element, to głęboka wiedza nt produktu. Tu jest ciekawy obszar do kontrowersji – na ile produkt owner może być uniwersalnym profesjonalistą, na ile musi się znać na dziedziedzinie, w której działa. Wracając do przykładu rozwoju aplikacji muzycznych. Jak szybko można sobie przyzwoić zagadnienia związane z jakością dźwięku, sposobami kompresji plików, oraz rozliczeń z właścicielami praw autorskich nie mając o nich pojęcia? Bez tego trudno dobrze je rozwijać. Tu z jednej strony wracamy do zdolności do uczenia się, z drugiej rozmawiamy o pasji.

Czy bez głębokiego zainteresowania i pasji można w jakiejś dziedzinie osiągnąć mistrzostwo?

Podcasty – od czego zacząć?

Podcasty przeżywają renesans. Stały się jednym z najlepszych sposobów na dobre spędzenie czasu w samochodzie np. w drodze do pracy. Problemem pozostaje tylko wybór. Od czego zacząć, jak się w tym wszystkim znaleźć i dlaczego warto?

Zaskakujące, że polecam podcasty. Zawsze miałem problem z przyswajaniem tekstu w postaci dźwięku. Moja ewolucja zaczęła się od.. spalonego mostu, który wydłużył drogę do pracy. Zacząłem z sensacyjnymi audiobookami. To ułatwia – polecam cokolwiek z cyklu z Jackiem Reacherem na drogę samochodem np. nad morze. Mija znacznie szybciej. Po sensacji przerzuciłem się na literaturę biznesową a kiedyś spróbowałem podcastów… i przepadłem.

Medium nie jest szczególnie nowe czy zaawansowane, ale z jakiegoś powodu rok – dwa temu mocno wzrosła jego popularność. Diagnozę, że stoi za tym dostęp do technologii na odpowiednim poziomie w samochodach + długie dojazdy do pracy znalazłem w NYMag. Wzrost popularności wywołuje rozwój oferty, powstają kolejne podcasty i ich sieci a w efekcie… mamy problem z nadmiarem. Nie ma Googla ani Youtuba dla podcastów, więc by znaleźć coś dla siebie, trzeba próbować. Są w aplikacjach gwiazdki i rekomendacje, ale to trochę jak z filmami – nie wiadomo, który z dwóch naprawdę dobrych przypadnie do gustu akurat Tobie.

Kluczowe są osobowośc autora, sposób prowadzenia konwersacji, interesujący goście i temat. Kontrowersje może budzić długość. Niektórzy mówią „więcej niż 15 minut to za dużo”. Dla mnie dobry podcast mógłby trwać wiecznie. Słucham np. Hardcore History, jestem w trakcie czwartej (czwartej!) części cyklu o pierwszej wojnie światowej. Każda z nich trwa ponad 3 godziny i ani chwili się przy tym nie nudzę. Ten podcast jest akurat wyjątkowy, gdyż słuchamy cały czas jednego faceta. Ale jak on ciekawie mówi! Na start polecam odcinek Prophets of Doom.

Skupiam się na podcastach anglojęzycznych i tematach poza „branżą”. Pierwsze zapewnia kontakt z językiem, drugie poszerza horyzonty. Niewiele dotąd znalazłem rzeczy dobrych, ale w tych, które mi odpowiadają, mam spore archiwa do przesłuchania. Tak jest z podcastem Tima Ferissa, od którego – szczęśliwie – zacząłem. Już pierwszy przesłuchany odcinek – gościem był Seth Godin – zainspirował. Seth pisze coś codziennie na swoim blogu robiąc jeszcze w życiu parę rzeczy. Dlaczego miałbym nie robić tego co 2 tygodnie?

Podcast Tima koncetruje się na procesie kreatywnym i produktywności. Jest w nim sporo ciekawych gości, autor świetnie prowadzi rozmowy. Dobre są powtarzające się pytania o książki, inspiracje, rutyny i sposoby na produktywność. Często jakość zależy od gościa i nie zawsze w sposób, w jaki się spodziewamy. Nie podobał mi się np. odcinek z Peterem Thielem, (inwestor, autor świetnej książki „Zero to One”). Polecam za to rozmowy z Kevinem Kellym (założyciel „Wired”), pisarzem Samem Harrisem, Joshem Waitzkinem (mistrz szachów i brazylijskiego ju-jitsu, po prostu posłuchajcie), ale też z Pavlem Tsatsouline (trener komandosów, pochodzi z Białorusi) i Jocko Willinkiem. Jocko, na litość boską, jest żołnierzem, ale posłuchajcie tego żołnierza…

Jeśli Ferris wam nie odpowiada, warto spróbowć Joe Rogana (też potrafi rozmawiać przez 4 godziny), dobrze się słucha Marca Marona. Zainteresowanym światem finansów i zarządzania polecam podcast Bloomberga Masters in Business, gdzie właśnie gościł profesor Danny Kahneman. Przy okazji – to dobry sposób żeby sprawdzić, który podcast nam odpowiada – wrzucić w google nazwisko człowieka, z którym rozmowy chcemy posłuchać i słowo podcast – ciekawi ludzie przewiają się przez różne audycje.

Produkty i ich warstwy

Produkty są jak cebula, mają warstwy. Niektóre z nich są fundamentalne, celem innych jest wywołać zachwyt. Jak w piramidzie, zaspokajają potrzeby na różnym poziomie. Sztuka to odróżniać te, bez których użytkownik nie może się obejść i identyfikować takie, które go uzależnią.

Spotify, Deezer i Tidal to ciekawe przypadki rozwoju produktów cyfrowych. Na ich przykładzie opisuję czym trzeba się zająć w takim procesie. Wspominałem w poprzednim wpisie jakie znaczenie ma pozyskiwanie użytkowników i zawartość. Pytanie brzmi jak dobry produkt trzeba robić, by różnice w treści nie wpłynęły na decyzje użytkowników o wyborze aplikacji. Czy to w ogóle jest możliwe? Tu zaczyna się rozmowa o jakości.

Nie wiadomo, co to jest jakość. Dla każdego to co innego. Tidal np. oferuje w specjalnym abonamencie muzykę w bezstratnej jakości dźwięku. Robi to, bo chce być kojarzony z jakością. Tej przewagi jednak żaden laik, na normalnym sprzęcie, nie doceni. Choć rozumie to rzadko kto, napiszę: dużą poprawe jakości daje dziś użycie lepszego od zwykłego przetwornika dźwięku po wyprowadzeniu cyfrowego sygnału z komórki czy tabletu, nawet przy zwykłym abonencie. Pliki mają tam wg deklaracji serwisów po 320 kbps. To nie jest mało. Więcej zależy od tego skąd się wzięły niż od tego, jak są wielkie. Koniec niszy. Piszę o tym, bo takie rzeczy rozwiając aplikację muzyczną trzeba przynajmniej rozumieć.

Ten aspekt jest techniczny, ale technologia w tym obszarze ma olbrzymie znaczenie. Z nią związana jest np. szybkość i sposób zachowania aplikacji – na ile jest „responsywna”, jak szybko robi to, o co się ją poprosi. Gdy naciśniemy play lub tapniemy tytuł piosenki – jak szybko zacznie grać. Gdy przechodzimy do playlisty – jak szybko się wyświetli. Gdy wyjmiemy słuchawkę z urządzenia – czy zagra jeszcze, czy się wyłączy. Te rzeczy wpływają na wygodę i postrzeganie jakości, nie każda w równym stopniu, i nie dla każdego.

Powyższe rzeczy mają pewną cechę wspólną – nie zależą wprost od tego jak wygląda interfejs. Widać więc jak dużo produktu jest poza „projektowaniem”. Ostatni element (wyjmowanie słuchawki) jest szczególnie ciekawy. Serwisy muzyczne nie istnieją bez wersji mobilnych. Tu znaczenie ma integracja ze sprzętem i środowiskiem, choćby wyświetlanie treści na zablokowanym ekranie. Zdarzają się w tym obszarze ciekawe innowacje – pytanie dla rozwijających produkt brzmi, które i jak warto obsłużyć gdy się tylko pojawią. Np. Chromecast. Małe urządzenie od Google pozwala na bezprzewodowe podłączenie streamingu do wzmacniacza. Rozwiązuje, za śmieszne pieniądze w porównaniu z dotychczas dostępnymi produktami, kilka istotnych problemów hmm… świadomego słuchacza (niekoniecznie audiofila). Jak poradziły sobie z tym aplikacje? Bardzo różnie – między pierwszą, która to zaadoptowała a ostatnią było ponad 4 miesiące różnicy.

Jak ocenić ważnośc obsługi Chromecasta w porównaniu ze sposobem organizacji playlist? To nie jest jedyny dylemat odpowiedzialnego za taki produkt. Próbując wymienić obszary, których dotyczą:

– Wyszukiwanie (jak szybko działa i jak dobrze podpowiada)

– Organizacja i sposób działania playlist (w tym – jak są wykorzystywane do napędzania aktywności w serwisie)

– Prezentacja treści (jakie informacje są wybite na stronie artysty, ale też uporządkowanie dyskografii)

– Rozwiązania „branżowe” i rozliczeniowe (jak zabezpieczona jest muzyka i jak jest rozliczana)

– Spójność designu na platformach (na ile aplikacja webowa powinna mieć look&feel apki…)

– W tym spójność na poziomie architektury informacji (jak zaprezentowana jest lista albumów, jak przejśc do wyszukiwania)

– Rozwiązania interfejsu użytkownika (jak dodaje się piosenkę do playlisty, skąd i co się po tym dzieje)

– Jak działa odkrywanie muzyki, skąd się biora rekomendacje, jakie są same rekomendacje (to jest duże, fascynujące i relatywnie nowe terytorium)

i to nie jest cała lista.

Kolejność nie jest głęboko przemyślana. Za mało wiem o użytkownikach, żeby to dobrze ułożyć. Mogę sobie coś wyobrażać, ale nie mam danych. Niektóre z tych rzeczy są fundamentalne, a inne są tylko istotne. Na pewne fundamenty, wszyscy powinni się zgodzić. Np. to że muzyka ma grać, gdy się ją włączy. Aspekty produktu tworzą piramidę takich składowych, zupełnie jak u hierachia potrzeb Maslowa. Im bardziej coś oczywiste i fundamentalne, tym niżej na piramidzie ważności się znajduje. Wyżej rzeczy, które mogą zdecydować, że raz pozyskany user, gdy je pozna, nie będzie mógł bez nich żyć…