Eski sistemleri iten yönetim nasıl ele alınır?

Şu anda ücretli bir staj yapıyorum ve son 5 yıl boyunca birden fazla geliştirici (farklı zamanlarda) tarafından geliştirilen eski bir sistemi korumakla görevlendirildim. Yönetim, "sistem yaşam desteği üzerinde" olduğunu kabul ediyor ve şu anda sistemi kullanan son kullanıcılardan oldukça düzenli bir hata raporu alıyorum.

Yönetim şimdi projeyi bir yıl daha uzatmak istiyor ve bu süreçte kullanıcı tabanını neredeyse üç katına çıkarıyor.

Stajyer olarak (veya herhangi bir giriş seviyesi pozisyonunda) nasıl "geri itebilirim"? Açık uçlu bir belgede de olsa endişelerimi belirten bir rapor zaten yazdım. Değişiklik önermek için protokol veya belge türü var mı? Öneride bulunacak mıyım yoksa eski sistemi desteklemeye devam etmeli miyim?

• Açıklığa kavuşturmak gerekirse, yazılım geliştirme şirketimin ana işi değildir. Bu nedenle, dahili protokoller yoktur. Ayrıca, projenin hiçbir resmi dokümanı ve gereklilik dokümanı da yoktur. Gelişme çok ad hoc.

Şu anda ücretli bir staj yapıyorum ve son 5 yıl boyunca birden fazla geliştirici (farklı zamanlarda) tarafından geliştirilen eski bir sistemi korumakla görevlendirildim. Yönetim, "sistem yaşam desteği üzerinde" olduğunu kabul ediyor ve şu anda sistemi kullanan son kullanıcılardan oldukça düzenli bir hata raporu alıyorum.

İnsanlar hala kullanıyorsa sistem kullanılmıyor ve iş faaliyetlerini destekliyor. Halen kullanılmakta olduğundan, işletme sadece atmakla kalmaz, sisteme ihtiyaç kalmayıncaya kadar desteklenmesi gerekir. Bu, iş hedeflerinde bir değişiklik olabilir veya yeni bir sistem geliştirildi, test edildi ve son kullanıcılara başarıyla dağıtıldı.

Gerçekten, 5 yıl o kadar uzun değil. Daha önce 10 yaşında olan kodla çalıştım. Hala kullanıcının ihtiyaçlarını karşılıyorsa, neden atmalısınız? Bu onu geliştirmek için harcanan çok parayı atıyor. Artan maliyetler nedeniyle sürdürülmesi olanaksız hale gelene veya gereksinimler büyük ölçüde değişene kadar, atmak için iş için bir neden yoktur.

Yönetim şimdi projeyi bir yıl daha uzatmak istiyor ve bu süreçte kullanıcı tabanını neredeyse üç katına çıkarıyor.

Yönetim bu sistemin "yaşam desteğinde" olduğunu söylüyorsa, neden sistemi daha fazla kullanmaya çalışıyorlar? Bakım faaliyetlerinin, değiştirilene kadar eski bir sistemde devam etmesi yaygındır, ancak bir sistem kullanım ömrü doluysa, genellikle daha fazla insana dağıtılmaz. Bakımın uzatılması bir şeydir, ancak sisteme güvenen kullanıcıları eklemek hep birlikte farklı bir durumdur.

Bana göre, aslında yaşamın sonu değil, bir bakım aşamasında ve sistem artık kullanıcıların ihtiyaçlarına hizmet edene kadar orada olmaya devam edecek.

Stajyer olarak (veya herhangi bir giriş seviyesi pozisyonunda) nasıl "geri itebilirim"? Açık uçlu bir belgede de olsa endişelerimi belirten bir rapor zaten yazdım. Değişiklik önermek için protokol veya belge türü var mı? Öneride bulunacak mıyım yoksa eski sistemi desteklemeye devam etmeli miyim?

Eski sistemi desteklemeye devam etmeniz gerekiyor. Daha sonra, yazılımın şirketinizin ana işi olmadığını söylüyorsunuz. Böyle bir ortamda yazılım ekiplerinin işi şirketin ana işini desteklemektir. Ancak, yazılım ekiplerinin de iş hedeflerini akıllarında tutmaları gerekir.

