Dzień z życia programisty: Symu.co

Autorem tekstu jest Jacek Zajączkowski – Product Owner w Symu.co. Za pomoc w realizacji artykułu serdecznie dziękuję.

Bywają dni, że człowiek budzi się z czołem zroszonym potem i dzień zaczyna od rzucenia porządnej inwektywy w bliżej nieznanym kierunku. Jeden z takich dni był powodem powstania Windu CMS oraz Symu.co, narzędzi stworzonych przez Adama Czajkowskiego. Windu miało być polską odpowiedzią na WordPressa, CMSem pozwalającym spokojnie przespać noce, nie martwiąc się o kolejne wordpressowskie pluginy. Symu natomiast wyrosło na ziemi skraplanej łzami po kontaktach z klientami. A że łez było dużo, narzędzie to rozrosło się w szybkim tempie. Obydwa twory są zbiorem doświadczeń wyniesionych z agencji interaktywnej, której Adam jest założycielem.

CEO Symu.co – Adam Czajkowski

Ponieważ zwykle komunikacja z klientem – polegająca na wymianie maili i dodawaniem do nich grafik – mogła powodować frustrację wynikająca z niezrozumienia, potrzeba było prostszego rozwiązania. Rozwiązaniem tym okazała się możliwość komentowania zmian dotyczących projektu bezpośrednio na nim. Dodawanie komentarzy – zamiast pisania elaboratów w mailu – pozwala na oszczędność czasu i zachowaniu resztek rozsądku, który może okazać się przydatny, jeśli chce się dożyć sędziwego wieku. Dodatkowo, dzięki zastosowaniu hotspotów w Symu, klient może obserwować zachowanie strony. Bez napisania choćby pojedynczej linijki kodu, dochodzi do wstępnego zatwierdzenia projektu.

Praca w Symu nie odbiega znacznie od ogólnie przyjętych modeli. Na upartego można przyjąć, że stosujemy okrojoną wersję SCRUMa, chociaż bierny obserwator mógłby tego na pierwszy rzut oka nie zauważyć. W przypadku naszego 6-osobowego zespołu (włącznie z grafikami) bardzo łatwo zresztą o podział obowiązków. Każdy dzień rozpoczyna się w ten sam sposób. Po 10 minutach oglądania filmików z kotami na YouTube, następuje uruchomienie Slacka, Wunderlisty, a potem przejrzenie wszystkich zadań. Jeszcze ktoś w między czasie rzuci dowcip na poziomie uczniów z gimnazjum, ale później słychać już tylko klikanie myszki i uginanie się klawiatury. Koledzy od front-endu uruchamiają Atoma, nastomiast ci od back-endu PHPStorma. Pomimo, że cała załoga pracuje na 68m², do komunikacji używamy głównie Slacka, tak jak na rasowych nerdów przystało. Zdarza się jednak, że przecieramy szlaki na drewnianych deskach zmuszając mięśnie do wysiłku. Głównie wtedy, gdy front potrzebuje pomocy backendowca albo nie do końca rozumie, co grafik miał na myśli. Osobiste wędrówki nabierają nowego znaczenia. Schemat pracy zazwyczaj wygląda tak, że product owner po otrzymaniu feedbacku od użytkowników, dodaje zadania na Wunderliście, a następnie przydziela je odpowiednim osobom. Zadania podlegają hierarchizacji. Czasami najpierw wykonuje się prostsze rzeczy, a czasami trudniejsze. Wszystko zależy do tego, jaki wpływ ma dana zmiana na UX. To UX decyduje o tym, która zmiana jest ważniejsza.

Zespół programistów Symu.co

Głową zespołu jest twórca Symu, czyli Adam. To on ostatecznie zatwierdza wszelkie zmiany po rozmowie z product ownerem i sam również dodaje zadania na liście. Adam także programuje w PHP i tworzy core softu. Nie wyobraża sobie pracy bez swojego MacBooka Pro, dodatkowego monitora 22” i PHPStorma. Po wypiciu pierwszej kawy i zjedzeniu batonika, przegląda zadania na Wunderliście. Najtrudniejsze zadania, o ile nie dotyczą Javascriptu, bierze na siebie.

Biorąc pod uwagę zaawansowany stan Symu, narzędzie to podlega już tylko drobnej ewolucji. Na pierwszy ogień zawsze idą poprawki, dlatego też to Adam jest osobą, która się nimi zajmuje. Jeśli poprawki zostają „zdjęte”, wtedy przychodzi czas na udoskonalanie Symu. Stąd też na Wunderliście Symu, jako pierwsza widnieje grupa „Błędy”, następnie „Realizacja”, „Na później i „Nieistotne”. Trzy ostatnie grupy dotyczą dodatkowych feature’ów. Kolejność ich podyktowana jest stopniem ważności dla UX. I tak przykładowo, w błędach można znaleźć zadanie „problem z hotspotami w Firefoxie”, a w grupie Realizacja „widok listy projektów”. Każda zmiana zapisywana jest w Bitbuckecie, oddzielnie framework i oddzielnie aplikacja. Najnowszym bugiem, który niemożebnie zirytował zespół, była niemożność   dodawania komentarza na „fixed header”. Błąd, który dotyka podstawowej funkcjonalności serwisu jest najgorszy. Natomiast pierwszym na liście nowym featurem jest dodanie do komentarzy opcji – „attach file”. Zmiana podyktowana własnymi obserwacjami, a nie feedbackiem od klienta.

Stanowisko pracy programisty Symu.co

Wprowadzanie takich zmian jest zawsze najprzyjemniejsze, ponieważ wtedy skamieniałe serce product ownera na chwilę bije tak, jak zwykłego człowieka. Bywają jednak dni, kiedy najlepszy internetowe memy i filmy o kotach nie pomagają. Serią takich mrocznych dni było integrowanie z API do płatności cyklicznych PayPala. Gdy już się wydało, że integracja działa, nagle okazywało się, że system od razu nie pobiera opłaty. Próby odnalezienia błędu nie kończą się sukcesem, co przekłada się na większą frustrację i zrzucaniem winy na API PayPala. W takich wypadkach przydaje się zatrzymanie się, wyjście na taras i zajęcie się czymś kompletnie innym. Kolejny wykład Jacka Bartosiaka na słuchawkach i zabranie się za coś nieistotnego, jak na przykład poprawa wyglądu tooltipów.

Wszystko rekompensuje jednak obserwacja ewolucji produktu. Jak na dniach system zyskuje nową funkcjonalność, a userzy napiszą w mailu „fajne to wasze narzędzie”. Wtedy okazuje się, że każda linijka miała sens.

Dzień z życia programisty, Dzień z życia programisty Symu.co, IT, Organizacja pracy, Programowanie, Scrum, Symu.co, Windu, Windu CMS