Kim jest kierownik projektu technicznego?

Kim jest kierownik projektu technicznego (TPM)? Odpowiedź zależy od tego, kogo zapytasz, mówi Andi Blackwell, doświadczony konsultant IT i ekspert ds. operacji biznesowych. Jako główny dyrektor ds. zarządzania projektami i produktami w Toptal, Blackwell kieruje zespołem odpowiedzialnym za łączenie wysoko wykwalifikowanych kierowników projektów w sieci freelancerów Toptal z organizacjami poszukującymi najlepszych talentów do konkretnych inicjatyw. W ostatnich latach obserwuje wzrost popytu na moduły TPM.

„Zdecydowanie w branży technologicznej toczy się debata na temat tego, co właściwie oznacza ten termin”, mówi Blackwell. „Jest wiele osób, które nazywają się technicznymi kierownikami projektów, ponieważ bardzo blisko współpracowały z zespołem inżynierów lub kierowały zespołem technicznym z perspektywy zarządzania projektami, ale nie tego szukamy”.

Definicja Toptala jest bardziej szczegółowa. Wszyscy kierownicy projektów w sieci Toptal są ekspertami w zakresie tradycyjnych umiejętności zarządzania projektami, takich jak ustalanie zakresu, budżetowanie i zarządzanie terminami, a także zwinnych praktyk rozwoju oprogramowania związanych z iteracyjnym dostarczaniem i ciągłym doskonaleniem. Niezmiennie ściśle współpracowali z inżynierami i mogli, gdyby zostali wezwani, trenować i prowadzić zespół Scrumowy.

Aby jednak kwalifikować się jako moduły TPM, muszą mieć dodatkową warstwę doświadczenia poza zarządzaniem procesami Agile i współpracą z programistami: sami muszą być programistami.

Nagrodzone połączenie

Organizacje duże i małe są coraz bardziej zainteresowane tą konkretną kombinacją umiejętności. „Większość startupów nie może zatrudnić osoby, która może zrobić tylko jedną rzecz”, mówi Blackwell, a większe firmy chcą widzieć „dewelopera” lub „architekta” w profilu kandydata, jeśli zatrudniają do projektu inżynierskiego.

Nawet w przypadkach, w których klient nie wymaga specjalnie kierownika projektu z zapleczem technicznym, zaznaczenie pola „deweloper” jest ważnym punktem sprzedaży. Ktoś, kto potrafi zaplanować i wykonać projekt oprogramowania, wdrożyć i zoptymalizować procesy Agile oraz kodować? To ogromne dobrodziejstwo.

W rzeczywistości jednak nie oczekuje się, że moduły TPM będą kodować — wiele z nich nie kodowało od lat. Skąd zatem potrzeba doświadczenia programistycznego?

Moduły TPM są wymagane do podejmowania decyzji technicznych, mówi Blackwell: „Jeśli nie masz przynajmniej stosunkowo niedawnego praktycznego doświadczenia z nowoczesnym stosem technologicznym, SDK (zestawem programistycznym), architekturą lub platformą automatyzacji testów, to znaczy, że” potencjalnie nie podejmiesz właściwych decyzji. Nie będziesz wiarygodny u klienta, ponieważ wcześniej nie używałeś tych rzeczy.”

Praca z zespołami

Wykazanie wiarygodności potencjalnemu klientowi jest istotnym czynnikiem w zabezpieczaniu zaangażowania, ale to tylko pierwsza przeszkoda. Po przypisaniu do projektu, TPM musi szybko zdobyć zaufanie i szacunek zespołu technicznego.

Michael Poythress zaczął programować jako nastolatek. W wieku 16 lat zbudował komercyjną stronę internetową dla firmy zajmującej się reklamą nieruchomości, którą założył ze swoim tatą. Od tego czasu jest prezesem i założycielem wielu startupów. W 2018 roku dołączył do sieci Toptal jako TPM i obecnie ściśle współpracuje z zespołami inżynierskimi. „Gdybym nie miał doświadczenia z kodowaniem, programiści by to zauważyli”, mówi. „Nie strzelaliby ze mną prosto. Ale jeśli rzucam im wyzwanie i rozmawiam z nimi jak rówieśnik, jest szacunek i porozumienie”.

