Marketing i Biznes IT To oni piszą kod dla największych!

To oni piszą kod dla największych!

23.03.2018 | Autor: Marta Bąk

Jesteś przedsiębiorczym freakiem i zależy Ci na rozwoju Twojej firmy? Spotkaj setki podobnych rekinów biznesu podczas konferencji Founders Mind

Sprawdź szczegóły!

Stawiasz pierwsze kroki w programowaniu? A może chcesz się nauczyć? Jesteś załamany(a), bo popełniłeś(aś) masę błędów, a jeszcze co najmniej drugie tyle, zanim osiągniesz zadowalający poziom. Poznaj tych, którzy pisali kod na największych!

Chcę Ci przedstawić kilka historii oraz case’ów. W niniejszej publikacji dowiesz się, że Tych, których teraz podziwiasz, kiedy zaczynali tworzyć swoje projekty/startupy wcale nie mieli różowo jakby się mogło wydawać. Jak teraz wygląda praca u nich w firmie? Jaka jest ich kultura organizacyjna? I w końcu – kogo szukają do pracy?

1. Piotr Wierzejewski – współtwórca Brand24

2. Wojciech Karwowski – SEMSTORM

3. Case Makolab

4. Tomasz Soszyński – Makolab

5. Paweł Neubauer – UXPin

6. Case – Packhelp

7. Case Thulium

Piotr Wierzejewski o zrozumieniu rynku i potrzeb klientów

Wszyscy znamy historię Brand24 opowiedzianą przez Michała Sadowskiego. Jestem ciekawa jednak, jak wyglądały Wasze początki od strony technicznej?

Brand24 od momentu startu (w 2011) przeszedł bardzo dużą zmianę filozofii jak rozwijać produkt. Tworzenie wersji beta, a obsługa systemu dostępnego 24h na dobę dla ponad dwóch tysięcy klientów wymaga zupełnie innego podejścia zarówno jeśli chodzi o utrzymanie, jak i rozwój systemu. Powiększenie zespołu IT z 3 do dwudziestu kilku również wywarło wpływ na nasze priorytety. Gdy nie obsługiwaliśmy jeszcze klientów, mogliśmy pozwolić sobie na eksperymenty, błędy oraz tymczasowe wyłączanie systemu. Również sam proces wytwarzania oprogramowania w tak małej grupie nie był sformalizowany i nie było problemu z przepływem wiedzy. Wtedy większość czasu poświęcanego na rozwój to było czyste programowanie systemu, którego koncepcja powstała w naszej głowie na podstawie naszych doświadczeń i intuicji. Na początku drogi nie mogliśmy opierać się na „data-driven development”, bo po prostu nie mieliśmy jeszcze użytkowników systemu. Kluczowe było dobre zrozumienie potrzeb rynku oraz oferty konkurencji. W pewnym momencie prac doszliśmy do wniosku, iż narzędzie w naszym rozumieniu daje już wartość i możemy poprosić o ocenę osoby z zewnątrz. Wysłaliśmy darmowy dostęp do wersji beta do kilkudziesięciu, a po pewnym czasie do kilkuset znajomym nam osób i firm, które potencjalnie mogły zostać naszymi klientami. Beta testy trwały przez kilka miesięcy. Cały czas poprawialiśmy produkt na podstawie użycia systemu, opinii od użytkowników i naszych spostrzeżeń. Po oficjalnym starcie narzędzia, czyli wprowadzeniu opłat, prace nad rozwojem dużo się nie zmieniły. Słuchanie i analizowanie użycia narzędzia przez klientów wciąż jest naszym priorytetem. Start komercyjny wymógł jednak inne podejście do utrzymania systemu. Od tego czasu musieliśmy poświęcać więcej uwagi na dostępność produktu i tym samym spowolnić trochę prace rozwojowe. Znalezienie balansu pomiędzy rozwojem, a utrzymaniem jest kluczowe. Jesteśmy uczuleni, aby wraz ze wzrostem bazy klientom nie stać się bezwładnym bytem skupionym na utrzymaniu statusu quo i ciągle walczymy o to, aby się rozwijać i wdrażać nowości do naszego produktu.

W jaki sposób dbacie o rozwój swoich programistów?

