Küçük bir yazılım ekibini yönetmek: roller, ritim ve kararlar

Kariyerime SEO ve yazılım geliştirmeyle başladım; bugün hem bir ajans ekibini hem de bir ürün ekibini yönetiyorum. İki ekip de küçük. Bu yazıda, küçük bir yazılım ekibini yönetirken en çok işe yarayan şeyleri topladım. Hiçbiri yeni bir araç ya da yöntem adı değil; çoğu, kimin neye karar verdiğini yazıya dökmekle ilgili.

Küçük ekip neden ayrı bir yönetim ister?

Büyük şirketlerin süreçleri, çok sayıda insanın birbirini beklemeden çalışabilmesi için tasarlanır. Küçük ekipte sorun bunun tersidir: herkes her şeyi bilir gibi görünür, bu yüzden hiçbir şey yazılmaz. Ekip büyüdükçe ya da biri ayrıldığında, yazılmamış her şey bir anda görünür olur.

Küçük ekibin avantajı hızdır. Bu hızı korumanın yolu ağır süreçler eklemek değil, az sayıda ama net kural koymaktır. Bir de şunu kabul etmek gerekir: geciken bir işi kişi ekleyerek hızlandırmak çoğu zaman beklenen sonucu vermez.

Geciken bir yazılım projesine insan gücü eklemek, projeyi daha da geciktirir.

Önce rolleri, sonra kişileri tanımlayın

Küçük ekipte bir kişi aynı gün hem geliştirici hem test eden hem de müşteriyle konuşan olabilir. Bu normaldir. Sorun, bu şapkaların hangisinin kimde olduğunun bilinmemesidir. Ben rolleri kişi adıyla değil, sorumluluk ve karar alanıyla tanımlamayı tercih ediyorum.

Haftalık ritim: az toplantı, net çıktı

Toplantılar küçük ekibin en pahalı kaynağını, yani odaklanma süresini tüketir. Bu yüzden her toplantının tek bir yazılı çıktısı olsun. Çıktısı olmayan toplantı ya mesaja dönüşür ya da kaldırılır.

1. Haftanın başında planlama: bu hafta biten ne olacak? Çıktı, kısa bir iş listesi.
2. Her gün kısa durum paylaşımı: yazılı da olabilir. Çıktı, takılan işlerin listesi.
3. Hafta ortasında demo: biten iş çalışırken gösterilir. Çıktı, kabul edilen ya da geri dönen işler.
4. Hafta sonunda retrospektif: ne işe yaradı, ne yaramadı? Çıktı, en fazla iki değişiklik.

Retrospektifi kısaltmak için hazır prompt

Retrospektif notları dağınık olduğunda ilk yarım saat notları toparlamakla geçer. Aşağıdaki promptu, ekibin haftalık notlarını yapıştırarak bir yapay zeka asistanında kullanabilirsiniz. Çıktıyı karar olarak değil, tartışmanın başlangıç noktası olarak kullanın.

Bir yazılım ekibinin haftalık retrospektif notlarını aşağıya yapıştırıyorum.

Görevin:
1. Notları üç başlıkta topla: işe yarayanlar, yaramayanlar, belirsiz kalanlar.
2. Birden fazla kişinin dile getirdiği konuları işaretle.
3. Gelecek hafta denenebilecek en fazla iki somut değişiklik öner. Her öneri için kimin sorumlu olabileceğini ve nasıl ölçüleceğini yaz.
4. Kişileri suçlayan ifadeleri, süreçle ilgili ifadelere çevir.

Kısa ve madde madde yaz. Notlarda olmayan bir bilgiyi ekleme.

Notlar:
[notları buraya yapıştırın]

Kod inceleme ve yayın kimseye bağlı kalmasın

Küçük ekiplerde en sık gördüğüm darboğaz şudur: kod incelemeyi ve yayını yalnızca bir kişi yapabilir. O kişi toplantıdaysa ya da izindeyse ekip bekler. Bunun çözümü kişiyi değiştirmek değil, adımları yazmaktır.

• Kod incelemede neye bakılacağını kısa bir kontrol listesine yazın.
• Yayın adımlarını, ekibe yeni katılan birinin uygulayabileceği kadar açık yazın.
• Her yayının bir geri alma yolu olsun ve bu yol en az bir kez denenmiş olsun.
• Bir işi kimin incelediği değil, işin kontrol listesinden geçip geçmediği takip edilsin.

Kararları yazıya dökün

Hangi kütüphaneyi seçtik, neden bu özelliği erteledik, hangi müşteri isteğini reddettik? Bu soruların cevabı yazılı değilse, her yeni kişi aynı tartışmayı yeniden açar. Uzun belgeler yerine, her karar için birkaç satırlık bir kayıt yeterlidir: tarih, karar, gerekçe, kim verdi, ne zaman yeniden bakılacak.

Ekibinizi sıfırdan kuruyor ya da var olan ekibi teslim eden bir yapıya çevirmek istiyorsanız, bu konuda birlikte çalışabiliriz.