Mitä 10X-teknologia tarkoittaa teknisille ohjelmapäälliköille?

Galen Low: Teknisten ohjelmapäälliköiden ei yleensä odoteta kirjoittavan koodia, mutta nykyään ohjelmistoinsinöörienkään ei odoteta tekevän sitä käsin. Kysymys ei siis välttämättä ole siitä, pitäisikö teknisten ohjelmapäälliköiden osata koodata. Kysymys kuuluu: kuinka syvällistä ymmärrystä tarvitaan, jotta tekniset ohjelmapäälliköt voivat muuttaa tapaa, jolla he tuottavat arvoa maailmassa, jossa heidän ympärillään olevat tiimit käyttävät tekoälyä toimiakseen viisi, kymmenen tai joskus jopa 50 kertaa nopeammin kuin vain muutama vuosi sitten?

Selvittääkseni, miten teknisen ohjelmapäällikön rooli kehittyy tämän päivän ohjelmistoteollisuudessa, olen kutsunut vieraakseni toimituksesta ja teknisistä toiminnoista vastaavan varajohtajan, joka on johtanut teknisten ohjelmapäälliköiden tiimejä Dellin ja Googlen kaltaisissa organisaatioissa sekä muissa nopeatahtisissa ja nopeasti kasvavissa ohjelmistoympäristöissä. Keskustelemme kaikesta siitä, millaisia taitoja teknisiltä ohjelmapäälliköiltä nykyään vaaditaan, siihen, miten toimitusjohtajat voivat puolustaa tiiminsä tuottamaa arvoa johtajuuden vaihtuessa.

Puhumme myös siitä, miten rekrytoivat esihenkilöt voivat arvioida teknisten ohjelmapäälliköiden ehdokkaita rekrytointiprosessin aikana ja mitä vaikutuksia olisi sillä, jos teknisen ohjelmapäällikön rooli katoaisi sukupuuttoon kuolleen dodon tavoin. Toivottavasti nautit jaksosta.

Tervetuloa Digital Project Manager -podcastiin – ohjelmaan, joka auttaa toimitusjohtajia työskentelemään fiksummin, toimittamaan sujuvammin ja johtamaan tiimejään luottavaisin mielin tekoälyn aikakaudella. Olen Galen, ja joka viikko perehdymme käytännön strategioihin, uusiin trendeihin, hyväksi havaittuihin viitekehyksiin ja satunnaisiin tositarinoihin projektien etulinjasta. Johdatpa sitten valtavia muutoshankkeita, hallitset tekoälytyönkulkuja tai yrität vain pitää kaaoksen hallinnassa, olet oikeassa paikassa.

Jos olet pitänyt siitä, mitä olet viime aikoina kuullut meiltä, harkitse meidän seuraamistamme siellä, missä kuuntelet meitä, ja ehkä myös arvostelun jättämistä. Selvä. Aloitetaan.

Tänään kanssani on Satish Menon, teknisen ohjelmajohtamisen ja teknisten toimintojen johtaja, joka on vastannut toimituksesta teknologiajättien, kuten Googlen ja Dellin, sekä Tenablen, Cohesityn ja Seismicin kaltaisten ohjelmistoyritysten palveluksessa.

Satishin vastuulla olevat ohjelmat ovat ulottuneet laitteisto- ja ohjelmistojulkaisuista pilvi-infrastruktuuriin ja datakeskusten optimointituotteisiin. Niissä on hyödynnetty Satishin kykyä navigoida johtoryhmän päätöksissä, tarjota organisatorista johtajuutta, kehittää ja toteuttaa operatiivista strategiaa, muuttaa prosesseja ja antaa neuvoja tuotekehityksessä.

Nykyään Satish auttaa teknisten ohjelmapäälliköiden tiimejä navigoimaan tekoälyllä tehostetun ohjelmistokehityksen ja ohjelmajohtamisen maailmassa sekä puolustaa teknisen ohjelmapäällikön roolin arvoa teknologiaa hyödyntävissä organisaatioissa.

Satish, kiitos paljon, että liityit seuraani tänään.

Satish Menon: Hei, Galen. Kiitos mahdollisuudesta. Olen innoissani täällä olemisesta.

Galen Low: Tässä on pieni etenemissuunnitelma, jonka olen laatinut meille tänään. Ensin halusin esittää sinulle hieman kiistanalaisen kysymyksen, jonka kuulijani varmasti haluavat kuulla sinun käsittelevän. Sen jälkeen haluaisin käyttää sitä näkökulmana kolmen asian tarkasteluun.

