Üst düzey programcıların küçük bir geliştiriciyi üstlenmeleri ve mentorluk yapmaları gerekir mi? [kapalı]

Sıkı sıkı ve destekleyici bir mağazada, üst düzey geliştiricilerin, genç geliştiricilerle mentor olarak eşleşmeleri kültürün bir parçası mı olmalı? Yoksa bu mentorluk daha organik ve kendiliğinden olan, yani gerekli olmayan, ancak yapay bir teşvik olmaksızın gelişmesine izin verilen bir şey mi olmalı?

Bence teşvik edilmeli ancak gerekli değil; yaşlılar gençlere veya onun gibi birşeye atanmamalı, yoksa Dilbert-diyarına gideceksin. “Mentor mentee” ilişkisi, özünde sağlıklı bir MUTUAL saygı dozunun bir derecesinde dostluk gerektirir. Bunu sadece insanlara gidip "söz" etmelerini söyleyerek elde edemezsiniz.

Üst düzey geliştiricilerin, genç geliştiricilerle mentor olarak eşleştirilmesi kültürün bir parçası mı olmalı?

Evet.

organik ve kendiliğinden, yani gerekli değil, ancak yapay teşvik olmadan gelişmesine izin verildi.

Gerçekten kimseye yardım edecek kadar sık ​​olmayacak.

Örgütlerde var olan ilişkileri olan insanlar, yeni insanlar tarafından klipler veya seçkinler olarak algılanacaktır. Klikler normalde bozulmaz. Tanıdığımız insanlara bağlıyız - bu insan doğasının temel bir unsurudur.

