MS PROJECT İLE PROJE PLANLAMA: WBS, TAKVİM, KAYNAK VE KRİTİK YOL

Proje planı, “ne yapacağız?” sorusunu cevaplamakla kalmaz; aynı zamanda “ne zaman, kimle, hangi kısıtlarla ve hangi risklerle?” sorularını da tek bir yerde toplar. MS Project bu işi yalnızca bir Gantt şeması çizmekten ibaret görmeyen ekipler için güçlü bir omurga sağlar: kapsamı WBS ile parçalarsınız, takvimi gerçek çalışma düzenine oturtursunuz, kaynakları kapasiteye göre dengelersiniz ve kritik yolu görünür kılarak teslim tarihini yönetirsiniz.

Kurumsal yazılım geliştirme projelerinde planlama çoğu zaman iki uçta sıkışır: Ya her şey “epik–story” seviyesinde kalır ve operasyonel plan görünmez olur, ya da plan aşırı detaylanır ve kimse güncellemez. Bu makalede hedef, MS Project’i “yaşayan plan” yaklaşımıyla kullanmak: kapsamı yeterli granülerlikte tanımlayıp, takvim ve kaynak gerçekleriyle bağlamak ve projenin kritik akışını saydam hale getirmek.

Aşağıdaki adımlar; bir ürün geliştirme, platform modernizasyonu, veri migrasyonu veya entegrasyon projesinde yaygın olarak karşılaşılan ihtiyaçlara göre kurgulanmıştır. İster klasik faz bazlı ilerleyin ister iteratif teslimatlar yapın, temel prensip aynı: plan, karar vermeyi kolaylaştıran bir yönetim aracıdır.

MS Project’te proje planlamanın temel yaklaşımı

MS Project’te başarılı bir proje planlama, üç katmanın birbiriyle tutarlı kurulmasına dayanır: kapsam (WBS), zaman (takvim ve bağımlılıklar) ve kapasite (kaynaklar). Bu üç katman birbirinden kopuk kurulduğunda plan hızla anlamını yitirir; örneğin kapsam doğru olsa bile takvim şirket çalışma düzenini yansıtmıyorsa tarihler yanıltıcı olur. Benzer şekilde kaynak ataması yapılmadan kritik yol “teorik” kalabilir.

Bu nedenle planlama akışını genellikle şu sırayla ilerletmek verimlidir: önce WBS ile işi parçalayın, sonra takvimi ve çalışma zamanlarını tanımlayın, ardından bağımlılıkları kurup süreleri gerçekçi hale getirin, son olarak kaynakları atayarak kapasite–maliyet etkisini görünür kılın. İlerleyen aşamada temel plan (baseline) alarak takibi başlatırsınız.

Planın hedefi: rapor değil, karar desteği

Planın amacı, haftalık durum toplantısında “ne oldu?”yu anlatmak kadar “ne yapmalıyız?” sorusuna da cevap vermektir. Bu yüzden plan, karar noktalarını, teslimat bağımlılıklarını ve kapasite baskılarını ortaya çıkaracak şekilde yapılandırılmalıdır. Özellikle çok ekipli ortamlarda kritik yol ve kaynak çakışmaları görünür olduğunda, yönetim aksiyonu gecikmeden alınabilir.

Yazılım geliştirmede doğru detay seviyesi

WBS’i task bazında her bir commit’e kadar bölmek planı “bakılamaz” hale getirir; yalnızca epik seviyesinde bırakmak da takvimi körleştirir. Pratik bir yaklaşım: 1–10 iş günü aralığında, teslimata hizmet eden iş paketleri tanımlamak; daha küçük işleri ekip içi araçlarda (issue tracker) yürütmek. Böylece MS Project, bütünün ritmini ve kritik akışını yönetirken, günlük operasyon ekibin çevik araçlarında kalır.

WBS ile kapsamı yönetilebilir iş paketlerine bölme

WBS (Work Breakdown Structure), kapsamı teslimat temelli parçalara ayırmanın en net yoludur. MS Project’te WBS’i kurarken hiyerarşi yalnızca “liste düzeni” değil, aynı zamanda raporlama, maliyet ve ilerleme takibi için bir iskele görevi görür. Kapsamı doğru kırdığınızda, sonradan bağımlılık ve kaynak yönetimi de daha az sürpriz üretir.