Zespół programistyczny odbywa spotkania dotyczące najlepszych praktyk w programowaniu i implementacji ich u nas.
Developerzy we własnym zakresie organizują wewnętrzne warsztaty, gdzie podejmują inicjatywy pozwalające szlifować swoje umiejętności i poznawać nowe technologie.
Posiadamy specjalny kanał na Slacku, gdzie developerzy wrzucają linki do ciekawych artykułów odnośnie IT.
Posiadamy dostęp do platformy z kursami online dla developerów.
Creative Fridays – w jeden piątek w miesiącu każdy z załogi Brand24 może w ramach samorozwoju przeznaczyć cały dzień na aktywnoście związane z samorozwojem (powiązane z profilem działności w Brand24), a nie aktualnymi pracami.
Organizujemy cyklicznie wewnętrzne Hackathony z nagrodami.
Raz w roku jeździmy całym składem programistycznym na konferencję 4Developers.
Stosujemy Code Review również do przepływu wiedzy odnośnie technik programowania.
Regularnie robimy audyty i konsultacje z zewnętrznymi ekspertami dzięki czemu nasi developerzy mają okazję pozyskać wiedzę bezpośrednio od ekspertów (świeże spojrzenie).

Wojtek Karwowski mówi o optymalizacji kodu przy projekcie, który liczy sobie 35 tysięcy plików

Czy i kiedy bywały sytuacje, gdzie musieliście siedzieć nad kodem ponad 8-śmio godzinny tryb pracy?

Przy tworzeniu SEMSTORM były dwa momenty, które wymagały wzmożonej pracy nad projektem.

Trzy miesiące po starcie okazało się, że SEMSTORM ma poważną wadę w silniku. Przez to nie byliśmy w stanie rozwijać projektu. Rozmiar usterki i problemów, które powodowała, zmusił nas do ponad 8-godzinnej pracy. Na szczęście udało nam się sprawnie przebudować system.

Drugim momentem była kolejna aktualizacja systemu. Zgubiły nas nadmierny optymizm i chęć udowodnienia, że projekty informatyczne da się dowieźć na czas. Aktualizacja była ogromna, a my tak uparci, że braliśmy sporo nadgodzin. Niestety, pomimo pracy od rana do później nocy i w weekendy, musieliśmy wyłączyć cześć funkcji. Tylko dzięki temu zdążyliśmy na określony termin.

W jaki sposób staracie się optymalizować kod?

Optymalizacja kodu to bardzo złożone zagadnienie, szczególnie jeżeli projekt liczy 35 tysięcy plików.

Całość kodu podzieliliśmy na zupełnie odrębne moduły. Każdy z nich realizuje oddzielną funkcję. Takie podejście pozwoliło nam łatwiej kontrolować „słabe części systemu”. Jeżeli wykryjemy, że dany moduł obciąża system, możemy poddać go procesowi refaktoringu. Optymalizacja polega na dokładnym przyjrzeniu się działaniu danego modułu. Dalsze działania zależą od wyników testów. W krytycznych sytuacjach przerabiamy cały moduł. Częściej jednak rozkładamy go na podmoduły, którymi łatwiej zarządzać. Te mniejsze części poddajemy następnie dużo bardziej szczegółowym testom i sprawdzamy, co jeszcze da się zoptymalizować.

Przede wszystkim staramy się tworzyć czytelny kod, w którym każdy członek zespołu się odnajdzie. Optymalizacja, która pogarsza zrozumienie projektu jest niedopuszczalna.

Jaka porażka/problem Cię najwięcej nauczył?

Myślę, że największym błędem była druga wersja SEMSTORM. Została zaprojektowana bez uwzględnienia możliwości dalszego rozwoju. Skupiliśmy się na funkcjach związanych z widocznością domen w wyszukiwarce. Dodaliśmy masę rzeczy związanych z filtracją, a mimo tego użytkownicy omijali filtry z daleka. Z czasem okazało się, że funkcje SEMSTORM przestały wystarczać naszym klientom. Próba rozbudowy pokazała nam, że jesteśmy blokowani przez architekturę. Co więcej, wszyscy bardzo przyzwyczaili się do interfejsu i zmiana na nowszy wygląd z podwójnym menu została chłodno przyjęta. Co prawda nowa wersja umożliwiała swobodną rozbudowę o kolejne moduły systemu oraz skalowalność systemu, ale wymagała optymalizacji „pod człowieka”. To zadanie pochłonęło masę czasu, ale z drugiej strony dostarczyło bezcennej wiedzy zespołowi.

