Bir geliştirme ekibi nasıl yapılandırılır

Şirketimin web sitelerine / web uygulamalarına bakan, 4 eşzamanlı proje artı herhangi bir zamanda günlük destek çalıştıran 11 yazılım geliştiriciden oluşan bir ekibin yöneticisiyim. 11 geliştiricinin içinde teknik becerilerin, iş unvanlarının ve deneyimin bir karışımı var, ancak ekip yapısı bana doğrudan rapor veren 11 geliştiricinin tümü ile aynı seviyede.

Tek bir menajere sahip olan tüm takımın çok iyi ölçeklendirilmediğini kanıtlamaya başlıyor. Çok ince bir şekilde yayılmaya başladım, bu yüzden doğrudan raporlarımı azaltmak istiyorum. Bunu yapmayı düşündüğüm tüm yolların ciddi olumsuz yönleri var:

• Küçük geliştiricilerin yaşlılara rapor vermesini sağlayın. Bu, en iyi teknisyenler tarafından geliştirme için harcanan zamanı azaltır.
• Ekibi yazılım ürününe göre ayırın, örneğin geliştiriciler 1-6 intranet üzerinde çalışır ve 7-11 dış siteler üzerinde çalışır, her bölüm yeni ekip liderliğine sahiptir (muhtemelen mevcut üst düzey geliştiricilere göre daha fazla yönetim / mentorluk / koçluk sorumluluğu olan yeni bir iş tanımı) ). Bu yapay silolar ekler ve eğer istersem harici bir web sitesinde çalışacak bir "intranet geliştiricisi" almayı zorlaştırabilir.
• Yapıyı düz tutun ve sadece baskı almak için Proje Yöneticileri / Ekip Yöneticileri şeklinde yönetim desteği ekleyin. Bu, problemi çözmez, çünkü takım sonsuza dek böyle büyümeye devam edemez.

Kaybettiğim bu sorunu çözmenin standart bir yolu var mı?

Olmazsa, başkalarınız bu sorunu nasıl çözdü?

Bazı hızlı düşünceler:

• Alt-ekipler iyi bir fikirdir: 11 yapıda olan doğrudan raporlar, çalışabilir bir ekip için çok büyük (doğrudan koçluk için yeterli zamanınız olmayacak ve birçok insanla verimsiz olma eğiliminde olacak ekip toplantıları).
• İşlemleri geliştirmeden ayırmayı düşünün - bu biraz farklı bir beceri setidir ve bütün gün operasyonel konular tarafından kesilmesi, projelerdeki geliştirme verimliliğine ciddi şekilde zarar verebilir.
• İlk iki puanın sonucu olarak, belki de 3 alt gruba sahip olmanız gerektiğini düşünüyorum - İntranet, Dış Alanlar ve İşlemler. Operasyon görevlileri tüm günlük meseleler / bakım onarımları vb. İle ilgilenecek, iki geliştirme ekibi işe yeni projeler / değerler sunmaya odaklanacak.
• Düzenli olarak takımlar arasında insanları dolaşın. Bu, bir proje için veya kalıcı olarak, zaman zaman (örneğin, insanların başka bir alt bölümdeki kodu incelemesini yapma) olabilir. Ancak, bir iş ihtiyacı olduğunda takım rollerinin değişeceği anlaşıldığından emin olun - hiç kimse sonsuza dek belirli bir role sahip değildir.
• Daha fazla yönetici / yönetici eklemeyin - bu, ekiplerinizin genel etkinliğini / verimliliğini azaltmanın kesin yoludur. Her bir alt takımdaki en deneyimli kişinin takım lideri / antrenör rolü oynamasını sağlayın. Buradaki rollerini koçluk ve tüm ekibin başarması için gördüklerinden ve “görev yöneticisi” olarak hareket etmekten ziyade bu şekilde davranmaya hazır olduklarından emin olun.
• Rolünüz dış paydaş yönetimi, grup içindeki kaynakların / görevlerin önceliklendirilmesi ve "baş koç" olarak hareket etmeye odaklanmalıdır. Alt ekiplerden zaman zaman artan sorunları çözmeniz gerekecek, ancak genel olarak sorunları size gelmeden kendileri çözmeleri için teşvik etmelisiniz.
• Kendinizi çok teknik biriyseniz, bir mimar / tasarım güvencesi rolü oynamayı da seçebilirsiniz. Değilse, takım içinde veya başka bir yerde bulabilecek birini bulun.