Teslimat odaklı kırılım nasıl seçilir?

Yazılım projelerinde WBS’i “aktivite” yerine “teslimat” üzerinden kurmak genellikle daha sürdürülebilirdir. Örneğin “API geliştirme” gibi geniş bir başlık yerine “Kimlik doğrulama API’si”, “Sipariş API’si”, “Raporlama API’si” gibi teslimatlara ayrılmış iş paketleri; test, dokümantasyon ve devreye alma gibi tamamlayıcı işleri de daha kolay ilişkilendirir. Bu yaklaşım, kapsam kaymasını da erken yakalamaya yardımcı olur.

Özet görevler, milestone’lar ve iş paketleri

Özet görev (summary task) yönetim seviyesinde okunabilirliği artırır. Milestone’lar ise süreye değil sonuca odaklanan kontrol noktalarıdır; sprint sonu demo, UAT tamamlandı, üretime geçiş gibi. MS Project’te milestone için genellikle süreyi 0 gün olarak belirlemek ve teslimat kriterlerini açıklama alanında netleştirmek iyi bir pratiktir. Böylece plan, “bitmiş sayılma” tanımını taşıyabilir.

WBS kodları ve raporlama disiplini

WBS kodu, iş paketlerini standart bir şemaya bağlar; özellikle çok proje portföylerinde veya entegrasyon projelerinde raporlama için kritik hale gelir. WBS kodlamasını faz–teslimat–bileşen şeklinde tasarlayabilir, ekiplerin aynı dili konuşmasını sağlayabilirsiniz. Bu kodlama, dış raporlama araçlarında da (Power BI gibi) birleştirme anahtarı olarak kullanılabilir.

WBS Örneği (Teslimat odaklı)
1. Başlatma
  1.1 Proje başlatma dokümanı (Milestone)
  1.2 Paydaş ve iletişim planı
2. Analiz & Tasarım
  2.1 Gereksinim atölyeleri
  2.2 Mimari tasarım ve ADR kayıtları
3. Geliştirme
  3.1 Kimlik doğrulama servisi
  3.2 Sipariş yönetimi servisi
  3.3 Entegrasyon adaptörleri
4. Test & Sertifikasyon
  4.1 Entegrasyon testleri
  4.2 Performans testleri
  4.3 UAT tamamlandı (Milestone)
5. Devreye Alma
  5.1 Üretim hazırlık kontrol listesi
  5.2 Üretime geçiş (Milestone)

Proje takvimini gerçek çalışma düzenine göre kurma

Takvim, projenin “matematiğini” belirler. Çalışma saatleri, tatiller, vardiyalar, bakım pencereleri ve ekiplerin farklı lokasyonlarda olması; tüm bunlar süre–tarih dönüşümünü doğrudan etkiler. Bu yüzden MS Project’te ilk yapılması gerekenlerden biri, varsayılan takvimi kurum gerçeklerine göre uyarlamaktır.

Standart takvim yerine ekip bazlı takvimler

Tek bir standart takvim çoğu zaman yetersiz kalır. Örneğin DevOps ekibi gece bakım pencereleriyle çalışıyorsa, test ekibinin hafta sonu regresyon koşuları varsa veya dış tedarikçi farklı ülkede tatil takvimine sahipse; görev takvimlerini ayrıştırmak gerekir. MS Project’te görev (task) veya kaynak (resource) bazında takvim atayarak bu farkları modele dahil edebilirsiniz.

Tatil, izin ve bakım pencerelerini modellemek

Resmi tatillerin yanı sıra planlı kesinti pencereleri, freeze dönemleri ve yüksek riskli değişikliklere kapalı zamanlar da planlamayı etkiler. Bu tür dönemleri “çalışma dışı” olarak işaretlemek, kritiği öngörmede şaşırtıcı derecede etkilidir. Eğer kuruluşta değişiklik yönetimi (CAB) belirli günlerde toplanıyorsa, onay akışını da bu pencereye bağlamak planın gerçekçiliğini artırır.

