4 sposoby na to, żeby biznes Cię pokochał

Przedstawiam Wam pierwszy na devstyle.pl post gościnny. Przed Wami: Andrzej Krzywda! Dużo dobrej treści, więc: miłej lektury ;).

Nadszedł ten dzień. Zaczynasz nowy projekt. Ekscytacja, ale jednocześnie zaniepokojenie. Czy tym razem pójdzie dobrze? Czy skończy się podobnie, jak ten poprzedni projekt? Czy klient będzie zadowolony? A może to projekt open-source w ramach akcji “Daj się poznać“? Jaki wtedy jest cel?

Jaki język wybrać? Jaki framework wybrać?

developers, when a new projects starts and they want to choose a new framework pic.twitter.com/1bByi949hv

— Andrzej Krzywda (@andrzejkrzywda) September 21, 2015

Jak już mam Twoją uwagę, to pozwól, że się przedstawię. Nazywam się Andrzej Krzywda i dzisiaj występuję gościnnie u Maćka na blogu. Maciek tak ostatnio nawychwalał mój jeden blogpost, że aż mi głupio teraz. Poprzeczka jest wysoko. Prawdopodobnie napisałem do tej pory około 150 blogpostów. Sam nie do końca w to wierzę, ale one wszystkie były po angielsku i prawdopodobnie jest to mój pierwszy wpis po polsku! Bloguję od 10 lat. Od początku jakoś jednak naturalniej było dla mnie, że piszę po angielsku. Pewnie wynikało to z tego, że obracałem się w światku Ruby i kiedy zaczynałem blogowanie było nas w sumie trzech w Polsce. Trochę bez sensu pisać do 3 osób. Szczerze mówiąc, nie wiedziałem też, że polska blogosfera mocno się rozrosła i można mieć spore grono czytelników. Dopiero od Procenta nauczyłem się, że może być sens blogować po polsku.

Skracając cała tą historię, postanowiłem spróbować sił po polsku. A że nie mam swojego polskiego bloga, postanowiłem zagadać do Maćka – naszego programistycznego Maxa Kolonko, “który mówi jak jest, Nowy York Białystok”.

Tyle tytułem przedstawiania się. Wróćmy do głównego wątku.

Wybór technologii

Na starcie projektu jest tyle ciekawych rzeczy do nauczenia się czy do przeanalizowania. Jako programiści, niestety, wszystko sprowadzamy do technologii. Jeszcze do końca nie wiemy, czy ten nowy projekt będzie dla światka finansowego, czy może kolejny Uber dla psów. Ale już trwa gorąca debata w zespole, czy iść w Angular (jednak sprawdzony), czy może Angular 2 (trochę ryzyko, ale to przecież najświeższa rzecz, więc musi być dobrze), albo iść w React.js/Redux.

Jeśli jakimś cudem dogadaliście się co do frontendu (wybraliście React, prawda? dobry wybór!), to mamy jeszcze backend. Jesteśmy u Maćka na blogu, więc spora szansa, że ten wybór jest dla Ciebie prostszy – C#, prawda? (ja wybrałbym Ruby i Railsy, ale to dlatego, że lubię poprawiać literówki na produkcji)

Ważniejsze od technologii są inne rzeczy. Na przykład: po co jest ten projekt?

Tak naprawdę, to wszystko nie ma znaczenia. Ciężko jest wybrać coś, z czego potem nie mógłbyś się wycofać. Jak mawia Uncle Bob, architektura to wszystkie te decyzje, które później ciężko zmienić. Jako ktoś, kto aż za dużo czasu spędził w projektach legacy mogę Ci powiedzieć – docelowo wszystko da się odkręcić, ale rzadko jest taka potrzeba. (Żartowałem, Angulara nie da się odkręcić, nie idźcie tą drogą.)

Ważniejsze od technologii są inne rzeczy. Na przykład: po co jest ten projekt? Niby takie proste pytanie, a nie zliczę ile razy zagiąłem nim programistów. “Po co jest ten projekt?” – to pytanie równie trudne dla programistów jak “Po co żyjemy na tym świecie?” czy “Jaki jest cel tej wędrówki?”. Okazuje się, że często to pytanie jest również trudne dla samego klienta. On chce mieć projekt/aplikację, bo tak na intuicję mu to pasuje.

