Nasza biblioteka uniforms ma ponad 200 tys. pobrań. Jak to osiągnęliśmy?

– Najważniejsze żeby zgłaszającym poświęcać czas regularnie. Często jest tak, że zdeterminowany użytkownik sam proponuje obejście błędu, z czego później korzystają inni – mówi Radosław Miernik, współtwórca biblioteki uniforms i architekt oprogramowania w Vazco. Od 3,5 roku zespół utrzymuje i rozwija bibliotekę do tworzenia formularzy, z której korzystają tysiące ludzi na całym świecie.

Jak od środka wygląda praca nad takim projektem i czy firmie opłaca się go rozwijać? Na te i na wiele pytań odpowiedzi znajdziecie poniżej.

Jaka jest historia powstania biblioteki uniforms?

Aplikacje, które robimy mają formularze. Niektóre mają ich więcej, niektóre mniej. Pisanie ich to bardzo powtarzalna praca, którą chcieliśmy zautomatyzować. Napisaliśmy więc pierwszą wersję uniforms i przetestowaliśmy ją w projekcie. Jak to często w takich wersjach bywa, nie udało się. To co widzisz to wersja druga, poprawiona. Paczka tak naprawdę robi dokładnie to, do czego jej potrzebowaliśmy, czyli pozwala zaoszczędzić czas.

Dlaczego zdecydowaliście się na jej publikację?

Decyzja o tym, że udostępnimy publicznie naszą paczkę padła zanim jeszcze powstała. Uznaliśmy, że skoro borykamy się z tym problemem, to chcemy zrobić coś, co pozwoli zaoszczędzić czas także innym. Mamy jednak skończoną liczbę projektów, więc chcieliśmy żeby produkt przetestowało jak najwięcej ludzi. Zaletą rozwiązań Open Source jest to, że mamy dużo ludzi, którzy używają projektu i potencjalnie dają nam feedback. Stosują go w innych przeglądarkach niż my, z innymi wersjami zależności i tak dalej. Dlatego właśnie zdecydowaliśmy się na Open Source.

Jak pracochłonne jest wspieranie biblioteki?

Zależy od tego czym zajmuje się dane oprogramowanie czy biblioteka. Generalnie im bardziej jest to narzędzie dla programistów, tym większa jest szansa na to, że będą konkretnie mówili, co nie działa, bo będą to wiedzieli. Czasem nawet sami znajdą tego przyczynę. I czasem nawet po prostu pomogą ją rozwiązać. Z drugiej strony są to często osoby na tyle techniczne, że nawet samo powiedzenie nam, że coś nie działa jest wystarczająco dokładne. Wtedy wiemy już co zrobić, żeby to naprawić. To nie są zgłoszenia w stylu: „guzik nie działa jak się go kliknie”.

Wygodne jest to, że udostępniamy narzędzie dla raczej technicznego grona osób, które jest świadome tego, że to tylko narzędzie. To tylko biblioteka, a nie panaceum na całe zło. Już 47 osób wzięło udział w jej tworzeniu, znacznie więcej osób zgłosiło błędy.

Ktoś wziął udział, ktoś zostawił komentarz albo napisał maila, że coś powinno działać inaczej. Co się dzieje dalej z takim zgłoszeniem?

Zgłoszenia możemy podzielić na trzy grupy. Jedna to “czyste” zgłoszenia błędów, czyli coś nie działa. Osoba mówi, że w takiej i takiej konfiguracji, takie i takie użycie, z taką a taką wersją, w takiej a takiej przeglądarce po prostu nie działa. Najczęściej zgłaszający opisuje w jaki sposób nie działa, na przykład pisze: formularz nie reaguje.

Te problemy są najprostsze, bo wystarczy krótka komunikacja i już wiemy co się dzieje. Często mamy możliwość zreprodukowania tego błędu, no i tak naprawdę od razu możemy pomóc tej osobie. Wydajemy wtedy nową wersję. Wiemy, że coś poprawiliśmy, ta osoba ma działający produkt. Stworzenie całej biblioteki trochę nas kosztowało, ale robiąc rachunek kosztów i strat wiemy, że zrobiliśmy coś dla innych, a przy okazji zaoszczędziliśmy czas w przyszłości.

Jesteś osobą odpowiedzialną za tę paczkę czy dzielisz się zadaniami z zespołem na dni tygodnia?

