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.

Nokia: jak UX wykończył Symbiana

Jedno z najważniejszych wydarzeń początku tego roku to decyzja Nokii, by porzucić rozwój Symbiana na rzecz współpracy z Microsoftem. Właśnie ma miejsce akt drugi – fiński producent zdecydował się przekazać R&D Symbiana do Accenture. http://news.cnet.com/8301-30685_3-20057772-264.html
Do tej pory nie zajmowałem się tematem telefonów, ale przy okazji tego wydarzenia odrobiłem zadania domowe i dotarłem do ciekawych opinii. Warto się z nimi zapoznać. Wygląda na to, że do końca Nokii przyczyniła się kultura organizacji i design. Żeby zrozumieć, warto przestudiować  linkowany artykuł i podążyć za umieszczonymi w nim linkami. Oto moje krótkie wnioski.
Po pierwsze Symbian miał szansę być trzecią siłą na rynku, ale została zaprzepaszczona przez fatalne decyzje dotyczące rozwoju technologii. Tracimy dojrzały system, który lepiej obsługiwał telefony niż konkurencja, zapewniając jakość rozmów i efektywne użycie baterii.
Kluczowy element, którym został pokonany Symbian to UX. System Appla i Android oferowały spójne interfejsy dla użytkownika, elastyczność i lepsze możliwości dla developerów aplikacji. Nokia w koszmarny sposób próbowała dogonić konkurencję. W pewnym momencie rozwijała swój system  równocześnie w dwóch złych kierunkach.
Tu niemal dosłowny cytat z Marka Wilcoksa, specjalisty, autora książek o Symbianie, kiedyś pracownika Nokii. Inżynierowie Nokki – jakkolwiek kompetentni – nie znali się na projektowaniu API dla zewnętrznych developerów. Równocześnie – jak większość inżynierów – nie wiedzieli jak budować interfejsy użytkownika. Robili natomiast obie rzeczy.
Zasady rządzące interfejsem użytkownika wyprowadzane były z kodu systemu, który go obsługiwał. To trochę tak jak projektować karoserię samochodu biorąc pod uwagę tylko sposób działania silnika.
http://mobilesoftware.tumblr.com/
Nokia osiągnęła spektakularny sukces, stając się niemal ikoną europejskiego sukcesu w nowych technologiach. Zbudowała niezwykle efektywną organizację wokół produkcji i sprzedaży słuchawek. Jej kulturze obcy był rozwój oprogramowania i UI (co nie znaczy, że stworzyła kilku ciekawych produktów i nie zatrudniała ludzi świetnie rozumiejących design).
Co gorsza, decyzja o porzuceniu Symbiana nastąpiła w momencie, w którym w zasadzie wszystko już zostało odkręcone.

Jedno z najważniejszych wydarzeń początku tego roku to decyzja Nokii, by porzucić rozwój Symbiana na rzecz współpracy z Microsoftem. Właśnie ma miejsce akt drugi – fiński producent zdecydował się przekazać R&D Symbiana do Accenture.

Do tej pory nie zajmowałem się tematem telefonów, ale przy okazji tego wydarzenia odrobiłem zadania domowe. Wygląda na to, że do końca Nokii przyczyniła się kultura organizacji i design. Żeby zrozumieć, warto przestudiować ten artykuł i podążyć za umieszczonymi w nim linkami. Oto moje krótkie omówienie.

Po pierwsze Symbian miał szansę być trzecią siłą na rynku, ale została ona zaprzepaszczona przez fatalne decyzje dotyczące rozwoju technologii. Tracimy dojrzały system, który lepiej obsługiwał telefony niż konkurencja, zapewniając jakość rozmów i efektywne użycie baterii.

Kluczowy element, którym został pokonany Symbian to UX. System Appla i Android oferowały spójne interfejsy dla użytkownika, elastyczność i lepsze możliwości dla developerów aplikacji. Nokia w koszmarny sposób próbowała dogonić konkurencję. W pewnym momencie rozwijała swój system równocześnie w dwóch złych kierunkach.

Tu niemal dosłowny cytat z Marka Wilcoksa, autora książek o Symbianie, kiedyś pracownika Nokii. Inżynierowie firmy – jakkolwiek kompetentni – nie znali się na projektowaniu API dla zewnętrznych developerów. Równocześnie – jak większość inżynierów – nie wiedzieli jak budować interfejsy użytkownika. Robili natomiast obie rzeczy. Zasady rządzące interfejsem użytkownika wyprowadzane były z kodu systemu, który go obsługiwał. To trochę tak jak projektować karoserię samochodu biorąc pod uwagę tylko konstrukcję silnika.

Nokia osiągnęła spektakularny sukces, stając się ikoną europejskiego sukcesu w nowych technologiach. Zbudowała niezwykle efektywną organizację wokół produkcji i sprzedaży słuchawek. Jej kulturze obcy był rozwój oprogramowania i UI (co nie znaczy, że stworzyła kilku ciekawych produktów i nie zatrudniała ludzi świetnie rozumiejących design).

Co gorsza, decyzja o porzuceniu Symbiana nastąpiła w momencie, w którym w zasadzie wszystko już zostało odkręcone.