Bir PID Katsayısını Tartışabilen Proje Yöneticisi Neden Farklıdır?

Proje yönetimi literatüründe sık tekrarlanan bir cümle var: "Proje yöneticisinin teknik olması şart değildir; önemli olan süreci, insanı ve iletişimi yönetebilmesidir."

Bu cümlenin yarısı doğru. Ve yanlış olan yarısı, donanım ağırlıklı Ar-Ge programlarında projeleri sessizce raydan çıkaran şeydir.

Bu yazı, teknik derinliğin proje yönetiminde tam olarak nerede işe yaradığını, nerede zarar verdiğini ve doğru çizginin nereden geçtiğini anlatıyor.

Teknik olmayan yöneticinin görünmez maliyeti

Teknik olmayan iyi bir proje yöneticisi, bir projeyi baştan sona götürebilir. Bunu defalarca gördüm ve küçümsemiyorum. Ama ödediği üç maliyet var ve üçü de bilançoda görünmez.

Birincisi: tahminleri doğrulayamaz.

Bir mühendis "bu iş iki hafta sürer" dediğinde, teknik olmayan yöneticinin elinde iki seçenek vardır: inanmak ya da inanmamak. Teknik olan yöneticinin üçüncü bir seçeneği vardır: sormak. "İki haftanın ne kadarı asıl geliştirme, ne kadarı test? Test ortamı hazır mı? Şu bileşen gelmezse plan ne?"

Bu sorular tahmini doğrulamaz; tahmini iyileştirir. Ve çoğu zaman mühendisin kendisi de o soruları sorulduğunda ilk kez düşünür.

İkincisi: riski geç görür.

Projelerdeki en tehlikeli cümle "sorun yok, ilerliyoruz"dur. Teknik olmayan yönetici bu cümleyi duyduğunda elinde yalanlayacak bir şey yoktur. Teknik olan yönetici, aynı toplantıda ekibin hangi problemin etrafında dolandığını, hangi konuyu konuşmaktan kaçındığını sezer.

Risk yönetiminin en zor kısmı riski kaydetmek değil, riski henüz kimse söylemeden fark etmektir. Bu, tamamen alan bilgisine dayanır.

Üçüncüsü: ekibin güvenini kısmi kazanır.

Mühendisler, kendi işlerini anlamayan birine karşı kibar ama mesafeli olurlar. Rapor verirler, toplantıya gelirler, ama gerçekten ne düşündüklerini söylemezler. Teknik bir soruyu doğru soran yöneticiye ise bambaşka davranırlar, çünkü konuşmanın bir maliyeti olduğunu, birinin gerçekten dinlediğini anlarlar.

Ama "teknik proje yöneticisi" de bir tuzaktır

Madalyonun öbür yüzü daha az konuşulur ve en az onun kadar zarar verir.

Teknik geçmişten gelen yöneticinin en yaygın hatası, mühendisin işini yapmaya devam etmektir. Belirtileri tanıdıktır:

• Çözümü kendi kafasında kurup ekibe "şöyle yapın" demek
• Kod incelemesine, şematiğe, katsayıya kendini kaptırıp haftalık planı unutmak
• Bir teknik tartışmayı yönetmek yerine tartışmanın tarafı olmak
• Ekibin bulduğu çözüm kendi düşündüğünden farklı diye rahatsız olmak

Bu davranışların ortak sonucu şudur: ekip düşünmeyi bırakır. Neden düşünsün? Kararı zaten yönetici veriyor. Ve bir Ar-Ge ekibinin düşünmeyi bırakması, o projenin yaşayabileceği en kötü şeydir, çünkü en iyi ihtimalle projenin zekâsı bir kişinin zekâsıyla sınırlanır.

Teknik derinlik, karar verme yetkisi değildir. Soru sorma yetkisidir.

Doğru çizgi nereden geçer?

Kullandığım ölçü şu:

Kararı verecek kadar derin olmayacaksın, ama doğru soruyu soramayacak kadar da sığ olmayacaksın.

Somutlaştırayım. Bir uçuş kontrol ekibiyle yapılan toplantıda üç farklı yönetici, üç farklı cümle kurar:

Teknik olmayan yönetici: "Kontrolcü ne durumda?" → Cevap: "Üzerinde çalışıyoruz." Toplantı bitti, hiçbir şey öğrenilmedi.

Fazla teknik, sınırını bilmeyen yönetici: "D katsayısını 0.02'ye çekin, öyle daha iyi olur." → Ekip kendi ölçümüne değil, yöneticinin sezgisine göre çalışmaya başladı. Sorumluluk bulanıklaştı.

Doğru çizgideki yönetici: "Bu adım cevabındaki aşım kabul edilebilir mi, yoksa sönümlemeyi mi artıracağız? Artırırsak sensör gürültüsü nereye gider, onu ölçtük mü? Ölçmediysek, ölçmek ne kadar sürer?" → Ekip düşünmeye başladı. Karar hâlâ onların, ama artık verinin üzerine kurulacak.

Üçüncü cümleyi kurabilmek için PID kontrolcünün ne olduğunu, türev teriminin gürültüyü neden yükselttiğini bilmek gerekir. Ama D katsayısının ne olması gerektiğini bilmek gerekmez; zaten bilmemelisiniz de.

Fark bu: teknik derinlik cevabı bilmek için değil, sorunun doğru olduğunu bilmek içindir.

Bu derinlik nasıl korunur?

Teknik derinliğin en can sıkıcı özelliği, kullanılmadığında erimesidir. Yöneticiliğe geçtikten sonra hiçbir şey yapmazsanız, üç yıl içinde alan bilginiz "eskiden biliyordum" seviyesine iner ve bunu ekip sizden önce fark eder.

İşe yarayan üç yol:

Akademik bir bağ kurun. Yüksek lisans, tez, bir araştırma konusu. Sahadaki bilginin dağıldığı noktada teori ayakta tutar. Ben kendi tarafımda quadrotor enerji verimliliği için PID, Tip-1 Fuzzy-PID ve Interval Type-3 Fuzzy-PID denetleyicilerini 6-DOF simülasyon ve Betaflight SITL ortamında karşılaştıran bir tez çalışması yürütüyorum. Ve şunu net söyleyebilirim: haftada birkaç saat gerçek bir teknik problemin içinde kalmak, toplantılardaki bütün sorularımı değiştirdi.

Küçük ama gerçek bir şey yapın. Bir simülasyon kurun, bir veri setini kendiniz işleyin, bir prototipi kendiniz uçurun, bir parçayı kendiniz basın. "Yapabiliyor olmak" ile "yapıyor olmak" arasındaki fark, ekibin size nasıl davrandığında görünür.

Ekibinizden öğrenmeyi açıkça talep edin. "Bunu bana anlatır mısın, karar vermek için değil, anlamak için soruyorum" cümlesi kurulabilir bir cümledir ve otoriteyi zayıflatmaz; güçlendirir. Bilmediğini söyleyebilen yönetici, bildiğini iddia eden yöneticiden her zaman daha güvenilirdir.

Neden bu, bir pozisyon meselesi değil bir kalite meselesi

Sonuçta mesele "teknik yönetici mi, teknik olmayan yönetici mi" değil.

Mesele şu: Bir Ar-Ge programında verilen kararların büyük kısmı teknik ile takvim arasındaki takasla ilgilidir. "Bu doğrulamayı atlarsak iki hafta kazanırız ama şu riski alırız." Bu takası doğru yapabilmek, her iki tarafı da anlamayı gerektirir.

Sadece takvimi anlayan yönetici teknik borcu görmez, projeyi hızlı götürür ve duvara toslar. Sadece tekniği anlayan yönetici mükemmeliyetçiliğe kayar, proje bitmez.

İkisinin kesişiminde duran kişi azdır. Ve bu yüzden değerlidir.

---

Bu yazıdaki görüşler şahsıma aittir, çalıştığım kurumları bağlamaz.