Nikt nie chce software'u

Dzisiaj software jest wszędzie: w zegarkach, urządzeniach medycznych, telefonach, TV, windach, autach, komputerach (tak jakby komputerami nie były urządzenia wymienione wcześniej). Współczesne społeczeństwo jest od niego zależne. 

Przez ostatnie 14 lat wspierałem firmy w tworzeniu oprogramowania jako konsultant, sam programowałem też całkiem sporo. Jestem współautorem międzynarodowego standardu i pracowałem przy jego implementacji. Napisałem oprogramowanie sterujące systemem komunikacyjnym satelity. Stworzyłem narzędzia dla teamu, który zbudował model Ekstremalnie Wielkiego Teleskopu. Byłem zaangażowany w rozwijanie oprogramowania m.in. dla firm motoryzacyjnych, systemu opieki zdrowotnej, banków, ubezpieczeń, telekomunikacji, czy lotnictwa.

W niektórych z tych firm proces wytwórczy oprogramowania działał dobrze. Zespoły dostarczały software wysokiej jakości. Interesariusze byli zadowoleni. Firmy powiększały bazę swoich klientów, by ostatecznie zwiększyć swoje zyski. 

Inne firmy natomiast borykały się z problemami. Widziałem działy spierające się ze sobą, czyje wymagania uwzględnić przed releasem. Developerów, którzy nie nadążali z liczbą nowych, rozwijanych funkcjonalności i kolejnymi zmianami projektowymi. Niektórzy z nich stracili jakiekolwiek poczucie sensu pracy nad projektem. Obserwowałem, jak psuje się komunikacja między programistami, a zarządzającymi nimi, „nietechnicznymi” inwestorami biznesowymi. Po paru latach rozpoznałem pewien wzorzec.

Za każdym razem, gdy byłem pytany o to, co idzie źle, zacząłem odpowiadać, że nikt nie chce używać software’u. Początkowo patrzono na mnie jak na wariata. Software jest wszędzie. Napędza współczesną cywilizację! Ale kiedy już wytłumaczyłem, o co mi chodzi, wielu z pytających przytakiwało, zgadzając się ze smutkiem.

Pewnie tak jak ja, przynajmniej część zakupów robisz w Internecie. Masz ochotę rejestrować się w kolejnym sklepie online? Lubisz dodawać produkty do koszyka, jeden po drugim? Chce Ci się ponownie sprawdzać, czy prawidłowo wpisałeś/aś numer karty płatniczej? A wielokrotnie potwierdzać swój zakup? Jestem przekonany, że nie. Mimo tego, wciąż nie rezygnujemy z zakupów w sieci. Dlaczego?

Pożądany rezultat

Tym, co się liczy, jest pożądany rezultat: posiadanie na własność nowej pralki lub lektura nowej książki. Każda kolejna interakcja z oprogramowaniem to krok ku pożądanemu wynikowi. A uświadomienie sobie tego miało olbrzymi wpływ na sposób, w jaki teraz tworzę oprogramowanie.

Wiele firm mierzy produktywność programistów liniami kodu lub tempem pracy, co z grubsza oznacza ukończenie określonej liczby funkcjonalności w konkretnym czasie, z uwzględnieniem rozmiarów danej funkcjonalności. Niektórzy kojarzą funkcjonalności ze sprzedażą pomarańczy. Im więcej będzie dostępnych dla klientów, tym wyższy zysk. Zapewniam, że to błąd. Dodanie funkcjonalności ułatwi bądź utrudni użytkownikowi osiągnięcie upragnionego rezultatu, a pracę developerów można mierzyć na inne, bardziej sensowne sposoby, niż poprzez jej tempo.

Kiedy wchodzisz na nowy rynek, upewnij się, że Twoje oprogramowanie spełnia potrzebę klienta. Ceń swoich klientów wysoko i dbaj o częsty feedback. Nie pozwól, by Twój software stał się w wielkim chaosem pełnym funkcjonalności, którego nikt nie chce używać.

Jeśli masz już stabilną pozycję na rynku, utoruj sobie drogę. Stwórz user’s journey; drogę użytkowników do ich pożądanego wyniku - możliwie najkrótszą i najprzyjemniejszą. Bo jej finał jest pierwszym momentem, w którym tworzysz wartość dla swojej firmy. Rozwój oprogramowania to inwestycja.

Krótsza ścieżka użytkownika, czyli Kindle Amazona

Kiedy Amazon zaczął sprzedawać online, zamawiałeś/aś książkę, którą dostarczano Ci do domu. Potem wprowadził zakupy jednym kliknięciem (1-Click), dzięki czemu mogłeś/aś pominąć wpisywanie szczegółów transakcji, klikając koszyk za każdym razem, gdy chciałeś/aś coś nabyć. Skrócono ścieżkę użytkownika.

Później wprowadzono Kindla, który uprościł ją jeszcze bardziej. Szukasz książki, sprawdzasz jej opis, potwierdzasz zakup. Szybko pobierasz i masz już produkt. Koniec z czekaniem na wysyłkę. Docelowo wszystko to prowadzi do tego samego rezultatu: możesz przeczytać książkę. Jedynie user’s journey jest znacznie krótsza.

Rozwijanie jak największej liczby funkcjonalności nie jest receptą na sukces. Na szczęście nie tylko ja tak uważam. Gojko Adzic stworzył technikę znaną jako Impact Mapping, która umożliwia połączenie funkcjonalności software’u z celami biznesowymi. Adzic apelował do społeczności developerów: Make impacts, not software. Z kolei David Heinemeier Hansson - twórca Ruby on Rails - zakłada, że zawsze możemy zrobić mniej (więcej o tym w jego artykule: You can always do less).

O ile developerzy, z którymi o tym rozmawiam, zgadzają się z sensem tego założenia, z mojego doświadczenia wynika, że tylko niewielki procent firm realnie dba o skrócenie user’s journeys.

Kocham software, fascynuje mnie. Zacząłem go tworzyć we wczesnych latach dziewięćdziesiątych i wciąż to lubię. Jest przydatny, ale nie sam w sobie - to tylko środek do celu. Co, mam nadzieję, będziesz mieć na uwadze.