Ensinnäkin halusin tarkastella sitä, miten teknisen ohjelmapäällikön rooli on murroksessa, erityisesti ohjelmistojen parissa. Voisimme puhua siitä, miten osastopäälliköt ja tiiminvetäjät voivat puolustaa teknisten ohjelmapäälliköidensä tuottamaa arvoa. Lisäksi voisimme perehtyä ohjelmistotiimien esihenkilöiden ja teknisten ohjelmapäälliköiden roolien yhdistymisen vaikutuksiin.

Miltä tämä kuulostaa?

Satish Menon: Erinomaista. Odotan innolla keskustelua.

Galen Low: Hienoa. Aloitetaan. Tässä on kipakka kysymys keskustelun aluksi. Teknisten ohjelmapäälliköiden mukaan heidän ei tarvitse osata koodata tuottaakseen arvoa. Samaan aikaan monet teknologiajohtajat näyttävät olevan eri mieltä. He sanovat, että tekoälyn ansiosta ohjelmistokehitystiimin esihenkilö ja tekninen ohjelmapäällikkö ovat nykyään yksi ja sama asia.

Kumpi siis on oikeassa? Onko tekoäly luonut tilanteen, jossa organisaatioiden on järkevää odottaa ohjelmistotiimien esihenkilöiden toimivan myös teknisinä ohjelmapäälliköinä ja päinvastoin?

Satish Menon: Voit varmasti olla kanssani samaa mieltä siitä, että ohjelmistoinsinöörin rooli on muuttunut viime aikoina paljon, eikö niin?

He ovat siirtyneet itse koodin kirjoittamisesta, joka oli aiemmin pullonkaula, nykyiseen tilanteeseen, jossa he käyttävät paljon niin sanottua fiiliskoodausta ja tekoälytyökaluja koodin tuottamiseen kymmenen tai jopa sadan kerran nopeudella. Nyt ongelma on siirtynyt tarkistusvaiheeseen, esimerkiksi yhdistämispyyntöjen tarkistukseen. Yhdistämispyyntöjen koko on kasvanut, joten ihmisen suorittaman valvonnan taakka on siirtynyt siihen osaan, jossa tekoälyn ohjelmistolle tuottamaa sisältöä valvotaan.

Samanlainen muutos, jonka näemme ohjelmistokehityksen työnkulussa, nopeudessa ja ohjelmistoinsinöörien työssä, täytyy tapahtua myös teknisten ohjelmapäälliköiden puolella. Esimerkiksi kolme–viisi vuotta sitten suuri osa työstä koostui suunnitelman tekemisestä ja sen selvittämisestä, mikä on tilanne.

Missä vaiheessa asiat ovat? Miten riippuvuudet sopivat yhteen? Mitkä ovat riskit ja miten niitä lievennetään? Miten laadunvarmistus etenee? Onko projektimme laadunvarmistus oikealla tiellä, liittyykö siihen riskejä? Lisäksi seurattiin virheitä, niiden vähentämistä ja testikattavuutta.

Tuolloin tekniset ohjelmapäälliköt hoitivat nämä asiat pääosin manuaalisesti tai puolimanuaalisesti. Sitten neljä tai viisi vuotta sitten aloimme muuttaa toimintaa Jiran ja Atlassianin avulla. Kun suunnitelma oli kerran määritetty, kaikki tämä tieto alkoi nousta automaattisesti esiin, ja tekniset ohjelmapäälliköt saattoivat tarkastella koontinäyttöjä ja arvioida, mikä oli punaisella tai keltaisella. Sen jälkeen he saattoivat keskittyä ongelmanratkaisuun.

Rooli muuttui siis muotoon: teen suunnitelman, mutta kerään ja raportoin myös paljon tilannetietoa, raportoin riskeistä ja autan riskien lieventämisessä. Nyt tarkkailen reaaliaikaisia koontinäyttöjä, jotka kertovat tilanteen, ja kun näemme punaisia tai keltaisia merkkejä, koordinoin ratkaisukeskeistä ongelmanratkaisua.

Rooli kehittyi näin. Nyt tekoälyn myötä teknisille ohjelmapäälliköille avautuu vielä enemmän mahdollisuuksia. Jos tarkastelet nykyisin käytössä olevia työkaluja, sinulla on esimerkiksi Jira ja GitHub, jossa koodi kirjoitetaan. Lisäksi käytössä on BrowserStack, jossa hallitaan kaikki laatuun ja käyttöönottoon liittyvät asiat.

Jos pystyt yhdistämään näiden kolmen tai muiden käytössä olevien työkalujen tiedot, saat kattavampia koontinäyttöjä, rikkaampaa dataa ja paremman analyysin riskeistä ja ongelmista. Teknisen ohjelmapäällikön rooli kehittyy näin. Meidän ei enää tarvitse manuaalisesti selvittää, mikä on punaisella tai keltaisella.

Voimme käyttää tekoälyä tietojen yhdistämiseen useista työkaluista sekä oikeiden signaalien ja tarkasteltavien asioiden tunnistamiseen, jotta löydämme punaiset ja keltaiset kohdat paljon paremmin kuin ennen.

