Tebe Gada

Gdy organizacja chce sprawnie tworzyć popularne produkty, potrzebuje do tego dobrych ludzi. Od pewnej liczby zatrudnionych to jednak za mało. Potrzebny jest dobry proces - powtarzalny sposób robienia rzeczy. Musi być na tyle sensowny, żeby ludzie go rozumieli i akceptowali. 

W prezentacji nt rozwoju produktów znanej, dynamicznej firmy internetowej natknąłem się na schematyczną prezentację procesu.

Wygląda tak:

Choć jest to ładnie pokazane, widać, że ma sporo etapów, które trzeba zrozumieć, więc nie jest bardzo proste. Zaskakujący może być aktywny udział managementu w kolejnych fazach procesu.

Zawsze jest między nimi furtka - zespół, autonomiczny, samodzielny i agilowy musi uzyskać akceptację / decyzję z udziałem managementu, żeby pójść dalej.

Jak na organizację, której to dotyczy, wydaje się dość sformalizowane. Przykład jest w miarę świeży. 

Kilka lat temu prowadząc rozmowy nt. procesu prezentowałem przy różnych okazjach taki obrazek:

Widać, skąd pochodzi. Prezentacja nt. tego jak działa AOL została upubliczniona przez Business Insidera.

Obrazek niżej pochodzi z 2009, z dużej polskiej firmy internetowej. W jakimś stopniu po wdrożeniu ten proces został porzucony, nie mam obowiązujego obecnie. Prawdopodobnie ten był niezbędnym etapem na drodze do Agile.

Ta firma to Allegro. Pokazywany był na branżowej konferencji informatycznej. Ze schematem z AOL łączy go podejście - kaskadowe. Na początku wymyślamy coś dużego, potem projektujemy coś dużego, potem długo to robimy. Na koniec okazuje się, że wszystko wyszło idealnie... No to akurat się rzadko zdarza.

Pierwszy proces ma fazy, ale różni się treścią. Inaczej wymyśla się w nim rzeczy, robi się o wiele taniej, głównie po to, żeby sprawdzić pewne teorie. Dopóki coś jest projektem i koncepcją, pozostaje teorią. Prawdziwe liczby i użytkownicy bez większego wysiłku stale takie teorie obalają.

Pierwszy proces to Spotify. Dość dokładnie opisany jest tutaj. Wszystkim, którzy się zajmują tematem [czyli pewnie jakimś 10 osobom w pl ;-)] polecam uważną lekturę.

Pisałem już jak ważne w rozwoju produktu jest priorytetyzowanie rzeczy, którymi się zajmujemy. Niedawno natknąłem się na niezły przepis na ten proces. Jego autorem jest Tom Conrad, który odpowiadał za rozwój Pandory, jednej z ważniejszych na rynku aplikacji muzycznych.

W tym podejściu wybór rzeczy do realizacji przypomina grę. Kolejne fazy są takie:

1. Każdy zgłasza swoje pomysły odpowiadając na sprytnie postawione pytanie: czego głupotą byłoby nie zrobić w najbliższych trzech miesiącach. Czyli nie "co moglibyśmy zrobić" tylko "czego nie możemy nie zrobić". Już to wymusza refleksję. 
2. Wszystkie pomysły opisuje się w podobny sposób - za każdym razem na takim samym slajdzie podając o co chodzi i jakie korzyści ma to przynieść produktowi.
3. Szacuje się ilośc pracy potrzebną do zrealizowania każdej rzeczy.
4. Tu zaczyna się praca grupowa. Tworzy się wirtualną walutę (np. papierowe dolary), które dostają osoby decydujące. Ich ilośc odpowiada liczbie dostępnych dni pracy ludzi, którzy są potrzebni, żeby to wszystko zrealizować.
5. W czasie sesji głosuje się "wydając" przydzielone pieniądze na poszczególne funkcjonalności / zmiany. To co zostało sfinansowane trafia do realizacji.

Warto poczytać dokładnie tekst Conrada, ale kilka rzeczy w tym podejściu jest wartych omówienia.

Całość upraszcza proces analiz i wymiarowania pomysłów. Metoda jest zwinna, oparta na zdrowym rozsądku. W innych podejściach każde zadanie można modelować na różne sposoby i wrzucać do exceli, z których na koniec nic mądrego nie chce wyjść. Tu logika jest prosta - albo jesteśmy jako zespół / startup / organizacja do czegoś przekonani i to finansujemy, albo nie. By to zadziałało, w grupie decydujących warto.. mieć decydentów. Byc może nawet dając im trochę więcej pieniędzy niż pozostałym.

