Kullanıcıların gereksinimleri kendi başlarına bir araya getirmelerine veya bunları yönlendirmelerine izin verilsin mi?

Eminim herkes böyle bir şey yaşamıştır. Bir projesi olan bir müşteriyle toplantıya girersiniz. Akıllarında hiçbir / birkaç gereklilik yoktur ve ne istediklerini / neye ihtiyaç duyduklarını en belirsiz şekilde anlarlar. Bu noktada, iki seçenek var gibi görünüyor:

1) Kullanıcılara "Tamam, henüz tanımlayamasanız bile sizin için bir şey oluşturamıyorum. Neden birkaç hafta içinde ne istediğinizi bildiğinizde bir araya gelmeyelim" deyin.

2) Kullanıcılarla birkaç kez görüşün ve iyi ole Socratic yöntemiyle onlara rehberlik ederek ne istediklerini anlamalarına yardımcı olun. "X'i izlemeniz mi gerekiyor?", "Y'ye ne dersiniz?", "Z işlevselliğine mi ihtiyacınız var?"

İlk seçenekle, başkasının işini yapmakta veya psişik güçlere sahip olmaktan kaçınamazsınız, ancak kullanıcılar size asla tutarlı bir şartname sunmayabilir veya son tarih yaklaşmaya devam ettikçe sonsuza kadar sürebilir. İkinci seçenekle, bir iş analisti olmak için bir sürü zaman harcarsınız ve muhtemelen bir daha asla kullanmayacağınız bir sürü iş bilgisini kafanıza sıkıştırmanız gerekir, ancak bir anlam ifade ediyor.

Bana göre bu, gelişimin en zorlayıcı yönlerinden biri ve bu düşüncede yalnız olmadığımı hissediyorum. Deneyiminize göre, bu seçeneklerden hangisi daha iyi çalışma eğilimindedir?

İtiraf etmeliyim ki bazen 3. seçeneği seçiyorum)

3) Müşterilerin belirsiz fikirlerini dinleyin, tam olarak ne istediklerini anlamalarına yardımcı olmak için haftalar geçirme fikrine göz atın ... bu yüzden neye ihtiyaç duyduklarını anlayın, bunu oluşturun ve gerektiği gibi yeniden düzenleyin.

Bu, özellikle küçük işler için işe yarar, çünkü müşterilerin gerçek dünyada pratik olmayan bu parlak fikrin kafasında bulunduğu durumlardan kaçınmaya yardımcı olur.

Bu bana her zaman olur; "elbette yapabiliriz ..." çok korkutucu bir ifadedir. Özellikle bahsedilen şeyler neredeyse her zaman çan, ıslık ve "sahip olmak güzel" özellik sınıfıdır. "Açıkçası bir böcek izleyici açıkçası ve sonra ..." ifadesinde bunu anlamıyorlar. Potansiyel çalışmanın büyük kısmı ilk dört kelimede duruyor.

Bu nedenle, bazen bir müşteri vizyonu almak , iyi bir doz programcı sağduyulu uygulamak ve ihtiyaçlarına uygun bir şey inşa etmek güzeldir .

Orijinal soru açısından; Bağlama çok bağlı olduğunu düşünüyorum. Müşteri ile sıkışmışsa (yani bağlı olduğum bir iş sözleşmesi yoluyla veya alternatif bir iş yoksa) o zaman # 2 en güzel yaklaşımdır. Aksi takdirde, bir hafta içinde size bir programcı olarak tamamen yararsız olan harika ve ayrıntılı bir spesifikasyon sunulacak olma olasılığı yüksektir.

