Developer Experience – jak zaangażowanie developerów wpływa na lepsze efekty software house’u

W tym artykule

• Maciej Stasiełuk CTO Vazco dzieli się z nami liderskim doświadczeniem i pokazuje na czym zasadza się dobry DX.
• Jasne procesy, eliminacja bezsensownych działań, upraszczanie pracy, wspierania rozwoju zawodowego – tego oczekują deweloperzy od organizacji, w których pracują lub mają pracować.
• Można wskazać obszary, które decydują o dobrym lub złym Developer Experience. To na przykład dokumentacja projektowa. Źle przygotowana może być frustrujący dla developerów i wpływać na nich demotywująco.

the:protocol.it: Czy programiści potrzebują innego wsparcia niż np. pracownicy sprzedaży? Czy raczej należy mówić o elementach wspólnych wszystkim pracownikom i o indywidualnych potrzebach pracowników-programistów?

Maciej Stasiełuk: Pracownicy mogą mieć bardzo podobne wymagania ogólno-organizacyjne. Jeśli pojawiają się różnice w oczekiwaniach, to mają związek z pracą już na konkretnych stanowiskach. Bez względu na to, czy mówimy o pracownikach sprzedaży, marketingu, kadr czy właśnie o programistach, te różnice znajdą się wszędzie.

Elementy kultury organizacyjnej, procesy, komunikacja itp. wpływają na wspomniany komfort każdego pracownika i tworzą coś szerszego, co możemy nazwać Employee Experience (EX), którego Developer Experience (DX) jest po prostu częścią.

Jak zatem zadbać o komfort pracy developerów?

Przede wszystkim należy dbać o to, aby programiści mogli skupić się na tym, co lubią robić najbardziej, a nie na rzeczach pobocznych, dodatkowych, powtarzalnych.

Można wskazać kilka obszarów, które wpływają na Developer Experience. To na przykład:

1. Narzędzia, z którymi na co dzień pracują programiści. Od hardware’u po software, muszą to być narzędzia, które są wygodne w użyciu i pozwalają skupić się na pisaniu i dostarczaniu wartości, a nie na czekaniu. Bo czekanie, nieważne czy na kompilacje, testy czy zwykłe przeładowanie strony, powoduje, że developerzy tracą skupienie.
2. Wygoda stosowanych rozwiązań. Nie tylko praca z edytorem skonfigurowanym pod siebie, ale też stack technologiczny, który jest znany i lubiany. Ważne, aby programista miał wpływ na ten stack, mógł go ewoluować i nie utknął ze starymi wersjami. Kluczowe jest też ograniczanie boilerplate’u – czyli powtarzalnego kodu, który trzeba napisać, nawet jak często jest taki sam.
3. Automatyzacje. Pozwalają one nie wykonywać rzeczy, których tak naprawdę nie trzeba robić ręcznie. Przydatne stają się tutaj dobrze skonfigurowane procesy Continuous Integration czy Continuous Delivery. Trzeba dodać, że programiści sami często tworzą automatyzacje w ramach upraszczania sobie pracy. Dzięki temu zamiast tracić czas na rzeczy powtarzalne, generyczne, mogą skupić swój potencjał twórczy na tematach nowych, unikalnych.
4. Dokumentacja. Warto, aby była ona przejrzysta, zrozumiała i użyteczna. Wiedza, która jest potrzebna w codziennej pracy powinna być łatwo dostępna i konsumowalna. Dotyczy to zarówno dokumentacji projektowej, jak i tej dotyczącej obsługi specyficznych narzędzi czy paczek wybranych przez zespół.
5. Kultura rozwoju i wymiany wiedzy. Ważne jest też, aby inne osoby w zespole były dostępne i chętne do pomocy, bo często szybka wymiana myśli na Slacku potrafi zastąpić kilka godzin czytania dokumentacji czy debugowania. Tak samo procesy w firmie muszą być proste i zrozumiałe, bo nikt nie lubi niepotrzebnej biurokracji, nadmuchanych procesów i spotkań, które mogły być mailem.

Co Twoim zdaniem sprawia, że developerzy lubią pracować przy swoich projektach?

Moim zdaniem wpływa na to kilka rzeczy.

Po pierwsze, praca przy projektach, w które wierzą i które ich osobiście jarają. Bo znacznie przyjemniej pracuje się przy startupie, o którym myślisz, że zmieni świat, niż przy następnej formatce w systemie bankowym.

Po drugie, ciągły rozwój i związana z nim wymiana wiedzy. W naszych zespołach prowadzimy np. code review, peer review, pair programming oraz inne procesy, które sprawiają, że stajemy się lepsi jako programiści, mamy bezpośredni wpływ na tworzony produkt i unikamy wypalenia zawodowego.