Jestem pomysłodawcą biblioteki, pracuję nad nią prawie 3,5 roku i zajmuję się stroną Community i jej rozwojem. Praca nad biblioteką zmienia się, czasem ktoś dołącza, czasem odchodzi. Doda czy poprawi jedną rzecz, bo na projekcie czegoś potrzebuje. Czasem wewnętrzne projekty zgłaszają jakieś błędy czy zapotrzebowanie na nowe funkcjonalności.

Co zmieniło się w uniforms od czasu premiery?

Pierwsza wersja to maj 2016 roku. Od tamtej pory największa zmiana dotyczyła motywów. W pierwszej wersji były tylko dwa, teraz jest ich pięć. W pierwszej wersji obsługiwaliśmy tylko jeden rodzaj definiowania formularzy, aktualnie obsługujemy cztery. Przybyło nam też funkcjonalności.

Z czego wzięły się pomysły na te motywy?

Oprócz błędów użytkownicy zgłaszają nam prośby o dodanie nowych funkcjonalności. Jeśli zapotrzebowanie ponawia się 10, 15 razy, to możemy potem wziąć te 15 różnych, czyichś skórek, skomponować w jedną, uznać że jest oficjalna i samemu ją wspierać. Autorzy rozwijają je trochę samoczynnie, choć podpisujemy się pod tymi zmianami. Jesteśmy pośrednikiem, bo zajmujemy się utrzymaniem kodu, ale jeżeli wychodzi nowa wersja jakiejś zależności, to tak naprawdę Community zajmuje się tym, żeby paczka działała z najnowszą wersją.

Bardzo ważne jest zatem nastawienie ludzi, tak? Zrozumienie na czym polega Open Source?

Tak. Aktywni użytkownicy wychodzą z takiego samego założenia co my. Włożywszy w to skończoną ilość czasu otrzymuję potencjalnie dziesięć razy tyle testowania, ile mogę sobie wyobrazić. Jest to dla mnie spora wartość, bo spędzę kilkadziesiąt godzin robiąc nowy motyw, ale potem ludzie mogą go używać w przyszłości. Testować, rozwijać i pomagać go utrzymywać.

Jak rozumiem to jest też jakaś wartość dla kandydata do pracy, że uczestniczył w takim projekcie?

Uważam, że każdy udział w Community Open Source wiąże się z odwagą do tego, by powiedzieć komuś, że jego rozwiązanie nie działa i mogłoby działać lepiej. Takie zachowanie pokazuje, że dana osoba potrafi się komunikować. Współpraca nad projektami Open Source’owymi świetnie sprawdza się w przypadku osób bez doświadczenia komercyjnego. Pracodawca, na podstawie projektu, w którym uczestniczył, może zobaczyć w jaki sposób ktoś się komunikuje, czy wspiera projekt.

Wróćmy jeszcze na chwilę do historii biblioteki. Co się stało po publikacji? W jaki sposób zdobyła zainteresowanie społeczności? Ma obecnie 212 tysięcy pobrań.

W tamtym momencie znaczna część naszych projektów była oparta na technologii Meteor i paczka powstała jako alternatywa do innej popularnej wtedy paczki do formularzy. Nasza była oparta o Reacta. Bibliotekę chcieliśmy wypromować wśród osób, które faktycznie korzystały z Meteora, tak jak my. Na początku mieliśmy tylko integrację definiowania formularzy z logiką pod Meteora oraz ze skórkami, które wtedy były na czasie, a które używaliśmy w projektach. Z czasem, gdy Community urosło i paczka osiągnęła stabilny status, zaczęliśmy zastanawiać się jak ją szerzej promować.

Pierwsi o istnieniu paczki dowiedzieli się użytkownicy forów dotyczących Meteora – do dziś pozostają najbardziej aktywnymi kontrybutorami. Fajne jest to, że w tym Community są osoby, które programują od lat, mają spore doświadczenie i pracują w znanych firmach. To one zaczęły same z siebie promować uniforms i ten organiczny ruch dał nam sporo satysfakcji.

Utwierdziło Was to w przekonaniu, że ma to jakiś sens? Skoro sama społeczność promuje tę paczkę, to rzeczywiście ma jakąś wartość?