I to doświadczenie technologiczne liczy się bardziej niż tytuł, mówi Allen Takatsuka, Toptal TPM z siedzibą w Orange County w Kalifornii: „Z tego, co widziałem, „T” w TPM nie ma dla inżynierów żadnego znaczenia. Myślą, że to po prostu kolejny kierownik projektu, który zaaranżuje ich spotkania i poprosi ich o wypełnienie arkuszy kalkulacyjnych”.

Jednak po ustaleniu wspólnej płaszczyzny „smak interakcji jest zupełnie inny. To bardziej partnerstwo z inżynierią”, mówi.

Takatsuka przez dziesięciolecia kierował zespołami inżynierskimi na wcześniejszym etapie swojego życia zawodowego. To doświadczenie przypisuje mu podniesienie swoich umiejętności miękkich. „To trochę inna umiejętność empatii”, mówi. „Musisz pokazać, że potrafisz mówić w języku. Jesteś w stanie powiedzieć: „Widzę, dlaczego masz te wyzwania, w oparciu o rzeczy techniczne, które mają miejsce”.

Dan Allen, konsultant ds. technologii z Wiednia w stanie Wirginia, opisuje swoje postępy w karierze jako „od programisty od faceta w szafce, przez kierownika technicznego do architekta, dyrektora, wiceprezesa, CTO, CIO”. Od czasu dołączenia do sieci Toptal jako TPM w 2019 roku jest zajęty, pracując nad 14 zleceniami dla klientów.

„Rzadko czytam kod. Prawie nigdy nie piszę kodu” – mówi. „Ale zdarzały się sytuacje, w których programista utknął. Mogą przeprowadzić mnie przez architekturę i dokładnie zobaczyć, co próbują zrobić i jaka jest logika”.

Uważa, że ​​dynamika jest użyteczna nie tylko w skrajnych przypadkach, ale szerzej. „Twój zespół wie, że mogą przyjść do ciebie i porozmawiać, a ty naprawdę rozumiesz, co mówią” — mówi. „Możesz pomóc im rozważyć wszystkie zawiłości na wypadek, gdyby coś przeoczyli. Możesz być forum sondażowym i przekazywać informacje zwrotne”.

Efekt mnożnikowy

Tego rodzaju informacje zwrotne i wgląd są ważne nie tylko dla budowania relacji. Moduły TPM oferują organizacji inną propozycję wartości. Służą mniej jako kanały informacyjne, a bardziej jako źródła wiedzy. Tak, planują, koordynują i komunikują się, ale pomagają również klientom i zespołom w podejmowaniu złożonych decyzji technologicznych.

„Potrafisz być technicznie uparty” – mówi Takatsuka. „A to dodaje wartości organizacji, ponieważ teraz masz większy efekt mnożnikowy, a nie tylko organizowanie i współpracę”.

Takatsuka zauważa, że ​​TPM-y muszą przeskakiwać przez mniej obręczy, aby rozwiązywać problemy. Zwłaszcza w większych organizacjach nietechniczny kierownik programu lub kierownik projektu może podejść do wyzwania technicznego, identyfikując odpowiednich graczy i interesariuszy, oferując kontekst, agregując informacje, a następnie przesiewając wyniki w celu podjęcia decyzji. Moduły TPM mogą wykorzystać swoją własną wiedzę.

„Możesz znacznie skuteczniej radzić sobie z ryzykiem”, mówi Oana Ciherean, TPM z Tokio. „A to ryzyko może pochodzić z wielu miejsc. Mogą pochodzić z błędnych szacunków zespołu. Możesz więc powiedzieć: „OK, jestem pewien, że napisanie tego fragmentu kodu nie zajmie tygodnia”, ponieważ tak naprawdę trwa to dwa dni. Więc możesz faktycznie odblokować ludzi. Ponieważ zorientowałeś się, że utknęli i dlatego zajmuje im to pięć dni. Wiesz o tym, ponieważ tam byłeś i sam utknąłeś.

