Jak dbasz o jakość i elastyczność architektury swojego startupu? Devdebata

Czym kierowałeś się przy wyborze technologii do stworzenia swojego startupu? Jak dbasz o to, by praca nad rozwojem startupu nie rozciągnęła się w nieskończoność? Które zdobyte wcześniej doświadczenie najbardziej pomogło Tobie w rozwoju startupu? Na te i na wiele innych pytań odpowiedzieli CEO i CTO polskich startupów, których zaprosiliśmy do devdebaty. Zobaczcie, jak odpowiadali na te same pytania.

Devdebata, którą czytasz nie powstałaby, gdyby nie pomoc Sebastiana Malaca, który przygotował poniższe pytania. Dziękuję, Sebastian! Oto startupy, których CTO wystąpili w tej edycji devdebaty:

Trustisto — Trustisto powstało z myślą o wszechstronnym wykorzystaniu. Mechanizmy społecznego dowodu słuszności można z powodzeniem wykorzystać na stronach typu landing page, SaaS, portalach z ogłoszeniami itp., a można tego dokonać za pomocą narzędzia Trustisto.

1koszyk — innowacyjna platforma sprzedażowa, integrująca różne rozwiązania e-commerce. Daje absolutną swobodę, jeśli chodzi o wykorzystywane kanały, utrzymując maksymalną prostotę użytkowania. To rozwojowe narzędzie, które spełnia oczekiwania każdego przedsiębiorcy – od domowego wytwórcy, sprzedającego rękodzieło po biznesmena, prowadzącego sklep z szerokim asortymentem.

Quantor — serwis służy do łatwego przeglądu rynku kantorowego w Polsce. Działa jako serwis niezależny od kantorów, serwisów finansowych i porównywarek. Dzięki niemu w krótkim czasie dowiesz się, gdzie najbliżej Ciebie znajdują się kantory stacjonarne i jakie kursy walut oferują. Nieważne czy chcesz wymienić walutę w dużym mieście, czy po drodze za granicę.

Czym kierowałeś się przy wyborze technologii do stworzenia swojego startupu?

Odpowiada Wojciech Grześkowiak, CEO & CTO Trustisto:

Przy budowaniu startupu, czyli firmy, która niekoniecznie może znaleźć swoje miejsce na rynku, szkoda czasu na testowanie nieznanych technologii, dlatego należy wybrać to co zna się najlepiej — w naszym przypadku było to Ruby on Rails, Node, React na platformie AWS. Dzięki temu mogliśmy szybko zbudować MVP Trustisto.com i sprawdzić czy klilenci faktycznie potrzebują takiego rozwiązania.

Odpowiada Konrad Łapin, PM i CEO 1koszyk:

Od lat specjalizujemy się w realizacji projektów informatycznych, bazujących na frameworku Symfony. 1koszyk.pl tworzymy w jego aktualnej, 4-tej wersji. Bazujemy także na stale rozwijanych, własnych komponentach programistycznych. Dokumentacja API z użyciem Swagger. Front budowany w Webpack 4. Automatyzacja deploymentu poprzez Ansible. FreeBSD jako stabilna platforma serwerowa.

Odpowiada Wojciech Grzelak, Quantor (Founder, CEO):

Na samym początku kluczowa była minimalizacja ryzyka, która sprowadzała się do minimalizacji kosztów wejścia i czasu pozyskania informacji zwrotnej z rynku. Dokonaliśmy kompromisu między specjalizacją programistów w zespole, a prostotą i dostępnością gotowych rozwiązań (w 2012 r. była nieco mniejsza niż dziś). Na tym etapie optymalizować można było wiele, włącznie z doborem narzędzi pomocniczych, jak np. środowisko testowe, kontrola wersji etc. Na samym początku wychodziliśmy z założenia, że technologia, a szczególnie architektura jest sprawą drugorzędną, skoro może okazać się, że projekt pójdzie do kosza. Pierwszą wersję portalu tworzyło 3 programistów, w czystym PHP, plikami zarządzaliśmy przez klienta FTP (żadnej kontroli wersji!), a dedykowana beta portalu (nie landing) była gotowa „od zera” już po miesiącu.