W obecnej chwili SEMSTORM został znacznie uproszczony. Mimo tego nadal jest bardzo zaawansowanym i skomplikowanym narządzeniem. W następnym miesiącach będziemy jeszcze bardziej upraszczać cały system przy zachowaniu jakości danych. Nie zapominamy o rozwoju, ale nie może być to wypuszczanie nowych funkcji dla samej idei. I my i klienci musimy widzieć w nich wartość.

Case Makolab – współpraca z wymagającym klientem

MakoLab: Kulisy wielkiej migracji stron internetowych koncernu Renault – Nissan na platformę RWD

Pewnie niewiele osób wie, że dzisiejsza, pełna użytecznych funkcjonalności wersja RSI (Renault Site International) -CMS to efekt długoletniej współpracy nad rozwojem narzędzia koncernu Renault-Nissan i MakoLab, jednej z największych niezależnych agencji interaktywnych w Polsce. Pierwsze narzędzie o nazwie Anteus powstało już w 2003 r. Prace nad obecną wersją rozwiązania rozpoczęły się w 2008 r., a w 2010 r. pierwsze kraje rozpoczęły funkcjonować na nowej platformie. Szybko rozwijające się technologie mobilne skłoniły w 2013 r. Renault do wdrożenia nowej – umożliwiającej tworzenie stron w technologii Responsive Web Design – wersji rozwiązania i przeprowadzenia przez zespół MakoLab pełnego, z sukcesem zakończonego w 2015 r. procesu migracji wszystkich 41 witryn Renault na wersję RWD. Nasze rozwiązanie obecnie funkcjonuje w ponad 70 krajach na całym świecie. O projekcie, w który zespół MakoLab włożył ogromnie dużo doświadczenia i serca, opowiada Dyrektor Projektów Zagranicznych w MakoLab, Tomasz Soszyński.

Czym jest RSI CMS?

RSI CMS to wysokiej klasy dedykowane rozwiązanie webowe opracowane z wykorzystaniem technologii .NET, które pozwala na generowanie i publikację stron internetowych zgodnych z globalnym brand identity marki Renault i Dacia. Podstawową zaletą systemu jest właśnie możliwość łatwego tworzenia i powielania witryn w oparciu o ustalony odgórnie szablon graficzny wynikający z restrykcyjnej dbałości o wizerunek międzynarodowej korporacji.

To znaczy, że o wszystkim decyduje Klient (Renault)?

Tak, wybór template’ów (szablonów) jest monitorowany przez centralę Renault od początku do końca. W skali globalnej pozwala to zapewnić jak największą jednorodność i spójność, dzięki czemu nawet poszczególne, prezentowane na stronach modele samochodów Renault posiadają zestaw wspólnych i niezmiennych cech bez możliwości niekontrolowanej ingerencji lokalnego przedstawicielstwa. Dzięki skrojonemu na potrzeby Renault systemowi zarządzania treścią – RSI-CMS, użytkownicy witryn producenta na całym świecie mają dostęp do dostosowanych do swoich potrzeb treści, w tym samej identyfikacji wizualnej, nadzorowanej z poziomu centrali.
Co ważne, platforma dzięki swojej modułowej budowie, daje możliwość łatwej konfiguracji oraz gwarantuje elastyczność jeśli chodzi o zakres funkcjonalny poszczególnych witryn krajowych.

Jak się to wszystko zaczęło?

Rok 2013 był kolejnym rokiem mobile. Wtedy też Renault zdecydowało, że chce ułatwić użytkownikom korzystanie ze stron internetowych koncernu na całym świecie i poprosił nas o migrację stron należących do koncernu na platformę RWD. Celem było takie zmienienie i zaprojektowanie strony, by jej przeglądanie na smartfonie czy tablecie stało się łatwe i przyjemne.

Co to oznacza?

