Historia Jibble
Stworzenie oprogramowania, które się wyróżnia, jest solidne i wywiera prawdziwy wpływ, jest arcytrudnym zadaniem. Wiele zespołów potrafi osiągnąć jeden z tych celów, niektóre dwa, ale rzadko spotyka się zespół, który potrafi odhaczyć wszystkie trzy.
A właśnie to miałem przyjemność zaobserwować w Jibble.
Chwila spędzona w Google potwierdza moją tezę — aplikacja Jibble ma imponującą ocenę 4,9 w serwisach GetApp i Capterra oraz 4,8 w Apple App Store.
Jestem pewien, że wciąż możemy wiele poprawić, ale takie oceny wskazują, że robimy coś dobrze. Chciałem zrozumieć, co dokładnie stoi za naszym sukcesem, więc postanowiłem przeanalizować, w jaki sposób i dlaczego firma osiąga tak imponujące wyniki.
Zdaję sobie sprawę, że aplikacja do elektronicznych kart czasu pracy i program do rejestracji czasu nie brzmią szczególnie ekscytująco. Ciężko je porównać do pracy w firmie zajmującej się grami, takiej jak Activision, która tworzy nową grę o Spider-Manie.
Jibble chwali się jednak, że jest „nowym standardem w rejestracji czasu pracy”. To śmiałe stwierdzenie, ale moim zdaniem oparte na faktach. Jest wynikiem żmudnych wysiłków, aby uczynić coś zwyczajnego – ale ważnego – interesującym.
Widzicie, większość start-upów bierze się za rewolucjonizowanie tradycyjnych branż, ponieważ najpilniejsze i najbardziej oczywiste innowacje zostały już wprowadzone. Dlatego uważam, że Jibble znajduje się w wyjątkowej pozycji, aby zdobyć rynek, który przez długi czas był zaniedbywany przez młodych przedsiębiorców i doświadczonych inwestorów venture capital.
Na pierwszy rzut oka Jibble może wyglądać jak zwyczajna koncepcja oparta na zasadzie „OK, znaleźliśmy problem, sklećmy razem trochę kodu, zróbmy interfejs użytkownika, dodajmy bramkę płatności i wypuśćmy to w świat”.
Tak przynajmniej mi się wydawało, zanim dołączyłem do zespołu. Jednak szybko się przekonałem, że firmy SaaS, które tworzą złożone produkty, takie jak oprogramowanie do ewidencji czasu pracy, działają zupełnie inaczej.
Muszą przestrzegać MNÓSTWA procesów i chociaż Jibble nie jest Googlem, to z pewnością może pochwalić się bardzo imponującym zespołem kierującym rozwojem. Ci bohaterowie często pozostają niezauważeni.
Być może słyszałeś stereotyp, że programiści nie są mistrzami w komunikacji międzyludzkiej – są zazwyczaj introwertykami, fachowcami w swojej dziedzinie i rzadko dają się rozproszyć interakcjami z innymi. Ten obraz jest w pewnym stopniu prawdziwy.
Większość programistów, aby być dobrymi w swoim fachu, musi spędzać niezliczone godziny nad słabo oświetlonymi ekranami, nieustannie stukając w klawiaturę, a nasz zespół nie jest tu wyjątkiem.
Będąc po obu stronach działalności firmy, zarówno w roli osoby mającej kontakt z klientami, jak i osoby odpowiedzialnej za produkt, znajduję się w wyjątkowej sytuacji, która pozwala mi skomentować, co sprawia, że Jibble tak dobrze funkcjonuje, i dlaczego warto obserwować ten startup.
Nasz proces rozwoju
Nasz zespół spędza niezliczone godziny na dopieszczaniu każdego etapu procesu rozwoju, który przebiega następująco:
1. Ideacja: przewidywanie problemów
Nasz zespół spędza potworną ilość czasu na etapie tworzenia pomysłu, czyli jeszcze przed napisaniem pierwszej linii kodu, aby upewnić się, że nie spędzimy dwa razy więcej czasu na niespodziewanych przeszkodach po rozpoczęciu pracy. Jak powiedział Abraham Lincoln:
„Daj mi sześć godzin na ścięcie drzewa, a pierwsze cztery spędzę na ostrzeniu siekiery”
Zdj.: rawpixel.com/Freepik
2. Research zewnętrzny
Po zidentyfikowaniu problemu zespół szybko porównuje opinie klientów, obecne i przewidywane trendy rynkowe oraz odpowiednie technologie, aby znaleźć podobieństwa, które pomogą w przygotowaniu danych wymaganych do podjęcia świadomej decyzji.
3. Research wewnętrzny: dyskusje z zespołem
Po zebraniu danych do rozmowy zapraszane są odpowiednie osoby, w tym właściciele produktów, menedżerowie produktów, CTO, główni projektanci i liderzy zespołów ze wszystkich sekcji.
Gdy zespół przeprowadzi już wewnętrzną debatę na temat zalet i wad, zasobów, czasu i oczekiwanego zwrotu z inwestycji w związku z decyzją, którą zamierzamy podjąć, wszyscy są proszeni o poświęcenie czasu na wyrażenie swoich obaw i zasugerowanie, w jakim kierunku ich zdaniem powinniśmy podążać i dlaczego.
4. Podejmowanie decyzji: teraz czy później – jaki wpływ będzie to miało na firmę?
Po opadnięciu kurzu i wyciągnięciu wniosków zespół podejmuje decyzję, która jest zgodna z wizją firmy i jej bezpośrednimi lub przyszłymi celami. Jeśli propozycja nie spełnia tych kryteriów, nie przechodzi dalej.
Decyzje są często (ale nie zawsze) związane z ulepszeniami istniejących funkcji lub rozwojem zupełnie nowych. Po otrzymaniu zielonego światła dla danego pomysłu czas umieścić go na mapie: bierzemy się za to teraz, w przyszłym miesiącu, w przyszłym kwartale, czy w nieokreślonej, ale dalekiej przyszłości?
W tym przypadku sprawdzamy, jaki wpływ zmiana będzie miała na obecnych klientów, przyszłe perspektywy i obecne możliwości, a następnie podejmujemy decyzję o przejściu do następnego etapu.
5. Research projektowy
Po ustaleniu osi czasu funkcji musimy wymyślić, jak będzie ona wyglądać. To etap, na którym wykłada się wielu nowych przedsiębiorców i właścicieli oprogramowania. Są zbyt skoncentrowani na tym, jak to powinno działać, podczas gdy powinni również zadbać o to, aby wszystkie funkcje pasowały do siebie w wizualnej układance.
Zdj.: Freepik
6. Specyfikacja
Kolejny krok to zmora programistów – dokumentacja. Specyfikacja to miejsce, w którym opisujemy zakres projektu, nad którym pracujemy. To tam zapisujemy i rozwijamy pomysł w formie dokumentu, który stanowi podstawę dla rozwoju, testowania i sprawdzania błędów.
Określa ona, czym będzie cała funkcja, wyjaśnia, jak będzie wyglądać, i opisuje cel końcowy (w tej chwili nie przywiązujemy dużej wagi do wskaźników). Zawarta jest tam również dokumentacja techniczna, sporządzana przez naszych programistów. Oto jak obecnie wygląda proces tworzenia specyfikacji:
- Kierownik projektu składa wstępny szkic specyfikacji.
- Kierownicy zespołów przeglądają wstępne specyfikacje i zostawiają komentarze dotyczące wykonalności technicznej lub alternatywnych propozycji.
- Kierownik projektu wprowadza poprawki.
- Kolejna dyskusja (kroki 2-3 mogą być powtórzone kilka razy w zależności od złożoności projektu).
Zespół pilnuje, aby uwzględnione zostały również wszystkie skrajne przypadki. Po sfinalizowaniu projektu dyskusja nad specyfikacją zostaje zakończona, a poprawki są możliwe tylko do tego momentu.
7. Projektowanie produktu
Nasi genialni projektanci tworzą mockupy z myślą o różnych wyświetlaczach. Wszystko jest generowane z uwzględnieniem palety kolorów Jibble.
Na tym etapie brane są pod uwagę wszystkie możliwe wyświetlacze – telefonu, komputera, tabletu – i szeroka gama rozmiarów ekranu.
Zdj.: zorandraganov/Pixabay
8. Implementacja backendu i testy jednostkowe
Większość funkcji zaczyna się od backendu. Nasz backend musi obsługiwać nową funkcję, zanim dodamy interfejs użytkownika i logikę po stronie klienta oraz nasze API. Tak więc przeprowadzamy sesje porządkowe z zespołem BE w celu dopracowania zgłoszeń i zadań w oparciu o specyfikację, a przypisanie zgłoszeń odbywa się podczas planowania sprintu backendu.
Zespół BE jest również odpowiedzialny za opracowanie testów jednostkowych dla kodu, który pisze, aby upewnić się, że wszystkie funkcje działają zgodnie z oczekiwaniami. W tym momencie tworzona jest architektura funkcji. Dobry model funkcji ułatwi proces rozwoju interfejsu klienta.
9. Implementacja klientów i testy jednostkowe
Teraz gdy nasz BE został wdrożony, zespoły programistów mobilnych i webowych rozpoczną implementację FR. Proces jest mniej więcej taki sam jak w przypadku BE, jednak dopracowywanie ticketów odbywa się głównie poza rozmowami planistycznymi.
Na urządzeniach mobilnych mamy dwa różne zespoły zajmujące się interfejsem użytkownika zgodnie z jednym wspólnym zestawem logicznym; pomaga to zoptymalizować dostarczanie i zmniejszyć redundancję.
Wstępne testy są przeprowadzane przez zespół programistów, a następnie przekazywane do QA w celu ręcznego sprawdzenia.
10. Testowanie akceptacyjne
W miarę opracowywania funkcji są one wdrażane w naszych środowiskach testowych, gdzie zespół QA przeprowadza rygorystyczne testy akceptacyjne. Jest to wymyślny sposób na powiedzenie, że testujemy opracowane funkcje programu do rejestracji czasu, aby upewnić się, że działają zgodnie z oczekiwaniami. W przypadku wykrycia problemów wracamy na warsztat w celu wprowadzenia zmian i ulepszeń.
Zdj.: vectorjuice/Freepik
11. Testowanie regresji
Jeśli wszystkie funkcje działają zgodnie z przeznaczeniem, są następnie wysyłane do produkcji, gdzie są ponownie testowane, tym razem w celu upewnienia się, że istniejące poprawki nie psują tego, co działało wcześniej.
Testowanie regresyjne definiuje się jako rodzaj testowania oprogramowania w celu potwierdzenia, że niedawna zmiana programu lub kodu nie wpłynęła negatywnie na istniejące funkcje.
W Jibble przeprowadzamy dwa rodzaje testów regresji: jednym z nich jest nieformalny lub pomniejszy test regresji, który jest wykonywany w ramach ticketów z testów akceptacyjnych, które wymagają ponownych poprawek. Drugi to pełny cykl iteracji testów regresji, który jest wykonywany pod koniec Sprintu skupiającego się na ścieżce krytycznej wybranych funkcji.
Obecnie wykonujemy je ręcznie, oczekując na zakończenie przygotowywania skryptów automatyzacji.
12. Testowanie eksploracyjne
Ponieważ zespół jest wprawiony w pracy nad programem do rejestracji czasu, wszystkie powyższe czynności są wykonywane w cyklach dwutygodniowych. Poza tymi cyklami lub w okresach, gdy obciążenie pracą jest stosunkowo niskie, zespół przeprowadza testy eksploracyjne – co oznacza po prostu nadzorowanie całości i flagowanie wszystkiego, co wymaga szybkich poprawek.
Przeprowadzamy również testy eksploracyjne podczas testowania ticketów z testów akceptacyjnych, które obejmują rozszerzony zakres samego ticketu.
13. Wdrożenie
W końcu, po wszystkich tych wysiłkach, nasze dzieło może ujrzeć światło dzienne. Przyznaj, że nie spodziewałeś się, że stworzenie oprogramowania do ewidencji czasu pracy zajmie aż tyle czasu, prawda?
Zdj.: Freepik
Myśl końcowa
Aby stworzyć doskonały produkt, trzeba mieć doskonałą wizję i nie porzucać obranego kierunku, gdy zmienia się kierunek wiatru. Zespół Jibble rozumie korzyść płynącą z niepoddawania się zbyt szybko trendom; jest zdeterminowany i nieustannie dąży do doskonalenia.
Jednocześnie realizuje strategie, starając się pozostać wiernym swojej wizji „nowego standardu w rejestrowaniu czasu”. To właśnie – moim zdaniem – odgrywa dużą rolę w ich sukcesie.
Ostateczny wniosek dla firm, które chcą powtórzyć sukces Jibble w tworzeniu niezawodnego oprogramowania do ewidencji czasu pracy, jest następujący: zbuduj szybkie, silne i sprawne zespoły, które poświęcą czas na badania oparte na danych przed podjęciem decyzji, i zatrudnij błyskotliwych inżynierów, którzy wykorzystują najlepsze praktyki i globalną współpracę, aby tworzyć, testować, ulepszać i dostarczać funkcje z niesłychaną precyzją.
A potem usiądź wygodnie i obserwuj, jak dzieje się magia.
