Co oznacza inżynieria 10X dla technicznych kierowników programów?

Galen Low: Od technicznych kierowników programów zazwyczaj nie oczekuje się pisania kodu, ale obecnie nie robią tego również inżynierowie oprogramowania — przynajmniej nie ręcznie. Pytanie nie brzmi więc koniecznie, czy techniczni kierownicy programów powinni umieć programować. Pytanie brzmi: jaki poziom zrozumienia jest potrzebny technicznym kierownikom programów, aby mogli zmienić sposób, w jaki tworzą wartość w świecie, w którym otaczające ich zespoły wykorzystują sztuczną inteligencję do pracy pięć, dziesięć, a czasem nawet pięćdziesiąt razy szybszej niż jeszcze kilka lat temu?

Aby przyjrzeć się temu, jak rola technicznego kierownika programu ewoluuje we współczesnej branży oprogramowania, zaprosiłem wiceprezesa ds. dostarczania i operacji inżynieryjnych, który prowadził zespoły technicznych kierowników programów w organizacjach takich jak Dell i Google, a także w innych szybko rozwijających się środowiskach związanych z oprogramowaniem. Wspólnie omówimy wszystko — od umiejętności, których obecnie wymaga się od technicznych kierowników programów, po sposoby, w jakie szefowie działów dostarczania mogą bronić wartości swoich zespołów w obliczu zmian na stanowiskach kierowniczych.

Porozmawiamy również o tym, jak osoby rekrutujące mogą oceniać kandydatów na stanowisko technicznego kierownika programu podczas procesu rekrutacyjnego oraz jaki byłby wpływ sytuacji, w której rola technicznego kierownika programu zniknęłaby niczym dodo. Mam nadzieję, że spodoba wam się ten odcinek.

Witamy w podcaście Digital Project Manager — programie, który pomaga liderom odpowiedzialnym za dostarczanie pracować mądrzej, sprawniej realizować projekty i pewnie prowadzić zespoły w epoce sztucznej inteligencji. Mam na imię Galen i co tydzień zagłębiamy się w strategie z prawdziwego świata, nowe trendy, sprawdzone ramy działania oraz od czasu do czasu w opowieści z pierwszej linii projektowej. Niezależnie od tego, czy kierujesz ogromnymi projektami transformacyjnymi, zarządzasz przepływami pracy opartymi na sztucznej inteligencji, czy po prostu próbujesz utrzymać chaos pod kontrolą — jesteś we właściwym miejscu.

A jeśli podoba wam się to, czego ostatnio słuchacie, rozważcie obserwowanie nas w miejscu, w którym nas znaleźliście, a może także wystawienie nam opinii. Dobrze, przejdźmy do odcinka.

Moim dzisiejszym gościem jest Satish Menon — lider ds. technicznego zarządzania programami i operacji inżynieryjnych, który kierował dostarczaniem produktów w gigantach technologicznych, takich jak Google i Dell, a także w firmach programistycznych, między innymi Tenable, Cohesity i Seismic.

Programy znajdujące się w zakresie odpowiedzialności Satisha obejmowały zarówno premiery sprzętu i oprogramowania, jak i infrastrukturę chmurową oraz produkty optymalizujące centra danych. Wykorzystywały jego umiejętność poruszania się po decyzjach podejmowanych przez kadrę kierowniczą, zapewniania przywództwa organizacyjnego, opracowywania i wdrażania strategii operacyjnych, transformowania procesów oraz doradzania w zakresie rozwoju produktów.

Obecnie Satish pomaga zespołom technicznych kierowników programów poruszać się po świecie inżynierii oprogramowania i zarządzania programami wspieranych przez sztuczną inteligencję, jednocześnie promując wartość, jaką rola technicznego kierownika programu wnosi do organizacji kierujących się technologią.

Satish, bardzo dziękuję, że do mnie dołączyłeś.

Satish Menon: Cześć, Galen. Dziękuję za zaproszenie. Cieszę się, że tu jestem.

Galen Low: Oto krótki plan, który przygotowałem na dziś. Najpierw chciałem zadać ci nieco kontrowersyjne pytanie, na które moi słuchacze z pewnością chcieliby poznać twoją odpowiedź. Następnie chciałbym wykorzystać je jako punkt wyjścia do omówienia trzech kwestii.

Po pierwsze, chciałem przyjrzeć się temu, jak zmienia się rola technicznego kierownika programu, szczególnie w obszarze oprogramowania. Moglibyśmy porozmawiać o tym, jak szefowie działów i liderzy zespołów mogą bronić wartości swoich technicznych kierowników programów. Chciałem również zagłębić się w konsekwencje hybrydyzacji ról menedżerów zespołów programistycznych i technicznych kierowników programów.

Jak ci się to podoba?

Satish Menon: Świetnie. Nie mogę się doczekać.

Galen Low: Doskonale. Zaczynajmy. Oto moje prowokacyjne pytanie na początek. Techniczni kierownicy programów mówią, że nie muszą umieć programować, aby dostarczać wartość. Tymczasem wielu menedżerów technologicznych wydaje się nie zgadzać. Twierdzą, że sztuczna inteligencja sprawia, iż menedżer zespołu inżynierii oprogramowania i techniczny kierownik programu są teraz jedną i tą samą osobą.

Kto ma więc rację? Czy sztuczna inteligencja stworzyła warunki, w których organizacje mogą rozsądnie oczekiwać, że menedżerowie zespołów programistycznych będą jednocześnie technicznymi kierownikami programów — i odwrotnie?

Satish Menon: Możemy się zgodzić, że rola inżyniera oprogramowania w ostatnim czasie bardzo się zmieniła, prawda?

Przeszli oni od samodzielnego pisania kodu, co wcześniej stanowiło wąskie gardło, do wykorzystywania programowania intuicyjnego i narzędzi sztucznej inteligencji, które pozwalają generować kod dziesięć, a nawet sto razy szybciej. Problem przesunął się teraz do cyklu przeglądu, na przykład przeglądu żądań scalenia. Rozmiar tych żądań się zwiększył. W związku z tym ciężar ludzkiego nadzoru nad tym, co sztuczna inteligencja generuje w oprogramowaniu, przesunął się właśnie tam.

Podobnie jak obserwujemy zmianę w przepływie pracy inżynierii oprogramowania, jego szybkości i zakresie obowiązków inżynierów oprogramowania, podobna adaptacja musi nastąpić po stronie technicznych kierowników programów. Jeszcze trzy do pięciu lat temu dużym obciążeniem było ustalenie planu, a następnie zebranie informacji o jego realizacji: jaki jest status, jak układają się zależności, jakie występują ryzyka i jak je ograniczyć, jak radzi sobie zapewnianie jakości oraz czy jakość naszego projektu jest na właściwym poziomie.

Techniczni kierownicy programów zajmowali się tym w dużej mierze ręcznie lub częściowo ręcznie. Później zaczęliśmy przekształcać ten proces za pomocą Jiry i Atlassiana. Po skonfigurowaniu planu status zaczął pojawiać się automatycznie, a techniczni kierownicy programów mogli przeglądać pulpity, oceniać, co jest oznaczone na czerwono lub żółto, i angażować się w rozwiązywanie problemów.

Rola zmieniła się więc z „tworzę plan, ale także zbieram informacje o statusie, przygotowuję raporty i ułatwiam ograniczanie ryzyka” na „obserwuję aktywne pulpity pokazujące status, a gdy widzę czerwone i żółte sygnały, koordynuję zorientowane na rozwiązania działania mające na celu rozwiązywanie problemów”.

Teraz, dzięki sztucznej inteligencji, pojawiło się jeszcze więcej możliwości dla technicznych kierowników programów. Jeśli spojrzymy na używane dziś narzędzia, mamy z jednej strony Jirę, a z drugiej GitHub, w którym powstaje kod. Następnie mamy BrowserStack, gdzie zarządza się jakością i wdrażaniem.

Jeżeli można zestawić informacje z tych trzech różnych narzędzi lub innych wykorzystywanych systemów, otrzymujemy bogatsze pulpity, dane i analizy ryzyka oraz problemów. Rola technicznego kierownika programu ewoluuje właśnie w ten sposób. Nie musimy już ręcznie wyszukiwać czerwonych i żółtych sygnałów. Możemy wykorzystać sztuczną inteligencję do zestawiania informacji z wielu narzędzi, właściwych sygnałów i właściwych obszarów analizy, aby znacznie lepiej niż kiedykolwiek wcześniej ustalać, gdzie występują problemy.

Galen Low: Bardzo mi się to podoba. Szczególnie podoba mi się ujęcie, w którym wąskie gardło się przesuwa, ale w rzeczywistości są to dwa różne wąskie gardła.

