Mühendislik Yönetimi ve Proje Yöneticiliği

Mühendislik yönetimi, teknik kararların yalnızca teknik doğrulukla değil; değer, zaman, maliyet, risk, kalite, insan kaynağı, mevzuat ve işletilebilirlik kısıtlarıyla birlikte yönetilmesidir. Proje yönetimi bu alanın önemli bir parçasıdır; ancak mühendislik yönetimi proje planının ötesine geçerek mimari kararların, teknik borcun, yaşam döngüsü maliyetinin, doğrulama stratejisinin, ekip yetkinliğinin ve operasyonel sürdürülebilirliğin de yönetilmesini kapsar.

Bir mühendislik yöneticisinin temel problemi “işleri takvime koymak” değildir. Asıl problem, belirsizlik altında doğru kararların zamanında alınmasını, kararların izlenebilir olmasını ve sistemin amaçlanan değeri güvenilir biçimde üretmesini sağlamaktır. Bu nedenle kapsam, takvim ve bütçe; mimari, kalite ve riskten bağımsız ele alınamaz.

Bu ders notu, 2023 tarihli çalışma materyalindeki proje yönetimi omurgasını korurken güncel proje yönetimi ve mühendislik yönetimi yaklaşımlarıyla yeniden sentezlenmiştir. PMI'nin Kasım 2025'te yayımlanan PMBOK Guide sekizinci baskısı, ISO 21502 proje yönetimi rehberi, güncel program/portföy ve kazanılmış değer standartları, Scrum Guide ve çevik ilkeler güncel çerçeve olarak kullanılmıştır.

Ünite 1: Mühendislik Yönetiminin Kapsamı

1.1. Proje, Operasyon, Program ve Portföy

Proje, benzersiz bir ürün, hizmet, sonuç veya değişim üretmek üzere yürütülen geçici bir girişimdir. Geçici olması sonucun kısa ömürlü olduğu anlamına gelmez; proje biter, üretilen sistem yıllarca işletilebilir.

Operasyon, tekrarlanan ve süreklilik gösteren değer üretim faaliyetidir. Üretim hattının işletilmesi, yazılım hizmetinin kesintisiz sunulması veya bir veri merkezinin işletilmesi operasyonel niteliktedir.

Program, ortak fayda ve bağımlılıklar nedeniyle birlikte yönetildiğinde tek tek yönetilmesinden daha fazla değer üreten ilişkili proje ve faaliyetler bütünüdür. Portföy ise kuruluşun stratejik amaçlarına hizmet eden proje, program ve diğer çalışmaların yatırım perspektifiyle birlikte yönetilmesidir.

Bu ayrım yalnız terminolojik değildir. Projede başarı ölçütü teslimat ve beklenen değerin gerçekleşmesi iken, operasyonda süreklilik ve hizmet seviyesi; programda birleşik fayda; portföyde ise stratejik yatırım dengesi öne çıkar.

1.2. Mühendislik Yönetimi ile Proje Yönetimi Arasındaki Sınır

Proje yöneticisi teslimatın koordinasyonuna odaklanabilir; mühendislik yöneticisi ise teknik kararların sonuçlarını da sahiplenmek zorundadır. Örneğin bir bileşenin hazır ürün mü yoksa kurum içinde geliştirilecek bir çözüm mü olacağı yalnız satın alma kararı değildir. Lisans maliyeti, güvenlik, gecikme, ölçeklenebilirlik, bakım yetkinliği, tedarikçi bağımlılığı ve yaşam döngüsü maliyeti birlikte değerlendirilir.

Mühendislik yönetiminin tipik karar alanları şunlardır:

• gereksinimlerin teknik olarak gerçekleştirilebilirliği,
• mimari ve teknoloji seçimi,
• doğrulama ve geçerleme stratejisi,
• güvenilirlik, emniyet ve güvenlik hedefleri,
• teknik borç ve bakım maliyeti,
• kapasite ve performans bütçeleri,
• üretme–satın alma kararları,
• sürüm ve konfigürasyon yönetimi,
• teknik risk ve fırsatlar,
• ekip yetkinliği ve kritik bilgi sürekliliği.

1.3. Başarı Üçgeninden Değer Sistemine

Kapsam–zaman–maliyet üçgeni proje kontrolü için yararlıdır; ancak tek başına başarıyı açıklamaz. Bir sistem zamanında ve bütçesinde teslim edilip kullanıcı ihtiyacını karşılamıyorsa proje yönetimsel açıdan “planla uyumlu” görünse bile başarısız olabilir. Benzer biçimde, kısa vadeli teslim baskısıyla bakım maliyeti ve güvenilirlik göz ardı edilirse görünür proje başarısı uzun vadede kurumsal maliyete dönüşebilir.

Bu nedenle modern yaklaşımda başarı; teslimatın yanı sıra değer, kalite, risk, paydaş sonucu, işletilebilirlik ve stratejik uyum ile birlikte değerlendirilir.

1.4. Proje ile Operasyonu Ayırmak

Proje ile operasyon arasındaki ayrım mühendislik yönetiminde bütçe, yetki ve başarı ölçütünü doğrudan değiştirir. Proje; benzersiz bir ürün, hizmet veya sonuç üretmek üzere geçici olarak kurulan çalışmadır. Operasyon ise tekrarlanan değerin sürekliliğini sağlar.

Aynı sistem iki farklı bağlamda görülebilir:

yeni üretim hattının tasarlanması -> proje
üretim hattının günlük işletilmesi -> operasyon

yeni yazılım sürümünün geliştirilmesi -> proje
canlı hizmetin nöbet ve bakım faaliyeti -> operasyon

Projenin tamamlanması operasyonun başarısını garanti etmez. Teslim edilen ürünün işletilebilirlik, bakım, eğitim, yedek parça, gözlemlenebilirlik ve destek modeli düşünülmemişse “zamanında ve bütçesinde” biten proje kurumsal açıdan başarısız olabilir.

Ünite 2: Değer, Yönetişim ve Projenin Başlatılması

Proje başlatılmadan önce çözülmek istenen ihtiyaç ve bu ihtiyacı gösterecek ölçülebilir sonuç belirlenir. Alternatif projeler yalnız beklenen getiriye göre değil, bağımlılık, kapasite ve risk açısından da karşılaştırılır. İş gerekçesindeki varsayımlar uygulama sırasında gözlenen verilerle sınanır; geçerliliğini kaybeden varsayımlara rağmen başlangıç planını aynen sürdürmek zorunlu değildir. Başlatma kararı, kapsamı belirsiz bir onaydan çok sorumluluk ve başarı ölçütü tanımlayan bir yönetim kararı olmalıdır.

2.1. İş Gerekçesi ve Değer Hipotezi

Bir proje “yapılabiliyor” olduğu için değil, anlamlı bir problem veya fırsata karşı ölçülebilir değer ürettiği için başlatılmalıdır. İş gerekçesi; problemin tanımını, seçenekleri, beklenen faydayı, toplam maliyeti, temel riskleri ve vazgeçme maliyetini açıklar.

Teknik ekip açısından yararlı bir başlangıç sorusu şudur:

Problem -> Beklenen sonuç -> Ölçülebilir fayda -> Teknik seçenek -> Risk -> Karar

Çözüm seçimi problem tanımından önce yapılırsa proje, ihtiyaca çözüm aramak yerine seçilmiş teknolojiye kullanım alanı aramaya başlayabilir.

2.2. Proje Başlatma Belgesi

Proje başlatma belgesi; projenin varlık nedenini, üst düzey hedeflerini, ana paydaşlarını, yetki sınırlarını, temel kısıtlarını ve proje yöneticisinin yetkilendirilmesini ortaya koyar. Ayrıntılı plan değildir. Belirsizliği tamamen ortadan kaldırmayı değil, çalışmayı meşru ve yönlendirilebilir hâle getirmeyi amaçlar.

Mühendislik projelerinde bu belgeye aşağıdaki teknik çerçevenin eklenmesi yararlıdır:

• sistem sınırı ve temel arayüzler,
• kritik kalite öznitelikleri,
• regülasyon ve uyumluluk kısıtları,
• kabul ölçütlerinin üst düzey tanımı,
• kritik bağımlılıklar,
• mimari karar gerektiren yüksek belirsizlikler.

2.3. Yönetişim

Yönetişim, kararların kimin tarafından, hangi yetkiyle, hangi kanıta dayanarak ve hangi eskalasyon mekanizmasıyla alınacağını tanımlar. Yönetişim ile günlük yönetim aynı şey değildir. İyi yönetişim, ekibin her karar için kurul beklemesi anlamına gelmez; aksine karar haklarını açıklaştırarak karar gecikmesini azaltır.

Teknik kararlarda karar sahibinin, danışılan kişilerin ve yalnız bilgilendirilecek tarafların ayrıştırılması; sorumluluğun dağılmasını önler. Kritik mimari veya güvenlik kararlarında karar kaydının gerekçesiyle birlikte saklanması, daha sonra “neden böyle yapılmıştı?” sorusuna ölçülebilir yanıt verir.

2.4. Proje Başlatma Aşamasının Gerekçeleri

Başlatmada teknik çözümden önce problem ve değer tanımlanır. İş gerekçesi şu soruları kapsar:

• hangi ihtiyaç veya fırsat var?
• hedeflenen sonuç nedir?
• başarının ölçüsü nedir?
• ana varsayımlar/kısıtlar nelerdir?
• sponsor kimdir?
• proje yöneticisinin yetkisi nedir?
• yüksek seviye riskler nelerdir?

Proje başlatma belgesi (charter), proje yönetim planı değildir. Projeyi ve proje yöneticisinin yetkisini resmen başlatır; ayrıntılı kapsam/takvim sonradan geliştirilir.

2.5. Planlama Tek Belge Üretmek Değildir

Planlama; kapsam/WBS, ağ diyagramı, kaynak-maliyet ve risk gibi birbirine bağlı eksenleri içerir. Pratikte proje yönetim planı, birbirine bağlı alt planlardan oluşur. Kapsam değişirse faaliyetler, kaynaklar, maliyet, risk ve tedarik de değişebilir.

Planlama çıktıları birbirinden bağımsız Excel dosyaları değil, aynı modelin farklı görünümleridir:

gereksinim
  ↓
teslimat / WBS
  ↓
faaliyet
  ↓
bağımlılık + süre
  ↓
kaynak
  ↓
maliyet
  ↓
risk ve rezerv

Ünite 3: Yaşam Döngüsü, Uyarlama, Çevik ve Hibrit Teslimat

3.1. Öngörücü, Çevik ve Hibrit Yaklaşımlar

Öngörücü yaklaşım, kapsamın önemli ölçüde önden belirlenebildiği, değişiklik maliyetinin yüksek olduğu veya düzenleyici izlenebilirliğin güçlü biçimde gerektiği işlerde etkilidir. Uyarlanabilir/çevik yaklaşım, gereksinimlerin keşif yoluyla olgunlaştığı ve kısa geri bildirim çevrimlerinin değer sağladığı ortamlarda öne çıkar. Hibrit yaklaşım iki uç arasında rastgele bir karışım değildir; farklı iş parçaları için farklı kontrol modellerinin bilinçli seçimidir.

Örneğin donanım üretiminin uzun tedarik süreleri öngörücü planlama gerektirirken, kullanıcı arayüzü iteratif geliştirilebilir. Aynı proje içinde mimari kilometre taşları sabit tutulup uygulama özellikleri artımlı teslim edilebilir.

3.2. Uyarlama

Bir metodolojinin tüm törenlerini veya belgelerini mekanik biçimde uygulamak olgunluk göstergesi değildir. Süreç; risk, ürün tipi, ekip büyüklüğü, mevzuat, dağıtım sıklığı ve paydaş yapısına göre uyarlanmalıdır.

Uyarlama için şu sıra yararlıdır:

Bağlam -> Risk -> Zorunlu kontroller -> Geri bildirim ihtiyacı -> Süreç seçimi -> Ölçüm

Süreç, ölçülebilir bir probleme cevap vermiyorsa ek işlem yükü üretir. Bunun tersi de geçerlidir: “çeviklik” gerekçesiyle güvenlik incelemesi, izlenebilirlik veya doğrulama gibi zorunlu kontrollerin kaldırılması çeviklik değil kontrol kaybıdır.

3.3. PMBOK Sekizinci Baskısının Yönelimi

PMBOK Guide sekizinci baskısı, proje yönetimini altı temel ilke ve yedi performans alanı etrafında ele alır; yönetişim, kapsam, takvim, finans, paydaş, kaynak ve risk eksenlerini pratik odakla bütünleştirir. Yapay zekâ, PMO ve tedarik gibi güncel bağlamların genişletilmesi, proje yönetiminin yalnız süreç ezberine indirgenemeyeceğini vurgular.

Daha eski PMBOK sürümlerindeki süreç grupları ve bilgi alanları tarihsel olarak önemlidir ve hâlen birçok kurumun çalışma dilinde bulunur. Ancak güncel uygulamada süreç listesini takip etmekten çok, hangi yönetim sonucunun hangi bağlamda üretileceği önemlidir.

3.4. Çeviklik bir Teslimat Amacı Değil Geri Bildirim Yeteneğidir

Çevik Manifesto, insan ve etkileşimleri, çalışan ürünü, müşteri iş birliğini ve değişime yanıtı vurgular. Bu, planlama veya dokümantasyonun değersiz olduğu anlamına gelmez; bağlama göre daha değerli olanı öne çıkarmaktır.

Çevik çalışmanın ana mühendislik kazancı, karar ile kanıt arasındaki çevrimi kısaltmasıdır. Küçük artımlar, otomatik test ve sık entegrasyon; hatalı varsayımın maliyetini düşürür.

3.5. Scrum

Scrum'ın güncel resmî kılavuzu Kasım 2020 sürümüdür. Scrum; Product Owner, Scrum Master ve Developers rollerinden oluşan Scrum Team; Product Backlog, Sprint Backlog ve Increment eserleri; Sprint, Sprint Planning, Daily Scrum, Sprint Review ve Sprint Retrospective etkinlikleriyle ampirik bir çalışma çerçevesi sunar.

Scrum'ı yalnız günlük toplantı ve iki haftalık takvim olarak uygulamak, çerçevenin şeffaflık–denetim–uyarlama mantığını kaybettirir.

3.6. Kanban

Kanban yaklaşımında iş akışı görselleştirilir, devam eden iş (WIP) sınırlandırılır ve akış metrikleri izlenir. Çevrim süresi, iş bitirme hızı ve darboğazlar; kapasite planlamasına veri sağlar.

WIP sınırı, ekibi meşgul tutmak yerine işi bitirmeyi optimize eder. Çok sayıda paralel iş, bağlam değiştirme maliyetini ve bekleme süresini artırabilir.

3.7. Hibrit Model

