Teknik uzmanlık olmadan bir geliştirme projesi nasıl yönetilir

Tüm kariyerim ve kodla çalışmayı sevdiğim için uygulamalı bir geliştirici oldum. Belirli bir teknoloji konusunda uzmanlığı çok az olan veya hiç olmayan ama yine de belirli bir uygulamada ısrar eden takım liderine her zaman kızdım.

Şimdi kendimi ayna camının diğer tarafında buluyorum. Ben C # uygulanacak şişman bir istemci lider geliştirici, ancak benim uzmanlık Java web uygulamaları oluşturma. Tasarım dillerini ve OO paradigmalarını herhangi bir dilde kullanabileceğimi bilsem de, kodlama standartları, proje yaşam döngüsü araçları ve serbest bırakma / dağıtım prosedürleri söz konusu olduğunda kayboluyorum. Temelleri bir ya da iki ay içinde alabileceğime şüphe yok, ancak birinin sadece zamanla toplayabileceği belirli deneyimler var.

Ne yapmalıyım ve gelişirken nefret ettiğim proje lideri olmaktan nasıl kaçınırım?

Dürüst olmak gerekirse, bir teknolojiyle ilgili ne kadar deneyime sahip olduğunuz önemli değil, tavsiyem aynı: Yönetimle meşgulken onlarla yaşamak zorunda kalacaklar hakkında teknoloji kararlarını zorlamayın.

Kendine karşı dürüst ol. Bahse girerim ki önceki yöneticilerden nefret etmenizin nedeni, karar verecekleri bilgi tabanına sahip olmadıkları değil, kararları uyguladıkları ve sonuçlarla asla uğraşmadıkları için değil.

Bu, daha önce hiç .NET'e dokunmamış olmanız ya da takımdaki en uzman geliştirici olmanız için geçerlidir. İşiniz artık teknik kararlar vermek değil yönetmek.

Yönetmek, geliştiricilerinizin beceri düzeyine bağlı olarak, istediklerinde onlara tavsiyede bulunmak anlamına gelebilir. "Spring.NET'e baktın mı?" (orada talimat eksikliği dikkat) söylemek mükemmel bir şeydir. Ayrıca, "Google, dünyanın geri kalanının ne yaptığını görün, bu sorunla ilk karşılaşan biz değiliz."

Bazı açılardan, deneyimli bir Java geliştiricisi olarak, bunun için çoğundan daha iyi bir konumda olabilirsiniz. Çoğu Java çerçevesi ve teknolojisinin .NET'te benzer bir eşdeğeri vardır. Yani "İşte kullanmak için en iyi şey" demek zorunda değilsiniz, "Bunu Java'da kullandım, bir .NET eşdeğeri biliyor musunuz?"

Ayrıca ekip içinde çok fazla konuşmayı teşvik edin. Haftalık teknik tartışma toplantıları düzenleyin. İhtiyacınız olan tek şey sonunda bilgi; hangi kararları verdiklerini ve nedenini bilmeniz gerekir. Ekip için bu kararları vermenize gerek yok.

Teknoloji hakkında çok az şey bilen çok iyi menajerler / takım liderlerim vardı ve en kötü yöneticilerimden bazıları her şeyi bildiğini düşünenler oldu.

Lider olmak için, eğer makul derecede yetkin insanlara sahipseniz, asıl mesele, yetkinliklerini ve yargılarını yargılayabilmek ve her birine, "yaban ördeklerini" görevde ve "zar zor" "güvenli" ancak üretken faaliyetlerle "yetkin" kişiler. Herkesin aynı davulcuya yürüdüğünden emin olun.

En büyük zorluğunuz üst yönetimi uzak tutmaktır. Raporları, programları ve onay işaretlerini isteyecekler ve ne istediklerini ve bunları nasıl makul bir şekilde taklit edeceklerini anlamanız gerekiyor. (Eh, tam olarak "sahte" değil, zamanınızı veya ekibinizin zamanını yemeden onları tatmin eden belgeler üretin.)

C # kodlama becerileriniz için seçilmediniz ve başlangıçtan itibaren kod yazmayacaksanız, C #'ı bilmeniz veya bilmemeniz önemli değildir. Daha yüksek bir seviyede düşünmeye başlamanız gerekir:

• Ekibinizdeki her kişi masaya hangi becerileri getiriyor?
• Projenin başarısı için hangi bileşenler kritik öneme sahiptir?
• Gerçek koda ek olarak ne üretmeniz gerekiyor? (Testler? Dokümantasyon?)
• Henüz yapmadıysanız gereksinimleri nasıl toplayacaksınız?
• Siz ve ekibiniz tasarım sürecine nasıl yaklaşacaksınız?
• Bir kodlama standardına sahip olmanın önemli olduğunu biliyorsunuz , ancak tam olarak hangi standardı takip etmek istediklerini anlamak için ekibinize güvenebilirsiniz.
• Sorunları erken nasıl tespit edebilirsiniz?

Bunlardan bazıları proje yönetimi bölgesine geçebilir, ancak baş geliştirici olarak bu ve diğer konularda proje yöneticisi ile yakın bir şekilde çalışacaksınız.

Elbette, C # 'da olabildiğince çabuk çalışmayı öğrenin. Rolünüzün sözdizimini ve çerçeve ayrıntılarını geçmiş ve daha büyük resme bakmak olduğunu unutmayın.

Yaklaşın. Kendinize basit bir C # astarı alıp bir kod yazarak başlayın. Başka bir dilde gözü kapalı yapmayı bileceğiniz birkaç temel şeyi deneyin.

Programlama tarzı ve kurallarını okuyun. Bunu kısmen astarınızda bulmanız gerekir, ancak bilmediğiniz stil kurallarını uygulamak için StyleCop ve Resharper gibi ürünleri de kullanabilirsiniz. Bu, yazılımınızı derlerken sorunlardan kaçınmak için işleri yaygın olarak kabul edilen bir şekilde yapmak için çok hızlı bir şekilde eğitecektir.

Sadece kendiniz olun ve sahip olduğunuz tasarım bilgisini uygulayın. Dilden bağımsız olarak temel bilgiler aynıdır. Farklılıkların olacağı yerlerde, yapı bakımından dillerin nasıl farklılık göstereceği oldukça az olacaktır ve bir veya iki test uygulamasını bir araya getirdiğinizde bunların çoğu çok hızlı bir şekilde görünecektir.

Bilmediğiniz aşikar şeyler varsa, yakında olun. Ekibiniz dürüstlüğe sadece bir ipucu olmadan takılmaktan daha fazla saygı duyacaktır. İyi bilgilendirilmiş ve gerekçeli kararlar verin ve yanıtınızı dikkate almak için her zaman birkaç dakika ayırın. Hükmetmeye çalışmadan iddialı olmanız gerekecek ve bir alandaki bilgi eksikliğinizin takıma liderlik etme yeteneğinizin bir yansıması gibi görünmesine izin veremezsiniz. Liderlik, mentorluk anlamına gelir, ancak mentorluk, yeni bir şey öğrenmek için isteklilik gösteremeyeceğiniz anlamına gelmez.

Böyle düşünüyor ve gerçekten endişeleniyorsanız, bu tür bir proje lideri olma riskinden zaten kaçındınız. Doğru bilgi olmadan karar vermeye cesaret edebilecek tamamen farklı bir kişilik. İş arkadaşlarınızın size söylediklerine açık fikirli olun ve ekibinizde bir diyalog ve bilgi alışverişi kültürü oluşturun ve teşvik edin.

Görünüşe göre buradaki birkaç sorun var.

Yönlendirdiğiniz projede kullanılan teknoloji ve projenin gelişimini yöneten süreç.

