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.

O pisaniu

Jakiś czas temu stwierdziłem, że z trudem notuję długopisem. Robiłem to tak rzadko, że się odzwyczaiłem. Postanowiłem to zmienić. Dla wygody przerzuciłem się z długopisu na cieńkopis , potem wróciłem do pióra. Notuję i dobrze mi z tym.

U Kapuścińskiego znalazłem cytat z Schopenhauera. Radził, żeby zapisywać rzeczy i obserwacje. Coraz więcej ludzi to robi. Zauważyliście? Co oni piszą w tych swoich moleskinach?

Podejrzewam, że wpisują kolejne zadania do wykonania. Ale nie wszyscy. Znajomy, bardzo skuteczny szef, trzyma notes na stoliku przy łóżku. Czasem notuje w nocy: „zapisuję pomysły, gdy tylko przyjdą mi do głowy”. Nie przypominam sobie, żeby kiedyś nie miał zbyt wielu pomysłów.

Inny znajomy wpisuje w swoim notesie rozwiązania. Również trzyma go przy łóżku w nocy. Lubi mieć go przy sobie i używa, gdy wymyśli jak coś zrobić. Wie „co”, nie wie „jak” – nad tym pracuje. To samo narzędzie, inne zastosowanie.

Sam zapisuję kawałki z książek i obserwacje, które mam nadzieję kiedyś wykorzystać. Ostatnio zapisałem, że 85 procent programowania w pierwszych latach Amazon dotyczyło rzeczy, których wogóle nie widzi użytkownik. Wpisuję tak notatki z prawdziwych książek, fragmenty z elektronicznych zbieram w Google Docs.

Zanotowałem też, że pisanie ułatwia myślenie i rozwiązywanie problemów. Powoduje, że lewa półkula mózgu, ta logiczna, współpracuje z prawą, tą odpowiedzialną za wyobraźnię. To pomaga.

Jest jeszcze jeden powód, dla którego warto mieć notes przy łóżku. Pozwala on na lepszy sen. Gdy coś Cię gnębi i nie pozwala zasnąć, weź notes, zapisz to. Będzie łatwiej, pisanie oczyszcza.

7 godzin na pracę – jakie są korzyści z zebrań

Jak napisałem – jeśli działamy w organizacji, zwykle czasu na normalną pracę zostaje nam niewiele. Wynikają z tego dobre i złe rzeczy.

Po pierwsze – czasu jest mało i warto o niego dbać. Trzeba walczyć z natłokiem korespondencji i nieproduktywnych spotkań. Zaczynać od siebie, by nie pomnażać bałaganu. Bicie piany w realu i programie pocztowym to zło, coś do czego zmusza nas otoczenie.

Jest też element pozywytny. Tak niewiele w sumie pracujemy, a jednak coś powstaje. Kolejne produkty, czasem sensownie działające strony. Okazuje się, że tak naprawdę niewiele potrzeba, by powstały. Jeśli odzyskamy więc ten zmarnowany czas, możemy albo zrobić więcej, albo.. mieć go dla siebie.

Wątek poboczny – 8 godzin pracy dziennie, które przyjąłem jako podstawę obliczeń. Spotkałem się z opiniami: T, a kto pracuje 8 godzin? Nie piszę o 10, bo przede wszystkim na 8 zwykle umawiamy się z pracodawcą – wynika to w szczególności z prawa pracy. Druga sprawa – ze zwiększania czasu pracy zwykle nie wynika nic pożytecznego… Nie ma niczego imponującego w tym, że ktos nie potrafi poradzić sobie z tym co jest do zrobienia w ośmiu. Nie ma nic bohaterskiego w tym, że ktoś nie chodzi na urlop i nie spędza czasu z bliskimi…