To rzeczywiście przyjemnie uczucie, a jeszcze lepsze, gdy przychodzą ludzie i mówią, że naszej biblioteki używają w dwa razy większej ilości projektów, niż my. Pytaliśmy wielu użytkowników, czy są zadowoleni, czy mają problemy, uwagi, to większość odpowiadała, że nie, że wszystko działa. Z drugiej jednak strony mieliśmy poczucie, że nie chcemy tak skończyć tej paczki. Nie chcieliśmy tak po prostu przestać jej rozwijać.

Doszliście już do takiego poziomu zaufania, w którym użytkownicy wiedzą, że mogą skorzystać z tej paczki. Co jednak w sytuacji, kiedy tworzymy projekt po godzinach? Jak zdobyć zaufanie?

Sam robię takie projekty po godzinach. Jestem świadomy tego, że sporo osób nie korzysta z danego projektu, bo nie ma za sobą dużej firmy. Boją się, że jedyny autor projektu zachoruje czy po prostu mu się odechce i skończy rozwijać projekt.

Zastanawiam się jak programiści dokonują wyboru, że korzystają z tej a nie innej paczki?

W przypadku projektów komercyjnych decyzji nie dokonuje programista tylko programiści. Gdy mamy do czynienia z długodystansowym planowaniem architekta i osoby zajmującej się długiem technologicznym, często są sceptyczne do tego typu rozwiązań z zewnątrz. Jeżeli za paczką nie stoi Facebook, Google, Red Hat itd., architekci są raczej na “nie”, dlatego, że ktoś może w pewnym momencie porzucić projekt, przez co zespół straci wiele wiele miesięcy developmentu.

Co zatem utwierdza Waszych użytkowników w przekonaniu, że nadal będziecie rozwijać uniforms?

Są zdziwieni, że zawsze odpowiadamy na ich pytania w ciągu 2-3 dni. Samo podtrzymywanie Community na takim poziomie odzywania się do siebie i reagowania na problemy już daje podstawę do wierzenia, że ktoś cały czas zajmuje się tym projektem. Z paczki korzystają duże firmy, utrzymujemy ją przez 3 lata, co zwiększa zaufanie.

Powiedziałeś wcześniej o Meteorze, a wiem też, że korzystacie z GraphQLa. Dlaczego wybraliście tę technologię?

Może to lekko ryzykowne, ale staramy się być na takim lekkim hypie. Wierzymy, że nowe technologie są na tyle blisko ciekawych rozwiązań, że nawet jeżeli uznamy rozwiązanie za nadające się do wyrzucenia, to zawsze przyniosło nam jakąś wiedzę. Dla nas największą wartością było to, że Apollo zostało wydane przez przez MDG – Meteor Development Group – ludzi, którzy rozwijali Meteora. Wiedzieliśmy, że są świetni, robią dobrą robotę. Wierzyliśmy w nich i jak widać opłaciło się. Jesteśmy te kilka lat później i GraphQL faktycznie jest rewolucyjną technologią.

Większość firm idzie utartą ścieżką i wybiera zawsze sprawdzone rozwiązania. Klienta interesują takie ciekawostki? Nie naciska, żebyście używali sprawdzonych, starych rozwiązań?

W przypadku bardzo dużych projektów liczonych na tysiące godzin, lata pracy, nowe technologie to może nie najlepszy wybór. Wtedy lepiej faktycznie postawić na coś sprawdzonego, tak dla pewności. Jeżeli mówimy o dodatkowym projekcie, staramy się mierzyć technologię pod niego. Nie działamy wszędzie według takiej samej technologii, to nie jest nasze podejście.

Będąc świadomym tego, jakie są nowe technologie, w czym są dobre, a w czym złe, możemy klientowi powiedzieć, że mamy małe doświadczenie w takiej technologii, ale widzimy, że idealnie pasowałaby do tego projektu. Często przedstawiamy wystarczająco dużo argumentów klientowi, w stylu: z jednej strony to jest nowa technologia, więc może będą jakieś błędy, może nie mamy w niej doświadczenia, może nie mamy jeszcze wystarczająco dużo wiedzy jak pracować dobrze w tej technologii. Możemy jednak zyskać jakieś rzeczy, które ta technologia nam da, których inne nie mają. W przypadku GraphQL to głównie upraszczanie rozwiązań. To ważne, ponieważ mówi się, że 75% projektów upada ze względu na zbytnie skomplikowanie.

A jak od środka wygląda taka rozmowa z klientem?

Często po dogłębnej analizie projektu, robimy dla klienta zestawienie, które pomaga mu podjąć świadomą decyzję. Następnie rozmawiamy o tym i szczegółowo tłumaczymy, oraz odpowiadamy na pytania i wątpliwości klienta. Dzięki temu wie o ryzyku, ale też i o korzyściach nowych rozwiązań. Razem szukamy najlepszej ścieżki.

Dla programisty styczność z nowymi technologiami to zaleta?

Wydaje mi się, że to bardzo personalna sprawa. Nie wszyscy lubią eksperymentować, nie wszyscy lubią poznawać nowe technologie. Wielu moich kolegów i koleżanek eksperymentuje z technologiami we własnym czasie. Może w mniejszej ilości i rzadziej, bo nie mają tyle wolnego czasu, ale sami z siebie to w jakimś stopniu robią. To nie jest tak, że nagle przychodzi szef i mówi: dzisiaj eksperymentujemy z GraphQL. Zazwyczaj takie propozycje padają od nas.

Jaki udział ma klient w podejmowaniu decyzji o wyborze konkretnej technologii? Zawsze ma ostatnie zdanie?

Klient zawsze ma ostatnie zdanie. Gdy mówi, że nie jest pewny, czasem sprowadza się to do przygotowania prototypów dla obu wersji. Takie przedstawienie rozwiązań pomaga klientowi odpowiedzieć na jakieś pytania. Czasem analizujemy dlaczego klient nie chce tego rozwiązania. Może trzeba zmienić argumenty lub podejście? Nigdy nie jest tak, że zmuszamy do czegoś klienta. Nigdy też nie jest tak, że ulegamy tak po prostu. Jeżeli proponujemy i spędzamy czas żeby przygotować propozycję jakiejś technologii, to nie robimy tego po to żeby się pobawić, tylko robimy to dla czegoś. Mamy jakiś powód i pomysł, dlaczego jakaś technologia mogłaby być potencjalnie lepsza.

Powiedz o przyznawaniu się do błędów, bo to też jest, mam wrażenie, pomijany temat. Zdarzyła Wam się taka sytuacja, że wybraliście technologię wspólnie z klientem i jednak coś źle się potoczyło?

Dla nas taką technologią był blockchain. Zaczęliśmy na fali hype’u i przestaliśmy zaraz po projekcie pilotażowym. Nawet nie zaczęliśmy nic komercyjnego. Podobnie niektórzy ludzie na fali takiego hype’u zaczęli się bardzo pchać w GraphQL, tylko po to, żeby mieć coś wspólnego z GraphQL. Takiej wtopy, żeby nie wiedzieć jak z tego wyjść nie mieliśmy.

Myślę, że wiele firm ma kosmiczny dług technologiczny i po prostu z tym żyje. Często próba robienia z tym czegoś kończy się tak szybko jak się zaczyna.

Jak się przed tym uchronić?

Trzeba starać się podejmować jak najbardziej doinformowane decyzje. Zanim zdecydujemy się na wykorzystanie mocno promowanej technologii, spróbujmy popracować z nią przy małym projekcie. Z GraphQLem tak właśnie było – zaczęliśmy od małego projektu. Realizowały go dwie albo trzy osoby, a dopiero później pokazaliśmy go całej firmie. Podczas warsztatów opowiadaliśmy dlaczego zrobiliśmy tak, a nie inaczej.

Gdybyś wcielił się w rolę programisty, który szuka pracy, to na co zwracałbyś uwagę przeszukując oferty? Jak podjąłbyś decyzję, czy pracować w małej, średniej czy w dużej firmie?

Pod kątem pracy i wartości dla programisty wydaje mi się, że to już bardzo zależy od samej firmy. Mam znajomych, którzy pracują w dużych firmach i dalej cieszy ich to co robią. Próbują nowych technologii, choć nie pracują w dziale R&D, które w korporacjach często są sposobem na nudę. Znam też ludzi, którzy pracują w małych firmach, realizują projekty w starych technologiach tylko dlatego, że są one sprawdzone, dobrze się w nich czują. Tutaj nie ma jakiejś reguły. Wydaje mi się, że bardzo często jest tak, że każdy musi ocenić to, co chce robić.

Oferty pracy z

A dla Ciebie co jest ważne?

Dla mnie bardzo ważne jest to, by wynieść jak najwięcej doświadczeń z każdej firmy, w której pracowałem. Nie dbać tylko o wpis w CV, a realnie doświadczyć czegoś, co pomoże w rozwoju mojej kariery. Często jest tak, że ludzie zmieniają pracę tylko dlatego, że chcieliby się spróbować z nową technologią, a nie mogli tego zrobić w poprzedniej firmie.

