Soft

Jak programista widzi świat?

Posted on by Maciej Etgens / 4 Comments

Drugim postem na swoim blogu postanowiłem wejść wszystkim programistom do ich głów i zrobić swoistą psychoanalizę postrzegania przez nich rzeczywistości.

Czemu nie? 🙂 Zrobię to na przykładzie fikcyjnych dialogów, fikcyjnych deweloperów na fikcyjnym spotkaniu.

Oczywiście nie mam ku temu żadnego wykształcenia. Jestem deweloperem jak wielu innych, obdarzonym umysłem ścisłym, patrzącym logicznie i racjonalnie na otaczający go programistyczny świat i problemy z jakimi zmagam się na co dzień. Ale czy na pewno, tak bardzo racjonalnie jak mi się wydaje?

Jak działa umysł?

Szybko. Ilość informacji, którą nasz mózg otrzymuje na wejściu jest ogromna. Gdyby chciał to wszystko przetwarzać i analizować wyniki jego pracy przestały by być efektywne. Podobno to kwestia ewolucji. Gdy coś zaszeleściło w prehistorycznych krzakach, nasz pra-pra-…-pradziadek (dajmy na to homo erectus) nie miał czasu na zastanawianie się “czy to aby nie tygrys?”. Aby przetrwać, lepiej dla niego było podjąć decyzję szybko, czyli po prostu schrzaniać gdzie pieprz rośnie. Może to kwestia ewolucji, może nie, ale musimy się pogodzić z tym, że nasz umysł opiera swoje działanie na skrótach myślowych. Właściwie powinniśmy mu być za to wdzięczni. To jest jego fantastyczna cecha.

W ciągu sekundy ludzki umysł otrzymuje około 11 milionów bitów informacji pochodzących z naszych zmysłów (źródło Britannica). Zakładając, że przeciętny człowiek potrafi przeczytać ze zrozumieniem 5 słów na sekundę, daje nam to prędkość świadomego przetwarzania informacji na poziomie 50 bitów/sekundę. Można zauważyć jaką niewiarygodną pracę wykonuje nasz mózg filtrując i kompresując informacje wejściowe do poziomu akceptowalnego przez świadomość.

Ta jego fantastyczna cecha ma jeden mały minusik. Wczesniej wspomniane skróty myślowe niestety prowadzą do błędów… tzw. błędów poznawczych.

Przejdźmy do przykładu.

Fikcyjna rozmowa fikcyjnych deweloperów – pełna błędów poznawczych

W moim fikcyjnym spotkaniu bierze udział grupa deweloperów. Każdy z nich jest innym człowiekiem, z innym bagażem doświadczeń, innym temperamentem. Patrząc na obrazek poniżej, to raczej startup niż korporacja 😉

 

A nasza rozmowa mogłaby się rozpocząć np. tak:

Mamy zamówienie na wykonanie nowego dużego sklepu internetowego… zamówienia, płatności, dostawa, magazyn.

Super! Zrobimy to w końcu na mikroserwisach! Użyjemy tej szyny komunikatów, o której wam ostatnio opowiadałem i deployujemy na Azurze.

Jak widać nasz Dev1 to dynamiczny programista, wie jakie są trendy w programowaniu. Teraz każdy deweloper, dbający o ostrość swojej piły, robi w mikroserwisach i w chmurze. A jeżeli już mowa o trendach, w psychologii poznawczej istnieje pojęcie tzw. zasady podczepienia, czy też mówiąc prostym językiem, owczego pędu.
Zasada podczepienia (ang. bandwagon effect) mówi, że ludzie często wierzą w pewne rzeczy lub robią je jedynie dlatego, że wiele innych osób tak robi. Najczęściej mówimy o tym zachowaniu w odniesieniu do polityki lub marketingu. Nie od dziś wiadomo, że my – konsumenci kupujemy częściej konkretne produkty tylko dlatego, że inni też tak robią. A my – programiści? Jak to wygląda w naszym świecie? Otwierasz facebook’a lub twitter’a a tam mikroseriwsy, serverless, DDD albo chmura 🙂 Idziesz na konferencję, meetup’a a tam… to samo 🙂 Śmiem twierdzić, że pojęcie mody i trendów jest tutaj bardzo mocno widoczne.