Süre tahmini, bağımlılıklar ve kısıtların doğru kurgusu

MS Project’in hesap motoru, süreleri ve bağımlılıkları doğru verdiğinizde size güçlü bir görünürlük sunar. Ancak yanlış kısıt kullanımı veya gelişi güzel link’ler planı “taşa çevirebilir”. Özellikle “Must Start On” gibi sert kısıtlar, kritik yolun doğasını bozar ve gecikmeleri gizleyebilir. Bu yüzden öncelik; bağımlılık türlerini doğru seçmek ve kısıtları minimumda tutmaktır.

FS, SS, FF, SF bağımlılıkları ne zaman kullanılır?

En yaygın ilişki Finish-to-Start (FS) olsa da yazılım projelerinde Start-to-Start (SS) ve Finish-to-Finish (FF) ilişkileri çok iş görür. Örneğin “API geliştirme” ile “Frontend entegrasyonu” tamamen ardışık değilse SS ile başlatıp, “Entegrasyon testleri”ni FF ile tamamlanmaya bağlamak daha gerçekçi olabilir. Böylece paralel çalışma modeli plan üzerinde doğal görünür.

Lead/Lag kullanımı: paralellik ve bekleme süreleri

Lead (öne alma) ve Lag (geciktirme) değerleri; kod inceleme, güvenlik taraması, ortam sağlama gibi bekleme sürelerini modellemek için kullanılabilir. Örneğin “SAST taraması”nın sonuçlanması 1 gün sürüyorsa lag ile göstermek, işleri takvim üzerinde “neden bekliyor?” sorusuna açık yanıt verir. Bu kullanım, iletişim maliyetini düşürür ve planın açıklanabilirliğini artırır.

Kısıtlar yerine tarihlerin doğal hesaplanması

Bir görevin mutlaka belirli bir tarihte başlaması gerekiyorsa önce bunun sebebini netleştirin: dış bağımlılık mı, sözleşme tarihi mi, ortam erişimi mi? Çoğu durumda sert kısıt yerine bir milestone ve buna bağlı bağımlılıklar daha sağlıklıdır. Bu yaklaşım, planın “itilebilir” olmasını sağlar; yani senaryoları test ettiğinizde model bozulmaz.

Bağımlılık örnekleri (özet mantık)
- API sözleşmesi onayı (Milestone) FS-> Backend geliştirme
- Backend geliştirme SS+2g -> Frontend entegrasyonu (2 gün sonra paralel başlar)
- Frontend entegrasyonu FF -> Entegrasyon testleri (ikisi birlikte tamamlanmalı)
- UAT hazırlıkları FS -> UAT koşuları
- UAT koşuları FS -> Üretime geçiş (Milestone)

Kaynak planlama: kapasite, maliyet ve sorumlulukların netleşmesi

Kaynak yönetimi, MS Project’i sıradan bir zaman çizelgesinden çıkarıp gerçek bir yönetim aracına dönüştürür. Kaynak ataması yaptığınızda; görevlerin ne kadar “iş” (work) gerektirdiğini, ekip kapasitesinin bunu ne kadar taşıdığını ve maliyet etkisini görmeye başlarsınız. Bu aşamada amaç, her göreve isim yazmak değil; kapasiteyi görünür kılacak minimum doğru modeli kurmaktır.

Kaynak türleri: Work, Material, Cost

Yazılım projelerinde çoğunlukla Work kaynakları (insan emeği) kullanılır. Lisans, bulut tüketimi veya test ortamı gibi kalemler için Cost kaynakları; donanım gibi kalemler için Material kaynakları tercih edilebilir. Bu ayrım, maliyet raporlamasında doğru sınıflandırma sağlar. Ayrıca bazı kuruluşlarda dış tedarikçi bütçeleri için ayrı Cost kaynakları oluşturmak, sözleşme yönetimini kolaylaştırır.

Takım bazlı planlama ve rol seviyesinde kaynaklar