Galen Low: Pidän tästä todella paljon. Pidän erityisesti siitä, että kuvaat pullonkaulan siirtymistä, mutta tuot esiin, että kyse on oikeastaan kahdesta eri pullonkaulasta.

Insinööripuolella koodarit käyttävät vähemmän aikaa koodin manuaaliseen kirjoittamiseen. He työskentelevät Cursorin kanssa ja pystyvät toimimaan nopeammin, mikä siirtää pullonkaulan tarkistusvaiheeseen. Kun puhut ohjelmistokehitystiimin esihenkilöstä, se tarkoittaa hänelle käytännössä enemmän tarkistettavaa.

Pullonkaula siirtyy. Tarkistettavaa on todennäköisesti enemmän, koodia on enemmän valvottavana, ja he tuottavat arvoa pitämällä työnkulun liikkeessä ja ratkaisemalla koodiin liittyviä ongelmia nopeasti. Toisin sanoen juuri siellä he voivat tuottaa enemmän arvoa.

Heille ei synny ylimääräistä kapasiteettia teknisen ohjelmajohtamisen hoitamiseen. Toisella puolella pullonkaula liittyi aiemmin tiedon ja tilannepäivitysten keräämiseen, mutta nyt myös meidän roolimme on murroksessa. Käytämme Jiran kaltaisia työkaluja ja tekoälyä, ja osa tästä automaatiosta vie meitä lähemmäs ongelmien ratkaisemista sen sijaan, että istuisimme toimettomina ja meillä olisi yhtäkkiä kapasiteettia valvoa ohjelmistokehitystiimiä.

Pidän tästä kuvauksesta. Häiriö tapahtuu molemmilla puolilla, mutta se ei tarkoita, että muodostuisi yksi yhteinen rooli. Kyse on kahdesta erillisestä asiasta.

Satish Menon: Mukana on myös toinen näkökulma. Ohjelmistokehityksen esihenkilö tai johtaja vastaa siitä, että tiimit toimittavat laadukasta, turvallista, saavutettavaa ja suorituskykyistä koodia hyvällä nopeudella.

He parantavat nopeutta tekoälyn avulla. Jos kuitenkin odotat heidän vastaavan myös toimituksen monitoiminnallisista osa-alueista – muiden ohjelmistotiimien riippuvuuksista, testauksen ja laadunvarmistuksen riittävästä kattavuudesta, suorituskyvyn skaalauksesta, järjestelmäintegraatiotestauksesta ja siitä, että asiakkaat saavat tuotteen ajoissa – kyse on jo ylimääräisestä taakasta.

Kaikki nämä monitoiminnalliset näkökulmat on jonkun hoidettava. Teknisten ohjelmapäälliköiden avulla ja kaikkien näiden työkalujen tuella ne voidaan hoitaa paljon tehokkaammin ja nopeammin, mutta ne on silti hoidettava.

Tarvitaan valvontaa ja tasapainoa.

Galen Low: Pidän tästä todella paljon. Automaatio lisääntyy tällä hetkellä monissa eri rooleissa, erityisesti teknisessä ohjelmajohtamisessa ja ohjelmistokehityksessä. Joskus kuulen puhuttavan siitä, että kaikki säännöt voidaan automatisoida viitekehysten avulla ja ihmiset vain noudattavat niitä.

Mutta kuten sanoit, ihmiset eivät toimi näin. Ongelmiin joutuu aina ihmisiä, jotkut rikkovat sääntöjä tarkoituksella, eivätkä kaikki ymmärrä prioriteetteja. Pohjimmiltaan joku tarvitsee edelleen prosessin ohjaamista.

Sitä tarvitaan vähemmän kuin ennen, mutta sillä on yhä arvoa. Lisäksi niin monen palasen täytyy loksahtaa yhteen ohjelmistotuotteen toimittamiseksi. Vain osa siitä liittyy koodin laatuun; loppu on monitoiminnallista koordinointia, jolla varmistetaan, että kaikki valmistuu oikeaan aikaan.

Jos ohjelmistoinsinöörien tiimin hallinta vie huomiosi – kahdenkeskiset keskustelut, uran johtaminen, koodin laadun tarkistaminen ja teknisten ongelmien ratkaiseminen – se on tärkeää. Jos se kuitenkin häiritsee toimitusta, näiden kahden asian priorisointi on hyvin vaikeaa.

Voisimme ehkä ottaa hieman etäisyyttä. Olet johtanut teknisten ohjelmapäälliköiden tiimejä Dellin ja Googlen kaltaisissa yrityksissä sekä muissa suurissa ohjelmistoyrityksissä. Olemme puhuneet ongelmanratkaisusta: ohjelmistotiimin johtaja voi ratkaista teknisiä ongelmia, ja tekninen ohjelmapäällikkö ratkaisee myös ongelmia, koska raportointi ja koontinäytöt mahdollistavat ennakoivamman toiminnan.

