PMI PMP: Ekip Liderliği ve Kaynak Yönetimi — Çalışma kılavuzu

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Şunun bir parçası: PMP — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: PMI sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Takım Oluşturma, Sözleşme ve Rol Netliği

Her yüksek performanslı takım, ilk durum toplantısıyla değil, bilinçli bir oluşum ritüeliyle başlar. Takım sözleşmesi kurucu eserdir — takımın paylaşılan değerlerini, karar alma kurallarını, saat dilimlerine göre çalışma saatlerini, iletişim sıklığını ve eszkalasyon yollarını yakalayan, birlikte oluşturulmuş bir belgedir. Projeyi yetkilendiren ve sponsoru belirleyen proje beratının aksine, takım sözleşmesi takım tarafından, takım için yazılır. Gücü, bu ortak yazarlıktan gelir: daha sonra bir geliştirici bir meslektaşının sözünü kestiğinde veya bir stand-up toplantısını kaçırdığında, proje yöneticisi kişisel otoritesini kullanmaz — takımın kendisinin oluşturduğu bir norma işaret eder.

Sözleşmenin yanı sıra, temel kurallar günlük disiplini operasyonel hale getirir: tasarım incelemeleri için kameraların açık olması, retrospektifler sırasında çoklu görev yapılmaması, sözlü güncellemeler için iki dakikalık kural, kararların 24 saat içinde belgelenmesi. Temel kurallar görünür olmalı (takım odasına asılmalı veya iş birliği kanalına sabitlenmeli) ve her iterasyonun veya faz geçişinin başında yeniden gözden geçirilmelidir. Kimsenin açmadığı bir SharePoint klasöründe duran bir sözleşme dekoratiftir; haftalık olarak başvurulan bir sözleşme ise düzenleyicidir.

Rol netliği, oluşum üçgenini tamamlar. Teslim edilecek işleri sorumlu (responsible), hesap veren (accountable), danışılan (consulted) ve bilgilendirilen (informed) taraflarla eşleştiren bir RACI (veya RASCI gibi bir varyantı) matrisi, “ben sende sanıyordum” tipi başarısızlık modunu ortadan kaldırır. Bir proje yöneticisinin haftalardır lidersiz kalmış bir grubu devraldığı yeni bir takımda, doğru ilk hamle ne agresif bir yeniden planlama ne de sponsorla derhal bir takvim pazarlığıdır. Doğru hamle, takımı bir araya getirmek, nelerin tıkandığını düşündüklerini dinlemek ve sözleşmeyi ile rol haritasını yeniden oluşturmaktır. Takım tam da bu çapalar eksik olduğu için kaybolmuş hisseder.

Liderlik Tarzını Olgunluğa Göre Uyarlama

Durumsal liderlik, liderlik tarzını bir kişilik özelliği olarak değil, bir değişken olarak ele alır. Klasik Hersey-Blanchard ilerlemesi, tarzı ekip üyesinin hazırbulunuşluğuna göre eşleştirir:

• Düşük yetkinlik, yüksek bağlılık (yeni)
  • Önerilen Tarz: Yönlendirme (Directing)
  • Davranış: Ne, ne zaman, nasıl yapılacağını söyleme
• Kısmi yetkinlik, değişken bağlılık
  • Önerilen Tarz: Koçluk Yapma (Coaching)
  • Davranış: Açıklama, kararları benimsetme, diyaloğa davet etme
• Yüksek yetkinlik, değişken bağlılık
  • Önerilen Tarz: Destekleme (Supporting)
  • Davranış: Kolaylaştırma, karar almayı paylaşma
• Yüksek yetkinlik, yüksek bağlılık
  • Önerilen Tarz: Delege Etme (Delegating)
  • Davranış: Sorumluluğu devretme

Engelleri kaldırma, takımı gürültüden koruma, onların gelişimine öncelik verme gibi bir hizmetkâr liderlik duruşu, bu modelin üzerine eklenir ancak durumsal muhakemenin yerini almaz. Hizmetkâr liderlik, müsamahakâr liderlik anlamına gelmez. Bir takım yoldan saptığında, hizmetkâr lider yine yönlendirir; sadece bunu kendi görünürlüğü yerine takımın başarısı hizmetinde yapar.

Yönsüz bir takımda laissez-faire liderlik tuzağı yaygın bir başarısızlıktır. Takımın iş hakkında ortak bir modeli olmadığında “takımın kendi kendine organize olmasına izin vermek” için geri çekilmek; kafa karışıklığına, gözden kaçan bağımlılıklara ve moral bozukluğuna yol açar. Kendi kendine organize olma, bir başlangıç koşulu değil, olgunluğun bir sonucudur. Tersine, benzer işleri daha önce beş kez teslim etmiş kıdemli mühendislere mikro yönetim uygulamak güvensizlik sinyali verir, inisiyatif almayı bastırır ve personel kaybına yol açar. Bunu gösteren işaret, proje yöneticisinin portföy seviyesindeki risk konuşmalarını görmezden gelirken bir alan uzmanının işindeki commit seviyesindeki ayrıntıları incelemesidir.

Farklı kıdem seviyelerinden oluşan bir takıma katılırken, başlangıç hamlesi bir dizi bire bir görüşme ile bir çalışma anlaşması atölyesi düzenlemektir. Bu, her bir bireyin hazırbulunuşluk yelpazesinin neresinde olduğunu ortaya çıkarır ve liderlik tarzının herkese tek tip uygulanması yerine kişiye özel ayarlanmasına olanak tanır.