W zależności od tego, z jakiego urządzenia korzysta użytkownik, parametry automatycznie zmieniają się tak, by tekst nie tracił na czytelności, a zdjęcia dopasowywały się do wielkości wyświetlaczy. Poruszanie się po stronie jest dużo prostsze, a jej struktura nie jest tak bardzo rozbudowana. Menu i linki zyskały odpowiednią wielkość i przejrzystość, a filmy bez problemu wyświetlą się i na komórce, i na tablecie, a na dodatek nie zawieszą się w połowie, nawet gdy zabraknie Internetu. Dzięki takim udogodnieniom użytkownik będzie czuł się dobrze, ponieważ wszystko będzie działało i wyglądało tak, jak powinno. Najważniejsze, że będzie mógł skupić się na tym, na czym mu zależy i nie będzie tracił czasu na walkę z oporną i źle wyświetlającą się stroną.

Co było największym wyzwaniem w tym projekcie?

Dużo czasu zajmowała komunikacja z krajami, przedstawianie całego procesu i ustalanie terminów poszczególnych etapów prac. Centrala Renault pilnowała i nas, MakoLab, i poszczególne kraje, jednak nie zawsze wszystko szło zgodnie z planem. Borykaliśmy się z różnymi, choć zazwyczaj niewielkimi opóźnieniami ze strony krajów, oczywiście w grę wchodził czynnik ludzki. Zważywszy na to, że przeprowadzaliśmy migrację w 31 krajach, z których część posiadała nieresponsywne strony w dwóch językach, co dawało nam łącznie 41 instancji, musieliśmy się zmierzyć z kwestiami niezależnymi od nas – święta w krajach prawosławnych, weekend inaczej niż u nas w krajach muzułmańskich, a jeszcze musieliśmy zmagać się z urlopami, zastępstwami, feriami i świętami państwowymi, podczas których komunikacja z krajami zamierała.

Wypuszczanie strony live to jest ten moment, kiedy albo wszystko będzie w porządku, albo wyjdą niedociągnięcia. Jak to wyglądało w tym przypadku?

Gdy już ustaliliśmy kolejność krajów, następowała migracja na platformę RWD. Prosiliśmy przedstawicieli klienta w poszczególnych krajach o sprawdzenie contentu na stronie, by był najbardziej aktualny. Oczywiście nie zawsze wszystko szło tak, jak sobie zaplanowaliśmy, więc nasz 3-osobowy zespół spędzał długie godziny nad poprawkami. Gdy strona prezentowała się już dobrze, kraj miał wyznaczony czas na sprawdzenie merytorycznej poprawności przeniesionego contentu. W przypadku stron w językach arabskim, izraelskim, farsi czy gruzińskim nie mieliśmy pojęcia, czy wszystko się zgadza.

Jak wyglądała współpraca z poszczególnymi krajami w trakcie migracji?

Zdarzało się, że informacje zwrotne przychodziły z opóźnieniem albo dopiero po migracji. Niedogodności w postaci tego, że nagle może okazać się, że teksty na stronie są nieaktualne lub w złym języku, są nie do ominięcia. To komplikowało nam pracę, odwlekało zakończenie projektu, i namnażało pracy. W pewnym momencie mieliśmy rozpoczęty proces dla 12 krajów. Wprowadzaliśmy wiele poprawek, mimo że uwagi ze strony klienta mogły wydawać się niezrozumiałe. Dla nas jednak najważniejszy był efekt końcowy – nie tylko, żeby strony dobrze działały, ale żeby klient był zadowolony. Zdarzyło się, że kraj sam, bez konsultacji z nami publikował w CMSie swoją nową stronę, mimo że prace nad nią nie były zakończone. Wtedy trzeba było ratować sytuację i przywracać starą wersję strony. Inny kraj, po naszym przeniesieniu contentu i podczas pracy nad nim, migrował starą stronę raz jeszcze, co skutkowało zdublowaniem każdej podstrony i błędem programu, jeszcze inny zdecydował się na ulepszanie strony w CMSie na własną rękę, co doprowadziło do powstania błędów i problemów z jej działaniem.

Mieliście sporo przygód po drodze, czy udało się dotrzymać terminów?

Jak widać, nie nudziliśmy się. Z urozmaiceniami zakończyliśmy proces migracji stron wszystkich krajów na początku września, co okazało się bardzo dobrym wynikiem. Pierwotnie projekt miał się zakończyć pod koniec sierpnia.

Kto pracował nad projektem po Waszej stronie?

