Programcılar piyangoyu kazanırsa, şirketinizin su altında kalmamasını nasıl sağlayabilirsiniz [kapalı]

Altımda birkaç programcı var, hepsi açıkça çok harika ve çok akıllı. Çok teşekkür ederim.

Ancak sorun şu ki, her biri, ekipteki hiç kimsenin ne olduğu hakkında en ufak bir fikri olmayan bir çekirdek alandan sorumlu. Bu, eğer biri dışarı çıkarılırsa, bir işletme olarak şirketimin değiştirilemediğinden ölmüş demektir.

Bir otobüse çarpmaları veya istifa veya her neyse, onları kapsayacak yeni programcılar getirmeyi düşünüyorum. Ama korkarım ki

1. Eski programcılar aktif olarak bilgi aktarımı fikrine karşı direnebilirler, bir yedeklemenin değerlerini azaltacağından korkuyorlardı.
2. Farklı geliştiriciler arasında teknoloji transferini kolaylaştıracak bir sistemim yok, bu yüzden onlardan yapmalarını istesem bile, doğru bir şekilde yapacaklarına dair hiçbir güvencem yok.

Benim sorum

1. Eski programcılara nasıl anlaştıklarını söyleyelim
2. Bu tür bir "yedeklemeyi" kolaylaştırmak için kullandığınız sistemler nelerdir? Kod incelemesi yapabileceğinizi anlayabiliyorum, ancak bunu yapmanın basit bir yolu var mı? Sanırım giriş kodu incelemesiyle tam bir giriş için hazır değiliz.

Eski programcılara nasıl anlaştıklarını söyleyelim

Sorunu onlara açık bir şekilde sunun, tabii ki bunu tehdit olarak görmeyecek şekilde, ekip ve projenin daha iyi çalışmasını sağlamak için bir fırsat. Örneğin, "Başkalarının kovulmanız durumunda bildiklerini bilmek istiyorum" açıkçası yanlış bir yaklaşım :-) "Bazılarınız tatile giderse veya hasta olsa bile projenin düzgün çalışmasını sağlamak isterim " çok daha iyi.

Genellikle geliştiriciler, bazıları tatilde olduğu ve kendileri için örtmeleri gereken her zaman, sorunları kendileri yaşarlar. Dahası, iyi geliştiriciler üzerinde çalıştıkları proje için sorumluluk hissediyorlar, bu nedenle muhtemelen bu fikirle aynı fikirde olacaklar. Yine de, onlara fikirlerini tartışma ve (umarım) taahhüt etme zamanı verin. Ayrıca, takım içinde bilgilerini nasıl ve kimlerle paylaşacaklarını söyleyebilmelerini sağlayın. Joe'nun Jim'le çalışmak (ve bilgilerini paylaşmak), ancak Jack'le değil.

Bu tür bir "yedeklemeyi" kolaylaştırmak için kullandığınız sistemler nelerdir? Kod incelemesi yapabileceğinizi anlayabiliyorum, ancak bunu yapmanın basit bir yolu var mı? Sanırım giriş kodu incelemesiyle tam bir giriş için hazır değiliz.

Ekibimizde kod / tasarım incelemeleri dışında kullanıyoruz

• Ekip üyeleri arasında görevlerin ve sorumluluk alanlarının rotasyonu (her birimizin ana sorumluluk alanları vardır, ancak her zaman ve sonrasında, başka bir ekip üyesi tarafından daha iyi bilinen bir alanda görevler yaparız)
• Yüz yüze bilgi aktarımı oturumları (genellikle yukarıdaki işler gerektiğinde, ancak birileri ekipten ayrılmadan önce)
• Takım / proje wiki

Kod incelemesinin kendisi, birçok alanda, geliştiricinin bilmesi gereken, koddan doğrudan okunabilecek olandan çok daha fazlası olduğu için yeterli olmayabilir. Başka bir deyişle, etki alanı modeli de var. Kodun gerçekte ne yaptığını okuyabilirsiniz , ancak model olmadan nedenini bilemezsiniz .

Bilgilerini paylaşmaları için onları motive etmenin bir yolu, onlardan çalışmaları hakkında diğer insanlara kısa bir sunum yapmalarını istemek olacaktır . Programcılar normalde çalışmalarından gurur duyarlar ve bu onu gösterme şansı olur. Bir sunum, yabancılar tarafından nadiren bilinen bazı tuhaflıkları göstermelerini sağlamak için iyi bir fırsattır.

