Błędnym założeniem jest to, że developerzy odchodzą tylko dlatego, że za mało im się płaci. W Stanach programiści utrzymują się na stanowiskach w firmie średnio przez 18 miesięcy. W Polsce z moich obserwacji rotacja jest nieco dłuższa, trwa między 24 a 36 miesięcy. Sen z powiek rekruterom spędza obecna sytuacja na rynku. Aktualnie wygląda to w ten sposób, że człowiek przychodzi do pracy w małej, średniej firmie za pewną płacę. Robi swoją robotę, następnie pojawia się duża firma outsourcingu IT i wykupuje wszystkich po kolei dając 2x tyle w ciemno. Następnie, po kilkunastu miesiącach, nasz bohater opuszcza duże korpo bo coś jest nie tak. Niby fundusze na koncie się zgadzają, ale czegoś brakuje…
Masz tutaj piwo i koszulkę, a teraz koduj!
Widzimy jak firmy starają się przyciągnąć ludzi darmowym jedzeniem, elastycznymi godzinami, firmowym MacBookiem, czy nawet darmowym piwem w lodówce w piątki. Jest to świetna sprawa, która buduje bardzo fajny komfort pracy. Ale czy to faktycznie konieczne?
Obserwując programistów możemy zauważyć, że uwielbiają się identyfikować. Identyfikują się z firmą, technologami, na których pracują czy społecznościami developerskimi. Ubierają się w swoje ulubione koszulki z logiem pracodawcy- drupala, pomarańczowego lisa, zielonego droida lub przywdziewają gadżety z ostatniego hackatonu. Skąd taka potrzeba przynależności?
Piramida potrzeb programisty
Każdy ze szkoły zna piramidę potrzeb Maslowa. By żyć potrzebujemy zaspokoić potrzeby fizjologiczne i mieć zapewniony bezpieczny byt. Potrzebujemy przynależeć do społeczności, inaczej będziemy czuli się samotni i odrzuceni. Gdy jesteśmy w grupie chcemy uznania, przez co budujemy swoją wartość. Aż wreszcie możemy się poświęcić rozwojowi i stawaniu się tym, kim chcemy być.
Analogie piramidy możemy przyrównać do osoby programisty. Fizjologią w tym wątku będzie miejsce pracy. Nowe dizajnerskie biurko z Mackiem na blacie, lodówka pełna darmowych napojów i przekąsek to tak naprawdę podstawa. Bezpieczeństwo programiście zapewnia stała okrągła sumka na koncie.
Zauważcie teraz, że głównie tylko na tych dwóch polach ścierają się pracodawcy. Czy Wy bylibyście długo szczęśliwi mając zaspokojone tylko potrzeby fizjologiczne i bezpieczeństwo?
Programista jak żaden inny człowiek potrzebuje czuć, że jest w grupie i jest częścią czegoś większego. Jest częścią grupy projektowej, która zamyka kuriozalne projekty w nagiętych deadlinach pod wodzą PMa komandosa. Uwielbia programować i udzielać się na forach iOS’a, równocześnie robiąc komity na gicie dla pewnego projektu opensource. T-shirty, które lubi przywdziewać z tej okazji, to manifestacja jego przynależności, którą jak żaden inny człowiek uwielbia demonstrować. Teraz zadajcie sobie pytanie jak wygląda to u Was? Czy tworzysz w firmie zgrany zespół czy grupę indywidualistów bez większych powiązań?
Te trzy pierwsze schodki w piramidzie programisty zapewnia większość firm. Prawdziwa zabawa zaczyna się z kolejnymi dwoma. Porozmawiajmy więc o 2 najtrudniejszych rzeczach w budowaniu zespołu.
Uznanie budujesz po wykonanej pracy nigdy przed
Ciągłe doskonalenie pracy nad projektem nie polega tylko na skupianiu się na błędach i jego naprawianiu. Większość metodyk, w których pracujemy, wymagają od nas retrospekcji po danej iteracji. Często nie mamy na nie czasu ;) Analizując wykonaną pracę skupiamy się na poszukiwaniu pomyłek w kodzie i jego działaniu. Postarajmy się podczas feedbacku skupić na omówieniu błędów oraz na tym, co wyszło dobrze. Kiedy ostatnio raz podszedłeś do swojego zespołu i powiedziałeś: „Hej chłopaki ten moduł, który napisaliście w poniedziałek jest świetny!” – tylko po to, żeby poczuli się bardziej dowartościowani?
Samopoczucie zespołu bardzo łatwo można zniszczyć. W szczególności, jeżeli koncertujesz się na wytykaniu błędów i szukaniu winnych. Prawdziwymi zabójcami są tutaj kiepscy menadżerowie. Developerzy nie odchodzą z firmy, odchodzą od kiepskiego zarządzania. Nie mówię, że nie możesz być twardym i stawiać konkretnych wymagania. Jednak jeżeli bierzesz pochwały tylko na siebie, a swoimi błędami obarczasz zespół, to nie zajdziesz z nimi za daleko.
Zadbaj o wymianę doświadczeń. W niektórych zespołach możemy się spotkać z pracami krzyżowymi. Np. kiedy programista razem z grafikiem omawiają swoje wdrożenia. W małych firmach i zespołach jest to łatwe do zrobienia. Może nie trzeba sadzać ich obok siebie na cały tydzień, ale na godzinę, dwie w tygodniu. Dzięki czemu obie strony mogą lepiej zrozumieć swoja pracę i spojrzeć na pewne rzeczy z innej perspektywy. Dodatkowo jest to fajna integracja dla zespołu i czasami rodzi coś nowego i kreatywnego.
Kim chcesz zostać kiedy dorośniesz?
Zapytaj kim chcą zostać członkowie Twojego zespołu. Może potrzebują pomocy w wyznaczaniu sobie celów? Może nie rozrysowali sobie jeszcze mapy rozwoju? Czy po tym, jak już wiesz jakie mają potrzeby – wysyłasz ich na szkolenia, konferencje ? Podrzucasz fajne materiały edukacyjne? Wspierasz ich rozwój poza godzinami pracy? Inspirujesz ich, żeby pracowali nad własnymi, małymi projektami?
Wspinając się na wyższe stopnie w tej szczególnej piramidzie razem ze swoimi podopiecznymi będziesz w stanie zbudować zespół, który nie tylko zostanie przy Tobie, ale ma szanse stworzyć coś większego!
Ten wpis to mała esencja wystąpienia Jeffa Casimira (@j3 https://twitter.com/j3) z Ruby Conf 2013. Całość do obejrzenia tutaj: