Teknik Proje Yöneticisi Nedir?

Teknik Proje Yöneticisi (TPM) nedir? Deneyimli bir BT danışmanı ve iş operasyonları uzmanı olan Andi Blackwell, yanıtın kime sorduğunuza bağlı olduğunu söylüyor. Toptal'ın Proje ve Ürün Yönetiminden Sorumlu Lider Direktörü olarak Blackwell, Toptal'ın serbest çalışma ağındaki yüksek vasıflı proje yöneticilerini belirli girişimler için üst düzey yetenek arayan kuruluşlarla eşleştirmekten sorumlu ekibin başındadır. Son yıllarda, TPM'lere olan talepte bir artış gördü.

Blackwell, "Teknoloji endüstrisinde bu terimin gerçekte ne anlama geldiği konusunda kesinlikle bir tartışma var" diyor. “Bir mühendislik ekibiyle çok yakın çalıştıkları veya proje yönetimi perspektifinden bir teknik ekibi yönettikleri için kendilerine Teknik Proje Yöneticisi diyen birçok insan var, ancak aradığımız şey bu değil.”

Toptal'ın tanımı daha spesifiktir. Toptal'ın ağındaki tüm proje yöneticileri, kapsam belirleme, bütçeleme ve zaman çizelgelerini yönetme gibi geleneksel proje yönetimi becerilerinin yanı sıra yinelemeli teslimat ve sürekli iyileştirme ile ilgili Çevik yazılım geliştirme uygulamalarında uzmandır. Her zaman mühendislerle yakın bir şekilde çalıştılar ve istendiğinde bir Scrum ekibine koçluk ve rehberlik edebilirler.

Bununla birlikte, TPM'ler olarak kalifiye olmak için Çevik süreçleri yönetmenin ve geliştiricilerle işbirliğinin ötesinde ek bir deneyim katmanına sahip olmaları gerekir: Kendilerinin geliştirici olmaları gerekir.

Ödüllü Bir Kombinasyon

Büyük ve küçük kuruluşlar, bu özel beceri kombinasyonuyla giderek daha fazla ilgilenmektedir. Blackwell, “Çoğu startup, yalnızca tek bir şey yapabilen birini işe alamaz” diyor ve daha büyük şirketler, bir mühendislik projesi için işe alıyorlarsa adayın profilinde “geliştirici” veya “mimar” görmek istiyor.

Müşterinin teknik altyapıya sahip bir proje yöneticisine özel olarak ihtiyaç duymadığı durumlarda bile, "geliştirici" kutusunun işaretlenmesi önemli bir satış noktasıdır. Bir yazılım projesini planlayıp yürütebilen, Çevik süreçleri uygulayabilen ve optimize edebilen ve kod yazabilen biri mi? Bu büyük bir nimet.

Ancak gerçekte, TPM'lerin kodlaması beklenmemektedir; birçoğu yıllardır kodlama yapmamıştır. O zaman neden programlama deneyimine ihtiyaç duyuluyor?

Blackwell, teknik kararlar almak için TPM'lerin gerekli olduğunu söylüyor: "Modern bir teknoloji yığını, SDK (yazılım geliştirme kiti), mimari veya test otomasyon platformuyla ilgili en azından nispeten yeni uygulamalı deneyiminiz yoksa, o zaman siz' potansiyel olarak doğru kararları vermeyecektir. Müşteri nezdinde güvenilirliğiniz olmayacak çünkü bu şeyleri daha önce kullanmadınız.”

Ekiplerle Çalışmak

Muhtemel bir müşteriye güvenilirlik göstermek, sözleşmeleri güvence altına almak için önemli bir faktördür, ancak bu sadece ilk engeldir. Bir projeye atandıktan sonra, bir TPM teknik ekibin güvenini ve saygısını hızla kazanmalıdır.

Michael Poythress bir genç olarak programlamaya başladı. 16 yaşında, babasıyla birlikte başladığı bir emlak reklam işi için ticari bir web sitesi kurdu. O zamandan beri birden fazla girişimin CEO'su ve kurucusu oldu. 2018 yılında Toptal ağına TPM olarak katıldı ve şu anda mühendislik ekipleriyle yakın bir şekilde çalışıyor. "Kodlama konusunda hiç deneyimim olmasaydı, programcılar bunu anlarlardı" diyor. “Benimle doğrudan ateş etmezler. Ama onlara meydan okuyorsam ve onlarla bir akran olarak konuşuyorsam, orada saygı ve uyum var.”

