Dlaczego nie każdy może tworzyć produkty?

28 czerwca
Sergey Berezhnoy
Dlaczego nie każdy może tworzyć produkty?
Nieustająca bitwa pomiędzy adeptami sztuki tworzenia produktów i specjalistami pracującymi w outsourcingu, moim zdaniem, prędko nie zwolni. Logiczne argumenty stają się rzadkością, a dysputy pomiędzy dwiema grupami profesjonalistów z branży IT (różniącymi się rozmiarem, ale w tym samym stopniu istotnymi) coraz bardziej przypominają kontrowersyjny spór pomiędzy fanami Apple i Samsunga. Prawdopodobnie nie ma w tym nic złego. Ale zamiast stawać po stronie jednego z dwóch skonfliktowanych podejść, postaram trzymać się faktów.

W pewnym momencie byłem współtwórcą firmy produktowej i popełniłem w tym czasie wiele błędów. Następnie pracowałem w outsourcingu, a właściwie przeskakiwałem pomiędzy tymi dwoma typami firm, szukając złotego środka. Obecnie mam okazję obserwować kierunek, w którym podąża DataArt od prawie roku, kierując jednocześnie przejściem w stronę podejścia produktowego w rozwoju oprogramowania. Właśnie o tym chciałem dziś opowiedzieć.

Napisałem artykuł związany z tym, o czym mówiłem w trakcie IT talk w Kijowie, jednego ze spotkań organizowanych przez DataArt, na które zapraszamy wszystkich pasjonatów IT i tematów pokrewnych. Nie byłem w stanie ująć w swojej prezentacji wszystkich możliwych faktów na potwierdzenie prezentowanych przeze mnie tez, ale mam nadzieję, że ten artykuł będzie jednak wystarczająco przekonujący.

Sny o produktach

W wielu krajach społeczność technologiczna koncentruje się wokół outsourcingu. Mówi się, że żołnierz, który nie śni o byciu generałem, jest złym żołnierzem. Tę samą prawidłowość można odnieść do profesjonalisty z branży IT, który nie ma ochoty stworzyć własnego produktu i stać się miliarderem albo co najmniej milionerem, i to zupełnie zdrowe.

Dlaczego wszyscy marzą o tworzeniu własnych produktów? Moim ulubionym wyjaśnieniem tego zjawiska jest błąd przeżywalności. Historie, które znamy łączy jedno – często opowiadają o ludziach, którzy odnieśli sukcesy za sprawą, po prostu, odrobiny szczęścia. Nie przyznają się do tego i twierdzą uparcie, że to, co osiągnęli jest wynikiem ich ciężkiej pracy. Własny produkt to przecież projekt na inną skalę, a do tego czysty zysk. Właśnie dlatego każdy chce stworzyć, na przykład, własny Snapchat. Przy okazji – jeśli sprawdzilibyśmy, jak wielu czytelników tego tekstu korzysta z tej usługi, prawdopodobnie okazałoby się, że nie jest ich wcale tak wielu. To przydatna informacja z punktu widzenia analizy potrzeb młodzieży i chęci stworzenia rozwiązania na miarę ich zainteresowań.

Outsourcing to biznes usługowy, którego rozwój zawsze manifestuje się powiększaniem się firm. Z upływem czasu tego typu wzrost jest potrzebny, by pracować z – na przykład - dziesięciokrotnie większą liczbą klientów. Czasami po prostu potrzebujesz do tego 10 razy więcej ludzi, ponieważ wzrost ten ma charakter nieliniowy. Dla developera nie ma to jednak znaczenia.

Istnieją dwa czynniki, dzięki którym praca w firmie produktowej jest postrzegana jako bardziej atrakcyjna – pieniądze i prestiż. Programista z większą ochotą podkreśli, że jest pracownikiem Facebooka niż opowie o tym, jak świetnie jest pracować w projekcie outsourcingowym. Firmy usługowe jako takie dużo rzadziej są rozpoznawalne. A kiedy twój produkt jest rozpoznawalny, łatwiej o rozgłos. I nie ma tu znaczenia czy praca specjalisty, który go stworzyła była interesująca czy zupełnie nudna.

W firmach usługowych poczucie przynależności i własności jest, generalnie, słabsze. Wewnętrzne startupy i inkubatory biznesowe, z drugiej strony, uważają poczucie własności za niezbędne, bo to, co je napędza to myśl o rozwijanym produkcie.

