|
czwartek, 12 stycznia 2012
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ć.
środa, 17 sierpnia 2011
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?
czwartek, 28 kwietnia 2011
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.
poniedziałek, 13 grudnia 2010
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.
Opinie i wszelkie skojarzenia, jakie budzą te punkty, mile widziane.
środa, 25 sierpnia 2010
|