I co na to nasz mózg? I co na to mózg naszego Dev1?

Pozostawię to pytanie (jak i wiele innych) bez odpowiedzi, do przemyślenia przez każdego z Was. Wróćmy do rozmowy.

Nie wiem czy mikroserwisy są najlepszym pomysłem. Zobaczycie, na tych powiązaniach, dziesiątkach baz, debugowaniu tego wszystkich po prostu polegniemy. Zróbmy po staremu, tak jak wcześniejszą aplikację. Przynajmniej wiemy, że działało. A przy okazji starego projektu napisałem świetny system do zbierania metryk! Wykorzystamy go. Od strzała będziemy mieli zagregowane dane: czasy odpowiedzi, metryki systemu.. cud, miód.

Co ty gadasz ?! Mikroserwisy zapewniają lepszą skalowalność, mogą być rozwijane niezależnie i łatwiej wdrażane na produkcję. Ta aplikacja będzie duża i składała się z kilku modułów. Mikroserwisy pasują tutaj idealnie.

Nasz nowy bohater – Dev2 to bardzo racjonalny programista. Stawia na sprawdzone rozwiązania. Jak jest sprawdzone to będzie działać, a jak będzie działać to ‘mission accomplished’. Czyżby? A może jego umysł działa pod wpływem dwóch małych robaczków: efektu Ikea i efektu status quo.

Efekt Ikea – to błąd poznawczy, który sprawia, że większą wartość przypisujemy rzeczom, w wykonaniu których mieliśmy swój udział. Nazwę swą zawdzięcza oczywiście szwedzkiemu producentowi mebli i poczuciu satysfakcji, które ponoć ogarnia nas po złożeniu tych cudownych szafek i łóżek 🙂 Trud włożony w ich składanie zwiększa nasze przywiązanie do nich. Tak samo trud włożony w dewelopment danego kawałka aplikacji może zmienić nasz sposób jego postrzegania.
Efekt status quo – to z kolei tendencja do zachowania aktualnego stanu rzeczy. Podświadomie budzi w nas lęk przed zmianą. Zmiana traktowana jest przez nasz umysł jako strata, szkoda. I tu z kolei na scenę wchodzi kolejny błąd poznawczy – niechęcią do straty. Pociąga on za sobą nadmierną ostrożność przy ryzykowaniu utraty czegoś, co się już posiada, np. wypracowanej i sprawdzonej architektury aplikacji, którą teraz będziemy stosować do każdego nowego projektu, żeby nie narażać się na wspomniane ryzyko.

Z drugiej strony Dev1 całkowicie zafiksował się na punkcie mikroserwisów. W końcu dobrego rozwiązania trzeba bronić do upadłego. A może to wpływ: efektu potwierdzenia?

Efekt potwierdzenia (ang. Confirmation bias) – to skłonność do wybierania tylko tych informacji i argumentów, które potwierdzają wcześniej przyjęte przekonania i pomijania tych, które im zaprzeczają. Wpływa na obniżenie skłonności do zmiany decyzji. Nawet gdy nasza decyzja jest obiektywnie błędna będziemy się starać szukać dowodu, że tak nie jest. Niejednoznaczne informacje interpretować w taki sposób aby nagiąć je do naszego stanowiska.

Może Dev1 wybiera tylko cechy nowego projektu, które faktycznie pasują do mikroserwisów? Może patrząc na mikroserwisy, podświadomie marginalizuje ich wady?

Dev2, a to Twoje zbieranie metryk ostatnio nie wywaliło się na produkcji?

W myślach: Jak wszystkie twoje aplikacje, zawsze musimy sprzątać po Tobie.

O takie uwagi bardzo łatwo podczas gorących dyskusji. Zwłaszcza gdy w naszej głowie hasa sobie tzw. efekt aktora-obserwatora. Co prawda  system metryk faktycznie wywalił się ostatnio na produkcji, ale w historii firmy komponenty Dev1 też miały swoje problemy. Te jednak w głowie Dev1 były zawsze dziełem złego zrządzenia losu lub efektem złych założeń złego biznesu 🙂 Może tak, a może to właśnie efekt aktora-obserwatora?