W każdy tego typu projekt musi być zaangażowany project manager, który koordynuje wszystkie działania i je scala, a także jest odpowiedzialny za komunikację z klientem oraz komunikację wewnątrz zespołu projektowego – tak żeby wszyscy się dobrze rozumieli i dowieźli projekt do końca. Oprócz tego niezwykle ważna jest rola programistów i content managerów. Specjaliści ds. zarządzania treścią muszą być skrupulatni, dobrze zorganizowani, a także komunikatywni. Mam tu na myśli płynne posługiwanie się językiem angielskim – w przypadku naszego międzynarodowego klienta Renault, ta umiejętność jest konieczna.

Cały mój 30-osobowy zespół codziennie pracuje nad realizacją projektów dla Renault na całym świecie. Cieszy mnie, że osobiście uczestniczyłem w procesach rekrutacyjnych i dobierałem sobie zespół. Ludzie, którzy go tworzą to zgrana ekipa, jeden na drugiego może liczyć. Profesjonalizm, a jednocześnie umiejętność zbudowania rodzinnej atmosfery, komunikatywność i otwartość na ludzi i wyzwania to główne cechy jakie cenię u swoich współpracowników tworzących zespół projektów zagranicznych.

Ciągle szukamy osób do zespołu – https://pracodawcy.pracuj.pl/makolab,23888

Mówiliśmy o użytkownikach, a co z osobami po stronie Renault? Jaki wpływ ta migracja miała na ich codzienną pracę?

Dzięki nam koncern Renault-Nissan może pochwalić się nowoczesnymi serwisami o spójnym wyglądzie, a osoby odpowiadające za obsługę stron poszczególnych krajów mają ułatwioną pracę. Dzięki nowemu i responsywnemu CMSowi edycja serwisu i treści stała się łatwiejsza i bardziej intuicyjna, a także raz wprowadzona treść jest czytelna i wyświetlana w poprawny sposób na dowolnym urządzeniu. Cieszymy się, że spełniliśmy oczekiwania Klienta – na koniec całego projektu centrala Renault podziękowała nam za intensywną współpracę i uznała, że zakończył się on pełnym sukcesem. Teraz pracujemy nad tym, by zaproponowane przez nas rozwiązania były jeszcze lepsze. Cały czas rozwijamy zarówno warstwę prezentacyjną, jak i zakres funkcjonalny dostępny na platformie. Nie zostajemy w tyle!

Tomasz Soszyński o komunikacji z klientem

Który klient był największym wyzwaniem dla Waszego zespołu programistów i dlaczego?

Renault jest jednym z największych klientów, z którymi współpracujemy. To doświadczony gracz na rynku automotive, który zdaje sobie sprawę, jak wielką siłę sprzedażową stanowi rozpoznawalna na całym świecie marka oraz jak ważne jest zachowanie jej jednolitego wizerunku w Internecie. Jednocześnie, potencjalni klienci koncernu potrzebują treści dostosowanych do lokalnych uwarunkowań, kultury oraz ich specyficznych potrzeb. Aby sprostać temu niełatwemu wyzwaniu połączenia obu – pozornie sprzecznych – potrzeb, koncern szukał rozwiązania uniwersalnego. Ze strony potrzeb centrali – zachowanie możliwości kontroli i monitoringu spójności Renault brand identity, z drugiej, potrzeby lokalnych oddziałów w zakresie dostosowywania treści do specyfiki użytkowników ich stron. Biorąc pod uwagę zróżnicowane kompetencje osób odpowiedzialnych za wdrożenie witryny internetowej na świecie, narzędzie musiało być również łatwe i intuicyjne w obsłudze. Tak powstał dedykowany system do zarządzania treścią – Renault Site International (RSI) CMS autorstwa MakoLab. Największym wyzwaniem było skoordynowanie całego procesu, by przebiegł on pomyślnie w 70 krajach – zróżnicowanych kulturowo i pod względem preferencji użytkowników.

Jakich błędów moglibyście wówczas uniknąć, mając tę wiedzę, co w chwili obecnej?

Projekt związany z migracją stron internetowych Renault na platformę RWD zweryfikował zasady rządzące komunikacją z klientem, zarówno jeśli chodzi o komunikację z centralą, ale też z poszczególnymi krajami. Mam tu na myśli egzekwowanie nawiązywania kontaktu, przesyłanie informacji i sposób, w jaki chociażby content w nietypowych językach powinien być nam dostarczony, żebyśmy mieli świadomość na czym pracujemy i co robimy. Oczywiście pewnych rzeczy nie da się przewidzieć, a tym bardziej im zapobiec ze względu na czynnik ludzki. Zawsze może wystąpić problem z aktualnością contentu czy przestoje wynikające z nieobecności osób odpowiedzialnych za kontakt.

Oczywiście możemy próbować się ubezpieczyć, zakładając jakieś marginesy czasu w poszczególnych etapach migracji, ale nie zawsze to się uda. Ponadto nie zawsze największe narzędzia do zarządzania pracą projektową są najlepsze. Biorąc pod uwagę kraje, z którymi współpracowaliśmy i ich wiedzę technologiczną, czasami najlepiej sprawdzały się proste narzędzia komunikacyjne jak Excel czy po prostu e-mail. Tak duża migracja na pewno poszerzyła naszą świadomość i przygotowała do następnych równie dużych przedsięwzięć.

Paweł Neubauer o tym, kogo szukają najwięksi?

Jak zwiększyliście zatrudnienie od czasu pierwszej wersji aplikacji? Kto doszedł do Waszego zespołu IT?

Pierwsza wersja aplikacji została napisana przez zewnętrzny software house. Następnie, przez około 12 miesięcy, UXPin był rozwijany przez trzech programistów. W 2013 roku otrzymaliśmy kolejną rundę finansowania, co pozwoliło nam rozwinąć zespół techniczny do 25 osób. W podobnej ilości pozostajemy do dzisiaj.

Nasz zespół zmieniał się na przestrzeni lat nie tylko jeżeli chodzi o liczbę inżynierów, ale również ich kompetencje. Początkowo wszyscy zajmowali się wszystkim, co z pewnością nie jest czymś wyjątkowym wśród młodych spółek technologicznych. W ostatnich latach udało nam się jednak sprofesjonalizować nasz zespół i obecnie mamy specjalistów m.in. od front-endu, infrastruktury czy testowania oprogramowania.

Czy szukacie nowych pracowników do zespołu IT? Jeśli tak, to czego oczekujecie od kandydatów?

Jak najbardziej! Wciąż poszukujemy osób, które swoją wiedzą i doświadczeniem wesprą nas w rozwoju naszego produktu. Obecnie rekrutujemy m.in. na stanowiska „Full-Stack Software Engineer” oraz „DevOps Engineer”. Wszystkie oferty pracy można znaleźć na naszej stronie www.uxpin.com/jobs.

Od kandydatów i kandydatek oczekujemy przede wszystkim nieustannej chęci rozwoju i poszerzania swojej wiedzy. Oczywiście istotne są dla nas aspekty techniczne takie jak umiejętność programowania, nie mniej jednak to pasja, determinacja i ciągłe poszukiwanie nowych wyzwań jest tym, co przykuwa uwagę podczas rozmów kwalifikacyjnych.

Rynek pracy IT jest rynkiem Pracownika, a nie Pracodawcy. Ogromna konkurencja wśród firm technologicznych powoduje, że przeciętne wynagrodzenie jest zdecydowanie wyższe niż w innych branżach. To natomiast, szczególnie dla młodych ludzi, stanowi często główny powód do wejścia na ten rynek. Myślę, że kluczem do sukcesu dla osób aplikujących na stanowiska w IT jest pokazanie, że ich motywacja płynie przede wszystkim z pasji do rozwiązywania trudnych problemów przy użyciu technologii oraz ciągłego samodoskonalenia się.

Eksperyment, który wypalił

Pewnego dnia umówiliśmy się na spotkanie z Patrykiem Kabajem (Co-Founder, Digital Product Manager) i Wojtkiem Sadowskim (CEO). Nie znaliśmy się wcześniej, na żywo widzieliśmy się po raz pierwszy. Kilka miesięcy wcześniej zrobiłem razem z Wojtkiem zdalnie projekt API do aplikacji mobilnej, który mu się bardzo spodobał. Na spotkaniu chłopaki przedstawili mi pomysł na startup. Rozwiązywał on problem żmudnego i czasochłonnego zamawiania pudełek w drukarniach oferując dostęp do łatwego narzędzia do projektowania, szybkiej wyceny zamówienia oraz możliwości zakupu małej ilości opakowań, już od 30 sztuk, co w przypadku wielu drukarni było niemożliwe.