Po stronie inżynierii programiści spędzają mniej czasu na ręcznym pisaniu kodu. Pracują z narzędziami takimi jak Cursor, mogą działać szybciej, a wąskie gardło przesuwa się do etapu przeglądu. Gdy mówisz o menedżerze zespołu inżynieryjnego, oznacza to dla niego więcej przeglądów, prawda?

Wąskie gardło się przesuwa. Prawdopodobnie jest więcej przeglądów i więcej kodu do nadzorowania, a wartość dostarczana przez menedżera polega na utrzymywaniu płynności procesu i szybkim rozwiązywaniu problemów po stronie kodu. Nie oznacza to jednak, że pojawia się dodatkowa zdolność do zajęcia się technicznym zarządzaniem programami.

Po drugiej stronie wąskie gardło dotyczyło wcześniej gromadzenia informacji i aktualizacji statusu. Teraz nasza rola również się zmienia. Korzystamy z innych narzędzi, takich jak Jira, wykorzystujemy sztuczną inteligencję, a część automatyzacji przybliża nas do rozwiązywania problemów, zamiast zmuszać nas do bezczynnego oczekiwania i nagle zapewniać nam czas na nadzorowanie zespołu inżynierii oprogramowania.

Podoba mi się to ujęcie. Zmiana zachodzi po obu stronach, ale nie oznacza to, że wszystko staje się jedną rolą. To dwie odrębne kwestie.

Satish Menon: Jest jeszcze jeden aspekt. Menedżer lub dyrektor inżynierii oprogramowania odpowiada za dostarczanie przez swoje zespoły wysokiej jakości, bezpiecznego i dostępnego kodu o odpowiedniej wydajności, przy zachowaniu dobrego tempa pracy.

Jeżeli oczekujesz od nich również odpowiedzialności za międzyfunkcyjne elementy dostarczania — zależności od innych zespołów programistycznych, zapewnienie odpowiedniego poziomu pokrycia kodu i testów, testy wydajnościowe, testy integracyjne oraz terminowe dostarczenie produktu klientom — nakładasz na nich dodatkowe obciążenie.

Wszystkie te międzyfunkcyjne aspekty musi obsługiwać jakaś osoba. Uważam, że techniczni kierownicy programów, wspierani przez te narzędzia, mogą robić to znacznie sprawniej i szybciej, ale ta praca nadal musi zostać wykonana.

Można posłużyć się analogią do bezpieczeństwa drogowego. Mamy urząd, który wydaje prawa jazdy, rejestruje samochody i dba o znajomość przepisów ruchu drogowego. Mamy jednak również patrol drogowy, który wystawia mandaty i upewnia się, że osoby łamiące zasady są karane dzięki losowym lub systematycznym kontrolom. Dobry system potrzebuje obu tych elementów. Potrzebne są mechanizmy kontroli i równowagi.

Galen Low: Bardzo mi się to podoba, ponieważ obecnie wiele ról podlega automatyzacji, szczególnie techniczne zarządzanie programami i inżynieria oprogramowania. Czasami słyszę, jak ludzie mówią o automatyzowaniu pracy za pomocą ram działania, w których wszystkie zasady są jasno określone, a ludzie mają ich po prostu przestrzegać.

Jednak, jak zauważyłeś, nie jest to coś, w czym ludzie są dobrzy. Zawsze znajdą się osoby, które napotykają problemy, celowo obchodzą zasady albo nie rozumieją priorytetów. Zasadniczo potrzebna jest osoba, która również poprowadzi ten proces.

Może w mniejszym stopniu niż wcześniej, ale nadal ma to wartość. Wiele elementów musi połączyć się w całość, aby dostarczyć produkt programistyczny. Jakość kodu to tylko część zadania. Reszta polega na międzyfunkcyjnej koordynacji, która zapewnia, że wszystko zostanie połączone we właściwym czasie.

Jeśli jesteś rozproszony zarządzaniem zespołem inżynierów oprogramowania — prowadzisz z nimi rozmowy indywidualne, jesteś ich menedżerem kariery, kontrolujesz jakość kodu i pomagasz rozwiązywać problemy techniczne — to jest to ważne zadanie. Gdyby przeszkadzało ono w dostarczaniu, bardzo trudno byłoby ustalać priorytety między tymi dwoma obszarami.

