Transkrypcja odcinka

Cześć,

dziś temat zasobów, zasobów tym razem nie tyle ludzkich, nie z perspektywy HR, ale z perspektywy tego co firma, co wasz zespół jesteście w stanie zrobić w danym czasie, na przykład kwartału, miesiąca, w jakiej kolejności zabierać się za realizację masy pomysłów, które płyną do was szerokim strumieniem z różnych źródeł.

Te różne źródła to są najczęściej wasi klienci potencjalni lub obecni, to są wasi znajomi, to jesteście wy sami, jako zespół, to jest wasze szefostwo różnie rozumiane, to może być prezes, może być inwestor, może być znowu wasz klient, który jest waszym szefem.

I zazwyczaj tych pomysłów jest znacznie więcej niż możliwości na ich realizację. I przy wielokrotnych rozmowach ze startupami, szczególnie tymi na początku swojej drogi, ale również tymi już bardziej zaawansowanymi, wyczuwam pewną frustrację wynikającą z tego, że

mamy za dużo pomysłów, a w zasadzie nie tyle za dużo pomysłów, co za mało zasobów.

Nie mamy na to, nie mamy tego, nie mamy takiego zespołu, powinniśmy mieć trzy razy większy, albo dziesięć razy większy zespół IT. I tutaj oczywiście przypomina się takie słynne już w branży technologicznej stwierdzenie, że dziewięć kobiet nie urodzi dziecka w miesiąc. Czyli to, że dodamy nagle bardzo dużą ilość zasobów takich produkcyjnych, na przykład w startupach technologicznych czy w firmach technologicznych dodamy zespoły IT, dotrudnimy kilkudziesięciu programistów, wcale nie oznacza, że proporcjonalnie przyspieszy nam to produkcję, tak, czy wytwarzanie oprogramowania. Owszem, dodanie kilkudziesięciu programistów oczywiście powinno przyspieszyć, ale nieproporcjonalnie, czyli jeśli dodamy ich razy dziesięć, to nie przyspieszymy razy dziesięć. Dodawanie dodatkowych zasobów przy produkcji, szczególnie w produkcji IT, takiej nie wprost liniowo skalowalnej wiąże się z dużymi, może nie tyle, że utrudnieniami, co dodatkowymi wyzwaniami związanymi ze skalowalnością produkcji takiego oprogramowania.

W dużym skrócie, tak półtechnologicznie próbując to tłumaczyć, trudno jest ujednolicić czy zebrać wszystkie potrzeby i wszystkie zachodzące i łączące się ze sobą procesy, elementy aplikacji jednocześnie wielu osobom pracując na tym samym kawałku kodu. I to nawet nie chodzi o zarządzanie wersjami, bo są do tego narzędzia, ale chodzi o takie wewnętrzne zarządzanie produktem, czyli co od czego zależy i który zespół nad czym pracuje, ponieważ w większości wypadków nie są to zupełnie osobne byty, to są wszystkie ze sobą połączone elementy jednego wielkiego mechanizmu. I czasami jak za dużo osób nad tym pracuje, to po prostu okazuje się, że nie ma wystarczającej kontroli po stronie zarządzania produktem, czy to co się tworzy faktycznie nadal stanowi wspólną i spójną całość. Więc nie zawsze drogą do zwiększenia efektywności wytwarzania oprogramowania, czy wytwarzania czegokolwiek w waszej firmie, jest zwiększenie ilości zasobów tych ludzkich, tak, czyli tych osób, które będą nad tym pracowały.

Natomiast to, na co chciałbym zwrócić wam uwagę, to jest to, że

fakt posiadania znacznie większej ilości pomysłów niż zasobów jest nie tylko naturalny, ale i pożądany.

Wyobraźcie sobie taką sytuację, że mielibyście znacznie więcej zasobów chociażby tych technologicznych do wytwarzania oprogramowania, a nie mieli pomysłów. Wtedy oczywiście pojawiają się kwestie kosztów i okazuje się, że tak firma prowadzona byłaby zupełnie nieefektywna kosztowo. Zasoby właśnie te technologiczne, deweloperskie, programistyczne, architektoniczne, systemowe nie są tanie, tak, to są ludzie bardzo dobrze wykwalifikowani a przez to też i drodzy, i raczej w większości wypadków, i to co podkreślam, jest to bardzo naturalne, tych zasobów zawsze będzie mniej niż pomysłów. To niesie za sobą pewne wyzwanie, które polega na tym, jak zarządzić pomysłami, jak je sprecyzować, jak wybrać te najlepsze i jak jednocześnie komunikować się z wszystkimi, którzy te pomysły do nas nadsyłają. I jak wewnątrz zespołu właśnie z troski o jego motywację, o jego takie transparentne zrozumienie całego szerszego dlaczego firmy, szerszej misji i tego, gdzie firma dąży, jak tym zarządzić w sposób wystarczająco dobry, a jednocześnie nieskomplikowany i nie na tyle zaawansowany, żeby był przekombinowany z perspektywy zarówno prowadzenia takiego systemu jak i jego dostępności wewnątrz firmy.