Koçluk, Bire Bir Görüşmeler ve Performans Yönetimi

Genellikle iki haftada bir 30 dakika süren tekrarlayan bire bir görüşmeler; koçluk, sorunların erken tespiti ve kariyer gelişimi için birincil kanaldır. Bunlar durum toplantıları değildir. Gündemler ekip üyesine ait olmalı, proje yöneticisi ise zamanın %70’inde dinleyici konumunda olmalıdır. Konular mevcut engeller, beceri gelişimi, her iki yönde geri bildirim ve moral arasında döner.

Performans sorunları, resmi bir değerlendirme döngüsü için biriktirilmemeli, ilk gözlemlendiği anda gündeme getirilmelidir. Zorlu konuşmaları ertelemek, proje liderliğindeki en zararlı davranış kalıplarından biridir: düşük performans gösteren kişi, düzeltmek için çok geç olana kadar hiçbir şey öğrenemez, yüksek performans gösterenler durumu izler ve kendilerini geri çeker ve moral sessizce aşınır. Geri bildirim, “ilgisiz görünüyorsun” gibi öznel izlenimler yerine ölçülebilir göstergelere — hata kaçırma oranı, story döngü süresi, kod incelemesi geri dönüş süresi, toplantı katılımı, taahhüt güvenilirliği — dayanmalıdır. Ölçülebilir göstergeler, görüşmeyi gözlemlenebilir davranışlara dayandırır ve ekip üyesine somut bir hedef verir.

Fonksiyonel yöneticilere eszkalasyon veya nihayetinde kaynak değişikliği talep etmek, ancak koçluk, net beklenti belirleme ve belgelenmiş bir performans iyileştirme görüşmesi başarısız olduktan sonra haklı görülebilir. Bu adımları atlamak güvene zarar verir ve genellikle İK politikalarını ihlal eder.

Uygulamalı Problem: Örnek Senaryo

Senaryo: Priya Kapoor, orta ölçekli bir bölgesel bankada 4,2 milyon dolar bütçeli ve 14 aylık bir zaman çizelgesine sahip “Meridian” ödemeler modernizasyon projesine liderlik etmek üzere yeni atanmıştır. 11 kişilik ekip üç farklı saat dilimine yayılmıştır: Bangalore’da beş geliştirici, Londra’da üç iş analisti ve Toronto’da bir QA lideri, bir mimar ve Priya’nın kendisi bulunmaktadır. Projenin ikinci haftasında, Bangalore’daki geliştiriciler bir prototip oluşturmuş, ancak Londra’daki iş analistleri bu prototipi “herkesin okuduğunu varsaydıkları” uyumluluk gereksinimleriyle uyumsuz olduğu gerekçesiyle reddetmiştir. Toronto’daki mimar ise teknoloji yığını kararı konusunda kendisine hiç danışılmadığını iddia etmektedir.

Zorluk: Priya, proje daha da gecikmeden ve iletişim kopukluğu için herhangi bir grubu suçluyor gibi görünmeden, ekibin çalışma normlarını ve rol netliğini yeniden belirlemelidir.

Önerilen Yaklaşım:

1. Tüm 11 üyenin de dokümanları canlı olarak birlikte yazabilmesi için çakışan saatleri (Toronto 07:00–10:00 / Londra 12:00–15:00 / Bangalore 16:30–19:30) planlayarak, iki günlük bir sanal ekip oluşturma çalıştayı için aktif geliştirmeyi duraklatın.
2. Ortak çalışma saati çakışması, karar hakları, “danışılan” (consulted) ve “bilgilendirilen” (informed) tanımları, asenkron kararlar için 24 saatlik bir geri dönüş kuralı ve sponsor ile sonlanan bir eskalasyon merdivenini kapsayan bir ekip şartnamesinin ortaklaşa oluşturulmasını kolaylaştırın.
3. WBS’deki 18 ana teslimata karşılık gelen bir RASCI matrisi oluşturun. “Sorumlu"nun (Accountable) her zaman tek bir isimlendirilmiş kişi olmasını ve herhangi bir teknik yığın kararı için “Danışılan"ın (Consulted) mimarı açıkça belirtmesini sağlamak amacıyla ekiple birlikte her satırın üzerinden geçin.
4. Tasarım incelemeleri için kameraların açık olması, kararların bir iş günü içinde Confluence’a kaydedilmesi, çakışan zaman diliminde haftalık 30 dakikalık bölgeler arası senkronizasyon toplantısı gibi temel kurallar belirleyin ve bunları ekibin Slack kanalına sabitleyin.
5. Kod yazılmadan önce kimin onay vereceğini belirlemek için yeni netleştirilmiş RASCI’yi kullanarak, prototip kapsamını iş analistleri ve geliştiricilerle birlikte yeniden çalışın.
6. Ekip olgunlaştıkça normları revize etmek için her iterasyonun ilk retrospektifine sabit bir 10 dakikalık “şartname kontrolü” ekleyin.

Bu Neden İşe Yarar: Ortak yazarlık, şartnameyi bir talimattan ziyade bir akran taahhüdüne dönüştürür; bu da Proje Yöneticisine, pozisyonel otorite kullanmadan normları uygulama yetkisi verir. RASCI, uyumluluk eksikliğine yol açan “ben sende sanıyordum” boşluğunu ortadan kaldırır ve her iterasyonda normları gözden geçirmek, şartnamenin yaşayan bir anlaşma yerine dekoratif bir doküman haline gelmesini önler.

← Paydaş Katılımı ve İletişim · Tüm alanlar · Agile →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →