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.

Reguła prostoty

„Simplicity – art of maximizing the amount of work not done – is essential”

To jedna z 12 zasad zwinnego tworzenia oprogramowania: „sztuka maksymalizacji pracy niewykonanej”. Całość w połączeniu z manifestem Agile (2001 rok) to podstawa metodyk, które zrywają z fikcją podejścia kaskadowego. Jeśli ktoś nie zna tematu, a w jakiś sposób zajmuje się rozwojem oprogramowania, powinien o tym poczytać. Materiałów jest dużo, wszystko co ważne można znaleźć zaczynając od Wikipedii.

Ta zasada definiuje prostotę i podkreśla, że jest kluczowa. Lubię ją, bo jest uniwersalna, działa nie tylko w świecie programowania. Mówi, by nie tracić czasu na rzeczy, które nie przynoszą efektu. Żeby skupiać się na istocie. To podejście spójne z Pareto – za 80 proc. efektów odpowiada 20 procent działań. Jak napisał P. Drucker „nie ma pożytku z efektywnego wykonywania pracy, która nie powinna być wykonywana”.

Kto budował ten wie, że jak niewiele funkcji w produktach ma znaczenie i jak trudno znaleźć zmianę, która przyniesie efekt, coś poprawi (zwiększy sprzedaż lub zaangażowanie użytkowników). Wie też, jak łatwo utonąć w detalach i scenariuszach, które nie mają znaczenia. W rozwoju nie jest ważna liczba wytworzonych rzeczy, tylko wynik. W działaniu nie jest ważna liczba przepracowanych godzin, tylko efekt. By go osiągnąć potrzebny jest dobry wybór środków a potem dbałość o detal. Może to dotyczyć zmian, ale też choćby poszukiwania kanałów promocji, które działają i są efektywne.

Podejście wynikające z tej zasady czasem wydaje mi się sprzeczne z wartościami powszechnie uważanymi za wartości. Np., że aby coś zrobić, należy się narobić. Jeśli nie siedzieliśmy po nocach, jeśli nie pojawiła się krew, pot i łzy, to jak możemy oczekiwać, że pokonamy konkurencję? Nie wiem czy to powszechne, czy tylko polskie, ale jeśli, to skąd po 50 latach bezproduktywnego komunizmu trwa w nas taki kult pracy? Wcale mi on nie imponuje.

W dłuższym horyzoncie zachowanie prostoty wspiera rozwój i utrzymanie – rzeczy mniej skomplikowane utrzymuje i modyfikuje się taniej i szybciej.

Często autorzy przydługich niejasnych dokumentów czy maili sięgają po cytat z B. Pascala „napisałbym krócej, gdybym miał więcej czasu”. Słusznie, prostota wymaga wysiłku. W pisaniu jest on potrzebny, by dotrzeć do sedna i osiągnąć przejrzystość. Jest takie redaktorskie porzekadło „o połowę krótszy artykuł będzie miał dwa razy więcej czytelników”. Również lepiej zapracuje krótszy, jaśniejszy i bardziej skupiony na sednie dokument. Ten wysiłek, podjęty odpowiednio wcześnie, potem owocuje – sensowniejszym działaniem, lepszymi decyzjami.

Efekty pracy adeptów sztuki UX

Mam takie zawodowe hobby: lubię w produktach oglądać efekty pracy „projektantów UX”. Bawi mnie to wielce, nawet w czasie wolnym. Pracuję z UXami, zajmuję się produktami i wszystko to jakoś ładnie się spina. Oglądam coś w sieci i wtedy kojarzę teorię albo przykłady z blogów czy „UX Magazine”, na których opierali się twórcy. (Designerzy, zwłaszcza w Google też potrafią dać czadu, ale to inna historia)

Teoria mówi, że użytkownika należy przywitać miłym słowem. Zwrócić się do niego osobiście, wtedy się lepiej poczuje i będzie miał z danym serwisem skojarzenie pozytywne. Sztuka to sensownie zaimplementować, bo ludzie są różni i różnie na komunikaty reagują – zwłaszcza jeśli interfejs wdraża się w różnych kulturach. Inkryminowany przypadek nie jest groźny lecz zabawny. Akurat na tym serwisie jestem non stop. Czekanie na mnie od 23:50 do 8:00 wygląda na patologię. Czy mam się niepokoić, czy kogoś bolało z tęsknoty? Hej, uspokójcie się tam, jestem i nigdzie się nie wybieram. Na dodatek tych dwóch albumów ostatnio słucham dość regularnie. O tej porze dałbym się skusić na kawę, zresztą już się robi…

