Lider geliştiriciyi döndürmek iyi veya kötü bir fikir midir?


31

Birkaç ay önce kurulduğundan bu yana örgütsel olarak düz bir takım üzerinde çalışıyorum. Yöneticim teknik değil ve bu da tüm ekibimizin karar vermekten sorumlu olduğu anlamına geliyor.

Müdürüm, hem kendi adına (görevler için tek bir temas noktası, hem de görevler için tek sorumlu taraf)) ve bizim için (anlaşmazlıkların çözümü, organize teknik rehberlik, vb.) Bir lider geliştiriciye sahip olmanın birkaç faydası olduğunu fark etmeye başlıyor.

Takımın düz olması nedeniyle, bir öncü geliştiricinin seçilmesi diğerlerini caydırabilir. Bir geliştirici olmayan, yöneticime lider geliştiriciyi döndürmenin bu sorunu önlemenin olası bir yolu olduğunu önerdi. Bir geliştirici bir ay, bir başkası diğeri vb.

Bu iyi bir fikir mi? Neden ya da neden olmasın?

Bunun tüm geliştiriciler anlamına geldiğini aklınızda bulundurun - Tüm geliştiriciler iyidir, ancak liderliğe eşit derecede uygun değillerdir.

Ve eğer değil , nasıl bu kadar bencil nedenlerle sadece gibi biz görünüşteki olmadan bu yaklaşımı önlemek tavsiye edersiniz?


7
"Şu andaki lider geliştirici hayalidir. Lütfen onu 90 derece döndürün ve tekrar deneyin"; o)
Piskvor

14
Bunu tavsiye etmem, bu onu sersemletir.
Gaurav

Yanıtlar:


31

Dönme

Hiç kimsenin döndürülen konumdan bir şey kazandığını sanmıyorum (liderliği hak etmeyenler dışında, şu anda aldıklarından daha fazla para kazanabilir).

Aşağıdakileri yapabilen harika bir lider geliştiriciye sahip olmak, geliştirme süreci için harikalar yaratıyor:

  1. Nasıl temsil edileceğini bilir.
  2. Kontrol altında.
  3. Deneyimli bir geliştiricidir.

Takımın geri kalanına bakmak ve danışmak için tek bir kaynak. Aynı zamanda üst düzey yönetim ile çekirdek geliştirme ekibi arasındaki arabulucudur. Değişimle uğraşmayı seven hiçbir yönetim ekibini tanımıyorum (onlar onu kışkırtanlar olmadığı sürece).

Gerçekten pozisyon için en uygun olan sensen herkes bunu bilirdi. Herkes bunu bilir (örneğin üst seviye yönetim, takım arkadaşınız, vb.). Pozisyonu döndürmeye inanmayacağınızı (eğer inanıyorsanız) değerinde olduğunu belirtin. Ardından arkanıza yaslanın ve atanmayı yapmalarına izin verin - adınızı düşürmekten kaçınınız veya kendi kendini terfi ettirmekten kaçınınız, çünkü bu size profesyonelce görünmez


@Jonathan Khoo: Cevabınız "düz bir sistemi unutun, bir rock yıldızı geliştiricisini işe alın" gibi görünüyor.

3
@ moz - Belki bir rock yıldızı geliştiricisi olmayabilir, ancak bir proje belirli bir boyuta ulaştığında, idari ek yükü idare eden bir tür birincil temas noktasına sahip olmak mantıklı olur. Bu aynı zamanda herhangi bir geliştirme çalışması yapmayan bir proje yöneticisi olabilir.
rjzii

2
eğer düz bir takımsa, "lider geliştirici" diğerlerinden daha fazla ödeme alamaz. Sorumlulukları üstlenecek ancak üst düzey bir pozisyona sahip olmanın faydalarına sahip olmayacak. Yani aslında ben hiç çalıştığım hemen hemen her takımda gerçektir.
jwenting

6
@ moz: Bir rock yıldızı bu pozisyonda boşa harcanacaktı, çünkü öncü geliştiricinin programlamayı içermediği birçok şey. Deneyim, mentorun liderliğine izin verdiğinden ve ona etkili bir şekilde liderlik etmesini sağladığı için faydalıdır, ancak daha verimli geliştiricinizin daha yüksek yönetimli toplantılarda zaman geçirmesini istemezsiniz.
David Thornley

1
Kodlamanın neyle ilgili olduğunu bilen yönetim türlerinin (kodu okuyabilir, hangi tabloların ve veritabanlarının olduğunu bilir, bir TCP / IP soketinin ne olduğunu bilir, daha önce kodlanmış olabilir) bu rollere en uygun olanı bulurum. Sonuçta bir sürü evrak işi var ve buna alıştılar.
Vincent Vancalbergh

11

Lider geliştirici olmak için iki bölüm vardır:

  • Teknik Liderlik Teknik liderlik için, proje düzeyinde farklı bir lider geliştirici seçmek mantıklıdır. Her geliştiriciyi, projeler döndükçe gerekirse döndürerek farklı bir proje için teknik bir lider yapın. Bu tür bir yaklaşım ekip dinamiklerini ele alabilir ve herkesin uygun şekilde mücadele edilmesini sağlayabilir

  • İletişim Dış dünyayla iletişim için tek bir iletişim noktası dış dünya için iyi, iletişim noktası için kötüdür. İletişim topuyla kim sıkışırsa, gerçek iş yapmak için daha az zamanı olacak ve etrafta dolaşmak için herkesten bilgi almak için koşacak. En iyi iletişimci sizseniz ve tüm konuşmaları yaptığınız, sizin için daha fazla güce sahip olduğunuzdan daha eğlenceli işler yapmayı bırakmaya istekliyseniz.


Öyleyse bu iki rolü bölmek mümkün olmaz mıydı? Genellikle en iyi iletişimci teknik olarak en iyisi değildir. Her biri bunlardan birinde öne çıktığında en iyi "çift programlama" durumunun ortaya çıktığını
gördüm

Onaylayabilir. İlk liderlik görevimi 6 ay önce (12 dev ekibinden oluşan ekip) kabul ettim ve şu anki kadar programlama yapmadan hiç zaman geçirmedim. Çoğunlukla sadece mentorluk, yönetim ve yukarı raporlama.
Bay JavaScript,

6

İlgili geliştiricilerin meşgul olması ve (ideal olarak) yetenekli olması şartıyla, bu kötü bir fikir değildir.

Bunun için referans bulmakta sorun yaşıyorum (ancak aramaya devam edeceğim), ancak bazı çevik şirketleri doğru hatırlıyorsam, bunu yapar - ya her yinelemede ya da başka bir önceden tanımlanmış zamanda "takım lideri" unvanını döndürürler. dönem. Bu, geliştiricinin katılımını teşvik eder ve herkese, bir geliştiriciyi bu rolün geliştirilmesinden kalıcı olarak hareket ettirmeden takım yönetimi / dış iletişimin bir kısmını yapma şansı verir.

Bazı dezavantajlar arasında potansiyel bilgi kaybı (bu çeşitli şekillerde hafifletilebilir) ve "kötü" liderlik potansiyeli daha yüksek olabilir. Ekip için vizyon / yön sağlamak da zor olabilir. Bununla birlikte, eğer herkes bu yaklaşıma sahipse ve ekip üyeleri hem bilgili hem de böyle bir sistem çalışması yapmakla ilgileniyorlarsa, buna değer olabilir.


HER bir dev'i takım liderliği pozisyonuna getirmek istediğinizi düşünmüyorum, ancak kıdemli bir devin bu sorumlulukları yerine getirebilmesini beklerdim. Açıkçası, bu saygısız bir iş ve yükü paylaşma ve bir bireyi yakmamaktan daha fazlası. Daimi org ekibinizin avantajlarını kalıcı bir lider olarak görmemek için dinamik olarak kullanmaya devam edeceğini düşünüyorum.
MebAone

“Bazı dezavantajlar arasında potansiyel bilgi kaybı (bu bir çok yolla azaltılabilir) ve“ kötü ”liderlik” için daha yüksek bir potansiyel var: sadece seçilen geliştiricilerde dönmeye ne dersiniz, bu sorunu önleyebilir.
Adrien

1
@AdrienBe Aralarında bilgi aktarmanız gerekir. Her zaman aynı anda liderlik yapmadıkça (amacı yener), bunu hesaba katmanız gerekecektir. Ayrıca takımda liderlik yapamayan ve kendilerini dışlanmış hisseden diğer devleri de yabancılaştırabilirsiniz.
Adam Lear

5

Döndürürseniz, bunu proje sırasında yapmayın. Bu projenin her pozisyonunda kimin en uygun olduğuna dayanarak, farklı projelere farklı insanlara farklı roller vermede kendinden yanlış bir şey yoktur. Ama Joe'yu “lider programcı” yapmayın, çünkü işi gerçekleştirme zamanı geldi. Yetenekli olmayabilir, hatta işi istemeyebilir.


4

Lider geliştiriciyi zamana göre döndürmek kötü bir fikirdir.

Herkes iyi bir geliştiricidir, herkesin iyi bir lider olduğu anlamına gelmez. Ve birincisi iyi bir lider, bu programın lideri için uygun olduğu anlamına gelmez.

