> tpl_peo_002
Takım Bildirgesi ve Çalışma İlkeleri
Temel misyonu, işletim ilkelerini, çekirdek çalışma saatlerini ve toplantısız odak bloklarını, kod inceleme yanıt SLA'larını, psikolojik güvenlik normlarını ve şeffaf karar alma yetkilerini (DACI/RACI) kurallara bağlayan yüksek performanslı mühendislik takımı kuruluş bildirgesi.
Takım misyonunu, odak saatlerini, PR inceleme SLA'larını, psikolojik güvenliği ve DACI karar haklarını belirleyen takım bildirgesi.
Önemli Teknik Doküman Şablonu ve Hukuki Uyarı
TinyCTO.tv Teknik Doküman Şablon Bildirimi: Bu şablon genel eğitim ve operasyon amaçlı bir başlangıç materyalidir. Hukuki, vergisel, muhasebesel, yatırım, satın alma, mevzuat, güvenlik veya sertifikasyon danışmanlığı değildir. Gereklilikler ülkeye, kuruma, sözleşmeye ve riske göre değişir. Kullanmadan önce yetkin uzmanlarla gözden geçirip uyarlayın.
Çözülen Üretim Problemi
Mühendislik ekipleri toplantı yorgunluğundan, belirsiz sorumluluklardan, pasif-agresif kod incelemelerinden ve kopuk iletişimden muzdariptir; bu da tükenmişliğe, yüksek işten ayrılma oranlarına ve hantal teslimat hızına neden olur.
Ne Zaman Kullanılmalı?
- •Yeni bir mühendislik ekibi kurarken veya organizasyonel büyüme sonrasında yeni mühendisleri ekibe katarken
- •Toplantı yorgunluğu ve bağlam değiştirme ile mücadele etmek için takım kültürünü ve sınırlarını yeniden belirlerken
- •Kod inceleme adabını, PR geri dönüş sürelerini ve nöbetçi eskalasyon sorumluluklarını netleştirirken
Ne Zaman Kullanılmamalı?
- •Geniş organizasyonel yapı ve takımlar arası Conway Yasası topolojisi haritalamasında (TPL-PEO-001 kullanın)
- •Resmi iş tanımları, işe alım kriterleri ve mülakat ölçeklerinde (TPL-PEO-003 kullanın)
5 Şablon Bölümü ve Yapısal İskelet
Takımın varlık nedeni: Bu takım hangi iş problemini sahiplenir? Birincil kullanıcılarımız kimlerdir? Pazarlık edilemez kalite ve mimari sınırlarımız nelerdir?
Senkronizasyon düzeni: Çekirdek ortak çalışma saatleri (ör. 13:00 - 17:00 UTC), günlük asenkron durum güncellemeleri ve zorunlu "Toplantısız Odak Günleri" (ör. Salı & Perşembe).
Kanal hiyerarşisi: Geçici sorular için Slack/Teams (yanıt SLA: 2-4 saat), görev takibi için Jira, kalıcı dokümantasyon için Notion/Confluence. Asenkron öncelikli iletişim kültürü.
Kod inceleme standartları: Maksimum PR boyutu (< 400 satır), ilk inceleme yanıt SLA'sı (< 24 saat), yapıcı üslup (Conventional Comments: öneri, detay, engelleyici) ve eşli programlama tetikleyicileri.
Suçlamasız kültür: Psikolojik güvenlik ilkeleri, itiraz et ve bağlan (disagree-and-commit), DACI karar modeli (Yönlendirici, Onaylayan, Katkıda Bulunan, Bilgilendirilen) ve iki haftalık retro iyileştirmeleri.
Doldurma ve Uygulama Yönergeleri
Bağımsız İnceleme ve Onay Kontrol Listesi
- Tüm zorunlu bölümler dolduruldu
- Gizli anahtar veya parola içermiyor
- Yönetici sponsor onayı alındı
Takım Bildirgesi ve Çalışma İlkeleri - Örnek Vaka Analizi
Örnek Organizasyon: Dağıtık Bulut Tabanlı Çekirdek Mühendislik Ekibi
Dağıtık Bulut Tabanlı Çekirdek Mühendislik Ekibi için eksiksiz operasyonel uygulamayı gösteren gerçek dünya vaka analizi.
- •12 kişilik bir mühendislik ekibinde ortalama PR inceleme geri dönüş süresini 4,2 günden 14 saate indirdi
- •Salı ve Perşembe günleri Toplantısız Odak Blokları uygulayarak haftalık geliştirici başına 18 saat derin çalışma süresi kazandırdı
- •Bildirgenin yürürlüğe girmesinden sonraki 90 gün içinde takım psikolojik güvenlik endeksini %62'den %91'e çıkardı
Sıkça Sorulan Sorular
Takım Çalışma İlkelerinin unutulmuş bir bürokrasiye dönüşmesini nasıl engellersiniz?
İlkeler yöneticiler tarafından dayatılmamalı, mühendislerin kendileri tarafından ortaklaşa üretilmelidir. 5-7 adet net, ölçülebilir kural ile sınırlandırılmalı, ekip alanında görünür tutulmalı ve her çeyrek dönem retrospektiflerinde gözden geçirilip güncellenmelidir.
DACI çerçevesi nedir ve karar felcini nasıl engeller?
DACI her karar için dört rol tanımlar: Driver (süreci yöneten ve öneriyi hazırlayan), Approver (nihai kararı veren TEK kişi), Contributors (fikir ve veri sunan uzmanlar) ve Informed (bilgilendirilenler). Karar verici olarak tam olarak TEK bir kişinin olması komite tıkanıklıklarını bitirir.
Pull Request boyutları neden kesinlikle 400 satır kodun altında tutulmalıdır?
Cisco araştırmaları, 400 satırdan sonra kod inceleme etkinliğinin çöktüğünü gösterir; inceleyenler bilişsel yorgunluk yaşar ve hataları kaçırır veya okumadan onaylar. Küçük, atomik PR'lar çok daha hızlı ve derinlemesine incelenir ve güvenle geri alınabilir.
Teknik Doküman Şablon Paketi
Giriş GerekliTüm boş şablonları, işlenmiş senaryoları ve doğrulama manifestolarını tek bir arşivde indirin.
Yetkili Standartlar ve Kaynaklar
- Google re:Work: Guide: Understand Team Effectiveness (Project Aristotle)Google • OFFICIAL REQUIREMENT
- Team Topologies: Organizing Business and Technology Teams for Fast FlowMatthew Skelton and Manuel Pais • OFFICIAL REQUIREMENT
- Atlassian Team Playbook: Working AgreementsAtlassian • OFFICIAL REQUIREMENT