Müşterinin talebi ile ne anlama geldiğini anlamak yazılım geliştiricisinin sorumluluğunda mıdır?

Bir çeşit evet / hayır sorusu ve neden?

Müşterinin isteği ile ne anlama geldiğini anlamak yazılım geliştiricinin sorumluluğunda mı yoksa geliştiriciye talebini doğru bir şekilde açıklamak müşterinin sorumluluğunda mı?

İşteki durum şu anda "müşteri zaten bize açıkladı, ne istediğini. Daha fazla soru sormak değil, isteği anlamak sizin sorumluluğunuzdadır".

İngilizce benim güçlü paketim olmasa da, tüm istekler yanlış İngilizce ve yanlış anlaşılmış cümlelerle yazılır, bazı istekler benim tarafımda sistemin daha önce anlaşıldığını varsayar.

Sistemin 3. veya 4. geliştiricisiyim (son geliştiriciler işi bıraktı) ve müşterinin geliştiriciler tarafında biraz anlayış beklemesinin nedeni bu olabilir.

Sistemin kendisi hem kullanıcı arayüzünde hem de kaynak kodu düzeyinde oldukça dağınık. Bu bana kodlama maymun gibi görünüyor ve aslında isteği anlamak değil, isteği doğru olsun umuyoruz.

Aslında işi bırakmayı düşünüyorum, ama kimin doğru ve kimin yanlış olduğundan emin olmadığım için henüz yapmadım.

Eğer anlamak sizin işinizse, siz öğrenene kadar soru sormak sizin işinizdir.

Sorduğunuz kişi , müşteri olmayan biri olabilir (genellikle bir aracıyla konuştum, müşteriyle iletişim halindeydi), bu nedenle müşteriyle konuşmanızı yasaklayanlar bunun yerine soruları kendileri cevaplamalı veya sizi yönlendirmelidir. yapabilen biri.

Ama sonunda bir tür iletişim olmalı. Reddediyorlarsa (ve anlamadığınız bazı belgeleri sağlamak etkili bir şekilde iletişimi reddediyorsa), öncekilerinizin yaptığı gibi yapmalısınız: hızla kaçın.

Müşterileriniz ve amirleriniz sizi dağınık bir kağıt izi ile terk ettiğinde, yapabileceğiniz tek şey, sahip olduklarınızdan mümkün olduğunca çok şey toplamak ve senaryoları nasıl yazdığınızı yapılandırmak için düz İngilizce olarak yazmaya başlamaktır. sistemin davranması gerekiyordu.

Verilen / Ne Zaman / Sonra senaryoları, olması gerekenler hakkında ayrıntılı bilgi almanızı mümkün kılar ve düz İngilizce yazıldıkları ve yapılandırıldıkları için, bunları amirinizle ve müşterinizle iletişim kurmak için kullanabilirsiniz: "Dinleyin, Bu noktaya geldim ve sistemin burada ne yapması gerektiği konusunda hiçbir fikrim yok ".

Ek açıklama istediğinde basitçe kaçtıysanız, yaptığınız ve anlamadığınız her şeyi belgelemek için çaba harcadığınız halde, önceki geliştiriciler, özellikleri nasıl ileteceklerini bilmedikleri için değil, çünkü bunu yapmak imkansız.

Bence hem (müşteri hem de geliştirici) problem ve çözümü aynı anlayışı .

İsteği anlamadıysanız çözümü oluşturamazsınız.

Yani özellikleri okumak zorundasınız. Spesifikasyon yeterince açık değilse (veya yazılı bir spesifikasyon yoksa) cevapları verebilecek biri olmalıdır.

İş sorularına cevap verebilecek bir kişi olan takımlarda çalışıyorum. Bu işletme sahibi , çalıştığım geliştirme şirketinin bir üyesi ya da müşteri işini bilen ya da müşteri ekibinin bir üyesidir.

Özel uyarlamanızda, proje yöneticisi müşterinin aynı soruları birden fazla kez sorması durumunda (geliştirici cirosu nedeniyle gerekli) rahatsız edileceğinden ve bunun kendisine ve şirketine kötü yansıyacağından korkuyor.

Tabii ki, bu soruları sormazsanız, sistemi tamamlamanız / değiştirmeniz çok daha uzun sürer ve sonuç müşterinin istediği şey olmayabilir, bu da daha fazla gecikmeye neden olur ve AYRICA proje yöneticisine ve şirket, en azından müşterinin gözünde.

Proje yöneticisinin soru sormanıza izin vermemeyi seçmesinin bazı nedenleri vardır:

1. Olumsuz sonuçları gerçekten anlamıyor ya da onlar hakkında inkar ediyor.
2. Alternatiflerin farkında, ancak müşterinin can sıkıcı sorulardan daha fazla gecikmeyi ve düşük kaliteyi kabul etme olasılığını biliyor.
3. Siyasi oyunlar oynuyor: belki de projeyi yakında terk edeceğini biliyor ve o zamana kadar problemleri gizli tutmak istiyor ya da bu iletişim eksikliğinden kaynaklanan sorunlar için sizi suçlamayı planlıyor.

IMO nedeni 2 olası değildir. Sebep 1'i ortadan kaldırmak için, ona alternatifleri açıklamayı deneyin ve onlardan açık bir seçim yapmasını isteyin - sıkıntıyı azaltmak için müşteriye sorunu açıklamayı önerin. Sebep 3'ü ortadan kaldırmak için bunu yazılı olarak yapın, böylece potansiyel problemlerin erken farkında olduğunuzu kanıtlayabilir ve düzeltmeye çalışabilirsiniz. Ama dürüst olmak gerekirse, bunun gerekli olduğundan şüpheleniyorsanız, muhtemelen mümkün olduğunca çabuk çıkmalısınız.