Ważne, aby developerzy mogli używać technologii, które lubią. Z niskim długiem technologicznym i bez legacy code’u – czyli starego kodu, z którym programista musi się niepotrzebnie męczyć. Mało jest osób lubiących pracować na projektach typu legacy. Większość programistów – i tak jest w naszej firmie – jarają nowości, innowacyjne projekty. Dlatego też skupiamy się na innowacyjnych startupach i pilnujemy, aby ten dług technologiczny utrzymywał się na niskim poziomie.

Warto dbać także o to, aby ludzie mogli się cały czas rozwijać, będąc w projekcie. Ktoś pracował na frontendzie, a chce na backendzie? Warto mu to umożliwić. Ktoś chce wprowadzić nowe rozwiązanie, o którym przeczytał? Jeśli ma to sens, to czemu nie. Ważne, by programistom pozwalać na realizację osobistych ambicji w ramach projektu.

Co zrobić, aby w firmie developerzy byli zadowoleni, a jednocześnie projekty były rentowne? Aby potrzeba samorozwoju pracowników nie stała w sprzeczności z jej biznesowymi celami?

Nie jest to łatwe, ale godzenie celów firmy z celami rozwojowymi poszczególnych osób jest możliwe. Na pewno bardzo zależy to od profilu firmy. Jeśli jest to firma produktowa np. z jednym produktem, to siłą rzeczy ta różnorodność, którą można zapewnić pracownikom, będzie trochę ograniczona.

W przypadku software house’u, gdzie prowadzi się równolegle kilkanaście projektów, możliwość zapewnienia różnorodności pracy jest większa. Poza tym, gdy dany projekt żyje i rośnie, to powstają nowe wyzwania, związane ze skalowaniem, optymalizacją, większym ruchem. Daje to możliwość rozwoju tym, którzy nad nim pracują. Jeśli któryś z programistów rośnie szybciej niż projekt, na którym pracuje, to zasługuje na to, aby np. zostać liderem innego projektu.

To jedyne rozwiązanie?

Można też stwarzać inne możliwości rozwoju developerom. Na przykład, gdy pracownik czuje się już zbyt komfortowo na swoim projekcie i zaczyna mu się nudzić, może zostać konsultantem w innych projektach lub przy jednorazowych zleceniach. Do nas często zgłaszają się firmy po audyty czy optymalizacje. Klienci zyskują wartościowe wskazówki i sugestie, a nasi pracownicy mają okazję poznać nowe projekty, prowadzone według innej filozofii niż u nas.

Z kolei w przypadku firmy z jednym produktem rozwiązaniem może być np. przeniesienie programisty do zespołu zajmującego się innym obszarem.

Jednak nie samą pracą komercyjną developer żyje. Aktywnościami, które świetnie poszerzają horyzonty i sprawiają, że praca programisty jest jeszcze ciekawsza, są wszystkie kwestie związane z dzieleniem się wiedzą. Mowa tutaj choćby o tworzeniu rozwiązań Open Source’owych, ale też o pisaniu artykułów, mentorowaniu czy czynnym udziale w meetupach i konferencjach. I tak też działamy w naszej firmie – dajemy każdemu przestrzeń do prób, by poznał, w czym czuje się najlepiej.

Ścieżki kariery, procedury wspierające rozwój pracowniczy… Jakie systemowe rozwiązania wykorzystać do budowania strategii DX w firmach?

Jeśli chodzi o ścieżki rozwoju, to wyróżniłbym tu dwie wyraźne grupy.

Część ludzi ma naturalne zacięcie do rozwijania się. Wystarczy tylko stworzyć im możliwości, a oni po prostu je wykorzystają. Takim ludziom mapy kariery nie są potrzebne, bo oni po prostu mają pomysł na siebie i wystarczy im nie przeszkadzać.
Natomiast niektórzy potrzebują popchnięcia do przodu, ścieżki rozwoju, która będzie pokazywała im, w jakich innych rolach mogą się jeszcze sprawdzić.

Systemowe rozwiązanie, jakie zastosowaliśmy u nas, to przede wszystkim decentralizacja zarządzania firmą i dawanie wpływu na decyzję tym, których te decyzje dotyczą. Cała nasza firma podzielona jest na kręgi odpowiedzialne za dane obszary. Każdy może dołączyć do kręgu, który go interesuje i mieć wpływ na to, jak pracuje. Przykładami takich kręgów są np. Open Source (rozwijanie naszych paczek, np. uniforms), narzędziowy (decydujący na jakim sprzęcie pracujemy) czy rekrutacyjny.

Niektóre kręgi zrzeszają dane role jak np. QA, PM, DevOps czy Tech Lead. Dzięki temu o swoje warunki pracy i DX dbają sami zainteresowani, a niezainteresowani a nie osoby operujące w zupełnie innych kontekstach.

Czy firma, która umożliwia pracownikom rozwój zawodowy, powinna sprawdzać, czy korzystają oni z oferowanych możliwości?

