Kategoria: PL

Planowanie rozwoju – sztorm doskonały

Świat rozwoju produktów jest fascynujący. Większość rozmów dotyczy tu możliwości, które nigdy nie ujrzą światła dziennego. Angażujemy się w zadania, których wyników nie jesteśmy w stanie przewidzieć. Przeceniamy korzyści, jakie przyniosą. Prawie wszystko robimy pierwszy raz i nigdy nie wiemy co tak naprawdę zadziała. I choć ciągle się mylimy, uparcie opowiadamy sobie bajeczki o terminach.

Tak, każda decyzja powinna zawierać termin i osobę odpowiedzialną. To dobra praktyka, lecz gdy daty są wymuszoną deklaracją bywają gorsze niż ich brak. Jeśli ktoś mówi, że coś złożonego zrealizuje w określonym czasie, warto go zapytać co daje mu tę pewność. Czy rozumie co musi zostać zrobione i wie, co się może stać? Jeśli potrzebna jest praca wielu osób – co każda z nich wie o swoich zadaniach? Czy już je kiedyś realizowała? Czy ma na nie czas? Im więcej jest zaangażowanych, im bardziej zadanie złożone, tym łatwiej się pomylić. Ostateczna pomyłka zwykle jest większa niż suma pomyłek składowych.

Temat niedawno poruszyła jedna z autorek piszących na Medium (po ponad roku artykuł został usunięty). Nieźle opisuje co wpływa na pomyłki w planowaniu. Przede wszystkim mylimy się, ponieważ nie pracujemy tyle ile nam się wydaje. Jeśli ktoś opowiada wam ile pracuje, nie wierzcie mu. Badania wykazały, że osoby, które deklarują 55-65 godzin pracy w tygodniu, przesadzają o 10. Ci, którzy mówią o 74 – przesadzają o 20. Przeceniamy więc ilość pracy, jaką możemy wykonać w danym czasie. Równocześnie wydaje nam się, że dobrze wykorzystujemy dostępny czas. Tymczasem aż do 60 procent nie spędzamy na pracy. Prokastrynacja to tylko jeden z powodów. Zapominamy o masie rzeczy, które wypełniają nam dni – innych zadaniach, zebraniach, rozmowach a także chorobach i urlopach.

Mylimy się również szacując ile czasu potrzeba, by coś zrobić. Fenomen „złudzenia planowania” jest całkiem nieźle zbadany. Dotyczy obsługi samochodów (jak to jest, że oni mając na coś godzinę mylą się o godzinę?) i budowania mostów. Gdyby nie obowiązywał, project managerowie byliby bez pracy. Planując skupiamy się na najbardziej optymistycznym scenariuszu. Bardzo rzadko schodzimy do poziomu detalu. Nie doceniamy ile każda z rzeczy, które trzeba zrobić, może zająć.

Na to nakłada się specyfika rozwoju produktów – już pisałem o mitach z nim związanych. Kluczem dla problemu planowania jest „inwentarz”, na którym pracujemy. Jest nim informacja. Krąży w postaci słowa, notatek i rysunków, w dokumentach. Pogooglajcie za definicjami: nie jest łatwo informację zdefiniować, jeszcze trudniej jest ją zmierzyć. A jeśli czegoś nie da się mierzyć, trudno jest tym zarządzać. To nie fabryka, gdzie codziennie procesy się powtarzają a wszystko jest zdefiniowane. Przekaz nigdy nie jest całkowicie jednoznaczny – każdy rozumie go po swojemu. Na dodatek często pod niewinnie wyglądającym zapisem kryje się coś złożonego. To okazuje się dopiero, gdy dokładniej się nim zajmiemy. Kto nie robił, nie zrozumie.

No i mamy sztorm doskonały – nie potrafimy planować, nie wiemy co tak naprawdę jest do zrobienia a na dodatek posługujemy się czymś czego nie da się zmierzyć, w procesie, w którym materiał każdy rozumie po swojemu. Mimo to nic nas nie powstrzymuje nas przed tworzeniem ambitnych planów i roadmap. I jakoś to działa.

No właśnie – przeważnie jakoś.

Fikcja produktowa: strategia i wizja