İsim bazlı planlama, organizasyonel değişikliklerde hızlı kırılır. Özellikle uzun projelerde rol bazlı plan (Backend Dev, QA, DevOps gibi) daha dayanıklıdır. İsterseniz kritik noktalarda isim seviyesine inebilirsiniz. Bu yaklaşım, projeyi kişilere bağımlı kılmadan kapasiteyi yönetmenizi sağlar; aynı zamanda tedarikçi veya işe alım senaryolarını daha rahat test edersiniz.

Kaynak dengeleme (leveling) ve bilinçli trade-off’lar

Kaynak leveling otomatik bir “mucize” değildir; ama çakışmaları görünür kılar. Leveling sonrası tarihler kayıyorsa iki seçeneğiniz vardır: kapsamı yeniden dilimlemek veya ek kapasite sağlamak. Burada kritik olan, kararın veriye dayanmasıdır. MS Project’te over-allocation raporları ve kaynak kullanım görünümleri, hangi rolün darboğaz olduğunu açıkça gösterebilir.

Basit maliyet modeli örneği (rol bazlı)
Rol, Saatlik Maliyet, Haftalık Kapasite
Backend Developer, 45, 30
QA Engineer, 40, 25
DevOps Engineer, 55, 20

Uygulama ipucu:
- Görev sürelerini "Duration" ile, eforu "Work" ile ayırın.
- Aynı sürede daha fazla efor gerekiyorsa, Work artar; kaynak baskısı görünür olur.

Kritik yol analizi: teslim tarihini belirleyen zinciri görünür kılma

Kritik yol, projenin bitiş tarihini belirleyen görev zinciridir. Bu zincirdeki bir gecikme, doğrudan teslim tarihini iter. Yazılım projelerinde kritik yol bazen “test ve onay” tarafında, bazen de “ortam hazırlığı ve devreye alma” tarafında çıkar. Bu yüzden kritik yol analizi, yalnızca geliştirme planına bakmak değil; uçtan uca akışı modellemek demektir.

Kritik yolun sık değişmesinin nedeni

Kritik yol sabit değildir; kaynak ataması, paralellik derecesi, kısıtlar ve tamponlar değiştikçe kritik zincir yer değiştirir. Örneğin performans test ortamı gecikirse kritik yol test fazına kayar. Bu yüzden kritik yol analizi “bir kere bakıp geçilecek” bir şey değil; plan güncellendikçe tekrar kontrol edilecek bir yönetim pratiğidir.

Float ve tampon yönetimi

Toplam boşluk (total slack/float), bir görevin gecikmeden ne kadar esneyebileceğini gösterir. Float’ı yüksek olan işler “önemsiz” değildir; ancak teslim tarihi açısından esnek olduklarını bilmek, önceliklendirmeyi iyileştirir. Program yöneticileri için en kıymetli bilgi; hangi işlerin tamponu tükettiği ve hangi tarihte riskin “kırmızıya” döndüğüdür.

Kritik yol ile kritik zincir farkı

Kritik yol, takvim bazlı en uzun bağımlılık zinciridir; kritik zincir yaklaşımı ise kaynak kısıtlarını merkeze alır. Eğer ekipleriniz aynı anda birden fazla kritik iş taşıyorsa, kritik zincir perspektifi daha gerçekçi olabilir. MS Project’te doğrudan kritik zincir metodolojisi uygulanmasa da kaynak çakışmalarını ve teslimat riskini birlikte okuyarak benzer içgörü elde edebilirsiniz.

İlerleme takibi: baseline, gerçekleşenler ve öngörü

Planı oluşturmak kadar, planı yaşatmak da önemlidir. İlerleme takibi için önce temel plan (baseline) almak gerekir; aksi halde “sapma” kavramı anlamsızlaşır. Baseline; başlangıç, bitiş, süre, iş ve maliyet gibi alanların referans kopyasıdır. Güncelleme döngünüz (haftalık/iki haftalık) ne olursa olsun, güncellemeleri disiplinli ve tutarlı yapmak gerekir.

Baseline alma ve değişiklik yönetimi

Baseline aldıktan sonra kapsam veya tarih değişiyorsa, bunun bir değişiklik kaydıyla (change request) yönetilmesi gerekir. Aksi halde plan “her hafta yeniden yazılan” bir tabloya döner. Bazı kuruluşlarda faz bazlı baseline yaklaşımı kullanılır: her faz için ayrı baseline; böylece geçmiş performans korunur, yeni faz planı güncellenebilir.