30 yıldan uzun bir süredir danışman olarak (100'den fazla müşteri katılımı) yeni insanların her zaman yabancı olduğunu iddia edebilirim . Bu "kültür" veya "atmosferik" bir özellik değildir. İnsanların nasıl çalıştığının temel bir özelliği. Danışmanlar kendi gruplarını oluşturur çünkü yerleşik personel onları hiçbir şeye dahil etme eğiliminde değildir.

Mentorluk kurmanın tek yolu, yeni insanları klikelere yerleştirmektir.

“Mentor” un geleneksel anlamı bir şekilde ödevlere meydan okuyor. Bir arkadaş edinebilirsin de.

Tecrübelerime göre, ilk hafta, ay, vb. Sırasında sorular için asıl irtibat olarak kurulmuş bir ekip üyesini kullanacak yeni bir ekip üyesi atamak iyi.

Genç geliştiricilere mentorluk yapmak için kıdemli geliştiricilere ihtiyaç duyulmalı mı?

Kesinlikle hayır. Bazı iyi üst düzey geliştiriciler, korkunç mentor olacak ve kişiliklerin eşleştirilmesi, başarılı mentorluk gemisi için şarttır. Bununla birlikte, üst düzey geliştiricilerin geliştirme ekibi hakkında daha iyi şeyler yapması gerektiğini düşünüyorum. Bu, bir tarafa prototip yapmak, bir süreci veya uygulamayı geliştirmek, yeni araçlara öncülük etmek, gruba teknik malzeme sunmak, bir takıma veya başka bir şeye öncülük etmek olabilir. Başka bir deyişle, bireysel iş paylaşımından daha büyük bir şey için sorumluluk almaları gerekir.

Yoksa bu mentorluk daha organik ve kendiliğinden olan, yani gerekli olmayan, ancak yapay bir teşvik olmaksızın gelişmesine izin verilen bir şey mi olmalı?

Hayır, onunla aynı fikirde değil. Mentorluğun "organik ve spontan" olması beklendiği ve çok nadiren gerçekleştiği çok fazla durum gördüm. Bence organizasyonlar mentorluğa bulaşıcı olma şansı verme onusunu üstlenmeye ihtiyaç duyuyor - ama bu zorlanamıyor. Bu zor ama değerli. Kuruluşun aşağıdakileri yapabileceğini düşünüyorum:

• Potansiyel mentorlar ve potansiyel proteinler arasındaki gayri resmi buluşmalar
• Mentorluğun kurum tarafından resmi olarak tanınması için önerilen yollar ve fırsatlar (örneğin, hemen hemen her şey için bir ücret numarasına sahip bir yerseniz, mentor gemi toplantıları için bir ücret numarası oluşturun - bunun çalışmanın uygun bir parçası olduğunu )
• Mentorlar için eğitim ve destek
• bir mentorun nasıl seçileceği ve ne bekleneceği konusunda proteinlere rehberlik
• danışmanlara ne bekleyip ne sunabileceği konusunda rehberlik
• Katılım şablonları içeren mentorluklar için önerilen (veya zorlanan) modeller - örneğin, hedefinizin haftalık toplantılarla 3 aylık bir deneyim olduğunu ve yeni bir geliştiricinin kalkmasına yardımcı olma hedefini önceden bildiğinizi düşünüyorsanız bir çekim yapmak çok daha kolaydır ve şirkete gidiyor. Daha fazla gelişmeyeceğini söylememek ... ama insanların başlaması için bir yer veriyor.

Bence bunu bir zorunluluk haline getirmenin potansiyel olarak geri tepebileceğini düşünüyorum, çünkü bazı insanlar sadece bu şekilde bağlanmadı ve bu fikir tarafından kapatılacaklardı. Bu söylendiğine göre, mentor olmaya uygun olduğunu düşündüğünüz insanları tanımlamalı ve onlara mentorlukta daha aktif bir rol alma konusunda yaklaşmalısınız (zaten değilse). Bu örnek örnek yaklaşımı daha fazla spontan mentorluk yakalayabilir ve ilham verebilir.

Ayrıca ekibin jöle yapmasına yardımcı olacak düzenli olarak gerçekleşen grup etkinliklerini de planlayabilirsiniz. Bunlar bir takım yemeği gibi tamamen sosyal aktiviteler veya haftalık programlama kitabı kulübü gibi programlama hakkında öğrenmeyi içeren aktiviteler olabilir.

Ayrıca, bir grup kod incelemesi gibi işlev görecek sistemlerde düzenli "mini postmortems" olabilir. Gözden geçirmeyi bir grup ortamında yapmanın bir yararı, yalnızca orijinal kodu yazan kişi yerine, geri bildirimden herkesin yararlanabileceğidir. İşleri başlatmak için kendi kurallarını değerlendirmek için rahat olan bazı gönüllülere ihtiyaç duymanız ve uygarlığı devam ettirdiğinizden emin olmanız gerekebilir.

Junior ve Senior programcı terimlerini hiç beğenmedim. Örneğin, bir süredir programlama yapıyorum ve bazı alanlarda deneyimim olmasına rağmen diğerlerinde çok yeşilim. Örneğin, WPF'ye geçiyoruz ve tonlarca pencerede uygulama deneyimi olmasına rağmen, WPF hala yeni ve benim için ayrılıyor. Bu yüzden "üst düzey" bir programcı olmama rağmen, caddeden birisini 'toplam' tecrübesiyle daha az işe alabilir ve muhtemelen bu noktada benden daha iyi ve daha hızlı bir WPF uygulamasını programlayabilirler.

WPF uygulamasına uygulanabilecek pek çok iyi uygulama tasarım ve mimarlık deneyimi olmadığını söylemiyorum, ancak sınırlarımı biliyorum.

Sanırım bazı zamanlarda akıl hocası, diğerlerinde de mentee olmaya istekli olmalısınız.

Bilgiye sahip olduklarında mentor olmaktan korkmayan takım üyeleriniz varsa ve bilgiye ihtiyaç duyduklarında başkalarına karşı mentee ettiyseniz, verimli bir deneyime sahip olacaksınız.

Geliştiricilerin mütevazi olduğu ve yeni fikirlere açık olduğu ve ihtiyaç duyulduğunda başkalarına yardım edebileceği bir gelişim ortamını teşvik edebilirseniz, sempai-kohai ilişkileri doğal olarak ortaya çıkacaktır.

Mentorluğa zorlama muhtemelen geliştiricilerin birbirlerine kızabilecekleri bir kast sistemi yaratacaktır. Her geliştiriciye aynı seviyede eşit davranmak daha iyidir.

Bu endüstri çok farklı. Senority her zaman daha iyi değildir.

Bazen yaşlıların gençler tarafından mentorluk yapmaları gerekir.

Her iki şekilde de iş yapan ortamlarda bulundum.

Okuldan ilk çıkardığım iş, akıl hocamdı. Adamdan hoşlanmadım ve kesinlikle her konuda onunla aynı fikirde değildim. Onunla çalışmak zorunda kaldığım için kızdım ve işverenimin bir hata yaptığından oldukça emindim ama geçmişe bakıldığında çok şey öğrendim.

Birkaç yıl hızlı ileri sarıldım ve şimdi geliştiricilere her biri için özel bir tutum sergileyen bir şirketle birlikteyim. Geliştiriciler sıkı son tarihler altındadır ve çok az zaman harcayan geliştiricilerin kendilerine ipleri göstermek için kendi kanatlarının altına alarak zaman harcayan geliştiriciler için herhangi bir ödenek verildiğinde çok azdır. Bence bu utanç verici. Genç geliştiricilerin yaptığım aynı şeylerle nasıl mücadele ettiğini görüyorum, ancak onlara yardımcı olmak için bir akıl hocası olmadan onları daha uzun sürüyor.

"Mentor" olarak ün kazandım, çünkü yeni işe alımlar "onlara sağlayabildiğim yardımı takdir ediyor" gibi görünüyor. Söyleyebileceğim kadarıyla, bu, vasat verimlilik değerlendirmelerine tolerans göstermeye istekli olduğumu ve bu sayede genç geliştiricilerin işlerini etkili bir şekilde yapmalarını ve hızlı bir şekilde gelişmelerini sağlamak için doğru şeyi yapabildiğimi söylemenin süslü bir İK yöntemidir.

Bence genç çalışanlarımızın hak ettikleri budur ve hightight ve tecrübenin yararına, ilk çalıştığım şirketin ve beni yönlendiren adamın o zaman düşündüğümden daha fazla düşündüğünü düşünüyorum.

Bunların hepsi, size mentor atamak zorunda kalmamayı dilerken, muhtemelen işin etrafına yayılmanın tek adil yolu olduğunu söylemenin uzun yoludur. Bunu yapmazsanız, bunu yapan insanlara kendi durumlarını vermelisiniz. Kolay iş değil; hem kişiler arası hem de mühendislik becerisi gerektirir; ve zaman alıcıdır.

Üst düzey geliştiricilerin kod kaybının dışına çıkması bekleniyor. Ancak, gittiği yön her kıdemli geliştirici için aynı olmamalıdır.

Bazıları mentorluğa çok uygundur. Diğerleri, mimari iyileştirmeler planlayıp uygulayan ya da yeni teknolojiyi değerlendiren ya da süreç iyileştirme planlaması ve öncül iyileştirme (örneğin sürekli entegrasyon, TDD, vb.) Gibi başka bir üst düzey hedefin peşinde değil ve olmalıdır.

Temel olarak, bir kıdemli sadece gençler arasında birkaç yıldan fazla bir süredir kodu kesen biri olmamalıdır. Takımın başarısına katkıda bulunacak ek sorumluluklar almaya istekli ve bunu yapabilen biri olmalıdır. Gençlere mentorluk yapmak önemlidir, ancak tek önemli olan bu değildir ve herkesin uygun olduğu bir şey değildir.

Bu tür mentörlük yapmak zorlayıcıdır çünkü insanlar doğal olarak zorla faaliyetlere, eylemlere ve ilişkilere karşı gayret gösterirler . Daha iyi bir yaklaşım, iyi mentorluk yapan insanları ödüllendirmek , böylece insanları mentor olmak istemelerini sağlamaktır.

Elbette bu, bu bağlamda "iyi" ölçülmesi sorununu da beraberinde getiriyor. Kusurlu ancak kolay uygulanabilen bir çözüm, bir yıl sonra yeni gelenlerin şirkete ve / veya kod tabanına entegre olmalarına yardımcı olan ilk üç kişinin isimlerini yazmaları olabilir. Bundan sonra en çok adı geçenleri ödüllendirebilirsin. Bununla birlikte, para ödülleri burada çalışmaz. Bir tür sosyal ödül bulmak daha iyidir.

Takım liderliği yapısı, kod değerlendirmeleri için hile yapmalı ...

Bir ya da daha fazla gençten sorumlu kıdemli bir üyeye sahip olursunuz. Kendiliğinden yardım olması gerektiğine inanmıyorum, daha ziyade resmi bir süreç; Bu anlamda, kıdemli üye yeni gelenlerin ürettiği işin kalitesinden sorumlu olacak. Bu yaklaşımın 2 faydası vardır (en azından): yaşlılara yönetim tarzlarında bilgi verin ve gençlerin kalite kodu üretmesini sağlayın.

Her şeyde programlama buna bağlıdır . Ancak, kesinlikle ister genç olsun ister olmasın, yeni işe alım danışmanlığı yapan üst düzey bir geliştiriciye, eldeki iş için en iyi eğitimi almalarını isterdim.

Hayır, çünkü bu kıdemli ve küçük geliştiricilerin sayısının her zaman aynı olacağı anlamına gelir. Mentor olmak isteyen üst düzey geliştiricileri cesaretlendirebilir, ancak eşleşmeyi zorlamak gerçekten kötü bir fikir olabilirdi. Mentorluk ilişkilerini destekleme fikri iyidir ve buraya atılmamalıdır.

Yapay teşvik burada olsa kötü bir fikir değil. Tüm küçük ve üst düzey geliştiricilere, biraz dindar ve geri tepme ne olursa olsun, kısa sürede motive olacaklarını ve mentor olacaklarını söylemek.

Şirket içinde mentorluğun nasıl kullanılacağına dair bir çerçeve varsa, bu harika olurdu. Ancak, eğer bu olmazsa, anahtar mentor ile mentee arasında birkaç farklı türde anlara sahip olur:

1. Mevcut durum - İşler şu an nerede? Mentorun bu sorunu çözmede yardım edebileceği mevcut zorluk nedir?
2. Gelecek durumu - Ne aranıyor: Bir ipucu, bir çözüm, sorulacak sorular, kime sorulacak?
3. Retrospektif - Ne çalıştı ve değişiklik yapmaya çalışmadı mı?
4. Gelecekteki değişiklikler - Gelecekte daha önce yapılanlardan daha iyi çalışabilecek neler denenecek?

En azından bunlar mantıklı bir yukarıdan aşağıya yaklaşımı benim görüşüme göre anlayabildiğim ve anlayabildiğim durumlar. Diğerleri de işe yarayabilecek daha organik ve serbest formlu bir şey isteyebilir. Kilit nokta, her iki tarafın da bu ilişkide iletişim kurma pratiği ile kazanılması gereken bazı becerilere sahip olmalarını sağlamaktır. Her iki taraf ilişkiden bir şeyler kazanmalı ve bu tür bir ilişkiye sahip olmanın ortak temel kuralları olmalı, çünkü geri bildirim burada çok önemlidir.

Birinin bu konuda ne kadar zaman harcadığı, gerçekçi olarak, ne yapıldığına ve becerilerini geliştirmek ve ilişkiler kurmak için zaman harcamak için ne kadar kabul edilebilir olduğuna bakmak zorunda olan gerçekçi bir sorudur. Bunu yapmak için haftada bir saat isteyen bazı çiftler görebiliyordu, bazıları ise bunun üstesinden gelmek için günde birkaç saat isteyebilirdi. Resmi bir mentorluk ilişkisi içinde olmasa da, yaşlı ve gençlerin birlikte çalışabileceği başka etkileşimler olabileceğini unutmayın.

Mentorluk sistemlerinde birkaç farklı girişim gördüm. En çok sevdiğimler, üst düzey devin, küçük deve yardım etmek için gerçekleştirdikleri belirli bir görev setine sahip olanları gerektiriyordu; Örneğin, ilk altı ay için bire bir kod yazarı atanan bir üst düzey dev çok faydalı olabilir ve mentorluğa yol açabilir. Sevmediklerim, fazladan iş gibi hissettiren ve yapılan işle doğrudan ilişkili gibi görünmeyenlerdi - örneğin, atanan danışmanınızla her hafta yarım saat buluşmak. Bu, mentorluk ilişkisinin iki üyesinin genellikle hafta boyunca birbirleriyle etkileşime girmediği ve birbirlerinin projeleriyle ilgisi olmadığı zaman bu çok sinir bozucuydu. Profesyonel olarak büyümeye odaklanmaktansa, çok zorlanmış ve dokunaklı hissediyordu. İstediğiniz son şey, mentorluk ilişkisinin bir danışma toplantısı gibi hissetmesidir.

IME, gelişmekte olan mentorluk ilişkilerine güvenemezsiniz; bu nedenle, en azından en azından en azından en azından İlk olarak, harika bir fikir. İdeal olarak, kıdemli üye rol için gönüllü olmalı ve bazı kişisel çıkarları algılayabilmelidir. Şu andaki şirketimde, üst düzey geliştiriciler neredeyse projeleri için önderlik ediyorlar ve bunun yararı kendi projelerinin ekibini oluşturmaları. Diğer şirkette mentorlar sıklıkla yönetim izini araştırıyorlardı.

Genç geliştiricileri işe alan her şirketin, oldukça etkili bir mentorluk programı yapması gerektiğini düşünüyorum. Ancak, varsayılan pozisyonun her üst düzey geliştirici olması gerektiğinden emin değilim, geliştirmelerinde ne kadar iyi olduklarına bakılmaksızın, birçok geliştiricinin mentorlukta sakıncalı olmasının basit bir nedenden dolayı yapması gerekir. Ne yazık ki bölge ile gider. Bazılarımız sadece istersen harika insanlar değiliz.

Öte yandan, bu konuda iyi insanların olduğu yerlerde, bunun için tanınırlık kazanmalı ve karar vermemelidir; Örneğin, NotePad ve Javac'ı kullandı.

Bu biraz dengeli bir yönetim gerektirir. Yaygın olduğundan emin değilim.

Herhangi bir mentorluğun çalışması için, yönetimin bunun önemli olduğunu kabul etmesi ve buna zaman ayırması ve bunu aktif olarak teşvik etmesi şarttır!

Görevlendirmeyle rezervasyon yaptırmış% 100 kişi için tam anlamıyla mentorluk yapma veya alma zamanı yoktur ve bu olmayacak.

Genel olarak mentor gemileri, kıdemliden ekip liderine veya yöneticisine geçiş için iyi bir adım atıyor. Mentorluğu PDP'deki (Kişisel Gelişim Planı) veya şirketinizin kullandığı herhangi bir hak planında ilerleme ile ilişkilendirmek daha etkilidir. Maaş artışlarını ve kariyer gelişimlerini en azından kısmen bilgi aktarma ve yeni geliştiricilere tımar yapma yeteneklerine bağlı kalmak, yönetim ve personel cirosunda değişiklik yapabilecekleri güçlü bir BT Personeli oluşturmak için anahtardır. Kilit hedefler sunmak ve kendilerini geliştirmelerine yardımcı olmak için çalışanlarla çalışmak, bu büyümenin liderliğe girmesinin bir parçasıdır. Yaşlıların değerlendirmesini, büyümenin bir parçası olan bir genç performansına bağlamanın adil olmadığını düşünenler için. Çoğu durumda, bir ücret indirimi hakkında konuşmuyorsunuz, bunun yerine, azalan artışı ya da yavaşlamayı azaltıyorsunuz.

Takıma ilk geldiğimde bana talimat veren sahibi ve lider geliştiricisindeydim. Her ikisine de bir şey sorabilirdim ve ikisi de cevap verecek. Gerçi, tam zamanında çözemediğim sürece, onları rahatsız etmeyecek kadar saygılıydım.

Harika çalıştı, ancak sonra yine, muhtemelen bu işe almak için espri anlayışı ile iyi insanlara ihtiyacınız var.