Ekibi yıllarca ürün yeniliğinden yoksun olduğunda, proje yönetimi yöntemlerini kullanmadığında ve kötü Yazılım Geliştirme uygulamalarını koruduğunda bir Dev olarak ne yapmalı? [kapalı]

Yıllardır değiştirilmeyen ve sonunda ürün ve ekip arızasına yol açacak olan mevcut bir yazılım geliştirme süreciyle nasıl başa çıkacağımı bilmekle ilgileniyorum. Evet, muhtemelen bunu çözmenin daha kolay yolu işleri değiştirmektir, ancak bu ekonomi ile yapılması gerekenden daha kolaydır. Ancak, belirli örnekleriniz varsa ve aynı durumda birden çok kez gördüyseniz veya olduysanız ve bu sorunları ele almak için en iyi çözümün şirketten ayrılmak olduğunu düşünüyorsanız, lütfen cevabınızı destekleyin. Mesele şu ki, özellikle konuyla ilgili birden fazla uzman sonuçlanacak en iyi yolun: A yolu olduğunu gösteriyorsa, bu sorunun gerçekten bir cevabı vardır.

Tonlarca geliştiricinin benzer durumlarda olduğunu ya da olduğunu biliyorum. Bu, şirketlerin pazarlarında 1 numara olmaktan, sonuncu hatta pazar dışı olmaya kadar gitmesinin ana nedenlerinden biridir. Umarım bu yazıdaki cevaplar benzer engellerle karşılaşan diğer geliştiricilere yardımcı olacaktır. Küçük veya büyük bir geliştirme ekibinde bu genellikle olur:

• Bazı geliştiriciler, akışla ilgilenmeye ve karar vermeyecek gibi görünüyor ve kodu çok fazla kodla bırakmayı tercih ettiği gibi kokuyor ve geliştirme süreci olduğu gibi,
• Diğerleri hiçbir değişiklikten ve istifa etmekten bıkar ve başka bir şirkete taşınır,
• Diğerleri konuşmaktan korkuyor ve sessiz kalmayı tercih ediyor,
• Bazen çok az sayıda geliştirici ya da sadece bir tanesi ürünün geliştirilmesi için konuşmaya çalışır ve ekibe, müşteriler, kullanıcılar ve ekip için en iyi kodlama uygulamalarını ve faydalarını takip etmenin ne kadar önemli olduğunu söyler. Bu tür geliştiriciler genellikle, şirket çok az yazılım şirketinin sunduğu avantajlar veya ürünün çok fazla potansiyele sahip olması gibi nedenlerle ekiple kalmaya karar verir.

Ekibimizdeki ürün, şirketin bir ürün şemsiyesi olduğu için gelirini aldığı kısmın sadece bir kısmıdır (bu şirket bir yazılım / donanım şirketi değildir; bu nedenle, en azından şimdilik, iş yaratan sürekli patent davası yok instabilite). Bu yıllar boyunca diğer geliştiricilerin deneyimlerinden ve deneyimlerimden öğrendiğim şey, bir geliştirme ekibini gerçekten tanımak için zaman, gün, hafta değil, birkaç ay sürmesi. Görüşme sürecinde ekip sizi işe almak istiyorsa veya size ihtiyaç duyuyorsa; her şeyi harika yapıyorlar ve size ne duymak istediğinizi söyleyebilirler. Bununla birlikte, o ekipte çalışmaya başladığınızda ve kodun içinde kazmaya ve tüm SDLC sürecine doğru ilerlemeye başladığınızda gerçek farklıdır. Bu, bir geliştirici olarak, girdiğiniz işin gerçekliğini görmeye başladığınız zamandır. Bu gerçeklik, bir şirketten diğerine geçmek istemeyi zorlaştırır, çünkü taşındığınız şirketin daha iyi veya daha kötü olup olmayacağını bilmek zordur. Evet, Glassdoor incelemelerini vb. Okuyabilirsiniz, ancak bu çevrimiçi incelemelerin kaç tanesi HR'den değil gerçek mi?

Başından beri yöneticinin her zaman değişmeye direndiğini ve önceki geliştiricilerin yıllardır aynı şeyi yaptığını düşünerek aşağıda özetlenen sorunları çözmenin en iyi yolu ne olurdu?