Ayrıca, neden sadece bu konuda açık olmamaya ve herkese birisinin otobüse çarpması durumunda hepinize bir bilgi paylaşım şeması bulmanız gerektiğini söyleyin. Bunu mantıksız görmüyorum. Şu an benim şirketimde oluyor ve bazıları savunmada bulunsa da yapılması gerektiğini biliyorlar.

Belki bazı şeyler üzerinde çiftler halinde çalışabilirler , eğer meraklı bir yapıya sahiplerse, sorun olmamalıdır.

Yazılımın dahili dokümantasyonunu güncel almak, yeni kişileri işe almadan önce ilk adım olmalıdır. Elbette, değerli programcılarınızın IDE yerine Office ve UML araçlarıyla biraz zaman geçirecekleri anlamına gelir, ancak her durumda buna değer olduğunu düşünüyorum.

Mevcut bir dokümantasyonunuz olduğunda, programcıların, diğerlerinin ne yazdığını herkesin anladığından emin olmak için kontrol etmelerine izin verebilirsiniz. Hala yeni insanlara gerek yok.

O zaman yeni insanlar almayı düşünebilirsiniz. Ya da şirketinizdeki iş yüküne bağlı olarak.

Büyük bir şirketseniz İK'yi arayabilir ve bu konuda konuşabilirsiniz. İnan bana, kilit personel bir otobüse çarptığında, muhasebe görevlilerinde de aynı sorun var. Bir pazarlamacı, önemli pazarlıkların ortasında bir zombiye dönüşürse, pazarlamacılar da çok fazla sorun yaşayacak - sık sık oluyor, ya da bana söylendi.

Bunun için doğru İK dilinin arka arkaya planlama olduğunu düşünüyorum . Şirketiniz bununla baş etmek için zaten politika ve çerçevelere sahip olabilir.

Çalıştığım bir yer aynı sorunu vardı. Yaptıkları, her bir Kıdemli geliştiriciyle çalışmak için bir küçük geliştiriciyi işe almaktı. Projelerde birlikte çalışan 2 kişilik küçük ekipler oluşturdular. Birkaç ayda bir veya projelerde küçük geliştiricileri döndürürler. Bu şekilde, Üst düzey geliştiriciler konu uzmanları olarak kaldı, ancak küçük geliştiriciler tüm sistemleri ve birlikte nasıl çalıştıklarını iyi anlamaya başladı. Ayrıca takım büyüklüğü ile iki katına çıkma projeleri daha hızlı hale geldi.

Ortaya çıkan daha büyük projeler için Üst düzey geliştiricilerden, bazen diğer sistemleri öğrenmeye başlayabilmeleri için bir projenin uzunluğu boyunca sistemin başka bir bölümünde Junior geliştirici olarak davranmaları istenmiştir.

Buradaki kilit nokta, ekibi geliştirmeye ve büyütmeye devam ederken mevcut geliştiricilerin bilgi ve kıdemlerine saygı duymaktı. Yavaş bir süreçti ama zamanla gayet iyi çalıştı.

Açık kaynaklı projeleri başarılı kılan şeylerden biri de "sahip olma" kodunun eksikliğidir. Bununla birlikte, hiç kimsenin bir uygulama alanının tek koruyucusu olmadığı anlamına gelir - herkes uygulamanın herhangi bir bölümüne katkıda bulunmaya teşvik edilebilir. Bu kesinlikle inandığım bir şey.

Yapmak istediğin şeylerin yolunun şu an sahip olduğun takıma zarar verdiğini açıklamak. Karşılaşmak istediğiniz noktalar ve tercihen bu sıraya göre:

• Bunun nasıl çalıştığını bilen tek kişi sizseniz, pike inen diğer harika şeyler üzerinde çalışmanıza izin veremem.
• Biz istiyoruz sen iyi bir tatil yapmak mümkün, ama hiç kimse senin yaptığını çünkü göze alamaz.
• İnsanların işlerini değiştirmeleri çok hoş olmayan bir gerçek çünkü şu anki durumlarından memnun değiller, sizi kaybetmek istemiyoruz, çünkü çalıştığınız alanın sıkışıp kaldığını hissediyorsunuz.

