Tek kişi mi, ekip mi? Bir projenin asgari kadrosu beceriler, bağımlılıklar ve riske göre nasıl belirlenir?

Araştırmalar "küçük ekipler her zaman daha iyidir" ya da "büyük ekipler her zaman daha fazla üretir" gibi basit bir kuralı desteklemiyor.

2023'te yayımlanan, 208 bağımsız etkiyi ve 21.435 ekibi kapsayan bir meta-analiz, ekip büyüklüğü ile görev performansı arasında genel olarak neredeyse sıfır ilişki buldu; ancak bağlama göre çok büyük farklılıklar da tespit etti. Yazarlar, ekip büyüklüğünün etkisinin görev karmaşıklığı ve koordinasyon gereksinimleri gibi unsurlarla değiştiğini gösteriyor. [4]

Karmaşık bir kriz haritalama görevi üzerindeki deney de büyük ekiplerin hem fayda hem maliyetlerini gösterdi: ekip büyüdükçe iş birliği arttı, ancak bireysel çaba örüntüleri de değişti. Bu belirli deneyde en büyük ekipler, aynı sayıda bağımsız çalışan kişiden daha iyi sonuç aldı. Bu, her çalışma türü için evrensel bir reçete değildir. [5]

Pratik sonuç basittir: kişi sayısı sihirli bir rakamdan değil, işin niteliğinden çıkmalıdır.

2020 Scrum Guide, Scrum Team'i küçük, farklı becerileri bir arada barındıran ve kendi işini yöneten bir ekip olarak tanımlar. Ayrıca böyle bir ekibin genellikle 10 veya daha az kişiden oluştuğunu belirtir. [3]

Bu, Scrum bağlamında yararlı bir rehberdir; ancak bütün projeler, hizmetler, sektörler ve çalışma modelleri için evrensel bir yasa değildir.

Bir inşaat projesi, pazarlama kampanyası, güvenlik değerlendirmesi, finans sistemi ve küçük bir bilgilendirme sitesi çok farklı gereksinimlere sahiptir. Tek bir sayı bu bağlamlar arasında doğrudan taşınmamalıdır.

Birleşik Krallık Service Standard, dijital hizmet ekiplerinin çok disiplinli olmasını ve uygun beceri çeşitliliğine erişmesini ister. Ayrıca ekip yapısının ilgili aşamada neyin başarılması gerektiğine göre şekillenmesi gerektiğini söyler. [1]

Ayrı GOV.UK rehberliği, ekip büyüklüğü ve gereken rollerin hizmetin farklı aşamalarında değiştiğini belirtir. [2]

Buradan pratik bir kural çıkar:

önce işi ve sorumlulukları çıkarın, sonra gereken becerileri belirleyin ve en son bunları belirli kişilere atayın.

Kapsam belirsizse ekip doğru boyutlandırılamaz.

En azından şunları yazın:

• hangi sonuç üretilecek,
• kapsamda neler var,
• kapsam dışında neler var,
• en önemli kalite gereksinimleri neler,
• zaman ve bütçe sınırları neler,
• sonucu kim kabul edecek,
• ekip yalnızca teslim mi edecek, yoksa çözümü işletmek de kapsamda mı.

"Bir uygulama yapmak" ile "bir uygulamayı tasarlamak, yapmak, güvenli hale getirmek, yayına almak ve bir yıl işletmek" tamamen farklı iş kapsamları gerektirir.

Hemen görev unvanları yazmak yerine gerçekten yapılması gereken iş türlerini listeleyin.

Bir dijital hizmette örneğin:

• kullanıcı ihtiyaçlarını anlamak,
• çözümü tasarlamak,
• kullanıcıya görünen katmanı oluşturmak,
• sunucu tarafı mantığı ve entegrasyonları geliştirmek,
• test etmek,
• güvenlik,
• erişilebilirlik,
• yayına alma ve işletim,
• kapsamı ve kararları koordine etmek.

Başka bir proje türünde liste farklı olacaktır.

GOV.UK, dijital bir hizmeti kuran ve işleten ekibin kullanıcı ihtiyaçları, tasarım, geliştirme, test, güvenlik, dağıtım ve canlı işletim dahil geniş bir beceri yelpazesine sahip olması gerektiğini belirtir. [2]

Her gerekli beceri ekipte tam zamanlı bir kişi gerektirmez.

Her alanı şöyle sınıflandırın:

