Mühendislik Ekipleri için Proje Başlangıç (Kickoff) Toplantı Gündemi

Başlangıç toplantılarının atladığı soru

İyi giden bir proje başlangıcı, ekibi ne inşa edileceği, kimin ne yapacağı ve ne zaman teslim edileceği konusunda hizalanmış halde bırakır. Bu hizalanma genellikle üç hafta kadar dayanır. Sonra kapsam kayar, bir paydaş temel bir varsayım hakkında fikrini değiştirir, bir bağımlılık gecikir ve ekip, iki makul kişi anlaşamadığında kararı kimin vereceği konusunda hiç anlaşmadıklarını fark eder.

Çoğu başlangıç gündeminin atladığı soru şudur: bir şey ters gittiğinde bu ekip nasıl karar verecek? Proje planı değil — karar verme çerçevesi. Bir özellik kesilmesi gerektiğinde kapsamı kim sahiplenir? Teknik bir kısıt bir ürün gereksinimini geçersiz kıldığında ekip ne yapar? İki departman farklı şeyler istediğinde hangi paydaşın son sözü vardır?

Bu sorular kickoff'ta yanıtlaması kolaydır çünkü henüz hiçbir şey riskte değildir. Herkesin bir tavrı olduğunda proje ortasında yanıtlanması çok daha zordur. Aşağıdaki şablon, zor kısım başlamadan önce bunlara zaman ayırır.

Gündem (kopyala-yapıştır)

Süre: Proje karmaşıklığına bağlı olarak 60–90 dakika
Format: Yönetilir; tüm ana paydaşlar ve katkıda bulunanlar hazır bulunur veya başlamadan önce asenkron incelemiş olur

Bölüm 1 — Proje hedefi ve kapsamı (20 dk)

Hedefi tek bir cümlede belirtin: başarı nasıl bir sonuca benziyor, mümkünse ölçülebilir olsun
Kapsam içi: projenin neyi teslim edeceği, özel olarak belirtilmiş
Kapsam dışı: bu projenin açıkça yapmayacağı şeyler — en az üç şey listeleyin
Başarı ölçütleri: ekip projenin bittiğini nasıl anlayacak?
Bu bölümü EM veya PM sahiplenir; belirtilen kapsam yapılabilirlikle uyuşmuyorsa mühendisler itiraz eder

Bölüm 2 — Roller ve sahiplik (15 dk)

Her iş akışı için bir sorumlu belirtin — bir ekip değil, bir kişi
Şunlar hakkında son kararı kim verir: ürün kapsamı, teknik mimari, dış iletişim?
Her büyük karar türünde kim bilgilendiriliyor, kime danışılıyor, kim karar verici?
Başka hiçbir şey net değilse hesap verecek proje liderini belirtin

Bölüm 3 — Kısıtlar ve riskler (15 dk)

Katı kısıtlar: son tarih, bütçe, uyumluluk, diğer ekiplere bağımlılıklar
Bilinen riskler: bu projeyi raydan çıkarabilecek ilk üç şey nedir?
Her risk için: olasılık, etki ve azaltma sorumlusu
Projenin iptal edilmesine veya önemli ölçüde daraltılmasına ne yol açar? Bunu şimdi belirtin

Bölüm 4 — İletişim planı (10 dk)

Ekip ne sıklıkta senkronize olacak? Hangi formatta?
Kim durum güncellemesi alacak ve nasıl? Paydaşların aynı kanalı istediğini varsaymayın
Proje dokümantasyonu nerede duruyor?
Bir şey projeyi engellerse üst mercie iletme yolu nedir?

Bölüm 5 — Açık sorular (15 dk)

Ekibin bugün yanıtlayamadığı her soruyu listeleyin
Her biri için: bir sorumlu ve cevabın gerektiği tarihi atayın
Tarihi ve sorumlusu olmayan sorular projenin ortasında hâlâ açık olacaktır

Bölüm 6 — Sonraki adımlar (10 dk)

Gerçek işe başlamak için sonraki beş iş gününde gerçekleşmesi gereken üç şey
Her sonraki adımın tek bir sorumlusu var
Kickoff özetinin nasıl ve kime dağıtılacağını teyit edin

Popüler başlangıç şablonlarında yapılan yanlışlar

Çoğu başlangıç şablonu proje planı konusunda titizdir ama plan tutmadığında ne olacağı konusunda zayıftır. Temiz bir kapsam belgesi ve bir RACI matrisi üretirler ki bu faydalıdır. "Veritabanı sağlayıcısı proje ortasında fiyatını üçe katladığında ne yaparız?" veya "Katı son tarihe %80 özellik tamamlanmışken ulaşırsak ne kesilir?" sorularına ortak bir yanıt üretmezler.

Kapsam-dışı eksikliği diğer tutarlı boşluktur. Kapsam içinde olanı belirtmek basittir. Açıkça dışarıda olanı belirtmek — projenin yapmayacağı üç dört belirli şeyi listelemek — paydaş beklentileri hakkında aynı konuşmayı ama diğer yönden zorlar. Mobil istemcinin dahil olduğunu varsayacak olan paydaşlar, altıncı haftada değil, kickoff'ta öğrenir.

Üçüncü boşluk açık sorular bölümüdür. Ekipler, kickoff'ta bilmediklerini ortaya koymak istemez çünkü bu, hazır olmamayı itiraf etmek gibi hissettirir. Ama bilinmeyen cevaplar proje ortası engellere dönüşür ve proje ortası engeller pahalıdır. Sorunun var olduğunu ne kadar erken bilirseniz, birinin cevabı sahiplenmesi o kadar erken olur.

Bu boşlukların çok aylık bir proje boyunca nasıl yüke dönüştüğü hakkında: Toplantı vergisi.

Başlangıç notlarını doğru tutmak neden buna değer

Başlangıç belgesi, herhangi bir projede en sık başvurulan üründür. İnsanlar kapsam tartışmalı hale geldiğinde, yeni bir ekip üyesi katıldığında, bir paydaş "kickoff'ta X'e karar vermemiş miydik?" diye sorduğunda ona bakar. İyi belgelenmiş bir başlangıç, yönetmesi daha kolay bir projedir.

Pavleur, tüm başlangıcı otomatik olarak yakalar: belirtildiği şekilde kapsam, atandığı şekilde roller, belirtildiği şekilde riskler, sorumlularıyla açık sorular, sorumluları ve tarihleriyle sonraki adımlar. Biri toplantı ortasında proje özetini, bir diyagramı veya bir gereksinim belgesini ekran paylaşımıyla gösterdiyse, görsel tartışmayla birlikte rapora eklenir. Yalnızca sese dayalı araçlar size kimin ne söylediğini verir; teknik liderin bağımlılığı anlattığı sırada ekranda olan mimari diyagramı yakalamaz. Ortaya çıkan rapor, ilk günden itibaren projenin tek doğru kaynak belgesi olarak hizmet eder. Bunun geleneksel toplantı yakalama araçlarıyla nasıl karşılaştırıldığı hakkında: Pavleur ve alternatifleri.

Katılım üzerine bir not

Bu projede karar vermesi beklenen herkes başlangıca katılmalı veya iş başlamadan önce tam bir kaydı ve yazılı özeti incelemelidir. Kickoff'u kaçıran ve kapsamı iki hafta sonra gayriresmi olarak öğrenen bir paydaş, olmaya hazır bir proje ortası kapsam anlaşmazlığıdır. Kickoff'un görevi ortak bağlam oluşturmaktır ve ortak bağlam yalnızca ilgili kişiler odada olduğunda vardır.