Efekt aktora-obserwatora (ang. Actor-Observer Bias) – to asymetria w postrzeganiu działań w zależności czy są to nasze działania, lub działania w których bierzemy w nich udział, czy tylko je obserwujemy. Nasz umysł ma tendencję tłumaczyć cudze zachowania cechami danej osoby, natomiast podobne nasze zachowania tłumaczyć wpływem czynników zewnętrznych. Jak często pojawia Ci się np. w głowie myśl.. ale on to długo pisze, ja bym to napisał 2 razy szybciej. Jak można być tak mało wydajnym programistą?! A może właśnie wtedy trzeba popatrzeć na szerszy kontekst

Nie mamy doświadczenia w mikroserwisach. Czy to nam nie zajmie za dużo czasu? Zdążymy z terminami?

Samą architekturę postawimy w 2 tygodnie ! A potem już kopiuj/wklej i implementacja logiki biznesowej tak jakbyśmy pisali po staremu.

Taak.. patrząc z boku to od razu wygląda jak złudzenie.. złudzenie planowania.

Złudzenie planowania (ang. Planning fallacy) – jest tendencją do niedoceniania czasu, ryzyka, kosztów potrzebnych na ukończenie zadania. Często padamy ofiarą tego błędu, znając historyczne dane, które mogą przeczyć naszym założeniom. Powodem jest nadmierny optymizm, opieranie założeń na scenariuszu, w którym wszystko przebiega bezproblemowo, bez nieprzewidzianych trudności. Tylko, czy tak wygląda praca programisty?

Zróbmy te mikroserwisy ! Oglądałem świetne video o tym jak to zaimplementować. Po spotkaniu siądę i szybko zrobię Proof of Concept!

Dev3 musi działać. Jego jestestwo jest podyktowane ilością napisanego kodu. Nie widzi zagrożeń wynikających z podjętej decyzji, ale widzi już otwarte IDE, w którym zakłada nowy projekt. Może w jego głowie ukrył się mały robaczek o nazwie: action-oriented bias

Action oriented bias – powoduje powstanie w naszych głowach presji działania. Ta presja wywołuje w nas nadmierny optymizm co do otoczenia w jakim działamy. Sprawia, że pomijamy wpływ środowiska i zdarzeń losowych na efekty naszych działań.

Dev4, a Ty co o tym sądzisz?

Tak, zróbmy mikroserwisy.

W myślach:A może jeszcze za wcześnie na wybór architektury, może należałoby skupić się na wymaganiach, na potrzebie klienta. Ale co ja wiem, chłopaki wiedzą co robią.

Ciekawe podejście pojawiło się w głowie naszego Dev4. Niestety nie zostało ono wyartykułowane. Może stało się tak, dlatego, że umysł Dev4 został zmanipulowany przez efekt Dunninga-Krugera?

Efekt Dunninga-Krugera – jest błędem poznawczym, który sprawia, że osoby o niskich kwalifikacjach w danej dziedzinie mają tendencję do przeceniania swoich umiejętności. Z drugiej strony zaś, osoby wysoko wykwalifikowane mocno zaniżają swoja ocenę. Może to przejawiać się brakiem pewności siebie. Co z kolei może prowadzić do konformizmu społecznego, czyli chęci podporządkowania się poglądom obowiązującym w danej grupie społecznej.

Czy każdy nasze zachowanie powinniśmy tłumaczyć nieracjonalnością naszego umysłu? Podsumowanie.

Lista błędów poznawczych jest dużo dłuższa. Ja wybrałem te, z którymi sam walczę w swojej głowie (na prawdę to napisałem?;). Jednym z błędów, o którym nie napisałem, jest efekt ślepej plamki, czyli niezauważania błędów we własnej ocenie rzeczywistości. A z drugiej strony, nie trzeba wiele wysiłku, żeby każde nasze zachowanie wytłumaczyć jakimś błędem poznawczym. I jak tu żyć?

Myślę, że to kwestia szczerości, z samym sobą, przeanalizowania bez emocji naszych zachowań z przeszłości. Zastanowienia się, dlaczego zachowaliśmy się tak a nie inaczej. Na ile to zachowanie było nieracjonalne i jakie były jego skutki. Skupmy się na faktach. Spytajmy się innych osób jak wyglądamy w ich oczach. Gdy będziemy świadomi naszej tendencji do ulegania błędom poznawczym będziemy mogli z nią walczyć.