Zobacz też

Praca w IT Zaczyna się od krawędziowania. O technologii rozpoznawania obrazu

Jak dbasz o to, by praca nad rozwojem startupu nie rozciągnęła się w nieskończoność?

Odpowiada Wojciech Grześkowiak, CEO & CTO Trustisto:

To jest praca w nieskończoność, zawsze można przecież coś poprawić, dodać, ulepszyć, a nawet zmienić technologię. Trzeba sobie jednak wyznaczać konkretne cele i nie tracić czasu na zmianę czegoś co działa — to najgorszy wróg. My programiści lubimy testować nowe technologie i ciągnie nas do nowych bibliotek, ale “done is better than perfect”. Należy wyznaczyć konkretne kamienie milowe i je realizować. W przypadku MVP należy określić zbiór minimalnych funkcjonalności i je zrealizować minimalnym nakładem pracy.

Odpowiada Konrad Łapin, PM i CEO 1koszyk:

Tworząc startup po części jestesmy i klientem, i wykonawcą. Wymaga to sporej dyscypliny w zakresie definiowania potrzeb i zarządzania zasobami na rzecz ich realizacji. Staramy się naśladować przykłady znanych projektów i korzystać z ich doświadczenia. Dążymy do utrzymania w ryzach założeń MVP. Następnie tworzymy kolejne funkcjonalności na bazie analizy działającego systemu i pojawiających się potrzeb biznesowych.

Odpowiada Wojciech Grzelak, Quantor (Founder, CEO):

Przede wszystkim ograniczam perfekcjonizm do koniecznego minimum. Jest to nie tyle problem techniczny, co mentalnościowy, by umieć godzić się z tym, że wydajesz coś niekompletnego, ograniczonego. Wychodzimy z założenia, że najpewniejsza teza doświadczonego UX/UI designera ustępuje testom na żywym organizmie. Dlatego działamy w metodyce Lean, która skraca „rzeźbienie” zarówno na poziomie konceptualnym, jak i wykonawczym. Długoterminowo definiujemy cele roczne, z których wynikają cele kwartalne, które z kolei osiągane są potem w sposób zwinny. Na etapie zarządzania tygodniowego w zupełności wystarczy skrojony pod zespół Agile i Trello.

Na początku tygodniowego „sprintu” ustalamy co chcemy osiągnąć, tworzymy taski i nadajemy priorytety, mając z tyłu głowy możność pojawienia się zgłoszeń wymagających zamrożenia tasków bieżących i nagłej reakcji. Pod koniec tygodnia dokonujemy podsumowania i wyciągamy wnioski, co należy zmienić podczas następnego planowania, a co było zaplanowane i zrobione dobrze. Oprócz tego polecam nie bać się outsourcingu i delegować, kiedy to tylko możliwe.

Jak dbasz o jakość i elastyczność architektury?

Odpowiada Wojciech Grześkowiak, CEO & CTO Trustisto:

Nasza usługa Trustisto.com działa na platformie AWS, dzięki temu mamy dostęp do szerokiego wachlarza usług, które daje Amazon. Jeśli potrzebujemy rozwiązań NoSQL, silnika wyszukiwań, CDN a nawet AI wszystko mamy w zasięgu ręki, dzięki czemu możemy łatwo testować, wdrażać, a nawet migrować nasze systemy. AWS daje bardzo duże możliwości i zachęcamy wszystkich do budowanie rozwiązań właśnie tam.

W Trustisto.com mamy wdrożone Continous Integration & Development. Każda wprowadzona zmiana przechodzi poszczególne etapy:

1. Na samym początku system sprawdza, czy wprowadzony kod trzyma się naszych standardów, tu pomocne są tzw. lintery, które analizują składnie i formatowanie pod kątem naszych wytycznych, ale i najpopularniejszych błędów. Dzięki temu, nasz kod jest czysty i czytelny dla wszystkich zaangażowanych w rozwój.