Bu arada, önerilerinizi zorlayıcı olmayan bir şekilde yakalayın. Sisteme entegre edilebilen veya yeni bir sistem oluşturulduğunda / oluşturulduğunda ve bunların artıları / eksileri ile kullanılabilecek diğer teknolojilere veya tekniklere dikkat edin. Bunu nasıl yapacağınız şirkete bağlıdır, ancak daha sonraki bazı noktaları göz önünde bulundurarak, belki bir wiki veya başka bir ortak çalışma sitesi oluşturmak yararlı olacaktır.

Yazılım dışı bir işte yazılım bir maliyettir ve yazılım ekipleri (özellikle yazılım projesi / program yöneticileri), son kullanıcıların ihtiyaçlarını desteklerken yazılım sistemlerini oluşturma ve bakım maliyetini olabildiğince azaltmak için çalışmalıdır. . Kullanıcıların ihtiyaçlarını karşılayabileceği kadarıyla (sizin de görebildiğiniz kadarıyla) yazılım ekibinin en iyi çıkarlarını karşılayan yazılımları atmak.

* Açıklığa kavuşturmak gerekirse, yazılım geliştirme şirketimin ana işi değildir. Bu nedenle, dahili protokoller yoktur. Ayrıca, projenin hiçbir resmi dokümanı, hiçbir gereksinim dokümanı yoktur. Gelişme çok ad hoc.

Benim için sorun bu. Belgeleme üretmeme, bir spesifikasyona göre geliştirmeme ve tutarlılık eksikliği, yazılım geliştirme maliyetini artırma eğilimindedir. Bunu düzeltmek için çalışmak benim en büyük önceliğim olurdu ve bunu bir kodlama standardı, sürüm kontrolü, kendi kendini belgeleyen kod ve tasarım belgeleri üretmek, hata takibi ve gereksinimler belirtimleri gibi şeyler üzerinde çalışarak yapardım.

Endişelerimi belirten bir rapor zaten yazdım

İyi. Bu stajyer olarak neler yapabileceğinizle ilgilidir. Gelecekte bu tür raporları yazarken referans olması için, sert gerçekleri duygusal önyargıları geçersiz kılan tarafsız, profesyonel bir tarzda sunmayı vurguluyorum. Raporu kimin okuyacağını bilmiyorsunuzdur, muhtemelen tanımladığınız sorunların bazılarına neden olan veya olmayanlar veya bu sorunlara yol açan kararlar almışlardır. Soğuk gerçekler dışında herhangi bir şey, bir hakaret veya suç gibi insanlar tarafından alınabilir ve onların sizi sevmemesine ve muhtemelen hiçbirini ciddiye almamasına neden olur.

Yönetim şimdi projeyi bir yıl daha uzatmak istiyor ve bu süreçte kullanıcı tabanını neredeyse üç katına çıkardı

Bunun gibi iş kararlarının alındığını unutmayın, çünkü onlar kendileri için mevcut olan kaynaklardan yararlanmaya çalışıyorlar. Yönetimin eski yazılımla ilgili sorunların farkında olduğundan ve muhtemelen kullanıcı şikayetlerinin farkında olduğundan eminim, ancak yeniden düzenleme veya yeniden yazma ile başa çıkmak için mevcut yazılım geliştirme kaynaklarına sahipler mi?

Çoğu zaman, özellikle yazılım şirketin ekmek ve tereyağı değilse ve yazılımdan kalite ve kullanıcı memnuniyeti, alt çizgiyi doğrudan etkilemez. Bu tür kararları vermek bazen yönetici olmanın neden berbat olduğudur, çünkü ne yaparsanız yapın genellikle kaybetme durumundasınız demektir.

son 5 yıl içinde birden fazla geliştirici (farklı zamanlarda) tarafından geliştirilen eski bir sistemin sürdürülmesi

Proje boyunca bu noktaya götüren hatalar yapıldı. Sağlam kullanıcı girişi veya gereksinimlerinin olmaması, değişen ürün ve gereksinimleri yönetmek için uygun ürün yönetimi ve değişiklik kontrolü eksikliği ve uygulanacak yeterli teknik kaynak eksikliği günümüzde var olan sorunlara neden olmuştur. Ama eskimiş doğru kelime olup olmadığını bilmiyorum. Altta yatan teknoloji, desteklenmeyen çerçeveler ve teknolojiler üzerine mi inşa edilmiş, yoksa sadece son teknoloji mi yoksa ideal teknolojiler mi?

Stajyer olarak (veya herhangi bir giriş seviyesi pozisyonunda) nasıl "geri itebilirim"?

