Produktywna paranoja

Czytam znakomitą książkę o prowadzeniu biznesu: Great by Choice. Autorzy opisują cechy wspólne twórców firm, które osiągają stabilny wzrost. Rzecz jest logiczna, świetnie udokumentowana i bardzo dobrze napisana. Raczej jest to opowieść niż biznesowa nuda. Nie ma przy tym lania wody – polecam.

Jednym z czynników, które zidentyfikowali autorzy jest „produktywna paranoja”. Okazuje się, że najlepsi, bez względu na to jak dobrze rzeczy się mają, myślą o tym co może pójśc źle. Przytaczana jest historia memo, które Bill Gates napisał w 1991 roku. Wyciekło ono z Microsoftu i spowodowało spadek kursu jego akcji o 11 procent. Mówiło o tym, jak niebezpieczna jest przyszłość firmy i jakie zagrożenia na nią czekają. Żadna z opisywanych katastrof nie nastąpiła – takie po prostu było podejście Gatesa, który zawsze wyobrażał sobie co się może stać złego.

Ma to sporo wspólnego z budowaniem produktów i zarządzaniem projektami. Rzadko kiedy przejawiamy objawy produktywnej paranoi. Optymistycznie szacujemy czas, jaki zajmą nam różne rzeczy. Zakładamy, że wszystko się uda. Gdy ktoś obiecuje nam coś zrobić przyjmujemy to za dobrą monetę, nie pytając, co daje mu pewność, że rzeczywiście wyrobi się w terminie. Ślepo wierzymy, że wystarczy coś komuś opisać a on wykona to w najlepszy z możliwych sposobów. Potem dajemy się zaskakiwać rzeczywistości. 

Jedną z metod, którą można stosować by tego uniknąć jest pre-mortem. Zaczynając projekt trzeba spróbować.. podsumować go. Wyobrazić sobie, że się nie udał, znaleźć przyczyny klęski by potem spróbować ich uniknać. To alternatywny sposób ustalania odpowiedzi na pytanie „co może pójść źle”. To wielka sztuka postawić się w tej sytuacji i rzeczywiście znaleźć możliwe scenariusze porażki. Warto jednak próbować.

Zacznij od końca, naprawdę

Opisywałem kiedyś, jak podchodzi do tworzenia produktów Amazon. Zaczynając projekt piszą tam informację prasową, która mówi, co ich produkt da użytkownikowi.

Nie tylko u Bezosa stosują tę metodę. Niejaki Steve Jobs również bierze pod uwagę ”perspective of what was the user’s experience going to be”..

W świetnym artykule z Wired można przeczytać o tym jak powstawał Google Plus. Vic Gundotra, odpowiedzialny za działania G ”w socialu”, który nadzorował projekt ma podobną metodę. Zaczyna.. od wyobrażenia sobie demostracji, którą będzie prezentował na premierze produktu i na jej podstawie ”cofa się” do jego składowych.

Ktoś jeszcze wątpi w to, że warto zaczynać z wizją końca?

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.

Zarządzanie pomysłami – szkolenie o tworzeniu produktów

Jest pewien problem z ekspetami ds. użyteczności. Tylko nieliczni zajmują się produktami, w których tworzeniu uczestniczą. Świat, o którym można przeczytać na blogach o UX, wydaje się idealny (coraz więcej jest wyjątków). Na wszystko w nim jest czas, decyzje są racjonalne. Inna jest rzeczywistość.

Wynika to z modelu pracy. Projektanci czasem stanowią wydzieloną w firmie komórkę, czasem są wynajmowani, zwykle jednak ich zaangażowanie jest chwilowe. Są zatrudniani na czas projektu. Przychodzą, doradzają, wychodza. Opuszczają budynek lub przechodzą do następnych projektów gdy produkt ich pracy zostanie oddany w ręce użytkownika. Tymczasem to wtedy zaczyna się jego życie.

Pracuję na programem szkoleń (wewnętrznych), które obejmowałyby tematy związane z realizacją rozwoju produktu cyfrowego (nie wymyśliłem chwilowo lepszej nazwy) w całym cyklu jego życia – od pomysłu przez projektowanie do utrzymania. Realizacją rozwoju czyli wszystkim, co związane z wprowadzaniem zmian funkcjonalnych lub konstrukcyjnych w tym wszystkim, z czym ma styk użytkownik. Osią programu pozostanie projektowanie. Osadzone zostanie jednak w kontekście „projektowania” w organizacji.

Co mam na myśli:

Zarządzanie pomysłami

Podejmowanie decyzji

Planowanie i zarządzanie projektami

Utrzymanie

Część pierwsza to „Zarządzenie pomysłami”. Mówi o tym skąd się biorą pomysły i jak z nich wybierać to, czemu poświęcić siły. Przygotowałem następujące punkty, które opisują tę cześć szkolenia.

  • Mit pomysłu (pomysły, czy realizacja)
  • Eksplozja idei – dlaczego dzisiaj mnożą się pomysły
  • Skąd się biorą pomysły – kreatywność, inspiracje pracowników, użytkowników, klientów
  • Czym staje się pomysł – droga do innowacji i produktów
  • Pomysł – cykl życia
  • Trudna sztuka zadawania pytań – jak dotrzeć do sedna sprawy
  • Najważniejse pytania:
    • Dlaczego. Po co?
    • Jak będzie, gdy się uda?
    • Co musi być zrobione?
    • Od czego zacząć?
  • Pomysł w produktach cyfrowych
  • Rysowanie – czy obrazek nadal wart jest 1000 słów
  • Co trzeba zrobić – różne typy problemów
  • Pierwszy krok – jak priorytetyzować
  • „Robimy” – znaczenie decyzji

Opinie i wszelkie skojarzenia, jakie budzą te punkty, mile widziane.