Hibrit çalışma, “Scrum yapıyoruz ama tüm kararlar yıllık planda sabit” gibi etiket birleşimi değildir. Hangi katmanda öngörücü, hangi katmanda uyarlanabilir kontrol kullanılacağı açıkça belirlenmelidir. Donanım tedariki, mevzuat onayı veya bütçe kapıları öngörücü; yazılım özelliği geliştirme ve kullanıcı doğrulaması iteratif olabilir.

3.8. Proje Yaşam Döngüsü ve Yönetim Süreçleri

PMI'nin tarihsel süreç grubu yaklaşımı başlatma, planlama, yürütme, izleme-kontrol ve kapanış olarak bilinir. Güncel standartlar daha esnek ve değer odaklı olsa da bu beşli model işin zaman içindeki yönetim mantığını öğretmek için hâlâ değerlidir.

başlatma
   ↓
planlama ←────────┐
   ↓              |
yürütme           |
   ↕              |
izleme/kontrol ───┘
   ↓
kapanış

Bu şekil ardışık waterfall aşamalarını göstermez. İzleme ve kontrol yürütmeyle eş zamanlıdır; planlama proje boyunca yeni bilgi geldikçe güncellenebilir.

3.9. Çevik Yaklaşımın Sınırı

Çevik, plansızlık değildir. Kısa geri bildirim döngüsü ve değişen gereksinime ekonomik yanıt üretme yaklaşımıdır. Regüle veya donanım ağırlıklı projelerde tüm teslimatı Scrum'a çevirmek yerine yazılım alt sistemi iteratif, fiziksel entegrasyon milestone tabanlı yönetilebilir.

3.10. Scrum Roller ve Olaylar

Scrum'da temel roller Product Owner, Scrum Master ve Developers olarak tanımlanır. Sprint, Sprint Planning, Daily Scrum, Sprint Review ve Sprint Retrospective düzenli geri bildirim noktalarıdır. Backlog önceliği proje WBS'siyle birebir aynı şey değildir; farklı amaçlara hizmet eder.

3.11. Kanban ve Akış

Kanban'da iş akışı görünür yapılır, WIP sınırları konur ve lead time/throughput izlenir. WIP sınırı işi yavaşlatmak için değil, gizli kuyruğu görünür kılmak için kullanılır. Çok sayıda “başlanmış ama bitmemiş” iş teslimat hızını düşürebilir.

3.12. Kullanıcı İhtiyacına Dayalı İş Önceliklendirme

Bir ürün geri listesini yalnız "kim daha yüksek sesle istedi?" veya "hangi iş daha kolay?" sorusuyla sıralamak, sınırlı mühendislik kapasitesini rastlantısal kullanır. Daha tutarlı yaklaşım, kullanıcı etkisini birkaç görünür boyuta ayırmaktır.

Basit bir değerlendirme şu üç soruyla başlayabilir:

kapsam   -> kaç kullanıcı / rol etkileniyor?
sıklık   -> sorun veya ihtiyaç ne kadar sık ortaya çıkıyor?
şiddet   -> gerçekleştiğinde görevi ne ölçüde bozuyor?

Bu boyutlar düşük, orta ve yüksek gibi küçük bir ölçekle puanlanabilir. Amaç matematiksel kesinlik üretmek değil, farklı ekip üyelerinin aynı kararı benzer gerekçeyle verebilmesini sağlamaktır.

Örneğin:

değer göstergesi
≈
kapsam × sıklık × şiddet

ardından geliştirme maliyeti, süre, risk ve bağımlılıklar ayrıca değerlendirilir. "Değer / maliyet" türü oranlar işe yarar; fakat ön koşul ve güvenlik kapılarını ezmemelidir. Bir mimari bağımlılık çözülmeden yüksek puanlı görünen yüzey iyileştirmesini öne almak, yerel optimizasyon olabilir.

Önceliklendirmede üç hata yaygındır:

• çok fazla ölçüt ekleyip puanı açıklanamaz hâle getirmek,
• küçük sayıları gerçek kesinlik sanmak,
• bağımlılık ve zorunlu kontrolleri skorun içine gömerek görünmez kılmak.

İyi rubrik kısa olmalı, kararın nedenini görünür kılmalı ve yeni kanıt geldiğinde değiştirilebilmelidir.

3.13. Üretim Geri Bildirimini Sürekli İyileştirme Döngüsüne Bağlamak

Ürün yayına çıktığında geliştirme bitmez; yalnız veri kaynağı değişir. Gerçek kullanım, hangi gereksinimlerin eksik anlaşıldığını ve hangi tasarım kararlarının sürtünme ürettiğini gösterir.

Yönetilebilir bir iyileştirme döngüsü:

gözle
 -> sınıflandır
 -> benzer sorunları kümele
 -> önceliklendir
 -> düzelt
 -> regresyonla doğrula
 -> yayımla
 -> yeniden gözle

şeklinde kurulabilir.

Bu döngüde tek tek kullanıcı şikâyetlerini doğrudan geliştirme işine çevirmek yerine kök neden aranır. Aynı yanlış anlama elli kez görülüyorsa elli ayrı iş değil, bir ortak tasarım veya mimari kusur olabilir.

İyileştirme süreci geliştirme akışından bağımsız da düşünülmemelidir. Çok sayıda küçük düzeltmenin aynı anda açılması WIP'i büyütür ve geri bildirim süresini uzatır. Teknik borç, hata düzeltme, kullanılabilirlik iyileştirmesi ve yeni özellik aynı kapasite havuzunda görünür olmalıdır.

Üretim verisinin değeri, sürekli değişiklik yapmak değildir. Kararlı davranış da bir kalite özelliğidir. Bu nedenle her değişiklik:

• gözlenen bir probleme dayanmalı,
• açık bir başarı ölçütüne sahip olmalı,
• regresyon etkisi değerlendirilerek yayımlanmalı,
• gerekirse geri alınabilmelidir.

Sürekli iyileştirme, sürekli oynatma değil; kanıt geldikçe sistemi küçük ve doğrulanabilir adımlarla daha iyi hâle getirme disiplinidir.

3.14. Hibrit Yönetim

Hibrit model “yarısı waterfall yarısı agile” demek değildir. Her bileşenin belirsizlik, geri bildirim süresi ve bağımlılığına göre farklı yönetim yaklaşımı seçilebilir. Örneğin sertifikasyon milestone'ları öngörücü, kullanıcı arayüzü iteratif, altyapı otomasyonu Kanban ile yönetilebilir.

Ünite 4: Gereksinim, Kapsam, WBS ve İzlenebilirlik

Kapsam yönetiminde önce her gereksinimin hangi teslimata karşılık geldiği belirlenir. İş kırılım yapısındaki paketler çıktıya dayalı tanımlanır; bir paketin tamamlanma ölçütü gözlenebilir olmalıdır. Değişiklik talebinde hangi gereksinim ve bağımlılıkların etkilendiği izlenir, ardından takvim ve maliyet etkisi yeniden hesaplanır. Yalnız daha çok görev tamamlamak ilerleme değildir; kabul edilmiş çıktılarla ilişkilendirilmeyen faaliyet gerçek kapsam başarısını göstermeyebilir.

4.1. Gereksinimden Kapsama

Gereksinim, çözümün sağlaması gereken doğrulanabilir ihtiyaç veya kısıttır. Kapsam ise projenin hangi ürünü ve hangi işi teslim edeceğinin sınırıdır. İki kavram karıştırıldığında, “müşterinin istediği her şey” proje kapsamı gibi algılanabilir.

İyi bir gereksinim mümkün olduğunca tek anlamlı, doğrulanabilir, gerekli, izlenebilir ve uygulanabilir olmalıdır. Özellikle performans ve güvenilirlik gereksinimleri “hızlı”, “yüksek erişilebilir” gibi ölçülemeyen sıfatlarla bırakılmamalıdır.

4.2. İş Kırılım Yapısı

İş kırılım yapısı (Work Breakdown Structure, WBS), proje kapsamını yönetilebilir teslimat ve iş paketlerine hiyerarşik olarak ayrıştırır. WBS bir organizasyon şeması veya yapılacaklar listesinden ibaret değildir; kapsamın tamamını temsil eden bir ayrıştırma modelidir.

Sistem
+-- Alt Sistem A
|   +-- Teslimat A1
|   +-- Teslimat A2
+-- Alt Sistem B
    +-- Teslimat B1
    +-- Entegrasyon

%100 kuralı, üst seviyedeki kapsamın tamamının alt öğelerde temsil edilmesini; kapsam dışı işin ise ağaca sızmamasını hedefler.

4.3. Kapsam Kayması ve Değişiklik Kontrolü

Kapsam değişikliği her zaman kötü değildir. Problem, değişikliğin etkisi ölçülmeden ve karar kaydı olmadan sisteme eklenmesidir. Değişiklik isteği en az şu etkilerle değerlendirilmelidir:

• değer ve öncelik,
• takvim,
• maliyet,
• teknik mimari,
• test ve doğrulama,
• güvenlik ve mevzuat,
• işletme ve bakım.

Değişiklik kurulu, her küçük değişiklik için bürokratik engel oluşturmak yerine yüksek etkili değişikliklerde karar bütünlüğü sağlamalıdır.

4.4. Gereksinim Mühendisliği ile Proje Kapsamı İlişkisi

Gereksinim “paydaş neye ihtiyaç duyuyor?”, kapsam ise “proje bu ihtiyacın hangi kısmını hangi teslimatlarla karşılayacak?” sorusudur. Gereksinim listesi doğrudan WBS değildir.

Gereksinim izlenebilirlik matrisi şu zinciri kurabilir:

R-17 gereksinimi
 -> tasarım bileşeni A
 -> WBS 2.3.4
 -> test T-81
 -> kabul kriteri AC-12

Bu zincir değişiklik etkisini ve eksik doğrulama riskini görünür yapar.

4.5. Kapsam Bildirimi, WBS ve WBS Sözlüğü

WBS ürün veya teslimat odaklı olarak işi yönetilebilir parçalara ayrıştırır. En alt yönetilebilir parça çoğunlukla çalışma paketidir. WBS'nin amacı görev listesini sonsuza kadar küçültmek değil, planlama ve kontrol için yeterli sahiplik noktaları oluşturmaktır.

WBS sözlüğü her çalışma paketinin kapsamını, sorumlusunu, kabul ölçütünü, varsayımını ve ilişkili kontrol hesabını açıklayabilir. “Yazılım geliştirme” gibi dev bir çalışma paketi kontrol edilebilir değildir; “ekranları kodla” gibi düşük seviye faaliyetleri WBS'ye taşımak da yapıyı gereksiz ayrıntılandırabilir.

4.6. %100 Kuralı

İyi bir WBS, proje kapsamındaki işin tamamını kapsar ve kapsam dışı işi içermez. Üst öğenin kapsamı alt öğelerin toplamıyla temsil edilir. Yönetim işi, entegrasyon, test, dokümantasyon ve geçiş gibi “ürünün parçası değil” görünen işler de proje için gerekliyse WBS'de görünür olmalıdır.

4.7. Kapsam Doğrulama ve Kapsam Kontrolü

Kapsam doğrulama, tamamlanmış teslimatın müşteri/sponsor tarafından resmî kabulüne odaklanır. Kalite kontrol ise teslimatın teknik kriterleri karşılayıp karşılamadığını değerlendirir. Aynı şey değildir.

Kapsam kontrolü, scope creep'i engeller ve onaylı değişikliklerin baseline'a işlenmesini sağlar. “Müşteri istedi, iki saatlik iş” gerekçesi değişiklik sürecini atlamak için yeterli değildir; küçük değişikliklerin toplam etkisi büyük olabilir.

4.8. Gereksinimden Kapsam Tabanına İzlenebilirlik

Mühendislik projelerinde kapsam hatasının önemli bölümü “ne teslim edeceğiz?” sorusunun gereksinim, tasarım, iş paketi, test ve kabul arasında kopmasından doğar. Gereksinim yönetimi ile proje kapsam yönetimi farklı disiplinlerdir; ancak birbirine bağlanmadığında planın tamamlanması ürünün doğru olduğu anlamına gelmez.

4.9. Gereksinim Sınıfları

Gereksinimler farklı soyutlama düzeylerinde ele alınabilir:

• paydaş/iş gereksinimi,
• kullanıcı veya operasyon gereksinimi,
• sistem gereksinimi,
• alt sistem/yazılım/donanım gereksinimi,
• arayüz gereksinimi,
• emniyet/güvenlik/mevzuat kısıtı,
• doğrulama ve kabul ölçütü.

Bir gereksinimin iyi tanımlanması; gerekli, açık, tekil, doğrulanabilir ve izlenebilir olmasını gerektirir. “Sistem hızlı olmalıdır” planlama ve kabul açısından yetersizdir. Ölçülebilir hedef, yük profili ve sınır koşulu gerekir.

4.10. Gereksinim İzlenebilirlik Matrisi

İzlenebilirlik, bir talebin teslimat zincirinde kaybolmadığını gösterir:

paydaş ihtiyacı
 -> sistem gereksinimi
    -> tasarım öğesi
       -> WBS iş paketi
          -> test/doğrulama
             -> kabul kanıtı

Bu ilişki yalnız dokümantasyon için değil değişiklik etkisi analizi için de kullanılır. Bir gereksinim değiştiğinde hangi tasarım, iş paketi, test ve maliyet kalemlerinin etkilendiği görülebilir.

4.11. Kapsam Tabanı

Kapsam tabanı genellikle onaylı kapsam bildirimi, WBS ve WBS sözlüğüyle temsil edilir. Gereksinim listesi ile WBS aynı şey değildir. Gereksinim “ne gerekli?” sorusunu, WBS ise proje kapsamında üretilmesi gereken teslimat ve işi yapılandırır.

WBS iş paketlerinin yeterince küçük olması tahmin, sahiplik ve izleme için önemlidir; ancak gereksiz mikro parçalama yönetim yükü üretir. Ayrıştırmanın amacı her faaliyeti saat düzeyinde bölmek değil, yönetilebilir kontrol hesapları oluşturmaktır.

4.12. Kabul Ölçütleri

Teslimatın “bitti” sayılması için kabul ölçütü önceden tanımlanmalıdır. Kabul kriterleri belirsizse proje sonunda teknik olarak çalışan ürün ile sponsorun beklediği ürün arasında anlaşmazlık oluşabilir.

kapsam maddesi
+ ölçülebilir kabul kriteri
+ doğrulama yöntemi
+ kabul sahibi
= yönetilebilir teslimat

4.13. Kapsam Değişikliği ve Gereksinim Oynaklığı

Her değişiklik kapsam kayması değildir. Kontrollü değişiklik proje yönetiminin normal parçasıdır. Sorun, etki analizi yapılmadan kapsamın sessizce büyümesidir.

Bir değişiklik talebinde en azından:

• neden,
• beklenen değer,
• kapsam etkisi,
• takvim etkisi,
• maliyet etkisi,
• risk etkisi,
• teknik mimari etkisi,
• sözleşme etkisi,
• karar sahibi

görünür olmalıdır.

Ünite 5: Takvim Yönetimi, Ağ Diyagramı, CPM ve PERT

5.1. Faaliyet Ağı

Takvim yalnız tarih listesinden oluşmaz. Faaliyetler arasındaki bağımlılıklar, süre tahminleri, kaynak sınırlamaları ve takvim kısıtları birlikte modellenir. Bir iş paketinin “5 gün” sürmesi, bu işin her durumda beş takvim günü sonra biteceği anlamına gelmez.

Bağımlılıklar tipik olarak bitiş–başlangıç, başlangıç–başlangıç, bitiş–bitiş ve daha seyrek başlangıç–bitiş ilişkileriyle ifade edilir. Gereksiz bağımlılıklar planı kırılganlaştırırken eksik bağımlılıklar sahte paralellik oluşturur.

5.2. Kritik Yol Yöntemi

Kritik yol, proje bitiş tarihini belirleyen ve toplam bolluğu sıfır ya da en düşük olan faaliyet zinciridir. İleri geçişle erken başlangıç/bitiş, geri geçişle geç başlangıç/bitiş hesaplanır.

Toplam Bolluk = LS - ES = LF - EF

Burada ES erken başlangıç, EF erken bitiş, LS geç başlangıç, LF geç bitiş zamanıdır. Kritik yol “en önemli işlerin listesi” değildir; ağ mantığına göre projenin bitişini doğrudan etkileyen yoldur. Kaynak kısıtları ve takvim kısıtları, saf ağ hesabından farklı sonuçlar doğurabilir.

5.3. PERT ve Üç Nokta Tahmini

Belirsiz süreler için iyimser (O), en olası (M) ve kötümser (P) tahminler kullanılarak klasik PERT beklenen süresi hesaplanabilir:

t_e = (O + 4M + P) / 6
Varyans = ((P - O) / 6)^2

Bu formül belirsizliği görünür kılar; ancak gerçek dağılımın her durumda PERT varsayımına uyduğunu kanıtlamaz. Kritik işlerde tarihsel veri veya Monte Carlo benzetimi daha gerçekçi sonuç verebilir.

5.4. Tampon ve Takvim Riski

Planın her faaliyetini “güvenli olsun” diye şişirmek toplam planı güvenilir yapmaz. Gizli tamponlar görünürlüğü düşürür ve Parkinson yasası benzeri davranışlara yol açabilir. Belirsizlik açık risk olarak yönetilmeli, kritik alanlarda uygun rezerv ayrılmalıdır.

5.5. Faaliyetlerin Tanımlanması ve Sıralanması

WBS çalışma paketinden faaliyetlere geçilir. Faaliyetler arasındaki mantıksal ilişkiler ağ diyagramını oluşturur. Precedence Diagramming Method'ta temel ilişkiler:

• Finish-to-Start (FS),
• Start-to-Start (SS),
• Finish-to-Finish (FF),
• Start-to-Finish (SF).

FS yaygındır fakat her şeyi FS yapmak gereksiz seri akış oluşturur. Teknik olarak paralel yürüyebilecek işler SS/FF ilişkileriyle modellenebilir.

5.6. Lead ve Lag

Lag, iki faaliyet arasında bilinçli bekleme süresidir. Lead ise ardıl faaliyetin önceki faaliyet bitmeden başlamasına izin verir. Lead takvimi kısaltabilir ama bağımlı işin erken başlaması yeniden çalışma riskini artırabilir.

5.7. Süre Tahmin Yöntemleri

Belirsiz süre tahmininde üç nokta/PERT yaklaşımı kullanılabilir:

• uzman görüşü,
• analog tahmin,
• parametrik tahmin,
• bottom-up tahmin,
• üç nokta tahmini

kullanılabilir.

PERT benzeri üç nokta tahmininde klasik ağırlıklı ortalama:

TE = (O + 4M + P) / 6

Burada O iyimser, M en olası, P kötümser tahmindir. Formül belirsizliği ortadan kaldırmaz; yalnız belirsizliği görünür bir modele taşır.

5.8. Kritik Yol Yöntemi — Derinleştirme

Kritik yol, proje bitişini belirleyen en uzun bağımlı faaliyet zinciridir. Kritik yol üzerindeki toplam bolluk (total float) sıfıra veya planın tanımına göre en düşük değere yakındır.

Kritik yol “en önemli işler listesi” değildir. Kritik olmayan bir faaliyet kalite veya güvenlik açısından kritik olabilir; yalnız takvim bitişini doğrudan belirlemeyebilir.

İleri geçiş (forward pass) erken başlangıç/bitişleri; geri geçiş (backward pass) geç başlangıç/bitişleri hesaplar. Yaklaşık olarak:

Total Float = LS - ES = LF - EF

5.9. Kaynak Kısıtları ve Kritik Zincir Düşüncesi

Klasik CPM öncelikle mantıksal bağımlılığı ele alır. Aynı uzman aynı anda iki kritik faaliyete atanmışsa kaynak kısıtı takvimi değiştirir. Resource leveling takvimi uzatabilir; resource smoothing ise mevcut float içinde kaynak dağılımını düzeltmeye çalışır.

Kritik zincir yaklaşımı kaynak bağımlılıklarını ve tampon yönetimini daha görünür ele alır. Her projede uygulanması gerekmez; özellikle paylaşılan uzman kaynakların darboğaz olduğu ortamlarda yararlıdır.

5.10. Takvimi Sıkıştırma

İki klasik teknik vardır:

• Crashing: ek kaynak/maliyet karşılığında süreyi azaltmak.
• Fast tracking: normalde ardışık işleri kısmen paralel yürütmek.

Crashing her faaliyette işe yaramaz; dokuz kişinin bir aylık işi bir günde bitirememesi gibi bölünemeyen işler vardır. Fast tracking ise yeniden çalışma ve entegrasyon riskini yükseltir.

5.11. Uygulamalı Ağ Diyagramı, CPM ve Takvim Analizi

Ağ diyagramları, PERT ve kritik yol takvim analizinin temel araçlarıdır. Kavramların formülle birlikte küçük bir örnek üzerinde görülmesi, takvim yönetiminin yalnız Gantt grafiği olmadığını gösterir.

5.12. Örnek Faaliyet Ağı

Bir proje parçasında faaliyetler şöyle olsun:

A: Gereksinim netleştirme       4 gün   -
B: Mimari tasarım               5 gün   A
C: Veri modeli                  3 gün   A
D: Servis geliştirme            6 gün   B,C
E: Entegrasyon testi            4 gün   D
F: Kullanıcı kabulü             2 gün   E

A tamamlandıktan sonra B ve C paralel yürüyebilir. D hem B hem C tamamlanmadan başlayamaz.

Yollar:

A-B-D-E-F = 4+5+6+4+2 = 21 gün
A-C-D-E-F = 4+3+6+4+2 = 19 gün

Bu basit ağda kritik yol A-B-D-E-F'dir. C'nin yaklaşık 2 günlük toplam float'ı vardır. C iki gün gecikirse proje bitişi değişmeyebilir; daha fazla gecikirse kritik yol etkilenir.

5.13. İleri ve Geri Geçiş

CPM hesaplamasında forward pass ile erken başlangıç/erken bitiş; backward pass ile geç başlangıç/geç bitiş hesaplanır.

ES = önceki faaliyetlerin EF değerlerinin maksimumu
EF = ES + süre
LF = sonraki faaliyetlerin LS değerlerinin minimumu
LS = LF - süre
Total Float = LS - ES = LF - EF

Gerçek araçlarda takvim, hafta sonu, kaynak takvimi ve lead/lag bu basit aritmetiği değiştirir. Formül mantığı yine aynıdır.

5.14. PERT ile Üç Nokta Tahmini

Belirsiz faaliyette iyimser O, en olası M ve kötümser P tahminleri kullanılarak klasik PERT beklenen süre yaklaşımı:

TE = (O + 4M + P) / 6

Örneğin O=4, M=7, P=16 gün ise:

TE = (4 + 4*7 + 16) / 6 = 8 gün

Bu değer kesin süre değildir; üç nokta tahmininden türetilmiş beklenen değerdir. Tahminlerin bağımsızlığı ve dağılım varsayımları gerçek projede sınırlıdır.

5.15. Kaynak Kısıtı Kritik Yolu Değiştirebilir

CPM mantığı çoğu zaman kaynakların faaliyetleri planlandığı anda yapabildiğini varsayar. Aynı uzman iki paralel kritik faaliyette gerekiyorsa program kayabilir. Resource leveling, kaynak çatışmasını çözmek için faaliyetleri erteleyebilir ve proje bitişini uzatabilir. Resource smoothing ise mümkün olduğunca mevcut float içinde kaynak dalgalanmasını azaltmaya çalışır.

5.16. Crashing ve Fast Tracking

Crashing, ek maliyet karşılığında süreyi azaltmaya çalışır. Yalnız kritik yoldaki ve gerçekten sıkıştırılabilir faaliyetlerde proje süresini azaltır. Kritik olmayan bir faaliyeti hızlandırmak toplam bitişi değiştirmeyebilir.

Fast tracking, normalde ardışık işlerin bir bölümünü paralelleştirir. Süre kazanabilir fakat yeniden çalışma ve koordinasyon riskini artırır.

süre azaltma kararı
 -> hangi kritik faaliyet?
 -> ne kadar süre kazanılır?
 -> ek maliyet ne?
 -> teknik/rework riski ne?

Bağımlılık ağından kritik yolu hesaplamak. Dört faaliyetten oluşan projede A = 2 gün ve B = 3 gün başlangıçta paralel yürütülebilsin; C = 4 gün yalnız A bittikten, D = 1 gün ise hem B hem C bittikten sonra başlayabilsin. İleri geçişte A ve B sıfırda başlar; C ikinci gün başlar ve altıncı gün biter; D için en erken başlangıç max(3,6) = 6, en erken bitiş 7 olur. Projenin en erken bitiş süresi 7 gün, kritik yol A → C → D olarak bulunur. B, üçüncü günde bitmesine rağmen D altıncı günden önce başlayamadığı için bu örnekte 3 gün toplam bolluğa sahiptir. Sonucun geçerliliği, faaliyet sürelerinin sabit, öncelik ilişkilerinin doğru ve kaynakların eşzamanlı çalışmaya izin verdiği varsayımlarına bağlıdır. Ortak kaynak kısıtları varsa CPM takvimi tek başına uygulanabilir plan oluşturmaz.

Ünite 6: Maliyet, Bütçe ve Kazanılmış Değer Yönetimi

6.1. Maliyet Tabanı

Maliyet planı yalnız personel saatlerinin toplamı değildir. Donanım, lisans, tedarik, altyapı, eğitim, test, bakım geçişi ve risk rezervleri birlikte ele alınır. Teknik tasarım kararı, ilk yatırım maliyetini azaltırken işletme maliyetini artırabilir. Bu nedenle toplam sahip olma maliyeti önemli bir mühendislik ölçütüdür.

6.2. Kazanılmış Değer Kavramları

Kazanılmış Değer Yönetimi (Earned Value Management, EVM), kapsam, takvim ve maliyeti ortak bir ölçüm tabanında birleştirir:

• PV (Planned Value): ölçüm tarihine kadar planlanan işin bütçelenmiş değeri,
• EV (Earned Value): gerçekten tamamlanan işin bütçelenmiş değeri,
• AC (Actual Cost): tamamlanan iş için gerçekleşen maliyet.

Temel göstergeler:

CV  = EV - AC
SV  = EV - PV
CPI = EV / AC
SPI = EV / PV

CPI < 1, bütçe açısından verimsizlik; SPI < 1 ise planlanana göre daha az iş tamamlandığını gösterir. Bu göstergeler kök nedeni açıklamaz; yalnız sapmayı görünür kılar.

6.3. Tamamlanma Tahminleri

BAC toplam onaylı bütçe olmak üzere, gelecekteki maliyet verimliliğinin geçmiş CPI ile benzer kalacağı varsayımında:

EAC = BAC / CPI

Geçmiş sapmanın tek seferlik olduğu ve kalan işin bütçe oranında yürütüleceği varsayımında:

EAC = AC + (BAC - EV)

Formül seçimi mekanik değil, kalan işin gerçekçi varsayımına dayanmalıdır. Kötü bir tahmini formülle hassaslaştırmak, onu doğru hâle getirmez.

6.4. Güncel Standart Bağlamı

ISO 21512:2024 ve Eylül 2026 tarihli Amendment 1, kazanılmış değer yönetiminin uygulanmasına; ISO 21508:2026 ise proje, program ve portföy yönetiminde EVM kullanımına ilişkin güncel uluslararası çerçeveler sağlar. Standartlar, metriklerin ortak dilini güçlendirir; kuruma özgü ölçüm tasarımının yerini almaz.

6.5. Maliyet Tahmini

Maliyet tahmini yalnız personel saatinin ücretle çarpılması değildir. Donanım, lisans, seyahat, test altyapısı, enerji, dış hizmet, bakım, eğitim, kalite maliyeti ve risk rezervleri dahil edilebilir.

Tahmin yöntemleri süre tahminine benzer:

• analog,
• parametrik,
• bottom-up,
• üç nokta,
• teklif/vendor analizi.

Tahminin doğruluk aralığı proje olgunlaştıkça daralmalıdır; başlangıçtaki kaba tahmini kesin bütçe gibi kullanmak yanıltıcıdır.

6.6. Cost Baseline ve Rezervler

Cost baseline, performansın ölçüldüğü onaylı zaman fazlı bütçedir. Contingency reserve bilinen-belirsizlik (identified risks) için baseline içinde tutulabilir; management reserve ise öngörülemeyen yönetim ihtiyacı için baseline dışında ayrı yönetilir.

Bu ayrım, risk gerçekleştiğinde harcamanın “bütçe aşımı” mı yoksa planlanmış rezerv kullanımı mı olduğunu anlamak için önemlidir.

6.7. Kazanılmış Değer Yönetimi: Temel Değişkenler

EVM proje performansını kapsam, zaman ve maliyet üzerinden birlikte okumaya yarar. Temel değişkenler:

• PV (Planned Value): rapor tarihinde planlanmış işin bütçelenmiş değeri,
• EV (Earned Value): gerçekten tamamlanan işin bütçelenmiş değeri,
• AC (Actual Cost): tamamlanan iş için gerçekleşen maliyet,
• BAC (Budget at Completion): toplam onaylı bütçe.

Türetilen göstergeler:

SV  = EV - PV
CV  = EV - AC
SPI = EV / PV
CPI = EV / AC

SPI < 1 takvim açısından geride, CPI < 1 maliyet açısından verimsiz performansı işaret eder. Bu yorumlar işin doğasına ve ölçüm yöntemine göre değerlendirilmelidir.