Ale o tym kolejnym razem.

Jeżeli podobał Ci się ten post, proszę napisz mi o tym. Będzie mi też super miło jeżeli udostępnisz go swoim znajomym.. programistom, nieprogramistom.. wujkowi, cioci 🙂 Każdemu, komu może on dać wartość.
Design

Design thinking, co to jest?

Posted on by Maciej Etgens / 1 Comment
Czy programista powinien zajmować sobie głowę design’em? A co to jest ten design? Design patterns – wiadomo znamy, szanujemy. 🙂 A design thinking to co to takiego? 
 
Sam osobiście na temat natknąłem się dosyć przypadkowo. Na tyle mnie on zaciekawił, że postanowiłem pogłębić wiedzę z tego zakresu. Między innymi udało mi się wziąć udział w warsztatach prowadzonych przez Google i PFR. Chciałbym się podzielić z Wami moimi przemyśleniami. Przy okazji jest to mój coming out, czyli początek przygody z blogowaniem.

Definicja

Przeszukując Internet można natrafić na kilka definicji. Design thinking to metoda twórczego rozwiązywania problemów. Design thinking to usystematyzowany iteracyjny proces.
 
Wg Hasso-Plattnera z Institute of Design at Stanford proces ten można podzielić na pięć etapów:
  • empatia
  • zdefiniowanie problemu,
  • pomysły,
  • prototypy,
  • testy.
Na warsztatach prowadzonych przez Google został zaproponowany trochę inny podział. Mianowicie:
  • focus on the user,
  • think 10x
  • be prototype driven.
Z mojej perspektywy design thinking to połączenie w pewien ciąg rzeczy oczywistych, które są przez nas podświadomie marginalizowane w pędzie wytwarzania końcowego rozwiązania. 

A wszystko zaczyna się od pomysłu

Żyjemy w czasach Startup’ów. Jesteśmy bombardowani tysiącami pomysłów i ich realizacji. To sprawia, że w naszych głowach tych pomysłów również nie brakuje. Sam osobiście mam spisaną listę kilkunastu rzeczy, które wpadły mi do głowy i czekają na realizację. To jest super. Co jest jeszcze super? To, że będąc programistami mamy jeszcze prościej, ponieważ od pomysłu do napisania pierwszych linijek kodu jest niedaleka droga. Szybki przegląd koncepcji i można zaczynać programować. Mam super pomysł, zarwę kilka nocek i… i tutaj jest chyba miejsca na cytat. 
 
You got an idea? And you know who thinks that’s a great idea? You.. You are the problem, you are a risk to be managed. 
Ed Hesse
No właśnie, według nas nasz pomysł zawsze wydaje się świetny. Jesteśmy emocjonalnie przywiązani do swojego dziecka.  Wróćmy teraz do design thinking. W design thinking te pierwsze linijki kodu, które już napisaliśmy to właściwie druga połowa całego procesu. Przeskoczyliśmy jego najważniejsze etapy. Bo w design thinking wszystko zaczyna się od problemu. Od problemu, który nasz pomysł rozwiązuje. Idąc dalej, za tym problemem stoją ludzie, jego adresaci. Nasz pomysł jest odpowiedzią na czyjąś potrzebę. W tym problemie, w tej potrzebie musimy się zakochać. 

“Zakochaj się w problemie, nie w rozwiązaniu” – focus on the user

 
Inwestycja powinna być poprzedzona badaniami, analizą rynku. Nawet jeśli w realizację pomysłu inwestujemy “tylko” czas. Czy to nie jest oczywiste? Jest. A teraz zastanów się, jak często zdarzało się, że wpadłeś/wpadłaś na jakiś pomysł rozwiązania i wszystkie znaki na niebie mówiły, że to jest to jedyne rozwiązanie. Ale czy na pewno wszystkie znaki? Czy podświadomie wybrałeś/wybrałaś tylko te, które potwierdzały Twoją tezę. To tak zwany “efekt potwierdzenia (confirmation bias)“. Bardzo często opieramy się na intuicji, a nie na faktach i rzetelnych analizach. 
 