W branży IT znane jest dobrze pojęcie backlogu i roadmapy.

W dużym skrócie backlog to jest lista rzeczy do zrobienia, które sobie czekają na to, aż zostaną zrobione. To są czasami małe projekty, które się łączy w większe projekty tak zwane epiki. I dopóki w backlogu te projekty, elementy sobie leżą, to leżą i czekają. Zazwyczaj, czy bardzo często, jest to taki worek, niestety, często również nieuporządkowany. Bardzo często jest to worek, który jest dostępny w narzędziu takim, do którego dostęp na tylko dział IT i osoby, które muszą mieć do tego dostęp, więc nie jest to powszechnie dostępny link do strony, do której może wejść każda osoba z danej firmy, co bardzo często przekłada się na pewną frustrację zespołu całości firmy, tak, całej organizacji, ponieważ firma nie wie dokąd zmierza, czy ludzie w firmie nie wiedzą dokąd firma zmierza.

Kolejny efekt jest taki, że jak już mamy ten backlog, to ktoś według jakiegoś trybu musi wybrać, co z tego backlogu, co z tego worka wyciągnąć do roadmapy, czyli do planu na najbliższy, powiedzmy, kwartał, miesiąc, kilka przebiegów w zależności od tego, jak funkcjonuje firma. I to co chciałbym wam dzisiaj przedstawić, i to co się sprawdziło bardzo ciekawie w AirHelpie to jest pewna taka bardzo prosta matryca pomysłów, często porównujemy też to do rodzaju business case, bo jest to narzędzie, które wspiera decyzje w wyborze właściwych projektów. Jakie mieliśmy wyzwanie w AirHelpie w pewnym momencie? To już było kilka lat temu, więc na szczęście udało się z tym uporać, ale na początku jak byliśmy jeszcze młodszą organizacją, to był mniej więcej okres, kiedy mieliśmy od 50 do 300 osób w firmie, mieliśmy duże wyzwanie polegające na tym, że pomysły płynęły do nas szerokim strumieniem z wielu źródeł i zarówno od nas jako od zarządu, od założycieli, od inwestorów, ale w dużej mierze też płynęły pomysły od pracowników działu operacyjnego. Tych pomysłów było dużo, pomysły często były bardzo drobne, ale usprawniające pracę agentów w dziale operacyjnym. I w pewnym momencie

był problem taki, że każdy pomysł jaki przychodził do osoby, która koordynowała kolejkę zleceń, był przekazywany do działu technologicznego z prośbą o wycenę, tak, czyli pytanie, ile by wam czasu zajęło zrobienie tego i tego.

I może lekko tutaj przesadzę, ale byliśmy bardzo bliscy sytuacji, w której większość czasu, a zdecydowanie zbyt duża część, ale myślę, że nawet mogę powiedzieć, większość czasu działu produktowo-technologicznego była zajęta wycenianiem różnych elementów zamiast tak naprawdę wdrażaniem ich w życie. I efekt był taki, że czas był wykorzystany nieefektywnie, bardzo mało było wdrażane w porównaniu do tego, co mogłoby być i de facto frustracja wszystkich rosła, bo pomysły napływały, były wyceniane i już nie było czasu, żeby cokolwiek z tego wdrożyć. I co wdrożyliśmy w tym momencie, jakby jakie proste narzędzie udało nam się zastosować? Narzędzie w zwykłym Spreadsheetsie Googla.