Mutta niiden välissä on kuilu. Millaisia ongelmia tekninen ohjelmapäällikkö voi ratkaista ilman koodausosaamista? Kuinka syvällistä teknistä sujuvuutta odotat teknisiltä ohjelmapäälliköiltäsi? Mitkä käsitteet jokaisen ohjelmistoinsinöörien kanssa työskentelevän teknisen ohjelmapäällikön pitäisi ymmärtää ja miksi?

Satish Menon: Tämä johtaa yhteen tärkeään asiaan. Ohjelmistoesihenkilö tai ohjelmistokehityksen johtaja voi hallita projekteja, jotka ovat kokonaan heidän oman organisaationsa sisällä. Kun kyse on suuremmasta toimituksesta, jolla on riippuvuuksia muista tiimeistä, tekninen ohjelmapäällikkö astuu mukaan.

Kyse ei ole vain ohjelmistokehityksen, tuotehallinnan, suunnittelun, kenttätoimintojen, markkinoillemenon ja teknisen dokumentaation välisestä yhteistyöstä, vaan myös ohjelmistotoimituksen sisäisistä tiimien välisistä riippuvuuksista.

Meidän ei pitäisi päättää tätä keskustelua siihen käsitykseen, ettei ohjelmistoesihenkilö tai ohjelmistokehityksen johtaja tee projektinhallintaa. He tekevät sitä, mutta oman organisaationsa sisällä täysin rajatuille toimituksille. Monitoiminnalliset kokonaisuudet on usein parempi hoitaa teknisen ohjelmapäällikön avulla neutraalista näkökulmasta.

Teknisen osaamisen tasosta olen yleensä sitä mieltä, että on hyvä käyttää tai palkata teknisiä ohjelmapäälliköitä, jotka ovat aiemmin koodanneet tai joilla on paljon kokemusta koodauksesta. Se auttaa heitä ymmärtämään insinöörien kieltä ja saavuttamaan heidän kunnioituksensa.

On tärkeää ymmärtää koodin elinkaari: mitä ovat sisäänkirjaukset, sitoumukset, yhdistämispyynnön tarkistus, tarkistussykli, linttaus ja staattinen analyysi? Entä yksikkötestaus verrattuna järjestelmätestaukseen, integraatiotestaukseen, suorituskykytestaukseen ja käyttöönottoon?

Jos olet koodannut aiemmin, tunnet nämä asiat. Vaikka koodaus olisi myöhemmin hieman ruosteessa, sinun pitäisi silti ymmärtää koodin elinkaari. Sinun pitää hallita myös sen ulkopuolinen elinkaari: vaatimukset, koodaus, testaus, pilotointi ja lopulta yleiseen saatavuuteen johtava tarkistuslista ja julkaisu.

Toinen teknisyyden taso liittyy siihen, että teknisen ohjelmapäällikön on hyvä ymmärtää, mitä tuotetta hän toimittaa. Jos tiedät, mitä ollaan kehittämässä ja mitä ominaisuus tarkoittaa, pystyt keskustelemaan paremmin tuotepäälliköiden, suunnittelijoiden, ohjelmistoinsinöörien, asiakasmenestyksestä vastaavien esihenkilöiden ja järjestelmäinsinöörien kanssa.

Kolmanneksi heidän pitäisi pystyä kirjoittamaan omia skriptejään ja luomaan omia koontinäyttöjään Jiraan, Tableaun, Sisensen tai muiden työkalujen avulla. Heidän pitäisi osata etsiä oikeita signaaleja ja selvittää, mitä muuta pitää mitata. Tämäkin on teknistä osaamista, mutta ei siinä määrin, että heidän pitäisi pystyä kirjoittamaan varsinaista ohjelmakoodia.

Galen Low: Pidän erityisesti siitä, että kyse ei ole kaksijakoisesta asiasta. Ei ole niin, että vain ohjelmapäälliköt voivat tehdä ohjelmajohtamista, eikä niin, että ohjelmapäälliköt katoavat, koska ohjelmistotiimien esihenkilöt hoitavat heidän työnsä.

Välissä on selkeä jatkumo, ja yksi muuttuja on monimutkaisuus. Jos toimitat ohjelmistoa vain oman tiimisi sisällä, liikkuvia osia on vähän ja tunnet järjestelmän hyvin. Silloin toimitus voi olla vähemmän monimutkaista.

Erittäin monimutkaisissa projektiympäristöissä mukana voi olla toimittajia, markkinointi- ja tuotestakeholdereita. Silloin arvo on kaiken yhdistämisessä ja monimutkaisuuden navigoinnissa, jotta toimitus onnistuu.

Pidän myös teemastasi, joka liittyy parempiin keskusteluihin. Syvempi ymmärrys ja yhteinen sanasto mahdollistavat paremman yhteistyön. Lähes kaikissa rooleissa on nykyään tekninen ulottuvuus, myös teknisen ohjelmapäällikön roolissa. On osattava rakentaa raportti tai koontinäyttö ja automatisoida prosessi.

Satish Menon: Jos käyt parempia keskusteluja, se johtaa parempaan kunnioitukseen. Parempi kunnioitus tarkoittaa, että sinut kutsutaan strategisempiin keskusteluihin, joissa sinut nähdään strategisena toimeenpanokumppanina ja henkilönä, joka varmistaa strategian muuttumisen hyviksi suunnitelmiksi.

Jos et saavuta heidän kunnioitustaan tai sinulla ei ole heidän käyttämäänsä sanastoa ja riittävää syvyyttä, tuotepäälliköt ja insinöörit päättävät strategiasta keskenään, etkä saa paikkaa heidän pöydästään.

Sinulle saatetaan antaa valmis suunnitelma ja pyytää vain seuraamaan sitä. Silloin sinusta tulee seurannan ylläpitäjä. Teknisen ohjelmapäällikön rooli tulee yleensä myöhemmin organisaation elinkaaressa. Aluksi tuotteet syntyvät usein tuotepäälliköiden tai insinöörien työstä, eikä teknistä ohjelmapäällikköä ole mukana.

Kun tiimi kasvaa, insinööritiimejä tulee useita ja tarvitaan yhteinen alusta, riippuvuuksia alkaa syntyä. Silloin organisaatio sanoo: otetaan tekninen ohjelmapäällikkö seuraamaan kaikkia riippuvuuksia.

Koska tulet mukaan myöhemmin, sinun täytyy ansaita paikkasi. Sinun on osattava tiimien käyttämä kieli, jotta sinut voidaan nähdä tasavertaisena kumppanina. Riippuvuuksien hallinta on työn perusta, mutta rooliin kuuluu myös monia muita asioita.

Galen Low: Pidän siitä, että tekninen ohjelmapäällikkö tulee usein myöhemmin mukaan, mutta organisaatio ei pysty skaalautumaan ilman tätä roolia. Arvo syntyy, kun asiat monimutkaistuvat, tiimejä on enemmän ja panokset kasvavat.

Strategisena kumppanina sinun on puhuttava kaikkien monitoiminnalliseen tiimiin kuuluvien ryhmien kieltä, myös tuotteen. Johtoryhmät haluavat kumppanin, joka ymmärtää, mitä ollaan toimittamassa, miksi sitä toimitetaan ja miten toimitus voidaan suunnitella mahdollisimman arvokkaaksi.

Jos rooli nähdään vain hallinnollisena työnä – ruutujen rastittamisena, Jira-tehtävien tarkistamisena ja jäljellä olevan työn kuvaajan seuraamisena – arvo jää vähäiseksi. Todellista arvoa syntyy siitä, että ymmärtää ongelman paremmin ja muuttaa suunnitelmaa niin, että saavutettu arvo voi olla suurempi kuin alun perin suunniteltu.

Satish Menon: Tekoälyn aikakaudella yksi mahdollisuus liittyy liiketoiminta-arvoon. Jos sinulla on idea, siitä voi tehdä fiiliskoodatun demon hyvin nopeasti. Sen voi näyttää kolmelle tai viidelle luotettavalle asiakkaalle ja kerätä palautetta.

Aiemmin koodausta piti tehdä valtavasti ennen kuin asiakkaalle voitiin näyttää demo. Nyt demon voi luoda nopeasti, ja Seismicillä kutsuimme sitä tutkimusesikatseluksi. Varhaista koodia näytetään asiakkaille, palautetta kerätään ja lopullisia vaatimuksia tarkennetaan ennen kuin ratkaisu viedään yleiseen saatavuuteen.

Tekniset ohjelmapäälliköt voivat auttaa tämän tutkimusesikatseluprosessin toteuttamisessa, jotta ennen yleistä saatavuutta saavutetaan suurempi arvo.

Toinen osa liittyy strategiseen arvoon ja siihen, miten yhteistyö uuden johtajan kanssa onnistuu. Kun yritykseen tulee uusi johtoryhmän jäsen, hänen ennakkokäsityksensä voivat olla erilaisia. Joskus saat mahdollisuuden näyttää kolmen kuukauden aikana tuottamasi arvon. Joskus päätöksiä tehdään välittömästi.

Meidän on hyväksyttävä, että ennakkokäsitykset vaikuttavat tilanteeseen. Joskus niitä voi muuttaa, joskus olet niiden uhri.

Galen Low: Tämä jakso on Fingerprintin sponsoroima. Jokainen alustallasi vieraileva käyttäjä näyttää aluksi samanlaiselta. Voitko luottaa häneen vai onko hän uhka? Fingerprint tunnistaa botit, tekoälyagentit, VPN:t, manipuloinnin ja yli sata muuta yksilöllistä signaalia tarjotakseen kestävää riskipisteytystä ja uhkien reaaliaikaista havaitsemista.

Yli 6 000 yritystä käyttää Fingerprintiä päivittäin. Liity joukkoon osoitteessa fingerprint.com. Ja nyt takaisin ohjelmaan.

Johtajuuden vaihtuessa teknisen ohjelmapäällikön on osoitettava, miten työ on muuttunut tekoälyn aikakaudella. On kerrottava, miten useiden järjestelmien tietoja yhdistetään, miten ennakoivia mittareita seurataan ja miten tekoälyä käytetään teknisessä ohjelmajohtamisessa ohjelmistokehityksen tekoälyn käytön tukena.

Satish Menon: Hyvä teknisten ohjelmapäälliköiden tiimi voi tunnistaa riskien ennakoivia mittareita missä tahansa ohjelmassa, toteutuksessa tai operatiivisesti tehokkaassa tiimissä. Näin voidaan varoittaa tulevasta huonosta lopputuloksesta ja lieventää riskiä ennen kuin on liian myöhäistä.

Galen Low: Rooli on nykyään erilainen, osittain tekoälyn ja ohjelmistokehityksen muutosten vuoksi, mutta myös siksi, että ammatit kehittyvät. Miten teknisen ohjelmapäällikön rooli eroaa nykyään kolmen tai neljän vuoden takaisesta?

Satish Menon: Ohjelmistoinsinöörit toimivat kymmenen tai sata kertaa nopeammin kuin ennen. Meidän on tehtävä sama. Emme voi enää tehdä manuaalisia raportteja tai kerätä tilannetietoa käsin.

Meidän täytyy käyttää automaattisia reaaliaikaisia koontinäyttöjä ja arvioida niiden punaisia ja keltaisia merkkejä. Lisäksi meidän on vahvistettava yhden työkalun ilmoittamat riskit vertaamalla niitä muihin työkaluihin.

Jos Jira ilmoittaa jonkin olevan lähes valmis, mutta GitHubin ja Clauden arviot eivät vastaa tätä, kyseessä on varoitusmerkki. Kun tarkastelet koodin elinkaarta koodin kirjoittamisesta sisäänkirjauksiin, sitoumuksiin ja yhdistämispyyntöjen tarkistuksiin, Jiran ilmoittama valmistuminen voi olla ristiriidassa todellisen tilanteen kanssa.

Myös testauksen edistymistä on verrattava BrowserStackin tietoihin laadusta, pilvikäyttöönotosta, testauksesta ja esivaiheen ympäristöstä. Näin saat rikkaamman ja paremman arvion.

Jos emme mukaudu näihin muutoksiin ja uusiin tapoihin ajatella projektin tilannetta ja arvon toimittamista, meistä tulee lopulta tarpeettomia. Jos pysymme mukana kehityksessä, parhaat ihmiset säilyvät.

Galen Low: Pidän tästä skaalautumisen mahdollistamisesta ja arvon mahdollistamisesta. Meidän ei pidä olla pullonkaula vanhentuneiden toimintatapojen vuoksi, vaan meidän pitää osallistua aktiivisesti.

Millaista ongelmanratkaisua odotat teknisiltä ohjelmapäälliköiltäsi? Onko kyse tiimien koordinoinnista, yhteisen näkemyksen varmistamisesta ja linjausten löytämisestä, vai pitääkö sen olla syvällisempää?

Satish Menon: Kyse on jatkumosta. Googlessa tekniset ohjelmapäälliköt olivat erittäin teknisiä ja pystyivät ratkaisemaan enemmän teknisiä ongelmia itse. Se ei kuitenkaan ole toimialalla tavallista.

Tyypillisen teknisen ohjelmapäällikön pitäisi pystyä tunnistamaan, että jokin tiimi on jäljessä ja tarvitsee apua. Hänen pitäisi tuntea samanlaiset sisartiimit ja pystyä ehdottamaan resurssien tai osaamisen lainaamista niiltä.

Jos alustatiimi on myöhässä ja se vaarantaa jonkin tuotteen julkaisun, teknisen ohjelmapäällikön pitäisi auttaa priorisoimaan tiimin työ niin, että tärkeä julkaisu valmistuu ajoissa.