En az güç pozisyonundasınız ve bu konuda geçicisiniz. Haklı olmanızın bir önemi yok, stajyerin beni "geri itmesini" beklemezdim. Onlardan öğrenmelerini, sorunları gördükleri gibi tartışmalarını ve emirleri takip etmelerini bekliyorum. Bu kadar. Bir emir verildikten sonra, yeteneklerinin en iyi şekilde yerine getirilmesini beklerim, çünkü tartışma zamanı o noktada sona erer.

Sen stajyersin. Hatta bir bütün olarak günlük iş zorunlulukları ile uzaktan au fait olup olmadığından çok şüphe ediyorum ve diğer insanların fark ettiği gibi, 5 yıllık bir kod tabanı gerçekten eski değil.

Eski sistemlerin değiştirilmesine ilişkin kararlar her zaman teknik olarak yönlendirilmez; değişen iş gereksinimleri tarafından yönlendirilirler. Bunlara giriş, sürdürmeyle ilgili zorluklar olabilir; ancak günün sonunda, pozisyonunuzun mutlaka mevcut ve gerekli tüm bilgilere sahip olduğunuz anlamına gelmediğini bilmeniz gerekir. Şimdiye kadarki en iyi hareketin ne olduğunu söylemek için gerekli bilgiye sahip olduğunuzu söyleyecek kadar ileri giderdim.

Size tavsiyem şudur: deneyimlerden bilgi alın ve bilginizin, işi günlük olarak yürütmek zorunda olan kişilerin bilgisine düştüğünü varsaymayı bırakın.

İşiniz, yeni ve parlak bir değişim önermek değil, sistemi çalışmaya devam ettirmektir.

Bana öyle geliyor ki, birçok genç programcı eski sistemlerin bakımının programlama çalışmalarının parlak yeni sistemler tasarlamaktan daha büyük bir parçası olduğunu fark etmiyor /

Geri itme. Yapmanız gereken tek şey endişelerinizi açık ve öz bir şekilde dile getirmektir. Mesele şu ki, gelecekte çalışacağınız çoğu işletmenin eski sistemleri olacaktır. Bu eski sistemlerin korunması gerekir, çünkü çoğu durumda değiştirilemeyecek kadar pahalıdır.

Birçok durumda, mevcut sistemi daha iyi bir sistemle değiştirmek için en iyi niyetiniz olabilir, ancak yeni ve farklı hatalar getirebilirsiniz ... sistemden ayrıldığınızda hızlı bir şekilde eski bir sisteme dönüşecek ve şirket daha önce olduğu yerde olmak. Artık amacına hizmet verene veya modern sistemlerle tamamen uyumlu olmayana kadar hiçbir şey kullanılmaz. Şirketim şu anda ASP.NET'e dönüştürdüğümüz 20 yaş üstü bir sisteme sahip. Sistem hala çalışıyor ancak eski teknoloji desteği azalıyor ve modern web tarayıcılarıyla çalışmasını sağlamak giderek daha fazla zaman alıyor.

Ne yapabilirsin:

İşleri Temiz Bırak

Bir şeyi koruduğunuzda, başladığınızdan daha temiz bırakın. düzeltmenizi yapın, ama aynı zamanda bir şeyleri temizleyin, böylece bir dahaki sefere bir değişiklik yapmak gerektiğinde anlaşılması daha kolaydır.

Doküman Oluşturma

Belgelerin eksikliği bir sorunsa, belgeler oluşturun. Sistemin belirli bir kısmı üzerinde çalışırken bunu belgelendirin.

Daha Az Ağrılı Olun

Belirttiğim gibi, endişelerinizi dile getirebilirsiniz, ancak elinizden gelenin en iyisini yapmak için sadece sistem üzerinde özenle çalışın ve daha sonra olanlar için daha iyi çalışın. Hataları düzgün şekilde düzeltin. Belge. Kod kokularını dağıtın. Daha iyisini yap. Ve bunları yaptığınızda amirlerinize bildirin. Onlara gelişim sürecini iyileştirmek için X, Y ve Z yaptığınızı söyleyin. Bu, güvenilirlik sağlar ve uzun vadede size ve şirketinize her şeyden daha fazla yardımcı olacaktır.

YAPMAYIN !!! Bu harika bir fırsat!

Öğrenecek bir stajsın! Bu proje gerçek bir dünya.

Sahip olduğunuz için çok şanslısınız. Kalifiye olmamanız endişeniz değildir. (Eğer yönetim bunu fark ettiğinde çok şey kazanmış olacaksınız)