Znalezienie równowagi

Ciherean rozpoczęła karierę jako programista, ale wkrótce przeniosła się do zarządzania projektami z chęci zaangażowania się w szerszy obraz. W tych rolach odkryła jednak, że tęskniła za kodowaniem. Mówi, że Technical Project Management oferuje to, co najlepsze z obu światów: „Pozwala mi być naprawdę praktycznym w technologii, ale także na wysokim poziomie, rozumiejąc biznes i klientów oraz czego chcą w funkcjach”.

Poythress też czuje, że znalazł swoje ulubione miejsce. „Jestem tłumaczem lub łącznikiem między wizjonerami, którzy mają pomysł, a talentem technicznym, który wie, jak go zbudować i zrealizować” – mówi. „Mówię płynnie w obu językach. Mówię „normalna osoba” i „technicznie”.

Mały CTO

TPM-y pracujące dla start-upów i małych firm zajmują szczególnie pierwszorzędną pozycję na styku biznesu i technologii. W przypadku tych zadań TPM jest często pierwszym zatrudnionym, który wchodzi na pokład na początku projektu. Następnie jest odpowiedzialny za ocenę rentowności produktu, zdefiniowanie zakresu technicznego i wymagań oraz pomoc klientowi (czasem pojedynczemu założycielowi z zalążkiem pomysłu) w wyborze stosu technologicznego, ocenie dostawców pod kątem świadczenia usług, wdrażaniu najlepszych praktyk DevOps, i zbierz odpowiedni zespół.

Takatsuka myśli o tych zadaniach jako o rolach „mini CTO”, w których TPM łączy sferę biznesową i techniczną, aby zacząć działać. Niektórzy klienci nie wiedzą prawie nic o tworzeniu oprogramowania, mówi: „Jak założyć sklep? Czytałem o Agile. Jak mogę to zrobić?"

Poythress uważa, że ​​te dwie role nakładają się na siebie, a w niektórych przypadkach są nawet nie do odróżnienia. „Jest dużo zapylenia krzyżowego”, mówi. „CTO w mniejszej organizacji może bardzo łatwo przejść na stanowisko starszego kierownika technicznego w większej organizacji i poczuć się jak w domu”.

Włączanie zwinności

Podczas gdy mechanika Agile znajduje się w sterówce praktycznie każdego kierownika projektu z doświadczeniem w tworzeniu oprogramowania, ktoś z umiejętnościami technicznymi może wnieść bardziej zniuansowaną perspektywę do zarządzania procesami.

Ciherean stwierdza, że ​​metodologie Agile nigdy nie są implementowane wyłącznie w książce; muszą być dostosowywane, łączone i dostosowywane do konkretnych potrzeb zespołu i projektu.

„Musisz upewnić się, że to, co projektujesz jako proces, nie koliduje z pracą programistów i faktycznie czyni ją bardziej wydajną lub produktywną”, mówi. „Czasami oznacza to zagłębienie się w przepływ pracy GitHub, na przykład, aby zobaczyć, jak wykonują swoje zatwierdzenia, zobaczyć, jak tworzą gałęzie dla swojego kodu i sprawdzić, czy twój proces pasuje do ich przepływu pracy. A potem albo poprawiasz swój proces, albo poprawiasz jego przepływ pracy”.

Ekspertyza TPM może również informować o konkretnych artefaktach i praktykach Agile, takich jak backlog produktu i szacunkowe względne rozmiary.

„Jeśli rozumiesz kwestie techniczne, wiesz, jaka jest złożoność zaległości”, mówi Takatsuka. „W przeciwnym razie wszystko, co masz, to ta lista i trudno byłoby ci określić, czy numer jeden to rozmiar koszulki Large w porównaniu z numerem dwa. Możesz sądzić, że jest to trudniejsze, ale tak naprawdę nie wiesz, co jest za kulisami. „Ekstremalny” TPM, jak mówi, „może sam oceniać rzeczy, z zastrzeżeniem, że kiedy zespół wejdzie na pokład, będzie miał własną prędkość”.