Orange County, California'da bulunan bir Toptal TPM'den Allen Takatsuka, başlıktan daha önemli olanın teknoloji deneyimi olduğunu söylüyor: "Gördüğüm kadarıyla, TPM'deki 'T' mühendisler için gerçekten herhangi bir ağırlık taşımıyor. Toplantılarını ayarlayacak ve onlardan elektronik tabloları doldurmalarını isteyecek kişinin başka bir proje yöneticisi olduğunu düşünüyorlar.”

Ancak ortak bir zemin oluşturulduktan sonra, “etkileşimin tadı çok farklıdır. Daha çok mühendislikle bir ortaklık” diyor.

Takatsuka, profesyonel yaşamının başlarında mühendislik ekiplerine onlarca yıl liderlik etti. Yumuşak becerilerini geliştirdiği için bu deneyime güveniyor. “Bu biraz farklı bir empati becerisi” diyor. “Dili konuşabildiğini göstermelisin. 'Olan biten teknik şeylere dayanarak neden bu zorluklarla karşılaştığınızı anlıyorum' diyebilirsiniz.”

Viyana, Virginia'dan bir teknoloji danışmanı olan Dan Allen, kariyerindeki ilerlemeyi "mimar, direktör, Başkan Yardımcısı, CTO, CIO'ya teknik liderliğe kadar kabindeki adam programcısı" olarak tanımlıyor. Toptal ağına 2019'da TPM olarak katıldığından beri meşguldü ve 14 müşteri katılımı üzerinde çalıştı.

“Kodları nadiren okurum. Neredeyse hiç kod yazmam” diyor. “Ancak bir geliştiricinin takıldığı durumlar oldu. Mimaride bana rehberlik edebilirler ve tam olarak ne yapmaya çalıştıklarını ve mantığı görebiliyorum.”

Dinamiği yalnızca uç durumlarda değil, daha geniş anlamda faydalı buluyor. "Ekibiniz size gelip konuşabileceklerini biliyor ve siz onların ne dediklerini gerçekten anlıyorsunuz" diyor. “Bir şeyleri gözden kaçırmaları ihtimaline karşı tüm karmaşıklıkları düşünmelerine yardımcı olabilirsiniz. Bir seslendirme tahtası olabilir ve geri bildirim sağlayabilirsiniz.”

Çarpan Etkisi

Bu tür bir geri bildirim ve içgörü, ilişki kurmaktan daha fazlası için önemlidir. TPM'ler bir kuruluşa farklı bir değer teklifi sunar. Bilgi için kanal olarak daha az hizmet ederler ve daha çok bilgi kaynağı olarak hizmet ederler. Evet, planlar, koordine eder ve iletişim kurarlar, ancak aynı zamanda müşterilerin ve ekiplerin karmaşık teknoloji kararlarında çalışmasına yardımcı olurlar.

Takatsuka, "Teknik olarak fikir sahibi olma yeteneğiniz var" diyor. "Ve bu, organizasyona değer katıyor çünkü artık sadece organize etmek ve işbirliği yapmak yerine, daha çok çarpan etkisine sahip oluyorsunuz."

Takatsuka, TPM'lerin sorunları çözmek için daha az çemberden geçmesi gerektiğini belirtiyor. Özellikle daha büyük kuruluşlarda, teknik olmayan bir program veya proje yöneticisi, ilgili oyuncuları ve paydaşları belirleyerek, bağlam sunarak, bilgileri bir araya getirerek ve ardından bir karar vermek için sonuçları gözden geçirerek teknik bir zorluğa yaklaşabilir. TPM'ler kendi bilgilerini taşıyabilir.

Tokyo merkezli bir TPM olan Oana Ciherean, “Riskleri çok daha verimli bir şekilde ele alabilirsiniz” diyor. "Ve bu riskler pek çok yerden gelebilir. Takımın yanlış tahminlerinden gelebilirler. Yani, 'Tamam, bu kod parçasının yazılması bir hafta sürmeyecek' diyebilirsiniz çünkü gerçekten iki gün. Böylece aslında insanların engellemesini kaldırabilirsiniz. Çünkü takıldıklarını anladınız ve bu yüzden beş gün sürüyor. Bunu biliyorsun çünkü oradaydın ve kendi başına sıkışıp kaldın.”

Dengeyi Bulma

Ciherean kariyerine geliştirici olarak başladı ancak kısa süre sonra büyük resme dahil olma arzusuyla proje yönetimine geçti. Ancak bu rollerde kodlamayı özlediğini fark etti. Teknik Proje Yönetiminin her iki dünyanın da en iyisini sunduğunu söylüyor: "Teknolojide gerçekten uygulamalı olmama, aynı zamanda işi, müşterileri ve özelliklerde ne istediklerini anlama konusunda üst düzey olmamı sağlıyor."

Poythress de tatlı noktasını bulduğunu düşünüyor. “Ben bir fikre sahip olan vizyonerler ile onu nasıl oluşturacağını ve gerçekleştireceğini bilen teknik yetenek arasında bir çevirmen veya bir bağlantıyım” diyor. “Her iki dili de akıcı bir şekilde konuşuyorum. 'Normal insan' ve 'teknik-ese' konuşuyorum.”

Mini CTO

Yeni başlayanlar ve küçük işletmeler için çalışan TPM'ler, işletme ve teknolojinin kesiştiği noktada özellikle önemli bir yere sahiptir. Bu taahhütlerde, bir TPM genellikle bir projenin başlangıcında gemiye katılan ilk kişidir. Daha sonra, ürünün uygulanabilirliğini değerlendirmek, teknik kapsamı ve gereksinimleri tanımlamak ve müşterinin (bazen bir fikir fidesi olan tek bir kurucu) bir teknoloji yığını seçmesine, hizmet sunumu için satıcıları değerlendirmesine, DevOps en iyi uygulamalarını uygulamasına yardımcı olmaktan sorumludur. ve doğru takımı bir araya getirin.

Takatsuka, bu görevleri, TPM'nin işleri yerden almak için iş ve teknik alanlar arasında köprü kurduğu “mini CTO” rolleri olarak düşünüyor. Bazı müşteriler yazılım geliştirme hakkında neredeyse hiçbir şey bilmiyor, diyor ki: “Mağazayı nasıl kurarım? Agile hakkında okudum. Bunu nasıl yaparım?"

Poythress, iki rolü örtüşen, hatta bazı durumlarda birbirinden ayırt edilemez olarak görür. “Çok fazla çapraz tozlaşma var” diyor. "Daha küçük bir kuruluş için bir CTO, daha büyük bir kuruluşta üst düzey bir teknik PM rolüne kolayca geçebilir ve kendini evinde gibi hissedebilir."

Çevikliği Etkinleştirme

Çevik'in mekaniği, yazılım geliştirme deneyimi olan hemen hemen her proje yöneticisinin direksiyonundayken, teknik yeteneğe sahip biri, süreçleri yönetmeye daha incelikli bir bakış açısı getirebilir.

Ciherean, Çevik metodolojilerin asla kitap tarafından katı bir şekilde uygulanmadığını tespit eder; bir ekibin ve projenin özel ihtiyaçlarına göre özelleştirilmeli, karıştırılmalı ve uyarlanmalıdır.

“Süreç olarak tasarladığınız şeyin geliştiricilerin çalışmasını engellemediğinden ve aslında onu daha verimli veya üretken hale getirmediğinden emin olmalısınız” diyor. "Bazen bu, örneğin taahhütlerini nasıl yaptıklarını, kodları için nasıl dallar oluşturduklarını ve sürecinizin iş akışlarına uyup uymadığını görmek için GitHub iş akışının derinliklerine inmek anlamına gelir. Sonra ya prosesinizi düzeltirsiniz ya da iş akışını düzeltirsiniz.”

Bir TPM'nin uzmanlığı, ürün biriktirme listesi ve göreli boyut tahminleri gibi belirli Çevik yapı ve uygulamaları da bilgilendirebilir.

Takatsuka, "Tekniği anlıyorsanız, bir biriktirme listesindeki şeylerin kaba karmaşıklığını da bilirsiniz" diyor. “Aksi takdirde, sahip olduğunuz tek şey bu listedir ve bir numaranın iki numaraya kıyasla Büyük bir T-shirt bedeni olup olmadığını bilmek sizin için zor olurdu. Birinin daha zor olduğuna dair bir fikriniz olabilir, ancak perde arkasında ne olduğunu gerçekten bilmiyorsunuz. "Aşırı" bir TPM, diyor, "ekip gemiye girdiğinde kendi hızlarına sahip olacakları uyarısıyla, işleri kendi başına boyutlandırabilir."

Poythress, bir proje için düşündüğü teknik liderleri ve mühendisleri değerlendirmek için boyut tahmini anlayışını bir ölçü olarak kullanır. Bir şeyin küçük bir görev olmasını bekliyorsa ve başka biri onu dev olarak görüyorsa, bu bir kırmızı bayraktır: “Bilmediğim karmaşıklıklar olup olmadığını görmek için onları dinleyeceğim, ancak bu su tutmazsa, Ben de, 'Tamam, bu pek uygun değil' diyorum. Bunu gerçekten iyi anlayan ve basit olması gereken bir özellikten korkmayan birine ihtiyacımız var.”

TPM'ler ayrıca müşterileri işlevsel olmayan gereksinimler konusunda eğitmeye yardımcı olur. Yüksek kullanılabilirlik ile nasıl başa çıkıyorsunuz? Felaket kurtarma ile nasıl başa çıkıyorsunuz? Takatsuka, "Teknik anlayış olmadan, bu tartışmayı nasıl yaptığınızı bilmiyorum" diyor. “Muhtemelen Scrum gereksinimleri düzeyinde duracaksınız ve teknik insanlar gelene kadar bir gün arayacaksınız. Peki, o zaman bu büyük uçurum var.”

Güncel Tutmak

Klavye başında geçirdikleri zaman, bugün yaptıkları işte temel bir rol oynasa da, TPM'ler alakalı kalmak için geçmiş deneyimlerine güvenemezler. Teknolojinin değişme ve gelişme hızı göz önüne alındığında, geride kalmak kolaydır.

Poythress bunu, Toptal'a katılmadan önceki beş yıllık süreçte, yalnızca kendi şirketini yönetmeye odaklandığı zaman, zor yoldan öğrendi. “Kesinlikle durgunlaştım” diyor. "Birçok farklı dil ortaya çıktı ve o zaman diliminde hakkında hiçbir şey bilmediğim sorunları çözdü çünkü teknoloji yığınımız vardı ve tek ihtiyacımız olan buydu."

Bugün zamanının yüzde 10'unu dokümanları okuyarak, YouTube'u izleyerek ve "en yeni ve en harika şeyler hakkında bilgi edinmek için" korumalı alanda geçiriyor.

“Neredeyse her zaman yeni bir dil veya teknolojiyle uğraşıyorum, sırf zinde kalabilmek için,” diyor. “Çünkü yapmazsam, endüstri ilerleyecek. Bunu daha önce yaşadım. Ve ezberlemek, güncel kalmaktan çok daha zordur.”

Takatsuka, bilgi boşluklarını doldurma konusunda da proaktif: "Google bugünlerde harika. YouTube harika. Ödevini yapmak zorundasın. Ancak bu çalışma kendi üzerine inşa edilir. ”

Ayrıca, destek ve bilgi paylaşımı için geniş bir danışman danışman ağına da güvenmektedir. "Müşterinin Google'ı kullanmak istediği durumlarda bulundum, ancak AWS platformunu daha iyi tanıyorum" diyor. "Arkadaşlarımı arayabilir ve 'Hey, Firebase kullanacağız. Bunu yapan müşterileriniz oldu mu? Peki ya ölçeklenebilirlik?”

30 yılı aşkın bir süredir iş hayatında ve birden fazla yönetici düzeyinde görevde bulunmasına rağmen, Dan Allen ellerini kirletmekten korkmuyor. Son üç yılda, Amazon ve Google Cloud'da tek başına dağıtım yapmayı kendi kendine öğrendi. “Bunu anlayabilmek ve bir Toptal müşterisine yardım edebilmek için yaptım” diyor. “Teknoloji ekipleri yoktu. Sahip oldukları tek şey bendim. Bu yüzden YouTube Üniversitesi'ne gittim ve işi bitirdim."

Allen 1985'te bir geliştirici olarak başladığından beri çok şey değişti. Ama o, her yeni fırsatın getirdiği zorlukların tadını çıkarıyor. “İşle ilgili sevdiğim şeylerden biri de bu” diyor. "Her zaman yapmadığın bir şey vardır, yeni bir şey. Ve her zaman şapkanızda bir sonraki nişanda kullanabileceğiniz ek bir tüyle çekip gidersiniz.”