Gerçekleşen iş girişi: yüzde mi, saat mi?

İlerleme girişinde iki yaygın yöntem vardır: yüzde tamamlanma (% Complete) veya gerçekleşen iş/saat (Actual Work). Yazılım projelerinde “yüzde” bazen subjektif olabilir; ama düzenli ölçüm yapılıyorsa pratiktir. Eğer zaman kayıtları (timesheet) ile entegre çalışıyorsanız Actual Work daha sağlıklı olabilir. Önemli olan, aynı projede karışık yöntemlerle veri girmemek ve ekiplerin aynı ölçüm dilini kullanmasıdır.

Earned Value mantığını basitçe kullanmak

Earned Value Management (EVM) kulağa ağır gelebilir; ancak basit yorumla bile güçlü bir erken uyarı sağlar. Planlanan değer (PV), kazanılmış değer (EV) ve gerçekleşen maliyet (AC) arasındaki farklar; gecikmenin mi yoksa verimsizliğin mi öne çıktığını gösterebilir. Özellikle büyük ölçekli dönüşüm projelerinde, yalnızca “geciktik” demek yerine gecikmenin finansal etkisini de görmek önemlidir.

Raporlama, paydaş iletişimi ve planın paylaşımı

Planı paydaşlar için anlaşılır kılmak, MS Project kullanımının en kritik yanlarından biridir. Teknik ekip detay görünümden çalışırken, yönetim için özet görünüm gerekir. Bu nedenle görünüm (view) ve filtre (filter) setleri oluşturmak; haftalık raporlamayı ciddi biçimde hızlandırır. Ayrıca riskli iş paketlerini vurgulayan özel alanlar veya etiketler kullanmak, toplantılarda “nereden başlayalım?” sorusunu ortadan kaldırır.

Gantt, Timeline ve milestone raporları

Gantt, operasyonel planı; Timeline ise üst seviye hikâyeyi anlatır. Milestone raporları, dış paydaşların çoğu zaman ihtiyaç duyduğu minimum bilgiyi taşır: “hangi tarihte ne teslim edilecek?” Eğer planı birden fazla hedef kitleye sunuyorsanız, aynı veriyi farklı görünümle sunmak en doğru yaklaşımdır.

Kurumsal eğitim ve standartlaştırma

MS Project’i ekipler arası standarda dönüştürmek istiyorsanız; WBS şablonları, takvim standartları, kaynak rolleri ve raporlama kuralları üzerinde uzlaşmak gerekir. Bu alanda hızlanmak için MS Project Eğitimi ile ekiplerin aynı modelleme dilini kullanması sağlanabilir. Böylece planlar birbirine benzer, portföy seviyesinde karşılaştırma daha kolay hale gelir.

Sık yapılan hatalar ve uygulanabilir iyi pratikler

MS Project’te en sık görülen sorun, planın “güncellenmeyen bir belge”ye dönüşmesidir. Bunun temel nedeni, planın gerçek hayattaki akışı yeterince temsil etmemesi veya güncelleme yükünün tek bir kişide toplanmasıdır. Aşağıdaki pratikler, planı yaşayan bir yönetim aracına çevirmeye yardımcı olur.

• WBS’i teslimat odaklı kurun, sprint içi mikro işleri ayrıca yönetin.
• Sert kısıtları minimumda tutun; bağımlılık ve milestone ile modelleyin.
• Rol bazlı kaynaklarla başlayın; kritik noktalarda isim seviyesine inin.
• Baseline alın ve değişiklikleri kayıt altına alarak yönetin.
• Her hafta aynı gün, aynı görünüm setiyle güncelleme ve raporlama ritmi kurun.

Bu yaklaşım, planı “kimsenin bakmadığı” bir dosyadan çıkarıp, karar verme mekanizmasının parçası haline getirir. En önemlisi, plan ekiplerin gerçek çalışma biçimini yansıttığında, güncelleme bir angarya değil ortak bir kontrol sistemi olur. Bu da teslim tarihi ve kalite hedeflerine ulaşmada belirgin bir fark yaratır.