Müşterilerin niyetlerini anlamalarını sağlamak her zaman servis sağlayıcının sorumluluğundadır.

Alanımızdaki uzmanlar olarak, sadece özetleri tamamlamak değil, aynı zamanda hizmetimizi kullanma sürecinde müşterilerimize rehberlik etmek de bizim işimizdir ve bu, sunduğumuz olanaklar ve şimdi ne yaptığımız konusunda onları eğitmekle ilgiliydi.

Müşteri odaklı bir yaklaşımın kesinlikle bir şeyler yapmanın yolu olduğunu, denenmiş ve test edilmiş bir iş modeli olduğuna inanıyorum.

Müşteri ve geliştiricilerin, sistem hakkındaki anlayışlarını geliştirmek için birlikte çalışmaları gerekir.

Yazılım şirketinin, her bir taraf için neyin gerekli olduğu, yani bir sözleşmenin temel yönü olan müşteri ile anlaşma yapması gerekmektedir. Eğer “akıl toplantısı” yoksa, o zaman çok gerçek anlamda, bir sözleşme yoktur.

Yetkili bir programcı olduğunuzu varsayarsak, şartname net değilse, sadece "İsteği anlamak sizin sorumluluğunuzdur, daha fazla soru sormak değil" denir.

Bu, orijinal soru hakkındaki yorumlarda bazı yeni bilgilere dayanmaktadır.

İfadesi

müşteri bize ne istediğini zaten anlattı. Daha fazla soru sormak değil, isteği anlamak sizin sorumluluğunuzdadır

proje liderinden geliyor; belirtilen gerekçe

sistemdeki ilk geliştirici olmadığım için müşterinin temsilcisini daha fazla soru ile rahatsız etmemeliyiz, ancak gerekirse soruyu yorumlamak için ekstra zaman harcamayı deneyin.

Bu nedenle, özellikle kaçınmanız gereken şey müşteriyi sorularla rahatsız etmektir .

Sizden "soruyu yorumlamak için fazladan zaman harcamanızı" istemek mantıksız değildir. Müşterinin gerçekte söylediklerine dayanarak gereksinimlerin ne olduğunu anlamak için makul bir çaba göstermeli, hatta belki de biraz mantıksız bir çaba göstermelisiniz. Başka bir şey değilse, bu değerli bir yetenek.

Bu başarısız olursa (ve çeşitli nedenlerle zaten varmış gibi görünüyorsa), proje liderinizden yardım isteyin. Ödevlerinizi yaptığınızı göstererek sorularınızda olabildiğince spesifik olmaya çalışın. Örneğin,

bu insanlar ne istiyor ??? "

gibi bir şey sor,

Gereksinimler belgesinin 17. paragrafında foobarın kıvrımı kıvırması gerektiğini; bu üç frozitten hangisine atıfta bulunuyor? "

Veya gereksinimler gerçekten o kadar kötü yazılmışsa, bunları deşifre edemeyeceğinizi söyleyin.

Nihayetinde gereksinimlerin doğru bir şekilde anlaşıldığından emin olmanın proje liderinin sorumluluğunda olduğunu söyleyebilirim (projenin başarılı olması kesinlikle onun yararınadır). Ancak ekibin bir üyesi olarak, bu sorumluluğun bir kısmını paylaşırsınız. Kendinize biraz çaba harcadığınızı gösterirseniz ve proje lideri size yardımcı olmayı reddederse, o tamamen sizin sorumluluğunuzdadır. Bu noktaya gelirse, bunu bildiğinden emin olun.

Mükemmel bir dünyada, bir yerde özelliklerin ve özelliklerin bir listesi olmalı, şirketinizi ve müşterinizi bağlayan bir sözleşmede yazılı bir şey olmalıdır.

Sorunuzu cevaplamak için, geliştirici gerçekten müşterinin ne istediğini anlamalı ve her iki tarafın da aynı vizyonu kabul etmesi için yazılı bir belgeye sahip olmalıdır.

Tabii ki, bu mükemmel bir dünya değil ve çoğu zaman şartname yoktur ve herhangi bir yazılı spesifikasyonunuz yoksa, bu zor olacaktır. Şirketinizde, müşteri ile ilişki temsilcisi olarak çalışan, müşterinin ne istediğini anlamanıza yardımcı olabilecek kimse kaldı mı?

Değilse, sizin pozisyonunuzda, elbette görevi anladıkları varsayılarak, önceki geliştiricilerden bilgi almaya çalışırdım.

Gereksinimleri anlamakla kimin ilgileneceğini belirleyen asıl rolün bu değişkenlerin bazılarına bağlı olarak değiştiğini düşünüyorum

• Takım boyu
• Şirket standartları
• Patronun işe alışma şekli
• Ekip üyeleri arasında farklı uzmanlık

Yani sadece tek kişilik bir takımsanız, taleplerin en altına ulaşmak için her türlü çabayı göstermelisiniz. devam etmekte olan bir projede yeniyseniz, talepleri müşteriyle tekrar gözden geçirmek için çaba göstermelisiniz.

DÜZENLEME: En önemlisi, müşteri bu kadar kötü gereksinimler yaptığını bilmeyebilir ve gereksinimleri toplama işlemi genellikle uzun ve sıkıcıdır, ancak bu önemli bir süreçtir ve eğer size düşerse, başka hiç kimse yapmazsa, onlarla yapın.