Saas Porażka #1: Cała prawda o tym, jak zawaliłem realizację aplikacji typu SaaS (i co możesz na tym zyskać)

Dzisiaj wracam z opowieścią, która nigdy nie wyląduje w żadnej z poczytnych książek jakiegoś guru marketingu czy innego kołcza. Będzie to historia mojej porażki. Po prostu nie dowiozłem. Będzie to historia pomysłu, który nie daje mi spokoju, choć myślałem, że już się z nim rozprawiłem. (Pewnie ten syndrom ma jakąś mądrą nazwę).

Tym razem jednak pomysł powrócił w zupełnie innej formie, o czym opowiem w dalszej części tekstu. Przy okazji postaram Ci się przekazać bardzo dużo praktycznej wiedzy z zakresu designu i architektury oprogramowania, klocków DDD oraz pozyskiwania wymagań biznesowych. Dowiesz się też, jak Twój kolega po fachu chciał na Tobie zarobić – ale spokojnie, mniej niż na działach HR. ;) Ja z kolei definitywnie rozprawię się z tym konceptem i podbiję sobie statsy, bo wiadomo: wincyj kodu i ćwiczeń = wincyj skilla. Po wszystkim zyskam +5 do mądrości na karcie postaci.

Nowe odcinki cyklu będą pojawiały się regularnie na devstyle.pl, a ich pełną listę znajdziesz tutaj!

Do rzeczy: pomyślałem, że skoro mam w głowie w miarę dobrze poukładaną domenę biznesową, to przedstawię Ci ją z najdrobniejszymi szczegółami. Poznasz moje motywacje i tok myślenia. Zero ściemy. Później krok po kroku będę ją implementował i pokazywał cały proces. Dzięki temu zobaczysz, jakie decyzje architektoniczne dotyczące designu będę podejmował, z jakich narzędzi DDD skorzystam i jak mi to wyjdzie. Ostatecznie spróbujemy to odpalić. (Może uda się zaprosić kogoś do dyskusji, gdzie i jak zrobić to najlepiej?) Ale najważniejsze zostawiłem na koniec: to będzie projekt open source! Jeśli zechcesz, będziesz mógł w nim uczestniczyć przez „forkowanie”, łatanie bugów i tworzenie PR-ów. A jak model biznesowy Ci się spodoba i uznasz, że masz żyłkę marketera i zawsze marzyłeś o własnym start-upie, będziesz mógł go wziąć, odpalić i zarabiać na nim miliony.

Skąd takie podejście? Dlaczego nie wyklepię projektu po kryjomu w piwnicy i samemu nie podbiję świata?

Po pierwsze, o czym już wspomniałem: chcę raz na zawsze rozprawić się z tym pomysłem. Podoba mi się ta idea od strony biznesowej i technicznej – wiem, jak chciałbym to zaimplementować.

Po drugie, chciałbym żeby projekt miał wartość edukacyjną zarówno dla Ciebie, jak i dla mnie.

Po trzecie, możliwe, że biznes ten wydaje się atrakcyjny wyłącznie mnie samemu. Wypadałoby go zweryfikować jeszcze przed implementacją. Gdyby się okazało, że to klapa, oszczędziłoby mi to dużo czasu i nerwów.

Po czwarte, w momencie kiedy miałem już prototyp, nastąpiła u mnie zmiana priorytetów i cały ogrom pracy, jaki trzeba było włożyć w marketing, żeby zostać zauważonym, spadł daleko, daleko na koniec listy. Taki projekt to bardzo duża odpowiedzialność. To jak kupienie sobie małego słodkiego maine coona, który gdy dorośnie, może Cię zeżreć. (Jak myślicie, dlaczego Aniserowicz nabył 20 książek o tym, jak wytresować kota?)

Rozkład jazdy

Przedstawię teraz, co będzie wchodziło w skład serii artykułów, czyli tematy, którymi się zajmiemy – z zastrzeżeniem, że ich kolejność i zakres mogą się jeszcze zmienić. Nie wykluczam, że w trakcie pojawią się zagadnienia, którym warto będzie poświęcić trochę więcej czasu. Teraz wyglądałoby to tak:

1. Opis domeny i tło sytuacji. To właśnie post, który czytasz. Jego zadaniem jest pokazanie moich motywacji i wyjaśnienie modelu biznesowego. Koniecznie musisz się z nim zapoznać, ponieważ wszystko będzie się kręcić wokół przedstawionych tu założeń.
2. Geneza. Tu będę do bólu szczery i pokażę Ci, jak nie zaczynać takiego projektu. Zobaczysz, jak rozmyślałem nad „fancy” logiem, interfejsem użytkownika, jak „walidowałem” pomysł. Opiszę też moje nieudolne próby content marketingu.
3. Big Picture Event Storming. Tutaj przedstawię, jak wyglądał mój pierwszy Event Storming i jakie fajne rzeczy mogą wyjść, jeśli się go robi z kimś, kto ma duże doświadczenie biznesowe.
4. Design Level Event Storming, podczas którego podzielimy wszystko na bounded contexty i subdomeny.
5. Wybór architektury, a może nawet architektur. ;)
6. Dokumentacja ogólna i decyzji architektonicznych.
7. Setup projektu, czyli struktura, system kontroli wersji i CI.
8. Agregaty, polityki, repozytoria i serwisy. Tutaj nam się to rozbije na kilka wpisów, bo jest o czym pisać. Są różne podejścia, więc będziemy je analizować.
9. Komendy i ich infrastruktura.
10. Zdarzenia i ich infrastruktura.
11. Deployment.

Opis domeny

Domena, którą będziemy się tutaj zajmować, to wsparcie dla początkowej fazy procesu rekrutacyjnego programistów. A dokładniej odwrócenie aktualnego modelu: programiści – zamiast przeglądać oferty pracy – mieliby wystawiać swoje anonimowe, ograniczone czasowo ogłoszenia z opisanymi wymaganiami i oczekiwaniami. Dzięki temu wystawialiby się niejako „na sprzedaż” – takie Allegro z programistami, choć doskonale wiemy, że programiści to towar niepotrzebujący reklamy. ;)

Jeśli chcesz poznać genezę samego pomysłu, znajdziesz ją w kolejnym poście. Teraz jedynie zaznaczę, że na taki kształt, jaki przedstawiłem, wpływ miało głównie rozeznanie tematu. Były to różnego rodzaju artykuły czy podcasty traktujące o bolączkach procesu rekrutacyjnego oraz oczywiście bezpośrednie rozmowy zarówno z programistami, jak i rekruterami (możesz o tym przeczytać w dalszej części tego artykułu). Z moich „badań” wynikało, że wiele problemów pojawia się jeszcze przed rozmową kwalifikacyjną. Występują one po obu stronach i w takiej formie referuję je poniżej.

Problemy z perspektywy programisty(-ki):

• Jeśli programista lub programistka nie byli zainteresowani zmianą pracy, to nie chcieli dostawać nowych ofert zatrudnienia przez portale społecznościowe, mailowo czy telefonicznie.
• Ogłoszenia z ofertami pracy zazwyczaj były nieustrukturyzowane. Widełki wynagrodzeń, warunki zatrudnienia i wymagania były niejasne bądź ich brakowało.
• Dość krępującym elementem każdej rozmowy o pracę było przedstawianie oczekiwań finansowych. Z jednej strony kandydaci obawiali się, że mogą zrazić pracodawcę, z drugiej zaś, że zgodzą się na stawkę niższą, niż mogliby dostać.
• Kandydaci mieli też obawy, że jeśli sami siebie uznają podczas rozmowy za niedostatecznie wykwalifikowanych, to obniżą swoje wymagania – syndrom oszusta w praktyce ;).
• Kolejnym problemem było przedstawianie pełnego profilu (np. w postaci CV) w obawie, że zostanie się odrzuconym z powodów takich jak poprzednie doświadczenie zawodowe, wiek czy płeć.

Problemy z perspektywy rekrutera(-ki):

• Brak wyselekcjonowanej grupy odbiorców. Innymi słowy, jeśli byłoby wiadomo, kto chce zmienić pracę, można by było składać oferty tylko takim osobom.
• Uczucie irytacji i zrezygnowania, kiedy większość wysłanych wiadomości z ofertą pracy pozostaje bez jakiejkolwiek odpowiedzi. Nawet bez krótkiego: „Nie, dziękuję”.
• Ustalony budżet na pracownika, którego nie można zamieszczać w ogłoszeniu o pracę.
• Wymagania kandydata nie wpasowują się w to, co może zaoferować firma. Często okazywało się to niestety dopiero podczas spotkania z kandydatem, przez co marnotrawiony był czas po obu stronach.

Możliwe, że część z tych problemów została już rozwiązana dzięki powstaniu portali z ogłoszeniami, które przedstawiają oferty w lepszy sposób, kładąc nacisk na eksponowanie warunków zatrudnienia. Nie siedzę teraz w temacie, ale nie przeszkadza to potraktować tej domeny jako problemu do modelowania.

Jak już wspomniałem wcześniej, moim pomysłem na wszystkie powyższe bolączki było całkowite odwrócenie początkowej fazy procesu rekrutacji przez przeniesienie inicjatywy na samych zainteresowanych. Dzięki temu możliwe byłoby poprawienie procesu w kilku obszarach:

• Zostałaby wyizolowana grupa ludzi, którzy aktywnie poszukują pracy.
• Ogłoszenia miałyby mieć taką samą strukturę, eksponującą umiejętności, oczekiwania finansowe i przykładowo lokalizację ewentualnego zatrudnienia.
• Polepszenie komunikacji przez to, że od samego początku obie strony miałyby jasność co do wymagań.
• Anonimowość pozwalałaby na sprawdzenie, jakie możliwości kandydat ma na rynku pracy, bez zdradzania potencjalnych czynników dyskryminujących, takich jak wiek czy płeć. Kandydaci byliby oceniani wyłącznie na podstawie posiadanych umiejętności i przedstawionych wymagań. Być może byłby to koniec z ofertami pracy, w których zwracają się do Ciebie: „Cześć, Paweł!”, gdy na imię masz Tomek. ;)
• Przez to, że ogłoszenia byłyby ograniczone czasowo i anonimowe, nie byłoby tu miejsca na networking i zbieranie siatki „znajomych”. Po prostu byłoby to narzędzie, którego używasz, tylko gdy go potrzebujesz.
• Docelowo sam początek procesu rekrutacyjnego zostałby przyspieszony, ponieważ łączyłby ludzi, którzy wiedzą, że mogą się dogadać.

I tak oto dochodzimy do momentu, w którym pokażę, jak widziałem nowy proces i jakie miałem wymagania biznesowe. No to lecimy:

1. Osoba szukająca pracy wystawia ogłoszenie.
   • Jest ono ograniczone czasowo, żeby nie zalegało na portalu.
   • Można wystawić kilka ogłoszeń w tym samym przedziale czasu. Powody tego mogą być różne, jak choćby chęć sprawdzenia innych możliwości. Przykładowo: programujesz w Ruby i szukasz pracy w tym języku, ale na boku, cichcem, chcesz sprawdzić, czy ze swoim doświadczeniem możesz znaleźć coś w Elixirze (przynajmniej kiedyś był to dość częsty przypadek). Wystawiasz wtedy drugie ogłoszenie.
   • Każde ogłoszenie można w dowolnej chwili ukryć (na przykład jeśli zbierzemy dużo ofert i nie chcemy więcej) albo usunąć (jeśli chcielibyśmy mieć aktywne nowe ogłoszenie, a limit na darmowe ogłoszenia nam się skończył). I tak oto płynnie przechodzimy do monetyzacji, o której w następnym punkcie.
   • Początkowo każde ogłoszenie miało być płatne. Założenie było takie, że skoro szukasz pracy i masz do tego dobre narzędzie, to nie będzie Ci żal wydać $5 na ogłoszenie. Problem jednak polega na tym, że możesz nie chcieć płacić, jeśli tego narzędzia jeszcze w ogóle nie znasz. Dlatego wyłoniły się dwa rozwiązania:
     • Każde kolejne ogłoszenie ponad X darmowych ogłoszeń jest płatne.
     • Wprowadzam pakiety dostępu. Pierwszy jest darmowy i pozwala na wrzucenie 2–3 ogłoszeń za darmo. Kolejne pozwalają na większą liczbę ogłoszeń i udostepniają dodatkowe funkcjonalności. Z tym że nie były one jeszcze sprecyzowane, no ale wiadomo, doda się promowanie ogłoszenia, dostęp do statystyk i tygryski dostaną to, co lubią najbardziej. Będą siedzieć, patrzeć na wykresy i merdać ogonkami.
       Z racji tego, że pierwsze podejście wydaje się nadal dość rzadkie, byłem skłonny iść w pakiety. Gdy ludziom daje się do wyboru 3 opcje, to są tacy, którzy zawsze wybiorą najtańszą (w tym przypadku darmową), część zdecyduje się na środek, ale jest też grupa, która weźmie tylko najdroższą. Drugie podejście wymagało oferowania tych nieokreślonych jeszcze funkcjonalności klasy premium. Dlatego też trzeba było tak zaprojektować proces dodawania ogłoszenia, żeby był elastyczny i otwarty na różne warianty. Aby samą decyzję odsunąć w czasie i nie musieć implementować płatności, zdecydowałem, że startuję z darmowymi ogłoszeniami z twardą blokadą na X ogłoszeń.