Oczywiście to nie jest wina specjalisty UX, który chciał dobrze. Jednak działał w pewnej abstrakcji. Wszystko się wali (oczywiście nie tu), gdy rzecz się zaimplementuje i przychodzi rzeczywistość (nawet jeśli wirtualna).

W Allegro jest kawałek interfejsu, w którym podaje się adres. Tam również zaatakowali UX-owcy. Ich działanie wpływa na wrażenie, które mamy przy korzystaniu z formularza, który użytkownika atakuje dość agresywnie. Gdy zaczyna wpisywać tam np. kod pocztowy, juz po pierwszej cyfrze pojawia się ostrzeżenie i na czerwono „krzyczy”, że liczb jest za mało. Powinno to robić, niekoniecznie tak mocno (nic złego się nie stało, to jest tylko ważne) ale dopiero po wyjściu z pola, albo 2-3 sekundach bezczynności. To wydaje się oczywiste. Wiem, ze UXowcy na pewno to dobrze zaprojektowali, spieprzył „informatyk”… To tak działa już ponad rok, od zmian w serwisie. (Nie piszę o Allegro bo go nie lubię, wręcz przeciwnie – duże, ważne, używam i w wielu miejscach sensownie się zmienia).

To, że coś nie działa szczególnie sensownie, choć wymyślone zostało zgodnie z książkami i blogami, nie jest dużym problemem. Ani komunikat w Deezerze, ani nieudolny kawałek Allegro nie wygonią nikogo z serwisu. Nie powodują żadnych zysków, ani większych kosztów. Gorzej, gdy podążanie za podręcznikiem pociąga za sobą spory koszt a nie tworzy żadnej wartości. W książce Lean Startup jest opisany przykład, który to świetnie ilustruje. W Startupie Grockit designerzy zaproponowali i doprowadzili do wdrożenia „lazy registration”, zgodnie z obowiązującą w tym czasie modą. Dzięki niej użytkownicy mogli w pełni korzystać z serwisu zanim zdecydowali się w nim zarejestrować. Ta możliwośc była dość droga w implementacji i co ważne – w utrzymaniu (to zespół działań występujących w czasie, kiedy goście z UX pracują już przy innym serwisie, a Ty produkcie się martw). Autor książki zachęcił zespół Grockita do przeprowadzenia testu na dwóch grupach – korzystającej z tej formy rejestracji oraz zmuszanej w sposób tradycyjny do założenia konta. Okazało się, że to „lazy” nie miało żadnego wpływu na skuteczność pozyskiwania użytkowników i równie dobrze można było tego nie robić.

W każdym fachu mamy poziom „amator” i „specjalista”. Mistrzowie UX to nie są osoby, które przeczytały najwięcej książek. To nie są nawet ci, którzy robią najlepsze makiety i prezentacje. To ci, którzy mają też wystarczająco dużo rozumu i doświadczenia by przewidzieć w praktyce skutki swoich pomysłów. Takie „Michałki” wychodzą dziś dość często, ponieważ jesteśmy na wczesnym etapie rozwoju specjalizacji. To też kolejny dowód na to, jak bardzo praktyka odbiega od teorii. Nie daje mi spokoju zdanie z komentarza do poprzedniego wpisu: w praktyce teoria o od praktyki różni się bardziej niż w teorii…

BTW. Przyszedłem tu, żeby napisać o swojej ulubionej zasadzie Agile, ale Deezer był dziś wyjątkowo inspirujący. Poprawiliśmy znowu interefejs bloxa, dzięki pracy Justyny i ekipy, pisanie w nowej, testowej wersji jest jeszcze przyjemniejsze. Za każdym razem, gdy coś zmienią muszę to przetestować.

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.

[..tu opublikowany w 2014 wpis zawierał kilka niedostępnych już wizualizacji..]

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