10 Kat Mühendislik Teknik Program Yöneticileri İçin Ne Anlama Geliyor?

Galen Low: Teknik program yöneticilerinden genellikle kod yazmaları beklenmez; ancak bugünlerde yazılım mühendislerinden de elle kod yazmaları beklenmiyor. Dolayısıyla soru, teknik program yöneticilerinin kod yazıp yazamaması değil. Asıl soru şu: Etraflarındaki ekipler yapay zekâ kullanarak birkaç yıl öncesine göre beş, 10, hatta bazen 50 kat daha hızlı çalışırken, teknik program yöneticilerinin değer kattıkları alanı değiştirebilmeleri için ne düzeyde bir anlayışa ihtiyaçları var?

Teknik program yöneticisi rolünün günümüz yazılım sektöründe nasıl geliştiğini incelemek için Dell ve Google gibi kuruluşlarda teknik program yöneticisi ekiplerine liderlik etmiş bir Teslimat ve Mühendislik Operasyonları Başkan Yardımcısını programa davet ettim. Birlikte, bugün teknik program yöneticilerinden beklenen becerilerden, teslimat liderlerinin liderlik değişiklikleri sırasında ekiplerinin değerini nasıl savunabileceğine kadar pek çok konuyu ele alacağız.

Ayrıca işe alım yöneticilerinin işe alım sürecinde teknik program yöneticisi adaylarını nasıl değerlendirebileceğini ve teknik program yöneticisi rolünün modasının geçmesi durumunda ne gibi etkiler doğacağını da konuşacağız. Umarım bölümü beğenirsiniz.

Dijital Proje Yöneticisi Podcast’ine hoş geldiniz; bu program, teslimat liderlerinin yapay zekâ çağında daha akıllı çalışmasına, daha sorunsuz teslimat yapmasına ve ekiplerini güvenle yönetmesine yardımcı olur. Ben Galen’ım. Her hafta gerçek dünyadan stratejileri, yeni ortaya çıkan eğilimleri, kanıtlanmış çerçeveleri ve proje cephesinden zaman zaman bir savaş hikâyesini ele alıyoruz. İster büyük dönüşüm projelerini yönetiyor, ister yapay zekâ iş akışlarını düzenliyor, ister yalnızca kaosu kontrol altında tutmaya çalışıyor olun, doğru yerdesiniz.

Son zamanlarda bizden dinlediklerinizi beğeniyorsanız, bizi bulduğunuz platformda takip etmeyi ve hatta bir değerlendirme bırakmayı düşünün. Pekâlâ, başlayalım.

Bugünkü konuğum, Google ve Dell gibi teknoloji devlerinin yanı sıra Tenable, Cohesity ve Seismic gibi yazılım şirketlerinde teslimat yönetmiş teknik program yönetimi ve mühendislik operasyonları lideri Satish Menon.

Satish’in sorumluluğundaki programlar; donanım ve yazılım lansmanlarından bulut altyapısına ve veri merkezi optimizasyon ürünlerine kadar uzanıyor. Bu çalışmalar Satish’in üst düzey yönetim kararlarını yönlendirme, kurumsal liderlik sağlama, operasyonel strateji geliştirme ve uygulama, süreçleri dönüştürme ve ürün geliştirme konusunda danışmanlık yapma becerilerine dayanıyor.

Satish bugün, teknik program yöneticisi ekiplerinin yapay zekâ destekli yazılım mühendisliği ve program yönetimi dünyasında yol almalarına yardımcı olurken, teknik program yöneticisi rolünün teknoloji odaklı kuruluşlarda oynadığı değeri de savunuyor.

Satish, bugün bana katıldığın için çok teşekkürler.

Satish Menon: Merhaba Galen. Bu fırsat için teşekkür ederim. Burada olmaktan mutluyum.

Galen Low: Bugün için küçük bir yol haritası hazırladım. Öncelikle dinleyicilerimin sizin görüşünüzü duymaktan hoşlanacağını düşündüğüm biraz tartışmalı bir soruyla başlamak istiyorum. Ardından bu soruyu üç konuyu incelemek için bir mercek olarak kullanacağız.

İlk olarak, özellikle yazılım alanında teknik program yöneticisi rolünün nasıl değişime uğradığına bakmak istiyorum. Bölüm yöneticilerinin ve ekip liderlerinin teknik program yöneticilerinin değerini nasıl savunabileceğini konuşabiliriz. Ayrıca yazılım ekibi yöneticileriyle teknik program yöneticileri arasındaki rol melezleşmesinin sonuçlarını da ele alabiliriz.

Sizce nasıl?

Satish Menon: Harika. Bunu konuşmak için sabırsızlanıyorum.

Galen Low: Harika. Hemen başlayalım. Başlangıç için çarpıcı sorum şu: Teknik program yöneticileri değer yaratmak için kod yazabilmeleri gerekmediğini söylüyor. Buna karşılık birçok teknoloji yöneticisi aynı fikirde değil. Yapay zekânın, yazılım mühendisliği ekibi yöneticisiyle teknik program yöneticisini artık aynı kişi hâline getirdiğini söylüyorlar.

Öyleyse kim haklı? Yapay zekâ, kuruluşların yazılım ekibi yöneticilerinin aynı zamanda teknik program yöneticisi olmasını ve bunun tersini beklemesini makul kılan koşulları mı oluşturdu?

Satish Menon: Yazılım mühendisinin rolünün son dönemde büyük bir dönüşüm geçirdiği konusunda benimle hemfikir olabilirsiniz, değil mi?

Eskiden darboğaz olan kodu kendileri yazma aşamasından, şimdi titreşimsel kodlama ve yapay zekâ araçlarını kullanarak kodu 10, hatta 100 kat daha hızlı üretme aşamasına geçtiler. Sorun artık inceleme döngüsüne, yani çekme isteği inceleme döngüsüne kaydı; çekme isteği boyutu büyüdü. Dolayısıyla yapay zekânın yazılımda ürettiği çıktılar üzerindeki insan denetimi kısmında yük arttı.