Jos tuot ongelmanratkaisuun alkuperäisiä ajatuksia ja helpotat teknisen johtajan ideointia, ansaitset enemmän kunnioitusta. Tavoitteena on saada oikeat osapuolet pöydän ääreen, tunnistaa käytettävissä olevat resurssit ja muotoilla seuraavat askeleet niin, että muiden tarvitsee tehdä vähemmän työtä ratkaisun löytämiseksi.

Galen Low: Syvempi ymmärrys tuottaa toistuvasti enemmän arvoa. Jos tiedät jo, että toisella tiimillä on oikea osaaminen ja kapasiteettia, voit tuoda ratkaisun tiimillesi sen sijaan, että sanoisit: tämä on teidän ongelmanne, ratkaiskaa se perjantaihin mennessä.

Satish Menon: Jos sanot vain, että tämä on teidän ongelmanne, ratkaiskaa se, kun taas pidät heidät vastuussa päivämäärästä, kunnioitus laskee. Jos tuot vähintään 70-prosenttisen ratkaisun resurssien jakamisesta tai luovista tavoista ratkaista ongelma, voit sanoa: tässä on ajatus, mutta te omistatte tämän. Jos siitä on hyötyä, käyttäkää sitä; muuten löytäkää parempi ratkaisu.

Galen Low: Pidän ilmaisusta 70-prosenttinen ratkaisu. Tuo jotain osittain valmista. Se ei ole lopullista, mutta antaa lähtökohdan.

Satish Menon: Tutkimusesikatselu on enemmän prosessiasia. En tarkoittanut, että tekniset ohjelmapäälliköt fiiliskoodaisivat asiakkaiden demoja. Tuotepäälliköt ja kokeneet insinöörit tekevät fiiliskoodauksen, ja tuotepäälliköt koordinoivat prosessia ja varmistavat hyvät asiakasdemot. Teknisten ohjelmapäälliköiden tehtävä on valvoa prosessia.

Galen Low: Kaikki toimivat nopeammin, mutta yhdessä toimiminen on edelleen arvokasta. Tutkimusesikatselu ei synny ilman insinöörejä. Kehittäjät eivät vain kirjoita koodia käsin, ohjelmapäälliköillä on käytössään työkaluja ja koontinäyttöjä, ja tuotepäälliköt voivat rakentaa prototyypin nopeasti. Näin kaikki voivat ymmärtää arvon, edistää työtä ja varmistaa sidosryhmien linjauksen.

Satish Menon: Olen nähnyt insinöörien tekevän fiiliskoodattuja varhaisia demoja tai tutkimusesikatseluja tuotepäälliköiden tai tuotesuunnittelijoiden ideoiden pohjalta. Enää emme rajoitu vain näyttämään, miltä jokin voisi näyttää Figma-suunnitelman perusteella.

Galen Low: Miten lähestyt rekrytointia? Palkkaisitko mieluummin entisen kehittäjän, josta on tullut hyvä ohjelmapäällikkö, vai pitkään toimineen ohjelmapäällikön, joka ei tiedä, mikä yhdistämispyyntö on?

Satish Menon: Kuten sanoin, aiemmin koodanneet tekniset ohjelmapäälliköt ovat usein parempia. Poikkeuksia kuitenkin on. Arvioin lopputulosta enkä etsi ansioluettelosta vain merkintää aiemmasta koodauksesta.

Haluan tietää, pystyvätkö he puhumaan tehokkaasti insinöörien kieltä sekä tuotepäälliköiden ja suunnittelijoiden kieltä. Sillä ei ole ratkaisevaa merkitystä, oppivatko he tämän koodaamalla aiemmin vai työskentelemällä läheisesti koodaajien kanssa.

Nykyään mahdollisuus siirtyä ohjelmistojen teknisen ohjelmapäällikön tehtäviin ilman koodaus­taustaa on kuitenkin pienempi. Aiemmin laitteisto-ohjelmapäällikkö saattoi siirtyä ohjelmistoprojektiin ja opetella työn ohessa. Nykyään työnantajat etsivät valmiita osaajia, ja perehdyttämisen sietokyky on hyvin pieni.

Galen Low: Se on realistinen kuvaus markkinasta. Jos et tiedä, mikä yhdistämispyyntö on, se ei välttämättä tarkoita, ettet saa työtä, mutta sinun on oltava valmis opiskelemaan ja oppimaan puhumaan monitoiminnallisten tiimien kieltä.

Satish Menon: Haastatteluissani käytän erityistä kysymyspatteristoa, jolla arvioin teknistä sujuvuutta. Mukautan kysymykset ehdokkaaseen ja hänen ansioluettelossaan esittämiinsä kokemuksiin. Arvioin sekä heidän oman toimialansa ja tuotteidensa että ohjelmistokehityksen yleisen työnkulun tuntemusta.

Lisäksi käytän tilannekysymyksiä, joilla arvioin ihmisiin liittyviä taitoja ja tunneälyä. Opin objektiivisen haastattelumenetelmän Googlessa, ja käytän sitä edelleen.

