Yetenek takımlar aracılığıyla nasıl dağıtılmalıdır?

Okuduktan sonra bu, Çevik takımların farklı yeteneklere sahip bir grup geliştirici içinde nasıl yapılandırılması gerektiğine dair pek çok anlaşmazlık olduğunu gördüm (neredeyse tüm takımlar). Tüm en iyi geliştiriciler kendi takımlarına konmalı ve en yüksek öncelikli çalışma verilmeli mi? Bu, en önemli görevlerin gerçekleştirilmesini hemen hemen sağlayacaktır. Aynı zamanda, sadece düşük öncelikli görevlerde bile olsa, başka bir yerde teknik borcu tıkayan "mükemmelden az" ekiplere bırakılırsınız. Öte yandan, eşit olarak dağıtılmış takımlar, gecikmeli geliştiricilerinizi biraz daha iyi hale getirme avantajına sahip olabilir, ancak en ağır vuruşlarınızı motive etme potansiyeline sahiptir. Ayrıca, bir grup iyi tasarım desenini bir sürü korkunç anti-desenle karıştırırsanız, bir grup anti-desen olabileceği gibi bir şeyle sonuçlanabilir.

A-Teams ile bilinen bazı riskler var, ancak dinamikler doğruysa, evet diye düşünüyorum, en güçlü insanlarıma en potansiyel projeleri olan genç geliştirici (ler) ile birlikte en önemli projelere koyardım. Düşük öncelikli projeleriniz için, rayların çok uzağına düşmelerini önlemek için mümkünse iyi bir takım liderine ihtiyacınız vardır. Teknik borç ne olursa olsun gerçekleşecek. Tüm teknik borçlar eşit değildir; teknik borcun maliyeti / yükümlülüğü ilk etapta projenin iş değeri ile orantılıdır, bu nedenle düşük öncelikli projeleriniz daha fazla siğile sahip olsa da, bunların maliyeti muhtemelen yüksek öncelikli projelerinizdeki önemli sorunlardan çok daha azdır. olmak.

Profesörlerimizden birinin bize takım yapıları hakkında bir fıkra anlattığımı hatırlıyorum (şimdi konuştuğu kağıda bir göz attım ama bulamıyorum).

Temel olarak, hikaye aşağıdaki gibi gitti:

Bir grup programcı yeteneğe göre gruplara ayrıldı, en kötü x programcıları birlikte gruplandı, bir sonraki x birlikte gruplandı, vb. Ve en iyileri birlikte gruplandı.

Hepsi aynı göreve atandı ve tamamlanmaları için belirli bir zaman aralığı verildi.

Zaman aralığının sonunda organizatörler görevlerin çözümlerine baktılar ve sürprizlerine göre en iyi performans gösteren çözümün ortalama insanlardan oluşan ekipten geldiğini keşfettiler. Buna karşılık, A * programcılarından oluşan ekip en kötü çözümlerden birini yaptı çünkü tüm zamanlarını en iyi çözümün ne olduğunu tartışarak geçirdiler .

İşleri yapacak bir takıma ihtiyacınız varsa, bir grup ortalama adam ve liderlik edebilecek baskın bir adam alın, çalışmanın sonucuydu (doğru hatırlarsam), aksi takdirde daha baskın üyeler savaşmaktan daha fazla zaman harcayacak şeyler bitti!

Deneyimsiz geliştiricilerin büyük çoğunluğu kendi başlarına sağlam ve zarif tasarımlar bulamayabilir, ancak bir tanesini gördüklerinde bunu anlayabilir ve anlayabilirler. Eğer yapamazlarsa, genellikle ilk etapta işe alınma yeteneğinden veya hazırlıktan yoksundurlar.

Ayrıca, çok karmaşık yazılım tasarımlarını anlayabilen, ancak daha basit bir şeyin ne zaman daha iyi olacağını bilmeye karar verme yetkisine sahip olmayan daha deneyimli geliştiriciler de vardır.

Deneyimlerime göre, karışık ekiplerle genellikle hazırlıksız üyeler, gereksiz derecede karmaşık üyeler veya her ikisini de içeriyorsa kalıcı sorunlarınız olur. Aksi takdirde, ekibinizin sorunları varsa, genellikle daha iyi iletişim veya uygun roller atayarak düzeltilebilirler.

En iyi insanları tek bir takıma gruplamak harika bir kısa vadeli çözüm gibi görünebilir, ancak uzun vadede başarısızlıktır ve ek maliyetleri vardır. Örneğin benim şirketim insanlar eğitim için para ödemek yerine daha yetenekli meslektaşlarından öğrenmeyi tercih ediyor. En iyi insanları ayırırsanız, bilgiyi daha az yetenekli insanlara aktaramazlar. Kısa vadede en iyi takımlarınız iyi performans gösterebilir ancak bilgi aktarımından yoksun olduğu için yetenekli kişilerin sayısı artmaz. Başlangıçta daha az performans gösteren takımlara sahip olmak ve insanlar daha yetenekli hale geldikçe tüm takımlara göre performansı artırmak çok daha iyidir.

Dahası, yetenekli insanlar ayrılmaya karar verirse ne olur? Projelerini kim alacak?

Başka bir nokta, takımın farklı beceri setlerine sahip insanlardan oluşması gerektiğidir. Her zaman en üst düzey geliştiriciler tarafından yapılması çok pahalı olan kolay görevlere (ve sıkıcı görevlere) sahip olacaksınız.

Öğretemeyenler, yapamazlar ...

Düşünülmesi gereken daha fazla faktör olduğunu düşünüyorum.

Takım lideri olarak öğretebilecek olanları dağıtarak en yüksek değeri elde edersiniz. Ekibin diğer üyelerini öğretebilir ve çalışmalarının kalitesini yükseltmeye yardımcı olabilirler.

Tüm kıdemli programcılar iyi sonuçlar elde edemez. Bilgi aktarma yeteneği kendi başına bir beceridir. Bu beceri programlama deneyimi ile gelişen bir şey değildir. Öğreterek ve açıklayarak gelişir.

Bir 'A' takımı atamanın iki önemli sorunu vardır. Birincisi uyumluluk. İyi geçinen ve birlikte iyi çalışan ekiplere sahip olmaları "yeteneklerinden" çok daha önemlidir. Şimdi bu iki "yüksek" beceri programcısı, iki "düşük" beceri programcısı veya bir karışım olabilir. Birlikte iyi çalışabilecekleri gerçeği, daha üretken olacakları anlamına gelir.

İkinci konu büyüme ile ilgilidir. İki "düşük" beceri programcısı kötü alışkanlıkların yanı sıra birbirlerinden çok fazla şey öğrenmeyeceklerdir. Aynı şekilde, iki "yüksek" yetenekli programcı birbirlerinden çok şey öğrenmeyecektir. Bununla birlikte, "düşük" ve yüksek "beceri seviyelerinin karıştırılması," düşük "becerinin yeteneklerini geliştirmeye yardımcı olur, aynı zamanda" yüksek "yetenekli yeteneklerini de geliştirir. Başka birine öğretene kadar "usta" bir beceri olarak düşünmüyorum.

Madalyonun diğer tarafından, birbirine "ayak uydurabilecek" takımları tutmak mantıklı. A-Team tipi programcılarınız, bitlerini tamamlamak için B-Team tiplerini beklemek istemiyorlar. B-Team tipleriniz A-Team tarzı iş akışı ile intibaklanmış olabilir.