Çıkış maliyetini bir çözüm seçmeye dahil etmeli miyim

10

Şu anda iki uygulanabilir yazılım tasarımı / çözümü arasında seçim yapıyorum. Çözüm 1'in uygulanması kolaydır, ancak bazı verileri özel bir biçimde kilitler ve daha sonra değiştirilmesi zor olacaktır. Çözüm 2'nin uygulanması zordur, ancak daha sonra değiştirilmesi çok daha kolay olacaktır.

Bu konuda YAGNI'ye gitmeli miyim yoksa çıkış maliyetini karar verme sürecine dahil etmeli miyim? Veya farklı bir şekilde sorulduğunda, çıkış maliyeti TCO'nun bir parçası mı?

Çıkış maliyetlerinin alakalı olup olmadığını sormak için bununla müşteriye geri dönmeyi düşünüyorum, ancak topluluğun ilk önce ne düşündüğünü bilmek istiyorum.

PS Çıkış maliyeti doğru terim mi?

— dvdvorle
kaynak

İlk çözümün verileri kilitleyeceğini ve daha sonra değiştirilmesinin zor olacağını düşündüğünüzü ekleyebilir misiniz?

— Jaap

Özünde, 'standart' veya 'açık' olduğu düşünülen biçimler de dahil olmak üzere, tüm biçimler tescilli değil mi? Yagni muhtemelen 'tescilli' formatın uygulanması daha kolay, kullanımı kolay ve / veya değişim için defacto formatı ise geçerlidir.

— JustinC

Özelliklere girmeden; bir Excel sayfasını (müşteri tarafından tasarlanan) bir belge yönetim sistemine (çözüm 1) yerleştirmek, uygun tabloları ve GUI'leri oluşturmak ve talep üzerine Excel sayfasını oluşturmak (çözüm 2) olarak düşünün. Excel dışında.

— Kasım'da dvdvorle

Bununla birlikte, bu muhtemelen proje sponsoruna seçim ve karar sunma konusundaki endişenin bu yönünü belirtmeyi engellemez.

— JustinC

@JustinC iyi sonunda burada nakit hakkında konuşuyoruz. 'Tescilli' biçimini uzun vadede kullanmak daha mı ucuz? Proje sponsoru için bence bu çok önemli

— dvdvorle

4

Çıkış maliyeti toplam sahip olma maliyetinin bir parçasıdır ( T toplamı ifade eder ), ancak sistemin ne kadar süreceğini önceden bilmediğiniz sürece çivilemek zordur . Diğer bir deyişle, sistemin tam olarak bir yıl boyunca kullanılacağını ve bundan bir yıl sonra kullanımdan kaldırmanın 52.000 dolara mal olacağını biliyorsanız, işletim bütçesine onu kapsayacak şekilde haftada 1.000 dolar eklemekten oldukça emin olabilirsiniz.

Sistemin ömrünü bilmediğinizde bu model pencereden dışarı çıkar. Sistem, teorik olarak, sonsuza kadar kullanımda kalabilir, bu da onu kapatmak için harcanan para olmayacağı anlamına gelir. Şu anda hesaba kattığınız her şey bugünkü dolar olarak gerçekleşecek ve bu rakamlar, süreci kolaylaştıran (veya zorlaştıran) iş gücü oranlarındaki ve teknolojideki değişiklikler nedeniyle bundan beş yıl sonra anlamsız olabilir.

Müşterinize sistemden uzaklaşmak için neyin gerekli olduğu hakkında bir fikir vermek ve o zaman geldiğinde değiştirme ile ilgili kararları hesaba katmalarını sağlamak iyi olur.

(Ve şimdi, bu cevabı yazdıktan sonra, bunu konu dışı olarak kapatmak için oy kullanıyorum.)

— Blrfl
kaynak

Bu çözümün toplam sahip olma maliyetinin bir parçası olan çıkış maliyetinin alternatifi, bir sonraki çözümün toplam sahip olma maliyetinin bir parçası olması olacaktır. Şimdi böyle söylersem bunun garip geldiğini biliyorum, ancak deneyimime göre bir sistemin hizmetten çıkarılmasının maliyeti, mevcut sistemin proje planının / bütçesinin değil, bir sonraki sistemin proje planının / bütçesinin bir parçası haline getirildi. bu mantıklı mı?

— Kasım'da dvdvorle

1

Bana mantıklı geliyor ve bu da geldiğim sonuç. Her şey bitene ve bitene kadar gerçek bir toplam elde edemezsiniz.

— Blrfl

'Çıkış maliyetlerini' doğru bir şekilde tahmin etmenin zorluklarını kabul ediyorum, sanırım bugünün parasında olsa bile bir tane sağlamanın değeri var. "Bu zor ve zaman alıcı olurdu" ve "yarın yapılacaksa bunun 25000 ila 50000 ABD Doları arasında bir maliyeti olacağını" karşılaştırın.

— vaughandroid

@Blrfl, bu soruyu konu dışı kılan nedir?

— neontapir

1