Bu staj ile işiniz bittiğinde YETENEKLENECEKSİNİZ.

Not: Yedekleri dini olarak yapın, yaptığınız HER ŞEYİN geri alınabileceğinden emin olun. "Kolay düzeltmeler" olan Sorunlar ile başlayın Ancak kullanıcılar için büyük acı noktaları. Bebek adımları atın.

Sanırım, çok teorik anlamda - Legacy sistemi diye bir şey yok . Çok eski bir telefonum var (eski bir sistem) ve bu günlerde iyi android telefonlar (modern platformlar) var, ancak telefonum çalışıyor ve ihtiyacım olanı yapıyor. Bunu neden atmalıyım?

Bugün "miras" olarak adlandırdığınız tüm sistemler, bir gün son teknoloji ürünüdür. Sadece ihtiyacımız olan zaman. Ayrıca, oldukça büyük bir iş olduğunda, tüm şeyleri modern platformlarda tekrar yapmak, otomatik olarak hatasız (veya ağrısız) olacağı anlamına gelmez.

Yapmanız gerekenleri tavsiye ederim:

1. Öncelikle "eski sistem" i beğenmemenizi bırakın. Bu sizi çok üretken hale getirecektir.

2. Şimdi ne yaptığınızı ve ne düşündüğünüzü belgelemeye başlayın. Adım adım olsa da. Dokümantasyon yapmak için ihtiyacınız olduğunu fark ettiğinizden daha iyi bir zaman yoktur.

3. "Eski sistem" in ilerlemesini geri itmeye çalışmak yerine, sorunsuz bir şekilde çıkması için yolu tanımlamaya çalışın. Eski sistemlerle birlikte çalışabilirliği bozmadan yeni plat formlarında izole edilebilecek yeni gelişmelerin adım adım yapılabileceğini yönetmeye ikna edebileceğinizi görmeye çalışın. Yavaş yavaş (ve bu gerçekten yavaş olacak) işler geliştikçe, eski sistemi koruma ihtiyacı ortadan kalkacaktır. Herhangi bir eski sisteme güle güle demenin tek yolu budur.

Dipan.

Gerçek hiç kimse stajyere yapmak istedikleri işi vermez. En genç kişi olduğunuzda, en az heyecan verici işi alırsınız. Daha heyecan verici bir iş yapmak için size güvenip güvenemeyecekleri konusunda kuruluşa çok şey söyleyen kişisel olarak ne kadar iyi idare edersiniz.

Bu yüzden, hata düzeltmeleri yaparak teslim edebileceğinizi, bu dokümana dokunduğunuz kodun her bölümünü biraz daha iyi hale getirerek, bu sistem için oluşturmaya başlayarak birim testleri oluşturabileceğinizi yeniden düzenleyebileceğinizi göstermek için paha biçilmez bir fırsat ve bu sisteme sıkışmış olan bir sonraki fakir ruh için belgeler oluşturarak belgeleyebilmenizi sağlar. Ayrıca, kullanıcılarla etkili bir şekilde (rapor edilen hatalar hakkında daha fazla bilgi almak için) başa çıkabileceğinizi ve ihtiyaçlarını karşılayabileceğinizi gösterme fırsatı verir. Proje şimdi kaynak denetiminde değilse, oraya koyun ve hatalar bir hata izleyicide izlenmiyorsa, bir tane başlatın. Bu tür eylemler size profesyonelce nasıl çalışacağınızı bilecektir.

Ya da tam tersi bir yol izleyebilir ve sadece projenin ne kadar kötü olduğunu ve yerini almanın ne kadar havalı olacağını öğrenebilirsiniz. Bu durumda, stajdan sonra neredeyse bu şirkette bir iş teklifi almayacaksınız.

Muhtemelen bir yıl daha gitmenin maliyet açısından uygun olup olmadığını belirlemek için yeterli bilgiye sahip değilsiniz. Şirketi ve neden kullanıcı eklediklerini anlamak ilginç olurdu. Bazı büyüme devam ediyor gibi görünüyor ve sadece finansal olarak veya başka bir uygulama oluşturmak için belirli zaman kısıtlamaları altında bir adım geri alamayacaklar. Yeni bir uygulama oluşturmak nadiren en iyi seçimdir. Başlangıçta eski teknolojiye dayanmadıkça 5 yıl o kadar eski değil.