Inny przykład. Często przystępujemy do tworzenia oprogramowania na podstawie specyfikacji. Ta specyfikacja jest niczym innym jak właśnie propozycją rozwiązania, której autorem jest jeden lub kilku architektów. A co jeżeli ona została stworzona wyłącznie na podstawie ich domysłów i jest obarczona tym samym “efektem potwierdzenia”. W tym przypadku sytuacja jest jeszcze gorsza, ponieważ programiści budują sobie obraz systemu patrząc na specyfikację. Nie mają często szansy dotrzeć do źródła, które za nią stoi. 
 
Tu z pomocą przychodzi design thinking, które mówi “focus on the user“. Zatrzymaj się, spróbuj zidentyfikować dla kogo tworzysz to rozwiązanie. Stwórz personę, która będzie identyfikować odbiorcę. Nazwij ją, opisz jakie ma problemy, jakie ma potrzeby, w jakim funkcjonuje środowisku. 

Przykład

Ciekawy przykład skupienia się na człowieku prezentował Paweł Tkaczyk w podcast’e Mała Wielka Firma. Firma Kruk (windykacja) postanowiła zbadać kim są ludzie, którzy zalegają z płatnościami. Czego Ci ludzie oczekują od firmy, która zajmuje się windykacją długów? Patrząc stereotypowo można wyciągnąć wnioski, że ci dłużnicy, patologia, złodzieje i pijacy, od tej firmy chcą najpewniej uciec jak najdalej. A jednak po przeanalizowaniu ankiet i wywiadów wyłania się obraz ludzi w znacznej mierze uczciwych, wstydzących się swojej sytuacji i chcących wyrwać się ze spirali długów. Firma Kruk wydrukował na ścianach zdjęcia i cytaty z wywiadów z tymi ludźmi, tak aby pracownicy nie opierali się na stereotypach, ale faktycznie poznali swoich klientów.

Jak poznać naszego odbiorcę?

Przede wszystkim trzeba chcieć :). Metod “researchu” jest wiele:
  • od pierwszych analiz przy biurku przed komputerem,
  • przeszukania for internetowych, grup w social-mediach, komentarzy pod blogami
  • poprzez wcielenie się w rolę klienta,
  • przeprowadzanie wywiadów, ankiet,
  • obserwację ludzi (tu najlepiej z ukrycia, ponieważ ludzie obserwowani mają tendencję do zmiany swoich zachowań).
 
Im bliżej jesteśmy człowieka tym lepiej. Wg współtwórcy Google, Larry’ego Page:
 
There is no substitute for personally watching and listening to real people.
W całym procesie ważne jest, aby opierać się na faktach, na prawdzie, a nie na naszych wyobrażeniach, czy intuicji. Prawda oszczędza pieniądze i czas.
 
Im więcej zbierzemy informacji, tym lepiej. Większa ilość zebranych danych przyspiesza kolejny proces: tworzenia pomysłów. Zespół analizując wyniki badań nie zastanawia się czy tak faktycznie jest, jeżeli dane mówią same za siebie. Ale pamiętajmy też, że tutaj nie chodzi o wygenerowanie statystyk, zestawień procentowych czy wykresów. Nie będziemy z nich robić sprawozdania dla zarządu. Zebrane dane mają uruchomić proces twórczego poszukiwania rozwiązania. W przypadku wątpliwości zawsze możemy wrócić do etapu “researchu” z nowymi konkretnymi pytaniami.
 
W całym procesie należy patrzeć szerzej, nie tylko pod kątem pierwotnego pomysłu. Być może ten szerszy kontekst już na tym etapie spowoduje rewizję pomysłu. Może pozwoli pchnąć go na inne tory. 
 
Etap “researchu” powinien zakończyć się konkretnym artefaktem. Wyniki naszych badań, teksty, zdjęcia powinny zostać przez nas przeanalizowane, pogrupowane i przedstawione w wygodnej i szybkiej do przyswojenia formie: map myśli, research wall’i. 
 
Po zapoznaniu się z naszym użytkownikiem i jego prawdziwymi problemami, możemy przystąpić do kolejnego etapu – generowania pomysłów.