Takım lideri veya lider bir geliştirici misiniz? Bir lider geliştirici de tasarım ve geliştirme çalışmalarının bir kısmını yapar. Dolayısıyla bunun tek yolu sadece aşağı inip yeni teknolojiyi öğrenmek .

Ekibe gerçekten liderlik yapıyorsanız , ekibe güvenmeniz ve projenin teknik yönünün çoğunu yönlendirmelerine izin vermeniz gerekir . Tabii ki, kavramsal olarak, o yönlendirmeyi doğru yönde tutabileceksiniz.

Projenin gelişimini yöneten süreçler çoğunlukla yerinde olmalıdır . Bu sadece onları okumak, anlamak ve yürütmek meselesidir.

Değilse, bazı geliştirme sürecini uygulamaya koymanıza yardımcı olacak bir danışman bulmak için patronunuzla görüşün. Bu oldukça önemli. Süreç yerinde değilse ve ad hoc ise oldukça hızlı bir şekilde başarısız olacaktır.

İyi şanslar!

Fırsat arada bir gelir .. Bunu yakala .. Ben söyleyebilirim, C # temellerini öğrenmeye çalışın. Çevrimiçi bazı öğretici alın, üzerinde çalışmayı deneyin. başlangıçta yeni konsepti öğrenmek zor olurdu, daha sonra ilk göreviniz bittiğinde ona biraz güveneceksiniz.

Olumlu düşünün, zor görevler almaya çalışın, kendi kodunuzu hata ayıklayın ve bu konuda uzmanlaşacağınızdan eminim.

Fırsatınızı kaybetmeyin.

Eğer iyi bir .Net geliştiricileri grubunuz varsa, takımda başlamak için belki de dokunmanız gereken çok fazla bilgi olduğunu düşünüyorum. Java ve .Net arasında zaten bildiğiniz şeylerin daha az doğrudan uygulayabileceği konusunda çok benzerlik vardır. Önemli olan, bu proje için neyin doğru olduğunu ve içerdiği riskleri bilmektir. Ekibinizle gerektiği sıklıkta iletişim kurun. Yazılım mühendisliği uygulaması bir proje boyunca gelişir, bu nedenle projenin çok erken saatlerinde "en iyi uygulama" sahibi olmak zor olabilir.

Yazılımla ilgili alanlardan olmayan çok yeşil bir ekip bana verildiğinde deneyiminizin tam tersini yaşadım. Ne yapmam gerektiğini öngörmek için tüm nedenlerim olsa da (işe alındım) bunun yerine bizi harekete geçirecek uygulamalar ve yazılım mühendisliği uygulamamızı geliştirmek için bol miktarda koçluk ve tartışma aradım. Ekipten yolda yığınları öğrendim ve bir yıldan fazla bir süre sonra işyerinde ilk projemizi teslim etmek için neredeyse oradayız!

Kodlama standartları, proje yaşam döngüsü araçları ve sürüm / dağıtım prosedürleri söz konusu olduğunda kayboluyorum.

Kullanacağınız teknolojiyi kullanan açık kaynaklı bir ürün bulun.

Mümkünse, sorunlu etki alanına bir şekilde benzer olanı bulun. Bu, aynı teknolojiye ve aktif güncellemelere sahip bir proje bulmak kadar önemli değil.

Çalışma kodlarını indirin. Oku onu.

Hangi araçları kullandıklarını anlayın. Onları kullan.

Açık kaynak projesinin nasıl oluşturulacağını ve serbest bırakılacağını öğrenin. Oluşturun ve bırakın.

Açık kaynak kodlu bir proje (çok sayıda katılımcı ile birlikte) en iyi uygulamaları gösterecektir.

Temelleri bir ya da iki ay içinde alabileceğime şüphe yok, ancak birinin sadece zamanla toplayabileceği belirli deneyimler var.

Doğru.

Açık kaynak topluluğundan bilgi edinin.