Oczywiście są backlogi w JIRA’rze, w innych narzędziach, które używa dział IT, ale nie spełniały one tego warunku powszechnej dostępności wewnątrz firmy. Więc zdecydowaliśmy się na Google Spreadsheet z ustawieniami, że każdy, kto ma link w domenie airhelpowej, mógł ten plik zobaczyć. I wszystkie pomysły, niezależnie od źródła, z którego one pochodziły, czy to byli pracownicy, czy to byli inwestorzy, zarząd, klienci, to wszystkie te pomysły trafiały do jednego worka. Był prosty opis tego pomysłu, jakich obszarów on dotyczy, spodziewane przez zgłaszającego ten pomysł efekty, czyli jakby w jakim obszarze co się usprawni dzięki wdrożeniu tego konkretnego elementu, tej funkcjonalności. I na tej podstawie jedna osoba wszystkie te pomysły oceniała, bardzo zgrubnie, z dwóch stron. Pierwszy punkt to był wpływ na biznes, czyli ile według tej osoby dobrego wdrożenie tej funkcjonalności da. I skala była od 1 do 5, 1 – bardzo mało, 5 – bardzo dużo. I oczywiście to była kwestia na tym etapie jeszcze bardzo subiektywna, ale przez to, że wszystkie tematy były oceniane przez tą samą osobę, to jakiekolwiek spaczenie tej wyceny było relatywnie niewielkie, bo ta sama osoba tak samo oceniała, znaczy według tego samego kryterium wszystkie pomysły. A że była to osoba, która wdrożyła już kilkadziesiąt różnych funkcjonalności właśnie od pomysłu do produkcji w dziale technologicznym, to miała wyczucie, jakie tak naprawdę może mieć przełożenie każdy kolejny pomysł na nasz biznes. Drugim elementem był szacowany czas czy koszt stworzenia. Natomiast tutaj istotnym jest elementem, że to jest szacowany, znowu, szacowany przez tą samą osobę bardo zgrubnie, i tutaj skala była od 5 do 1. Czyli jeśli coś było bardzo tanie to dostawało 5 punktów, jak coś było bardzo drogie, to dostawało 1 punkt. I tu były wytyczne tego typu, że bardzo tanie to oznacza, że to jest na przykład tylko zmiana tekstu na stronie, tak, czy zmiana kopii, bardzo drogie, to znaczy, że jest duża funkcjonalność do napisania od zera. A gdzieś pośrodku były przeniesienie funkcjonalności z jednego miejsca, w którym się sprawdziła do innego, w którym też może się przydać analogiczna, tak, czyli pewne jakieś analogie. Albo może rzeczywiście zmiana kopii, ale już bardziej skomplikowana, bo w kilkunastu językach dynamicznie w zależności od tego, gdzie się znajduje, powiedzmy, użytkownik, na jakim etapie. Czyli gdzieś pomiędzy tymi skrajnościami od prostej zmiany tekstu w jednym miejscu do zaawansowanych dużych funkcjonalności ta osoba umieszczała ten pomysł, czyli 5 do 1 skala w dół tym razem. Następnie bardzo proste przemnożenie dwóch składników, czyli tego wpływu na biznes razy koszt stworzenia. I tu, jak się można domyślać, skrajne wartości tego mnożnika czy wyniku tego liczenia, był od 1 do 25.

1 jest wtedy, kiedy projekt jest bardzo drogi do wykonania, a do tego ma mały wpływ na biznes, a drugi skrajny przypadek to jest kiedy coś jest bardzo tanie do wykonania i ma potężny wpływ na biznes. Czyli można mówić 25 punktów lub mniej, tak, jeśli projekt był mniej atrakcyjny. Na tym etapie było ponad 100-kilkadziesiąt pomysłów, zostały one posortowane malejąco według tego wskaźnika i zajmowaliśmy się tylko tą górną 20-procentową częścią całego zestawu, poniekąd wedle zasady Pareto, tak, czyli że 20% danego obszaru zrobi nam 80% wyniku. I tutaj też tak było, nawet ta zasada Pareto była wzmocniona. I z tych 20%, mimo że możliwości tak znowu, pi razy drzwi, bardzo, bardzo zgrubnie, mieliśmy na zrealizowanie koło, powiedzmy, 10 takich projektów czy pomysłów w skali kwartału, to patrzeliśmy już nie na 100-120, tylko na 20-kilka projektów pod kątem dalszej dogłębnej wyceny. Efekt był taki, po pierwsze, mieliśmy znacznie mniejszą listę rzeczy, którymi zawracaliśmy głowę działom technologicznym, czyli nie prosiliśmy ich o wycenę rzeczy, które już jakby z daleka widać, że są mniej istotne niż pozostałe. Po drugie tak powstała lista uszeregowana malejącym wskaźnikiem, była publicznie dostępna wewnątrz firmy. Czyli każdy kto chciał, mógł zobaczyć, na jakim etapie jest pomysł, który dana osoba zgłosiła. I w momencie, kiedy ten pomysł był zgłaszany, to ta osoba mogła zobaczyć, gdzie wylądowała na tej liście. I jak wylądowała w określonym miejscu, to albo mogła w jakiś sposób zakwestionować, czy, powiedzmy, no niejako odwołać się od tej decyzji, na przykład tłumacząc, dlaczego uważa, że wpływ na biznes jest większy niż zostało to oznaczone, albo dlaczego uważa, że czas szacowany wytworzenia tego elementu będzie jednak mniejszy.

