Müşterilerden gelen “yalnızca birkaç alan daha ekleyebilir misiniz” türden talepler nasıl ele alınır?

Çok yaygın olarak, yalnızca bir müşterinin istediği alanlar için özellik taleplerimiz vardır. Bu, en iyi ihtimalle uygulamanın kodunu keser. Genellikle, alanları ekledikten birkaç ay sonra veritabanlarına baktığımızda, aslında fazladan alanları kullanmadıklarını görebiliriz. Ayrıca, oldukça eski bir uygulamadır, bu nedenle tek bir alan eklemek için birden fazla kod değişikliği, raporların değiştirilmesi ve alanın görülmesi gerekmeyen diğer müşterileri etkilemediğinden emin olunması gerekir.

• Bir müşterinin bu özellik isteklerine gerçekten ihtiyaç duyduğundan nasıl emin olabiliriz?

• Kibarca "buna gerçekten ihtiyacınız yok" nasıl söyleyebiliriz?

Şu anda belirli özellik talepleri için ücret almaya başlıyoruz. (Önceden, özellik istekleri genellikle ücretsizdi) Yapabileceğimiz başka bir şey var mı?

Ek özellikler için ödeme yapıyorlar mı? Eğer öyleyse, onları kullanıp kullanmadıkları gerçekten sizin işiniz değildir. Onlara ne ödediklerini verin. Bununla birlikte, durum böyle değilse, ek gelir olmadan özellik eklemeye devam etmek isteyip istemediklerine karar vermek liderliğinize bağlıdır.

Benzer bir durumumuz var. Bizim başa çıkma şeklimiz, bize "buna ihtiyacınız yok" demenin özgürlüğünü veren güvene dayalı bir ilişki kurmaktır. Zaman, sabır ve çok konuşmaya ve öğle yemeği ve diğer sıkıcı görevlere hazır olmalısınız. Bu sıkıcı toplantılar, gerçekten önemli özellikler yaratmaya odaklanabileceğiniz uzun vadede kendileri için ödeme yapacak.

Konuşmak, sordukları şeyin gerçekten önemli olup olmadığını da görmenizi sağlayacaktır.

"Gerçekten ihtiyacın var mı?" müşterilerle tartışma. Şahsen, "Bu şirketinizi nasıl daha fazla para kazanacak?" Diye sormak istiyorum. ama işin aslı şu ki, bazı yöneticiler, bir nedenden ötürü onu izlemek istiyorlar ve yollarını bulmaya çalışıyorlar. Bunu yapmak istemiyorsanız, isteğinizi caydırmak için hayır deyin veya bu kadar büyük miktarda para talep edin.

Uygulamanızın daha fazla sayıda müşteri alanını ele almasını kolaylaştıracak yollar düşünmeye başlayın.

1. Raporlardaki ve formlardaki etiketlerin müşteri tarafından mevcut alanları kullanması için ayarlanmasına izin verin.
2. Varolan veya ek özel alan tablolarına genel alanlar (String12) ekleyin.
3. Tüm bunların veri girişi tarafından işlendiği ve tablolarda yeni sütunlar oluşturmak zorunda kalmayacağı kullanıcı tanımlı bir alan sistemine sahip olun (buna yardım denildiğini hatırlayamıyorum.).

Mevcut müşterilerin sisteminizi fazlasıyla büyüttüğünü görebilirsiniz. Sektör değişiyor olabilir, bu nedenle yeni gereksinimler ortaya çıkıyor.

Üzgünüz, ancak müşterilerinize sadece teknik nedenlerle istedikleri şeyi kar elde edemiyorsanız, bu hıza uymanız gerekir. Yeni bir gelenin pazarınıza daha fazla alanla girmesi zor olmayacaktır, bu yüzden bunun olmasına izin vermeyin.

Pencerenin diğer tarafından bir anlığına baktığımda, son işimde, son kullanıcı tarafından herhangi bir varlığa / tabloya "özel" sütunların eklenmesine izin veren bir ERP sistemine maruz kaldım. Kısa etkileşimlerimden, sütunları dinamik olarak bire bir eşleme ile ikinci bir tabloya ekliyorlardı. Örneğin:

Statik sütunlu WIDGET tablosu:

• WIDGET_ID
• EKLENTİ ADI
• WIDGET_COST
• vb.

Kullanıcı tanımlı sütunlarla WIDGETCUSTOM tablosu:

• WIDGET_ID
• WIDGET_WEIGHT
• DID_BOB_WORK_ON_WIDGET
• vb.

WIDGET_ID sütunu bunları birbirine bağlayabilir. Bir widget'ı düzenlerken fazladan alanlarınızı otomatik olarak gösterdi ve bunları dinamik raporlara dahil edebilir, hatta aratabilirsiniz. Oldukça etkiliydi çünkü veritabanı hala onları takip edebilir ve gerekirse bu sütunları dizine ekleyebilir.

Programlama açısından bakıldığında, bunun nasıl aklı başında tutacağını görüyorum. Her müşterinin kendi özel sütunları olabilir, ancak bu özel sütunlar temel mantığınıza müdahale etmez.

Özellik "istekleri" sadece, istekleri vardır. Eğer talepte bulunuyorlarsa, kod tabanını bununla "karıştırmanın" ne kadar değerli olduğuna karar vermelisiniz. Endemik bir sorun haline gelirse, üzerine bastırabilirsiniz, ancak sorduğunuz şeyi veya ona yakın bir şeyi ödemeye istekli iseler ve burada ve orada sadece birkaç özellik varsa, parayla git dedim.

Daha da ileri gitmek için, bu ürününüzle ilgili sürekli bir sorunsa ve birden fazla müşteri bu tür özelleştirmeleri arıyorsa, belki de uygulamanızın bu bölümlerini yeniden düşünmenin ve müşterilerin bunu yapmaya yetkilendirilecek şekilde esnek hale getirmenin zamanı gelmiştir. ister ad-hoc raporlama, ister esnek veri toplama vb. olsun, bu sıkıntıları bir satış noktasına dönüştürmeye çalışın. "Stok veri modelimiz sizin için yeterince iyi değil mi? Özelleştirme seçeneklerimize göz atın! Bunu kendiniz yapabilirsiniz!"

Bahsedilen özellikte ne yapacağınızı tam olarak belirtmeli ve bunu oluşturmak için tahmini bir zaman uygulamalısınız. Müşteri, ek alanların iyi olmasını istiyorsa, bunun için faturalandırın. Müşterilerime, özelliği oluşturduktan sonra özellikler eklemek istiyorsanız, bu iyi, ancak bazı durumlarda bunları çalıştırmak için biraz daha pahalıya mal olacağını söylüyorum.

Kullanıp kullanmadıklarını neden önemsediğinizi anlamakta zorlanıyorum. Çok basit, istediklerini inşa edersiniz ve bunun için ödeme alırsınız.

Kod tabanı dağınıklığı? Yeni özellikte çalışırken kodunuzu yeniden düzenlemeniz gerekiyorsa, kodunu ücretlendirin.

Eklemeyi düşündüğünüz, "yalnızca birkaç ekstra alan" eklemek de dahil olmak üzere çeşitli özelliklerin bir listesini oluşturun. Listeyi müşterilerinize gösterin ve onlardan önce hangilerini istediklerini bildirin. Kaynaklarınızın sınırlı olduğunu ve hepsini aynı anda yapamayacağınızı açıklayın. Başvurunuzla hangi yöne gitmek istediğinize karar vermek için geri bildirimi kullanın.

Bir müşteri, fazladan birkaç alanın gerçekten bu kadar önemli olduğu konusunda ısrar ederse ve yine de bunları eklememeye karar verirseniz, umarım müşteri bunun yerine uyguladığınız özelliklerin faydasını görebilir.