2. Następnie uruchamiane są testy jednostkowe, które analizują i sprawdzają, poszczególne moduły kodu. Tu sprawdzamy, czy nic na najniższym poziomie się nie zepsuło.

3. Kolejny krok to testy integracyjne, gdzie automatycznie uruchamiany konkretne scenariusze np. rejestracja konta, płatność itp.

4. Na koniec wrzucamy zmiany na serwer testowy tzw. staging, gdzie nasz tester już manualnie sprawdza wprowadzone zmiany. To środowisko jest identyczne jak produkcyjne, więc wszystkie problemy z wdrożeniem można wykryć na tym etapie.

5. Gdy tester zaakceptuje zmiany poprawka ląduje na produkcji, tworzona jest nowa wersja systemu.

6. Na produkcji jednocześnie uruchomione są narzędzia do analizy błędów i każdy znaleziony ląduje w naszym koncie Sentry.io oraz na Slacku.

7. Dzięki wersjonowaniu, wiemy w której wersji pojawił się błąd i jakie zmiany do niego doprowadziły. W tym momencie albo wrzucamy poprawkę, albo wycofujemy zmiany jeśli nie jesteśmy w stanie szybko naprawić błędu, a ten jest dla działania systemu krytyczny. Opisany sposób działa zarówno w przypadku gdy na projektem działa 1 osoba jaki 100 osób.

Odpowiada Konrad Łapin, PM i CEO 1koszyk:

W ramach continous integration dbamy o zachowanie wewnętrznych procedur, spójności źródeł i odpowiedniej weryfikacji prac. Tam gdzie to możliwe automatyzujemy sprawdzanie jakości kodu, między innymi stosując narzędzia do analizy statycznej. Dzięki temu mamy szansę wcześnie wykryć sytuacje grożące potencjalnymi błędami.

Z kolei restrykcyjny code review pozwala na utrzymanie m.in. zrozumiałego i spójnego nazewnictwa zmiennych i funkcji. Aplikacja przechodzi następnie testy funkcjonalne i integracyjne. Kolejnym etapem jest deploy na środowisko testowe wraz z generowanymi zestawami parametrów testowych – tefixturów. Tutaj prowadzone są manualne testy, nakierowane w szczególności na funkcjonalność i ergonomię platformy.

Staging jest podpięty jako demo aplikacji na stronie informacyjnej, co zwiększa zasięg testów jeszcze nie wdrożonych wersji aplikacji. Dla wersji produkcyjnej uruchomione są narzędzia do analizy błędów, których wystąpienie jest raportowane programistom i pozwala na szybką diagnozę oraz usunięcie problemu.

Odpowiada Wojciech Grzelak, Quantor (Founder, CEO):

W tym temacie trzeba szczególnie szukać kompromisu, bo w startupie (z definicji) przyszłość nie jest pewna i stawianie na nią tj. wybieranie wielkich frameworków, które „zwrócą się kiedyś” nie jest zawsze optymalne. Przywiązanie do technologii też nie jest tutaj najważniejszym elementem. Przede wszystkim unikamy złych praktyk, a logikę biznesową centralizujemy w API, najlepiej od samego początku. Na studiach uczono mnie o metrykach, które liczą się w wielu korporacjach. Zakładam, że porządny programista zna wzorce projektowe i stara się zaplanować kod zanim do niego przysiądzie i tak staramy się działać, ale nie jest to naszą „religią”.

Gdy start-up rozwinął się i zaczął realnie zarabiać, dopiero wtedy zyskało to biznesowe uzasadnienie. Charakterystyka startupu i jego standardowego procesu finansowania zmusza do tego, by przed procesem skalowania pozyskiwać finansowanie i stawiam tezę, że jest to jeden z lepszych momentów by dopiero rozważyć enterprise lub wręcz zmienić część lub całość technologii. Choć może to zabrzmieć dla niektórych seniorów jak herezja, to do tego czasu (w początkującym biznesie) architektura i utrzymywanie jakości kodu powyżej przeciętnego nie jest tak istotne.

