Neden müşteri doğruyu söylemez ?

Asıl sıkıntı noktası; müşterinin dediği ile istediği arasındaki farktır. Bu noktada gereksinimlerin doğru toplanması çok önemlidir. Peki gereksinimler doğru toplamak için ne yapmalıyız ?

Burada müşterilere kesinlikle yalancı demek istemiyorum. Müşteri tam olarak ne istediğini dile getiremeMEsinin en büyük sebeplerinden biri , sizi o fırmada 10 yıllık bir çalışan olarak varsaymasıdır. İşin aslı arka planda tonlarca detayların gizli olduğudur. O kadar ki aynı özellik üzerine iki farklı çalışan iki farklı hikaye anlatabilir.

Bu gizli detayları ortaya çıkartmak için müşteriyle pes etmeden sürekli bir şekilde bilgi toplamak ve yapılan işi yerinde incelemeniz iyi bir fikir olabilir. Yalın felsefenin en iyi pratiklerinden biri olan Genchi Genbutsu (現地現物?) yani git ve yerinde gör yaklaşımı kesinlikle uygunlanmalıdır.

Başka bir müşteri tipi de projeyle o kadar çok ilgilenir ki  proje bir anda  “özellikler çöplüğüne” döndürebilir -ki bu özelliklerin çoğu kullanılmayacaktır.

Ünlü İtalyan ekonomist Perato’nun 80-20 kuralı, yazılım projelerine gayet iyi uyar. Yani yazılım projesinin %20 lık kısmı gerçekten kullanılır, geriye kalan %80’lık kısım neredeyse kullanılmaz. Kısaca israf söz konusudur.

Yazılım tasarlamak, bir bilinmezlik ile uğraşmak olduğunu kabul etmek etmek lazım. Bu arada Business Model Generation kitabından tasarımcı ve tasarlama olgularını çok iyi  ifade eden şu yazıları paylaşmak istiyorum :

Tasarımcının işi, yeni bir şeyi en iyi nasıl yaratabileceğine dail bitmez tükenmez bir arayışı, keşfedilmemiş olanı, keşfetmeyi veya fonsiyonelliği ulaşmayı içerebilir. Tasarımcının görevi, düşüncenin sınırlarını genişletmek, yeni seçecekler üretmek ve nihayetinde kullanıcılar için değer yaratmaktır.

Tasarlarken uygulayabileceğiniz bir kaç öneri

Müşteri Ol

Yani empati yapabilirsiniz, sen müşteri olsan ne yaparsın ?  XPLANE firmasının çıkarttığı Müşteri empati haritasını kullanmak iyi bir fikir olabilir.

Bu empati haritasına göre müşteriyi anlamaya çalışmak gayet basit. Bu noktada Post-It ler kesinlikle devrede olmalı.

 

Problemleri görseleştirin

Görsel düşünme soyutu somuta çevirir. Ögeler arasındaki ilişkileri ortaya çıkartır. Karmaşık olanı basitleştirir. Büyük resmi görmenizi sağlar.  Önemli olan ilitişimi sağlamak ve işin özünü anlamaktır. Boş kağıda veya tahtaya konuyu anlatan çizimler yapabilirsiniz.  Bir resim bin kelimeye bedeldir. Bunları anlatırken aklınıza sakın UML kullanmalıyım şeklinde bir düşünce gelmesin. Anlatmak istediğim UML’ın ötesinde birşey.

 

Prototip Oluştur

Bilinmezlik ile uğraşmanın en iyi yollarından bir diğeri de  prototip(ler) oluşturmaktır. Aynı görsel düşünce gibi prototip oluşturmak soyut fikirleri somut hale çevirir, hataların daha çabuk ortaya çıkmasını sağlar.

Domain Driven Design uygulayın

DDD bir teknoloji değil bir metodolojidir. Temelinde işin ve iş mantığının herşeyden daha önemli olduğunu söyler. Yani teknoloji odaklı değil, iş odaklı düşünme.  Bir kaç DDD kuralını sizinle paylaşmak istiyorum.

  • Ortak dil herşeydir. Yapılan işin dilini öğrenin: Örneğin muhasebe ise defter-i kebir ‘ın ne anlama geldiğini öğrenin ve benimseyin. Aksi takdirde müşteriyi anlama şansı kalmaz ve proje batabilir.
  • İletişim herşeydir; yapılan işi programlama dünyasının  jargonlarıyla bulandırmayın.
  • Yapılan modellemelerin (var mı ?) müşteri kolayca anlayabilmeli.
  • Detaylar için http://domaindrivendesign.org

 

 

 

 

No Comments

Post a Comment

Comment
Name
Email
Website