6.8. EAC, ETC, VAC ve TCPI

Tamamlanma tahmini varsayıma göre değişir. Tipik örnekler:

EAC = BAC / CPI

mevcut maliyet performansının devam edeceği varsayımını kullanır.

EAC = AC + (BAC - EV)

gelecekte kalan işin orijinal bütçe verimliliğiyle tamamlanacağı varsayımına yakındır.

VAC = BAC - EAC
ETC = EAC - AC
TCPI(BAC) = (BAC - EV) / (BAC - AC)

Formülü mekanik uygulamak yerine sapmanın kök nedeni belirlenmelidir. Tek seferlik tedarik problemi ile kalıcı üretkenlik düşüşü aynı EAC modelini gerektirmez.

6.9. EVM'nin Veri Kalitesi Şartı

EV ölçüm yöntemi nesnel değilse EVM güvenilir görünür fakat yanlış sonuç üretebilir. “%90 tamamlandı” gibi öznel beyanlar yerine 0/100, 50/50, milestone-weighted veya fiziksel ilerleme ölçümü kullanılabilir. WBS ve baseline iyi değilse EVM grafiği yalnız hatalı planı hassas biçimde ölçer.

6.10. Uygulamalı Kazanılmış Değer Yönetimi

EVM, takvim ve maliyeti aynı ölçüm dilinde birleştirir. Ancak üretilen göstergeler yalnız temel plan ve ilerleme ölçümü güvenilir olduğunda anlamlıdır.

6.11. Sayısal Örnek

Bir iş paketinin toplam bütçesi BAC = 1.000.000 TL olsun. Rapor tarihinde planın %60'ının tamamlanmış olması bekleniyor, gerçekte işin %50'si tamamlandı ve 580.000 TL harcandı.

PV = 1.000.000 * 0,60 = 600.000 TL
EV = 1.000.000 * 0,50 = 500.000 TL
AC = 580.000 TL

Varyanslar:

SV = EV - PV = -100.000 TL
CV = EV - AC =  -80.000 TL

Endeksler:

SPI = EV / PV = 0,833
CPI = EV / AC = 0,862

Bu durumda proje hem planlanan fiziksel ilerlemenin gerisindedir hem de üretilen değer başına planlanandan daha fazla maliyet harcamıştır.

6.12. EAC Senaryoları

Gelecekteki işin mevcut maliyet performansıyla süreceği varsayılırsa:

EAC ≈ BAC / CPI

Örnekte:

EAC ≈ 1.000.000 / 0,862 ≈ 1.160.000 TL

Ancak geçmiş sapma tek seferlik bir olay ise bu formül aşırı kötümser olabilir. Başka bir yaklaşım:

EAC = AC + (BAC - EV)

Bu formül kalan işin bütçe oranında yapılacağını varsayar. Formül seçimi, yönetim varsayımını açıkça ifade etmelidir.

6.13. TCPI

Belirlenmiş bütçeye ulaşmak için kalan işin hangi maliyet performansıyla yapılması gerektiğini gösteren TCPI, hedefin gerçekçiliğini sorgulamaya yardım eder.

BAC hedefi korunacaksa:

TCPI = (BAC - EV) / (BAC - AC)

Örnekte:

TCPI = 500.000 / 420.000 ≈ 1,19

Geçmiş CPI 0,862 iken kalan işte 1,19 CPI beklemek çok güçlü bir performans sıçraması gerektirir. Yönetim burada “bütçeyi koru” talebinin teknik gerçekçilikle uyuşup uyuşmadığını değerlendirmelidir.

6.14. EV Fiziksel İlerleme Olmalıdır

EV'nin en kritik noktası, harcanan para veya geçen zaman değil tamamlanan kapsamın bütçelenmiş değeri olmasıdır. “Bütçenin %50'sini harcadık, o halde %50 tamamladık” yaklaşımı EVM değildir.

İlerleme ölçüm yöntemleri iş paketine göre farklı olabilir:

• 0/100,
• 50/50,
• ağırlıklı kilometre taşı,
• fiziksel yüzde tamamlanma,
• tamamlanmış birim sayısı.

Ölçüm kuralı önceden tanımlanmalıdır.

6.15. EVM ve Teknik Performans Birlikte Okunmalıdır

Takvim/maliyet göstergeleri ürünün teknik olarak doğru olduğunu kanıtlamaz. Proje CPI=1 ve SPI=1 iken performans, güvenlik veya kalite hedeflerini kaçırabilir. Bu nedenle EVM teknik performans ölçütleriyle birlikte değerlendirilmelidir.

Kazanılmış değeri bir tahmin kararına dönüştürmek. Planlanan değer PV = 80, kazanılmış değer EV = 60 ve gerçekleşen maliyet AC = 75 (hepsi bin TL) olduğunda zaman performans göstergesi SPI = EV/PV = 0,75, maliyet performans göstergesi CPI = EV/AC = 0,80 bulunur. SPI < 1, plana göre daha az iş tamamlandığını; CPI < 1 ise kazanılan iş başına maliyetin bütçeyi aştığını gösterir. Tamamlanma bütçesi BAC = 200 bin TL ve mevcut maliyet verimsizliğinin kalan işte de aynı oranda süreceği varsayılırsa EAC = BAC/CPI = 250 bin TL kestirimi yapılabilir. Ancak bu tek olası EAC modeli değildir; tek seferlik maliyet sapması varsa farklı bir kestirim seçilmelidir. SPI oranı da doğrudan gün cinsinden gecikme vermez. Dolayısıyla metrikler önce teşhis, sonra nedensel analiz ve gerekçelendirilmiş yeniden tahmin için kullanılmalıdır.

Maliyet sapması ile kapasite sapması ayrı kontrol değişkenleridir. Bir projenin planlanan bütçede ilerlemesi, geliştirilen yazılımın hedef yükü karşılayacağı anlamına gelmez. Kazanılmış değer metriğine ek olarak kapasite testinde geçerli işlem/s, p99, hata oranı ve kaynak tüketimi ölçülmelidir. Yapılan işin yüzdesi bir teslimat metriğidir; saniyede tamamlanan güvenilir işlem sayısı ise çalışan ürünün niteliğidir.

Performans iyileştirmesi yatırım kararında yalnız beklenen throughput artışıyla sunulmamalıdır. Kazanımın gerçekleşeceği yük aralığı, test ortamı farkları, operasyonel karmaşıklık ve regresyon riski parasal maliyetle birlikte ele alınmalıdır. Bir önbellek eklemek altyapı maliyetini azaltırken tutarlılık, invalidation ve olay yönetimi maliyetini artırabilir. Bu etkileri görünmez sayan yatırım hesabı eksiktir.

Ünite 7: Kalite, Doğrulama, Geçerleme ve Güvenilirlik

7.1. Kalite Planlaması

Kalite, son test aşamasında ürüne eklenen bir özellik değildir. Gereksinim, mimari, kodlama/üretim, entegrasyon ve işletme boyunca tasarlanır. Kalite planı yalnız kusur sayısını değil; hangi kalite özniteliklerinin ne şekilde doğrulanacağını açıklamalıdır.

7.2. Doğrulama ve Geçerleme

Doğrulama (verification), ürünün tanımlanan gereksinimlere ve tasarıma uygun üretilip üretilmediğini; geçerleme (validation) ise doğru problemin çözülüp çözülmediğini sorgular.

Doğrulama: Ürünü doğru mu inşa ediyoruz?
Geçerleme: Doğru ürünü mü inşa ediyoruz?

Bu iki soru birbirinin yerine geçmez. Gereksinime kusursuz uyan fakat yanlış ihtiyacı hedefleyen sistem teknik olarak doğrulanmış, fakat geçerlenmemiş olabilir.

7.3. Kalite Maliyeti

Kalite maliyeti; önleme, değerlendirme ve başarısızlık maliyetleriyle birlikte düşünülür. Erken gereksinim incelemesi veya otomatik test ek maliyet gibi görünse de üretimde bulunan kusurun maliyetinden daha düşük olabilir. Mühendislik yönetimi, kalite faaliyetlerini “ek iş” değil risk azaltma yatırımı olarak görmelidir.

7.4. Teknik Borç

Teknik borç her kısa yolun kötü olduğu anlamına gelmez. Bilinçli, etkisi ölçülmüş ve geri ödeme planı bulunan borç iş hedefi için rasyonel olabilir. Problem; borcun görünmez, sahipsiz ve faizinin ölçülmez hâle gelmesidir. Teknik borç; değişiklik süresi, kusur oranı, olay sıklığı, bağımlılık güncelliği ve mimari karmaşıklık gibi göstergelerle birlikte izlenebilir.

7.5. Kalite: Uygunluk ve Amaca Uygunluk

Kalite yalnız hatasız ürün değildir. Ürünün gereksinime uygunluğu, kullanım amacını karşılaması, güvenilirliği, bakım yapılabilirliği ve doğrulanabilirliği birlikte değerlendirilir.

Kalite yönetimi üç farklı işlev içerir:

• kaliteyi planlamak,
• süreçte kalite güvencesi sağlamak,
• çıktıda kalite kontrol yapmak.

Test yalnız kalite kontrol araçlarından biridir; kaliteyi en sona bırakmak pahalı yeniden çalışma üretir.

7.6. Kalite Maliyeti — Derinleştirme

Cost of Quality iki büyük sınıfta düşünülebilir:

• uygunluk maliyeti: önleme ve değerlendirme,
• uygunsuzluk maliyeti: iç ve dış hata.

Kod inceleme veya otomatik test maliyeti görünür olduğu için bazen “ek yük” gibi görülür; üretimde kritik hatanın maliyeti çok daha yüksek olabilir.

7.7. Temel Kalite Araçları

Kaynak içerikte kalite/problem çözme yaklaşımının parçası olarak şu araçlar önemlidir:

• Pareto analizi,
• neden-sonuç (Ishikawa/balık kılçığı) diyagramı,
• kontrol grafikleri,
• histogram,
• scatter diagram,
• check sheet,
• akış şeması.

Pareto “sorunların %80'i mutlaka nedenlerin %20'sinden gelir” şeklinde fizik kanunu değildir; baskın hata kaynaklarını önceliklendirmeye yarayan heuristiktir.

7.8. Kök Neden Analizi

Belirti ile neden ayrılmalıdır. “Test başarısız” bir sonuçtur; neden gereksinim belirsizliği, hatalı tasarım, yanlış veri, ortam farkı veya regresyon olabilir. Five Whys, Ishikawa ve fault-tree analizi farklı karmaşıklık düzeylerinde kullanılabilir.

7.9. Doğrulama ve Geçerleme — Derinleştirme

Verification: ürünü spesifikasyona uygun mu yaptık?

Validation: doğru ürünü mü yaptık; gerçek ihtiyaç karşılanıyor mu?

Bir sistem bütün teknik testleri geçip kullanıcı ihtiyacını karşılamıyorsa verification başarılı, validation başarısız olabilir.

7.10. Güvenilirlik, Bakım Yapılabilirlik ve Kullanılabilirlik

Mühendislik projesinde teslimat sonrası davranış önemlidir. MTBF, MTTR ve availability gibi ölçüler uygun bağlamda kullanılabilir. Basit yaklaşım:

Availability ≈ MTBF / (MTBF + MTTR)

Ancak dağıtık ve yedekli sistemlerde kullanılabilirlik modeli daha karmaşıktır; ortak hata nedenleri ve bakım pencereleri hesaba katılmalıdır.

Ünite 8: Risk, Belirsizlik, Nicel Analiz ve Karar Ağacı

8.1. Risk Kavramı

Risk, gelecekteki belirsiz bir olayın hedefler üzerinde olumlu veya olumsuz etkisidir. Gerçekleşmiş problem artık risk değil sorundur. Bilinen bir kusuru “risk” olarak kaydetmek, çözüm sorumluluğunu belirsizleştirebilir.

Basit nicel yaklaşımda beklenen parasal değer:

EMV = Olasılık x Etki

Bu hesap karşılaştırma için yararlıdır; fakat düşük olasılıklı felaket risklerinde tek başına yeterli değildir. Emniyet, güvenlik ve mevzuat risklerinde tolerans sınırları ayrıca tanımlanmalıdır.

8.2. Risk Kaydı

İyi bir risk kaydı yalnız risk cümlesi içermez. Tetikleyici, olasılık, etki, sahip, yanıt stratejisi, artık risk ve gözden geçirme tarihi bulunmalıdır. “Teknoloji çalışmayabilir” yerine neden–olay–etki yapısı daha işlevseldir:

Eğer kritik bağımlılık hedef sürümde gerekli özelliği desteklemezse,
entegrasyon yeniden tasarım gerektirebilir ve teslimat gecikebilir.

8.3. Yanıt Stratejileri

Tehditler kaçınma, azaltma, aktarma veya kabul ile; fırsatlar yararlanma, geliştirme, paylaşma veya kabul ile yönetilebilir. Risk aktarımı riski yok etmez. Örneğin sigorta finansal etkiyi aktarabilir, hizmet kesintisinin operasyonel etkisini ortadan kaldırmaz.

8.4. Monte Carlo ve Duyarlılık

Birden fazla belirsiz süre veya maliyetin birleştiği projelerde tek tarih vermek sahte kesinlik yaratabilir. Monte Carlo benzetimi, farklı dağılımlardan çok sayıda senaryo üreterek “bu tarihe yetişme olasılığı” gibi sonuçlar sağlar. Modelin kalitesi, giriş dağılımlarının kalitesine bağlıdır.

8.5. Risk Yönetimi Döngüsü

Risk yönetimi tek seferlik “risk listesi hazırlama” faaliyeti değildir:

planla
 -> tanımla
 -> analiz et
 -> yanıt planla
 -> yanıtı uygula
 -> izle
 -> yeni riskleri ekle

Risk kaydı en az neden, olay, etki, olasılık, etki derecesi, sahip, yanıt, tetikleyici ve durum içerebilir.

8.6. Risk ile Sorun Arasındaki Fark

Risk gelecekte gerçekleşebilecek belirsiz olaydır. Gerçekleşmiş risk artık issue/problem olarak yönetilir. Risk kaydında “sunucu çöktü” yazmak geç kalınmış tespittir; “tek depolama denetleyicisinin arızası hizmeti durdurabilir” risk ifadesidir.

8.7. Niteliksel Risk Analizi

Olasılık-etki matrisi riskleri göreli önceliklendirir. Sayısal hücrelerin kendisi bilimsel kesinlik sağlamaz. 1–5 ölçeği organizasyon içinde aynı şekilde anlaşılmalıdır. Urgency, detectability, proximity ve controllability gibi boyutlar gerektiğinde eklenebilir.

8.8. Niceliksel Risk Analizi

Expected Monetary Value:

EMV = olasılık × parasal etki

Tek riskte basittir; karar ağaçlarında alternatiflerin beklenen değeri karşılaştırılabilir. Ancak ortalama değer kuyruk riskini gizleyebilir.

Monte Carlo simülasyonu çok sayıda süre/maliyet dağılımını tekrar örnekleyerek toplam sonuç dağılımı üretir. “P80 tarih” tek tahminden farklı olarak belirli güven seviyesine göre planlama sağlar.

8.9. Risk Yanıt Stratejileri

Tehditler için tipik stratejiler:

• kaçınma,
• azaltma,
• transfer,
• kabul.

Fırsatlar için:

• exploit,
• enhance,
• share,
• accept.

Risk transferi sorumluluğu tamamen ortadan kaldırmaz. Sigorta veya sözleşme finansal etkinin bir kısmını aktarabilir; itibar, teknik bağımlılık ve müşteri etkisi kurumda kalabilir.

8.10. Karar Ağacı ve Beklenen Değer

Birden fazla teknik alternatif belirsiz sonuçlar üretiyorsa karar ağacı kullanılabilir. Her dal için maliyet, olasılık ve sonuç değeri açıkça yazılır. Karar ağacı etik veya güvenlik sınırını ekonomik ortalamayla yok saymak için kullanılmamalıdır; kabul edilemez sonuçlar önceden kısıt olarak belirlenebilir.

8.11. Nicel Risk, Beklenen Değer ve Karar Analizi

Niteliksel risk matrisi önceliklendirme için yararlıdır; ancak büyük maliyet/takvim belirsizliklerinde sayısal analiz karar kalitesini artırabilir.

8.12. Beklenen Parasal Değer

Bir riskin gerçekleşme olasılığı %20 ve maliyet etkisi 1.000.000 TL ise basit EMV:

EMV = 0,20 * 1.000.000 = 200.000 TL

Bu, olay gerçekleştiğinde 200.000 TL kayıp yaşanacağı anlamına gelmez. Risk ya oluşup 1.000.000 TL etkileyebilir ya da oluşmayabilir; 200.000 TL portföy/rezerv planlaması için beklenen değerdir.

Beklenen parasal değer bir kararın ortalama etkisini özetler; nadir fakat yıkıcı sonucun kabul edilebilir olup olmadığını tek başına göstermez. Örneğin %1 olasılıkla 10 milyon birimlik kayıp riski, beklenen değer hesabında 100 bin birimdir. Bu büyüklük düşük görünüyor diye kurumun tek bir olayda 10 milyonluk kaybı karşılayabileceği varsayılamaz. Karar kaydında sonuç dağılımı, risk iştahı, en kötü kabul edilebilir kayıp ve etkisi yüksek senaryolar ayrıca görünür olmalıdır. Farklı alternatifler aynı beklenen değere sahipken çok farklı dayanıklılık profili taşıyabilir.

8.13. Karar Ağacı

İki mimari seçeneği olsun:

• Seçenek A: 400.000 TL başlangıç maliyeti; %20 olasılıkla 900.000 TL ek yeniden çalışma.
• Seçenek B: 550.000 TL başlangıç maliyeti; %5 olasılıkla 300.000 TL ek yeniden çalışma.

Basit beklenen maliyet:

A = 400.000 + 0,20*900.000 = 580.000 TL
B = 550.000 + 0,05*300.000 = 565.000 TL

Bu modelde B'nin beklenen maliyeti daha düşüktür. Fakat karar yalnız EMV'ye indirgenmemelidir; kuyruk riski, maksimum kayıp, teknik kapasite ve geri dönüşü olmayan sonuçlar ayrıca değerlendirilir.

8.14. Monte Carlo Yaklaşımı

Tek bir iyimser/en olası/kötümser proje süresi yerine faaliyet süreleri dağılım olarak modellenip binlerce senaryo simüle edilebilir. Çıktı “proje 180 günde biter” yerine dağılım verir:

P50 = 176 gün
P80 = 194 gün
P95 = 218 gün

Bu değerler örnektir. P80, simülasyon varsayımlarına göre sonuçların yaklaşık %80'inin bu sürenin altında kaldığı yüzdeliktir. Yönetim taahhüdü risk iştahına göre seçilebilir.

8.15. Korelasyon Problemi

Faaliyet sürelerini bağımsız varsaymak riski küçümseyebilir. Aynı tedarikçi, aynı uzman ekip veya aynı teknik bilinmezlik birden çok faaliyeti birlikte etkileyebilir. Nicel risk modeli ortak nedenleri ve korelasyonları mümkün olduğunca yansıtmalıdır.

8.16. Risk Rezervleri

Contingency reserve bilinen-belirsizlikler için plan içinde tutulabilir. Management reserve daha üst düzey belirsizlikler için ayrı yönetim kontrolünde olabilir. Rezerv kullanımı “bütçe fazlası” değil risk gerçekleşmesine karşı bilinçli finansal tampon olarak ele alınmalıdır.

8.17. Mühendislik Riskinde Bağlı Olayları Modellemek

Bir proje riskini olasılık × etki çarpımıyla puanlamak yararlı bir ilk gösterimdir; fakat çoklu bileşenlerin aynı kök nedene bağlı olduğu sistemlerde riskleri bağımsız toplamak yanıltıcı olabilir. Ortak tedarikçi, aynı sürümdeki yazılım kütüphanesi veya tek bir test düzeneği birden fazla alt sistemin birlikte gecikmesine neden olabilir. Marjinal olay olasılıkları bilinse bile ortak gerçekleşme olasılığı bilinmeden birleşik risk kesin hesaplanamaz.

Örneğin \(A\) ve \(B\) olaylarından en az birinin gerçekleşme olasılığı \(P(A\cup B)=P(A)+P(B)-P(A\cap B)\) bağıntısına uyar. Bağımsızlık varsayımı ancak gerekçesi varsa \(P(A\cap B)=P(A)P(B)\) biçiminde kullanılabilir. Senaryo analizi, ortak nedenli gecikmelerin bütçe ve teslim tarihine etkisini ayrı gösterebilir. Risk tetikleyicisi ve erken uyarı metriği birbirine bağlandığında risk kaydı statik bir liste olmaktan çıkar.

Risk yanıtı yalnız azaltma planından oluşmaz; riskin sahibi, karar zamanı, alınan önlemin kanıtı ve geride kalan risk belirtilir. Teknik doğrulama tamamlanmadan kilometre taşını 'bitti' saymak, program görünümünü iyileştirirken gerçek entegrasyon riskini sonraki aşamaya taşır. Risk değerlendirmesinde ölçülmemiş iyimser varsayımlar açıkça ayrıştırılmalıdır.

8.18. Erken Uyarı Göstergelerini Risk Kararından Ayırmak

Proje maliyetinde ani artış, gerçekleşme oranında düşüş veya sürekli değişen teslim tarihi erken uyarı işareti olabilir. Bunlar tek başına başarısızlık hükmü değildir. Karar için gösterge tanımı, veri yenileme aralığı, karşılaştırma dönemi ve nicel etki birlikte değerlendirilir. Birden çok göstergenin aynı kök nedenden etkilenmesi bağımsız risk sayısının abartılmasına yol açabilir. Risk göstergesi ile alarm arasındaki fark Anomali Algılama dersinde ele alınır.

Ünite 9: Organizasyon Yapıları ve Proje Yöneticisi Yetkinliği

9.1. Organizasyon Yapısı Proje Davranışını Belirler

Fonksiyonel, proje bazlı, matris, yatay ve ağ tipi organizasyon yapıları farklı yetki ve kaynak modelleri oluşturur. Proje yöneticisinin yetkisi organizasyon şemasından bağımsız düşünülemez.

9.1.1. Fonksiyonel Yapı

Uzmanlık birimleri güçlüdür; mühendisler kendi disiplin yöneticilerine bağlıdır. Teknik standartlaşma ve kariyer gelişimi kolaylaşır, fakat çapraz bir proje için kararlar fonksiyonlar arasında yavaşlayabilir.

9.1.2. Proje Bazlı Yapı

Kaynaklar projeye doğrudan atanır ve proje yöneticisinin yetkisi yüksektir. Hız ve odak artabilir; buna karşılık uzman havuzlarının tekrar kullanımı ve proje sonrasında personel yerleşimi sorun olabilir.

9.1.3. Matris Yapı

Fonksiyonel ve proje otoritesi birlikte bulunur. Zayıf, dengeli ve güçlü matris biçimleri proje yöneticisinin kaynak/karar yetkisine göre değişir. Matrisin temel riski ikili raporlama ve öncelik çatışmasıdır.

              Fonksiyon Yöneticisi
                    |
Mühendis -----------+----------- Proje Yöneticisi
        teknik ev   |   teslimat önceliği

İkili otorite açık RACI, kaynak anlaşması ve eskalasyon mekanizması olmadan çalışanı iki farklı hedef arasında bırakabilir.

9.1.4. Yatay/süreç Odaklı ve Ağ Organizasyonları

Süreç odaklı yapılarda müşteri değer akışı fonksiyon sınırlarından daha önemlidir. Ağ organizasyonlarında dış ortak ve tedarikçiler kritik yetenek sağlar. Bu model esneklik sunarken sözleşme, entegrasyon, fikrî mülkiyet ve tedarikçi sürekliliği riskini büyütür.

9.2. Proje Yöneticisinin Yetkinlik Modeli

Proje yöneticiliği yalnız Gantt şeması güncelleme işi değildir. Yetkinlik üç ana kümede ele alınabilir:

• teknik proje yönetimi: kapsam, takvim, maliyet, risk, kalite ve tedarik;
• liderlik: ekip, çatışma, müzakere, karar ve motivasyon;
• iş/strateji anlayışı: değerin, finansal kısıtların, müşteri ve kurum hedeflerinin anlaşılması.

Mühendislik projesinde bunlara sistem düşüncesi ve teknik karar okuryazarlığı eklenir. Proje yöneticisinin bütün teknik ayrıntıları bizzat tasarlaması gerekmez; fakat teknik riskin bütçe/takvim üzerindeki etkisini anlayabilmesi gerekir.

9.3. Fonksiyonel, Proje Bazlı ve Matris Organizasyon

Fonksiyonel yapıda uzmanlık ve kariyer hattı güçlüdür; proje yöneticisinin kaynak üzerindeki yetkisi sınırlı olabilir. Projectized yapıda proje odağı ve karar hızı artabilir; uzmanlık havuzlarında tekrar ve proje sonrası kaynak belirsizliği oluşabilir.

Matris yapı iki ekseni birleştirmeye çalışır. Zayıf/dengeli/güçlü matris ayrımı proje yöneticisinin yetkisi ve kaynak sahipliği açısından düşünülür. Matrisin temel riski çift raporlama ve öncelik çatışmasıdır.

9.4. Yetki ile Sorumluluğun Dengesi

Bir kişiye sonuç sorumluluğu verip gerekli karar veya kaynak yetkisini vermemek yapısal hata üretir. RACI benzeri matrisler sahipliği görünür kılabilir; fakat gerçek karar hakları organizasyon pratiğinde desteklenmelidir.

Ünite 10: Kaynak, Takım ve Liderlik

10.1. Kaynak Yönetiminin Mühendislik Boyutu

Kaynak planı “kaç kişi var?” sorusundan fazlasıdır. Yetkinlik, kritik uzmanlık, öğrenme eğrisi, iletişim maliyeti ve görev bağımlılığı birlikte değerlendirilir. Dokuz aylık işi dokuz kişiye dağıtmak her zaman bir ayda tamamlanmasını sağlamaz; paralelleştirilebilirlik ve koordinasyon maliyeti sınırlayıcıdır.

10.2. Rol Açıklığı ve Sahiplik

RACI benzeri matrisler sorumluluğu görünür kılabilir; fakat yanlış kullanıldığında her iş için çok sayıda “sorumlu” üretir. Kritik mühendislik kararlarında tek bir hesap verebilir karar sahibi olması, danışma ve uygulama rollerinin açık ayrılması daha değerlidir.

10.2.1. İnsan ve Ajanlar Arasında Sorumluluk Paylaşımı

Kodlama ajanı bir görevi icra edebilir; gereksinimin sahibi, onay mercii ve üretime çıkış sorumlusu ise insan veya açıkça tanımlı kurumsal roldür. Kaynak planlamasında ajanı sınırsız paralel iş gücü olarak saymak gerçekçi değildir. Araç erişimi, hesaplama maliyeti, bütünleme, kod inceleme ve kabul testi aynı teslim kapasitesini paylaşır.

Görev dağılımında karar yetkisi, değişiklik yetkisi ve doğrulama yetkisi ayrıştırılır. Ajanlar rutin araştırma veya test önerisi üretebilir; iş etkisi yüksek kararların gerekçesi ve kabulü sorumlu mühendislik rolünde kalır. Organizasyonel performans ölçümü, tek başına üretilen değişiklik sayısından ziyade doğrulanmış teslimatlar ve üretimdeki sonuçları esas almalıdır.

10.3. Liderlik

Teknik liderlik, en fazla teknik işi liderin yapması değildir. Lider; karar kalitesini, ekip kapasitesini ve bilgi akışını artırmalıdır. Mikroyönetim kısa vadede kontrol hissi üretirken karar darboğazı yaratabilir.

Durumsal liderlik açısından ekip olgunluğu ve işin riskine göre yönlendirme düzeyi değişebilir. Kritik olay sırasında daha merkezi karar modeli gerekirken, keşif aşamasında uzmanların özerkliği daha yüksek olabilir.

10.4. Çatışma ve Müzakere

Teknik çatışma her zaman zararlı değildir. Mimari alternatiflerin açıkça tartışılması karar kalitesini artırabilir. Zararlı olan; kişiselleştirilmiş, kanıtsız ve çözümsüz çatışmadır. Sorun çözme/iş birliği, uzlaşma, yumuşatma, zorlama ve kaçınma farklı bağlamlarda kullanılabilir; sürekli tek stratejiye bağlı kalmak doğru değildir.

10.5. Kaynak Yönetimi ve Kapasite

Kaynak yönetimi yalnız kişileri görevlere atamak değildir. Yetkinlik, kullanılabilirlik, takvim, öğrenme eğrisi ve darboğaz birlikte değerlendirilir. Bir kişinin %100 tahsis edilmesi pratikte %100 üretken zaman anlamına gelmez; toplantı, destek, izin ve kesinti payı vardır.

Kritik uzmanı aynı anda çok projeye atamak lokal utilization'ı yükseltip toplam lead time'ı bozabilir. Kuyruk teorisi açısından kapasite %100'e yaklaştıkça bekleme süresi keskin biçimde artabilir.

10.6. RACI ve Sorumluluk Tasarımı

RACI:

• Responsible,
• Accountable,
• Consulted,
• Informed

rollerini ayırır. Bir teslimat için birden fazla Responsible olabilir, ancak Accountable rolünün belirsiz olması karar gecikmesi yaratır. RACI organizasyon şemasının yerine geçmez; iş bazında karar sahipliğini netleştirir.