Geliştiricilere verilen görevlerin öneminin farklı olduğunu ve her geliştiricinin liderliğinin farklı olduğunu düşünüyorum. Yöneticinize oy vermesini tavsiye edebileceğinizi düşünüyorum. Her biri en iyi aday için 2 kişi oy kullanır ve en fazla oyu alan kişi lider geliştirici olmalıdır.


3

Öncü geliştiriciyi döndürmenin kötü bir fikir olabileceği konusunda Jonathan Khoo ile aynı fikirdeyim . Genellikle daha büyük projeler için, projeyi yöneten tek bir teknik ipucu vardır ve bu kişinin çeşitli sistem çapındaki sorunları tartışmak için kendilerine raporlama yapan birkaç bileşeni olabilir.

Bununla birlikte, Jonathan'ın bahsetmediği önemli bir nokta, teknik liderin aynı zamanda projedeki diğerlerinin sahip olamayabileceği yüksek derecede bir kurumsal bilgi geliştirmesidir. Teknik ipucunu döndürerek, birileri pozisyona getirildiğinde bu bilgiyi geliştirmelerini istersiniz. Ek olarak, lider, son kullanıcılarla yapılan bazı (daha büyük) toplantılar için ideal olarak bulunması gerektiği gibi, proje dışındaki müşterileriyle de bir ilişki geliştirecektir.

Teknik bir ipucuna sahip olmak iyidir, ancak onları dışarı çıkarmaya çalışırsanız, bir tane olmadan daha iyi olduğunuzu fark edebilirsiniz.


2

İlk önce, bu kişinin rolünün ne olduğunu, kimden daha fazla ve ne kadar süreceğini belirlemeniz gerektiğini düşünüyorum.

Bunun, geri kalanınızın çalışma şeklini önemli ölçüde değiştirip değiştirmeyeceğini ve performansınızı düşürüp düşürmeyeceğini belirlemeniz gerekir. Bir kişinin olması, ciddi bir etkiye sahip olabilecek herhangi bir meslektaş yerine, kodunuzun her satırını "onaylamak" zorundadır.

Hiçbiriniz "üstün" olmadan, farklı ekip üyelerine farklı spesifik roller verilebilir. Yönetici ve diğerleri arasında en iyi iletişim kurabilen kişiye, bunu yapması için belirli bir rol verilebilir, ancak bu onların "öncü geliştirici" olduğu anlamına gelmez ve teknik olarak en iyi veya en iyi olan kişi olmayabilir. kod incelemeleri yapıyorum.


2

Görünüşe göre takım görünüşte düz olsa da, zaten aralarında bir lider olduğunu ve hepsinin bunu zaten bildiğini iddia ediyorum.

Kuruluş çizelgeleri, insanların gerçekte nasıl çalıştıklarını nadiren yansıtır. Özellikle "düz bir takım" gibi idealleştirilmiş grafikler.


2

Kuruluşunuz düzse, o zaman tüm geliştiricilerinizin resmi bir süreci takip etmeleri için Gereksinimler ve Çözümler Analizi (RSA) eğitimini tamamlayın. Daha sonra bir projeye birden fazla konu uzmanı (KOBİ) atayabilir ve tüm çözümlere yönelik belgelenmiş bir süreç alabilirsiniz.

Ayrıca, yöneticinin teknik olmadığını belirttiğiniz için, söz konusu kişi hala RSA sürecini yönetebilir ve iletişimi kolaylaştırabilir. Kolaylaştırma ve bireysel becerilerini geliştirmek için proje bazında belirli bir KOBİ'yi proje bazında atayabilirsiniz.



1
  1. Takımınıza liderlik etmek için takımınızdan birisini seçebilirsiniz.
  2. Patronunuz bu pozisyonu almak için deneyimli başka birini işe alabilir

PS: Dönmenin iyi bir fikir olduğunu düşünmüyorum, kişi iletişim becerisine sahip olmalı ve takım yönetimi konusunda iyi bir deneyime sahip olmalı.


1

Sorunuzun da önerdiği gibi, tüm ekip karar vermekten sorumlu, aynı şekilde tutabileceğinizi öneririm. Ancak, ekibin dışındaki yetkililerle iletişim kurmak ve raporlamak için, ekip içinden seçilen bir Ekip Koordinatörü olabilir . Sorumlulukları teknik olmayan her şeyi içerir. Tüm teknik özellikler için, ekibin şu anda yaptığınız gibi oturması ve tartışması gerekir. Hangi kararı verirseniz verin, Koordinatör aracılığıyla dış dünyaya iletilir . Bu pozisyon zamana bağlı bir şekilde kolayca döndürülebilir.