2. Jak już ogłoszenie zostanie opublikowane, staje się dostępne w wyszukiwarce. Mogą z niej korzystać rekruterzy. Jeśli ogłoszenie zostaje ukryte lub usunięte, znika z wyników wyszukiwania.
3. Po zapoznaniu się z ogłoszeniem rekruter może złożyć ofertę. Tutaj właśnie w grę wchodziło kilka ciekawych wymagań:
   • Rekruter może złożyć ofertę do konkretnego ogłoszenia tylko raz.
   • Żeby złożyć ofertę, rekruter musi zaakceptować warunki, które zamieszczający ogłoszenie zaznaczył jako wymagane.
   • Przy składaniu oferty konieczne jest podanie danych kontaktowych firmy, w imieniu której się to robi.
4. Osoba zamieszczająca ogłoszenie widzi w swoim panelu złożone oferty. Może je usunąć, jeśli uzna, że nie są interesujące, bo np. zostały złożone przez firmę, w której aktualnie pracuje. ;) W takim przypadku już nigdy nie dostanie oferty od tej samej osoby do tego konkretnego ogłoszenia. Kandydat może skorzystać z otrzymanych danych kontaktowych i reszta procesu odbywa się wtedy już poza portalem, ponieważ nie chcemy wiązać jakichkolwiek danych użytkownika (CV) z kontami na portalu.

Mniej więcej tak to miało wyglądać. Wiesz już, jakie problemy zidentyfikowałem i jak chciałem je rozwiązać. Kiedyś opisałem (mniej szczegółowo) całą ideę w artykule, który znajdziesz tutaj. Miał to być element content marketingu, dlatego wrzuciłem go nawet na Hacker News, ale przeszedł bez echa. Polecam go bardziej jako ciekawostkę, bo punktem wyjścia do dalszych badań i tak pozostaje post, który masz teraz przed oczami. Tutaj drobiazgowo przedstawiłem domenę i wymagania biznesowe, żebyśmy mieli na czym pracować przy nadchodzących Event Stormingach.

Obiecałem pokazać całe zaplecze, dlatego w następnym poście – jeszcze nie technicznym – dowiesz się, jaka była geneza pomysłu, jak powstawały logo i design, jak zbierałem informacje od programistów i rekruterów oraz jak ostatecznie… odpuściłem. Krótko mówiąc: zobaczysz, jak (nie) startować z takim przedsięwzięciem. Może przyda Ci się ta wiedza w Twoich przyszłych projektach. Później wskoczymy w samo mięsko, czyli modelowanie problemu.

Zakończenie, jak już jesteśmy w takim biznesowym nastroju, nie może się obejść bez call to action!

Koniecznie daj znać w komentarzu, czy podoba Ci się pomysł na serię postów, w których przedstawiam historię i domenę, a następnie implementację modelu biznesowego. Co więcej, zrobimy to razem! Serio!

Napisz, nawet jeśli tego zwykle nie robisz. Wystarczy, że wpiszesz „+1” …

a ja będę wiedział, że chcesz lecieć z tym dalej.