Każdy produkt ma jakąś wizję i strategię. Sytuacje, w których jego właściciel nigdy nie pomyślał o tym co robi, dla kogo i jak, zdarzają się rzadko. Z drugiej strony spisywanie tych rzeczy nie jest popularne. Lepiej wychodzą, gdy komuś np. przy piwku, opisujemy czym się zajmujemy. Gdy start-upowiec po raz 5-ty usłyszy pytanie „dla kogo jest ten produkt” albo „jaki problem rozwiązuje”, to w końcu wpisze to do swojej prezentacji. Będzie ze swoim partnerem (czy jak się mówi w tej branży) działał posługując się tymi ustaleniami, czasem nawet nieświadomie. Co bardziej światły nazwie je po imieniu.

Gdy firma zatrudnia więcej niż kilkudziesięciu tzw. pracowników umysłowych i nie odrabia zadań domowych należycie, na korytarzu zaczynają się pojawiać pytania „jaka właściwie jest nasza strategia?”. To zdrowy objaw – ludzie interesują się kierunkiem, w którym zmierza budynek. Gdy jest odpowiedź moga ją krytykować, a podchodząc pozytywnie – lepiej działać. Strategia się więc przydaje. Poza nią wizja i jeszcze parę rzeczy powodujących, że przestają być tylko interesującą opowieścią.

Zacznijmy od wizji, bo to właściwa kolejność. Ona określa tożsamość i mówi, co robimy, co chcemy osiągnąć i gdzie chcemy być w ciągu 2-5 lat. CEO LinkedIn Jeff Weiner mówi: Na świecie jest 3,3 mld profecjonalistów i LinkedIn chce być zawodową tożsamością każdego z nich. Chce też by każda firma na świecie utrzymywała profil na LinkedIn i używała serwisu do zatrudniania. Niewiele więcej trzeba, ale ustalenie tych paru zdań nie jest łatwe.

Strategię określa się po ustaleniu wizji. Wizja mówi „wygramy wojnę”, strategia „wystrzelimy dużo rakiet”. Mniej więcej – tak to łatwiej zapamiętać. Nie udaję eksperta, ale wiem, że ze strategią jest jak z UX: większość osób, które posługują się tymi określeniami nie potrafi ich wytłumaczyć. Strategie piszą wszyscy bez względu na to co w jej ramach powstaje. Czasem jest to „roadmapa” czy inny pseudoplan, czasem opowieść o sytuacji rynkowej, najcześciej fantazyjny i mało treściwy powerpoint.

Strategią ludzie nazywają tyle różnych rzeczy, że powstał nawet blog skupiający się na cytowaniu różnych jej definicji. Niestety zgubiłem link. Zamiast niego polecam świetny tekst w nieocenionym HBR: „Don’t let strategy become planning”. Mówi, że strategia to zbiór wyborów dotyczących tego co chcemy osiągnąć, jak będziemy o to walczyć i czego do tego potrzebujemy. Na tym poziomie nie trzeba studiować tematu, żeby zacząć go realizować z sensem.

Więc wiemy gdzie chcemy być i jak tam dojdziemy. To dużo ale zanim cokolwiek zrobimy, jest to fikcja. I teraz zaczynają się schody.

Dokumentowanie, notowanie i biurokracja produktowa

Dobrze pamiętam, sensownie się umówiliśmy. Nic jednak się nie stało. Nikt też nie pamięta, co dokładnie się miało wydarzyć. A wystarczyło spisać. Ciągle jeszcze mi się zdarza doświadczyć sensowności prostej zasady: nie ufaj swojej pamięci. Zapisuj. Twórz notatki, zwłaszcza jeśli pracujesz z dużą liczbą osób.

Dokumentowanie kojarzy nam się z biurokracją i odrabianiem zadań domowych. Bardzo tego nie lubimy. Na dodatek wiemy z opowieści, że produkty cyfrowe mogą się bez tego obejść. Wszystko da się zrobić w kodzie, bazując na szkicach. Wystarczy zgrany zespół i rozproszona w mailach i zapisach z komunikatorów korespondencja. Tak może zaczynać dowolny startup, ale wzrost wymusi na nim zmianę.