Bir çeşit çekme sisteminden faydalanabileceğiniz anlaşılıyor. Daha sonra hangi özelliğin uygulanacağını kullanıcının seçmesine izin verin, ancak herhangi bir zamanda geliştirilmekte olan sayıyı sınırlayın. Kanban tahtası bunun için müthiş. Kullanıcıya önceliklendirme sürecinin sahipliğini verebilir (sizin için daha az sorumluluk ve stres). Güven bana, eğer kullanıcı hangi özelliğin bir sonraki aşamada geliştirileceğine karar vermek zorunda kalırsa, diğer isteklerin bir kenara bırakılacağını bilerek, sahip olması gereken şeylere gerçekten karar vermek için çok daha fazla yatırım yapacaklar.

Sanırım müşterinizden bir ya da daha fazlasını “ofiste bir gün” geçirerek yazılımı gerçekten nasıl kullandıklarını görmelerini istemelisiniz ... Bekleyin ... Beni 250 $ / saat karşılığında kiralayın ve öğreneceğim. Ayrıca, lütfen, lütfen goldplate etmeyin. Sadece çalışmasını sağlayın. Çoğu işletme, iyi çalıştığında çirkin görünmesini umursamaz.

İstekleri izleyin. Büyük özellikleri tasarlamaya / geliştirmeye başlarken, bu sürüme dahil etmek için birkaç öncelikli istek seçin.

İstekler için standart bir görüşme sistemi oluşturun. Belki bir şey bildirme veya sisbugz gibi özellik istek sistemi dayalı bir şey. Müşterilerinizin istekte bulunmasına izin verin ve aşağıdakilere dayanarak önceliği belirleyin:

• özelliğin teknik fizibilitesi / maliyeti
• özellik "ücretli" bir istek mi? Bir sözleşmedeyse ve / veya bunun bedelini ödediyse,
• özellik "mantıklı" mı? Bu bir sanattır, ancak genellikle yeterli sayıda müşteri bir özellik isterse, ücretsiz olarak uygulayın. Ürününüzü daha iyi hale getirme ve bir sonraki müşteriye satışı daha kolay hale getirme fırsatı
• Kullanılmayan, ücretli döngüleriniz var mı? Sözleşmelerinizin bir parçası olarak bakım / destek için bir dizi aylık saat eklerseniz (sayı çok düşük olsa bile kesinlikle yapmanızı öneririm) ve kullanılmıyorsa, bu tür değişiklikleri yapmaya atmaya başlayın

Müşterinin uygulamanın toplam sahipliği varsa, istediklerini yapın. Bırak paralarını uçursunlar; bu onların.

Ancak, bunu yapmazsanız, bu yardımcı alanlar için bunları çekirdek veri modelinin dışında saklamayı içeren bir çözüme gitmek istersiniz. Daha sonra bu müşteri için ekstra alanları birleştirmek üzere veritabanı görünümü gibi bir şey kullanabilirsiniz. (Depolanan verinin niteliğine bağlı olarak yardımcı depo yapmanın birkaç yolu vardır; en basit olanı ana tablonuzdaki bazı PK'larla aynı birincil anahtara sahip bir tablodur, ancak kullanım Alanın çok seyrek olması, yalnızca alanın indeksleme gibi şeyler gerektiren özellikleri istedikleri zaman gerçekten bir sorundur.)

Ayrıca, müşterilerin bu aşamada bunları uygulamak için yeterli kaynağınız olmadığını söyleyerek isteklerini erteleyebilirsiniz. Bu noktada, (en iyi tahmininiz) istediklerini ucuza uygulamanın ne zaman mümkün olacağını söyleyen yol haritanıza işaret ederseniz gerçekten yardımcı olur. Ve gerektiğini o meta özelliği ana uygulamanın temel bir satış özelliği olduğunda, ucuza özellikleri desteklemek için mümkün hale bir duruma uygulama öncelik verin.