Yazılım Projesinden Donanım Projesine Geçen Proje Yöneticisinin Kırılan Üç Varsayımı

Yazılım projelerinde bir "geri al" tuşu vardır. Kötü bir kararın maliyeti genellikle bir commit'i geri almak, bir sürümü rollback etmek, bir sprintin bir kısmını çöpe atmaktır. Bu kadar ucuz bir hata maliyeti, yazılım proje yönetiminin bütün pratiklerini şekillendirmiştir: hızlı iterasyon, erken ve sık teslim, geç bağlanan kararlar.

Donanım ağırlıklı bir Ar-Ge projesine geçtiğinizde bu tuş yoktur. Ve onunla birlikte, farkında bile olmadan taşıdığınız birkaç varsayım da kırılır.

Bu yazı, o kırılmanın envanteri.

Varsayım 1: "İterasyon ucuzdur, o yüzden çok iterasyon yapalım"

Yazılımda bir değişikliği denemenin maliyeti dakikalarla ölçülür. Bu yüzden yazılım metodolojileri "hızlı dene, hızlı öğren" üzerine kuruludur ve bu doğrudur.

Donanımda bir kart revizyonunun maliyeti tasarım süresi değil, tedarik süresidir. Yeni bir baskı devre kartı turu; şematik revizyonu, yerleşim, üretim, dizgi ve nakliye demektir. Kalıplı bir mekanik parçada süre daha da uzar. Kritik bir entegre devrenin temin süresi projenin tamamından uzun olabilir.

Sonuç şu: donanımda iterasyon sayısını değil, iterasyon başına öğrenmeyi maksimize edersiniz.

Bu, "az deneyin" demek değil. Tam tersi: denemeyi fiziksel donanımdan başka bir yere taşıyın demek. Simülasyon, donanımsız test ortamı (SITL), donanım-döngüde test (HIL) ve modelleme yatırımları donanım projelerinde bir lüks veya akademik süs değildir. Doğrudan bir takvim aracıdır. Simülasyonda yakaladığınız her hata, bir kart turu tasarruf eder.

Bir proje yöneticisi olarak bunun pratik karşılığı: simülasyon altyapısı için harcanan haftaları "asıl işe başlamadan önceki hazırlık" olarak değil, kritik yolu kısaltan yatırım olarak planlayın ve öyle savunun. Çünkü üst yönetime "üç hafta simülatör kuracağız" demek zordur; "üç haftalık simülatör yatırımı bize iki kart turu kazandıracak" demek kolaydır.

Varsayım 2: "Entegrasyon en sonda yapılır"

Yazılımda bileşenleri geç birleştirmenin maliyeti yönetilebilirdir; sürekli entegrasyon zaten bu riski dağıtmak için vardır.

Donanımda en pahalı hata sınıfı arayüz hatasıdır. İki alt sistem ayrı ayrı mükemmel çalışıp birbirine bağlandığında çalışmıyorsa, kaybettiğiniz şey bir hafta değil, iki alt sistemin de tasarım turu olur. Üstelik bu tür hatalar geç bulunur, çünkü ancak ikisi de hazır olduğunda ortaya çıkarlar.

Bunun panzehiri, sistem mühendisliğinin en sıkıcı ve en değerli belgesidir: Arayüz Kontrol Dokümanı (ICD). Mekanik, elektriksel, veri ve zamanlama arayüzlerinin, alt sistemler tasarlanmadan önce yazılıp dondurulması.

Ama belge tek başına yetmez. İşe yarayan pratik şu: arayüzü, arkasındaki sistem hazır olmadan test edin. Gerçek uçuş kontrol kartı yoksa onun yerine geçen, aynı protokolü konuşan bir taklit (stub) yazın. Gerçek sensör yoksa kaydedilmiş veriyi aynı formatta besleyen bir simülatör koyun. Amaç, entegrasyon gününü projenin sonundan alıp başına taşımaktır.

Yazılımcı bu fikre yabancı değildir; sadece adı farklıdır. Donanımda buna yatırım yapmayı öğrenmek gerekir.

Varsayım 3: "Kapsam esnektir, takvim sabittir"

Çevik yaklaşımların temel manevrası budur: takvim ve kaynak sabit, kapsam pazarlık konusu. Yetişmiyorsa kapsamdan kısarsınız.

Donanımda bu manevra çoğu zaman elinizde yoktur, çünkü kritik yol insanda değil, malzemededir. Uzun temin süreli kalemler (long-lead items) takvimi belirler ve bu kalemlerin siparişi, gereksinim tam olarak kesinleşmeden verilmek zorunda kalınır.

Bu, proje yönetimi açısından çok rahatsız edici bir gerçektir: bir kararı, onu vermek için gereken bilgiye sahip olmadan vermek zorundasınız. Yazılım dünyasının "son sorumlu ana kadar bekle" prensibi burada tersine döner; son sorumlu an, bilginin oluşmasından önce gelir.

Yapılabilecekler sınırlı ama gerçek:

• Uzun temin süreli kalemleri projenin ilk haftasında çıkarın. Kapsam netleşene kadar bekleyen bir tedarik planı, projenin takvimini sessizce yiyen şeydir.
• Bu kalemleri gereksinimden çok yeteneğe göre seçin. Nihai gereksinim belirsizse, marjı geniş olanı alın. Fazladan yetenek para, yetersiz yetenek zamandır ve zaman geri gelmez.
• Yanlış çıkma ihtimalini bütçeye yazın. "Bu siparişin yüzde otuz ihtimalle boşa gitmesini göze alıyoruz" cümlesini risk kaydına açıkça yazmak, aynı kararı sessizce vermekten çok daha savunulabilirdir. Kimse sizi hesaplanmış bir riski aldığınız için suçlamaz; kimse hesaplamadığınız bir riski affetmez.

Peki ne değişmiyor?

Bu farkların hepsi teknik ve tedarik kaynaklı. Proje yönetiminin insan tarafı değişmez ve orada yazılım dünyasından getirdikleriniz aynen geçerlidir:

• Paydaş beklentisini yönetmek hâlâ işin yarısıdır.
• Kötü haberi erken vermek hâlâ geç vermekten iyidir.
• Takımın moralini bozan şey zor iş değil, anlamsız iştir.
• Ölçmediğiniz şeyi yönetemezsiniz.

Aslında donanım projelerine geçen yazılım kökenli proje yöneticilerinin en büyük avantajı da budur: yazılım dünyası, iletişim ve geri bildirim döngüleri konusunda donanım dünyasından yıllarca öndedir. O kültürü donanım disiplininin içine taşıyabilen kişi, iki tarafın da en iyisini yapar.

Özet

• İterasyon ucuzdur. Donanımdaki karşılığı: İterasyon pahalıdır; öğrenmeyi simülasyona taşıyın
• Entegrasyon sonda yapılır. Donanımdaki karşılığı: Arayüz en pahalı hatadır; entegrasyonu başa çekin
• Kapsam esnektir. Donanımdaki karşılığı: Kritik yol malzemededir; kararı bilgiden önce vermeyi öğrenin

Donanım projeleri yazılım projelerinden daha zor değildir. Farklı yerlerde zordur. Zorluğun nerede olduğunu bilmeden yönetmeye kalkmak, projeyi değil kendinizi yorar.

---

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