• Yıllarca ürün eksikliği: Ürün çok fazla potansiyele sahiptir ve şirkete iyi gelir getirir, ancak ürün 20 yıl önce yapılmış gibi görünüyor. Bazı kullanıcılar, ürünün kullanıcı dostu veya sezgisel olmadığından şikayet ediyorlar ve diğerleri, Gmail gibi uygulamalarda kullanılan ve benzer özelliklere sahip olmadığı için ürünü kullanırken hayal kırıklığına uğradığını belirtti. Buradaki ana sorun, bir geliştirici olarak ürün üzerinde değişiklik yapmaya çalıştığınızda ve ürünün ana öğelerini sadece birkaç piksel uzağa taşımaya (daha kullanıcı dostu veya sezgisel hale getirmek için), yönetici paniklerine ve olduğu yere geri koymak. Kullanıcılar için üretkenliğe fayda sağlayacak bir özellik eklemeye çalışırsanız, yönetici sizden "kullanıcılar işlemi olduğu gibi yapmaya alışkın vb." Sanırım değişime, gelişime ve yeniliğe karşı direnişe dikkat çekiyorsunuz. Şirketin alanında birkaç rakibi var (birkaçının ürünleri çok daha rekabetçi), ancak bir şekilde şirket yıllardır mevcut müşterileri korudu.

• Proje yönetimi koordinasyonu eksikliği: Bunun bir sonucu olarak, bazı projeler geç teslim edilir, hatalar ve bazı müşteriler şikayet eder (müşteriler hataları bildirir) veya proje teslim etmeden önce bütçe çok hızlı kullanılır vb. birkaç proje koordinasyon ipucu ve fikirler şimdi yapılacak proje ve görevlerin ilerlemesini izlemek için düzenli olarak kullanılmaktadır.

• Kötü yazılım Geliştirme Uygulamaları: Kod kokusu, tüm dosyalar olmasa da çoğu dosyada görülür, belge yok, kod fazlalığı, ön uç katmanı ve arka uç aynı dosyada karışık, eski geliştirme araçları, gerçek bir test ortamı veya test araçları yok (sadece kopyala yapıştır dosyaları geliştirme ortamından üretime geçirin ve sonra işlerin iyi göründüğünü ve serbest bırakıldığını manuel olarak test edin). Ekip tarafından bilinmeyen yerlerde geliştirme ve test için kullandığım geliştirme araçlarının çoğu, ekip kod geliştirme ve kaynak kontrolü için yalnızca 2 IDE kullandığından yalnızca geliştirme ortamı için kullanılabilir. Diğer geliştiriciler, mevcut sorunları iyileştirmek için en yeni çerçeveleri kullanmaya çalıştılar, ancak yönetici, "ayrılırsanız, o kodu kim koruyacak?", Bu şekilde bırakalım "Bu geliştiricilerin bazıları zaten ayrıldı ve başka şirketlere taşındı.

Özetle, benzer şirketlerin diğer şirketlerdeki birçok geliştiriciye de geldiğinden eminim, ancak farklı koşullar nedeniyle, bir geliştirici (iş kolaylığı, iş esnekliği, şirket faydaları veya çünkü daha iyi bir fırsat gelmedi). Bildiğim mükemmel bir şirket yok, ancak bir geliştirici olarak şeyleri olumlu tutmak ve nihayetinde ürünün iyileştirilmesi ve yazılım geliştirme sürecinin iyileştirilmesi için değişikliği teşvik etmek için tüm bu konulara nasıl davranır ve yaklaşırsınız? yıllık geliştirme tecrübesi veya sadece birkaç)? Bu yazının uzun olduğunu biliyorum, ancak daha yararlı geri bildirim alma şansını artırmak için ekstra ayrıntılar vermeyi tercih ettim.

Tüm geri bildirimleriniz ve zamanınız için çok teşekkürler

Martin Fowler'in teklifi şu anlama gelir: "Kuruluşunuzu veya kuruluşunuzu değiştirebilirsiniz." Görünüşe göre kuruluşunuzu değiştirmek yerine (farklı bir kuruluş için çalışın) kuruluşunuzu değiştirmeye (daha iyi hale getirmeye) karar verdiğiniz göz önüne alındığında, işte birkaç öneri.

İlk olarak, hareket tarzınızın çoğu, işyerindeki güç yapıları ve politika hakkındaki ayrıntılara bağlıdır. Bir yazılım geliştirme yöneticisi veya birkaç tane var mı? Eğer birkaç tane varsa, değişimden kaçınmayanlar var mı? Kaç yazılım geliştiricisi var? Geliştiriciler değişmekle ilgileniyor mu? Öyleyse, yönetim onayı olmadan bile yapabileceğiniz bazı değişiklikler vardır. (Fowler'ın Refactoring'de önerdiği gibi , yönetime bile söylemeniz gerekmeyebilir. Muhtemelen mümkün olan en iyi yazılımı geliştirmek için işe alındınız, bu yüzden bunu yapmanın daha iyi bir yolu varsa, sadece yapın.)

