Jak prowadzić dev shop: przyciąganie klientów (cz. 4)

Jak przyciągnąć klientów? To pierwsze i najważniejsze pytanie, jakie trzeba sobie zadać przed założeniem firmy. Marketing i sprzedaż są równie ważne dla dev shopu, jak każdego innego przedsiębiorstwa.

Oferta definitywnej wartości

Wierzę, że oba wspomniane projekty odzwierciedlają definitywną wartość, jaką dev shop może wnieść do społeczności. Definitywna wartość, jaką firma programistyczna może przekazać społeczności, wynika z możliwości wielokrotnego poradzenia sobie z tym samym problemem. To doskonała okazja do stworzenia zasadniczo lepszego rozwiązania niż to, które jest używane przez społeczność. Może ono przybrać wiele form: nowego frameworku, biblioteki, nowej architektury lub wzorca projektowego, naprawy błędu albo po prostu sprytnego sposobu, z którego inni mogą skorzystać.

Środki, które firma programistyczna zarabia dla społeczności wykonując projekty, zamiast trafiać do firm marketingowych są reinwestowane w tę społeczność. To jest niezwykle szlachetny cel, który osobiście bardzo sobie cenię.

Zarządzanie czasem

Mała firma o ograniczonych zasobach musi znaleźć sposób, by wnieść znaczący wkład do społeczności. Różne akcje marketingowe i działania związane z budowaniem wizerunku pracodawcy można połączyć ze sobą lub traktować jako uzupełniające. Dodatkowo, istnieje kilka kreatywnych taktyk ułatwiających zaistnienie w społeczności w pierwszych dniach działania firmy programistycznej. Po pierwsze… praca po godzinach. W ten sposób udało mi się wydać pierwszą wersję Waffle. W tamtym czasie nie było możliwości, żeby upchnąć tę pracę w moim napiętym harmonogramie. Choć taka metoda nie jest zbyt zrównoważona i nie skaluje się, to świetny sposób na rozpoczęcie działalności. W realnym życiu trudno ruszyć z marką premium bez dodatkowego wysiłku.

Ważne jest także stopniowe wyodrębnianie. Biblioteki i frameworki często mają swój początek w drobnym kodzie helpera albo warstwie abstrakcji w kodzie klienta. Z czasem kod może być skopiowany jako fragmenty lub wyodrębniany do szablonu. Kolejnym krokiem powinno być przetestowanie go w więcej niż jednym projekcie, a następnie wyodrębnienie do małej biblioteki, która z czasem może rozwinąć się do pełnej postaci. Aby w pełni rozwinąć projekt biblioteki, można zrobić z niej backport do projektów klientów. Pozwoli to na wprowadzanie małych zmian iteracyjnych, które można rozliczyć z klientem. Uważam, że ta praktyka jest fair, o ile klient się na nią zgadza. A daje mu to konkretną wartość, ponieważ otrzymuje darmowe aktualizacje rozwijane w innych projektach.

Uwaga: warto jasno określić w umowie z klientami, że można wyodrębniać kod. Zawsze najlepiej zapytać w każdym konkretnym przypadku i upewnić się, że nie zagraża to konkurencyjności klienta.

Warto także organizować od czasu do czasu jednodniowe wydarzenie dla całej firmy, mające na celu tworzenie bibliotek, pisanie tutoriali i wpisów na blogu, łatanie projektów open-source i kreowanie innych form wkładu w społeczność. Nie tylko przynosi to natychmiastową wartość, ale także pomaga ludziom rozwijać się i uczy, jak działać w społeczności. Dobry wewnętrzny hackaton powinien być podsumowany prezentacją i małą imprezą firmową.

Przed dołączeniem do Ethworks brałem udział w wewnętrznych hackatonach, ale nie było presji na tworzenie wkładu dla społeczności, więc zdecydowana większość prac trafiła do kosza. Niemniej było to dobre ćwiczenie budowania zespołu, dające ludziom możliwość próbowania nowych rzeczy. Gdy jednak twoja praca nie jest wykorzystywana przez nikogo i idzie na marne, nie jest to zbyt motywujące. Zdecydowanie wolałbym napisać mały tutorial, który pomaga ludziom, niż napisać kiepską aplikację, której nikt nie używa.

W praktyce publikowane było 40-60 proc. pracy zespołu z hackatonu. Wynik powyżej 50 proc. to bardzo dobry rezultat, ponieważ jeden dzień to mało, a ludzie muszą mieć w tym czasie możliwość eksperymentowania i popełniania błędów.

