|
Cześć MailingR, tu Jarek 👋
Kiedy zostałem team leadem, byłem ogromnie pewny siebie. W końcu, jako doświadczony inżynier, zjadłem zęby na kodzie, przeżyłem niejeden deploy w piątek i przetrwałem spotkania z klientami.
Myślałem, że jestem gotowy na wszystko. Ha! Gdybym tylko wiedział, że czeka mnie przygoda, która sprawi, że zatęsknię za problemami z kodem.
Oto historia Niewidzialnego Developera.
Wszystko zaczęło się niewinnie. Na horyzoncie pojawił się kandydat z całkiem ładnym CV. Na rozmowie? Cóż, oczarował nas - elokwentny, pewny siebie, z solidną wiedzą techniczną i architektoniczną.
"To będzie skała na której zbuduję zespół mobile!” - pomyślałem, dając rekomendację, żeby złożyć mu ofertę na seniora.
(No dobra, nie pomyślałem DOKŁADNIE tych słów, ale ładnie brzmią tutaj)
Świetnie. W pierwszych kilku tygodniach wszystko było tak jak należy. Na daily mówił jaki progres robi w poznawaniu naszego codebase’u i wdrażaniu się, kiwał głową w odpowiednich momentach ... No nikt nie oczekiwał, że od pierwszego dnia zacznie dostarczać najbardziej skomplikowane taski.
I nagle nasz Nowy Cudowny Członek Zespołu zaczął… znikać. Najpierw opuścił jedno spotkanie. Potem drugie. Ale gdy trzecie daily minęło bez jego obecności, zacząłem się zastanawiać, co może być nie tak.
Wymijające odpowiedzi – “problemy z internetem”, “odwożę dzieci do szkoły”.
A jeśli chodzi o status update, to zamiast konkretów, zaczęły spływać tajemnicze wiadomości: “Refaktoryzuję kod”, “Optymalizuję CI”.
Brzmiało spoko, ale coraz bardziej przypominało mi to opowieści mojego nauczyciela WF o tym, jak to on “prawie” pojechał na Igrzyska Olimpijskie.
Sytuacja wymykała się spod kontroli. Nasz Nowy Cudowny Członek Zespołu stał się mistrzem wymówek i znikania. Na Slacku pojawiał się sporadycznie, a jego commity może i były rzadkie, za to małe i nieszczególnie przydatne.
“Gdzie jest moduł, nad którym miałeś pracować?” - pytałem. “A, przepisuję to z RxJavy na Coroutines” - odpowiadał nonszalancko.
Ten refaktoryzowany kod istniał podobno gdzieś na jego lokalnych branchach, ale nikt go nie widział. Czułem się, jakbym gonił cień. Z każdym dniem rosło moje podejrzenie, że zatrudniliśmy jakiegoś szarlatana.
I tak minęło kilka tygodni. Ja, jako świeżo upieczony team lead, bałem się interweniować.
W końcu to doświadczony developer, pewnie wie, co robi - uspokajałem sam siebie. Może tak właśnie pracują seniorzy, a mnie coś ominęło?
Przepisują, optymalizują, refaktoryzują…
Udawałem, że rozumiem te wszystkie mglistne wyjaśnienia.
Aż nadszedł dzień sądu - mieliśmy zaprezentować demo do klienta. Nagle okazało się, że nasz projekt to istny powtór, a my jesteśmy dr Frankensteinami. Projekt pół stary, pół nowy i całkowicie niefunkcjonalny.
Panika? To mało powiedziane.
W tym momencie dotarło do mnie, że bycie team leadem to nie tylko zatwierdzanie urlopów. To także umiejętność odróżniania realnego postępu od „widocznego zapierdolu”.
Ledwo skleciliśmy działające demo.
Zawiodłem po całości. Dałem przyzwolenie na pracę w izolacji. Patrząc na naszą ledwo działającą aplikację, obiecałem sobie zmianę.
Nigdy więcej nie założę, że rockstar developer pracujący solo działa w najlepszym interesie zespołu.
Nigdy więcej nie zaakceptuję niejasnych update’ów bez drążenia tematu.
Nigdy więcej nie zignoruję sygnałów ostrzegawczych od reszty zespołu.
Ta sytuacja nauczyła mnie, że muszę stworzyć środowisko, gdzie transparentność jest normą. Regularne code review, częstsze check-iny i otwarta komunikacja muszą stać się nowym standardem.
Bo prawda jest taka, że ustalanie jasnych oczekiwań i wymaganie przejrzystości to nie jest micromanagment. A cholernie bałem się, że zostanę tym wkurzającym micromanagerem.
Sukces projektu nie zależy od umiejętności jednego developera, ale od efektywnej pracy całego zespołu.
Software engineering to sport zespołowy.
Gdybym teraz miał dać radę komuś, kto właśnie obejmuje stanowisko liderskie, powiedziałbym tak:
1. Nie bój się pytać. Regularne, konkretne pytania o postępy to podstawa.
2. Ufaj, ale weryfikuj. Zaufanie jest ważne, ale równie istotna jest regularna kontrola faktów.
3. Promuj transparentność. Stwórz środowisko, gdzie dzielenie się problemami jest normą.
4. Twoja dostępność i zaangażowanie mają kluczowe znaczenie dla zespołu.
5. Nie ignoruj sygnałów ostrzegawczych, działaj zanim problem urośnie.
6. Pamiętaj, że komunikacja to klucz. Jasne oczekiwania i regularna wymiana informacji to nie mikromanagement, to dobra praktyka.
7. Ucz się na błędach
- swoich i innych. Każde potknięcie to szansa na usprawnienie procesów.
8. Rozwijaj się wraz z zespołem i nie bój się przyznać, gdy czegoś nie wiesz.
|