Gotowi do drogi

Jeśli chcesz, by firma świadcząca usługi dążyła w kierunku podejścia produktowego, powinieneś rozumieć, że to zupełnie inny rodzaj biznesu. Inne motywacje będą kształtowały zespoły. Wymagania dotyczące celów biznesowych przez specjalistów technologicznych również ulegną zmianie. Każdy profesjonalista powinien wiedzieć, w jaki sposób tworzony przez zespół projekt zarabia na rzecz klienta – od kadry managerskiej, po programistów i specjalistów QA.

Wyobraź sobie, że masz do czynienia z jakimkolwiek biznesmenem. Powiedzmy – właścicielem mobilnego stoiska z kawą. Zapytaj go, ile zarabia, jak wiele osób obsługuje codziennie, jaki jest średni dzienny zysk, a jakie koszty średnie i koszty ryzyka. Właściciel biznesu będzie prawdopodobnie potrafił odpowiedzieć na każde z tych pytań. A kiedy zdecyduje się na kolejne samochody wyposażone w sprzęt do serwowania kawy, wyszkoli pracowników i upewni się, że jego zespół rozumie wszystkie wymienione zjawiska. Dokładnie to powinno być brane pod uwagę przez każdego, kto pracuje nad produktami – na tych czynnikach opierają się wszystkie decyzje dotyczące przyszłości produktu.

Relacje pomiędzy specjalistami i klientami budują się na różne sposoby. Firmy outsourcingowe umieszczają zazwyczaj pomiędzy dwiema stronami managerów na kilku poziomach, chroniąc developerów przed koniecznością myślenia o aspektach biznesowych. Podejście produktowe wysuwa ich naprzód, gdzie komunikują się z klientami w kwestiach związanych z technologią. Na drugim biegunie, daleko od tradycyjnego modelu usługowego jest Booking, gdzie nie znajdziemy testerów ani managerów, którzy odpowiedzą na pytanie „wypuszczać czy nie”.

W takiej sytuacji można wdrażać nowe funkcjonalności jednym ruchem. Nie chodzi o to, że nie mają ludzi zajmujących się poszczególnymi czynnościami, kod po prostu najpierw przechodzi przez rundę testów AB obejmujących miliony opcji. Głównym parametrem jest OCR (Order Conversion Rate). Jeśli liczba zamówień obejmujących nowe funkcjonalności rośnie, robot zwiększa ruch. Jeśli spada – robot usuwa tę funkcjonalność z testów, a autor dostaje maila: „Dzięki, twój pomysł przegrał.”. Wskaźniki biznesowe stają się zatem jednostką miary w zakresie podejmowanych decyzji. Wiadomo przecież, że bierność czasami okazuje się lepszą strategią niż tworzenie niepotrzebnych funkcjonalności.

Kryteria sukcesu

A teraz wyobraź sobie, że jesteś właścicielem albo CEO tej samej firmy z tymi samymi ekspresami do kawy. Z jakiegoś powodu zlecasz na zewnątrz stworzenie systemu IT dla twoich kawiarni. Jakie informacje powinien otrzymać zespół, by rozwiązanie było efektywne z biznesowego punktu widzenia. Wizja biznesowa i grupa docelowa: kto kupuje od ciebie kawę i gdzie masz największy ruch. Ponadto wskaźniki, które sygnalizują, że produkt powinien być poprawiony lub zmieniony. W takim przypadku takim wskaźnikiem będzie średnia ilości kupowanych dziennie kaw. Eksperymenty można przeprowadzić relatywnie szybko – spędzić jeden dzień na miejscu i przeanalizować warunki pogodowe. Nie trzeba do tego być ani Einsteinem ani Mikołajem Kopernikiem. By sprawić, by tworzony produkt dedykowany kawiarni odniósł sukces, musimy jednak odpowiedzieć na następujące pytania:

  1. Kto i w jaki sposób może określić, czy projekt odniesie sukces czy nie?
  2. Kto zapyta, czy projekt odnosi sukces?

