Jak ustalić priorytety?

Zespoły nie są w stanie skutecznie zajmować się wieloma sprawami jednocześnie. Skupienie pomaga, dlatego warto minimalizować ilość “pracy w toku”. To, czym się zajmujemy powinno wynikać z większego planu i założonej w nim kolejności działań – z przyjętych priorytetów.

Plany produktowe to najczęściej pogoń za ficzerami, które ma konkurencja. Można rozwój produktu prowadzić ad hoc, ale dobrze się to nie kończy. Gdy po roku prowadzonych w taki sposób prac spojrzy się wstecz, widać, że nic istotnego się nie wydarzyło. Co więc jest potrzebne by dobrze ustalać priorytety?

Lista spraw. Priorytetyzowanie to określanie ważności rzeczy względem siebie. Dowolne dwie możemy porównać i stwierdzić, którą zająć się wcześniej lub która jest ważniejsza (to nie to samo). By zacząć potrzebna jest jakakolwiek lista.

Co priorytetyzować? Jeśli kogoś poprosicie o listę priorytetów rozwojowych dla jego produktu, pokaże spis funkcjonalności, które chce wdrożyć. Tymczasem powinny to być problemy jakie chce rozwiązać. Zawsze łatwiej stwierdzić, że chcemy wdrożyć niebieski przycisk niż zdefiniować jaką potrzebę ma zaspokoić.

Elementy listy. Priorytetyzowane rzeczy powiny być mieć podobny ciężar gatunkowy i być w podobny sposób opisane. Nie należy zestawiać postulatów naprawy drobnych uciążliwości z potrzebami systemowych zmian. Czasem warto je zebrać w dwie – trzy grupy, w zależności od tego, czego dotyczą i kogo będą angażować.

Ile spraw? Liczba musi przekraczać nasze możliwości realizacyjne. Jeśli jest ich nieco za dużo, mamy konkurencję. Jeśli lista będzie przekraczała niezbyt magiczną liczbę 20, będzie demotywująca. Komfort związany z bardzo krótką listą jest zły – oznacza brak wyboru.

Kolejność. Jak układać taką listę? Prywatną można nawet alfabetycznie. Czasem będzie to bardziej korzystne niż gdyby wynikało tylko z subiektywnej atrakcyjności. Indywidualne prefencje w biznesie są mało praktyczne.

Jak więc sortować? Warto dla wszystkich pozycji użyć miar, co pozwoli uzyskać kolejnośc, w której mamy najlepszy stosunek oczekiwanych korzyści do szacowanych kosztów. Równocześnie należy zapewnić żeby ważne i trudne rzeczy nie były odkładane w nieskończoność – czasem może być konieczne podzielenie ich na więcej drobnych tematów.

Aktualizacja. Lista powinna być regularnie weryfikowana. To co dziś wydaje się ważne, za miesiąc może już takie nie być. Najbardziej atrakcyjne wydają nam się rzeczy, które właśnie do listy dołożyliśmy – im najlepiej dać chwilę czasu, żeby dojrzały, zamiast z dnia na dzień zmieniać harmonogramy.

Tyle teoria. By ją uzupełnić warto zobaczyć proste drzewo decyzyjne dla użyteczności oraz przeczytać o priorytetach na tynerblain.com a także na Svpg.com.

Para idzie w kod

Ciekawe statystyki prac nad nowym serwisem PKO BP podało na Facebooku K2. Cytuję za UXlabs:

  • 1.100 h pracy działów Strategii, Design i UX
  • 1.500 h poświęconych na analizę
  • 11.000 h pracy działu IT
  • 700 h poświęconych testom jakości
  • 700 h pracy content edytorów
  • 2.800 h pracy działu Client Service

Jak widać największa część to praca nad kodem i wdrożeniami (dział IT). Jest potraktowana jak monolit, ale w przeciętnym projekcie czas programowanie + przystawki oscyluje w okolicach 75 proc. całości. Dane podane są w kolejności prac. Niektórzy drugą część – analizę, w której określa się jak zaprogramować to co zostało zaprojektowane – wliczają w część IT. Podobnie z testami jakości. Stąd to 75 proc. a nie 61 jak w tym zestawieniu.

Tak jest w w zdecydowanej większości projektów np. u nas, w Gazeta.pl. Podobnie wygląda w dowolnym projekcie rozwojowym, z którego statystykami się spotkałem. Ktoś mógłby powiedzieć „w bankach jest inaczej”, powyższe dane jednak pokazują, że w zasadzie jest tak samo. Dowolna rzecz, która trwa miesiąc lub więcej, w której powstają nowe rozwiązania, składa się przede wszystkim z programownia albo oczekiwania na efekty pracy programistów.

Prace IT pozostają największym kosztem w tego typu projektach. Najwięcej można zyskać dobrze nimi zarządzając i monitorując postępy w tej części – np. dzieląc całość na mniejsze kawałki, które można wdrażać niezleżnie. I na milion jeszcze innych sposób – ale nie o tym tu.

Równocześnie – i to strasznie ważne – wartość z projektu powstaje na początku. W pierwszych składowych projektowane są rozwiązania i tu zapadają decyzje jak czas programistów zostanie „wydany”. To pokazuje jak istotne jest podejmowanie decyzji i projektowanie (które w dużym stopniu jest podejmowaniem decyzji).

Mamy te same pomysły, rzadko mamy dobre rozwiązania

Jeśli myślisz, że idea ma wartość, spróbuj ją sprzedać – pisali autorzy Rework. Zwykle przeceniamy pomysły. Wielu nie chce podzielić się „pomysłem na biznes” bojąc się, że ktoś na nim zarobi. 

Gdyby pomysły były tak cenne, to musiałoby ich być mało, rzadko kto by je miewał. Często mielibyśmy do czynienia z pomysłami, na które nikt nigdy wcześniej nie wpadł. Tak nigdy nie było. William F. Ogburn i Dorothy Thomas już w 1922 roku stworzyli listę 150 odkryć, których niemal równocześnie dokonały różne osoby. Ich wniosek: znajomość aktualnego stanu wiedzy i wyników prowadzonych badań tworzy możlwości, których twórcze wykorzystanie nie jest niczym wyjątkowym.

Marconi był znany jako wynalazca radia mimo, że patenty związane z tą technologią wcześniej uzyskał Nicola Tesla. Spór o autorstwo trwał w tym przypadku ponad 40 lat. Został rozstrzygnięty na korzyść Tesli, ale zapytajcie 10 osób o to, kto wynalazł radio.

Podobnie jest w świecie biznesu i start-upów. Bez względu na to, jak błyskotliwa i odkrywcza wydaje się nam idea, na którą właśnie wpadliśmy, wielu miało ją przed nami. I albo jej nie zrealizowali, albo jeszcze realizują, albo zrealizowali i nic o tym nie wiemy. 

Czy należy się tym zrażać? Niekoniecznie. Nigdy nie jest za późno i zawsze można skuteczniej i lepiej zrobić coś, co wcześniej próbowali inni. To nie oryginalne pomysły decydują, ale dobre rozwiązania. Bo naprawdę cenne są pomysły na rozwiązania proste, intuicyjne, efektywne…

O ciężki losie korpo projektantów

Maciej na uxdesign.pl ciekawie napisał o tym, jak ciężko jest o dobre projektowanie w korporacjach. Trzy słowa o tym co z tego wynika:

1. Nie wystarczy umieć narysować. Projektant America Airlines miał świetne szkice sajtu w szufladzie, ale nie był w stanie ich wdrożyć, bo wszystko komplikowała korporacja.

2. Zwracam uwagę na fragment: „Kto nie brał udziału w całodniowych spotkaniach projektowych, w których uczestniczy 15 osób po stronie klienta…”. Takie spotkania to zło w postaci czystej. Zło dla projektu. Najgorsze jest to, że wszyscy ci ludzie chcą dobrze i każdy z nich na swoim blogu mógłby napisać to samo o swoim losie.

3. Największe znaczenie ma jednak realizacja. Ona zależy od tego jak w firmach tworzone są grupy projektowe, jak zorganizowana jest ich praca. Jaki mają rozmiar, możliwości podejmowania decyzji.

4. Nie wystarczy stworzenie małych zespołów. Kluczowe jest to, co potrafią ich członkowie – czy naprawdę rozumieją, albo wiedzą jak sprawdzić, jakie są wszystkie konsekwencje ich decyzji.

5. Wiedza co najmniej połowy tzw. branży UX jest oderwana od rzeczywistości realizacyjnej w korporacjach. Ta rzeczywistość spowodowana jest rozmiarem. Rozmiar komplikuje – o tym, że ze wzrostem trudno utrzymać szybkość wiedzą nawet w Google.

6. Z drugiej strony co najmniej połowa korporacji (ale też start-upów) nie ma pojęcia o UX i projektowaniu, więc jest co poprawiać. Jeśli ktoś potrafi to wszystko robić ma gigantyczną przewagą konkurencyjną. Bez niej nie byłoby sukcesów Apple i Amazon.