Sürekli - düzenli olarak gerekir ve günlük kararları doğrudan etkiler.
Dönemsel - belirli aşamalarda veya kontrol noktalarında gerekir.
Dışarıdan erişilebilir - yanıt süresi ve sorumluluk yeterince açık ise başka bir kişi veya ekip tarafından sağlanabilir.

GOV.UK, uzman bilginin ekip için erişilebilir olmasını, uzmanın sürekli ekip üyesi olmasına gerek kalmadan açıkça mümkün görür. [1]

Bu, önemli uzmanlığı kaybetmeden ekibi gereksiz yere büyütmeyi çoğu zaman önler.

İki kişi birlikte gereken bütün becerilere sahip olabilir, ancak tüm iş dar bir bağımlılık zincirindeyse yine de kötü bir kadro olabilir.

Şunları kontrol edin:

• hangi görevler paralel ilerleyebilir,
• hangileri diğerlerini beklemek zorunda,
• sonraki işi engelleyen kararları kim alıyor,
• proje hangi dış ekip veya tedarikçilere bağlı,
• bir kişinin yokluğu nerede birden fazla alanı aynı anda durdurur.

GOV.UK, diğer ekiplere olan bağımlılıkları yönetmeyi dijital hizmetlerin kurulması için gerekli beceriler arasında sayar. [2]

Bir hizmet üzerinde birden fazla ekip çalıştığında, ekipler arasında plan ve ilerlemeyi koordine etmek için ek ihtiyaç doğar. [8]

Bazı gerekli uzmanlıklar ürün özellikleri listesinde görünmez, ancak yoklukları pahalı olabilir.

Projeye göre bunlar şunları içerebilir:

• güvenlik,
• veri koruma,
• erişilebilirlik,
• hukuki veya sektörel gereksinimler,
• güvenilirlik,
• veri taşıma,
• kritik sistemlerle entegrasyonlar,
• ekibin daha önce kullanmadığı teknoloji.

GOV.UK, proje ihtiyaç duyduğunda uzman bilgisine erişimi önerir ve ekip yapısının ilgili aşamadaki en riskli varsayımları da yansıtması gerektiğini belirtir. [1]

Bu, her risk için ayrı tam zamanlı bir rol gerektiği anlamına gelmez. Ancak yetkin bir kişinin açık sorumluluğu ve kararlara gerçek etki gücü olmalıdır.

Bir kişi tasarım, geliştirme, test ve yayına alma konularını biliyor olabilir. Bu, bütün bu işleri aynı anda ve her teslim tarihinde yapabileceği anlamına gelmez.

PMI'nin kaynak planlamasıyla ilgili materyali, beceriler, uygunluk, maliyet ve deneyimin proje ihtiyaçlarıyla eşleştirilmesinin önemini vurgular. [7]

Her kişi için kontrol edin:

• gerçekte ne kadar zaman ayırabilir,
• hangi görevler dikkat için birbiriyle yarışır,
• hangi işler paralel yürümek zorunda,
• sürenin birçok iş türü arasında gerçekçi olmayan geçişler varsayıp varsaymadığı,
• yayından sonra çözümü işletmek için birinin gerekip gerekmediği.

Becerileri karşılayıp zamanı karşılamamak, projeyi tam karşılamak değildir.

Asgari kadro sürekliliği de hesaba katmalıdır.

Sorun:

• kilit kişi uygun değilse ne olur,
• kritik bir parçayı yalnızca bir kişi mi anlıyor,
• kararlar ve bilgi belgeleniyor mu,
• başka biri en önemli işleri devralabilir mi,
• yokluk sırasında proje güvenli şekilde durabilir mi.

Her küçük proje tam yedeklilik gerektirmez. Kısa ve düşük riskli projede bu riski bilinçli kabul etmek makul olabilir.

Kritik bir projede aynı tek kişiye bağımlılık kabul edilemez olabilir.

Bir proje her rol adı için ayrı bir kişi gerektirmez.

Bir kişi gerçekten gereken becerilere sahipse, yeterli kapasitesi varsa ve kabul edilemez risk yaratmıyorsa birden fazla alanı sorumlu biçimde karşılayabilir.

Örneğin küçük bir projede bir kişi arayüz tasarımı ile uygulamayı birleştirebilir. Başka bir projede iş analizi ile kapsam koordinasyonunu bir arada yürütebilir.

Sorumlulukları sadece "birinin yapması gerekiyor" diye birleştirmeyin. Birleştirme ancak kişi iki sorumluluğu da gereken düzeyde yapabiliyor ve yeterli zamanı varsa anlamlıdır.

Aşağıdaki koşullar birlikte sağlanıyorsa tek kişi makul bir kadro olabilir:

• kapsam küçük ve iyi tanımlı,
• gereken beceriler gerçekten kişinin yetenekleri içinde,
• görevler çok fazla paralel çalışma gerektirmiyor,
• dış bağımlılıklar sınırlı,
• risk kabul edilebilir,
• süre gerçek kapasiteyle uyumlu,
• yedek kişi olmaması bilinçli olarak kabul edilmiş.

Küçük bir bilgilendirme çıktısı, basit analiz, tek seferlik danışmanlık veya bilinen ortamda sınırlı bir uygulama buna örnek olabilir.

Yine de belirleyici olan gerçek kapsamdır. "Küçük proje" etiketi tek başına cevap vermez.

Aşağıdaki koşullardan birkaçı oluştuğunda ekip daha güçlü biçimde gerekçelendirilir:

• gereken beceriler tek kişi için fazla geniş,
• birçok iş paralel ilerlemek zorunda,
• süre gerçekçi sıralı uygulamadan daha kısa,
• çok sayıda bağımlılık ve arayüz var,
• risk bağımsız uzman bilgisi gerektiriyor,
• çözüm aynı anda hem geliştirilmeli hem işletilmeli,
• tek kişi bütün proje için kritik nokta haline gelecek,
• sorumluluk farklı disiplinlere yayılıyor.

Bu koşullarda eksik becerileri eklemek, yalnızca kişi sayısını artırmaktan daha önemlidir.

İnsan eklemek mevcut bilgi havuzunu ve potansiyel kapasiteyi artırır; ancak bağımlılıkları, iş devrini ve kararları uyumlandırma ihtiyacını da artırabilir.

Journal of Systems and Software'da yayımlanan yazılım projeleri araştırması, ekip büyüklüğü, üretkenlik, çaba ve zaman arasındaki ilişkilerin karmaşık olduğunu ve sezgisel beklentileri her zaman doğrulamadığını gösterdi. [6]

Ekip büyüklüğü meta-analizi de sonuçların görev bağlamına ve ekip süreçlerinin maliyetlerine bağlı olduğunu gösteriyor. [4]

Dolayısıyla soru "kaç kişi ekleyebiliriz?" değil, "sonraki kişi gerçek bir proje kısıtını koordinasyon maliyetini artırdığından daha fazla azaltıyor mu?" olmalıdır.

Her önemli becerinin her gün ekipte bulunması gerekmez.

Sürekli bulunma, kişi düzenli olarak karar alıyorsa, işi diğer alanlarla çok sayıda bağımlılık içeriyorsa veya hızlı yanıt gerekiyorsa daha anlamlıdır.

Dönemsel destek, uzmanlığa belirli noktalarda, örneğin inceleme, danışmanlık, risk değerlendirmesi veya uzman onayı için ihtiyaç duyuluyorsa yeterli olabilir.

Tek koşul şudur: erişim gerçek olmalıdır. Şunlar açık olmalıdır:

• kim sorumlu,
• ne zaman erişilebilir,
• beklenen yanıt süresi nedir,
• hangi kararları alabilir,
• sorun bulursa ne olur.

Tanımlı sorumluluk olmadan bir uzmana kağıt üzerinde erişim, organizasyon şemasında iyi görünüp gerçek projede işe yaramayabilir.

Amacın çevrimiçi bir rezervasyon sistemi başlatmak olduğunu varsayalım.

Seçenek A: fikri test etmek için basit prototip
Kapsam sınırlı, ödeme veya özellikle hassas veri yok ve amaç süreci küçük bir kullanıcı grubuyla test etmek. Çok yönlü bir kişi tasarım ve uygulamayı karşılayabilir, gerektiğinde dönemsel danışmanlık alınabilir.

Seçenek B: hesaplar, ödemeler ve entegrasyonlar içeren kamuya açık hizmet
Daha fazla uzmanlaşma, test, risk, bağımlılık ve paralel iş ortaya çıkar. Birkaç kişilik ekip çok daha gerekçeli hale gelir.

Seçenek C: sürekli çalışan ve sorunlara hızlı yanıt gerektiren hizmet
Geliştirmeye işletim, izleme, olaylara yanıt ve bilgi sürekliliği eklenir. Yayına çıkmak için yeterli kadro, sürdürülebilir işletim için yeterli olmayabilir.

Genel ürün türü aynı olsa da farklı kapsam, risk ve işletim modeli farklı ekip ihtiyaçları doğurur.

1. Yapılacak işten değil, hazır görev unvanları listesinden başlarsınız.

2. Her rolün ayrı kişi gerektirdiğini varsayarsınız.

3. Yalnızca becerilere bakar, mevcut zamanı görmezden gelirsiniz.

4. Bağımlılıkları ve darboğazları kaldırmadan kişi eklersiniz.

5. Görünür ürün özelliği üretmediği için risk kaynaklı becerileri atlarınız.

6. Riski bilinçli kabul etmeden birden fazla kritik alanı tek kişiye bağlarsınız.

7. Proje başındaki kadroyu sonuna kadar değişmez kabul edersiniz.

GOV.UK, ekip büyüklüğü ve rollerin hizmet geliştirme aşamalarında değiştiğini açıkça belirtir. [2]

Bu ilke kamu hizmetleri dışında da mantıklıdır:

• başlangıçta daha fazla araştırma ve problem tanımı gerekebilir,
• uygulama sırasında üretim ve test becerileri önem kazanır,
• yayından önce güvenlik, kalite ve işletim hazırlığına daha fazla ihtiyaç olabilir,
• yayından sonra geliştirme ile işletim arasındaki denge değişir.

Asgari kadro, aşama ve kapsamın özelliğidir; projeye sonsuza kadar atanmış sabit bir sayı değildir.

Her önemli alan için beş şeyi yazın:

İş alanı - ne yapılmalı?
Beceri - hangi bilgi ve yetenek gerekli?
Sorumluluk - kim karar veriyor ve sonuçtan sorumlu?
Erişilebilirlik - beceri sürekli, dönemsel veya dışarıdan mı?
Yokluk riski - beceri eksikse veya kişi uygun değilse ne olur?

Ancak bundan sonra belirli kişileri atayın.

Bir kişi birden fazla satırı karşılıyorsa zamanı ve bağımlılıkları kontrol edin. Bir satır birkaç kişi gerektiriyorsa sebebin kapasite, bağımsız kontrol veya paralel iş olup olmadığını belirleyin.

1. Zorunlu her iş alanının sorumlusu var mı?
2. Her kritik sorumluluk doğru beceriye sahip biri tarafından karşılanıyor mu?
3. Bir kişi birden fazla rol üstleniyor mu ve buna gerçekten yeterli zamanı var mı?
4. Proje mevcut kadronun karşılayamayacağı paralel çalışma gerektiriyor mu?
5. Diğer kişiler, ekipler ve tedarikçilere olan ana bağımlılıkları biliyor muyuz?
6. Önemli riskler doğru uzman bilgisine erişebiliyor mu?
7. Tek bir kişinin yokluğu bütün projeyi durdurabilir mi?
8. Kadro yalnızca geliştirmeye değil, kapsamdaysa yayına alma ve işletime de yeterli mi?
9. Hangi becerilerin sürekli yerine dönemsel olabileceğini biliyor muyuz?
10. Kapsam veya aşama değiştiğinde kadroyu yeniden değerlendireceğimiz noktaları belirledik mi?

Ekip tasarımı şu soruyla başlamamalıdır:

"Böyle projelerde genelde kaç kişi gerekir?"

Daha iyi sıra:

sonuç -> iş -> beceriler -> bağımlılıklar -> risk -> kapasite -> kişiler.

Bu sıralamadan sonra tek kişi gerçekten her şeyi karşılıyorsa, doğru seçim tek kişi olabilir.

Beceri, zaman, bağımsız kontrol, süreklilik veya paralel çalışma imkanı eksikse ek kişilere ya da güvenilir uzman erişimine ihtiyaç vardır.

Amaç en küçük ekip değildir. Amaç, gereken sonucu gerekli risk ve kalite düzeyinde gerçekçi biçimde sağlayabilen en küçük kadrodur.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Kaynağı aç

[2] GOV.UK Service Manual - Set up a service team at each phase
Kaynağı aç

[3] The Scrum Guide, 2020 - Scrum Team
Kaynağı aç

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Kaynağı aç

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Kaynağı aç

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Kaynağı aç

[7] Project Management Institute - Solving The Resource Puzzle
Kaynağı aç

[8] GOV.UK Service Manual - Running more than one service team
Kaynağı aç

Metodoloji notu: Bazı kaynaklar dijital kamu hizmetlerini, bazıları Scrum ekiplerini, proje yönetimini veya ekipler ve yazılım geliştirme araştırmalarını ele alır. Bu rehber her kaynağı yalnızca desteklediği noktalar için kullanır. Yedi adımlı asgari kadro yöntemi bu ilkelerin editoryal sentezidir; adı geçen kuruluşlardan hiçbirinin resmi standardı değildir.