Bir ekip parçası olarak etkin bir şekilde çalışmak, işin kalitesi, motivasyon ve işi sürdürebilmek için inanılmaz derecede önemlidir. Ekip çalışması ile ilgili mesleki deneyimim öncelikle yazılım mühendisliğiydi, ancak yetkinliklerim mühendislikle sınırlı değil.

Frederick Brooks’un The Mythical Man-Month kitabında büyük ekip çalışmasının, verimliliğe etkisine dair argümanları oldukça dikkat çekicidir.  Brooks’un savunduğu temel fikir; projenin başlangıcında, yılda bir kişinin (on iki ay) tamamlayacağı bir yazılım projesine, bir düzine mühendis personel atayarak zaman çizelgesini tek bir aya indirgeyeceği fikridir. Oysa birçok yönetici, projelerin geride kaldığını gördükten sonra, sadece projeye daha fazla mühendis ekleyerek programları değiştirmeye çalışıyor.

Bu mantıkla ilgili bir problem yaratıyor, bir projeye eklenen her ek mühendisin ekipteki diğer herkesle iletişim ve koordinasyon masraflarına neden olması ve dolayısıyla bir projeyi tamamlama zamanının aslında azalmadığı tersine doğrusal olarak arttığını savunuyor. Bu, yaygın olarak Brooks Yasası olarak bilinen ve “geç bir yazılım projesine insan gücü eklenmesi onu daha geç yapar” yolunu doğuruyor.

Bu mantık hatası yüzünden müdürler veya teknik ekipler bazen iletişim masraflarını sıfıra indirmek için tek kişilik projelerle personel verimliliği en üst düzeye çıkarmaya çalışır. Google gibi bazı şirketler, tanıtım süreçlerinde bir mühendisin bir projede mülkiyet göstermesi gerektiğini vurgular; bu da mühendisleri bireysel projeleri tanımlamaya ve önceliklendirmeye teşvik ederek bu projelerin tartışmasız sahipleri olabilir ve bir tanıtım şansını artıracaktır. .

Gerçek şu ki, çıkış kalitesini ve moralini etkileyen tek başına çalışmanın birtakım dezavantajları ve riskleri vardır:

Tek başına çalışmak, erken ve sürekli tasarım geri bildirimine gitmeyi zorlaştırmakta ve böylece çıktı kalitesini düşürmektedir.
Sıkı geri besleme döngüsü, üretken bir akış durumuna ulaşmak için önemlidir ve geribildirim almaya başlamadan önce, yanlış yolu seçmek için daha az zaman harcarsınız ve kursunuzu düzeltmek için daha önce bilirsiniz . Uygulamada yazılım geliştirmede ortaya çıkan bir yer, bir başkasının sizinle aynı ekip üzerinde çalışıp sizinle aynı proje içeriğini paylaşması durumunda kodunuzu gözden geçirmek ve iyi bir geri bildirim vermek çok daha kolay; Farklı bir projedeki birinin size kod vermesi daha zor. Brian Fitzpatrick ve Ben Collins-Sussman bu düşünceyi Team Geek’teki etiket çizgilerinden birinde iyi bir şekilde yakalarlar: “yazılım geliştirme bir takım sporudur.”

Tek başına çalışmak öğrenmeyi azaltır. Bunun bir kısmı, fikirlerinize meydan okumak için paylaşılan bağlamı olan az sayıda kişinin bulunduğu ilk nokta ile ilgilidir. Bir diğeri, projenin tamamlanması daha uzun sürdüğü için, birlikte çalışan her kişi zamanla daha az projede çalışır.
Bir ekip üzerinde çalışmak, bir projenin otobüs faktörünü artırır. Bir projenin otobüs faktörü [4], bir proje tamamlanıncaya kadar bir otobüsle vurulabilecek (veya hastalanır, şirketten ayrılır, doğum izni alır vb.) Ekip üyelerinin sayısını belirtir; Bir otobüs faktörü daha yüksek bir projedeki riski azaltır. Ayrıca, tek bir kişi tarafından belirsiz ve belgelenmemiş kısayolların engellenmesine yardımcı olur ve takım üyeleri, bilgiyi yaymaya ve ekipteki diğer kişilerin gerektiğinde alabilecekleri şekilde şeyler yapmaya zorlar.
Bir ekip üzerinde çalışmak hesap verebilirliği artırır. Akran baskısı güçlü bir kuvvettir. Özellikle, saygı duyduğunuz ve üzülmek istemediğiniz insanlarla çalışıyorsanız, ekibinize başarılı olmanıza yardımcı olan motivasyon, en iyi olmadığınız günlerde karşılaştığınız motivasyonun düşüşünü geçersiz kılabilir.
Yalnız çalışmaktan daha yavaş olan proje ivmesi moralleri azaltır. Proje tahmini zor ve projeler programın gerisinde kalma eğilimindedir. [5, 6] Tek kişili projelerde tek bir durak, projeyi bir duraklama noktasına getirebilir; tıpkı bir bakkalda yalnızca bir ödeme satırı, bir sorunlu müşteri ya da bir fiyata kontrol etmesi gereken bir öğe, tüm satışları Geçici olarak durdurmak için. Projedeki en az bir ek kişiyle, en azından bir miktar ileriye dönük momentum olabilir. İlgili nokta, insanların bir proje için harcanan zaman hakkında geçen zaman ve yatırım zamanı düşünmek eğiliminde olması, Sadece iki ay boyunca yarı zamanlı olarak yarım yıl boyunca yarı zamanlı olarak çalışıyordunuz ve sizin ve kurum içindeki diğer kişilerin bunu içselleştirmesi ve tüm projenin yavaş ilerlediğini ve tamamlanması için yarım yıl sürdüğünü düşünmemeniz zor. Bir projeyi bitirmek için geçen süredeki bu hayal kırıklığı da genel moral ve heyecanı azaltabilir.
Bir projenin en düşük seviyeleri yalnız çalışırken daha moral bozucu. Çıkmak için mücadele ettiğiniz kum tuzakları, öğütmeniz gereken monoton işler ve tüm anlayışa meydan okuyan böcekler, acıyı paylaşacak bir başkası olduğunda daha az boşalma ve daha katlanılabilir hale gelir.
Bir projenin üst seviyeleri, bir ekip halinde çalışırken daha motive olur. Takım arkadaşlarıyla bir başarı kaydetmek moral düzeyini artırmanın mükemmel bir yoludur. Yalnız çalışırsan, işe başlayınca kim yüksek beşliğe gideceksin?

Edmond Lau, Quora Engineer
Why And Where Is Teamwork Important? yazısından çeviridir.

ETİKETLER:

YORUM YAZ