Galen Low: Voisitko antaa esimerkin tilannekysymyksestä, jolla testaat tietyn ehdokkaan teknistä osaamista?

Satish Menon: Jos joku kertoo työskennelleensä SaaS-ympäristössä ja optimoineensa julkaisuprosessin nopeampaa toimitusta varten, kysyn, mikä SaaS-ohjelmiston toimituksessa eroaa paikallisesti asennettavan ohjelmiston toimituksesta. Kysyn, missä he ovat oikaisseet ja miksi.

Kysyn myös heidän julkaisemistaan tuotteista ja ominaisuuksista. Heidän pitäisi pystyä kertomaan, mitä ominaisuus teki ja millaista muutosta se toi asiakkaille. Näin näen, olivatko he vain lisänneet prosessin olemassa olevan ohjelmiston elinkaaren päälle vai ymmärsivätkö he todella toimitettavan tuotteen.

Kysyn myös ohjelmiston elinkaaresta koodauksen puolella, DevOpsista, esivaiheen ympäristön ja tuotantoympäristön eroista sekä turvarajoista. Näin selviää, ymmärtävätkö he, miten ohjelmistot ja pilvi toimivat.

Galen Low: Olemme puhuneet siitä, että teknisen ohjelmapäällikön ja ohjelmistokehitystiimin esihenkilön roolien ei pitäisi yhdistyä. Jos kuitenkin tulevaisuudessa hybridiroolista tulee hallitseva rakenne, mitä se tarkoittaisi?

Satish Menon: Meidän pitää keskittyä siihen, mitä voimme hallita. Voimme pysyä edellä siinä, mitä tämän päivän työkalut mahdollistavat ja missä voimme edelleen tuottaa arvoa tuotetoimitukselle.

Ajattele monitoiminnallisesti, useiden tiimien näkökulmasta ja tieteenalojen rajapinnoilla. Arvomme on suurimmillaan siellä, missä useat toiminnot yhdistyvät tuotteen toimittamiseksi.

Aluksi kyse voi olla useista insinööritiimeistä. Seuraavalla tasolla mukaan tulevat laadunvarmistus, DevOps ja tekninen dokumentaatio. Sen jälkeen mukaan tulevat tuoteorganisaatio, kenttätoiminnot, asiakasmenestyksen esihenkilöt, myynti-insinöörit, asiakastuki ja yrityksen tarjoamat palvelut.

Lisäksi mukana ovat julkaisutapahtumat ja markkinointiviestit. Tässä kokonaisuudessa eri toiminnot tekevät oman osuutensa, ja tekninen ohjelmapäällikkö voi toimia kaiken orkestroijana.

Ajattele myös useita yrityksiä ja kumppanuuksia. Yritys voi julkaista jotain yhdessä kumppanin tuotteen kanssa, jolloin ohjelmajohtamista tarvitaan yritysten välillä.

Nykymaailmassa teknisten ohjelmapäälliköiden pitää käyttää reaaliaikaisia koontinäyttöjä, yhdistää tietoja useista työkaluista, hyödyntää tekoälyä ja osallistua tuote- ja ongelmanratkaisuun. Sen jälkeen heidän pitää ajatella yhä suurempia monitoiminnallisia ongelmia.

Galen Low: Pidän tästä todella paljon. Olemme keskiössä. Jos rooli poistetaan ja keskitytään vain ohjelmistokehitykseen, menetämme kaiken muun arvon. Eri kumppanit, tiimit ja tieteenalat tuovat kompleksisuutta, jossa lisäämme eniten arvoa.

Tarvitsemme kuitenkin syvällistä ymmärrystä. Emme voi vain rastittaa ruutuja ja asettaa viitekehyksiä tuotteisiin, joita emme ymmärrä. Meidän on tiedettävä, mitä arvo tarkoittaa, miten tuotteet valmistetaan ja miten voimme varmistaa niiden merkityksellisen ja vaikuttavan toimituksen.

Satish, kiitos paljon ajastasi. Tämä on ollut hauskaa. Mistä ihmiset voivat lukea sinusta lisää?

Satish Menon: Etsikää minut LinkedInistä.

Galen Low: Kiitos vielä kerran.

Satish Menon: Nautin keskustelustamme, Galen. Kiitos paljon mahdollisuudesta.

Galen Low: Selvä, kaikki. Tässä oli tämä Digital Project Manager -podcastin jakso. Jos pidit keskustelusta, tilaa podcast siellä, missä kuuntelet sitä. Jos haluat vielä enemmän käytännön näkemyksiä, tapaustutkimuksia ja toimintaohjeita, luo meille ilmainen tili osoitteessa thedigitalprojectmanager.com.

Ensi kertaan, kiitos kuuntelusta.