Diğer yaklaşım, aynı projedeki deneyim> deneyim> aynı şirketteki deneyime dayanan lider bir geliştiriciye sahip olmak olabilir. Gerekirse, pozisyon faz-faz bazında döndürülebilir. İdeal olarak, her geliştirme aşaması, mini bir proje olarak planlanabilen ve üzerinde çalışılabilecek kendi gereksinim ve teslim kümelerine sahiptir. Her faz için farklı bir lead'in olması, rotasyonun neredeyse tüm olumsuz etkilerini en aza indirecektir.


1

Dönen bir lider geliştiricisine sahip olmak yerine, dönen bir proje liderine sahip olmak, x projesini tamamlamaya yönelik en fazla bilgi ve anlayışa sahip biri.

Lider Geliştirici genellikle bir promosyondur ve kazanılmalıdır.

Ancak, liderlik becerilerinin geliştirilmesine ve geliştirilmesine yardımcı olmak için, farklı projelerden kimin sorumlu olduğunu döndürün ve daha sonra ne kadar iyi yaptıklarını veya ne yapmadıklarını net bir şekilde ölçün.


0

Aynı şekilde yeterince büyük bir gemide kaptan olduğu gibi bir takım lideri olmalı.

Yönetici bu rolü yerine getirmezse veya başaramazsa, geliştiricilerden birinin doldurması için atanması gerekir.


0

İlk olarak, geliştirme ekibinin içindeki tüm teknik kararları alma gücüne sahip olduğunuz için ne kadar şanslı olduğunuzu fark etmelisiniz. Kaç takımın teknik kaprislerini kendilerine dayatan bir mikro yönetme hiyerarşisinin yükü vardır, bu da genellikle tutarsız seçimler, uyumluluk kabusları ve geliştirici hayal kırıklığıyla sonuçlanır ...

Bahsettiğiniz bir dev liderin yararlarına göre, teknik beceriler konusunda doğal olarak olağanüstü bir kişi olsaydı, bazıları (organize teknik rehberlik ...) zaten olmuş olmalıydı. Böyle bir durumda, bu kişiyi resmi olarak lider bir geliştirici yapmanın şimdi elde ettiğinizden daha iyi sonuçlar vereceğini göremiyorum. Eğer böyle bir ekip üyesi ekibinizde mevcut değilse, o zaman resmen herhangi bir kişiye teknik otorite vermenin tartışma ve toplu karardan daha iyi sonuçlara neden olacağını göremiyorum .

Örgütsel bir lider kurma konusunda çok daha fazla değer görüyorum - Danimarka’nın belirttiği gibi bir koordinatör. Bir yönetici değil, bir patron değil, kolektif karar alma sürecini organize edecek ve ekibin sözcüsü olarak görev yapacak biri, dışarıya bir arayüz. Bu şekilde giderseniz, yukarıda belirtilen sorunlardan kaçınmak iyi bir fikir olabilir - maaş farkları, kıskançlık ...


0

Bazen, lider olmak bir şeylerden çok daha ağır bir sorumluluktur. Birisinin seçimler için sorumluluk alması gerekiyor, başka hiç kimse yapmak istemediğinde toplum böyle işler.

Bir ekibin lideri döndürmek istediği gerçeği, herkesin yaptıklarının sorumluluğunu üstlenebileceğini düşündüğü anlamına gelir ve kimsenin lehine olmak istemezler ve bu iyi bir şey gibi görünüyor: zor duygular yok ve herkes ekibin başarmasını istiyor.

Bu gibi durumlarda, alınacak zor kararlar olduğunda, sadece bu kararlar için bir oy verin ve diğer insanlarla konuşmak için bir temsilciye ihtiyacınız olduğunda, sadece en iyi iletişim becerilerine sahip birini seçin.


-1

Her şeyden önce, rolleri ayırmanız gerektiğini düşünüyorum. Takım ile şirketin geri kalanı arasında bir temas noktası görevi gören kişinin mutlaka nihai teknik kararlar veren kişi olması gerekliliği de yoktur.

Temas noktası olarak hareket etmek hiçbir yetki vermemelidir, bu nedenle sorumluluğu sabit bir zaman çizelgesinde döndürmek gerekli olmamalıdır. Ekibin oturmasını söylerim, herkes işini yapmanın ne kadar sakındığını söyler (bazı insanlar hoşuna gidebilir, diğerleri buna şiddetle karşı çıkabilir), sonra rolünü doldurması için oy verin. Bunu yapmaktan bıktıklarında onu başkasına devredebileceklerini anlayın.

Teknik kurşun tarafı gelince. Eğer herkes aynı beceri setine ve kabaca aynı seviyede bir deneyime sahipse, elbette herkesin bir liderlik için elini deneymesine izin verin. Önemli olan, kesinlikle proje ortasında değişmemek. Yeni bir projenin başlangıcına kadar bekleyin ve ardından o alanda en fazla deneyime sahip olan veya rastgele olanı seçin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.