Kullanıcılar İçin Değil, Kullanıcılarla Birlikte Tasarlamak
Şirketlerin çoğunda uygulanan geleneksel iş analizi metodolojilerini düşündüğümüzde, ihtiyaçların sadece paydaşların katılımı ile toplantı odalarında geleneksel bir şekilde ele alındığını, analiz çıktısı olarak ise detaylı, teknik terimlerin bol olduğu dokümanların hedeflendiğini görüyoruz. Yapılan onca toplantıya ve analiz dokümanlarına rağmen yine de projeler başarısız olmaktadır ve proje başarısızlıklarının temel nedeni ise genellikle gereksinimlerle ilgilidir. Paydaşları bir araya getirmek ve ihtiyacı anlamak noktasında geleneksel bir şekilde çalışan şirketlerin çoğu birçok zorlukla karşı karşıya kalmaktadır. Tüm bu zorlukların üstesinden gelmek için iş analizini yeni yöntemler ve bakış açılarıyla yeniden ele almaya ihtiyaç vardır. Yeni nesil iş analizi dediğimiz tasarım odaklı yöntemler tam bu noktada projelerde yaşadığımız sıkıntılara derman olacaktır.
Günümüzde ve gelecekte iş analizinde kilit bir bakış açısı olarak ele aldığımız yöntem, gereksinimlerin toplamasından ziyade gereksinimlerin ortaya çıkarılması (requirements elicitation) olarak tanımlanmaktadır. Toplamak (gathering), çok belli olan gereksinimlerin toplanması anlamına gelmektedir. Ancak, gereksinimlerin ortaya çıkartılması çok daha derin araştırmaları, konuşmaları ve gözlemleri içermektedir. Bu, son kullanıcının gerçek ihtiyaçlarının ortaya çıkarılması ile ilgilidir. Son kullanıcıları ihtiyacın ortaya çıkarılması ve çözüm tasarımı aşamalarına dahil etmek, yeni nesil analizi yaklaşımlarında çok kritiktir.
İş analistleri olarak karşılaştığımız zorlukları yeni nesil iş analizi yaklaşımları ve bakış açılarıyla nasıl ele almamız gerektiğine bakacak olursak;
ZORLUK #1: Belirsiz Gereksinimler
Belirsiz durumlarda gereksinimlerin tanımlamalarını yapmak projeler için en büyük zorluktur. Net ve açık olarak belirli olmayan gereksinimler ile projeye başlamak, varış yerinizi bilmeden bir yolculuğa çıkmak gibidir. Gereksinim belirsizlikleri çeşitli sebeplerden kaynaklanabilir; ancak benzer sonuçlar verir. Projeler ertelenir ve temel beklenti ve ihtiyaçları karşılamaz.
İş Analistleri olarak, ihtiyacı doğru ve net bir şekilde tanımlayabilirsek; yani Johari Window’daki pencerenin “bilinen” (known-knowns) kısmına taşıyabilirsek, yaptığımız analizimiz ile alakalı daha güvenli hissederiz. Eğer “bilinmeyen”ler (known-unknowns) olduğunu bilirsek, onları da daha fazla analiz yaparak ortaya çıkartabiliriz.
Ancak bir iş analisti olarak farkında olmadığımız ama ihtiyaç sahipleri tarafından bilinen birçok gereksinim olabileceğini (unknown-knowns) de göz önüne almalıyız. Bu da, doğru soruları sorarak, resmi daha anlaşılır kılmak için daha çok gereksinimleri ortaya çıkartma (requirements elicitation) aktivitesi yapmamız gerektiği anlamına gelmektedir.
Johari penceresindeki son alan ise “bilinmeyen bilinmeyenler”dir (unknown-unknown). Burası kimsenin bilmediği gereksinimleri içermektedir. Müşterilerin de bu alan ile ilgili hiçbir fikri yoktur. Bizim bir sonraki büyük çözüme ulaşmamız için bu alanla ilgili araştırmalar yapmamız ve içgörüleri yakalamamız gerekmektedir. Apple akıllı telefonları yaratmadan önce, bir akıllı telefona ihtiyacı oldugunu kim söyleyebilirdi?
ZORLUK #2: Problem mi Çözüm mü?
Müşterilere ihtiyaç duydukları şeyleri sorduğumuzda, sorunlarını çözdüklerini düşündükleri bir çözümle soruyu cevaplandırırlar. Bu bizim için çok yaygın bir tuzaktır. Genellikle yazılım ekiplerine gelen taleplere bakıldığında birçoğunun çözüm olarak iletildiğini görüyoruz. İş Analistleri olarak, çözümden önce tüm müşterilerin ihtiyaçlarının kök nedenlerine odaklanmamız gerekir. İhtiyaçlar müşteri için bir acı noktası (pain point), istek veya yapılacak bir iş olabilir.
Bir ihtiyacı veya problemi tam olarak anlamlandırdıktan sonra, kullanıcının ihtiyaçlarını karşılayacağını düşündüğümüz çözüme odaklanmalıyız. Çözümü ise tüm paydaşlarla birlikte tasarlamalıyız.
Bazen iş birimleri tüm cevaplara sahip olduklarına ve müşterilerle görüşülmesinin vakit kaybı olduğuna inanırlar. Aksine, müşteri ihtiyaçlarının iyi anlaşılması yeni potansiyel çözümlerin keşfedilmesine yardımcı olur. Kullanıcılara deneyimlerini sormak ve yaptıklarını gözlemlemek, nasıl davrandıklarını ve motivasyonlarının ne olduğuna bakarak inovasyon sürecini içgörülerle temellendirebiliriz.