Jeśli forma oferująca usługi nie ma na co dzień w zespole osób, które są w stanie odpowiedzieć na te dwa pytania, wtedy nie można twierdzić, że działa zgodnie z zasadami modelu produktowego. Szczerze mówiąc firmy czasami same nie znają odpowiedzi, ale to błąd. I w tych przypadkach TEN project manager (uwielbiany przez wszystkich) wkracza na scenę. Ten, który przelicza trudne do zrozumienia wskaźniki, porównując cenę auta z miesięcznymi rachunkami za prąd, albo robiąc cokolwiek innego. Nie jest to trudne, a jeśli włożyć w to odrobinę wysiłku, można przez całe miesiące wydawać się mądrzejszym niż inni.

 Ekspresy do kawy i „kawa na kółkach” to biznes, który działa zgodnie ze zrozumiałymi schematami. IT zajmuje się tworzeniem innowacyjnych - z biznesowego punktu widzenia - produktów. Przynajmniej i ja i reszta świata chce myśleć, że za każdym razem tworzymy coś nowego. Ale przekazanie prawdziwego sensu danych wskaźników biznesowych jest niemniej istotne. Moim zdaniem, większość firm nie przewiduje do tego celu osobnego stanowiska.

Problem pogłębia fakt, że większość tworzonych produktów ma opóźniony feedback. Z kawą jest prosto, właściwie wszystko wiadomo „tu i teraz”. W przypadku rozbudowanych gier online jest już odrobinę gorzej – użytkownicy nie znikają z chwilą, kiedy zaczynają się nudzić. Rezygnują z grania powoli – na początku to zaledwie ułamki procentów. I, po pierwsze, powinno się zwrócić uwagę na to, czy to zjawisko związane z czynnikami zewnętrznymi, wewnętrznymi czy okresowy spadek zainteresowania. Można naprawić sytuację w półtora miesiąca (w najlepszym wypadku), a czasami trwa to kilka razy dłużej.

Firmy outsourcingowe fantastycznie realizują część techniczną, ale nie wiedzą, w jaki sposób efektywnie monitorować biznes. Jednocześnie większość zgłaszających się do nich klientów nie ma związku z IT, co znaczy, że także nie widzą w jaki sposób patrzeć na produkt z punktu widzenia technologii. I to właśnie rodzi problem.

Głębiej w biznes!

W nierobieniu produktów nie ma nic złego. Outsourcing to również jasna i konkretna ścieżka biznesowa. Zupełnie inną sprawą jest, że łatwiej zrozumieć, kiedy rozwiązanie problemu tkwi poza technologią wtedy, kiedy patrzysz na projekt z pozycji managera produktu.

Z mojego własnego doświadczenia wynika, że kiedy tworzysz oprogramowanie, zwracasz uwagę na architekturę, niezawodność, funkcjonalność, itd. Kiedy tworzysz produkt najbardziej doceniasz czas. To reguła – project manager uważa zadanie za zakończone, kiedy zadania są zamknięte i osiągnięto określone wskaźniki jakości. Dla managera produktu kryteria jakości redukują się do wskaźników biznesowych. Kiedy znajdziesz się w tym miejscu stwierdzisz, że finanse i marketing nie bez powodu znajdują się w programie MBA.

***

Przejście w kierunku podejścia produktowego wydaje się atrakcyjne przede wszystkim dlatego, że otwiera drogę na światowe rynki. Kiedy oferujesz gotowy produkt IT, klienta nie obchodzi, czy został on stworzony w Belgii, Kenii czy Chinach. Jeśli oferujesz usługi, znaczenia nabierają: bariera językowa, strefy czasowe i inne tego typu czynniki.

Firmy outsourcingowe mają sporo czasu, by przygotować solidną bazę technologiczną, ale taka rezerwa jest nie tylko korzyścią, ze względu na to, że firmy mają wykwalifikowanych specjalistów, ale również minusem – ponieważ są przyzwyczajeni do rozwiązywania wszystkich problemów w cyklu produkcji oprogramowania. I im większy jest twój team, tym trudniej zmienić nastawienie jego członków.

Tworzenie produktów bez wiedzy biznesowej jest niemożliwe. Jeśli to twój cel, skup się na wpojeniu tej wiedzy wszystkim, którzy będą brali w tym procesie udział. Aby upewnić się, że przejście w stronę nowego modelu nie jest zbyt trudne dla tych, którzy muszą podążyć za najbardziej radykalnymi zmianami, ostrożnie rozkładaj siły. Czasami pomaga tu fizyczna separacja – rozproszone zespoły i odmienny od tradycyjnego sposób działania może pomóc.