Temat rozwoju to zadanie dla product managera, product ownera czy ogólnie przełożonego? Czy raczej każdy powinien zadbać o rozwój samodzielnie?

To zależy od tego jakie cechy chcemy rozwijać. Z punktu widzenia managera bardzo dobrze byłoby, gdyby osoby na niższych stanowiskach uczyły się rzeczy technicznych, żeby były bardziej samodzielne. Z kolei osoby na wyższych stanowiskach miały doświadczenie w komunikowaniu się, w udzielaniu jakiejś odpowiedzi, sposobie pomocy, może prezentowania i dzielenia się wiedzą. Każdy ma swoje cele. Młody programista chce się uczyć i generalnie wszystkim powinno zależeć na tym żeby nabierał doświadczenia, starał się być samodzielny i nabywał nowych umiejętności.

A z punktu widzenia Seniora?

Finał może być dwojaki, bo sam zainteresowany, czyli programista może z jednej strony chcieć pogłębiać wiedzę w konkretnej technologii, poznawać nowe, żeby móc np. powiedzieć, że ta jest lepsza od tej w tym przypadku, a ta lepsza od tej w takim przypadku. Senior powinien mieć szersze pole widzenia. Albo nauczyć się branży i być np. specjalistą w aplikacji na smart watche. Zależy to oczywiście od tego o jakiej technologii i branży mówimy. Z punktu widzenia managera jest tak, że zawsze dąży się do tego żeby projekt czy firma miała się jak najlepiej.

Mówimy o indywidualnym rozwoju. A w kontekście ogólnego rozwoju zespołu? Inaczej podchodzi się do zespołu, gdy składa się z mniej doświadczonych programistów?

Młodych programistów lepiej rozwijać ogólnie. Po prostu uczyć ich pracować, bo też wtedy sami będą mogli powiedzieć co ich interesuje. Sami będą wiedzieli jak się rozwijać. Wszystkich warto zachęcać do pracy z innymi, jakiejś współpracy nad kodem, projektem, współpracy między projektowej. I to zadanie jest bardzo ważne, bo często się o tym zapomina. Kończy się to w ten sposób, że człowiek jest świetnym ekspertem, robi coś kosmicznie dobrze lub strasznie szybko, ale nie jest w stanie o tym opowiedzieć. Odchodząc z firmy nie zostawia dokumentacji, bo nie był tego nauczony, ani nikt go nie pilnował żeby ją uzupełniał. Z punktu widzenia PMa powinno dążyć się do tego żeby wszyscy współpracowali jako zespół.

Co uważasz za największą zaletę pracy właśnie w Vazco?

Bardzo dużo osób mówi o tym, że można przyjść o 13:00 i wyjść o 21:00. Mamy na tyle luźną atmosferę, że możemy pracować w dowolnym miejscu, choć jeśli masz spotkanie projektowe to musisz na nim być. To nie jest jednak tak, że klient przychodzi i mówi, że spotkanie będzie o ósmej, tylko po prostu zespół dogaduje się, kiedy ono jest. Z punktu widzenia obowiązkowości i pracowania zdalnie jest to bardzo wygodne.

Dla mnie największą zaletą jest to, że faktycznie mam wpływ na to, co robię. Często mówimy przełożonym, że chcielibyśmy spróbować czegoś nowego, jakiejś technologii i na tego potrzeby robimy wewnętrzny projekt. Uważam, że to wartość dla klienta, bo może zachęcić inwestorów tym, że używa nowej technologii, która nie jest jeszcze taka popularna i może zgarnąć tym jakąś lwią część rynku. To też duża wartość dla mnie, że rozwijam się w nowej technologii. Ważne dla mnie jest także to, że uczę się nowych rzeczy, a nie robię kolejny i kolejny projekt w tej samej technologii.

---

Radosław Miernik. Entuzjasta Open Source, architekt oprogramowania, od 2015 w Vazco. Przygodę z programowaniem rozpoczął już w podstawówce. W pracy skupia się na detalach, a akademicko-hobbystycznie zajmuje się sztuczną inteligencją w grach. Pasjonat prawdziwej herbaty.

Zdjęcie Radka pochodzi z meetup.com/pl-PL/GraphQL-Wroclaw.