W naszym przypadku wystarczyło, że druga wersja portalu powstała w mikro-frameworku Silex, który posiadał mechanizmy pełnego Symfony (MVC, Bundle), ale miał ograniczoną liczbę komponentów wymaganych do startu. Dzięki temu można było dość płynnie przejść na skalowalne rozwiązania dopiero kiedy zaszła taka realna potrzeba.

Oferty pracy z

Które zdobyte wcześniej doświadczenie najbardziej pomogło Tobie w rozwoju startupu?

Odpowiada Wojciech Grześkowiak, CEO & CTO Trustisto:

Budując Trustisto.com najbardziej pomogło mi to, że budowałem wcześniej inne start-upy, więc wiedziałem, gdzie są największe problemy i starałem się ich unikać. Doświadczenie w tym wypadku jest kluczowe, nie da się przeczytać książki i zbudować MVP z marszu, często trzeba mieć za sobą kilka projektów, również te, których nie udało się dowieźć.

Odpowiada Konrad Łapin, PM i CEO 1koszyk:

Doświadczenie zdobywamy cały czas. Dużo wiedzy zdobyliśmy już wcześniej, realizując własne i komercyjne projekty. W miarę możliwości refaktoryzujemy aplikację, aby spełniała nasze oczekiwania i bieżące standardy.

Odpowiada Wojciech Grzelak, Quantor (Founder, CEO):

Żeby ruszyć najbardziej przydała się wiedza z zakresu całościowych wdrożeń, szczególnie zleceń dla małych klientów. Nie przydała się wiedza korporacyjna, która w moim przypadku uczyła zagłębiania się w wielkie komponenty tworzone latami przez dziesiątki ludzi. Liczył się przede wszystkim odpowiedni dobór technologii do danego etapu tj. by technologia nie tworzyła barier wejścia, a na dalszych etapach rozwoju była umiarkowanie skalowalna, stosunkowo tanio utrzymywana i promowała dobre praktyki. Uważam, że najważniejszą cechą jest gotowość na zmiany, włącznie ze zmianą technologii.

Kluczowa jest nie tyle dogłębna znajomość języka (choć czasem startup może na tym bazować), co ogólna znajomość obiektowości, abstrakcji kodu i szybkość przyswajania nowości – uczenia się. Nie bez znaczenia jest też dyscyplina w wytwarzaniu oprogramowania zarówno na poziomie zarządzania zespołem, jak i samego programowania. W tym sensie wartościowe mogą okazać się przyzwyczajenia i rutyna przyswojone na etacie.

Jak podejmujesz decyzję o tym, co jest mniej istotne, a co ważniejsze?

Odpowiada Wojciech Grześkowiak, CEO & CTO Trustisto:

Najważniejsze są błędy, które zgłaszają nam użytkownicy, wszystkie takie sytuacje załatwiamy od ręki, często tego samego dnia, a nawet w ciągu 2-3 godzin. To dla nas kluczowe i często w Trustisto.com dostajemy pochlebne opinie i podziękowania, że szybko udało się coś dla nich naprawić. Najmniej istotne są poprawki rzeczy, które działają, ale “wypadałoby je poprawić”. Skoro działają, to niech działają dalej, jak będziemy mieć wolną chwilę, można się tym zająć. Tu trochę też trzeba patrzeć w przód, bo jeśli coś działa, ale przestanie jak nam tylko wzrośnie baza użytkowników, to należy się zająć tym wcześniej. Wszystko co jest pomiędzy, realizujemy zgodnie z naszym planem.

Odpowiada Konrad Łapin, PM i CEO 1koszyk:

Najważniejsza jest stabilność aplikacji, ale również jej wydajność i ergonomia. Dla użytkowników administracyjnych w pierwszej kolejności wdrażane są funkcje kluczowe dla realizacji procesów biznesowych, a w dalszej kolejności wszelkie usprawnienia związane z wygodą. Dla użytkowników końcowych (kupujących) na pierwszym miejscu są ergonomia i szybkość działania.