Ćwiczenie wymusza uczestnictwo i wciąga zainteresowanych. Dobrze zrealizowane zapewnia, że kluczowe dla produktu osoby aktywnie uczestniczą w decyzjach. Identyczna prezentacja wymusza myślenie o tym, co określona rzecz da. Nic nie dzieje się pod stołem - każdy krok jest omówiony, a równocześnie nie zajmuje to dużo czasu. Przy okazji rozmowy o kosztach i korzyściach wszyscy mogą lepiej zrozumiec proces rozwoju. Gra wspiera też tworzenie kultury priorytetyzacji w załodze.

Dośc kluczowy jest szacunek kosztów i ocena czasu pracy jaki mamy do dyspozycji. Tu najczęściej popełniamy błędy. Mylimy się szacując ile coś zajmie, dlatego trzeba to robić z uwagą, ale też dzielić rzeczy na takie (czytaj: względnie nieduże), by ich ocena była możliwa. Z drugiej strony nie można zakładać, że miesiąc pracy człowieka to pełne 20 dni na rozwój. Ludzie chorują, chodzą na urlopy, a przede wszystkim robią całą masę rzeczy, które zżerają ten czas. Utrzymanie, zebrania i maile zabierają więcej niż wam się wydaje. To warto liczyć i posługiwać się danymi zbliżonymi do historycznych.

Niedawno przećwiczyliśmy to w praktyce m.in. planując dalszy rozwój nowego Blox.pl. Zachęcam do próbowania w startupach i przedsiębiorstwach wszelakich.

BTW - świetnie się pisze w tym nowym edytorze Blox.pl

Ucieszył mnie wpis Davida HH, na temat wycen i budżetów w projektach. Radzi on, by wstępny szacunek czasu pracy uznawać za budżet i trzymać się go w czasie realizacji, poświęcając na projekt tylko tyle na ile go wstępnie wyceniliśmy. Na taki pomysł wpadliśmy pod koniec 2012 roku. Nie jest to łatwe, zwłaszcza w dużej organizacji, ale działa - warto się starać.

Osobom, które "tego" nie robiły, trudno się rzecz tłumaczy. Oczekują one zwykle, że ktoś odpowiedzialnie powie ile potrzeba pracy i czasu by stworzyć nową funkcjonalnośc czy usługę. Doświadczeni (w innych obszarach) menedżerowie mogą takie deklaracje uznawać za "nieprofesjonalne", ale nie ma czegoś takiego jak sensowna wycena w projektcie programistycznym, zwłaszcza, gdy powstaje w nim produkt dla konsumenta. Nie bez powodu jest to jeden z głównych wątków metodyk rozwoju oprogramowania, których jest bez liku. 

Dlaczego tak jest? Z wielu powodów, o których już pisałem. Przede wszystkim, w rozwoju praktycznie nie zdarza się, że robimy to samo po raz kolejny. Tylko w takiej sytuacji możnaby - zakładając identyczne zachowanie zespołu i czynników zewnętrznych - powiedzieć ile coś zajmie. Przeważnie to, co wiemy na początku o produkcie jest zbyt ogólne by można było powiedzieć ile zajmie. Wszystkie niejasności znikają z czasem - kiedy już w trakcie realizacji poznajemy co trzeba stworzyć, by osiągnąć konkretne cele. Żeby było trudniej, koszt realizacji każdej ze składowych projektu zależy od wybranego sposobu rozwiązania. Gdy już dobiegamy do mety, zaczynają się mnożyć błędy, których naprawianie wywołuje następne. 

Jeśli nie da się powiedzieć na kiedy i za ile, to jak w takim razie podejmować decyzje? Przecież każda zmiana powinna się opłacać - oczekiwane korzyści mają być mniejsze niż koszt realizacji. Tradycyjne podejście do projektów zakłada, żeby robić to dwustopniowo. Najpierw podejmujemy wstępną decyzję, potem robimy dokładne analizy, projekty i wyceny, wtedy podejmujemy decyzję właściwą. To jednak żółwi proces, dobry np. w banku. Tam - przynajmniej teoretycznie - można policzyć ile coś da. W rozwoju produktów tempo musi być znacznie żywsze, a korzyści tak bardzo zależą od reakcji użytkowników, że opowiadanie o nich zwykle ociera się o wróżenie. Dlatego warto przyspieszać weryfikację założeń o kosztach i zyskach.

Proponowane podejście wychodzi od zrozumienia ograniczeń, po czym je wykorzystuje. Nie udajemy już, że wiemy ile coś zajmie, ale nadal staramy się to w miarę dokładnie przewidzieć. Potem, realizując, tak podejmujemy decyzje, żeby się zmieścić w przyjętym budżecie i czasie. Wymaga to ofiar (pozornych), oraz dyscypliny (która zawsze jest trudna). Nic tak nie pomaga w realizacji jak narzucony termin - nie trzeba znać metodyk rozwoju oprogramowania, żeby wiedzieć, że praca zawsze wypełnia cały dostepny czas...

