Przez ostatnie półtora roku byłem kierownikiem technicznym złożonego wielozespołowego projektu z innym współpracownikiem. Typowe dni wahają się od spokojnej żeglugi do absolutnego chaosu, z wieloma pożarami palącymi się jednocześnie. Poniżej znajduje się kilka lekcji, których się nauczyłem i kilka wskazówek, które utrzymywały mnie przy zdrowych zmysłach i pomogły nam dostarczyć je na czas.

Architektura i kod będą niedoskonałe

Jedną z moich zmagań było utknięcie w myśleniu o tym, jak mogę ulepszyć naszą bazę kodu i architekturę aplikacji. Jako programista jestem dumny z kunsztu i jakości oprogramowania. Stale mierzyłem jakość pracy w stosunku do mojego standardu i zapomniałem, że ocena pochodzi z lat doświadczenia w projektowaniu i rozwoju. Wnioski, które naturalnie pojawiają się wraz z doświadczeniem, nie zawsze są intuicyjne dla zespołu młodych programistów. W rezultacie straciłem z oczu niezwykłe ulepszenia, jakie wprowadzał mój zespół.

Zmieniają się wymagania i priorytety. Dzisiejsza „doskonała” architektura i kod mogą nie mieć zastosowania w przyszłym tygodniu. Te artefakty są środkiem do osiągnięcia celów organizacyjnych, więc powinny być ewoluowalne. Dopóki zachowują pewną modułowość i są w większości luźno powiązane i nadają się do wielokrotnego użytku, nie ma problemu, jeśli rozwiązania nie mają dokładnego kształtu, który chcemy dostarczyć. Zamiast koncentrować się na jakości w mniej krytycznych obszarach, bardziej skalowalne jest kierowanie zespołem i ufanie mu, że wymyśli, jak to zrobić.

Jako indywidualny współpracownik nie mam oficjalnego upoważnienia do zarządzania, ale nadal jestem odpowiedzialny za wyniki pracy ludzi, z którymi współpracuję, oraz pomyślną realizację projektu. Tymczasem moja osobista wydajność, mierzona połączonymi żądaniami ściągnięcia, była najniższa, odkąd zostałem programistą. Zajęło mi trochę czasu, zanim zdałem sobie sprawę, że powiedzenie: „Masz to. Oto potrzebne zasoby i informacje. Będę tutaj, jeśli będziesz potrzebować pomocy”. umożliwia innym naukę i podejmowanie działań. Kiedy sprawy w końcu zaczynają iść we właściwym kierunku, zgodnie z naszą wizją techniczną, jest to trochę krzepiące.

Autonomia jest zaletą, ale nadmierne zaangażowanie już nie

Powierzenie mi tworzenia moich magicznych zaległości w pracy w oparciu o aktualne priorytety produktowe jest satysfakcjonujące. Ale wiedza o tym, co ma wpływ, i wybranie odpowiedniego zakresu i szczegółowości, na których należy się skupić, jest trudne.

Mój archetyp w obecnym zespole, z którym pracuję, to mieszanka lidera technicznego, architekta i rozwiązującego. Zespół projektowy składa się z dwóch zespołów zajmujących się pizzą, z których oba nie znają stosu technologii . Niektórzy członkowie byli nowi w organizacji. Starszy system członkostwa, który modernizujemy, zarządza podstawową częścią działalności AMA. Wiele aplikacji obejmujących wiele domen w obrębie działu integruje się z nim na potrzeby określonych operacji biznesowych.

Z tak skomplikowaną przestrzenią problemową codziennie jestem ciągnięty w milionach kierunków. Wszystko ma swój koszt alternatywny — poświęcenie czasu na przygotowanie propozycji poprawy niezawodności i skalowalności naszej architektury oprogramowania zabiera czas na przeglądy PR i odblokowanie zespołu. Ale gdybym stał się nadgorliwy w kierowaniu technicznym i pilnowaniu dostępu, mój zespół straciłby cenne doświadczenia edukacyjne.

Czasami jest to walka, aby zdecydować, kiedy wejść lub pozostać nad wodą.

Jako doświadczony współpracownik indywidualny jestem świadomy nieoptymalnych rzeczy wokół mnie: architektur, których nie można skalować, procesów szkodliwych dla zdrowia zespołu, możliwości wypróbowania czegoś nowego itp. Jednak robienie wszystkiego nie jest zrównoważone. Ukłon w stronę mojego przełożonego za przypomnienie mi, że mój czas jest cenny — dla mojego zdrowia zdziała cuda, jeśli deleguję zadania, gdy jest to właściwe, i skupiam się na rzeczach, nad którymi mam wyjątkową pozycję do pracy. Delegowanie jest trudne, ponieważ rozwiązywanie problemów było moim domyślnym narzędziem. Jest to więc jeden z moich celów zawodowych na ten rok.

Wyzwania techniczne nie są jedynym problemem

Moje lata konsultingowe dobrze nauczyły mnie jednej koncepcji: nic nie jest zawsze tylko projektem informatycznym. Konsultanci często noszą wiele czapek, aby pomóc klientom odnieść sukces, a bycie liderem technicznym wzmacnia to pojęcie. W przeciwieństwie do koncertów konsultingowych, projekty czy inicjatywy nie „kończą się”. Zawsze jest więcej prac konserwacyjnych, większy kontekst do przyswojenia i jeszcze trudniejszy teren do nawigacji.

Pisanie kodu i tworzenie genialnych rozwiązań to tylko część historii sukcesu długotrwałego, interdyscyplinarnego projektu.

Dodatkowe obawy obejmują zapewnienie, że historie użytkowników mają odpowiedni poziom szczegółowości technicznej, wyjaśnienie, w jaki sposób pewne decyzje architektoniczne pasują do ogólnej wizji, przekonanie innych grup o konkurencyjnych celach do naszych priorytetów lub współpraca z kierownikami zespołów w celu zidentyfikowania niezbędnych procesów i zmian kulturowych.

Niestety, w przeciwieństwie do debugowania, uzyskanie informacji zwrotnej na temat tego, czy moja praca przynosi jakiekolwiek efekty, może zająć tygodnie lub miesiące. Niemniej jednak za efekt końcowy odpowiadam jako lider techniczny. Oznacza to, że muszę rozważyć cały problem i wykonać inne zadania, które popchną sprawy do przodu, ale upadną, jeśli nikt nie zwróci na nie uwagi.

Końcowe przemyślenia

Moja droga do zostania liderem technicznym była pełna ekscytujących wyzwań i jestem błogosławiony, że mam wspaniały system wsparcia liderów i współpracowników w pracy. Poza tym obserwowanie, jak zespół rozkwita i jest doceniany za osiąganie ważnych kamieni milowych, jest niesamowicie podnoszące na duchu, ponieważ pokazuje, że moja wytrwałość i siwe włosy na mojej głowie naprawdę się opłaciły.

Winnie Ho jest starszym programistą w Alberta Motor Association , który ma nienasyconą chęć uczenia się, czytania i pisania o wszystkich rzeczach AWS i sieci.