Na pierwszy rzut oka widać było, że pomysł jest bardzo dobrze przemyślany przede wszystkim pod kątem biznesowym oraz produkcyjnym. Jako full-stack developer poczułem, że jestem w stanie pracować zarówno nad frontendem i backendem tej aplikacji. Dodatkowo wiedziałem, że bardzo ważna będzie tu kreatywne podejście do implementacji, co jest dla mnie bardzo ważne w programowaniu. Byłem akurat w sytuacji, gdzie szukałem startupu do którego mogłem dołączyć. Miałem inne propozycje, ale nie czułem że są to dobre projekty z właściwym potencjałem. Decyzja zapadła natychmiast. Po spotkaniu, które trwało ok 2 godziny w piątek zdecydowałem się że zaczynamy pracować od poniedziałku. Nie pracowałem wtedy na etat w żadnej firmie i miałem zaoszczędzone pieniądze aby móc eksperymentować z tego typu projektami, co było kluczową kwestią w podjęciu tej decyzji.

Pierwsze linijki kodu powstały już na początku następnego tygodnia. Patryk przez kilkanaście miesięcy programował razem ze mną i stworzył wiele rozwiązań do dzisiaj obecnych w kodzie. Po tym jak udało nam się domknąć pierwszą rundę inwestycyjną objął rolę Digital Product Managera. Na wstępie podzieliliśmy się obowiązkami – on odpowiadał za frontend eCommerce, ja za backend oraz silnik kreatora 3D. W międzyczasie dzieliliśmy się także wieloma zadaniami związanymi z dev-ops. Decyzję o tym w jakich technologiach będziemy tworzyć startup podjęliśmy wspólnie na podstawie macierzy decyzyjnej. Zrobiliśmy research i dla każdej znanej nam technologii wypisaliśmy plusy i minusy. Rozważaliśmy Node, Python, PHP, Rails na backendzie oraz Angular i React na frontendzie.

Wiedzieliśmy, że nie zbudujemy szybko dobrego startupu jeżeli będziemy pisać to co jest już dostępne za darmo lub za niewielką cenę dla developerów. Strategia była taka, aby szybko zaadoptować w projekcie większe, gotowe kawałki funkcjonalności dostępne na rynku, a swoją moc programistyczną skupić na unikanych wartościach naszej firmy.

Do backendu wybraliśmy Ruby on Rails razem z silnikiem eCommerce – Spree. Dzięki temu mieliśmy od początku do dyspozycji bardzo dojrzały framework wraz z setkami rozszerzeń oraz gotowe API do składania zamówień. Bardzo ważne było to, że Ruby nawet w przypadku adopcji tak dużych projektów daje nieograniczone możliwości dostosowania wszystkich funkcjonalności do naszych potrzeb. Działa to dużo lepiej niż w przypadku innych języków.

Na frontendzie postawiliśmy na React oraz WebGL/Three.JS. Stworzyliśmy Single Page Application, komunikacja się bezpośrednio z API. Nigdy wcześniej nie miałem do czynienia z projektem gdzie były wykorzystywane modele 3D oraz WebGL, a na tych technologiach opiera się nasz kreator pudełek. Wierzę jednak w to, że najważniejszą miejętnością programisty jest umiejętność szybkiego uczenia się nowych rzeczy oraz wiedza o teorii programowania, dzięki której łatwo jest wdrożyć się w nowe tematy. Przeczytałem książkę na temat WebGL, dokumentacje i przykłady biblioteki Three.JS i stworzyłem prototyp, który pokazywał co jesteśmy w stanie stworzyć. Byliśmy tym zachwyceni i pracę bardzo szybko poszly do przodu.

Do naszego zespołu dołączyła Aleksandra Gajda, które była po kursie Coders Lab. Bardzo szybko wdrożyła się w prostsze tematy związane z cięciem stron statycznych oraz szablony e-mailowe. Wprowadziła do naszego kodu BEM dla CSS. Po kilku miesiącach zaczęła wdrażać się w bardziej zaawansowane projekty.