I czasami to rzeczywiście pomagało zrozumieć lepiej pomysł, który został zgłoszony, bo może coś uciekło, że tak powiem, na etapie rozumienia tego pomysłu. A czasami po prostu osoba miała jasny komunikat, rzeczywiście są lepsze pomysły od mojego, więc grzecznie poczekam. Więc przynajmniej unikaliśmy frustracji tej osoby wynikającej z tego, że zgłosiłem/zgłosiłam super pomysł, a to gdzieś tam utknęło. Co więcej, w momencie kiedy założyciele, czy prezes całej grupy, wysyłał informację, słuchajcie, taką i taką funkcjonalność trzeba koniecznie zrobić, to dopóki nie było takiego backlogu, takiej listy, to łatwo było rzucić wszystko i robić tylko to, co założyciel każe, no bo przecież tak trzeba. A w momencie kiedy się pojawiła taka lista, to niezależnie od tego skąd przychodził pomysł, staraliśmy się w taki sam sposób te pomysły szeregować i mówić założycielowi, słuchaj, super, fajny pomysł, ale jesteś 34. I to otwierało pewną dyskusję, tak, i bardzo często okazywało się, że założyciel wcale nie miał na myśli, że mamy teraz wszystko rzucić i robić to, tylko w dobrej woli przekazywał nam informację, słuchajcie, taka funkcjonalność też by się przydała, rozważcie, gdzie to zrobić, w jakim momencie i czy. I okazuje się, że w zupełności taka komunikacja wystarczała. Efektem było też to, że frustracja wszystkich osób zgłaszających pomysły, istotnie zmalała. Nie można powiedzieć, że wszystko to jakby rozwiązało oczywiście wszystkie problemy, bo nadal jeśli z perspektywy firmy jakiś problem jest mało istotny, czy ma niewielki wpływ na biznes, to może mieć wielki wpływ na pracę konkretnej osoby, która w danym dziale, w danym elemencie procesu spędza więcej swojego czasu i taka funkcjonalność bardzo by tej osobie pomogła.

Więc nie można powiedzieć, że taki sposób rozwiązuje wszystkie możliwe problemy, ale bardzo pomaga w utrzymaniu w ryzach naszych zasobów, w utrzymaniu w ryzach nawet naszych pomysłów bardziej niż zasobów, pomaga lepiej wykorzystać zasoby, które nam są dane.

Pomaga nam też stwierdzić, o ile te zasoby powinniśmy i warto je zwiększać, bo widzimy z każdego takiego planowania, powiedzmy, kwartalnego czy miesięcznego widzimy, co jest pod kreską, widzimy, co nie zostanie zrobione, co nie zostanie stworzone. To jest bardzo istotny element, o którym często się zapomina przy planowaniu pracy w firmach technologicznych, że należy patrzeć nie tylko na to, co jakaś grupa czy zespół uznała, że warto zrobić w kolejnym kwartale, tylko przede wszystkim trzeba patrzeć na koszt alternatywny, czyli ile stracimy przez to, że nie zrobimy pierwszej, drugiej, trzeciej rzeczy, która jest pod kreską tego, co da się wykonać. Takie ułożenie pomysłów w firmie pomaga nam na lepsze zagospodarowanie tymi zasobami, na bardziej transparentne komunikowanie się wewnątrz organizacji odnośnie tego, co robimy, dlaczego robimy, w jakiej kolejności i pomaga też na lepsze strategiczne dopasowanie tego tak naprawdę co robimy. Bo w jednym miejscu mamy zebrane nasze plany w najbliższym czasie, również te, które nie weszły do realizacji, ale które grzecznie czekają.

I właśnie z troski o tą ludzką twarz biznesu, z troski o to, jak budowana jest atmosfera współpracy w firmie i jak ważna jest motywacja osób, które przekazują nam pomysły do realizacji. Z tą myślą zachęcam was do stosowania tej prostej metody i do transparentnego pokazywania wewnątrz firmy, jakie są plany, co weszło, co nie weszło z pomysłów, które przysłaliście, i zachęcam was do tego, żeby odpowiadać i szeregować pomysły, które przychodzą do was z zespołu. To jest niesamowicie motywujące, jeśli jest ten feedback, jeśli jest ta informacja zwrotna, a bardzo przeszkadzające i rozbijające zespół, kiedy pomysły trafiają w próżnię. Jeśli pomysły trafiają w próżnię, one bardzo szybko przestaną być generowane. To zabija motywację, to utrudnia rozwój firmy we właściwym kierunku. Polecam serdecznie i życzę miłego dnia.

Kliknij w obrazek, aby posłuchać lub nagrać komentarz głosowy