Nie lubimy dokumentów, założeń i notatek, bo często stają się czymś koszmarnym. W korporacjach standardowe kwity, zwłaszcza dotyczące tzw. projektów informatycznych zwykle są fatalnie sformatowane i wypełnione pustymi formularzami, które bardzo rzadko mają zastosowanie (są w każdym kwicie, bo format jest uniwersalny). Na 5 stronach mamy kilka zdań treści, a reszta to elementy dokumentu, których używa się raz na jakiś czas. Na dodatek nazwy pól są bardziej czytelne niż treść. Dlaczego się tak dzieje? Bo rzadko kto zawraca sobie głowę dbaniem o przejrzystość tych rzeczy. Kolejne generacje pracowników używają tego, bo muszą. Na dodatek uczą się, że tak ma być i.. przenoszą czasem wzory w nowe miejsca.

Po co spisuje się rzeczy? Przede wszystkim – by wyręczyć pamięć i nie tracić czasu na dyskusje o tym, co raz się ustaliło. Gdy coś jest spisane może krążyć i wywoływać dyskusję. Tylko ludzie, którzy „wiedzą lepiej” jej nie potrzebują. Pisanie wspomaga też myślenie. Zwłaszcza u wzrokowców – osób, które najlepiej odbierają informacje, gdy je czytają. Taki przekaz zaoszczędza też czas na osobiste tłumaczenie. W końcu kwity są potrzebne, by uchwycić moment podjęcia decyzji. Potem można do tego wracać. Spisane ustalenia pozwalają na weryfikację dokonań.

W każdej organizacji, w której niewielu decyduje o pracy większości, pewne rzeczy trzeba ustalać zanim zacznie się coś realizować. Nawet jeśli mamy całkowicie samodzielne zespoły, coś musi wyznaczyć ramy ich działania. Gdy wszystkie ustalenia są w mailach, to czasem ten stan wymaga tylko drobnej ewolucji. Wystarczy wyjść z poziomu dyskusji do spisanych ustaleń, a efekt przerzucić do notatki z nazwą, datą i autorami. Stworzyć minimalną liczbę wymaganych dokumentów i napisać, czego nie może w nich zabraknąć. Minimum jakie ma się w nich znaleźć wymaga dyscypliny. Lepiej przy tym unikać długich kwitów. Czasem to nie wychodzi, wtedy można wymuszać pisanie w punktach.

Poza tym warto jeszcze zadbać o sensowne nazwy tych kwitów (naprawdę macie 50 plików o nazwie zalozenia.rtf?). Formatowaniem nie trzeba się zajmować, jeśli nikt nie formatuje. Gdy ludzie zaczynają korzystać z wymyślnych możliwości oprogramowania, lepiej narzucić prosty standard. Żeby nie tracili czasu na wybór kształtu bulletpointa a skupili się na treści.

Warto pamiętać, że – to wychodzi zwłaszcza w rozwoju produktów – tekst pisany każdy rozumie po swojemu. Jednoznaczne jest dopiero to co powstało, coś czego można użyć. Dobre, proste kwity są jak terminy. Same nie mają mocy sprawczej, ale pozwalają się nam znaleźć na „tej samej kartce”. Nie są celem samym w sobie, dlatego warto dobrze się umówić jakie powinny być, a jakich tworzyć nie trzeba.

Warto spisywać kluczowe ustalenia dotyczące zmian w produktach, lub tworzonych funkcjonalności. Po każdym projekcie dobrze jest stworzyć podsumowanie. Powody nieźle opisuje UxBooth, choć trochę przesadza z ilością dokumentów. Ważniejsze niż spisywanie tego jest sprawienie, by rzeczywiście ktoś do tych zapisów wracał i ich użył. Na wyższym poziomie warto mieć spisaną strategię, wizję i jakąś roadmapę / backlog z postulowanzmi zmianami (pamiętając, że wielomiesięczna roadmapa zawsze jest fikcją). Ten ostatni to na szczęście nie literatura – raczej sztuka dzielenia, nazywania i priorytetyzowania rzeczy.

Jak robić duże redesigny?