Poythress wykorzystuje swoją wiedzę na temat szacowania rozmiaru jako miernika do oceny kierowników technicznych i inżynierów, których bierze pod uwagę do projektu. Jeśli spodziewa się, że coś będzie małym zadaniem, ale ktoś inny uzna to za gigantyczne, jest to czerwona flaga: „Wysłucham ich, aby zobaczyć, czy są jakieś zawiłości, o których nie wiem, ale jeśli to nie wystarcza, Mówię: „Dobrze, to nie jest dobre”. Potrzebujemy kogoś, kto naprawdę dobrze to rozumie i nie przeraża go to, co powinno być prostą funkcją”.

Moduły TPM pomagają również edukować klientów w zakresie wymagań niefunkcjonalnych. Jak radzisz sobie z wysoką dostępnością? Jak radzisz sobie z odzyskiwaniem po awarii? „Bez technicznego zrozumienia nie wiem, jak prowadzisz tę dyskusję”, mówi Takatsuka. „Prawdopodobnie zatrzymasz się na poziomie wymagań Scruma i uznasz to za dzień, dopóki nie pojawią się ludzie techniczni. Cóż, wtedy masz tę ogromną przepaść.

Bieżący prąd

Chociaż ich czas spędzony na klawiaturze odgrywa fundamentalną rolę w tym, co robią dzisiaj, TPM nie może polegać na przeszłym doświadczeniu, aby pozostać aktualnym. Biorąc pod uwagę tempo, w jakim technologia się zmienia i rozwija, łatwo jest zostać w tyle.

Poythress nauczył się tego na własnej skórze podczas pięcioletniego okresu przed dołączeniem do Toptal, kiedy skupiał się wyłącznie na prowadzeniu własnej firmy. „Zdecydowanie popadłem w stagnację” – mówi. „W tym okresie pojawiło się wiele różnych języków i rozwiązało problemy, o których nic nie wiedziałem, ponieważ mieliśmy nasz stos technologiczny i to było wszystko, czego potrzebowaliśmy”.

Dziś spędza do 10 procent czasu na czytaniu dokumentacji, oglądaniu YouTube i piaskownicy, „aby dowiedzieć się o najnowszych i najlepszych rzeczach”.

„Prawie zawsze zajmuję się na boku nowym językiem lub technologią, tylko po to, by zachować czujność” — mówi. „Bo jeśli tego nie zrobię, branża będzie się rozwijać. Zdarzyło mi się to już wcześniej. I o wiele trudniej jest wkuwać niż być na bieżąco”.

Takatsuka jest również aktywny w uzupełnianiu swoich luk w wiedzy: „Obecnie Google jest świetny. YouTube jest niesamowity. Musisz zrobić swoje zadanie domowe. Ale ta praca sama się buduje”.

Opiera się również na szerokiej sieci współpracowników konsultantów w zakresie wsparcia i dzielenia się wiedzą. „Byłem w sytuacjach, w których klient chce korzystać z Google, ale zdarza mi się lepiej poznać platformę AWS”, mówi. „Mogę zadzwonić do znajomych i powiedzieć: „Hej, będziemy korzystać z Firebase. Czy miałeś jakichś klientów, którzy to robią? A co ze skalowalnością?”

Nawet po ponad 30 latach w biznesie i wielu stanowiskach kierowniczych Dan Allen nie boi się ubrudzić sobie rąk. W ciągu ostatnich trzech lat nauczył się samodzielnie wdrażać w Amazon i Google Cloud. „Zrobiłem to, aby móc to zrozumieć i pomóc klientowi Toptal” – mówi. „Nie mieli zespołu technologicznego. Jedyne, co mieli, to ja. Poszedłem więc na Uniwersytet YouTube i udało mi się”.

Tak wiele się zmieniło, odkąd Allen zaczął jako programista w 1985 roku. Ale on lubi wyzwania, które pojawiają się wraz z każdą nową szansą. „To część tego, co kocham w tej pracy”, mówi. „Zawsze jest coś, czego nie zrobiłeś, coś nowego. I zawsze odchodzisz z dodatkowym piórkiem w czapce, które możesz wykorzystać przy następnym zaręczynach.