@neontapir: Sorunun eti gerçekten proje yönetimi hakkında; bunun bir programla ilgili olması gerçekten programlama ile ilgili değildir. Aynı şey telefon anahtarlarına veya pizza fırınlarına da kolayca uygulanabilir.

— Blrfl

2

YAGNI yerinde büyük bir kuraldır, ancak bu durumda uygulanması gerektiğinden emin değilim. Gelecekteki maliyetleri tahmin edersiniz , gelecekteki gereksinim değişikliklerini biraz dikkate alması gereken bir etkinlik . Uygulamayı yazıyorsanız, farklı bir hikaye olurdu!

Maliyetlendirmeyi yapmanızı öneririm, ancak müşterinin bunu neden yaptığınızı anladığından emin olun. Eğer çok teknik değillerse, "Zaten başka bir şey kullanmayı düşünüyorsanız iyi bir çözüm olamaz!"

Maliyet tahminlerinizi yaparken / sunarken göz önünde bulundurmanız gereken daha ayrıntılı bazı yönler olabilir:

Gelecekte verilerin başka bir sisteme taşınması ihtimali nedir?
Çözüm sağlayıcının gelecekte veri taşımayı kolaylaştırmak / zorlaştırmak için kendi veri biçimini değiştirmesi olası mı? Eğer öyleyse, bu çözümünüzü etkiler mi?
Verileri daha sonra değiştirmek istemeseniz bile , farklı bir şekilde sunmak / erişmek isteyebileceğiniz bir şans var mı? Benim tecrübem bu oldukça yaygın!

— vaughandroid
kaynak

1

Excel dosyası durumu hakkındaki yorumunuzdan yola çıkarak şöyle bakıyorum:

geçerli biçimi değiştirmeme (çözüm 1)
biçimi ayrıştırmak ve farklı bir biçimde depolamak (muhtemelen / umarım daha uygun / geleceğe hazır) (çözüm 1 + ayrıştırma adımı, diğer bir deyişle çözüm 2)

YAGNI'nın bu ayrıştırma adımı için geçerli olduğuna inanıyorum; mevcut yapı hakkında bilgi sahibi olduğunuzdan emin olun, ancak ayrıştırmayı henüz uygulamayın.

Ayrıca, ayrıştırılmış veri yapısı düşündüğünüz kadar esnek olmayabilir; gereklilikler farklı tabloları güncellemek / genişletmek zorunda olduğunuz anlamına gelen farklı bilgileri / dosyaları depolamaya da gidebilir.

— Jaap
kaynak

Açık olmak gerekirse, şu anda bir çözüm yok (eğer yapacaksanız 0 çözümü). Şu anda tüm bilgileri kağıt dosyalarda saklıyorlar. Doküman yönetim sisteminde zaten "Excel" dosyasını kullanmışlarsa, bu cevabı gönülden kabul ederdim, ancak burada hala bir seçenek var.

— dvdvorle

Yoksa çözüm 1'in uygulanması ucuz olduğu için bunun uygun olmadığını mı düşünüyorsunuz?

— dvdvorle

Demek istediğim, eğer çözüm 2, çözüm 1'in bir geliştirmesi olarak düşünülebiliyorsa, ancak bu geliştirmenin artık kesinlikle gerekli olmadığına inanıyorsa, YAGNI geçerlidir.

— Jaap

Ne demek istediğini anlıyorum. Düşünülmesi gereken bir şey. Şimdi müşteriye gitmenin zamanı geldiğini düşünmeme rağmen, bunun bir geliştirme ve ne olmadığı hakkında ne düşündüğünü görün.

— dvdvorle

0

Gelecekte değişeceğinden% 95 emin değilseniz - Çözüm 1 - YAGNI =)

Elbette bu, müşterilerinize ve bu müşteri için bir şey programlama deneyiminize bağlıdır .

— MikroDel
kaynak

2

Yani çözümün değişme şansı ile ilgili herhangi bir maliyetin alakasız olduğunu mu söylüyorsunuz?

— dvdvorle

Demek istediğim bu bir çeşit his ... "YAGNI" nin ne anlama geldiğini biliyorsun - gerisi hissediyor =)

— MikroDel

0

Deneyimlerime göre, yeniden icat edilen tekerleklerin yeniden keşfedilmesi sandığınızdan daha uzun sürüyor ve dış tekerleklerin değiştirilmesi daha kolay oluyor. Her iki tekerlek türü de bir kez satın aldığınızda kararınızı verdiklerinden daha kötü görünme eğilimindedir.

Gerçekten # 1'in uygulanmasının kolay olduğunu düşünüyorsanız ve # 2'nin ne kadar süreceğini soruyorsanız, soruyu dinlerdim. Şimdi 1 numarayı uygulayın ve daha büyük tasarımı düşünün. Daha sonra yeniden icat etmek istiyorsanız bu size yardımcı olacaktır.

Tersine, # 1 artık düşündüğünüz kadar kolay görünmüyorsa # 2'ye atlayın.

— btilly
kaynak