Inną świetną techniką jest zapewnienie inżynierom czasu wolnego od projektów, aby mogli tworzyć wkład w społeczność, publikować i prezentować. Kiedy takie działanie jest połączone z punktacją i systemem nagród, może być bardzo skuteczne. Nagrodą za zdobyte punkty zwykle jest możliwość wzięcia udziału w prestiżowej konferencji. Zazwyczaj zachęci to część pracowników do aktywnego udziału w akcji, ale trudno oczekiwać, że zaangażuje się w nią większość.

W końcu, gdy firma nieco się rozrośnie, sensownym posunięciem może być zatrudnienie dedykowanej osoby lub wewnętrznego zespołu OSS (Open Source Software). Jako nieco kosztowna, jest to strategia skierowana do nieco większych firm, która umożliwia im zrównoważony wzrost. Chociaż może być ekwiwalentna do prowadzenia solidnej strategii opartej na reklamach, to jednak generuje znacznie wyższej jakości leady.

Każda z tych metod wymaga znaczących nakładów pracy i bez lidera firma będzie miała trudności z ich wdrożeniem. Raz po raz niezbędne będzie przejęcie wiodącej roli przez CTO.

Konwersja

Można znaleźć wiele wysokiej jakości materiałów, książek i usług konsultingowych ułatwiających przekształcanie leadów w projekty. Dlatego ograniczę się do elementu, który jest bardzo ważny, a przy tym słabo opisany. Chodzi o zaangażowanie osoby technicznej. Jeśli kierujemy swoje działania do społeczności programistycznej, możemy oczekiwać, że najlepsi potencjalni klienci są technicznie biegli i wymagający. W takim razie przedstawiciel handlowy nie przekona ich, że nasza firma jest właściwym wyborem. Z drugiej strony, gdy ważna osoba techniczna w naszej firmie (w rodzaju CTO lub CEO) będzie poświęcać zbyt wiele czasu na rozmowy telefoniczne, to prawdopodobnie zaniedba inne obowiązki. Właśnie na tym etapie przydaje się kwalifikacja leadów.

Jednym z powszechnych sposobów kwalifikowania leadów jest podział ich na grupy, np. wysokiej, średniej i niskiej jakości. Bez zagłębiania się w różne algorytmy czy skalę niepewności takiego podziału, można oprzeć go na kilku założeniach. Leady wysokiej jakości, to te co do których jesteśmy pewni, że chcemy je skonwertować. Tacy klienci powinni trafić bezpośrednio do CEO lub CTO i zostać skonwertowane z pomocą działu sprzedaży. Leady średniej jakości to z kolei takie, z których niektóre chcemy skonwertować. Tacy klienci powinni trafić do zespołu sprzedażowego i mieć jedynie nieznaczne wsparcie ze strony osób na najwyższych stanowiskach. I wreszcie leady niskiej jakości, których prawdopodobnie nie chcemy przekształcać, chyba że mamy dostępnych wolnych specjalistów. Tacy klienci powinni trafić do działu sprzedaży, a jeśli nie zostaną przeklasyfikowani w trakcie procesu sprzedaży, to powinni zostać podzieleni pomiędzy inne firmy programistyczne w ramach umów o dzieleniu się projektami.

Podsumowanie

Moją pierwotną inspiracją do wypróbowania strategii opisanej w tym odcinku była brazylijska firma Plataformatec oraz José Valim, który był współtwórcą Railsów, a później stworzył swój własny język – Elixir. Na przestrzeni lat widziałem różne warianty tej strategii stosowane z sukcesem przez wiele niszowych firm programistycznych. Większość z nich została już przejęta i zrobiło się miejsce dla następców.

Udało nam się również pomyślnie zastosować ją w Ethworks. W szczycie naszego rozwoju – tuż przed przejęciem – mieliśmy listę oczekujących klientów i odrzucaliśmy kilka leadów tygodniowo. Nadmiarowe projekty dzieliliśmy z trzema różnymi dev shopami – niektóre z nich stały się w projektami wieloletnimi. Mogłem zadzwonić wtedy do dowolnego klienta i zapytać: „Czy chcesz powiększyć zespół?” i wiedziałem, że w większość przypadków odpowiedź brzmiałaby: „Tak”. Nasi klienci należeli do najciekawszych i najbardziej renomowanych marek w obszarze Ethereum.

Ponad rok po przejęciu i zamknięciu naszych kanałów marketingowych – w środku „kryptozimy” – wciąż od czasu do czasu napływają do nas potencjalne zlecenia, które być może wystarczyłyby, aby prowadzić nadal małą firmę. Z tak dużym potokiem leadów, można by zadać pytanie, dlaczego nie rozwijaliśmy firmy dalej. Aby wytłumaczyć, trzeba odwołać się do modelu rozwoju firm programistycznych. I o tym będzie ostatni odcinek naszej serii: „Wzrost i struktura”, który ukaże się w kolejnym wydaniu CRN Polska.