Yazılım mühendisliği iş akışında, hızında ve yazılım mühendislerinin yaptığı işlerde gördüğümüz değişime benzer şekilde, teknik program yöneticileri tarafında da benzer bir uyarlama yapılması gerekiyor. Örneğin üç ila beş yıl önce, “Plan bu, peki durum ne?” sorusuyla ilgili büyük bir iş yükü vardı.

İşler hangi aşamada? Bağımlılıklar nasıl eşleşiyor? Riskler neler ve bunları nasıl azaltacağız? Kalite mühendisliği nasıl gidiyor? Projemizin kalite güvence boyutu yolunda mı ve orada bir risk var mı? Hataları ve hataların azalmasını, test kapsamını ve benzeri unsurları izlemek gerekiyordu.

Bunlar o dönemin sorunlarıydı ve teknik program yöneticileri tarafından çoğunlukla manuel ya da yarı manuel şekilde ele alınıyordu. Daha sonra, dört veya beş yıl önce Jira ve Atlassian ile bunu dönüştürmeye başladık. Planı kurduktan sonra tüm bu bilgiler otomatik olarak görünür hâle gelmeye başladı. Teknik program yöneticileri panolara bakıp neyin kırmızı, neyin sarı olduğunu değerlendirebiliyor ve ardından sorun çözmeye dâhil olabiliyordu.

Böylece rol değişti. Artık yalnızca plan hazırlamıyor, durum ve risk raporları toplamakla, risk azaltma çalışmalarını kolaylaştırmakla uğraşmıyordum. Durumu bana gösteren canlı panoları izliyor, kırmızı ve sarı göstergeler gördüğümüzde tüm çözüm odaklı sorun çözme çalışmalarını koordine ediyordum.

Şimdi yapay zekâyla birlikte teknik program yöneticileri için daha fazla fırsat var. Bugün kullanılan araçlara bakarsanız bir tarafta Jira, diğer tarafta kodun yazıldığı GitHub var. Ardından kalite ve dağıtım bölümlerinin yönetildiği BrowserStack geliyor.

Bu üç farklı araç ya da kullanılan diğer araçlar arasında bağlantı kurabilirseniz daha zengin panolar, daha zengin veriler ve riskler ile sorunlar hakkında daha kapsamlı analizler elde edersiniz. Teknik program yöneticisi rolü de bu şekilde gelişiyor. Artık neyin kırmızı ve sarı olduğunu manuel olarak bulmak zorunda değiliz.

Yapay zekâyı kullanarak birden fazla araç arasında bağlantı kurabilir, doğru sinyalleri ve bakılması gereken doğru noktaları belirleyebilir, kırmızı ve sarı alanları geçmişte hiç olmadığı kadar iyi tespit edebiliriz.

Galen Low: Buna bayıldım. Darboğazın yer değiştirmesi çerçevesini gerçekten seviyorum; ancak aslında iki farklı darboğaz olduğunu da vurguluyor.

Mühendislik tarafında kod yazarları elle kod yazmaya daha az zaman ayırıyor. Cursor ile çalışıyor, daha hızlı çalışabiliyor ve bu da darboğazı inceleme aşamasına taşıyor. Bir mühendislik ekibi yöneticisinden söz ettiğinizde, bu onun için daha fazla inceleme anlamına geliyor, değil mi?

Darboğaz yer değiştiriyor. Artık muhtemelen daha fazla inceleme ve denetlenecek daha fazla kod var. Kod tarafında hattı hareket hâlinde tutarak ve sorunları hızlıca çözerek değer yaratıyorlar. Başka bir deyişle, daha fazla değeri burada sunabiliyorlar.

Bu, ardından teknik program yönetimi de yapabilecekleri anlamına gelen fazladan bir kapasite oluşturmuyor. Diğer tarafta ise ikinci darboğaz var. Eskiden darboğaz bilgi toplamak ve durum güncellemelerini derlemekle ilgiliydi. Şimdi bizim rolümüz de değişiyor. Jira gibi başka araçları ve yapay zekâyı kullanıyoruz. Bu otomasyonların bir kısmı bizi sorunları çözmeye yaklaştırıyor; bütün gün boş boş oturup bir yazılım mühendisliği ekibini denetleyecek kapasite kazanmıyoruz.

Evet, bu çerçeveyi beğendim. Değişim her iki tarafta da gerçekleşiyor; ancak bu, iki rolün tek bir role dönüşmesi gerektiği anlamına gelmiyor. Bunlar iki ayrı alan.

Satish Menon: Bunun bir başka boyutu daha var. Bir yazılım mühendisliği yöneticisi ya da direktörü, ekiplerinin güvenli, erişilebilir, yüksek performanslı ve yüksek kaliteli kod teslim etmesinden sorumludur.

Yapay zekâ ve benzeri araçlarla hızlarını artırıyorlar. Ancak teslimatın ekipler arası boyutlarından da sorumlu olmalarını beklerseniz bu ek bir yük olur. Öncelikle diğer yazılım ekiplerinden gelen bağımlılıkları yönetmeleri gerekir. İkinci olarak kalite mühendisliği ekiplerinin yüksek düzeyde kod ve test kapsamını tamamladığından emin olmaları gerekir.

Performans, ölçek ve sistem entegrasyon testlerinin yolunda gittiğinden emin olmaları ve müşterilerin ürünü zamanında almasını sağlamaları gerekir. Altyapı, dallanma ve DevOps ekiplerinden gelen teslimatlar, saha beklentileri, teknik belgeler ve saha iletişimi gibi pek çok ekipler arası unsurun da yönetilmesi gerekir.

Bütün bunlarla birinin ilgilenmesi gerekiyor. Bence teknik program yöneticileri, tüm bu araçların yardımıyla bunları çok daha verimli ve hızlı yapabilir; fakat bu işin yapılması gerekiyor.

Yazılım mühendisliği direktörleri ve yöneticilerinin bunu da üstlenmesini beklerseniz, bu ek bir yük oluşturur. Yol güvenliği benzetmesini düşünmek önemli. Ehliyet veren, araçların kaydını yapan ve trafik kurallarının bilinmesini sağlayan kurumlar vardır.

Ancak aynı zamanda ceza kesen ve sisteme uymayan kişilerin rastgele ya da sistematik denetimlerle cezalandırılmasını sağlayan trafik ekipleri de vardır. İyi işleyen bir sistem için ikisine de ihtiyaç duyarsınız. Sadece ehliyet vermeyi, her aracı kaydetmeyi ve insanlara güvenli sürüşü öğretmeyi sağlayıp iyi bir sonuç bekleyemezsiniz.

Kontrol ve denge mekanizmalarına ihtiyacınız vardır.

Galen Low: Bunu gerçekten seviyorum. Şu anda özellikle teknik program yönetimi ve yazılım mühendisliği gibi pek çok farklı rolde büyük bir otomasyon yaşanıyor. İnsanların, tüm kuralların çerçevelerle ortaya konduğunu ve herkesin bunlara uyacağını söylediğini sıkça duyuyorum.

Sizin de belirttiğiniz gibi, hayır, insanların iyi yaptığı şey bu değil. Her zaman sorunlarla karşılaşan, bazen bilerek sistemi ihlal eden veya önceliklerin nerede olduğunu anlamayan insanlar olacak. Temelde süreci yönlendirecek birine de ihtiyaç var.

Eskisinden daha az olsa da bunun hâlâ bir değeri var. Bir yazılım ürününü teslim etmek için pek çok parçanın bir araya gelmesi gerekiyor ve bunların yalnızca bir bölümü kod kalitesiyle ilgili. Geri kalan her şey, doğru zamanda bir araya gelmesini sağlamak için gereken ekipler arası koordinasyon.

Bir yazılım mühendisleri ekibini yönetmekle dikkatiniz dağılırsa; bire bir görüşmeler yapmak, onların kariyer yöneticisi olmak, kod kalitesini denetlemek ve teknik sorunların çözümüne yardımcı olmak zorunda kalırsanız teslimat önceliğini korumak zorlaşır.

Bu noktada biraz uzaklaşıp daha geniş açıdan bakabiliriz. Dell ve Google gibi şirketlerde ve diğer büyük yazılım kuruluşlarında teknik program yöneticisi ekiplerine liderlik ettiniz. Bir yandan yazılım ekibi liderlerinin teknik sorunları çözdüğünü, diğer yandan teknik program yöneticilerinin de özellikle raporlama ve panolar sayesinde sorunları daha proaktif biçimde çözdüğünü konuşuyoruz.

Ancak burada bir boşluk var. Kodlama geçmişi olmayan bir teknik program yöneticisi hangi sorunları çözebilir? Teknik program yöneticilerinizden ne düzeyde teknik yetkinlik bekliyorsunuz? Yazılım mühendisleriyle çalışan her teknik program yöneticisinin hangi kavramları anlaması gerekir ve neden?

Satish Menon: Bu soru, şimdiye kadarki konuşmamızı genişleterek değinmek istediğim bir noktaya götürüyor. Bir yazılım yöneticisi ya da direktörü kendi kuruluşu içinde tamamen kapsanan projeleri yönetebilir. Ancak diğer ekiplere bağımlılığı olan daha büyük bir teslimat söz konusu olduğunda teknik program yöneticisi devreye girer.

Bu yalnızca mühendislikten ürün yönetimine, tasarıma, sahaya, pazara açılmaya ve teknik belgelere uzanan ekipler arası çalışma değildir. Yazılım teslimatının kendi içindeki, yani ekipler arasındaki bağımlılıkları da kapsar.

Bu önemli bir nokta. Bu konuşmadan, yazılım yöneticisinin veya direktörünün proje yönetimi yapmadığı sonucuyla ayrılmamalıyız. Proje yönetimi yaparlar; ancak tamamen kendi kuruluşlarının sınırları içinde kalan teslimatlar için yaparlar. Ekipler arası konularda ise tarafsız bir bakış açısına sahip teknik program yöneticisiyle çalışmak daha etkilidir.

Teknik yetkinlik düzeyine gelince, geçmişte kod yazmış veya kodlamaya geniş ölçüde maruz kalmış teknik program yöneticilerini kullanmayı ya da işe almayı tercih ederim. Çünkü bu kişiler mühendislerin dilini anlayabilir, onların saygısını kazanabilir ve onlarla daha iyi iş birliği yapabilir.

Kodun yaşam döngüsünü anlamıyorsanız eşit bir ortak olmanız zorlaşır. Kontrol noktalarının, işlem kayıtlarının, çekme isteği incelemesinin, inceleme döngüsünün, kod kalite analizinin ve statik analizin ne olduğunu bilmelisiniz.

Birim testi, sistem testi, entegrasyon testi, performans testi ve dağıtım arasındaki farkları anlamalısınız. Kodlama yaşam döngüsündeki çeşitli değişkenlerin inceliklerini bilmeniz gerekir. Daha önce kod yazdıysanız bunları zaten biliyor olursunuz.

İkinci teknik düzey, gönderdikleri ürünün ne olduğunu anlamaktır. Bazı teknik program yöneticileri teknik iş akışının üzerine yalnızca bir süreç yerleştirir; ancak geliştirilen yazılımın ne yaptığını gerçekten bilmez. Günümüzde birçok sistem yazılımı ve hizmet olarak yazılım ürünü, son müşteri açısından oldukça karmaşıktır.

Bunu anlarsanız yeni bir özellik istendiğinde ne geliştirildiğini ve ne gönderdiğimizi çok daha iyi anlarsınız. Ürün yöneticileri, tasarımcılar, yazılım mühendisleri, müşteri başarı yöneticileri ve sistem mühendisleriyle daha iyi konuşabilirsiniz.

Üçüncü düzey ise kendi betiklerinizi yazabilmek, Jira, Tableau, Sisense veya benzeri araçlarda kendi canlı panolarınızı oluşturabilmektir. Bir miktar betik yazabiliyor, doğru sinyalleri bulabiliyor ve başka neleri ölçmemiz gerektiğini anlayabiliyorsanız bu yararlı olur.

Bunlar da teknik becerilerdir; ancak doğrudan kod yazacak düzeyde olmanız gerekmez. Benim görüşüm bu yönde; elbette insanlar farklı düşünebilir.

Galen Low: Bunu gerçekten beğendim. Özellikle ilk söylediğiniz nokta önemli: Bu ikili bir durum değil. Yalnızca program yöneticilerinin program yönetimi yapabileceği ya da yazılım ekibi yöneticileri program yönetimi yapacağı için program yöneticilerinin ortadan kalkacağı doğru değil.

Bu kadar siyah beyaz değil. Arada kesinlikle bir ölçek var ve değişkenlerden biri karmaşıklık. Yalnızca ekibiniz içinde, fazla hareketli parça olmadan ve sisteminizi çok iyi bilerek yazılım teslim ediyorsanız, teslimat daha az karmaşık olur.

Çok zor olsa bile daha az karmaşıktır; çünkü bunlar bildiğiniz şeylerdir. Buna karşılık tedarikçileri, pazarlamayı ve çeşitli ürün paydaşlarını içeren son derece karmaşık proje ekosistemlerinde asıl değer, her şeyi bir araya getirmek ve karmaşıklığı yöneterek teslimatın gerçekleşmesini sağlamaktır.

Daha iyi konuşmalar temasını da seviyorum. Daha derin anlayış ve ortak bir kelime dağarcığı, insanlarla daha iyi iş birliği yapmayı sağlar. Ayrıca bugün teknik program yöneticisi rolü dâhil neredeyse tüm rollerin teknik bir boyutu olduğunu vurgulamanız önemli.

Bir rapor ya da pano oluşturma veya bir süreci otomatikleştirme duyarlılığına sahip olmanız gerekiyor. Ancak bu, işinizin bugün ya da geçmişte sürekli kod yazmayı gerektirdiği anlamına gelmiyor.

İş liderleri için sorayım: Bir kişinin daha derin bir anlayışa sahip olmasının veya ekiple daha iyi konuşmasının yatırım getirisi nedir? Bu sizin için neye dönüşüyor?

Satish Menon: Daha iyi konuşmalar daha fazla saygı getirir. Daha fazla saygı, stratejik tartışmaların yapıldığı daha büyük masalara davet edilmeniz anlamına gelir. Orada sizi uygulama tarafında stratejik bir ortak ve stratejinin iyi planlara dönüşmesini sağlayan biri olarak görürler.

Saygı kazanamazsanız, onların dilini ve derinliğini paylaşamazsanız, ürün yöneticileri ve mühendislik ekibi stratejiyi kendi aralarında belirler ve siz masada yer bulamazsınız.

Size bir plan verir ve “İşte plan, bunu takip etmenizi istiyorum” derler. Çünkü sizi oraya yerleştirirler. Onların sahip olduğu kelime dağarcığına sahip değilseniz size saygı duymazlar ve sizi masaya davet etmezler. Sadece takip eden kişi olursunuz.

Herkesin anlaması gereken önemli bir kavram var: Yazılım mühendisliğindeki yaşam teknik program yöneticileriyle başlamadı. Mühendislerle ve ürün yöneticileriyle başladı. Ürün yöneticilerinin fikirleri vardır; mühendislik ekipleri de onlarla iş birliği yaparak bunları hayata geçirir.

Bazen bir teknoloji yeniliği söz konusu olur. Bu durumda süreç mühendislerle başlar, ardından ürün yöneticileri dâhil olur ve teknoloji pazara sunulur. İlk ürün gönderildiğinde ortada henüz bir teknik program yöneticisi olmayabilir.

Ancak ekip büyümeye, girişim büyümeye başladığında daha büyük ekipler ve birden fazla mühendislik ekibi oluşur. Mühendislik ölçeklenmediği için ortak bir platforma ihtiyaç duyulur. Altı farklı dikeyin aynı platform üzerinde çalışması sağlanır ve mühendislik ekipleri arasında karşılıklı bağımlılıklar oluşur.

İşte o zaman “Buna bir teknik program yöneticisi atayalım; tüm bağımlılıkları takip edebilsin” dersiniz. Teknik program yönetimi oyunun başında değil, daha sonraki aşamalarında ortaya çıkan bir işlevdir.

Bu nedenle kuruluşun ilk teknik program yöneticisi olduğunuzda size ne yapacağınız ve nasıl yapacağınız söylenir. Zamanla etki yaratmaya başlarsınız. Yani sürece zaten gecikmeli bir noktadan girersiniz.

Siz geldiğinizde ürün yöneticileri ve mühendislik ekipleri uzun süredir konuşuyor, strateji oluşturuyor ve plan yapıyordur. Siz ise daha yeni katılmışsınızdır. Eşit bir ortak olabilmek için onların saygısını kazanmanız gerekir. Bu nedenle onların dilini bilmeniz çok önemlidir.

Bağımlılık yönetimi sizin temel işinizdir; ancak bundan çok daha fazlası da vardır.

Galen Low: Bunu seviyorum. Birincisi, partiye muhtemelen geç kaldığınızı unutmamalısınız. Alçakgönüllü biçimde girip sizden önce uzun süre nasıl çalıştıklarını anlamaya çalışmalısınız. Ancak bunun güçlendirici bir tarafı da var: Bu ekipler sizin yardımınız olmadan ölçeklenemez.

Sizin masaya getirdiğiniz değer, işler karmaşıklaştıkça, daha fazla ekip dâhil oldukça ve riskler yükseldikçe büyümelerini sağlayan bir kaldıraç olmanızdır. Stratejik ortak ifadenizi de beğendim. Teknik yetkinlikten söz ederken aslında her iki tarafın da dilini konuşmanız gerektiğini söylüyorsunuz.

Ürün de dâhil olmak üzere ekipler arası çalıştığınız tüm ekiplerin dilini bilmelisiniz. Yönetici katmanından baktığımda yöneticilerin stratejik ortak ifadesinden ne anladığını düşünüyorum. Teslimat tarafında yöneticilerden duyduğum en büyük şikâyet çoğu zaman insanların meseleyi anlamamış olması.

Bir şeyleri zamanında yapmaya çalışıyorlar ama yanlış bir şey gönderiyorlar. Ya da karşılarına çıkan fırsatı değerlendirmiyorlar. Bir ortaklığı derinleştirme veya müşteri için daha fazla değer sunma fırsatının yanından geçip gidiyorlar.

Dilini konuşmak, saygı kazanmak ve her iki tarafı da derinlemesine anlamak; gerçekten meseleyi kavrayan, teslim edilen şeyin vizyonunu savunabilen stratejik bir ortak olmanın mekaniklerini geliştirmek anlamına geliyor.

Bu, yalnızca görevlerin yapılıp yapılmadığını kontrol etmekten çok daha fazla değer yaratır. Bir planı uygulamakla kalmaz, değere daha hızlı ulaşmak için planın farklı biçimlerini de geliştirirsiniz.

Satish Menon: Burada birkaç nokta var. Birincisi, iş değerinden söz ettiniz. Yapay zekâ dünyasında sahip olduğumuz fırsatlardan biri, bir fikriniz varsa bunun titreşimsel kodlamayla hazırlanmış bir demosunu çok hızlı oluşturabilmeniz.

Bunu üç ila beş güvenilir ya da dost müşteriyle paylaşabilir ve geri bildirim alabilirsiniz. Eskiden müşteriye gösterebileceğiniz bir demoya ulaşmadan önce çok uzun süre kod yazmanız gerekirdi. Bu döngü o kadar yavaştı ki etkili değildi.

Şimdi hızlıca bir demo oluşturabilir, bunu Seismic’te araştırma ön izlemesi olarak adlandırdığımız biçimde müşterilere gösterebilir ve geri bildirim alabilirsiniz. Böylece nihai gereksinimleri geliştirebilir, ardından ürünü olgunlaştırıp genel kullanıma hazır hâle getirebilirsiniz.

Teknik program yöneticileri, daha yüksek değer elde etmek için araştırma ön izlemesi ve benzeri süreçlerin uygulanmasını sağlayabilir.

İkinci konu stratejik değer. Yönetici seviyesindeki yöneticinizle değer kattığınız noktalar konusunda uyumlu olmanız çok daha kolaydır. Ancak yeni bir üst düzey yönetici geldiğinde, onun ön kabulleri farklı olabilir.

“Bunca insanı neden barındırıyoruz? Burada ne yapıyorlar? Bunun değerli olduğunu düşünmüyorum” diyebilir. Bazen size kendinizi anlatmanız ve değerinizi göstermek için üç ay istemeniz fırsatı verilir. Bazen de böyle bir fırsat olmaz.

Bazı yöneticiler hemen değişiklik yapmak ister. Bunu kabul etmemiz gerekir. Bazen mücadele etme fırsatımız olur, bazen de onların düşünce biçiminin kurbanı oluruz.

Galen Low: Bu bölüm Fingerprint tarafından desteklenmektedir. Platformunuzdaki her ziyaretçi ilk bakışta aynı görünür. Ona güvenebilir misiniz, yoksa bir tehdit mi? Fingerprint; botları, yapay zekâ aracılarını, VPN’leri, tahrifat girişimlerini ve 100’den fazla benzersiz sinyali algılayarak gerçek zamanlı ve kalıcı risk puanlaması ile tehdit tespiti sağlar. İnsan ve aracı etkinliği iç içe geçse bile şüpheli trafiği daha hızlı belirleyebilir, daha güvenli ve korunaklı site ve uygulamalar oluşturabilirsiniz.

Her gün 6.000’den fazla şirket Fingerprint’e güveniyor. Siz de fingerprint.com adresinden katılabilirsiniz. Şimdi programa dönelim.

Araştırma ön izlemesi konusuna birazdan dönmek istiyorum; ancak şu anda, özellikle liderlik katmanında çok fazla değişim yaşandığına dair önemli bir noktaya değindiniz. Kuruluşun temel direklerinden biri değişiyor; üst düzey yöneticiler, dijital dönüşüm yöneticileri ve ürün yöneticileri geliyor.

Hızla işe alışmaları gerekiyor ama kendi fikirlerini getirmek için görevlendiriliyorlar. Bu nedenle hızlı hareket etmeleri gerekebilir.

Satish Menon: Evet, kesinlikle. Biz kesinlikle kuruluşun merkezinde değil, çevresinde görülebilen bir işleviz. Bunu ne kadar çabuk kabul eder ve uyum bulunan yerlerde değer katarsak kendimizle o kadar barışık oluruz.

Galen Low: O hâlde buradan ilerleyelim. Bazen kendinizi ve ekibinizi savunmak için çok kısa bir zamanınız olur. Teslimat başkanı olarak program yöneticilerinden oluşan ekibinizi yönetiyorsunuz ve yeni bir lider geliyor. Onun kendi ön kabulleri var.

Konuşmaya nasıl dâhil olursunuz ve ekibinizin kattığı değeri nasıl savunursunuz? Yapay zekânın yazılım geliştirme ve program yönetimini değiştirdiği bir dünyada ekibiniz için sunduğunuz argüman nasıl değişti?

Satish Menon: Yapay zekâ çağıyla geçmiş arasındaki temel fikir aynı. Ancak bu konuşmayı yapmak için artık farklı bir ölçüt kullanmam gerekiyor.

Geçmişte nasıl örgütlendiğimizi, durum güncellemelerini almak için panoları nasıl otomatikleştirdiğimizi, sorun çözme ve risk azaltmaya nasıl dâhil olduğumuzu anlatırdım.

Bugün ise bunları yapay zekâ dünyasına nasıl taşıdığımızı anlatmalıyım. Birden fazla sistem arasında bağlantı kuruyor, kötü bir sonuç ortaya çıktıktan sonra tepki vermek yerine kötü sonuçları önceden belirlemek için öncü göstergeleri arıyoruz.

Bunlar bizim öncü göstergelerimiz, güncel panolarımız ve birden fazla sistem arasında bağlantı kurma yöntemlerimiz. Teknik program yönetimi dünyasında yapay zekâyı mühendislikteki yapay zekâ kullanımını desteklemek için nasıl kullandığımızı ve ekibimizi bu yeni dünyaya nasıl uyarladığımızı gösteririm.

Değişim olduğunu öğrendiğim anda bu konuşmalar için fırsat ararım. Bazen kazanırım, bazen kazanamam. Sorun değil.

Galen Low: Bazı mücadeleler kazanılamaz. Özellikle değişiklik yapmak ve kârlılığı etkilemek için baskı altında olan bir yönetici söz konusuysa. Ancak burada sevdiğim şey, bunun aynı zamanda eğitici olması.

Rol artık insanların zihnindeki program yöneticisi imgesinden farklı. Değer artık yalnızca görevleri kontrol etmek değil; sorunları önlemek, riski yönetmek ve yüksek hızda iyi bir sonuç elde etmek.

Bu, yeni yönetici için de çok daha iyi bir başarı hikâyesi yaratır. Kimse işlerin kontrolden çıkmasını istemez. Tüm ekipleri bir araya getirip değere odaklanmalarını sağlamak ve program yönetimi ekibinin riski azaltmaya yardımcı olduğunu göstermek oldukça ikna edicidir.

Satish Menon: Kesinlikle. Bana göre yapay zekâ çağında doğru çalışma biçimine sahip, sağlam bir teknik program yönetimi ekibi herhangi bir programda, uygulamada veya operasyonel açıdan verimli ekipte risklerin öncü göstergelerini belirleyebilir.

Yaklaşan kötü sonucu önceden haber verir ve bunu azaltır. Aksi hâlde kötü sonuçların bedeli vardır; ancak geç kalınmış ve pahalı bir bedeldir.

Galen Low: Bu güzel bir geçiş oldu. Teknik program yöneticisinin rolü artık farklı. Bu, yapay zekâ ve yazılım geliştirmedeki değişikliklerden kaynaklanıyor; ancak birçok meslek gibi rol de doğal olarak gelişiyor.

Araştırma ön izlemesinden, titreşimsel kodlamadan, ürünle birlikte çalışmaktan ve sorunları önlemek için öncü göstergeler içeren panolar oluşturmaktan söz ettik. Üç ya da dört yıl öncesine kıyasla teknik program yöneticisinin rolü ne kadar değişti?

Satish Menon: Yazılım mühendisleri bugün 10, 100 kat daha hızlı çalışıyor. Bizim de aynısını yapmamız gerekiyor.

Manuel raporlar hazırlamayı ve manuel durum bilgisi toplamayı bırakmalıyız. Otomatik ve canlı panolara bakmadan kırmızı ve sarı göstergeleri değerlendirmeyi bırakmalıyız.

Örneğin Jira bir işin tamamlanmaya yaklaştığını söylüyorsa ancak GitHub ve Claude değerlendirmeleri bunu doğrulamıyorsa bu bir tehlike işaretidir. Kod yazımından kontrol noktalarına, işlem kayıtlarına ve çekme isteği incelemelerine kadar kodlama yaşam döngüsü Jira raporundan kopuk görünüyorsa risk erken ortaya çıkmıştır.

Test tarafında da BrowserStack’in kalite değerlendirmesi, buluta dağıtım, test ve hazırlık ortamı hakkında ne söylediğine bakmalısınız. Bu üç kaynağı birlikte incelediğinizde daha zengin bir değerlendirme elde edersiniz.

Tüm bu değişimlere ve yeni düşünme biçimlerine uyum sağlamazsanız bir noktada işlevsiz kalmayı hak ederiz. Ancak ayak uydurursanız hayatta kalanlar siz olursunuz.

Yazılım mühendisleri için de durum aynı. Yapay zekâyı yalnızca takıldıklarında yardım almak için kullanan ve işlerinin küçük bir bölümünü yapay zekâya dayandıran mühendislerin zamanı da sınırlı. Kodun büyük bölümü yapay zekâ tarafından üretilecek; insan denetimi ise doğru şeylerin yapılmasını ve önemli sınırların ihlal edilmemesini sağlayacak.

Teknik program yönetimi tarafında da aynısını yapmalıyız. Böylece yazılım mühendisliği ve teknik program yönetimi olarak birlikte işleri çok daha hızlı teslim edeceğiz. Yine de bu, her iki işlevin daha hızlı ve daha iyi çalışmak için hızlandığı bir ortaklık olmaya devam edecek.

Galen Low: Bu, ölçeklenmeyi ve değeri mümkün kılma fikrine geri dönüyor. Günümüzdeki çalışma biçimlerine ayak uyduramayıp darboğaz hâline gelmemeliyiz; aynı zamanda sürecin aktif bir katılımcısı olmalıyız.

Sistemler arasındaki tutarsızlıkları belirleme fikrini de seviyorum. Ekipler araçlarıyla birlikte çalışırken hâlâ erken aşamadayız ve risk yaratan tutarsızlıklar olabilir.

Bir teknik program yöneticisinin kodlama geçmişine sahip olması veya kod yazmasının beklenmesi gerekmiyor; ancak saygı kazanmak için yazılım geliştirme yaşam döngüsünü anlamalıdır.

Beklediğiniz sorun düzeyi nedir? Yalnızca ekipleri koordine edip aynı sayfada olmalarını sağlamak mı, yoksa daha derin sorun çözme becerileri mi?

Satish Menon: Bir ölçek var. Google’da çalışırken teknik program yöneticileri son derece teknikti ve daha fazla teknik sorun çözebiliyorduk. Ancak bu durum sektörde yaygın değil.

Tipik bir teknik program yöneticisi bir ekibin geride kaldığını gördüğünde yardım edilmesi gerektiğini anlayabilmelidir. Benzer kapasiteye sahip kardeş ekiplerin yardım edebileceğini fark etmeli ve bu fikri gündeme getirmelidir.

Bir platform ekibi gecikiyorsa ve belirli bir dikeyin sürümünü etkiliyorsa, ekip içindeki platform işlerinin yüksek öncelikli dikeyin zamanında gönderilmesini sağlayacak şekilde önceliklendirilmesi gerekir.

Bir ekibin sorunu varsa kimin yardıma çağrılabileceğini anlamak önemlidir. Mühendislik direktörüyle beyin fırtınası yapabilirsiniz. Mühendislik liderinin değerlendirmesine sunmak üzere özgün fikirler getirirseniz daha fazla saygı kazanırsınız.

En azından onların yükünden bir kısmını alırsınız. Doğru tarafları masaya getirir, yardım alınabilecek ekipleri belirlerseniz ve çözümün sonraki adımlarını çerçevelerseniz, onların daha az iş yaparak sonuca ulaşmasını sağlarsınız.

Benim pratikte gördüğüm değer bu. Bir grup mühendise gidip sorunu çözmek için tam olarak ne yapmaları gerektiğini söyleyen teknik program yöneticileri görmüyorum.

Galen Low: Daha derin anlayışın daha fazla değer yaratması, tekrar eden güçlü bir tema.

Başka bir ekibin doğru yeteneklere sahip olduğunu, uygun olduğunu ve çözüm olabileceğini biliyorsanız akıllı kaynak planlaması yapabilirsiniz. “Bu sizin sorununuz, cuma gününe kadar çözün” demek yerine iş birliği yapıp daha hızlı bir çözüme ulaşabilirsiniz.

Satish Menon: “Bu sizin sorununuz, çözün” deyip onları yalnızca bir tarihe karşı sorumlu tuttuğunuzda saygınız azalır. Ancak ne yaptıklarını yeterince biliyorsanız kaynak ataması açısından yüzde 70’lik çözümler veya yaratıcı yaklaşımlar sunabilirsiniz.

“Şöyle bir şey düşünüyorum; ancak bunun sahibi sizsiniz. İşinize yararsa kullanın, aksi hâlde başka bir yol bulun” diyebilirsiniz. Böylece en azından bazı önerilerle geldiğinizi takdir etmeye başlarlar.

Galen Low: Yüzde 70’lik çözümler ifadesini seviyorum. Tamamlanmamış, nihai olmayan ama başlangıç noktası sağlayan bir şey getirmek.

Satish Menon: Araştırma ön izlemesi için teknik program yöneticilerinin titreşimsel kodlama yapacağını kastetmedim. Bu daha çok bir süreç değişikliği. Ürün yöneticileri ve kıdemli mühendisler titreşimsel kodlamayı yapan kişiler olur. Teknik program yöneticileri ise süreci koordine eder, iyi müşteri demolarının hazırlanmasını sağlar ve gereksinimleri toplar.

Galen Low: Herkes daha hızlı hareket ediyor; özellikle yazılım mühendisliği tarafında 10, 50, 100 kat hızdan söz ediyoruz. Ancak birlikte hareket etmek de değerli. Ekipler daha verimli diye siloların artık var olmasına gerek kalmıyor.

Araştırma ön izlemesi mühendislik olmadan gerçekleşmez. Ürün yöneticileri de prototipleri çok hızlı oluşturabilir. Böylece herkes değeri anlayabilir, ilerlemeyi sürdürebilir ve paydaş uyumunu koruyabilir.

Satish Menon: Titreşimsel kodlama ve erken demoların, mühendislerin ürün yöneticilerinin veya ürün tasarım ekiplerinin fikirlerine dayanarak yaptığı kodlamalarla ortaya çıktığını gördüm.

İyi bir fikirleri olur, hızlıca titreşimsel kodlama yaparlar ve geçmişte yalnızca bir Figma tasarımına bakarak nasıl çalışacağını göstermeye çalıştığımız dönem geride kalır.

Galen Low: Teknik program yöneticileri kod yazmak zorunda değil; ancak yazılım geliştirme yaşam döngüsünü anlamaları ve kullanılan dili konuşmaları yararlı. İşe alım kararlarında buna nasıl yaklaşıyorsunuz? Daha önce geliştirici olarak çalışmış ve sonradan iyi bir program yöneticisine dönüşmüş birini mi, yoksa birleştirme isteğinin ne olduğunu bile bilmeyen uzun süreli bir program yöneticisini mi işe almayı tercih edersiniz?

Satish Menon: Daha önce kod yazmış teknik program yöneticilerinin daha iyi olduğunu düşünüyorum. Ancak istisnalar var. Kod yazanlarla uzun süre çalışan ve bu şekilde öğrenen teknik program yöneticileri de gördüm.

Bu nedenle özgeçmişte daha önce kod yazıp yazmadıklarını aramaktan çok sonucu değerlendiriyorum. Mühendislerin dilini etkili biçimde konuşabiliyorlar mı? Ürün yöneticilerinin ve tasarımcıların dilini konuşabiliyorlar mı? Ben bunları test ediyorum.

Nasıl öğrendikleri önemli değil. Önümdeki kişi bu dili konuşabiliyor ve gerekli anlayışa sahipse onu işe alırım.

Ancak bugün kodlama geçmişi olmayan bir teknik program yöneticisinin yazılım alanında çalışmaya başlayıp iş başında kodlama iş akışını öğrenme fırsatı çok az. On beş yıl önce donanım program yöneticisi olup bir yazılım projesine geçebilirdiniz. Bugün iş başında eğitim alacak kişilere tolerans çok düşük. Kuruluşlar hazır kişileri arıyor.

Galen Low: Bu çok gerçekçi bir bakış açısı ve piyasada duyduklarımla örtüşüyor. Birleştirme isteğinin ne olduğunu bilmiyorsanız iş bulamayacağınız anlamına gelmez; ancak kendinizi eğitmeye ve bu dili konuşmayı öğrenmeye hazır olmalısınız.

Satish Menon: Bunu 15 yıl önce yapabilirdiniz.

Galen Low: Artık roller ayrı görülmüyor. Birlikte çalışma düzeyi daha yüksek, teslimat baskısı daha yüksek ve hata yapmaya daha az yer var. 10, 50, 100 kat hızda kusursuz olmamız bekleniyor.

Satish Menon: Bazı şirketler ve işe alım yöneticileri yalnızca teknik olmayan durumsal sorular soruyor. Ben bunu yapmıyorum. Her görüşmede beklediğim teknik yetkinlikleri ölçmek için özel bir soru havuzu kullanıyorum.

Elbette soruları adaya ve özgeçmişindeki iddialara göre uyarlarım. Daha önce gönderdiği ürünlere ve sahip olması gereken teknik bilgiye göre, teknik yetkinliğinin sıfırdan 10’a kadar hangi düzeyde olduğunu belirlemeye çalışırım.

Bunun yanında insan ilişkileri ve duygusal zekâya yönelik durumsal sorular da sorarım. Google’da nesnel mülakat yöntemini öğrendim. Çok bilimsel ve nesnel bir işe alım süreciydi. Ben de bu yöntemi uyguluyorum.

Galen Low: Bunu seviyorum. Adaya göre hazırlanmış olması çok iyi. Belirli bir adayın teknik bilgisini ölçen durumsal bir soruya örnek verebilir misiniz?

Satish Menon: Örneğin bir aday hizmet olarak yazılım ortamında çalıştığını, daha hızlı teslimat için sürüm ortamını optimize ettiğini veya daha önce hizmet olarak yazılım ürünleri yayımladığını söylüyorsa, hizmet olarak yazılım teslimatının şirket içi kurulumlara kıyasla ne farkı olduğunu sorarım.

Hangi alanlarda şirket içi kuruluma kıyasla kısayollar kullandıklarını ve nedenlerini sorarım. Ayrıntılara iner, takip soruları sorarak hizmet olarak yazılım teslimatını ve ürünün nasıl çalıştığını ne kadar anladığını değerlendiririm.

Aday Disney veya Salesforce’ta yayımladığı bir üründen söz edebilir. O şirketlerin ürünlerini inceler, adayın yayımladığı özelliklerle ilgili sorular sorarım. Böylece yalnızca bir yazılım yaşam döngüsünün üzerine süreç yerleştirip neyin başlangıç olduğunu, neyin teslim edildiğini ve müşteriler için hangi değişikliğin yaratıldığını bilip bilmediğini anlarım.

Ayrıca kodlama tarafındaki yazılım yaşam döngüsü, DevOps, hazırlık ortamıyla gerçek üretim ortamı arasındaki fark ve güvenlik açıklarını önlemek için kullanılan korumalar hakkında temel sorular sorarım.

Galen Low: Bu konuşmaya teknik program yöneticilerinin değer yarattığı alanlarla bazı iş liderlerinin beklentileri arasındaki uyuşmazlıkla başladık. Bazı yöneticiler teknik program yöneticisi rolüyle yazılım mühendisliği ekip yöneticisi rolünün birleşmesini istiyor.

Geleceğe bakarsak ve bu hibrit rol yazılım geliştirmede baskın ekip yapısı hâline gelirse sizce etkisi ne olur? İki rolün ayrı kalması gerektiğine güçlü biçimde inanan liderler için bunun anlamı nedir?

Satish Menon: Bir topluluk olarak kontrol edebileceğimiz şeylere odaklanmalıyız. Kontrol edemeyeceklerimiz bizim elimizde değil.

Kontrol edebileceğimiz şey, bugünün araçlarının ürün teslimatına değer katmaya devam etmemizi nasıl sağladığıdır. Ekipler arası, çok ekipli ve disiplinler arası düşünmeliyiz.

Birden fazla işlevin bir ürünü teslim etmek için kesiştiği noktada en büyük değerimizi yaratıyoruz. İlk düzeyde birden fazla mühendislik ekibi vardır. Sonraki düzey mühendislik ve kalite mühendisliğidir. Daha sonra DevOps, teknik belgeler ve teslim edilmesi gereken diğer unsurlar gelir.

Ardından ürün kuruluşunun teslim ettikleriyle saha, müşteri başarı yöneticileri, satış mühendisleri, müşteri desteği ve müşterilere sunulan hizmetler arasındaki ekipler arası bağlantılar gelir. Lansman etkinlikleri ve pazarlama mesajları da buna dâhildir.

Tüm bu büyük resimde farklı işlevler rollerinin farklı bölümlerini yürütür. Siz de bunların tamamında koordinatör olma fırsatına sahip olursunuz.

Birden fazla şirket ve ortaklık arasındaki çalışmayı da düşünün. Bir şirket bir şey yayımlar, ancak bu başka bir ortak ürünle birlikte yapılan ortak bir lansmandır. Şirketler arası program yönetimi gerekir.

Araçların yapabildiği şeyleri ve bizim elimizde kalanları daha geniş düşünün. Bugün otomatik canlı panolar, birden fazla araç arasında bağlantı kurma ve yapay zekâ kullanımıyla ürün ve sorun çözme süreçlerine daha fazla dâhil olun.

Galen Low: Bunu gerçekten seviyorum. Merkezdeyiz. Bu rol merkezden çıkarılıp yalnızca yazılım mühendisliğine odaklanırsa tüm bu değeri kaybederiz.

Farklı ortaklar, ekipler ve disiplinler bir araya geldiğinde, değer kattığımız alan ölçek ve karmaşıklıktır. Bu nedenle rol ayrı kalmalıdır. Ancak bunun için derin bir anlayış gerekir. Yalnızca kutuları işaretleyip anlamadığımız ürünlerin üzerine çerçeveler yerleştiremeyiz.

Satish, bugün zaman ayırdığın için çok teşekkürler. Çok keyifliydi. Söylediklerinizi dinlemek isteyenler sizin hakkınızda daha fazla bilgi edinmek için nereye gidebilir?

Satish Menon: LinkedIn’de adımı aramanız yeterli.

Galen Low: Tekrar çok teşekkürler.

Satish Menon: Sizinle konuşmaktan büyük keyif aldım Galen. Bu fırsat için çok teşekkür ederim.

Galen Low: Pekâlâ arkadaşlar, Dijital Proje Yöneticisi Podcast’inin bu bölümü burada sona eriyor. Bu sohbeti beğendiyseniz dinlediğiniz platformda abone olmayı unutmayın. Daha fazla uygulamaya dönük içgörü, vaka çalışması ve uygulama rehberi istiyorsanız thedigitalprojectmanager.com adresinden ücretsiz bir hesap oluşturun.

Bir sonraki bölüme kadar, dinlediğiniz için teşekkürler.