Najbardziej naturalną motywacją jest chęć zarobku. W jaki sposób ta aplikacja będzie zarabiać pieniądze? Którędy te pieniądze idą? Kto płaci? Komu trzeba odpalić prowizję? Ile z tego zostanie na końcu? Ilu płacących trzeba w jakim czasie, żeby to się finansowo spięło? To trudne pytania, ale nie obawiaj się ich używać, nawet jeśli jesteś “tylko” programistą.

Jest kilka technik, które można zastosować, aby zmniejszyć dystans między nami i klientem, jeśli chodzi o wiedzę – po co to wszystko. Dzisiaj nakreślę Wam 4 takie techniki.

Impact Mapping​

O tej technice nauczyłem się na konferencji CraftConf w Budapeszcie w 2014 roku. Odbywały się tam warsztaty prowadzone przez twórcę tej techniki – Gojko Adzic. Impact Mapping to w dużym skrócie inne podejście do sprawy backloga.

Impact Mapping to inne podejście do backloga

Kto z Was był w projekcie, gdzie backlog rozrastał się bez końca? Kto z Was przestał wierzyć, że jest szansa, że kiedykolwiek to wszystko zrobicie? Gojko proponuje dosyć zaskakującą sprawę – wrzucajcie do backloga jak najwięcej pomysłów. Gdzieś to musi być zgromadzone. Każdy pomysł na historyjkę/task w backlogu może mieć swój sens. (Przy okazji, jeśli przygnębia Was długi backlog to polecam technikę zaproponowaną przez mojego kolegę z zespołu – Chronos vs Kairos czyli inne spojrzenie na percepcję czasu w projekcie).

OK, więc mamy wszystkie możliwe historyjki w backlogu. Co teraz?

Impact Mapping: Cele

Gojko radzi, aby operować pojęciem Celu (Goal). Zamiast od razu myśleć o tym, które historyjki bierzemy, zdefiniujmy Cel(e). Przykładowym celem może być – “100 tysięcy unikalnych użytkowników do kwietnia 2016”. Dobrze zdefiniowany cel nie ma w sobie szczegółów implementacyjnych. Dobry cel jest zwykle czymś, co już jest bliskie samych pieniędzy, choć nie musi wspominać dokładnych kwot. Taki cel musi oczywiście być przedstawiony przez klienta lub Product Ownera, ale docelowo sam nabierzesz takich umiejętności.

Dobra, mamy więc cel – co dalej?

Impact Mapping: Aktorzy

Teraz przechodzimy na aktorów – postacie/profile/persony, które mogą wspomóc realizację tego celu. Tutaj warto wspomnieć, że ten proces nie dotyczy tylko zespołu technicznego. Impact Mapping powoduje, że wszystkie “działy” są jednym zespołem, które wspólnie działają w kierunku celu. Przykładowo, pozyskanie nowych użytkowników można sobie wyobrazić do zrealizowania w całości przez dział marketingu poprzez wykupienie reklam. Wtedy nasi ludzie od marketingu są aktorem. Możemy potraktować naszych aktualnych użytkowników jako aktorów w tym celu – być może oni mogą wirusowo reklamować naszą aplikację?

Jeśli celem jest ściągnięcie większego ruchu, to musimy się upewnić, czy nasz system i infrastruktura taki ruch ogarnie, więc tutaj aktorem też będzie sysadmin/devops. Nie wchodzimy tu jeszcze w szczegóły techniczne, po prostu iterujemy po naszych możliwych aktorach i myślimy, czy jest realne, że oni jakoś mogą wspomóc dany cel. Przydaje się posiadanie listy naszych aktorów w jakimś dokumencie, aby nie pominąć żadnej grupy. Tutaj też warto dodać, że dobrze jest te grupy traktować bardziej szczegółowo niż sama nazwa. Przydaje się jeszcze kontekst:

“Aktualni użytkownicy, którzy używają naszą aplikację poprzez mobile, w grupie osób”​
“Bierni użytkownicy forum pasjonatów tematu XYZ”​
“Czytelnicy tych konkretnych naszych blogpostów, którzy przyszli z Google”

Z jednej strony, to nie jest trudna technika. Jednak w praktyce jest ona bardzo mocno poza strefą komfortu wielu programistów. Wolimy kodować niż myśleć o jakichś celach, personach, marketingach i sprzedażach, prawda?

Impact Mapping: Impact

Nie będę próbował na siłę tego słowa tłumaczyć. Wpływ? Eh, łatwiej się jednak po angielsku bloguje ;) Impact to oczekiwana zmiana zachowania danych aktorów.

“Aktualni użytkownicy przyciągną 1000 ludzi do systemu”
“Reklamy na fejsie ściągną nam 10.000 nowych ludzi”
“Użytkownicy forum XYX – 100 z nich zarejestruje się u nas”
“Czytelnicy naszych blogpostów – 1000 nowych rejestracji”

Liczby tutaj są opcjonalne – widziałem różne szkoły. Impact to w pewnym sensie hipoteza na przyszłość. Dla zainteresowanych proponuję wyobrazić sobie jak takie cele potem faktycznie weryfikować – może tutaj jest miejsce na jakieś narzędzie?

Impact Mapping: Deliverables

W końcu dochodzimy do powiązania tej metodyki z naszym backlogiem. Tutaj też jesteśmy w naszym żywiole – coś trzeba dowieźć. No właśnie, ale co? Mamy już listę potencjalnych impactów, ktore są powiązane z aktorami. Teraz więc idziemy do backloga i przeglądamy nasze pomysły na taski. Wszystkie. Dla każdej z historyjek sprawdzamy, czy ta historyjka może wspomóc planowany Impact. Ktoś kiedyś dodał taska “przycisk Share on Twitter” i wyestymował na 1h. Brzmi jak coś, co może wspomóc przyciągnięcie nowych użytkowników przez aktualnych użytkowników. Tak, brzmi sensownie – bierzemy to. Czasami wymaga to pewnej kreatywności, aby połączyć kropki w naszym systemie. Zwykle jednak powinno to być łatwe w obsłudze. Takie Deliverables zaczynamy realizować i mierzymy ich efekt. Mierzenie jest tutaj kluczowe – w pewnym sensie cała ta koncepcja opiera się na hipotezach. Te hipotezy to takie asercje na przyszłość.

Impact Mapping: Podsumowanie

​Przyznam, że nigdy nie udało nam się podążać tą techniką przez cały czas prowadzenia projektu. Jednak te momenty, gdzie “włączyliśmy” sobie to myślenie ułatwiały nam zrozumienie celów biznesowych i pomyśleć czasem w niestandardowy sposób. Impact Mapping można zastosować na początku projektu, wtedy zmusi nas do lepszego zrozumienia celów, person, zmian jakich spodziewamy się po tej aplikacji. Trochę to wtedy da do myślenia. Z dużą siłą można wprowadzić IM do istniejącego projektu, szczególnie, jeśli już dysponujecie dużym backlogiem.

Impact Mapping daje do myślenia. Zmusza do lepszego zrozumienia celów aplikacji.

Polecam poczytać więcej na stronie dotyczącej tej techniki.

Analiza tekstowa specyfikacji​

Czasem zdarzy Ci się Klient-Korporacja, który wystawi Ci na osobę kontaktową… zgadnij kogo? Oczywiście – to Człowiek-Garnitur, wszyscy go znamy. Człowiek-Garnitur już sobie wszystko spisał w 100-stronicowej specyfikacji i nie rozumie potrzeby porozmawiania. Ma to swoje wady, ale też ma zalety. Masz jednak jakąś specyfikację. Technika jest tutaj bardzo prosta. Wypisujesz sobie wszystkie rzeczowniki i czasowniki z tego tekstu. Jak masz do tego jakieś narzędzie, to można to zastosować. Kartka papieru, długopis i stawianie kresek w zupełności wystarczy.

Rzeczowniki to klasy. Czasowniki to metody.

Ta dosyć prymitywna technika polega na tym, że rzeczowniki to są obiekty/klasy w Twoim systemie. Czasowniki to oczywiście metody. Jeśli już masz jakiś kod, a projekt jest już w trakcie, to możesz też się przyjrzeć emailom czy dokumentom od klienta i sprawdzać czy takie byty z tekstu są w Twoim systemie pod takimi właśnie nazwami. Oczywiście, nie będą. Warto się zastanowić wtedy skąd taki rozjazd i czy może Twój kod powinien być bliżej tego jakiego języka używa klient.

Jedna uwaga – jeśli klient jest z tych “obytych z programistami”, to już pewnie się poddał i używa języka CRUD’owego w komunikacji z Tobą. Wszystko jest wtedy listą, rekordem, postem. Wszystko się tworzy, updejtuje i usuwa. Jeśli dotarłeś do tego etapu, to współczucie, ale pewnie sam się do tego dołożyłeś :P Ta technika wtedy może nie być odpowiednia…

Event Storming

​Event Storming przydaje się szczególnie wtedy, kiedy robisz swój kod w stylu DDD. Zakłada to pewne zrozumienie co to jest Command, Aggregate, Event. W skrócie – aggregate bierze komendę na wejściu, a zwraca event. Command to input, a Eventy to output.

Agregat przyjmuje komendę i publikuje zdarzenie

​Bierzemy wszystkich programistów i tyle osób “od biznesu” ile możliwe i umieszczamy ich w jednej sali. Przygotowujemy samoprzylepne karteczki, najlepiej w 3 kolorach. Każdy dostaje po pisaku i stosiku tych karteczek. Pierwsza osoba zaczyna i przylepia na ścianę karteczkę z nazwą jakiegoś ważnego Eventu z naszej aplikacji – np. BookRefunded. Inne osoby dołączają (nie ma kolejności) i przyklejają inne eventy, commandy czy agregaty. Dobrze jest zachować chronologię, więc BookRefunded będzie na prawo od agregata Book, a jeszcze na lewo od nich będzie RefundBook (jako Command). W praktyce jeden agregat będzie otoczony z lewej strony Commandami, a z prawej Eventami. Nie ma tutaj jakichś dodatkowych zasad zabawy. Chodzi o to, żeby móc się czegoś nauczyć o naszej domenie. Taka sesja zajmie pewnie 1-2h. Po jakimś czasie będą się tworzyć grupki, gdzie będzie toczyć się dyskusja o jakimś konkretnym module aplikacji. To dobry efekt. Warto jednak podejść do tematu szeroko i przejść się wzdłuż ściany. To jest okazja, żeby wizualnie zobaczyć cały nasz biznes. Ta technika opiera się na ciekawym zjawisku – ludzie biznesowi całkiem sensownie umieją operować Eventami. Formuła oparta o te 3 rodzaje karteczek narzuca wręcz odejście od języka CRUD’owego, co może być zbawienne dla wielu modułów.

Zacznij od środka

To jest technika, którą jestem pewien, że skądś ukradłem, ale zapomniałem skąd i jak była nazwana. Postanowiłem więc nazwać ją po swojemu – Start from the Middle.

20% wymagania = 80% efektu

Idea jest ogólnie prosta i może działać na poziomie zarówno całego projektu (wtedy to już się zbliża do MVP) jak i pojedynczej funkcjonalności. Być może powinno się to nazywać Minimal Viable Feature. Dla większości wymagań da się znaleźć taką programistyczną zasadę Pareto. Zrobienie 20% konkretnego wymagania oznacza już 80% efektu. To brzmi świetnie w teorii, każdy chciałby tak efektywnie działać, ale jak znaleźć które to jest 20%?

Większość typowych aplikacji opiera się na tym, że więcej osób przegląda treść w systemie niż tą treść tworzy. Bardzo wiele ficzerów da się zacząć od tego, że implementujemy najpierw wyświetlanie jakichś danych. Jeszcze ich nie można tworzyć, edytować ani usuwać, ale już można wyświetlać. W zależności od sposobu współpracy z klientem/użytkownikami – być może warto już takie coś “dowieźć”. Oczywiście jako programista możesz pewne dane zhardkodować – albo w samym html, albo w obiektach, albo w bazie danych.

Często Start From the Middle to właśnie najpierw shardkodowanie wyświetlania danych w html. To już możemy pokazać klientowi bardzo szybko (po godzinie pracy?). Następnie mamy równoległe akcje – klient sobie to przegląda/klika. Ty w tym czasie już przesuwasz hardkodowanie z html na Twoje obiekty widoku – prezentery, dekoratory, read modele czy co tam aktualnie jest na topie do wyświetlania. Zauważ, że to może być robione w JavaScripcie, jeśli frontend nie odstrasza Cię za bardzo. W tym przypadku przesuwasz dane z przykładowo komponentu React hardkodowanego w JSX na properties, potem na state. Następnie w ogóle wyciągasz to ponad React, albo na Redux albo na swój sposób wyciągania danych. Za chwilę przesuniesz to na Ajax, następnie zrobisz API endpoint i hardkodujesz to w generatorze JSON. Potem obiekty, na bazie których JSON powstaje, następnie już baza danych na backendzie.

Brzmi jak dużo pracy? Niekoniecznie, jeśli to nie są dla Ciebie nowe technologie to każdy krok robisz w kilka minut. Zauważ, że ciągle jedziesz “na zielonym”, a klient już może to testować. Jeśli testuje, to może Ci szybko zwrócić uwagę co ma być inaczej. Im szybciej to zrobi, tym mniej warstw musisz potem poprawiać/zmieniać. Na tym polega ta technika – szybko dowozisz coś klientowi i dostajesz szybki feedback.

Szczególną wersją Start from the Middle jest podejście Frontend-first, gdzie zatrzymujesz się przez jakiś czas na tym, że dane są ulotne na frontendzie (w rozumieniu JS), ale można całkiem sensownie takiej aplikacji używać. Dopóki nie przeładujesz strony, masz wszystkie dane w pamięci. Udało mi się kiedyś sporo gier przeglądarkowych tak dowieźć – najpierw 2 tygodnie iterowania na tym, jak ma to wszystko wyglądać i działać na przeglądarce, następnie 1-2 dni na backend.

Ta technika wymaga sporo od Twojego procesu tworzenia oprogramowania. Jak szybko Twoja linia kodu może być uruchomiona przed klientem? W kilka minut? Nieźle – warto to wtedy stosować. W kilka godzin, raczej też warto, ale to podobnie jak z powolnym buildem, pewnie w międzyczasie zmieniłeś kontekst i teraz jest koszt przełączenia ponownego.

Wszystko tutaj opiera się na szybkim feedbacku. Im szybciej, tym lepiej. Zdarzało mi się tak, że CzłowiekGarnitur dawał mi opis ficzera na 20 stron. Ja dowiozłem pierwsze 10% (wyświetlanie), pokazałem to na ekranie i nagle klienta olśniło, że w sumie to on jednak widzi teraz, że chciałby coś innego. Poszliśmy w zupełnie inną stronę, niż specyfikacja. Skończyliśmy w 50% planowanego czasu z dużo lepszym rozwiązaniem.

Obserwując dziesiątki/setki projektów informatycznych, nauczyłem się, że jeśli coś warto optymalizować to właśnie czas feedbacku i komunikację z klientem/użytkownikami.

Co dalej?

Nie ma znaczenia, czy użyjemy Ruby, .NET czy nawet Haskell – jeśli wciąż zdarzają się nieporozumienia pomiędzy programistą a klientem, to one powodują większe marnotrawstwo i opóźnienia niż to, czy użyjemy języka X. Warto zainwestować trochę czasu w doskonalenie technik, które ułatwiają komunikację z klientem.

Trzymam kciuki i życzę powodzenia!

Na koniec jeszcze trochę prywaty. Tak jak wspominałem, jest to mój pierwszy blogpost po polsku. Jeśli Ci się spodobało, daj znać w komentarzu. Jeśli coś można poprawić, również będę wdzięczny za info :)

A jeśli chcesz zobaczyć jak mi idzie z pisaniem po angielsku, to można mnie znaleźć w kilku miejscach:
Blog Arkency
https://medium.com/planet-arkency
Blog Andrzej on Software
Twitter @andrzejkrzywda
Facebook: Andrzej on Software
Książki, przy których wydaniu/napisaniu brałem udział (szczególnie warto zerknąć na “Blogging for busy programmers” oraz na “Developer Oriented Project Management“, która jest w duchu tego blogposta).