Yukarıda belirtilenler ile aynı problem (# 3) ve zaten # 2 yapmak zorunda kalmanızı sağlayan bir problem.

sadece bir programcı olmak istiyorsanız, bir başkası müşterinin neye ihtiyacı olduğunu anlayana kadar bekler ve

Eğer bir geliştirici olmak istiyorsanız ve bu sizin müşteriniz ise, o zaman müşterinizin elini tutup, birlikte Wants and Needs'ın kesişiminde mutlu tavşan dolu çayırları bulana kadar onları yoğun korkutucu olasılıklar ormanından geçirin.

EK: bu sürece "sistem analizi ve tasarımı", diğer adıyla Danışmanlık denir ve asla ücretsiz yapılmamalıdır.

Programlama başlangıçta kullanıcıların problemlerini çözmektir. Bu yüzden benim için, kullanıcılarımıza çalışan, tatmin edici bir çözüm elde etmek için "ekstra" çaba ve acıya girmek, neredeyse "ekstra" güçlükten kaçınmak ve sonunda yararlı bir şey sunmaktan neredeyse kazanır.

(Tabii ki, orada gerçekten ne istediklerine dair hiçbir fikri olmayan gerçek kullanıcılar var ve hiçbir çaba onları anlamlı bir karar verebilecekleri bir duruma sokamaz. Ama çoğu durumda gerçek bir sorun, çözülmek için çaba ve nakit harcamaya hazırlar ve çalışan bir çözüme daha yakın olmalarına yardımcı olabilirsek mutlu olurlar.)

Sonuç olarak, odak noktamız kullanıcıların sorunlarını çözmek olmalıdır. Bu bazen bazı hedefli sorular sormayı ve cevapları bulmaları için onlara daha fazla zaman vermeyi gerektirebilir. Bazen alan adının yakın işbirliği içinde birlikte çizilmesini gerektirir. Bazen basit eskizler / prototipler / maketler yapmak için biraz zaman harcamanız ve ardından sonucu göstermeniz ve "bu aklınızdakine benziyor mu?" (daha sonra "aslında tamamen farklı bir şey düşünüyordum ..." diyerek prototipin fırlatılmasına ve baştan başa ... :-)

Gerçek beceri doğru yaklaşımı doğru zamanda seçmektir.

Son olarak, deneyimlerime göre, iyi çözümler neredeyse her zaman geliştirici tarafından en azından bazı alan bilgisi gerektirir. Bu olmadan, kullanıcıyla gerçek bir ortak diliniz yoktur, bu nedenle sunduğunuz şeyin gerçekten yararlı olacağına dair hiçbir garanti yoktur. Kullanıcılar genellikle teknoloji hakkında çok fazla fikre sahip değildir, bu yüzden neyin mümkün ve neyin mümkün olmadığı ve farklı yaklaşımların / özelliklerin maliyetinin ne olduğu hakkında hiçbir fikre sahip değildir. Teknolojiyi yeterli ayrıntıya kadar öğrenmelerini makul bir şekilde bekleyemeyeceğimiz için, köprünün sonundan bu ekstra adımı atmalıyız.

Bu, geri ödeme yapmayan "ekstra" çaba olarak görülebilir - ancak bunu iki nedenden dolayı yatırım olarak görmeyi tercih ederim:

• uzun vadede bir geliştirici olarak pazar değerimi artıran iyi çözümler sunmamda yardımcı oluyor ve
• farklı alanlar tamamen farklı değildir, bu nedenle bu alan bilgilerinin en azından bir kısmı gelecekteki konserlerde tekrar kullanılabilir olacaktır.

Bir yazılım geliştiricisi olarak görevinizin bir kısmı, yazılımın kullanılacağı etki alanı hakkında yeterli bilgi edinmektir. Bu nedenle, bir projenin başlangıç ​​aşamasının bir parçası olmak son derece değerlidir (zaman ve müşteri deneyimi açısından). . Evet, bu kapsamlı bir alan adı ve ihtiyaç analizi yapmak anlamına gelir. Hedef kullanıcıları dahil etmek, onlarla görüşmek veya yazılımınızın kullanılacağı yerde dolaşmak için mükemmel bir zamandır.

Ancak, bu beceriyi kazanmak, özellikle alan bir mühendislik disiplinine bağlı olmadığında neredeyse bir sanat formudur. Açık sorularınız müşteri için ürkütücü görünebilir, yerinde varlığınız istenmeyebilir, hedef kitlenizin sosyal yapısını anlamamanız hala kırılgan bağlantıları parçalayabilir.

Bu aşamanın karmaşıklıklarını anlayamamak, hem yazılım geliştiricileri hem de müşteri gibi hayal kırıklığına neden olur. Bu aşamadan daha hızlı geçmek ya da tamamen ortadan kaldırmak istiyoruz. Sonuçlar genellikle felakettir: hızlandırılmış başlangıçtan sonra, geliştirme sırasında başarılı olmanın hisseleri daha da artar ve çizim tahtasına geri dönmek daha da zorlaşır. Sistem nihayet bittiğinde ve milyonlar harcandığında, ne müşteri ne de mühendislik firması başarısızlığını kabul etmeye istekli değildir, bu da başarısız bir sistemin zorla kullanılmasına yol açar.

Bir alternatif, bir iş analistinin işi sizin için yapmasına izin vermektir. Bu, bazı ürünler için mantıklı olabilir ve analist genellikle aracı olabilir, ancak yalnızca daha fazla iletişim kanalı (ve dolayısıyla daha yüksek bir hata şansı) yaratacaktır.

Her durumda: bir kod parçasının yeniden yazılması asla bir parça parçanın yeniden yazılmasından daha ağır basmaz.

ps belki şelale yöntemini savunuyorum düşünüyorum. Ben 'önde büyük tasarım' inanan değilim, ancak etki alanı analiz çaba uygulama çaba orantılı olması gerektiğine inanıyorum. Birden fazla döngü yapılabilir (prototip, sürüm adayları, vb.).

Kullanıcılarınız geliştirici olmadıkça kesinlikle seçenek 2 (o zaman bile seçenek 2 gerekli olabilir).

Yazılım geliştirme yaşam döngülerinin çoğu gereksinim toplamaya odaklanır. Çoğu kullanıcı sadece ne istediklerini bilmekle kalmaz, aynı zamanda neyin mümkün olduğunu da bilmez, bu yüzden kullanıcının neye ihtiyacı olduğunu anlamak için kullanıcıyla çalışmak kritik bir yazılım geliştirme görevidir.

Her iki seçenekle de gitmeniz gerektiğini düşünüyorum . Bırakın ve ne istediklerine karar verin. Ardından, başlangıç ​​noktası olarak kullanılacak somut bir fikir olduğunda, gereksinimleri faydalı bir şeye düzeltmek için onlara rehberlik edin.

İstedikleri şeyi zorlukla ifade edebildiklerinde Seçenek # 2'ye atlamak istemezsiniz, çünkü tüm süreci daha yavaş ve daha sinir bozucu hale getirirler (size geldiklerinde çok net bir fikirleri yoksa, ancak benim durumumda bu çok nadirdir). Fikirlerini bir araya getirmelerini sağlayın. Kağıt üzerinde bir şeyler yazmalarını sağlayın, mümkünse mevcut sistemler açısından ne istediklerini açıklayın (ör. "Blahblah.com gibi bir web sitesi istiyoruz, ancak bu farklılıklar ile ... Ürün A'yı Ürün X gibi bir araç istiyoruz , ancak kullanıcı arayüzü Görev B de yapmalıdır ... "). Ardından, sistemi oluşturmak için kullanabileceğiniz çok özel gereksinimlere istediklerini geliştirmeye başlamanın tam zamanı.

Genel olarak, müşteriler size tam olarak neye ihtiyaçları olduğunu düşündüklerini bilerek gelecektir. Ne yazık ki, sağlayacağınızı düşündükleri çözüme götüren sorunları açıklamak yerine, size söyleyecekleri budur.

İhtiyaçlarını karşılayacak bir şey tasarlamak için, bu ihtiyaçları tanımlamanız gerekir ve bunu yapmak için, birisinin müşteriyi basılı tutması ve bu ihtiyaçları çıkarması gerekir. Başka kimse yapamazsa, yapmalısınız. (Birisi yapabileceğini düşünüyorsa, onlarla oturup daha sonra gerçek ihtiyaçları elde etmeniz gerekebilir ...)

Seçenek 2 ile, bir dizi toplantıda, müşteriyi çözümleri değil de sizinle sorunları paylaşması için eğitebilirsiniz. (Müşterinin teknik yeteneği olsa bile - örneğin, bu işi yapmak için kullanılabilirliği yoktur ve bunun yerine bunu yapmanız gerekir - yine de son müşteri için ideal olmayan bir uygulamaya odaklanıyor olabilir.) hangi geliştirme sürecini kullanırsanız kullanın, soruları sizin için özellikleri tanımlayacak şekilde cevaplayabilene kadar birkaç kez ileri geri gitmeniz gerekecektir.

Unutmayın, hataları geliştirme döngüsünde mümkün olduğunca erken yakalamak istersiniz. Bunları kodlama veya test etme yerine gereksinimler sırasında yakalayabilirseniz, kendinize çok zaman kazandıracaksınız.

Seçenek 1, bir iş yapmamak için mükemmel bir yoldur. İşin gereksiz olduğuna inandığımda ya da yapacak daha önemli işlerim olduğunda kullandım.

İlk olarak, kullanıcılar bilgisayarların neler yapabileceğini bilmiyorlar. Çoğumuz bilgisayarları ve hesaplamayı anlamayı öğrenmek için yıllar geçirdik ve bizim için açık olan şey, o yılları başka şeyler öğrenmeye harcayan biri için kolayca anlaşılabilir olmayabilir.

İkincisi, kullanıcılar ne istediklerini bilmiyorlar ve genellikle ne istediklerini, herhangi bir işlem yapılabilir anlamda bilmiyorlar.

Bir benzetme yapmak için, şu anki evimi satın aldığımda, bir iç tasarımcı ana (ABD ilk, İngiltere zemin) katındaki odalar için duvar renklerini seçti. Bu renkleri asla kendim seçemezdim. İyi görünen bir ev istedim ve anladım. Tasarımcı beni dinleseydi ve bana dile getirebileceğim bir şey verseydi, neredeyse ortaya çıkmazdı.

Kullanıcılara ihtiyaç duydukları şeyi istedikleri şekilde yapmanın tek yolu onlarla kendiniz çalışmaktır.