Bardzo ważna jest dla nas jakość kodu i dbanie o szczegóły. Wszystkie nasze prace nad kodem przechodzą przez Code Review. Od początku naszego projektu mamy środowisko Continuous Integration, które uruchamia testy automatyczne przy każdej zmianie w kodzie. Nasze wdrożenia, backupy i skalowanie serwerów jest zautomatyzowane. Przykładamy do automatyzacji bardzo wysoką wagę. Działamy w Scrumie zaadoptowanym do naszych potrzeb. Robimy restrospekcje i staramy się na bieżąco poprawiać naszą pracę.

Całość projektu uruchomiliśmy własnymi siłami za swoje pieniądze. Dzisiaj jesteśmy po pierwszej rundzie inwestycyjnej, a nasze pudełka sprzedajemy w każdym europejskim kraju. Nasz zespół programistyczny stale się powiększa, więc zapraszamy do współpracy.

Ewolucja, czyli samodzielne finansowanie projektów

Pierwsza wersja systemu Thulium powstała około 10 lat temu. Tak naprawdę niewiele miała wspólnego z tym co jest dziś, bo w międzyczasie kilkukrotnie ewoluowała. W swoim debiucie była to centrala telefoniczna VOIP, oparta na open-sourcowym Asterisku. Stopniowo przerodziła się ona w system call center, poprzez contact center, aż do narzędzia dedykowanego dla e-commerce wspierającego komunikację wielokanałową z klientem. Do tego około dwa lata temu cała platforma została przeniesiona do chmury i rozpoczęliśmy sprzedaż w modelu SaaS.

Chciałbym podkreślić jak ważne jest tu słowo ewolucja. Ponieważ finansujemy się sami bez zewnętrznych inwestorów, to nie mogliśmy pozwolić sobie, żeby w pewnym momencie powiedzieć „STOP – przepisujemy system, bo od jutra korzystamy z chmury”. Architektura i kod rozwijane były krok po kroku i dopasowywane do bieżących potrzeb. A w tym samym czasie tworzyliśmy funkcjonalności zamawianie przez klientów.

Dziś powoli rozbijamy monolit jakim był nasz system, wydzielając mikroserwisy obsługujące poszczególne funkcje. Po stronie serwera stawiamy na Javę 8 żeby sprawnie obsłużyć duży ruch i pogodzić skomplikowaną logikę biznesową z wielowątkowym przetwarzaniem. Z kolei aplikacja webowa to PHP 7 i JavaScript. Bardzo ważne jest dla nas, żeby używać zawsze najnowszych wersji języków i bibliotek.

Co charakteryzuje naszą pracę:

Przede wszystkim stawiamy na jakość – kod ma być prosty, czytelny, łatwy do utrzymania. Deadline’ów w większości przypadków nie ma, albo są drugorzędne. Co za tym idzie – nie estymujemy zadań.
Piszemy testy – każda metoda w kodzie ma mieć test jednostkowy, a większe funkcjonalności testy integracyjne (np. w Selenium).
Continuous delivery – nowa wersja na produkcji jest codziennie (no, poza weekendami).
Automatyzacja – automatyczne buildy, automatyczne testy, gotowe środowisko do pracy dla programistów. Do wszystkiego używamy Dockerów i Salta.
Kanban do zarządzania bieżącą pracą, każdy sam decyduje nad czym chce pracować.

Przez lata doświadczeń w poprzednich firmach byłem mocno zafascynowany ruchem Agile’owym i miałem to szczęście, że pracowałem z kilkoma topowymi konsultantami z branży. Wartości, które stoją u podstaw Agile’a i Extreme Programming są mi bardzo bliskie i na ich bazie staram się budować dział programistów w Thulium. Jeśli identyfikujesz się z tymi wartościami i Tobie również są bliskie, to serdecznie do nas zapraszam.

P.S. Mamy też żelazną zasadę dla nowych członków zespołu – każdy ma obowiązek przeczytać „Clean Code” Roberta C. Martina. I jak to mówi nasz kolega, powinieneś przeczytać tę książkę tyle razy, aż będzie się zgadzał z każdym stwierdzeniem. Myślę, że to najlepsze podsumowanie naszych wartości (śmiech).

Ten wpis powstał dzięki Coders Lab – Szkole Programowania

Tagi

cto, it, kod, programiści, programowanie