İkinci olarak, yönetimin yaptıklarının iyi nedenleri olabileceğini unutmayın. Bir yazılım geliştiricisisiniz; işiniz iyi yazılım geliştirmek ve bunu yapmak için iyi teknikler bilmek. Yönetimin görevi, daha büyük resim konularını ve düşüncelerinizin ötesinde olabilecek iş hususlarını anlamaktır. Haklı olsanız ve iş düşüncelerinin ne olduğu konusunda yanlış olsalar bile (inovasyon eksikliği, geç teslimat, müşteri şikayetleri vb. İle ilgili endişeleriniz), yönetimin nereden geldiğini anlamak, terimleriyle iletişim kurmanıza, hafifletmenize yardımcı olacaktır. onların endişeleri vb.

Üçüncüsü (ve ilgili), işletme dilini konuşabildiğinizden emin olun. Bir işletme (haklı olarak) iyi yazılım geliştirme uygulamalarıyla doğrudan ilgili değildir; bir işletme müşterilerin ihtiyaçlarına hizmet etmek ve kar etmekle ilgilenir. (Ve birçok işletme, kâr elde etmek için mümkün olan minimum ihtiyaçları karşılayacaktır.) Kötü yazılım geliştirme uygulamalarının ve yenilik eksikliğinin şirketin kârına veya uzun vadesine nasıl zarar vereceğini açıklayabilirseniz, değişikliği teşvik etmede daha etkili olacaksınız. sağlık.

Dördüncüsü, bir şirket kültürünü rütbe ve dosya çalışanı olarak değiştirmek son derece zordur. James Shore (çevik bir danışman ve yazar) bunu yapmaya yönelik çabalarını açıklayan bir Değişim Günlüğü yazdı . Her şeyi okumanızı şiddetle tavsiye ederim. Alakalı birkaç nokta:

• Her şeyi aynı anda değiştirmeye çalışmayın. En büyük ağrı noktalarını bulun ve oradan başlayın. Değişikliklerinizin bu acı noktalarına nasıl hitap ettiğini görmelerine yardımcı olarak herkesi gemiye alın.
• Başkalarının bakış açılarını anlayın. Shore, bir yazılım geliştirme perspektifinden ittiği değişikliklerin proje yöneticisi tarafından nasıl karşılandığını anlatıyor çünkü (Shore) değişikliklerin proje yöneticisini nasıl etkileyeceğini düşünemedi.
• Sonunda, değişikliklerin çoğunu kendiniz sorsanız bile, yukarıdan biraz desteğe ihtiyacınız olacak. Shore şampiyonundan bahsediyor ("birlikte çalıştığım ve benden daha fazla nüfuzu olan ve genelde yaptığım aynı çizgileri düşünen biri").

Açık olan kısa cevap şirketten ayrılmaktır. Diğerleri zaten ayrıldı ve yöneticiniz ilerleme için aktif bir engel. Bu pozisyonda kalırsanız yavaşça çürüyorsunuz (hem moral hem de yeteneklerde). Yeni bir iş bulmak her zaman kolay değildir, ancak bu durumda gereklidir.

Şirketten ayrılmamayı seçmeniz durumunda (sorunuzun ilk satırı bunu verdi):

Yöneticinizin patronu var mı? Öyleyse, bu patron ürünü nasıl görüyor? Müdürün kafasının üzerinden geçip patronuna yaklaşabilir misin? Onu teknik detaylarla tutmayın, sadece şirket içinde büyümeye olan ilgiyi ve coşkuyu ifade edin. Sonuç olarak ölçülebilir şekilde etkileyecek iyileştirmeler için somut fikirler sunun. Engeli altından terfi ettirebilirsiniz.

Yine de dikkatli olun - bazı gıcırtılı tekerlekler yağlanırken, diğerleri değiştirilir. Yöneticinizin sizi kesinlikle sevmemesine neden olacaksınız. O olacak bundan haberi ve o olacak patronuna hakkında kaba şeyler söylüyorlar. Dikkatli davranın, ancak unutmayın - risk yok, ödül yok.

Olabilecek en kötü şey, yine de yapmanız gereken yeni bir iş arayacağınızdır.

Nakit inekler hakkında bilgi edinmenin zamanı geldi. Git buradan ve buradan . Ve Growth Share Matrisine bir göz atın . GSM, nakit ineğin neden iyi bir durumda olduğu hakkında bazı ek bilgiler sağlar.

Investopedia (ikinci bağlantı) muhtemelen bu durumda en iyi alıntıya sahiptir.

1. Bir nakit inek az yatırım sermayesi gerektirir ve yıllık olarak şirket içindeki diğer bölümlere tahsis edilebilecek pozitif nakit akışları sağlar. Bu nakit üreticileri, paralarını piyasadaki hisseleri geri almak veya hissedarlara temettü ödemek için de kullanabilirler.

Belirttiğiniz gibi, bir nakit inek projesinde olmanın bazı olumsuz yönleri var.

• Kararlı
• Mütevazı derecede yeni bir gelişme garanti edilmektedir
• Mücadelede her zaman hata düzeltme işi vardır.

Ve belirttiğiniz gibi, bu projelerin bazı dezavantajları var.

• Kararlı ve kod tabanı fazla dönmüyor
• Yeni teknolojiler genellikle göz ardı edilir (cıvatalamak için çok pahalı)
• Ve işler ... bayat.

Bir zamanlar ortaya koyduğunuz şeyle benzer şikayetlerimin olduğu bir proje üzerinde çalıştım. Kod tabanı hakkındaki endişelerimi o zaman patronumla paylaştığımı hatırlıyorum. İçgörüsü özellikle aydınlatıcı değildi, bu yüzden paylaşmayacağım. Ama projeyi çıkardım ve gerçeği söylemek gerekirse, gördüğüm daha iyi projelerden biriydi. Hayır, gösterişli değildi. Evet, teslim tarihlerini kaçırdık. Evet, oradan birkaç ölüm yürüyüşü düzenledim. Hayır, kod teknolojisi o kadar yenilikçi değildi, ancak bazı şaşırtıcı çözümler ürettik.

Sorun bendim. Hayatta kalabilmek için bir kod tabanının gerçekten neye ihtiyacı olduğunu anlamak için yeterli perspektifim yoktu. Yeniliğin gerçekte nerede gerçekleştiğini görmek için deneyimim yoktu. Bu nakit inek projesi için uygun fon seviyesinin ne olduğunu belirleyen piyasa temellerini anlamadım.

Bunu, işletmenin nasıl çalıştığını ve bir ürünü işletmenin ihtiyaçlarına uyarlama becerilerinizi nasıl geliştirebileceğinizi daha iyi anlamak için bir öğrenme fırsatı olarak görmenizi öneririm. İş gösterişli olmasa da, öğrenme potansiyeli yüksektir ve bu beceriler daha sonra kariyerinizde iyi duracaktır. Kurumsal düzeyde gelişimin büyük bir kısmı, az önce bahsettiğiniz tüm kısıtlamalar etrafında dönmektedir. Kod kokuyor; daha önce kaçmış olan son teslim tarihlerini içerecek şekilde bazı şeyler yerine yerleştirilmişti; birçok geliştirici değişime karşı dayanıklıdır.

Bir noktada, yine de projeden devam edeceksiniz. Yanınıza alabileceğiniz dersler gerçek kariyer yapma dersleri olabilir.

Yöneticiniz muhtemelen değişime karşı dirençlidir çünkü (iş) değerinin değişen uygulamalar olmadığını görür. İşletme, gerçek bir sorun görmez, çünkü geliştirme ekibinden istenen her şey yapılır ve müşteri şikayetleri, daha iyi bir sonuç elde etmek için ilgilenen ve / veya bir şeyler yapabilen kişilere bunu yapmaz. Bu ya da iş, mevcut durumu kaçınılmaz olarak kabul etmeye başladı.

Geliştirme uygulamalarını değiştirecekseniz, mevcut durumun kaçınılmaz olmadığını göstermelisiniz. Ve işitilmenin tek yolu, mevcut durumun ürünün maliyetini nasıl artırdığını gösteren bir iş vakası oluşturmak ve başka bir durum göz önüne alındığında gelir potansiyelini geri almaktır.

Bu iş vakasını oluşturmak için, bu yazılım parçasının ürün yöneticisiyle konuşmanız gerekir . Ürün yöneticisi, temsil ettikleri iş değerine göre geliştirilecek öğelerin önceliğine karar veren kişidir. Ürün yöneticisi, daha hızlı yazılım geliştirmenin avantajını ve iş değerini görebilen kişidir (olmalıdır) . (Ve umarım geliştirme ekibinin sorumlusu ile aynı değildir.)

İş vakası, iş geliri üzerindeki etkilerin neler olduğunu ele almalıdır:

• Uygulanmadığı takdirde daha fazla müşteri yaratacak veya daha fazla müşteriyi elinde tutacak (henüz) uygulanmayan özellikler.
• Müşteri memnuniyetsizliği yaratan ve müşterilerde yıpranmaya yol açan, yetersiz uygulanan özellikler.

İş vakası ayrıca, mevcut geliştirme uygulamalarının çok ihtiyaç duyulan özellikleri geliştirmenin hızını ve maliyetini nasıl etkilediğini göstermelidir:

• En basit değişiklikleri bile yapmak ne kadar zaman alır.
• Hem yeni özellikte hem de diğer özelliklerde teminat hasarında yeni özellikler geliştirmenin sonucu olarak kaç hata getirildi.
• Yeni özelliklerin uygulanması için harcanamayan bu hataları düzeltmek için ne kadar zaman harcanır.
• Bu hatalar nedeniyle kaç tane destek çağrısı üretilir ve bu çağrılar için ne kadar destek personeli harcamak gerekir.

Ve elbette daha iyi kalkınma uygulamalarının benimsenmesinin bu rakamları nasıl etkileyeceğini göstermesi gerekiyor.

Muhtemelen yazılımın (büyük) bölümlerinin (büyük) yeniden yazılmasına ihtiyaç duyuyorsunuz. Yapmasanız bile, Akıl Sağlığınızı Kaybetmeden Yere Kadar Yeniden Yazmak Nasıl Sağlanabilir ?

Son not: ürün yöneticisi tüm bunlarla ilgilenmiyorsa, kaybolursunuz: zıplama gemisi.

Bunun doğrudan bir çözümü olmayan, gerçekten zor bir sorun olduğunu düşünüyorum. İşte yapmayı deneyebileceğiniz bazı fikirler:

Değişim Korkusu Değişen şeyler konusunda daha iyi yönetim korkusunun neden değiştiğini anlıyorum. İnsanlar şeylere belirli bir şekilde alışırlar ve değiştirirseniz kullanıcılar isyan eder (belki). Değişim korkutucu bir şeydir ve genellikle yapılmadan önce çok fazla düşünce ve çalışma gerektirir. İhtiyacınız olan şey bunun daha iyi olduğunu ve kullanıcıların bunu istediğini gösteren verilerdir. Gmail'den bahsetmişken, kullanıcıların yeni bir deneme yapabilmesi için yeni özellikleri etkinleştirebileceğiniz / devre dışı bırakabileceğiniz "Google Labs" gibi bir şey yapabilirsiniz. Ardından, değişikliklerinizin yedeklenmesine yardımcı olmak için bazı veri toplama işlemlerini gerçekleştirin.

Yazılım Geliştirme Sürecinin Değiştirilmesi Yine, insanların daha iyi bir yol olduğunu söylediğiniz için değişmek zor değildir. Bu senaryoda en iyi tavsiyemin örnek olması gerektiğini düşünüyorum. Yapılmasını istediğiniz şeyleri yapın ve insanlara ne kadar iyi olduğunu gösterin. Ayrıca, bu anahtardır, düşüncelerinizi paylaşan diğerlerini bulmanız gerekir. Teknede birkaç kişi bulabilirseniz, bu da amacınıza büyük ölçüde yardımcı olacaktır. Bazı sonuçları gösterdikten sonra, bu değişiklikleri daha geniş hale getirme konusunda yönetime yaklaşabilirsiniz. Yukarıdan aşağıya ve bir taban kök çabasının değişiklik yapmaya gerçekten yardımcı olduğunu düşünüyorum.

Ayrıca araçlar tarafında şirketler, bunları yükseltmek / değiştirmekten korkuyor çünkü paraya mal oluyorlar ve yeni araçların sonuçları her zaman ölçülebilir değil. Buradaki tavsiyem kendi aletlerinizi yapmak. Kendinizinkini yaparsanız kendinize zaman kazandıracak ve daha iyi iş yapacaksınız. İnşallah insanlar fark etmeye başlar ve sonra da onları kullanmak ister.

Değişen yönetim Bu zordur ve sonuç üreten ve görüşlerine değer veren biri olmaktan nasıl emin değilim. Fikriniz değerlendirildikten sonra insanlar dinlemeye başlayabilir ya da olmayabilir.

Son olarak, değişimin zor olduğunu ve zaman aldığını unutmayın. Orada durun ve küçük başlayın ve birikin.