Nie robić. Duże redesigny są trudne i rzadko się udają. Bardzo łatwo w nich o błędy projektowe i utratę kontroli nad zmianami. Nie jest jednak niemożliwe skuteczne przeprowadzenie takiego projektu. Co jest niezbędne by przebiegał sprawnie?

Ostatnio sporo dzieje się w temacie: zmiany na stronach Google, Allegro, Fotka.pl, Facebooka. Sporo można się nauczyć analizując projekt Google z 2011. Niedawno pisał o tym The Verge, całkiem sporo materiałów trafiło do sieci po zeszłorocznym SXSW. To ciekawy przypadek – korporacja, która natworzyła produktów, nie zawsze potrzebnych. I teraz równie bezsensownie czasem je zamyka (to już inna historia).

W styczniu 2011 Larry Page za pomocą kominikatora zapytał projektantów o pomysły na całościowy redesign. W kwietniu został szefem Googla i zdecydował, że chce mieć nowy wygląd na koniec lata. W 2007 Google podjęło już podobną próbę. Dzięki czemu tym razem się udało? Boldem zaznaczam istotne, uniwersalne czynniki, które pomogły.

Po pierwsze zaangażowanie osoby u szczytu rozumiejącej temat (Larry Page już na studiach czytał D. Normana). To powoduje zmianę priorytetów i wymusza współpracę. Pomaga też narzucony deadline. Zespoły musiały współpracować, inaczej nie byłby możliwy do osiągnięcia. Terminy, niekoniecznie wariackie, dobrze robią projektom.

Wygląd projektował silny zespół centralny, który nie był związany z żadnym produktem. Projektanci nie musieli rozpatrywać specyficznych problemów tych produktów. To uprościło podejmowanie decyzji. Na prezentacjach projektanci żartowali, że używali argumentu “ponieważ Larry tak chce”. Żarty żartami, ale konieczność uzyskiwania zgód potrafi paraliżować. Powinien ją przełamywać ktoś, kto naprawdę poniesie odpowiedzialność za decyzje. W sam raz zajęcie dla CEO firmy produktowej.

Zespół zadbał o to, by zmiany były wdrażalne. Ustalił, jak może wyglądać minimalny zestaw zasad, które mają zastosować wszyscy. By ułatwić wdrożenia stworzył w html/css działające prototypy produktów. Nie tworzył więc w abstrakcji od materiału. Dzięki prototypom programiści i projektanci w zespołach produktowych w 3 miesiące wprowadzili nową wersję searcha, map, gmaila i kalendarza. Nawet Google+ zdążyło przerobić swoje produkty tuż przed premierą. Zmiany były robione niezależnie, ale w tym samym kierunku.

Ciekawy jest harmonogram, który można znaleźć na jednym ze slajdów na temat projektu. Wiele prac toczy się w nim równolegle. Projektowanie rusza w kwietniu, w jego trakcie zaczynają się przygotowania do implementacji. Zespoły pracują nad nią od początku czerwca, a już od lipca zaczynają się pierwsze wdrożenia i testy. Kolejne etapy zaczynają się najwcześniej jak się da. To co powstało było niezależnie wdrażane w zespołach produktowych. Samodzielne zespoły dla każdego produktu + odpowiedni priorytet – projekt miał wystarczające zasoby.

Co jest ważne: zmiany dotyczyły jednego aspektu, wyglądu. Łączone ze zmianą sposobu działania (tak jak np. w Allegro) mogłyby się nie udać. To jeden z najcześciej popełnianych błędów. Nie powinno się robić takich rzeczy, zwłaszcza, gdy są duże. Dlaczego? Warto poznać tę prezentację Etsy.

Historia pokazuje, jak taki redesign można przeprowadzić sprawnie. To nie jest uniwersalny przepis na to, jak go zrobić dobrze. Tego, czy jest sukcesem nie wiem. Te strony ciągle są modyfikowane – nie analizuję tego dokładnie, ale mam wrażenie, że dokonania projektantów już się rozjeżdżają. Warto pamiętać, że takie projekty łatwo się nie kończą. Zmiany w Google jeszcze trwają i z pkt widzenia użytkowników nie zawsze oznaczają poprawę.