Standardy i wzorce programowania przyspieszają pracę zespołową i poprawiają jakość kodu. Design system pozwala szybciej i w bardziej powtarzalny sposób budować komponenty i widoki. CI/CD zapewnia puszczanie kluczowych testów oraz powtarzalność deploymentów.
Gdy jednak w roli liderskiej przychodzi nam pracować z ludźmi, trafiamy często na pozbawiony zasad dziki zachód. Skoro standardy i wzorce tak pomagają nam w pracy technicznej, to czy mogą pomóc również w feedbacku i rozwoju członków zespołu?
W Bethink odczuliśmy potrzebę usystematyzowania procesu ewaluacji już kilka lat temu. Znaleźliśmy i wdrożyliśmy framework, który pozwala holistycznie spojrzeć na działania osoby w ramach zespołu i firmy. Pomaga w wyznaczeniu priorytetów i wizualizowaniu postępów. To wszystko przedkłada się na efektywniejszy rozwój i pomaga zarówno liderom, jak i samym specjalistom.
Dziś, po sześciu „sezonach”, możemy podzielić się z Tobą nie tylko samym narzędziem, ale też praktycznymi wnioskami z jego użycia. jeżeli szukasz podobnego rozwiązania, to możesz śmiało skopiować nasz framework i dostosować go do potrzeb oraz kultury Twojego zespołu.
Zdecydowanie łatwiej będzie nam „rozmawiać”, jeżeli zobaczysz nasze narzędzie przed dalszym ciągiem artykułu, więc przejrzyj arkusz, który znajdziesz pod poniższym linkiem.
Otwórz arkusz: Engineering Stages – Framework rozwoju, stosowany w Bethink
Zbuduj holistyczną ścieżkę rozwoju
W Bethink używamy narzędzia, które „sforkowaliśmy” z Engineering Levels w Patreon. Ich podejście do ewaluacji okazało się bardzo spójne z naszym. Zaczęliśmy więc od przetłumaczenia wszystkich punktów na polski, żeby zminimalizować ryzyko nieporozumień, a z czasem wprowadziliśmy sporo modyfikacji i dodatkowych wyjaśnień.
Nasz framework Engineering Stages (nazywany dalej ES) koncentruje się na obserwacji konkretnych działań, podejmowanych przez członków zespołu. Działania te są mapowane do głównych obszarów rozwoju:
- Współpracy i komunikacji.
- Wywierania wpływu na organizację.
- Efektywnego działania.
- Dojrzałości.
- Umiejętności technicznych.
Zwróć uwagę, iż umiejętności techniczne są tylko jednym z pięciu obszarów. To bardzo dobrze odzwierciedla nasze podejście do tego, co czyni dewelopera profesjonalistą i świetnym członkiem zespołu.
Ścieżka rozwoju podzielona jest na sześć etapów, oznaczonych odpowiednio IC1-IC6. Skrót IC pochodzi od Individual Contributor – jest to wersja dla specjalistów, nie menedżerów. Każdy kolejny etap zakłada rozwój we wszystkich głównych obszarach, ale zawiera inny zestaw działań, których oczekujemy.
Dla przykładu, na etapie IC1 w ramach „Współpracy i komunikacji” skupiasz się na umiejętności komunikowania swoich postępów wewnątrz zespołu, na IC2 – komunikowaniu swoich postępów poza zespołem, dostosowując odpowiednio przekaz do odbiorcy, a w ramach IC3 – komunikowania postępów zespołu szerszemu gronu interesariuszy. Dzięki temu, rozwój w ramach kolejnych etapów wymaga utrzymania dobrych nawyków z poprzednich.
Skup się na analizie konkretnych działań
Naturalnie, sam arkusz nie wystarczy do tego, żeby wdrożyć realne zmiany w zespole. Silnikiem rozwoju jest ciągły proces mierzenia etapu rozwoju, ewaluacji postępów oraz planowania i wdrażania zmian.
W Bethink co 6 – 12 miesięcy, w zależności od okoliczności, przeprowadzamy „podsumowanie sezonu”. Uzupełniamy prywatne arkusze dla deva, przypisując do każdego działania częstotliwość, z jaką je postrzegamy:
- Prawie zawsze lub zawsze (działanie wykazywane w co najmniej 90% sytuacji),
- Zwykle tak (60-90% sytuacji),
- Różnie bywa (40-60% sytuacji),
- Zwykle nie (20-40% sytuacji),
- Prawie nigdy (0-20% sytuacji).
Podsumowanie dla wszystkich deva uzupełnia on sam, a niezależnie robi to lider lub liderzy. Dzięki temu unikamy biasowania w jedną lub drugą stronę.
Sama skala ewoluowała na przestrzeni lat. Zaczęliśmy od prostego Tak / Nie / Nie wiem. Taka skala z jednej strony była prostsza w użyciu, ale z drugiej zostawiała mniej wartościową informację zwrotną – trudniej było zaobserwować tendencję.
Rozmawiając, zaczynaj od „dlaczego?”
W trakcie rozmowy na „podsumowanie sezonu” najważniejsze jest zbudowanie odpowiedniej ramy interpretacyjnej. Takie rozmowy, choćby w zdrowym i wspierającym środowisku, są zawsze nieco stresujące. Z natury dotyczą też obszarów, nad którymi pracujemy i czujemy się w nich niepewnie. Dlatego bardzo łatwo o odbieranie feedbacku osobiście i traktowanie go jako ocenę człowieka, a nie jego pracy.
Jednocześnie moim celem w trakcie rozmów jest budowanie motywacji wewnętrznej. W związku z tym chcę unikać interpretacji Engineering Stages tylko jako listy oczekiwań do spełnienia.
Po kilku iteracjach, wypracowałem sformułowanie, które na ten moment dobrze oddaje moje intencje:
„Jeśli chcesz mieć większy wpływ na produkt i działania zespołu, to potrzebujesz robić te i te rzeczy”.
Taka perspektywa skupia nas bardziej na przyszłości oraz możliwościom wpływu, które są konsekwencją rozwoju.
Skup rozmowę na tym, co najistotniejsze
Engineering Stages to obszerny framework. W związku z tym, w trakcie rozmowy trzeba przyjąć strategię, która priorytetyzuje najistotniejsze tematy.
Po pierwsze, nie przechodzimy przez wszystkie etapy dla każdej osoby. jeżeli ktoś jest na etapie IC2 i aspiruje do IC3, to przechodzenie przez IC4-IC6 mija się z celem. Podobnie w drugą stronę – jeżeli ktoś pracuje nad IC5, to przechodzenie przez IC1, IC2 i często IC3 nie ma już sensu. Większość punktów na kolejnych etapach nieuchronnie wymaga realizowania tych z poprzednich etapów.
Jak wspomniałem wcześniej, arkusz dla wszystkich deva jest uzupełniany niezależnie przez jego samego oraz jego lidera/liderów, w osobnym arkuszu. Przed rozmową kopiujemy zawartość z arkusza liderów do indywidualnego arkusza deva. Następnie porównujemy odpowiedzi i ustalamy priorytety dla rozmowy. Wybieramy punkty, które spełniają jedno z trzech kryteriów:
- Nasza ocena punktu różni się o min. dwa poziomy (np. „Niemal zawsze lub zawsze” vs. „Różnie bywa” lub „Zwykle tak” vs. „Zwykle nie”).
- Naszym zdaniem, jako liderów, skupienie się na określonym punkcie będzie miało największy wpływ na rozwój deva.
- W danym obszarze zaobserwowaliśmy stagnację lub regres, względem ostatniego spotkania.
Rozmowa o poszczególnych punktach zależy już od indywidualnej sytuacji. Staramy się natomiast ustalić kilka kluczowych kwestii:
- Jaka jest perspektywa specjalisty, a jaka liderów? W czym się różnią? Czy i jak rozjeżdża się zestaw informacji, na których się opierają?
- Kto i jakie działania może podjąć, żeby na przyszłość uniknąć podobnych rozjazdów?
- Po ustaleniu wspólnej perspektywy, jeżeli uznajemy, iż dane działanie przez cały czas wymaga uwagi – co konkretnie może robić dany specjalista, żeby częściej je realizować?
Wybierz kilka obszarów i regularnie do nich wracaj
Wnioski z rozmowy są spisywane na bieżąco, a na koniec spotkania wybieramy 2 – 4 kluczowych obszarów, na których skupimy się na początku kolejnego „sezonu”. Nie zawsze są to priorytety na cały okres – zachęcamy zespół, żeby starali się „odhaczać” punkty z listy i wybierać kolejne.
Engineering Stages są świetnym narzędziem do budowania „big picture vision”. Każda wielka zmiana składa się jednak z wielu małych zwycięstw. Nad zmianą nawyków pracujemy więc głównie na regularnych spotkaniach 1:1, na których staramy się na bieżąco oceniać postępy i planować nowe działania w krótszej perspektywie.
Dlatego aktualne priorytety z ES dla danej osoby są kopiowane do pliku z notatkami 1:1 i wracamy do nich na każdym spotkaniu. Swoją drogą, dzięki temu unikamy sytuacji, w których na 1:1 „nie ma o czym rozmawiać” – zawsze punktem wyjścia jest ocena poprzedniego tygodnia z perspektywy priorytetów i rozmowa o tym, co możemy w ramach nich zrobić w kolejnym okresie.
Cały „sezon” trwa kilka miesięcy, po tym czasie widzimy się na podsumowaniu i powtarzamy proces.
Po prostu zacznij
Przede wszystkim, pomimo tego, iż dostrzegamy wciąż pole do usprawnień, jako zespół oceniamy wprowadzenie Engineering Stages jednoznacznie pozytywnie. Powtarzalność procesu pozwala nam częściej udzielać kompleksowej informacji zwrotnej oraz wizualnie dostrzegać progress, gdy „czerwone” obszary zmieniają się w „zielone” na koniec kolejnego sezonu. Rozmowy te nie są łatwe, ale myślę, iż odpowiednio poprowadzone budują też spójność zespołu i wzajemne zaufanie. Co więcej, wnioski mają często wpływ nie tylko na działania pojedynczych osób, ale na organizację całego zespołu.
Na koniec mam dla Ciebie jeszcze kilka dodatkowych tipów, które mogą pomóc Ci w skutecznym wdrożeniu Engineering Stages, czy innego frameworka w Twojej organizacji.
Spisuj przykłady na bieżąco
Wykorzystaj też koniecznie spotkania 1:1 do bieżącego spisywania przykładów, które mogą przydać się na „podsumowaniu sezonu”. Gdy jako lider będziesz mieć tylko „wrażenie” odnośnie jakiegoś punktu, bez przykładów, to Twój feedback będzie dużo mniej skuteczny, a wręcz może zostać odrzucony.
Zdecydowanie lepiej włożyć więc kilka minut tygodniowo, żeby zastanowić się nad świeżymi przykładami realizowania oraz nierealizowania działań z ES, zwłaszcza tych priorytetowych dla danego deva.
Co niezaplanowane, to się nie stanie
Nigdy nie ma dobrego momentu na takie rozmowy. Zawsze są pilniejsze zadania i ważne projekty. Czekanie na „dobry moment” sprawia, iż on nigdy nie przychodzi. Jako ludzie, mamy niestety bias krótkowzroczności, który sprawia, iż nie doceniamy wartości długofalowych działań.
Dlatego zaplanuj po prostu rozmowy z wyprzedzeniem, uwzględniając czas na przygotowanie po stronie devów i liderów. Okaże się, iż czas na nie jednak był, a inwestycja w rozwój zespołu zwróci Ci się z nawiązką.
Better done than perfect
„Zawsze lepsze zrobione niż idealne” to jedna z kluczowych idei stojących za manifestem agile i strategią skutecznego działania. choćby najbardziej doskonały system jest wart dokładnie nic, o ile nie jest używany.
Dlatego zacznijcie po prostu używać wybranego frameworka i nie poświęcajcie zbyt dużo czasu w doprowadzanie go od razu do perfekcji. Po każdym sezonie wyciągnijcie wnioski i poprawcie to, co najbardziej Was bolało. Wtedy będziecie wiedzieli, iż odpowiadacie na prawdziwe, a nie hipotetyczne problemy.
Powodzenia!
Jak zwykle w pracy zespołowej, framework jest tylko narzędziem, celem jest rozwój i satysfakcja ludzi. Dobre narzędzia mają jednak to do siebie, iż wyciągają z ludzi potencjał, którego sami się nie spodziewali. Mam nadzieję, iż tak będzie i w Twoim przypadku!
Jeśli będziesz mieć jakieś pytania, uwagi lub po prostu historię wdrożenia do opowiedzenia, daj znać (najlepiej na LinkedIn). Powodzenia!
Adam Karmiński. Co-founder i CTO w Bethink, gdzie rozwija platformę e-learningową, łączącą w jedno doświadczenie podręcznik, kurs, korepetycje i wspólną naukę. Będąc generalistą, pracował jako marketer, programista, designer, project manager oraz product owner. Największą satysfakcję daje mu znajdowanie prostych rozwiązań dla złożonych problemów oraz precyzyjna komunikacja, przy użyciu możliwie niewielu słów.
Zdjęcie główne artykułu pochodzi z envato.com.