Kişisel bir not olarak, vefat eden bir iş arkadaşı ile uğraşmak zorunda kaldım. Herhangi bir bilgi silosu bulunmamakla birlikte, kayıp hala sert bir şekilde devam etmektedir. Bunun olma olasılığı yukarıdaki üçüncü mermi noktasından çok daha düşük.

Davanızı ortaya koyduktan sonra, sorunun nasıl düzeltileceğine dair fikirlerini almak için yardımlarını alın. Elbette kendinle gel. Fikirleri, bir ekibin parçası olduklarını anlamalarına yardımcı olacak ve uzmanlık alanlarından daha fazlası için ihtiyaç duyulacak. Jane'in Joe'nun yaptıklarına ilgi duyması olabilir, ama biraz korkutuyor olabilir. Bunun, bilgi transferinin daha eğlenceli olmasına yardımcı olabileceğini bilmek. Yapmak isteyeceğiniz şeylerden bazıları:

• Mevcut takımı çapraz eğitin. Kısa vadede biraz verimlilik kaybedebilirsiniz, ancak uygulamanın bir köşesinde uygulamanın diğer bölümlerine uygulanabilecek bazı dersler çıkarılabilir. Jane ve Joe'nun bir süre birbirlerinin projesinde birlikte çalışmasını sağlayın.
• Bir bilgi paylaşımı kültürünü teşvik edin. Çalıştığım bir şirketin "kahverengi çanta teknolojisi konuşması" programı vardı. Herkes onaylanan herhangi bir konuda sunum yapabilir (genellikle teknoloji veya yazılım işlemlerini tanıtır). Şirket öğle yemeğini hazırladı ve sunum yapan kişi çabaları için birkaç yüz dolar aldı.
• Mentorluk bir yaşam tarzı olmalıdır. Başkalarını mentorluk yapmanın amacı, sizi yeni şeyler yapmakta serbest bırakmak ve sizi şirket için daha da değerli kılmaktır.
• Bilgi silosu sınırlarını geçmeden rütbe çekmeden yollarını bulun. Ne kadar eğlenceli yaparsanız, o kadar az tehditkar olur. Takımınızdaki insanlar söylediğiniz kadar iyiyse, muhtemelen olaylardan tamamen memnun değillerdir. Takımın başa çıkıp çıkamayacağının yargıcı olmanız gerekecek, ancak “hadi öyleyse seçelim” haftasına sahip olabilirsiniz. Her zaman burada kendinle başla. Fikir, herkesin gözünde “so-so-so” nun sorumluluklarının ne olduğunu ve yaşadıkları problemleri nasıl daha iyi çözebileceklerini anlamaktır. İlk önce boynunuzla birlikte başladığınız sürece, kimsenin işini yapamayacağı fikrine sahip olacaklar.

Genel olarak, işi daha zevkli hale getirmek istediğinizi ve bunun için onların yardımına ihtiyaç duyduğunuz konusunda onları etkilemeye çalışın.

Stajyerler iyi bir fikir olabilir, mevcut geliştiricilerin doğrudan astları olacaklar, bu yüzden kendilerini tehdit altında hissetmeyecekler.

Şirket büyüdükçe, hem eski geliştiricilere hem de staj sonrasında bunu yapanlara ihtiyacınız olacak.

Bence bu işe yarayabilir.

Genel olarak, bazı yöneticiler birdenbire dokümantasyon ve arka arkaya planlamaya özen göstermeye başladığında, programcıların kovulması veya işten atılmak üzere olduğu güçlü bir uyarı işaretidir. Tipik yönetim davranışından böyle bir ayrılıktır ve programcılarda her türlü uyarı sinyalini vermesi endişesiyle karşı karşıyadır.

Herkese tüm işlemlerini ve süreçlerini belgelemesi söylenir.

" Kurumsal Doom Uyarı İşaretleri " nin Seviye 3'ü .

Bir alternatif olarak, bir makalede " Yukarı veya Dışarı " kültürünü teşvik edeceğimizi öne sürmekteyiz. içeriyor.

@AmmoQ'nun cevabında başlattığı tam dokümantasyon kavramını geliştirmek ...

İyi bir yönetici, doğrudan raporlarının becerilerini geliştirmek için çalışır, böylece raporlardan herhangi biri yerini alabilir. Geliştiricilerinize, işlerinde tam şeffaflık sağlayan bir çalışanın, tüm çalışmalarını gizli ve gizli tutanlardan daha değerli olduğunu anlamasını sağlayın. Eğer 'gizli' geliştirici bugün bugün öldüyse, bu kaybedilen bilgiyi geri kazanmak şirkete büyük bir maliyet sorumluluğu olacaktır. Eğer “tam açıklama” çalışanı bugün ölmüşse, şirket hala zararda olacaktır, ancak daha az yıkıcı olacaktır. Bu nedenle, “tam açıklama” çalışanı daha fazla değere sahiptir.

Kendisini kovulmaya karşı bağışık kılmak için gizli bilgileri saklamaya çalışan herhangi bir çalışan da bir terfi için bağışıklık kazanır. Günümüzde sahip oldukları sıradan işleri tamamlayacak kimse yoksa bir geliştiriciyi daha zorlayıcı ve ödüllendirici bir konuma getiremezsiniz. Eğer sıradan işler tamamen belgelenirse ve tamamen açıklanırsa, önceki geliştiriciyi doldurmak ve daha üst bir pozisyona yükseltmek için yeni bir geliştirici kiralayabilirsiniz.

Bu, sizin de yaptığınız şeyi belgelemeniz ve doğrudan raporlarınızın her birine eğitim vermeniz gerektiği anlamına gelir. Bu şekilde, sen bugün öldü tam zamanlı yedek bulunana kadar, onlardan biri sizin için doldurulabilir.

Yeni programcıları getirmeye başlamadan önce, her birinin kendi belgelenmiş mirasını yaratmalarına yardım etmelerini isterdim.

Ya bir wiki ile ya da işlerinin her yönüyle ilgili 3-halka bir belge inciliyle.

Ya da gerçekten ayrıntılı ve eksiksiz bir dokümantasyon istiyorsanız, her programcı ile röportaj yapmak için teknik bir yazar kiralayın ve daha sonra herkesin günlük, haftalık, aylık, yıllık yaptığı her şeyin bir dokümantasyonunu oluşturun.

Ardından, programcınızın güncelleme / düzenleme / katılım / yorum yapabilmesi için bir wiki sürümü oluşturun.

O zaman, zamanla büyüyecek bir sisteme sahipsiniz ve yeni programcılar için gelişmiş bir öğrenme eğrisi olacaksınız.

Ayrıca dürüst olmak gerekirse, programcının sadece bir çekirdek alanda sıkışıp kalması akıllıca değildir, gerçekten treni geçmek, çekirdek işleri geçmek.

Ardından, 1 kişi tatile çıktığında veya onun gibi bir şey olduğunda mevcut personelinizi kullanabilirsiniz.

Programlayıcılarınızdan biri hastalandığında, soruları ve problemleri ile tekrar tekrar telefon edin.

Programlayıcılarınızdan biri tatilde olduğu her an, sorularınız ve sorunlarınızla tekrar tekrar telefon edin.

Yakında onlar için hem de şirketin çekirdek alanlardan sorumlu tek kişilere sahip olmamanın daha iyi olacağını anlayacaklar .

Kimse otobüse çarpılmak istemez, ancak kısa sürede başka birinin projesini devralmak ve projelerini sürdürmek de istemezler. O zaman herkes işsiz kalma riskini taşıyor.

Silolarda gelişiyorsanız, insanları bir projeden diğerine taşımaya başlamanız gerekir. Belgelendirme, kod incelemesi veya basit bir hatayı düzeltmekle başlayın. Herhangi bir küçük kod koruma / bölge davranışı, kullanımın çok ötesine geçmeden ele alınmalıdır.

Kodunuzun bir parçası üzerinde yalnız bir uzmana sahip olmak verimlilik yanılsamasıdır.

Hiç tatile gitmek isteyen var mı?

Yönetimle yapılan aptalca hatalar yüzünden daha birçok şirketim oldu. Bir veya iki mühendis ayrılırsa çarpmaz ve yanmazsınız, sadece bir süre daha çalışmanız gerekir. Sheesh, her çeyrekte birini kaybeden bir denizaşırı ekibi yönetiyorum. Görevleri hareket ettirmeye başlayın. Bugün.