Niestety nie mogłem się powstrzymać. Mam.

Przed lekturą tego wpisu, warto zapoznać się z poprzednim: Jak rekrutować. Tym razem o tym, jak przeprowadzić rozmowę z kandydatem.

Jak już pisałem, do rekrutacji musimy być przygotowani. Wiemy więcej niż kandydat napisał w CV. Wiemy kogo i do czego szukamy. Uniwersalna zasada mówi, że szukamy ludzi inteligentnych, którzy osiągają cele i mają niezbędne kompetencje do realizacji zadań na nowym stanowisku. Prowadzimy jedną z kilku rozmów, najlepiej ostatnią, przed decyzją. Poprzednie przeprowadzili nasi najlepsi współpracownicy. Tacy, o których wiemy, że nie zawahają się rekomendować kogoś... lepszego od siebie.

Rozmawiamy przede wszystkim po to, żeby zweryfikować poznane wcześniej informacje. Zadajemy przygotowane pytania, a z wypowiedzi dowiadujemy się, na ile to co wiemy może być prawdą i jak wiele mówi o kandydacie. 

Do sali wchodzi człowiek i jest jakiś. Robi pierwsze wrażenie. Ono jest strasznie ważne, bo cała rozmowa będzie służyła też temu, żeby je obalić. Wydaje się miły? Może tak naprawdę nie jest... Wydaje się dziwny i jakiś nieciekawy? Może to świetny zawodnik, tylko "drugiego rozpoznania". 

Na początek warto się przedstawić - opowiedzieć kim się jest i jaką rolę pełni w rekrutacji. Nawet jeśli gość wie, do kogo przyszedł, ta część jest dobrą rozgrzewką. Potem prosimy kandydata, by powiedział 3 słowa o sobie. Można zapytać o to, co go interesuje i ekscytuje. To dobra rozgrzewka do właściwej rozmowy. Może się zrobić ciekawie - co jest dobrym sygnałem. Nie przeciągajmy jednak fajnej części. Zegar cyka. Ten czas jest cenny dla nas i kandydata. Pytanie, które można sobie zadać, przerywając luźną część "Czy poszedłbym z tym człowiekiem na piwo"? Lepiej, by odpowiedź była pozytywna - będziecie spędzać razem dużo czasu.

Pora na "mięsko". Na początek można poprosić by kandydat opisał jak pracuje - niech po prostu powie jak wygląda jego przeciętny dzień w pracy. Robi sobie tą kawę i... Tu często znajdziemy punkt do zaczepienia. Produktywność? Papierosy? Dostępność? Narzędzia jakich używa? 

To jeden z wariantów pytań dotyczących pracy i kultury organizacyjnej, do jakiej kandydat przywykł. Jest więcej tego typu tricków. Satya Nadella pyta kandydadtów, co powiedzieliby o nich ich szefowie, współpracownicy i podwładni. 

Z informacji zebranych o kandydacie powinniśmy mieć wybrane 2-3 projekty, z których jeden zamierzamy podrążyć. Chcemy ustalić jaki był wkład kandydata. Czy przyczynił się on do sukcesu i jaki to był sukces. Pytamy wg klucza STAR: Situation, Task, Actions, Results. Tak się składa, że te angielskie akronimy czasem pomagają. Ustalamy: jakie było otoczenie - sytuacja rynkowa, umocowanie w organizacji, jego rola. Jakie dostał zadanie, od kogo, w jakiej formie (czy to sensowne forma). Jak się za nie zabrał i jakie podjął działania. Jakie były wyniki, jakie miary? Ludzie nie są skorzy do opowiadania, więc czasem trzeba dopytywać. Ale to taka praca.

Złe sygnały to ważne sygnały - bo to ich tutaj szukamy.

Rekrutując projektantów czy innych specjalistów warto mieć przygotowane gotowe problemy do rozwiązania. Zwłaszcza takie, z którymi sami się mierzymy. Można też poprosić kolegów o przedyskutowanie idealnego rozwiązania. Albo drogi dojścia do niego.

Robimy jak najwięcej notatek. Potem wracamy do nich w dyskusji z innymi osobami, które też rozmawiają z kandydatem - o innych rzeczach. Jeśli wynik jest pozytywny, a stanowisko ważne, warto jeszcze przed zatrudnieniem odbyć kilka rozmów z osobami, z którymi pracował kandydat - najlepiej z tymi, do których mamy jakieś dojście. A potem już tylko negocjacje płacowe, sprawy formalne i rozpoznanie bojem.

O tym już nie napiszę.

Polecam lekturę dwóch teksów, które mnie inspirowały. O rekrutacji pisali: Sam Altman z YCombinator oraz Neil Roseman były vp z Amazon.

Wpis powstał w całości w nowym edytorze Blox.pl