10.7. Takım Gelişimi

Takımlar ilk günden yüksek performanslı olmaz. Tuckman'ın forming-storming-norming-performing modeli deterministik yasa değil, takım dinamiğini konuşmak için yararlı modeldir. Yeni üye, lider değişimi veya kriz takımı daha önceki aşamalara döndürebilir.

10.8. Motivasyon Teorilerini Doğru Bağlamda Kullanmak

Maslow, Herzberg, McGregor ve benzeri klasik motivasyon modelleri yönetim literatüründe yaygın tarihsel çerçevelerdir. Bu modeller tarihsel yönetim düşüncesini anlamak için yararlıdır; deneysel olarak evrensel insan davranışı yasaları olarak ele alınmamalıdır.

Mühendislik ekibinde motivasyonu etkileyen somut unsurlar arasında özerklik, ustalık, işin anlamı, adil geri bildirim, çalışma ortamı, rol açıklığı ve gerçekçi yük bulunabilir.

10.9. Liderlik Stilleri

Tek bir “en iyi liderlik stili” yoktur. Acil durumda direktif yaklaşımı, uzman ekipte katılımcı yaklaşım, yetkin ve özerk ekipte delegasyon daha uygun olabilir. Liderliğin amacı karar hızını, teknik doğruluğu ve sahipliği bağlama göre dengelemektir.

10.10. Çatışma Yönetimi

Çatışma her zaman kötü değildir; teknik seçenekler arasındaki kontrollü çatışma tasarımı iyileştirebilir. Kişiselleşmiş veya belirsiz sahiplikten doğan çatışma ise maliyetlidir.

Yaklaşımlar:

• problem çözme/işbirliği,
• uzlaşma,
• yumuşatma,
• zorlama,
• kaçınma.

Yüksek etkili teknik kararda “çoğunluk ne diyorsa” yaklaşımı kanıta dayalı mühendislik kararının yerini almamalıdır.

10.11. Organizasyon, Takım Dinamiği ve İletişim Tasarımı

Organizasyon yapıları, motivasyon, liderlik ve iletişim mühendislik yönetiminin insan-sistem boyutunu oluşturur. Bu kavramları mühendislik yönetiminde kullanırken davranış bilimindeki modelleri kesin doğa yasaları gibi değil, yönetim düşüncesini yapılandıran araçlar olarak görmek gerekir.

10.12. Takım Gelişimi — Derinleştirme

Tuckman modeli forming–storming–norming–performing aşamalarını düşünmek için yaygın bir çerçevedir. Takımlar bu aşamalardan doğrusal ve bir kez geçmek zorunda değildir; yeni üye, kriz veya kapsam değişikliğiyle yeniden çatışma evresine dönebilir.

10.13. Motivasyon Modelleri

Maslow, Herzberg veya McGregor gibi tarihsel modeller yönetim literatüründe sık görülür. Bunlar her bireyin davranışını öngören doğrulanmış algoritmalar gibi kullanılmamalıdır. Mühendislik ekibinde özerklik, ustalık, adil ücret, psikolojik güvenlik, anlamlı amaç, geri bildirim ve iş yükü dengesi birlikte etkilidir.

Ünite 11: Paydaş ve İletişim Yönetimi

11.1. Paydaş Analizi

Paydaş, projeden etkilenebilen veya projeyi etkileyebilen kişi, grup veya kuruluştur. Kullanıcı ile sponsor aynı rol değildir; güvenlik ekibi, operasyon ekibi, satın alma, hukuk ve düzenleyici otoriteler de teknik projenin paydaşı olabilir.

Paydaşların güç, ilgi, etki ve tutumları zaman içinde değişebilir. Analiz tek seferlik başlangıç faaliyeti değildir.

11.2. İletişim Planı

Daha fazla rapor, daha iyi iletişim anlamına gelmez. İletişim planı; kimin hangi bilgiyi, hangi sıklıkta, hangi ayrıntı düzeyinde ve hangi kararı verebilmek için ihtiyaç duyduğunu tanımlar.

Yönetici raporu ile teknik ekip raporunun aynı olması beklenmemelidir. Üst yönetim trend, risk, karar ve sapmaya; teknik ekip ise neden, bağımlılık ve uygulanabilir eyleme ihtiyaç duyar.

11.3. Durum Raporlaması

İyi durum raporu “%80 tamamlandı” gibi bağlamsız yüzdeler yerine teslimat, risk ve tahmin değişimini gösterir. Aşağıdaki yapı çoğu mühendislik projesinde yeterlidir:

Sonuç -> Sapma -> Neden -> Etki -> Karar/Eylem -> Sahip -> Tarih

Kırmızı durumu yeşile boyamak, yönetime iyi haber vermek değildir; müdahale süresini azaltır.

11.4. Paydaşların Erken Belirlenmesi

Paydaş yalnız müşteri veya sponsor değildir. Üründen etkilenen kullanıcı, operasyon ekibi, güvenlik, hukuk, kalite, düzenleyici, tedarikçi, bakım ekibi ve hatta proje sonucundan olumsuz etkilenebilecek gruplar paydaştır.

Güç-ilgi matrisi basit ama yararlı başlangıç aracıdır:

yüksek güç / yüksek ilgi -> yakın yönet
yüksek güç / düşük ilgi  -> tatmin et
 düşük güç / yüksek ilgi -> bilgilendir
 düşük güç / düşük ilgi  -> izle

Bu sınıflandırma sabit değildir. Proje fazına göre güç ve ilgi değişebilir.

11.5. İletişim Kanalları

Ekipte potansiyel birebir iletişim kanalı sayısı:

n(n-1) / 2

Ekip büyüdükçe koordinasyon maliyeti karesel artma eğilimi gösterir. Bu nedenle her kişinin herkesle toplantı yapması ölçeklenmez; arayüzler, temsilciler ve yazılı karar kayıtları gerekir.

11.6. Push, Pull ve Etkileşimli İletişim

• Etkileşimli: toplantı, telefon, canlı görüşme.
• Push: e-posta, bildirim, rapor gönderimi.
• Pull: wiki, dashboard, doküman deposu.

Acil karar pull modeline bırakılamaz; kalıcı teknik bilgi yalnız sözlü toplantıda tutulmamalıdır. İletişim yöntemi bilginin aciliyeti ve kalıcılığıyla eşleştirilir.

11.7. Durum Raporunun Amacı

İyi durum raporu “çok çalışıyoruz” mesajı vermez; karar için gerekli sapmayı görünür yapar. Kısa bir yönetim görünümü şu alanları içerebilir:

• önemli kilometre taşları,
• baseline'a göre takvim/maliyet sapması,
• en yüksek riskler,
• karar bekleyen konular,
• kapsam/değişiklik durumu,
• kalite ve teknik performans göstergeleri.

11.8. İletişim Kanalı Sayısı

Tam bağlantılı bir grupta teorik ikili iletişim kanalı sayısı:

n(n-1)/2

10 kişi için 45, 20 kişi için 190 kanal eder. Bu formül iletişim maliyetinin ekip büyüdükçe doğrusal artmadığını gösteren iyi bir sezgidir; gerçek organizasyonda herkes herkesle aynı yoğunlukta iletişim kurmaz.

11.9. İletişim Mimarisi

İletişim planı “haftalık toplantı yap” listesinden daha kapsamlıdır. Şunları tanımlar:

• hangi bilgi,
• hangi karar sahibine,
• hangi sıklıkta,
• hangi formatta,
• hangi gecikme toleransıyla,
• hangi kayıt sistemi üzerinden

ulaşmalıdır.

Kritik kararların yalnız sohbet uygulamasında kaybolması kurumsal hafızayı zayıflatır. Karar kaydı ile operasyonel sohbet ayrılmalıdır.

Ünite 12: Tedarik, Sözleşme ve Teşvik Tasarımı

12.1. Üretme–Satın Alma Kararı

Bir bileşeni satın almak geliştirme süresini azaltabilir; ancak lisans, entegrasyon, tedarikçi bağımlılığı, güvenlik, veri taşınabilirliği ve ürün yaşam döngüsü risklerini artırabilir. Karar yalnız ilk fiyat üzerinden verilmemelidir.

12.2. Sözleşme Türleri ve Teşvikler

Sabit fiyat sözleşmeleri maliyet riskinin önemli bölümünü satıcıya aktarabilir; ancak belirsiz gereksinimlerde değişiklik maliyetini büyütebilir. Maliyet geri ödemeli sözleşmeler belirsiz Ar-Ge işlerinde esneklik sağlar; alıcı açısından maliyet kontrolü gerekir. Zaman ve malzeme yaklaşımı ise kapsamın tam belirlenemediği işlerde yararlı olabilir, fakat güçlü takip gerektirir.

Sözleşme modeli, tarafların davranış teşviklerini de belirler. Yanlış teşvik, teknik olarak “sözleşmeye uygun” fakat toplam sistem açısından verimsiz sonuç üretebilir.

12.3. Tedarikçi Teknik Yönetimi

Tedarikçi değerlendirmesinde yalnız teslim tarihi ve fiyat değil; kalite, güvenlik, değişiklik yönetimi, destek süresi, sürüm politikası, yedek parça/bağımlılık erişilebilirliği ve olay müdahale yükümlülükleri de değerlendirilmelidir.

Yazılım tedarik zincirinde bileşen envanteri, güvenlik açığı takibi, imzalı eserler ve köken bilgisi gibi kontroller proje yönetiminin teknik risk görünümüne dâhildir.

12.4. Tedarik: make-or-buy Kararı

Üretme veya satın alma kararı yalnız ilk maliyetle verilmez. Değerlendirme:

• stratejik yetkinlik,
• teslim süresi,
• yaşam döngüsü maliyeti,
• bağımlılık/vendor lock-in,
• fikrî mülkiyet,
• güvenlik,
• bakım kapasitesi,
• tedarik sürekliliği

unsurlarını içerir.

12.5. Sözleşme Türleri ve Risk Dağılımı

Genel sınıflar:

• sabit fiyat (fixed price),
• maliyet geri ödemeli (cost reimbursable),
• zaman ve malzeme (time & materials).

Sabit fiyat alıcı için maliyet öngörülebilirliği sağlar, fakat kapsam belirsizse tedarikçi risk primini yükseltir veya değişiklik talepleri artar. Cost-reimbursable Ar-Ge belirsizliğinde uygun olabilir ama güçlü maliyet gözetimi ister. T&M esnektir; tavan ve kabul mekanizması olmadan maliyet kontrolü zayıflayabilir.

12.6. Tedarikçi Teknik Yönetimi — Derinleştirme

Tedarik sözleşmesi imzalandıktan sonra teknik risk bitmez. Arayüz kontrol dokümanı, kabul kriteri, teknik review, test kanıtı, değişiklik bildirimi, güvenlik zafiyet yönetimi ve obsolescence takibi gerekir.

Bir entegrasyon hatasında “tedarikçi sorumlu” demek proje etkisini ortadan kaldırmaz; proje yöneticisi bağımlılığın planını yönetmek zorundadır.

12.7. Teklif ve Kaynak Seçimi

RFI bilgi toplamak, RFP çözüm ve yaklaşım teklifi almak, RFQ daha tanımlı ürün/hizmet için fiyat almak amacıyla kullanılabilir. Kaynak seçimi yalnız en düşük fiyat üzerinden yapılmamalıdır. Teknik uygunluk, toplam sahip olma maliyeti, teslim riski, referanslar ve sözleşme şartları ağırlıklandırılabilir.

Tedarik sözleşmesi yalnız hukuk belgesi değil risk paylaşım mekanizmasıdır. Yanlış sözleşme tipi, tedarikçiyi teknik kalite yerine yerel maliyet optimizasyonuna teşvik edebilir.

12.8. Sabit Fiyatlı Sözleşmeler

Fixed-price yaklaşımında kapsam yeterince tanımlıysa maliyet riski daha çok satıcıya aktarılabilir. Ancak belirsiz kapsamda satıcı belirsizliği fiyata ekleyebilir veya değişiklik talepleri üzerinden geri alabilir. “Sabit fiyat = maliyet kesin” varsayımı bu nedenle yanıltıcıdır.

12.9. Maliyet Geri Ödemeli Sözleşmeler

Cost-reimbursable model yüksek belirsizlik ve araştırma niteliğindeki işlerde esneklik sağlar; maliyet kontrolü alıcı açısından daha fazla yönetişim gerektirir. Teşvik yapısı maliyet, takvim ve kalite davranışını etkiler.

12.10. Time & Materials

T&M modeli personel zamanı ve malzeme üzerinden ödeme yapar. Kapsamın henüz ayrıntılı tanımlanamadığı uzmanlık işlerinde kullanılabilir; ancak üst sınır, performans ölçütü ve kabul kriteri tanımlanmazsa maliyet öngörülebilirliği zayıflar.

12.11. RFI, RFQ ve RFP Ayrımı

• RFI: piyasa/yetenek hakkında bilgi toplamak,
• RFQ: yeterince tanımlı ürün/hizmet için fiyat teklifi istemek,
• RFP: çözüm yaklaşımı, teknik yeterlilik, plan ve fiyatı birlikte değerlendirmek

için kullanılabilir.

Belge adı kurumdan kuruma değişebilir; asıl önemli olan talep edilen bilginin karar ihtiyacıyla uyumudur.

12.12. Tedarikçi Seçiminde Teknik Puanlama

En düşük fiyat her zaman en düşük yaşam döngüsü maliyeti değildir. Değerlendirme:

• teknik uyum,
• güvenlik/emniyet,
• teslimat kapasitesi,
• desteklenebilirlik,
• geçmiş performans,
• finansal sürdürülebilirlik,
• bağımlılık ve vendor lock-in,
• toplam sahip olma maliyeti

gibi faktörleri içerebilir.

12.13. Kabul ve Claim Yönetimi

Sözleşme imzalandıktan sonra teknik kabul mekanizması açık olmalıdır. Teslimatın hangi testlerle kabul edileceği, uygunsuzluk durumunda ne olacağı ve değişikliğin nasıl fiyatlanacağı belirsizse proje yönetimi sürekli müzakereye dönüşür.

Ünite 13: Mühendislik Kararları, Değişiklik, Konfigürasyon ve Sistem Mühendisliği

13.1. Karar Analizi

Teknik kararlar çoğunlukla birden fazla kalite özniteliği arasında ödünleşim içerir. En yüksek performans, en düşük maliyet ve en yüksek esneklik her zaman aynı seçenekle elde edilemez.

Karar ölçütleri önceden tanımlanmalı ve ağırlıkların sonucu nasıl etkilediği görünür olmalıdır. Çok ölçütlü karar matrisi yararlı olabilir; fakat sayısal puanlama uzman muhakemesinin yerine geçmez.

