Ürün Deneyim Haritası

Gokhan Besen
Oct 4, 2017 · 5 min read
Deneyim Haritası + Release Plan

Hepimizin yapabileceğimizden çok daha fazla işi var ve kaynaklarımız sınırsız değil. Bu da hangi işi önce yapacağımız ve daha önemlisi hangi işi yapmayacağımız ile ilgili bir yöntem ihtiyacını beraberinde getirdi. Dahası dün önemli olan, bugün önemini yitiriyor, sabah toplantısından çıkan 25 kalem iş birden bire en önemli konu haline gelebiliyor.

Agile manifestosunu oluşturan 12 maddenin ilki şöyle der;

En önemli önceliğimiz, değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.

Bu ilk vaadi yerine getirmek için yazılım dünyası Scrum metodolojisini geliştirdi. Bu sayede sürekli olarak ve kısa periyotlarla teslim edilen bir yazılım kültürü doğdu. Değişen önceliklere en kısa sürede cevap verebilmek, şirketlerin rekabetçi kalabilmeleri için ihtiyaç duydukları en önemli rekabet avantajı haline geldi.

Tek ürün / tek ekiple başlayan şirketler, zaman içinde tek ürün / çok ekibe ve daha sonra da çok ürün / çok ekibe doğru bir evrim yaşadı. Ekipler çoğaldıkça uzmanlık ve derinleşme artıyor, paralelde pekçok iş yapılabiliyordu. Fakat bu durumun artıları olduğu kadar eksileri de vardı. Birden fazla ekibe dokunan işleri tamamlamak için sprintler arasında mekik dokumak, öncelik almak için savaşmak, iki haftadan sonrasının görünmediği, önemli projeler ilerlemezken küçük işlerin hızlıca yapılıverdiği bir dünya oluşmaya başladı. Elbette vizyonunu yitirmiş şirketler için yapacak birşey yok ama diğerleri için işe yarayabilecek birkaç yöntem var.

Ürün Deneyim Haritası bu yöntemlerden biri. Aslı “User Story Mapping” olan, Jeff Patton’ın icadı bu yöntem çevik yazılım camiasında oldukça popüler bir araç haline geldi. Türkçe’ye Ürün Deneyim Haritası olarak çevirdiğim bu yöntem size büyük resmi gösterecek ve tüm paydaşları aynı sayfada birleştirmenize yarayacak bir araç.

Deneyim Kartlarıyla Tanışın

Scrum’ın yaygınlaşmasıyla birlikte “Story” kelimesini çokça duyar olduk. İngilizce biliyorsanız bu basit kelimeyi anlamak çocuk oyuncağıdır, fakat Türkçesi “hikaye” olan bu kelimenin yazılım, tasarım, proje ve iş dünyasında hiçbir karşılığı yoktur. Bu yüzden anlamlandıramayız ama evet story der işimizi bildiğimiz gibi yapmaya devam ederiz. İşin aslı Story denmesinin çok önemli bir sebebi vardır, hatta çevik yazılımın story yazma formatı bile bu amaç için geliştirilmiştir;

As a {persona}, I want to {outcome}, so that {Business Value}

Şimdi story bize zaten çok birşey ifade etmezken karşımıza bir de persona, outcome ve business value gibi buyur burdan yak cinsinden terimler çıkınca en iyisi biz kafayı sallayıp devam edelim diyesi geliyor insanın. Hele ki sen kimsin de Business Value sorguluyorsun bakışları da varsa karşımıza, evet biz işimize bakalım diyip şu sıkıntılı toplantıdan bir an önce çıkalım kafasına geliyor insan.

Bir adet story açacaktık başımıza gelenlere bakın. Büyük şirketlerse günde 50–100 civarı story açılır, bu da yılda onbinlerce story anlamına gelir. Peki bunlar gerçekten de story mi? Şimdi şu tanımlardan uzaklaşıp olayın özüne inelim.

Story, kullanıcı ile yazılım arasında bir etkileşimi yani deneyimi anlatır. Bu yüzden Story bir “deneyim kartı”dır.

Şimdi daha anlamlı geliyor mu? O halde story olarak açtığınız işleri şimdi bu gözle tekrar değerlendirme zamanı, çünkü aslında iş listemizde iki tip talep olmalıdır. Birincisi story’ler, yani deneyim kartları, ikincisi de technical tasks yani teknik kartlar. Kullanıcılarınız için değer ürettiğinizden emin olmak istiyorsanız her iterasyonda maximum seviyede deneyim kartı geliştirdiğinizden emin olmalısınız. Bunun 80/20 gibi bir oranını da hedefleyebilirsiniz, zira teknik kartlar da sizin teknik borç üretmemeniz için çözmeniz gereken kartlardır. Bu elbette pazarlığa tabidir.

Kullanıcı Yolculuğu

Deneyim kartlarımızı şimdilik bir kenara koyalım, çünkü amacımız kullanıcı odaklı ürün yönetimi için bir altyapı kurmak. Bunun için kullanıcıdan başlamamız gerekiyor.

Kullanıcı yolculuğu, her şirketin kullanıcılarına yaşattığı deneyimin adımlarından oluşur.

Bir e-ticaret sitesini ele alalım. Nedir yaşadığımız deneyimin adımları?

  1. Ürün bulma
  2. Hesap yönetimi
  3. Satın alma
  4. Sipariş Yönetimi
  5. Yardım ve İletişim

Çok uzatmamak adına 5 ana grupta kullanıcı deneyiminin aşamalarını grupladım. Bunu biraz daha detaylandırarak 20–25 adıma çıkartabilirsiniz. İşte bu da bize “Epic” dediğimiz ve Türkçe karşılığını arayıp bulamadığımız meşhur çevik yazılım teriminin karşılığını veren listedir.

Epic, kullanıcı yolculuğunu oluşturan “deneyim grupları”dır.

Ürün ve yönetimine kısa bir giriş yazısı olarak yazdığım yazıda, bir balta olan ürünü yine bileşenlerine ayırmış ve deneyim sırasına göre dizmiştim. Buradaki her bir “epic” derinlemesine uzmanlaşma alanları olmakta, her biri veya birkaçı için de dedike ekipler çalışmaktadır. Amaç her bir alanda daha iyi deneyim üretmek. Dolayısiyle tüm şirket organizasyonunu da bu şekilde kullanıcı deneyimine hizalamak mümkündür.

Deneyim Haritası

Kullanıcı yolculuğunu ve deneyim kartlarını oluşturduğumuza göre artık deneyim haritamızı oluşturabiliriz. Adım adım yazıyorum;

  1. Epic’lerimizi (Maviler) soldan sağa doğru kullanıcının deneyimleyeceği sıra ile diziyoruz
  2. Her bir epic altındaki deneyim kartlarımızı da (Sarılar) yukardan aşağı doğru diziyoruz. Burada Teknik kartlar da olabilir, fakat farklı renk olmalı.
  3. Kulvarlar açarak deneyim haritamızı fazlandırıyoruz. (Alın size MVP)

Karşınızda ürününüzün birkaç ay sonraki deneyim haritası veya yol haritası veya ürün planı, nasıl kullanmak istiyorsanız o.

Şimdi iş havuzunuzda kaç epic var, bunlar gerçekten epic mi? Kullanıcı deneyiminin parçalarını oluşturuyor mu? Kaç story var, bunlar gerçekten story mi bakma zamanı. 8–10bin kartlık bir havuzda bu işi yapmak epey zor olabilir ama küçükten başlayarak ilerleyebilirsiniz. Bir ürün seçin ve deneyim haritanızı oluşturun.

Nasıl Kullanırım?

Deneyim haritası sürekli önceliklendirme mantığına göre çalışır. Siz güncelledikçe aslında yol haritanızı da çıkartmış olursunuz. Her bir iterasyonda anlamlı bir yazılım üretmek için önceliklendirmeyi sürekli yapıyor olmanız gerekir. Kapsam belirdikçe haritanıza ekleyin ve önceliklendirin. Böylece analiz, tasarım, mimari fonksiyonlarının da öncelikleri belirgin hale geleceği için herkesin aynı hedefe doğru ilerlemesini sağlamış olacaksınız.

Deneyim haritalarının amacı tüm paydaşları aynı sayfaya getirmektir, dolayısiyle bir görünürlük sağlama aracı olarak kullanmanız gerekir. Dijital araçlarda geliştirip büyük bir çıktısını duvara asabileceğiniz gibi, yansıtabilirsiniz de. Yok ben fiziksel kartlarla yapacağım diyorsanız, küçük haritalarda tercih sebebidir, ağanın eli tutulmaz ancak 2500 kartlık bir haritayı hazırlamak epey yorucu olacaktır.

Bu yazıda temel olarak Jira kullanımını baz alarak 2 seviyeli bir haritayı anlattım. Aşağıdaki Jira pluginiyle böyle bir yapı kurabilirsiniz. Diğer ürünler Jira ile entegre çalışmakla birlikte iş akışı bakımından yeni bir araç öğrenmek istemiyorsanız bu plugini tavsiye ederim.

Not: Proje yönetimi açısından dijital araçlar filtreleme fonksyonları sunduğundan tercih edilebilir. Projeleri “label” kullanarak filtreleyebilirsiniz.

Dijital Araçlar:

Sevgiler.

*Bu yazının orijinali 27 Eylül 2017’de yayınlanmıştır.

ProductTank İstanbul

ProductTank'in İstanbul organizasyonu bu Medium yayını ile Ürün Yönetimi konusunda Türkçe içerik üretmek ve farkındalık yaratmayı amaçlıyor.

Gokhan Besen

Written by

ProductTank İstanbul

ProductTank'in İstanbul organizasyonu bu Medium yayını ile Ürün Yönetimi konusunda Türkçe içerik üretmek ve farkındalık yaratmayı amaçlıyor.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade