Esnek olmayan programlayıcılarla başa çıkmak

Bazen bir projede uzun süre çalışan programcılar esnek değildir ve onlarla mantık yürütmek zorlaşır. Onları ikna etmeyi başarsak bile, önerilerimizi uygulama olasılığı düşük olabilir.

Örneğin, son zamanlarda derleme ve yayınlama sürecinin çok karmaşık olduğu ve gereksiz engelleri olan bir projeye katıldım.

Sadece hata yönetimi ve sürüm kontrol araçlarını entegre ederek (her ikisi de IBM-Rational araçlarıdır, böylece entegrasyon çok kolay bir kerelik bir çaba olabilir) bazı geliştirme yüklerinden (birkaç elektronik tabloyu doldurmak gibi) kurtulmamızı önerdim. Ayrıca, Maven & Ant (proje Java ve bazı COTS ürünlerini içerir) gibi araçlar kullanırsak, manuel hataları ve müdahaleyi azaltması gereken derleme ve yayın basitleştirilebilir.

Başkalarını ikna etmeyi başardım ve kavram kanıtı geliştirmek için çaba göstermeye hazırım. Ancak 'Kıdemli' geliştirici istekli değil, çünkü mevcut süreç onu daha değerli kılıyor.

Takımda sürtünme gelişmeden bu durumu nasıl ele alırız?

Siz yeni ekip üyesisiniz ve ekibin nasıl çalıştığının bazı temel yönlerini değiştirmek istiyorsunuz. İyi şanslar, geleceğinizde mutlu bir takım hissediyorum.

Tamam, bazı pratik öneriler:

Kendinizi takıma kanıtlayın. Bunu teknik ve güvenilirlik perspektifinden yapmanız gerekir. İnsanların sizi takip etmesini istiyorsanız, onlara bunu yapmaları için bir sebep vermelisiniz.

Metodolojinin tarihini kavrar. Neden var? O zaman hangi sorunu çözüyordu? Çözümünüzün ekip için gerçekten bir fayda olduğundan emin olun. Belki değişiklikleriniz daha iyidir, ancak ekibin sahip olduğu bir sorunu çözmeyebilirler.

Birlikte gösterimlerinizi tanıyın. Dirençlerinin nedenlerini öğrenin ve bu öğeler üzerinde çalışın.

Bir değişim aracısı olmak istiyorsanız, başarılı bir değişim aracısı olmayı öğrenin . Burada bulacağınızdan çok daha fazla bilgi sağlamak için düzinelerce kitap ve diğer kaynaklar.

Ve evet, size şans diliyorum. Ama lütfen, mutluluğunuz ve ekibinizin mutluluğu için, bu konuda akıllı olun. Doğru yolu oluşturmak için enerjiye yatırım yapmadan bir süreç değişikliği yapma arzunuz, faydadan çok daha fazla zarar verebilir.

Bahsettiğiniz pozisyondaydım. Yıllarca Java geliştiricisi olarak geçirdim ve sonunda hepsinin Smalltalk kullandığı bir işe girdim. İlk tepkim "OMG, bu antika teknolojiyi kullanıyorlar" ve Java çözümleriyle Smalltalk'a özgü sorunları çözmeye çalıştım. Sadece diğer geliştiricilere ne gibi bir baş ağrısı olmalı hayal edebiliyorum ve Java'dan tutkuyla nefret ediyorlardı.

Smalltalk dilinin asısını alıp beğenmeyi öğrendiğim birkaç ay boyunca iki üst düzey geliştirici tarafından bana danışmanlık yapılırken orta ölçekli bir proje bana verilinceye kadar değildi. Bu İşten ayrıldığımdan ve Java geliştirme çalışmalarına geri döndüğümden beri, bir projeyi alıp şirketin kullandığı her dili uygulayabildiğim için çok daha esnek hissediyorum. Bu insanları anlamalarını sağlayacak en önemli şey dilin ortamdan başka bir şey olmadığıdır. Kendime Lisp ve Erlang'ı öğretmek için de zaman ayırdım, ancak bu herkesle işe yaramayabilir.

Bir ekip oluşturma stratejisi olarak, sorun yaşadığınız kişilere Yedi Haftada Yedi Dil öneririm .

Sanırım bu insanlar daha esnek olmak için ne kadar zaman harcamak istiyorlar. Çoğu Üniversitedeki sorun (en azından gördüklerim), belirli bir dile karşı önyargılı olmaları ve öğrencilerinin de belirttiğiniz gibi 'kurumsallaşmış' olmalarıdır. Stratejinizin bir kısmının ekibinizde esneklik geliştirmek olduğunu düşünüyorum. Bu, Etki Alanına Dayalı Geliştirme ile tamamlanabilir .

(1) Bir alan modelleme (Basit bir alan) (2) İki farklı dil (yani Java ve Lisp) kullanarak uygulama

Yine, bu, yukarıdakileri yapmaya motive oldukları ve bunu başarmak için kendi zamanlarını yatırmaya istekli oldukları varsayımı altındadır.

Bu yardımcı olur umarım

Burada tamamen yanlış bir yolda olabilirim, ama bana göre aynı problemler daha geniş bir ölçekte yaygın ve insan muhafazakarlığıyla ilgili. İnsanlar, çok fazla sayıda nedenden ötürü, iyi bilinen davranış kalıplarını değiştirmeyi reddediyorlar.

Rus bir geliştirici olarak (ve dolayısıyla daha az rasyonel bir Batı pragmatizmi görüyorum), pratik akıl yürütmenin başkasının ayakkabılarında yürümeye çalışmaktan çok daha az ikna edici olduğunu düşünüyorum.

Başka bir deyişle, kıdemli programcının mevcut çalışma planıyla ilgili kendi konumuna değer verdiğinden bahsettiniz. Belki de onu yeni şeyler yapmanın yerini daha da değerli kılacağına ikna etmelisiniz ve bunu yapmanın birçok yolu var. Örneğin, fikrinizi gerçekten telaffuz etmesini ve bunun için kredi almasını sağlayabilir veya süreçte münhasıran kontrol edebileceği belirli bir nokta bulabilirsiniz.

Fikrinizin belirgin avantajları dışında esnek olmanın, burada büyünüz olabileceğine inanıyorum.

Başkalarını ikna etmeyi başardım ve kavram kanıtı geliştirmek için çaba göstermeye hazırım. Ancak 'Kıdemli' geliştirici istekli değil, çünkü mevcut süreç onu daha değerli kılıyor.

Üst düzey geliştiricinin karakterine (kötü hamle) sapma yapmak yerine, belki de neden hevessiz olduğunu anlamaya çalışmalısınız:

• Belki de fikirlerini satan insanlardan biri olduğunu düşünüyor. Belki onlara teslim edebileceğinden şüphe ediyor.

• Belki de problemleri abarttığınızı düşünüyor. (O kadar kötü olamazlar ...)

• Belki de teknik riskleri tam olarak anlamadığınızı düşünüyor.

• Belki şu anda yapılacak daha önemli şeyler olduğunu düşünüyor (biliyor).

• Belki de onu yanlış şekilde ovuyorsun.

Benim tavsiyem, kendinizi ona kanıtlamak olacaktır. Sanki size verilen projeleri yerine getirmek gibi. Yeteneğinize ve yargınıza daha fazla güvendiğinde, bu sorunu tekrar ziyaret edin.

Şu anda "süreç iyileştirme" çizgisini takip etmek istiyorsanız, tavsiyem bunu küçük adımlarla yavaşça yapmak olacaktır.

Akılda Ayı oradaki şüphesiz bir risk senin önerilen değişikliklerin grubun üretkenliğine kitlesel etkisi ve mevcut yazılım korumak için bile onların yeteneği. Böyle bir durumda, sorumlu kişinin üst yönetimden en fazla flak alması muhtemeldir.

Özellikle neyle ilgili kurumsallaştınız? Teknolojiler, kalıplar, uygulamalar?

Eğer uzun süredir organizasyonda / projede bulunmuşlarsa, üst düzey geliştiriciler olmaları ve bu çağrıları yapma sorumluluğuna / deneyimlerine sahip olmaları ve sadece 5 maymun deneyi gibi şartlanmak yerine projede deneyimleri olma şansları vardır .

Onları ikna etmenin çözümü konunun ne olduğuna bağlı olacaktır, çünkü eğer bir desen / teknoloji zaten seçilmişse, iyi bir neden olacaktır ve işi atmayı ve yeniden tanımayı vb. Haklı çıkarmak için daha iyi bir neden olması gerekecektir. Eğer öyleyse, çözüm, en iyi çözüme demokratik olarak karar vermek için bir toplantı düzenleyen bir mimar / kıdemli geliştirici içindir.

Ekibin gerçekten gereksiz yol blokları varsa, muhtemelen onları düzeltmelerine yardımcı olmanızdan çok mutlu olacaklar. Bununla birlikte, orada olmalarının çok iyi bir nedeni olabileceğini ve uzun bir süre herkese sattıktan sonra "ah, iyi, benim fantastik fikrim işe yaramıyor" demek zorunda kalırsanız aptal görüneceğinizi unutmayın.

Önce araştırın, sonra ileri gelin. Ayrıca, nasıl iyileştirildiğini nasıl göstereceğinizi GÖSTERMENİN el yıkamadan çok daha iyi olduğunu unutmayın.

"Esnek Olmayan Programcı" olan siz olduğunuzu söylemeye meyilliyim. Projede yenisiniz, ancak fikrinizin en iyisi olduğu ve projeye liderlik eden, daha uzun süren ve sistemi içeride ve dışarıda bilen adamın sadece rocker'ının dışında olduğu konusunda ısrar ediyorsunuz.

Oldukça tecrübeli ve oldukça saygılıyım ve sık sık mücadele eden projeleri bir kaplan ekibi üyesi olarak düzeltmek için görevlendirildim. O zaman bile, ekibin, projenin ve uygulamalarının nasıl, neden, dinamiklerini öğrenmek ve çılgınca girmemek ve onlara bunun ve bunun nasıl yanlış olduğunu söylemek için zaman ayırıyorum. Aslında, ne yaptıklarının yanlış olduğunu asla söylemiyorum çünkü bu istediğim yanıtı almıyor ve genellikle yaptıkları yanlış değil, sadece bazı ayarlamalar gerekiyor.

Her proje benzersizdir. Her takım benzersizdir. Çözümünüz sizin ve geliştiriciler için daha iyi olabilir, ancak lider, müşteri, işletme veya proje için daha iyi olmayabilir, ancak daha iyi bilmek için projeyle ilgili deneyiminiz olmadığından, bilemezsiniz. bunun cevabı.

İnsanlara istediğiniz şeyi yapmalarını sağlamanın en iyi yolu, her şeyin onların fikri olduğunu düşünmelerini sağlamaktır. Yani doğrudan önerilerde bulunmak yerine, seçenekleri sunun. Fikirleriniz alternatiflerden açıkça daha iyiyse, kıdemli geliştiriciye onları seçme ve kendisinin yapma şansı verin. Kredi alma konusunda endişelenme. Önemli olan insanlar neler olduğunu bilecek.