I jeszcze raz pomysły

Pomysły najlepiej generować w grupie (choć można też samemu). Jeżeli podejdziemy do tematu grupowo, na jego początku zadbajmy o wprowadzenie wszystkich uczestników w temat. Uczestnicy powinni też być zmotywowani, czuć, że zostali wybrani do tego grona ponieważ ich pomysły są ważne!
 
Możemy wybrać różne metody generowania pomysłów ale jest kilka zasad, które bardzo nam pomogą w całym procesie.

Yes, and… Yes, but..

Próbujmy budować na pomysłach innych, nie krytykujmy ich. Nawet drobna krytyka spowoduje niepotrzbne napięcie i stratę czasu na dyskusję.  Na pierwszym etapie chodzi o wygenerowanie dużej ilości pomysłów. Nie na ich ocenie. Jeżeli pomysł kogoś innego nie przypadł nam do gustu… odpuśćmy. 
 
Jeżeli potrafimy jakiś pomysł rozwinąć, super, o to chodzi. Jeżeli ktoś rozwija nasz pomysł nie w tym kierunku, który pierwotnie sobie wyznaczyliśmy, nie krytykujmy go. Właścicielem, każdego pomysłu jest grupa, nie konkretna osoba. 

Quantity

Drogą do tego by mieć super pomysł jest posiadanie wielu pomysłów. Im więcej wygenerujemy pomysłów, tym większe prawdopodobieństwo, że znajdziemy w nim naszą perełkę lub po prostu kilka pomysłów wartych przetestowania. Kolejna oczywistość ;). Żeby generować dużo pomysłów nie traćmy czasu na ich dokładne opisywanie, wystarczą hasła lub jeszcze lepiej rysunki. Rysunek zastępuje 1000 słów. Niezrozumiałe rzeczy wyjaśnimy grupie w stosownym czasie.

10x 

Większość osób kieruje się w życiu rozsądkiem. Podejmując decyzję analizujemy nasze otoczenie: dostępne technologie, wyniki innych. Myślimy o zmianie jako o ewolucji, jako o ulepszeniu, udoskonaleniu obecnego stanu rzeczy, o czymś, co następuje niejako liniowo, krok po kroku. Przykładowo… zastanów się, jak rozwiązać problem korków w miastach? Wielu polityków na pewno ma w swoich programach taki punkt. Proponuję sobie wpisać to pytanie w Google’a i zobaczyć odpowiedzi. Postawmy na komunikację zbiorową, wdrożmy inteligentną sygnalizacje świetlną. Wiele mądrych, rozsądnych pomysłów. Ich wcielenie w życie prawdopodobnie zniweluje problem w jakimś stopniu, upłynni ruch o 1%, 2%, może o 10%, ale na pewno nie zlikwiduje korków w mieście.
 
Na to samo pytanie odpowiedział np. Elon Musk. 
 

 
Widzisz różnicę? 🙂 A może nie tunele, ale latające samochody? A może ruchomy chodnik jak u Jetsonów? A może trochę zwolnijmy i zrezygnujmy z prywatnych samochodów w mieście?
 
Na tym etapie przygody z design thinking odrzućmy na chwilę nasz rozsądek, odblokujmy odwagę i kreatywność. Próbujmy wymyślić coś, co nie jest 10% lepsze ale coś, co jest 10 razy lepsze, unikalne, prostsze. Nawet jeżeli twój pomysł wydaje Ci się totalnie irracjonalny i przez to głupi i nie wart tracenia czasu. Pozwól niech grupa o tym zadecyduje. Być może inne spojrzenie na ten pomysł spowoduje, że okaże się on wcale nie taki nierealny,  a może będzie on dla innych źródłem innych dobrych pomysłów. Jeszcze jedna kwestia związana z 10x. Chcąc zbudować coś 10 razy lepszego być może wymyślimy coś fantastycznego, ale i piekielnie trudnego. Nie bójmy się trudnych zadań.
 
John F. Kennedy powiedział:
 
We chose to go to the moon, not because it was easy … but because it was hard.

Burza mózgów

Wracając do samego procesu generowania idei, na warsztatach wykorzystaliśmy technikę burzy mózgów, a konkretnie “brainwritingu“. Cały proces wyglądał mniej więcej tak:
  • Po wprowadzeniu do problemu, każdy z grupy miał za zadanie wymyślić jak największą ilość pomysłów, kierując się wcześniej wspomnianymi zasadami. Mieliśmy na to ograniczony czas – 5 minut.
  • Pomysły spisywaliśmy na karteczkach (post-tip). Po upływie czasu każdy z nas kolejno przyklejał swoje karteczki na tablicy i krótko opisywał pomysł, jeżeli ten dla grupy był nie do końca zrozumiały. To był czas na dyskusje, ale ten czas był też ograniczony.
  • Następnie przychodziła kolejna runda generacji pomysłów, gdzie próbowaliśmy inspirować się obecną zawartością tablicy i rozwijać istniejące pomysły. Oczywiście bez krytyki. Wszystko znów w ograniczonych ramach czasowych.
  • Mając już dostateczną ilość wartościowych pomysłów następowała faza oceny… a właściwie wybrania pomysłów wartych sprawdzenia na etapie prototypowania.
 
Zalety wykorzystania techniki brainwritingu to: 
  • proces generacji pomysłów jest szybki, ponieważ każdy z członków grupy generuje je niezależnie. Jednocześnie na pierwszym etapie ograniczana jest faza dyskusji.
  • w grupie mogą znaleźć się zarówno osoby dominujące oraz osoby nieśmiałe, w tej metodzie każdy ma równe szanse na przedstawienie swoich pomysłów
  • pomysły trafiają na tablice, są następnie rozwijane w kolejnych iteracjach, dzięki czemu nie możemy ich przypisać do jednej osoby i stają się pomysłami grupy. Odcinane są od konkretnych członków grupy i niwelujemy ryzyko, że summa summarum przechodzi pomysł szefa, bo pozostali bali się go nie poprzeć 🙂
 
Burza mózgów może też przebiegać w zgoła inny sposób. Odwrotnie do brainwritingu można ją przeprowadzić opierając się na żywiołowych dyskusjach lub nawet na zasadzie teatru, przedstawiania scenek.

Zespół – zbiór mózgów

Bardzo pomocne jest dobranie odpowiedniego zespołu ludzi. Powinni to być ludzie z różnym punktem widzenia, zarówno programiści jak i ludzie mający kontakt z klientem, a może wręcz przedstawiciele klienta. Może warto zaprosić też osoby z zupełnie innej działki i zobaczyć ich punkt widzenia. 
Nie przesadzajmy z wielkością zespołu. Jeff Bezos (CEO Amazonu) stosował zasadę 2 pizz. W spotkaniu powinna brać udział taka liczba ludzi, którym wystarczą dwie pizze, by się najeść. 
 
Pamiętajmy też, że każde spotkanie, może przerodzić się w długi niekończący się tasiemiec. Szanujmy czas.  Warto przed spotkaniami ustalić granicę, czy to czasową czy to np. uzgodnić, że kończymy etap generowania pomysłów, gdy na tablicy znajduje się ich konkretna liczba. Design thinking to proces iteracyjny, do każdego z jego etapów możemy, a nawet powinniśmy wrócić nie raz.
 
Po tym etapie powinniśmy mieć co najmniej kilka pomysłów, które chcemy przetestować i które na użytek testów powinny zamykać się w konkretnych pytaniach. Może też zdarzyć się tak, że nie możemy wygenerować żadnego pomysłu, ponieważ mamy istotne braki w danych. Wtedy możemy wrócić do etapu poszukiwań lub też zadać konkretne pytanie, które można przetestować tworząc prototyp.

Prototypy i testy

A czym jest prototyp? Prototypy to kolejna oczywistość w design thinking. Przecież oczywiste jest, że przed rzuceniem całych dostępnych sił w implementację pomysłu, warto ten pomysł poddać testom, przedstawić go ludziom, zebrać opinie. Sprawdzić czy “zażre”. Niby tak.. ale może jeszcze na to za wcześnie.. Jeszcze trochę “pokodzę”, dopiszę kilka funkcjonalności i zaraz potem pokażę. Nie no, patrz jakie to brzydkie i czasem się zawiesza, nie chcę żeby ludzie się od razu zrazili. Dobre wrażenie robi się tylko raz. Takie dysputy można toczyć bardzo długo i co gorsza przeważnie toczą się one tylko wewnętrznie w naszych zespołach lub tylko w naszej głowie. 
 
źródło: rework.withgoogle.com
 
Design thinking kładzie nacisk na szybkie testowanie naszych idei. Prototyp to nawet nie MVP. Prototyp ma dać odpowiedź na pytania, które powstały po etapie burzy mózgów. Im mniej czasu i nakładów poświęcimy na zbudowanie prototypu i jego przetestowanie tym lepiej. Oczywiście, do wszystkiego trzeba podchodzić zdroworozsądkowo. Pamiętajmy cały czas o użytkowniku.
 
Co może być prototypem? Patrząc od strony aplikacji to np.:
  • szkic, rysunek
  • bardziej szczegółowy, mockup
  • reklama Google Adwords, Facebook
  • landing page
  • aplikacja
 
W książce “The 4-Hour Workweek” Tim Ferris opisuje jak do przetestowania produktu może posłużyć “fake’owy” sklep internetowy. W omawianym przykładzie w ostatnim kroku zamawiania produktu, po zebraniu danych kontaktowych klienta, pojawiał się komunikat przepraszający użytkownika, że w danej chwili wysyłka produktu nie może być zrealizowana. 
 
Warto jednak zaczynać od mniej pracochłonnych prototypów. Dobrym pomysłem jest też testowanie ich najpierw na mniejszej grupie, sprawdzenie czy prototyp faktycznie daje odpowiedź na pytanie, które za nim stoi.
 
A skąd mamy wiedzieć czy prototyp daje nam tę odpowiedź? Musimy mierzyć 🙂 Zbierać odpowiedzi, zliczać ilość kliknięć (w reklamę lub w linki na naszym landing page’u), podglądać użytkownika, mierzyć czas, mierzyć wielkość naszej “widowni”. Musimy zbierać dane, które później pozwolą nam wrócić znów do etapu researchu, czyli do etapu, w którym analizujemy fakty, a nie podpowiedzi naszej intuicji.
 
Na koniec akapitu, pozwolę sobie wrócić jeszcze do idei budowy prototypu w postaci “landing page’a“. Jest ona o tyle ciekawa, że przy okazji mierzenia ilości kliknięć, budowania heat-map, odzwierciedlających co użytkownika zainteresowało na naszej stronie, daje nam coś jeszcze. Pozwala zbudować tzw. “Minimum Viable Audience“, czyli jak to opisuje Paweł Tkaczyk na swoim blogu  “Minimalną Działającą Widownię – twój własny tłum, który będzie paliwem dla Twojej marketingowej machiny”. Ta widownia to ludzie, którzy zostawią na siebie namiar i być może staną się naszymi pierwszymi testerami, a później klientami. To ludzie, których opisaliśmy budując “personę”, na etapie badań.

Podsumowanie

Co to jest design thinking? Czy programista powinien zajmować sobie głowę design thinking? Wg mnie TAK. Ta metoda pokazuje nam programistom, że oprócz specyfikacji i wymagań projektów, w tym co robimy jest jeszcze jakiś kontekst. Zwraca nam uwagę, że warto pochylić się nad problemem, zobaczyć jak coś działa, popytać użytkowników, spróbować wytworzyć jakąś wartość wspólnie z nimi. Nie jest to złoty środek, a raczej tak jak wspomniałem zebranie kilku oczywistych procesów i połączenie ich ze sobą w jedną całość. W pewien sposób łączy się też z coraz popularniejszym podejściem Domain Driven Development, w którym to struktura naszych aplikacji powinna odzwierciedlać rzeczywistość. Aby tak było, musimy tę rzeczywistość najpierw poznać. 
 
Na koniec wielka prośba. Jeżeli wpis Ci się podobał i wyniosłeś z niego wartość, proszę daj mi o tym znać! Jeżeli jest coś co mogę poprawić, tym bardziej, proszę, napisz. Będzie mi też niezmiernie miło, jeżeli podzielisz się nim z innymi osobami, które mogą być zainteresowane tematyką designu.