Ayrıca, her zaman gitmeye ve Çevik Manifesto'yu ve özellikle on iki ilkeyi okumak yeniden değer .

Bu yapı esas olarak depend on project specifications

İdeal olarak, bir ekipte üst düzey geliştirici başına 3 genç olmalıdır. Sonuç olarak, bir öğretmen adayı için 2-3 üst düzey geliştirici vardır.

Bu nedenle, yalnızca teknik liderler projenin ilerleme durumu hakkında Başbakana rapor verecek. Açıklanan yapı, teknik olmayan sorunlar (tatil, mola, çatışmalar vb.) İçin herkesin Başbakanlığa erişebileceğini varsayar.

Bir parçası olduğum nispeten başarılı yazılım geliştirme ekiplerinden biri proje bazında böyle bir şeye gitti:

Herkesin doğrudan bildirdiği bir Yazılım Geliştirme Müdürü / Kıdemli Geliştirici / Mentor.

• Programları tutan, gereksinimleri ve kabul pazarlığını kabul eden ve iletişim kuran bir proje yöneticisi. Herkes noktalı çizgi de bu kişiye bildirdi. Bir dökümantasyon görevlisi (zaman zaman Başbakan olan ancak yalnızca uzmanlığa izin verildiğinde).
• Projenin ihtiyaçlarına bağlı olarak 1-3 geliştirici veya üst düzey geliştiriciden oluşan bir karışım.
• Mevcut olduğunda küçük bir geliştirici.
• Bir QA havuzundan atanan biri.
• Bir altyapı çalışanı (yönetici tarafından sıklıkla yerine getirilmiş bir rol, çünkü aynı zamanda SA yetkinliğine de sahiptir).

Mükemmel çalışıyordu ve o organizasyonu sevdim. Öte yandan, Yazılım Geliştirme Müdürü'ydüm ve ekibin organizasyon yapısı gelişiyordu.

İşlevsel Personel Örgütü modelini izlemeyi düşünün . Bu, takımı yazılım ürününe bölmek için ikinci seçeneğinize yönelik olacaktır.

Makaleyi kendi bağlamınızda alıntılamak için:

İşlevsel bir organizasyonun en büyük gücü, sosyal yapıları iş değerinin sağlanmasına bağlamasıdır. Benim görüşüme göre yazılım projeleri, destekledikleri faaliyetin etkinliğini arttırdıkları kadar başarılı olurlar - işletme değeri verir. Ekiplerinizi aynı şekilde düzenleyerek, işletme kullanıcılarını memnun etme konusunda odaklı bir ekibiniz var.

Gerçek yönetim / İK yapısı bunun ötesinde önemsizdir.

Kaybettiğim bu sorunu çözmenin standart bir yolu var mı?

Pek sayılmaz. Bu, ekibinize, size, yapmanız gerekenlere ve şirketin sizin için hangi kaynakları sağlayacağına bağlı olacaktır.

Şahsen, en iyi geçiş türü teknik yönetimi idari yönetimden ayırmaktır. İnsanların her ikisinde de iyi olmaları nadirdir ve nadiren etkileşime girme eğilimindedir.

Bir kişi teknik yönleri ele alır. Ne yapılması gerekiyor, kim yapacak? İşlerin nasıl hizalanması gerekiyor? Diğer idari yönleri ele alır. İncelemeler, bütçe toplantıları, ürün planlama vs.

Bunun nasıl bozulduğu birkaç farklı yoldan geçebilir. Bunlardan en yaygın olanı mühendislik yöneticisinin idari taraf ve bir mimarın teknik taraf olması. Eşler ve bir yönetmene / başkan yardımcısına rapor verirler

Gördüğüm bir diğer iş ise mühendislik yöneticisinin idari kişi olması ve ardından takım liderlerinin teknik kişi olarak görev yapması. Bu daha zordur ve raporlama hiyerarşik olsa bile doğru kişilerin (çoğunlukla) akran olarak hareket etmelerini gerektirir.

Özel senaryonuz için, 2-3 ekip bulundurmanızı ve teknik yönelimleri teknik yönden yönlendirmenizi öneririm ve siz de yönetime odaklanın. Evet, müşteri adaylarının kod yazmasının zamanını keser, ancak (iyi bir iş yapıyorlarsa) daha genç geliştiricileri daha verimli / üretken hale getirerek bu zamanı telafi etmeleri gerekir. Onlara daha fazla motivasyon ve gerçek promosyonlarla da başarı hissi verir. Ve en pratikte, yönetime yeni bir pozisyon açmaktan daha kolay bir satış.