Tak. Firma powinna brać aktywny udział w tym rozwoju. Nie badając tego, nie może ocenić, czy robi to dobrze. Należy poświęcać dużo uwagi na zbieranie feedbacku od pracowników, by wiedzieć, czy te działania, które są im oferowane, dają im to, czego potrzebują.

W naszym wypadku mierzymy regularnie eNPS, czyli metrykę, która mówi nam, jak bardzo zadowoleni są nasi pracownicy i co możemy robić lepiej. Mamy regularnie sesje peer to peer, które pomagają zebrać feedback od współpracowników. Mamy też procesy feedbackowe i mentoringowe, które pomagają wytyczyć developerom ukierunkowane na nich cele rozwojowe i po czasie sprawdzić, czy były trafne.

Czy wdrażanie DX w firmie pomaga zbudować zespół, utrzymać developerów? Czy jest to sposób, by przyciągnąć i zatrzymać wykwalifikowanych programistów?

Na pewno, ponieważ dobry DX działa na korzyść firmy, a przede wszystkim znacząco zmniejsza rotację pracowników. W przypadku programistów DX jest kluczowy. Ludzie zmieniają pracę z różnych powodów – często dlatego, że nie mają zapewnionych warunków pracy, których oczekują. Zapewniając im odpowiednie środowisko nastawione na komfort pracy i rozwój, zyskuje się usatysfakcjonowanych i stałych pracowników.

Poza tym dzięki DX programiści mogą pracować efektywniej, co przekłada się też na wydajność firmy. Pracownicy zadowoleni ze swojej pracy wykazują też większą proaktywność i kreatywność, co z kolei bardzo pomaga zauważyć, co jeszcze można zrobić lepiej w projektach czy w firmie.

I warto pamiętać, że developerzy, którzy są szczęśliwi w swojej firmie, chętniej reklamują ją i ściągają do niej znajomych, co przekłada się na wyższą skuteczność rekrutacji.

Czy developerzy zwracają uwagę na to, czy firma, która prowadzi rekrutację, dba o DX w firmie?

W rozmowach rekrutacyjnych ludzie pytają o to, ale nie wprost. To znaczy nie spotkałem się jak dotąd z bezpośrednim pytaniem o DX, natomiast kandydaci próbują ocenić, czy będą w firmie szczęśliwi. Pytają o narzędzia, procesy, kulturę organizacyjną. Porównują i to, co usłyszą, odnoszą do dotychczasowych doświadczeń. Myślę też, że ci proaktywni programiści oczekują, by tego owijania w bawełnę było mniej. Dobry DX do tego właśnie się sprowadza – do jasnych procesów, do eliminacji bezsensownych działań, upraszczania pracy, wspierania rozwoju zawodowego.

W pewnym stopniu rozwiązania wspomagające pracę developerom zapewnia dziś sztuczna inteligencja.

Tak i być może za kilka lat, narzędzia będą na tyle skuteczne, że developerzy będą tylko akceptować to, co napisze sztuczna inteligencja (AI). Developer Experience też wówczas będzie inny, silnie wspierany przez AI.

Nie sądzę jednak, aby sztuczna inteligencja szybko pozbawiła pracy programistów, ponieważ nie jest to zawód „maszynowy”. Praca programisty wymaga ogromnej kreatywności i zawiera element twórczy. Bliżej mu do artysty, który musi zrozumieć oczekiwania klienta, zobaczyć cel, a potem przekuć to w program. Biorąc pod uwagę, że wymagania klientów bywają tak zmienne, że trudno je zautomatyzować – a to jest domeną sztucznej inteligencji, to szybko nie da się developera zastąpić maszyną.

Jeśli założylibyśmy, że rolą programisty jest tylko pisanie kodu, to tak – sztuczna inteligencja faktycznie mogłaby przejąć tę rolę. Natomiast praca programistów jest znacznie szersza. To nie tylko pisanie kodu, więc AI raczej będzie pełnić tylko funkcję wspierającą.

My w firmie mamy filozofię „code is a waste”, która mówi o tym, że celem pisania kodu nie jest kod sam w sobie, a jest osiągnięcie zamierzonego rezultatu, najczęściej biznesowego. Jeżeli można ten sam cel osiągnąć bez napisania kodu – super, zróbmy to. Każda linijka kodu ma przybliżyć nas do zamierzonego celu, a pozostałe są tylko wspomnianym „waste”. Wierzymy, że kod jest jedynie narzędziem do realizacji celu, a nie celem samym w sobie.

Z samym Developer Experience jest podobnie. Wszystkie nadmiarowe procesy, przeszkadzajki, które odciągają uwagę; każda niepotrzebna czynność, którą programista musi, a której nie chce wykonać – to „waste". Unikając ich, sprawiamy, że praca jest przyjemniejsza dla wszystkich.