Satish Menon: Właśnie dlatego techniczni kierownicy programów nadal są potrzebni. Ich wartość polega na koordynowaniu zależności, ryzyka i dostarczania między zespołami oraz funkcjami. Nie chodzi o zastępowanie inżynierów, lecz o zapewnienie, że całość zostanie dostarczona.

Galen Low: Rozmawialiśmy o tym, jak zmienia się rola, jak sztuczna inteligencja przyspiesza pracę oraz jak techniczni kierownicy programów mogą dostarczać wartość poprzez wcześniejsze wykrywanie ryzyka, koordynację i głębsze rozumienie produktów.

Satish Menon: Techniczni kierownicy programów muszą przestać tworzyć ręczne raporty i ręcznie zbierać informacje o statusie. Powinni korzystać z aktywnych, zautomatyzowanych pulpitów, zestawiać dane z wielu narzędzi i analizować wczesne sygnały ryzyka.

Jeśli Jira wskazuje, że coś jest bliskie ukończenia, ale informacje z GitHuba lub innych narzędzi pokazują coś innego, jest to sygnał ostrzegawczy. Dzięki takiemu zestawianiu danych można wcześniej wykryć ryzyko, zanim będzie za późno.

Techniczni kierownicy programów muszą rozwijać się wraz z inżynierami oprogramowania. Obie funkcje powinny współpracować, aby szybciej i lepiej dostarczać wartość.

Galen Low: Podoba mi się myśl, że głębsze zrozumienie ostatecznie tworzy większą wartość. Jeśli wiesz, że inny zespół ma odpowiednie kompetencje, jest dostępny i może pomóc, możesz przedstawić rozwiązanie zamiast po prostu powiedzieć: „To wasz problem. Rozwiążcie go do piątku”. Możesz podejść do tego współpracująco i szybciej dotrzeć do rozwiązania.

Satish Menon: Właśnie to buduje szacunek. Jeśli masz wystarczającą wiedzę, aby zaproponować częściowe rozwiązanie, na przykład dotyczące przydziału zasobów, możesz powiedzieć: „Oto mój pomysł, ale to wy jesteście właścicielami tego problemu. Wykorzystajcie go, jeśli będzie pomocny”. Wtedy ludzie doceniają, że przychodzisz z sugestiami, zamiast jedynie przekazywać im odpowiedzialność.

Galen Low: Bardzo podoba mi się określenie „rozwiązania na poziomie 70%”. Nie muszą być ostateczne, ale powinny stanowić punkt wyjścia.

Satish Menon: Techniczny kierownik programu nie musi sam tworzyć prototypów ani pisać kodu intuicyjnego na potrzeby demonstracji dla klientów. Jego zadaniem jest nadzorowanie procesu, koordynowanie działań, zapewnienie dobrych demonstracji dla klientów i zebranie kolejnych wymagań.

Galen Low: Wszyscy pracują szybciej, ale współpraca nadal jest bardzo cenna. Nie chodzi o to, że silosy nie są już potrzebne, ponieważ zespoły stały się wydajniejsze. Przeciwnie — potrzebujemy większej spójności i współdziałania.

Satish Menon: Wartość technicznych kierowników programów jest największa na styku wielu funkcji, zespołów, dyscyplin i organizacji. Powinni myśleć o coraz większych problemach międzyfunkcyjnych, które trzeba rozwiązać, oraz wykorzystywać narzędzia sztucznej inteligencji do zwiększania skali i jakości swojej pracy.

Galen Low: Bardzo dziękuję za poświęcony czas, Satish. To była świetna rozmowa. Osoby, którym podoba się to, co mówisz — gdzie mogą dowiedzieć się o tobie więcej?

Satish Menon: Wystarczy znaleźć mnie na LinkedInie.

Galen Low: Jeszcze raz bardzo dziękuję.

Satish Menon: Bardzo podobała mi się nasza rozmowa, Galen. Dziękuję za zaproszenie.

Galen Low: Dobrze, to wszystko w tym odcinku podcastu Digital Project Manager. Jeśli podobała wam się ta rozmowa, zasubskrybujcie nas w miejscu, w którym słuchacie podcastów. A jeśli chcecie uzyskać jeszcze więcej praktycznych wskazówek, studiów przypadków i przewodników, utwórzcie bezpłatne konto na stronie thedigitalprojectmanager.com.

Do usłyszenia następnym razem. Dziękuję za słuchanie.