13.2. Mimari Karar Kayıtları

Mimari Karar Kaydı (Architecture Decision Record, ADR), kararın bağlamını, değerlendirilen seçenekleri, seçimi ve sonuçlarını kısa ve kalıcı biçimde kaydeder. Amaç her kod değişikliğini belgelemek değil, geri döndürülmesi pahalı veya sistem davranışını önemli ölçüde etkileyen kararları izlenebilir kılmaktır.

13.3. Teknik İnceleme Kapıları

System Requirements Review, Preliminary Design Review, Critical Design Review gibi kapılar karmaşık sistemlerde teknik olgunluğu kanıtlamak için kullanılabilir. İnceleme, takvimdeki tarih geldiği için “geçilmiş” sayılmamalıdır; önceden tanımlı giriş/çıkış ölçütleri bulunmalıdır.

13.3.1. Ajanlı Üretimde Teknik İnceleme Darboğazı

Otomatik kod üretimi hızlandığında inceleme kuyruğu ve test altyapısı teslim sürecinin kısıtlayıcı kaynağı haline gelebilir. İşlerin tamamlanma oranı yalnız üretim aşamasının kapasitesiyle değil, en dar doğrulama ve kabul aşamasıyla sınırlanır. Kuyruk uzunluğu, bekleme süresi ve iade edilen değişiklik oranı birlikte incelenmeden ajanların teslimata net katkısı belirlenemez.

İnceleme kapıları değişiklik riskine göre düzenlenebilir: düşük etkili belgeler ile yetki, veri bütünlüğü veya eşzamanlılık davranışını değiştiren kod aynı güvence düzeyini gerektirmez. Risk temelli derecelendirme insan onayının ortadan kaldırılması değil, uzman incelemesinin en önemli değişikliklere ayrılmasıdır. Kabul ölçütleri önceden tanımlandığında incelenebilirlik artar.

13.4. Arayüz ve Konfigürasyon Yönetimi

Birçok entegrasyon sorunu bileşenin kendi içinden değil arayüzden kaynaklanır. Arayüz sözleşmeleri, veri formatı, zamanlama, hata davranışı ve sürüm uyumluluğu yönetilmelidir. Konfigürasyon yönetimi de “dosyaları sürüm kontrolüne koymak”tan daha geniştir: hangi ürün tanımının hangi sürümde geçerli olduğunu belirler.

13.5. Entegre Değişiklik Kontrolü

Değişiklik kontrolü bürokrasi üretmek için değil, lokal değişikliğin sistem etkisini görmek için vardır. Bir değişiklik isteği şu eksenlerde analiz edilir:

kapsam
+ takvim
+ maliyet
+ kalite
+ risk
+ kaynak
+ sözleşme
+ mimari/konfigürasyon

Onaydan önce baseline değiştirilmez. Değişiklik reddedilse bile karar gerekçesi kayıt altına alınabilir.

13.6. Konfigürasyon Yönetimi

Konfigürasyon yönetimi, ürünün “hangi sürümü doğru ürün?” sorusunu cevaplar. Konfigürasyon öğeleri, sürümler, baseline'lar, değişiklik geçmişi ve release kimliği izlenir. Yazılım projesinde Git tek başına konfigürasyon yönetiminin tamamı değildir; altyapı, şema, firmware, gereksinim, test paketi ve dağıtım parametreleri de konfigürasyon öğesi olabilir.

13.7. Teknik Karar Analizi

Mühendislik yönetiminde kararlar yalnız maliyet ve süre üzerinden verilmez. Weighted scoring, AHP, trade study veya utility yaklaşımı kullanılabilir. Kriterler örneğin:

• performans,
• güvenilirlik,
• güvenlik,
• entegrasyon riski,
• maliyet,
• tedarik süresi,
• bakım yapılabilirlik.

Ağırlıklar karar vericinin değer sistemini görünür yapar. Hassasiyet analizi, küçük ağırlık değişiminde karar tersine dönüyorsa sonucun kırılgan olduğunu gösterir.

13.8. Mimari Karar Kaydı

ADR, teknik kararın bağlamını, seçeneklerini, seçilen yaklaşımı ve sonuçlarını kısa biçimde kaydeder. Amaç her tasarım ayrıntısını belgelemek değil, “neden böyle yaptık?” sorusunun kaybolmasını engellemektir.

13.9. Teknik Gözden Geçirme Kapıları

SRR, PDR, CDR, TRR veya benzeri review kapıları sektöre göre değişebilir. Kapının değeri toplantı yapmak değil, belirli olgunluk kanıtını değerlendirmektir. Çıkış kriteri belirsiz review, yönetim sunumuna dönüşür.

13.10. Sistem Mühendisliği ile Proje Yönetiminin Birleştirilmesi

Karmaşık mühendislik projelerinde proje planı ile teknik geliştirme planı iki bağımsız dünya olamaz. Takvim kilometre taşı teknik olgunluk kanıtına bağlanmadığında “tarih geldiği için aşama tamamlandı” yanılgısı oluşur.

13.11. Teknik Performans Ölçütleri

Maliyet ve takvim yanında teknik performans da izlenmelidir. Örneğin bir gerçek zamanlı sistem için:

• uçtan uca gecikme,
• throughput,
• hata oranı,
• kullanılabilirlik,
• güç tüketimi,
• ağırlık,
• güvenlik açığı sayısı değil güvenlik hedefleri,
• doğruluk veya algılama performansı

proje ilerleme ölçütlerine bağlanabilir.

13.12. Teknik Gözden Geçirme Kapıları — Derinleştirme

Konsept, gereksinim, ön tasarım, kritik tasarım, test readiness veya operasyonel readiness gibi kapılar isimden bağımsız olarak karar noktalarıdır. Kapının amacı sunum yapmak değil, bir sonraki aşamaya geçmek için yeterli kanıtın bulunup bulunmadığını değerlendirmektir.

kilometre taşı tarihi
+ giriş kriteri
+ kanıt
+ açık riskler
+ karar yetkilisi
= gerçek yönetim kapısı

13.13. Arayüz Yönetimi

Büyük projelerde alt sistemlerin kendi içinde doğru olması entegrasyon başarısını garanti etmez. Arayüz sözleşmeleri; veri biçimi, zamanlama, hata davranışı, fiziksel/elektriksel özellik, sürümleme ve sahipliği tanımlamalıdır. Interface Control Document veya eşdeğer yaşayan sözleşme, bağımlılık yönetiminin teknik karşılığıdır.

13.14. Konfigürasyon Yönetimi — Derinleştirme

Hangi gereksinim sürümü, tasarım, yazılım, donanım, test prosedürü ve kalibrasyon verisinin birlikte bir baseline oluşturduğu bilinmelidir. Aksi halde test edilen sistem ile teslim edilen sistem aynı olmayabilir.

13.15. Teknik Borç ve Proje Kararı

Teknik borç tamamen kaçınılması gereken bir “kötülük” değildir; bazen zaman baskısı altında bilinçli borç alınabilir. Yönetilebilir olması için:

• borcun nedeni,
• etkilediği kalite özelliği,
• faiz etkisi,
• ödeme koşulu,
• sahipliği

kayıtlı olmalıdır. Görünmez teknik borç, sonraki tahminlerin sistematik biçimde iyimser kalmasına yol açar.

13.16. Başarıyı Teslim Tarihinden Ayırmak

Mühendislik projesinin başarısı yalnız zamanında ve bütçede bitmesi değildir. Ürün gereksinimi karşılamıyor, sürdürülemiyor veya beklenen operasyonel faydayı yaratmıyorsa proje üçlü kısıtı tutturmuş olsa bile değer üretmemiş olabilir. Bu nedenle teknik performans, teslimat performansı ve fayda gerçekleşmesi ayrı ama bağlı göstergeler olarak ele alınmalıdır.

Ünite 14: Ölçüm, Tahmin ve Kontrol Döngüsü

14.1. Ölçülebilir Hedefler

Metrik, yalnız toplanabildiği için kullanılmamalıdır. Her metriğin bir karar amacı olmalıdır. Kod satırı, toplantı sayısı veya tamamlanan görev sayısı bağlam olmadan üretkenlik ölçüsü değildir.

İyi ölçüm sistemi; teslimat, kalite, akış, maliyet, risk ve operasyonel sonuçları dengeler. Tek metrik optimize edildiğinde Goodhart yasası riski doğar: ölçü hedef hâline geldiğinde iyi bir ölçü olmaktan çıkabilir.

Bir proje göstergesi tanımlanırken hesap formülü kadar verinin oluşma süreci de kaydedilmelidir. “Hata sayısı azaldı” cümlesi, yeni sürümde kayıt alma eşiği değişmişse ilerlemeyi göstermez. Geçmiş dönem karşılaştırmasında gözlem kapsamı, payda, sınıflama kuralı ve eksik kayıt politikası aynı olmalıdır. Gösterge üretim hattı değiştirilirse eski ve yeni yöntem paralel bir örneklem üzerinde çalıştırılıp fark ayrıştırılabilir. Yönetim raporunun amacı yalnız olumlu eğilimi göstermek değil, eğilimi hangi belirsizliğin değiştirebileceğini ve hangi yönetim kararının bu bilgiden türediğini ortaya koymaktır.

14.2. Öncü ve Gecikmeli Göstergeler

Gecikmeli göstergeler sonucu ölçer: bütçe aşımı, üretim olayı, müşteri kusuru gibi. Öncü göstergeler ise gelecekteki sonucu etkileyebilecek davranışı erken gösterir: kritik risklerin kapanma süresi, test kapsamı eğilimi, bağımlılık yaşlanması veya teslimat çevrim süresi gibi.

Her öncü göstergenin nedensel olduğu varsayılmamalı; korelasyon düzenli olarak sorgulanmalıdır.

14.3. Kontrol Çevrimi

Plan -> Ölç -> Sapmayı yorumla -> Karar ver -> Uygula -> Yeniden ölç

Kontrolün amacı planı değişmez tutmak değil, hedefe ulaşma olasılığını yükseltmektir. Yeni kanıt geldiğinde tahmini güncellemek “plan başarısızlığı” değil, iyi yönetim davranışıdır.

14.4. Ölçüm Sistemi

Metrik ölçülebilir olduğu için otomatik olarak değerlidir. İyi metrik karar üretir. Örneğin sadece “açılan hata sayısı” ekibi daha az hata raporlamaya teşvik edebilir. Defect escape rate, recovery time, deployment failure rate veya requirements volatility gibi bağlama uygun ölçüler daha anlamlı olabilir.

14.5. Leading ve Lagging Göstergeler

Lagging indicator sonucu sonradan gösterir; leading indicator gelecekteki sonuçla ilişkili erken sinyal olabilir. Örneğin teslimat gecikmesi lagging; test kuyruğunun sürekli büyümesi gecikmenin leading sinyali olabilir.

14.6. Kontrol Döngüsü

Mühendislik yönetimi kapalı çevrim kontrol problemine benzetilebilir:

hedef/baseline
    ↓
uygulama
    ↓
ölçüm
    ↓
sapma analizi
    ↓
düzeltici / önleyici karar
    └───────────────↺

Ölçüm gecikmeli veya gürültülü ise aşırı düzeltme yapılabilir. Her küçük varyansta plan değiştirmek sistemde yönetim salınımı yaratır.

14.7. KPI bir Sayı Değil, Ölçüm Sözleşmesidir

Bir KPI'nın adı ve hedef değeri tek başına yönetilebilir bir ölçüm sistemi oluşturmaz. Aynı "hata oranı" veya "teslim süresi" ifadesi farklı ekiplerce farklı hesaplanıyorsa trend karşılaştırması anlamını kaybeder. Bu nedenle kritik göstergeler bir ölçüm sözleşmesi olarak tanımlanmalıdır.

En az şu alanlar açık olmalıdır:

ölçülen olay / nüfus
pay ve payda tanımı
zaman penceresi
hariç tutulan durumlar
veri kaynağı ve sorgu sürümü
ölçüm sahibi
hedef / tolerans / aksiyon eşiği
ölçüm bozulduğunda uygulanacak kontrol

Örneğin "başarılı dağıtım oranı" için rollback ile tamamlanan dağıtımın başarılı sayılıp sayılmadığı, kısmi rollout'un paydaya girip girmediği ve planlı test dağıtımlarının üretim dağıtımından ayrılıp ayrılmadığı tanımlanmazsa metrik ekipler arasında karşılaştırılamaz.

Metrik ile hedef de aynı şey değildir:

metric    -> gözlenen nicelik
indicator -> niceliğin karar bağlamındaki yorumu
target    -> istenen seviye
threshold -> aksiyon başlatan sınır

Bir metriği hedefe çevirmek Goodhart etkisini ve oyunlaştırmayı tetikleyebilir. Bu nedenle KPI'nın yanında dengeleyici metrik ve veri-kalite kontrolü bulunması, özellikle tek sayının personel veya ekip performansına bağlandığı durumlarda önemlidir.

14.8. SLO, Error Budget ve Kapasite Planlamasını Yönetim Kararına Bağlamak

Mühendislik yönetiminde bir SLO hedefi, teslim takvimi ile güvenilirlik maliyetini ortak karar zeminine taşır. Error budget tüketimi sürüm çıkarma sıklığını, kapasite yatırımlarını ve teknik borç azaltma işlerini önceliklendirmek için kullanılabilir; ancak bu kararlar ölçülen hizmet düzeyi, gözlem penceresi ve olayın kullanıcı etkisi belirtilerek gerekçelendirilmelidir. Kaynağı belirsiz genel performans beyanları yerine yük testinden üretim davranışına uzanan izlenebilir ölçütler tercih edilmelidir.

• Teslim tarihi ile reliability borcu arasındaki trade-offu ölçülebilir SLO üzerinden görünür kılmak.
• Kapasite yatırımını ortalama yük yerine peak ve tail davranışına göre gerekçelendirmek.
• Olay sonrası incelemeyi kişi hatası yerine sistem ve süreç iyileştirmesine dönüştürmek.

Headroom kararı tek bir ortalama kullanıma bağlanamaz. Bir servisin günlük ortalama RPS'i, beş dakikalık zirve geliş hızını veya belirli sorguların beklenmedik kaynak tüketimini gizleyebilir. Ölçeklendirme kararında yükün zaman dağılımı, burst süresi, backlog tüketme hızı, hedef kurtarma süresi ve iş başına kaynak maliyeti birlikte incelenmelidir. Ek kapasite maliyeti, kabul edilemez kuyruk beklemesi ve hizmet kesintisi riskiyle karşılaştırılır.

SLO hedefi örneğin “başarılı işlemlerin belirli yüzdesi X ms altında” biçimindeyse hangi işlemlerin paydada yer aldığı, zaman aşımının nasıl sayıldığı ve pencere uzunluğu sözleşmede yazılmalıdır. Error budget'ın kullanılması, kötüleşen sistem üzerinde kontrolsüz yeni iş yükü başlatma gerekçesi değildir. Yönetim raporunda performans iyileştirmesi bir ayar listesiyle değil doğrulanmış başlangıç koşulu, kontrol edilen değişiklik, gözlenen sonuç ve geri alma koşulu ile sunulmalıdır.

Ünite 15: Program, Portföy, PMO, Kapanış ve Kurumsal Öğrenme

15.1. Program Yönetimi

Program yönetimi, ilişkili projelerin ortak faydasını, bağımlılıklarını ve geçişlerini koordine eder. Bir projenin yerel optimizasyonu programı kötüleştirebilir. Örneğin bir alt projenin erken teslimi, bağımlı altyapı hazır değilse toplam faydayı hızlandırmayabilir.

15.2. Portföy Yönetimi

Portföy yönetimi “tüm projeleri tek listede tutmak” değildir. Kıt sermaye ve insan kaynağının stratejik amaçlara göre dağıtılmasıdır. Değer, risk, zorunluluk, kapasite ve bağımlılık birlikte değerlendirilir.

Bir projenin iyi yönetiliyor olması, onun hâlen yapılması gereken doğru proje olduğunu kanıtlamaz. Portföy düzeyinde durdurma veya yeniden önceliklendirme de rasyonel bir yönetim kararıdır.

15.3. Proje Yönetim Ofisi

PMO'nun rolü kuruma göre destekleyici, kontrol edici veya yönlendirici olabilir. Etkili PMO yalnız şablon üretmez; ortak yöntem, veri kalitesi, kapasite görünürlüğü, yönetişim ve kurumsal öğrenme sağlar. PMBOK sekizinci baskısında PMO bağlamının genişletilmesi de bu kurumsal rolün önemini yansıtır.

15.4. Proje Kapanışı

Teslimatın bitmesi proje yönetiminin bittiği anlamına gelmez. Kabul, açık işlerin yönetimi, sözleşme kapanışı, varlıkların devri, erişimlerin kapatılması, dokümantasyon ve operasyon sorumluluğunun transferi planlanmalıdır.

15.5. Operasyona Geçiş

Üretime geçen sistemin sahipliği belirsizse proje teknik olarak teslim edilmiş fakat işletilebilir olmayabilir. Operasyona geçişte en az şu konular netleşmelidir:

• hizmet sahibi ve destek modeli,
• izleme ve alarm sorumluluğu,
• yedekleme ve geri dönüş,
• kapasite ve performans tabanı,
• güvenlik güncelleme süreci,
• olay ve değişiklik yönetimi,
• bilgi aktarımı ve işletme dokümantasyonu.

15.6. Dersler ve Proje Sonrası Değerlendirme

“Lessons learned” yalnız kapanış toplantısında oluşturulan bir belge olmamalıdır. Öğrenme proje boyunca kaydedilip sonraki kararlara taşınmalıdır. ISO 21513:2026, proje ve programlar için proje sonrası değerlendirmeye ilişkin güncel rehber sağlayarak teslimat sonrası sonuç ve öğrenmenin önemini vurgular.

Kapanış sonrası değerlendirme şu sorulara odaklanabilir:

• Beklenen değer gerçekleşti mi?
• Tahmin hatalarının sistematik nedeni neydi?
• Hangi teknik kararlar uzun vadede doğru/yanlış çıktı?
• Hangi risk sinyalleri erken görülebilirdi?
• Hangi süreç gerçekten kalite üretti, hangisi yalnız işlem yüküydü?

15.7. Program ve Portföy Mantığı

Program, ortak fayda veya bağımlılıklar nedeniyle birlikte yönetilmesi anlamlı olan projeler ve ilişkili çalışmalardan oluşur. Portföy ise stratejik hedeflere göre yatırım seçimi ve kaynak tahsisi problemidir. Program yönetimi “işleri birlikte nasıl teslim ederiz?”, portföy yönetimi ise “hangi işlere neden yatırım yapmalıyız?” sorusuna daha yakındır.

Portföy seviyesinde aynı kaynak havuzunu kullanan projeler arasında optimizasyon gerekir. Her proje kendi başına pozitif NPV veya güçlü teknik gerekçe sunsa bile organizasyonun aynı anda hepsini yürütecek mühendis, bütçe veya test altyapısı olmayabilir.

15.8. Proje Seçimi ve Finansal Değerlendirme

Portföy ve proje başlatma kararlarında basit finansal araçlar kullanılabilir:

• Net Present Value (NPV),
• Internal Rate of Return (IRR),
• payback period,
• benefit-cost ratio.

NPV gelecekteki nakit akışlarını iskonto eder. En kısa payback her zaman en yüksek stratejik değeri sunmaz. Kamu, güvenlik, mevzuat veya emniyet projelerinde finansal getiri tek seçim ölçütü olamaz.

15.9. PMO'nun Farklı Biçimleri

PMO yalnız şablon ve rapor isteyen bir ofis olmak zorunda değildir. Destekleyici, kontrol edici veya yönlendirici yetki düzeyleri olabilir. Modern PMO; ortak veri, kaynak görünürlüğü, metodoloji, koçluk, portföy koordinasyonu ve bağımlılık yönetimi sağlayabilir.

15.10. Kapanış ve İdari Tamamlama

Kapanış yalnız son faturayı ödemek değildir. Şunları içerir:

• teslimatın resmî kabulü,
• açık değişiklik/claim'lerin kapatılması,
• sözleşmelerin tamamlanması,
• belgelerin arşivlenmesi,
• operasyon devri,
• kaynakların serbest bırakılması,
• öğrenilen derslerin kaydı.

Erken iptal edilen proje de kapatılmalıdır. Aksi halde mali, sözleşmesel ve teknik yükümlülükler belirsiz kalır.

15.11. Operasyona Geçiş — Derinleştirme

Teslimat ile kullanım arasında geçiş planı gerekir. Eğitim, veri göçü, cutover, rollback, destek seviyesi, gözlemleme, bakım prosedürü ve garanti kapsamı tanımlanır. Kritik sistemlerde “go-live” tek yönlü kapı olarak tasarlanmamalı; kontrollü geri dönüş mümkün olmalıdır.

15.12. Öğrenilen Dersler ve Kurumsal Hafıza

Lessons learned yalnız proje sonunda “ne iyi/ne kötü gitti” toplantısı değildir. Proje boyunca toplanabilir. Dersin işe yaraması için olay, neden, etki, bağlam ve gelecekte uygulanacak davranış açık olmalıdır.

Kötü örnek:

İletişim daha iyi olmalıydı.

İyi kayıt:

Olay    : API şema değişikliği entegrasyon ekibine iki gün geç ulaştı.
Neden   : Şema sahibi ve bildirim kanalı tanımlı değildi.
Etki    : Entegrasyon testi dört gün kaydı.
Eylem   : API şema değişikliği için sahip + otomatik kontrat testi + duyuru kuralı.

15.13. Proje Sonrası Değerlendirme

Proje teslim edildiğinde beklenen faydanın gerçekten oluşup oluşmadığı ayrıca değerlendirilmelidir. Yeni sistem zamanında devreye girmiş olabilir fakat hedeflenen maliyet azalmasını veya kalite artışını üretmemiş olabilir. Bu nedenle ürün teslimatı ile fayda gerçekleşmesi aynı kilometre taşı değildir.

15.14. Bilgi Yönetimi, Devir ve Kurumsal Hafıza

Kurumsal öğrenme yalnız doküman üretmek değildir. Bir sistemin nasıl çalıştığına ilişkin bilgi; kod, tasarım kararı, runbook, olay kaydı, test, yapılandırma, veri modeli ve insanların deneyimi arasında dağılmış olabilir. Yönetim problemi bu bilginin bulunabilir, doğrulanabilir ve devredilebilir hale gelmesidir.

Özellikle iki bilgi türünü ayırmak yararlıdır:

• açık bilgi: yazılı prosedür, ADR, şema, runbook, test ve teknik kayıtla taşınabilir,
• örtük bilgi: deneyimle edinilmiş karar sezgisi, failure-mode tanıma ve bağlamsal yargı gibi doğrudan dokümana indirgenmesi zor bilgidir.

Örtük bilgiyi yalnız "doküman yaz" talimatıyla aktarmaya çalışmak yetersiz kalabilir. Pair review, ortak problem çözme, gölgeleme, rotasyon, olay incelemesi ve gerçek operasyon senaryosu üzerinden devir, karar bağlamını görünür hale getirir.

Teknik kurumsal hafıza için her kaydın en azından şu metadata'sı düşünülmelidir:

sahip
kapsam
geçerli sürüm / sistem
son doğrulama tarihi
kanıt veya kaynak
yerine geçen yeni kayıt / emeklilik durumu

Eski fakat kolay bulunan doküman, hiç doküman olmamasından daha tehlikeli olabilir. Bu nedenle bilgi tazeliği de kalite özelliğidir.

Devir başarısı yalnız belge sayısıyla ölçülmemelidir. Daha güçlü kabul testi, yeni sorumlunun bağımsız olarak şu işleri yapabilmesidir:

sistemi kur / çalıştır
normal durumu gözle
kontrollü hata senaryosunu teşhis et
geri kazanım veya rollback uygula
kararın dayandığı teknik kaynağı bul

Bu yaklaşım kurumsal hafızayı arşivcilikten çıkarıp operasyonel kapasitenin parçası haline getirir. "Bus factor" benzeri tek-kişiye bağımlılık göstergeleri de cezalandırılacak skor değil, bilgi aktarımı ve yedeklilik gerektiren bir risk sinyali olarak okunmalıdır.

Ünite 16: Mühendislik Yönetiminde Uygulama İlkeleri

Mühendislik yönetimini tek bir metodolojiye indirgemek yerine aşağıdaki ilkeler daha kalıcıdır:

1. Problemi çözümden önce tanımlayın. Teknoloji seçimini problem tanımının yerine koymayın.
2. Karar haklarını açık tutun. Herkesin sorumlu olduğu işte çoğu zaman kimse hesap verebilir değildir.
3. Belirsizliği saklamayın. Tek tarih ve tek maliyet yerine varsayım ve güven aralığını görünür kılın.
4. Kapsam, takvim ve maliyeti teknik gerçeklikten ayırmayın. Mimari borç ve kalite kaybı görünmeyen bütçe kalemleridir.
5. Metrikleri karar için kullanın. Rapor üretmek için metrik üretmeyin.
6. Değişikliği kontrol edin, değişime direnmeyin. Kontrollü uyarlama ile kontrolsüz kapsam kayması farklıdır.
7. Geri bildirim çevrimini kısaltın. Riskli varsayımları en erken ve en ucuz aşamada sınayın.
8. Yerel optimizasyondan kaçının. Alt ekibin verimliliği toplam sistem akışını kötüleştirebilir.
9. Teknik kararları izlenebilir kılın. Kararın yalnız sonucunu değil gerekçesini de saklayın.
10. Teslimat kadar işletilebilirliği yönetin. Proje kapanır; mühendislik ürününün yaşam döngüsü devam eder.

16.1. Etik ve Mesleki Sorumluluk

Mühendislik yöneticisi yalnız sponsorun talebini yerine getirmez; emniyet, güvenlik, mevzuat, kullanıcı etkisi ve mesleki etik sınırları da gözetir. Takvim baskısı altında kritik testin atlanması kısa vadede planı koruyabilir fakat kabul edilemez risk yaratabilir.

16.2. Güncel Standartları Tarihsel Kaynakla Birlikte Okumak

PMI süreç grupları ve bilgi alanları tarihsel proje yönetimi çerçevesinin önemli bir bölümüdür; çünkü WBS, CPM, EVM, risk ve tedarik pratikleri hâlâ mühendislik yönetiminin temel araçlarıdır. Ancak güncel PMI PMBOK Sekizinci Baskı, değer teslimi, uyarlama, yönetişim, kapsam, takvim, finans, paydaşlar, kaynaklar ve risk gibi performans alanlarını daha bütünlüklü ele alır. ISO 21502:2020 farklı teslimat yaklaşımlarına uyarlanabilen proje yönetimi rehberi sunar; ISO 21508:2026 ise EVM uygulamalarını güncel standardizasyon çerçevesinde ele alır.

16.3. İlgili Dersler

Mühendislik yönetimi, Yazılım Mühendisliği, Yazılım Test Mühendisliği, Güvenli Yazılım Mühendisliği ve Bilişsel Sistemler Mühendisliği dersleriyle birlikte ele alındığında teknik kararların yaşam döngüsü daha bütünlüklü görülebilir.

Kaynakça

• Agile Alliance. Manifesto for Agile Software Development. 2001. https://agilemanifesto.org/
• Eric, Mihail. The Modern Software Developer (CS146S). Stanford University, course materials, 2025–2026. https://themodernsoftware.dev/

• Forsberg, Kevin; Mooz, Hal; Cotterman, Howard. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems. Wiley.
• Ikujiro Nonaka; Hirotaka Takeuchi. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press, 1995. DOI: https://doi.org/10.1093/oso/9780195092691.001.0001

• INCOSE. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. 5th ed., Wiley, 2023.
• ISO. ISO 21500:2021 Project, programme and portfolio management — Context and concepts. 2021.
• ISO. ISO 21502:2020 Project, programme and portfolio management — Guidance on project management. 2020.
• ISO. ISO 21508:2026 Project, programme and portfolio management — Earned value management. 2026.
• ISO. ISO 21511:2018 Work breakdown structures for project and programme management. 2018.
• ISO. ISO 21512:2024 Project, programme and portfolio management — Earned value management implementation guidance. 2024.
• ISO. ISO 21512:2024/Amd 1:2026 Project, programme and portfolio management — Earned value management implementation guidance — Amendment 1. 2026.
• ISO. ISO 21513:2026 Project, programme and portfolio management — Guidance on post-project and post-programme evaluation. 2026.
• Kerzner, Harold. Project Management: A Systems Approach to Planning, Scheduling, and Controlling. Wiley.
• Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 8th ed., 2025.
• Schwaber, Ken; Sutherland, Jeff. The Scrum Guide. November 2020. https://scrumguides.org/

• Heather Adkins; Betsy Beyer; Paul Blankinship; Piotr Lewandowski; Ana Oprea; Adam Stubblefield. Building Secure & Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems. O’Reilly Media, 2020.

• Martin Kleppmann. Designing Data-Intensive Applications. 1st ed. O’Reilly Media, 2016.

• Miller, Richard H. UX for Enterprise ChatGPT Solutions: A Practical Guide to Designing Enterprise-Grade LLMs. Packt Publishing, 2024. ISBN 978-1-83546-119-8.
• Zahra Zohrevand; Uwe Glässer. Should I Raise The Red Flag? A Comprehensive Survey of Anomaly Scoring Methods toward Mitigating False Alarms. arXiv, 2019. https://arxiv.org/abs/1904.06646