Odpowiada Wojciech Grzelak, Quantor (Founder, CEO):

Na pewno nie zawsze wszystko zgłaszane przez użytkownika/klienta ma najwyższy priorytet, szczególnie gdy zaplanowane są konkretne działania, a zasoby ograniczone. Zawsze należy wysłuchać i rozpatrzyć uwagę, ale gdy np. reprodukcja błędu jest trudna lub czasochłonna, a problem nie jest ewidentnie krytyczny, wówczas „pozwalamy błędowi pożyć”. Innymi słowy, zakładamy, że problem jest proporcjonalnie ważny do liczby zgłoszeń, szczególnie krótkoterminowo tj. jeżeli pojawi się kilka podobnych zgłoszeń od niepowiązanych użytkowników w małym odstępie czasu i które potencjalnie mogą mieć wspólną przyczynę, wtedy nadajemy temu większy priorytet. Oczywiście mamy inne podejście do przeciętnego użytkownika niż do klienta, gdzie tego drugiego traktujemy znacznie poważniej i w pierwszej kolejności.

Z drugiej jednak strony, szczególnie w startupie niemalże spontanicznie pojawiają się różnego rodzaju oferty i okazje o ograniczonym czasie żywotności. W takich przypadkach stosuję podejście, które nazywam „wspólną abstrakcją” lub po prostu esencją przedsiębiorczości. Przykładowo od tygodnia „wisi” task X o niskim priorytecie, ale dzisiaj dostaliśmy propozycję od portalu/klienta, by zrobić dla nich widget Y, który wymaga czasu i pracy. Gdy task X i task Y występują osobno, mają niski priorytet, ale gdy występują razem i okazuje się, że np. 80% pracy między nimi jest identyczna, wówczas rozważamy zwiększenie priorytetu obu tasków, bo zmienił się stosunek zysku do poniesionych kosztów/pracy.

Zobacz też

Praca w IT Szybko reaguj na opóźnienia w płatnościach

W jaki sposób zbierasz feedback od użytkowników?

Odpowiada Wojciech Grześkowiak, CEO & CTO Trustisto:

Nie mamy zorganizowanego tego w jakiś proces. Najczęściej użytkownicy piszą do nas przez czat na stronie, i z tego kanału mamy najwięcej feedbacku. W drugiej kolejności piszą do nas maila, na które staramy się od razu odpowiedzieć, nawet z informacją, że “przyjęliśmy i się już tym zajmujemy”.

Ostatnim sposobem jest automatyczne zbieranie błędów, które pojawiają się na stronie. Dzięki dobre integracji Trustisto.com z Sentry.io, wiemy konkretnie, którym użytkownikom pojawił się błąd i sami możemy do nich napisać z informacją, że widzieliśmy, że coś się stało i już nad tym pracujemy.

Odpowiada Konrad Łapin, PM i CEO 1koszyk:

Od strony użytkowo – biznesowej, jeszcze udaje się nam utrzymywać bezpośredni kontakt z użytkownikami platformy. Widzimy jednak potrzebę zautomatyzowania tego procesu i jesteśmy w trakcie przygotowania ankiet ewaluacyjnych. Pod względem technicznym, system jest oczywiście ciągle monitorowany i wszelkie błędy oraz wyjątki raportowane są automatycznie.

Odpowiada Wojciech Grzelak, Quantor (Founder, CEO):

W dobie LiveChata i CallPage stawiamy mimo wszystko na bardziej tradycyjne metody. Zaskakująco dużo użytkowników preferuje kontakt telefoniczny inicjowany przez nich samych i czasem wystarczy po prostu udostępnić numer telefonu. Choć to może nie intuicyjne, ale ostatnie zwiększanie się udziału użytkowników mobilnych w ruchu ogólnym uczyniło zwyczajne dzwonienie bardziej dostępnym niż wcześniej. Jest to mechanizm o tyle dobry, że sam się filtruje tj. użytkownik zastanowi się dwa razy nad wagą swojego zgłoszenia zanim zaryzykuje potencjalną opłatę za dzwonienie. Na dzień dzisiejszy mamy tyle samo zgłoszeń telefonicznych, co drogą elektroniczną. Pomijając standardy tj. formularz kontaktowy i e-mail staramy się również być obecni na mediach społecznościowych i szybko odpowiadać na wiadomości, szczególnie prywatne. Od niedawna swoich „power-userów” staramy się utrzymywać w społeczności i np. zachęcamy ich do udzielania się na specjalnej grupie np. na FB.

Jak angażujesz firmy/klientów do pomocy w budowaniu aplikacji?

Odpowiada Wojciech Grześkowiak, CEO & CTO Trustisto:

Tworzymy aplikacje i usługi tylko na własne potrzeby, dlatego zależy nam, aby cała firma pracowała przy ich tworzeniu, a w szczególności wszystkie osoby, które będą z niej korzystać. Nie musimy się specjalnie zachęcać, w Trustisto.com jesteśmy entuzjastami nowych technologii, więc angażowanie w takie projekty przychodzi nam dość łatwo. Kluczem jest zatem odpowiednia rekrutacja. Warto zatrudniać osoby, którym po prostu chce się pracować i robią to nie tylko dla pieniędzy, ale i dla frajdy.

Odpowiada Konrad Łapin, PM i CEO 1koszyk:

Wśród klientów wcześniejszych projektów, znajomych oraz użytkowników 1koszyk.pl zdobyliśmy rzeszę entuzjastów i propagatorów pomysłu. Często sami sugerują ich zdaniem ciekawe rozwiązania i funkcjonalności – takie spontaniczne uwagi są dla nas niezwykle cenne.

Ponadto, od samego początku mamy założenie, że 1koszyk.pl to marka przyjazna, otwarta i interaktywna. Tę interakcję najłatwiej jest oczywiście wywołać w social mediach, na których skupiamy się w komunikacji marketingowej. W niedalekiej przyszłości chcemy też udostępnić naszym fanom blog z jakościowym, branżowym contentem, który z pewnością stanie się świetnym pretekstem do szerszej dyskusji z klientami.

Odpowiada Wojciech Grzelak, Quantor (Founder, CEO):

Kiedy pojawia się pomysł np. na pivot, w pierwszej kolejności rozważamy czy jesteśmy w stanie sami wziąć na barki wdrożenie. Kluczowy jest stosunek specjalizacji i bieżącego obycia programistów do wymagań na technologię. Choć mamy dość uniwersalny zespół, to mamy pokorę do szukania wsparcia wśród branżowych i/lub technologicznych specjalistów. Staramy się tak dobierać partnerów, by nasze skille/doświadczenie bardziej się uzupełniały niż nachodziły na siebie, a gdy o to trudno, staramy się wyraźnie rozdzielać zakresy obowiązków. Całkiem dobrze wychodzi to przy wspólnym ustalaniu mechanizmów komunikacji między systemami np. ustalaniu funkcji webservice’ów czy API.

Wzajemną motywacją od strony biznesowej w takich przypadkach najlepiej okazuje się dla nas współpraca w modelu udziału w zyskach. Jest to zazwyczaj wystarczająca zachęta dla partnerów, by zaangażować do pracy programistów, którzy nie należą dziś do najtańszej siły roboczej, a w rozwiązaniach w modelu SaaS ich działania mają niemal bezpośredni i natychmiastowy wpływ na konwersję i przychody. W bardziej przyziemnych przypadkach, staramy się również angażować naszych klientów do zgłaszania błędów i proponowania usprawnień, które konfrontujemy następnie z planami rozwoju. Zauważyliśmy, że z kolei w takich sytuacjach jako środek motywujący dobrze sprawdza się udzielanie małych rabatów na usługi.