Bir Kullanıcı Talebinin Perde Arkası
Dijital ürün yönetiminde, bir kullanıcı talebinin arkasındaki ihtiyacı anlamak, teknik imkanları değerlendirmek ve ürün için doğru kararı verebilmek üzerine
Dijital ürünler geliştiren ekiplerde Product Owner olarak çalıştım. Yaptığım işin önemli bir bölümü, bir tarafta ürünü kullanan veya üründen beklentisi olan insanlarla, diğer tarafta bu ürünü geliştiren ekipler arasında ortak bir anlayış oluşturmaktı.
Dijital ürünler dünyasında müşteri ve kullanıcı kavramları her zaman aynı kişiyi ifade etmiyor. Müşteri, bir ürünün geliştirilmesini talep eden, satın alan veya bunun için bütçe ayıran tarafı ifade ederken, kullanıcı ise o ürünle günlük işlerini yapan kişiyi ifade eder. Bazı dijital ürünlerde müşteri ve kullanıcı aynı kişidir, bazen de aynı dijital uygulamayı kullanan şirketin farklı bölümlerinde çalışan insan gruplarıdır.
Bir de işin geliştirme tarafı var. Buradaki görev dağılımı daha net ve daha spesifik tabii: Yazılımcılar, tasarımcılar, test ekipleri, network ekipleri ve ürün ihtiyaçlarının belirlediği farklı uzmanlıklardan insanlar… Bu insanlar aynı ürüne farklı bir yerden bakan meslek profesyonelleridir.
Product Owner olarak benim sorumluluklarımdan biri de bütün bu bakış açılarını bir araya getirerek ürünün hangi yönde gelişmesi gerektiğine ilişkin kararların alınmasına yardımcı olmaktır.
Bir talep geldiğinde…
Ürün geliştirme süreçlerinde sık sık kullanıcı (müşteri ve kullanıcı ayrımını yukarıda yapmıştım, yazımım devamında bu iki grubu tek bir isimle “kullanıcı” ile tanımlayacağım) talepleriyle karşılaşırız.
Bir kullanıcı mevcut ekranın değiştirilmesini ister, bir iş birimi yeni bir rapor talep eder, başka biri, günlük işlerini kolaylaştıracak yeni bir özellik önerir.
Bunlar ürünün gelişmesi için önemli girdilerdir. Çünkü ürünü her gün kullanan insanlar, yaşadıkları zorlukları çoğu zaman geliştirme ekibinden daha yakından bilir.
Benim işim de tam olarak burada başlar.
Önce talebi anlamaya çalışırım. Kullanıcı ne yapmak istiyor, mevcut durumda nerede zorlanıyor, önerdiği değişiklikle hangi sorunu çözmek istiyor?
Ardından bu ihtiyacı karşılamak için gerçekten yeni bir geliştirme gerekip gerekmediğini incelerim. Kullanıcının mevcut ürünü ne kadar etkin kullandığına da bakarım. Çünkü ihtiyaç duyulan çözüm, ürünün zaten sahip olduğu bir özellikte bulunabilir.
Bu incelemenin sonunda yeni bir geliştirme gerektiği kanaatine varırsam konuyu ilgili ekiplerle değerlendirmeye açarım.
Burada yalnızca talebin nasıl gerçekleştirileceğini değil, önerilen çözümün gerçekten ihtiyaç duyulan çözüm olup olmadığını da anlamaya çalışırız.
Çünkü kullanıcıdan gelen bir talep bazen doğrudan ihtiyacı anlatır, bazen de o ihtiyaca yönelik önerilmiş bir çözümü. İkisi her zaman aynı şey olmayabiliyor nitekim.
Kullanıcı ürüne başka bir yerden bakar
Bir kullanıcıdan ürünün bütün geliştirme süreçlerini, teknik bağımlılıklarını veya uzun vadeli stratejisini bilmesini bekleyemeyiz. Zaten böyle bir sorumluluğu da yoktur.
Onun önceliği genellikle çok daha somuttur: İşini ona ayrılan zaman içinde daha kolay yapmak, daha az zaman harcamak, gereksiz adımlardan kurtulmak veya karşılaştığı bir sorunu çözmek.
Örneğin, bir kullanıcı yönetime hazırladığı bir rapor için, her gün aynı bilgileri farklı ekranlardan toplamaktan şikayet edebilir ve bu bilgileri tek seferde kopyalayabileceği yeni bir buton yapılmasını isteyebilir.
Yeni bir buton geliştirmek sorunu hafifletebilir belki. Ama sistemleri birbiriyle konuşturmak, aynı bilgilerin farklı ekranlardan toplanması ihtiyacını tamamen ortadan kaldırabilir.
İlk çözüm daha ekonomik ve hızlı görünebilir. İkinci çözüm ise daha fazla geliştirme gerektirse de uzun vadede daha kalıcı bir fayda sağlayabilir.
Elbette bunun her durumda geçerli olduğunu söyleyemeyiz. Burada karar alırken dikkat etmemiz gereken şey, ilk duyduğumuz çözüm önerisiyle yetinmeden ihtiyacın kendisini anlamak olmalıdır.
Teknoloji geliştikçe kullanıcı beklentileri de değişiyor
Geçmişte teknik imkanlar ve kısıtlar konusunda geliştirme ekiplerinin verdiği bilgi tartışmaya pek açık değildi. Bir talebin neden yapılamayacağı ya da neden uzun süreceği anlatıldığında, kullanıcıların bunu değerlendirebileceği kaynaklar bugünkü kadar da erişilebilir değildi.
Get Gökhan Bakın’s stories in your inbox
Join Medium for free to get updates from this writer.
Bugün ise durum çok farklı.
Günlük hayatımızda kullandığımız uygulamalar, otomasyon araçları ve özellikle yapay zeka, teknolojinin neler yapabildiğini çok daha görünür hale getirdi.
Artık teknik bilgisi ve geçmişi olmayan biri bile kısa sürede yapay zekayı kullanarak bir web sayfası oluşturabiliyor, bir iş akışını otomatikleştirebiliyor veya küçük bir uygulama geliştirebiliyor. Bu gelişmenin kullanıcı beklentilerini etkilemesi çok doğal.
Bir zamanlar karmaşık görünen bazı işler artık birkaç dakikada yapılabiliyor. Dolayısıyla kullanıcılar da haklı olarak daha fazlasını bekliyor.
Hatta bazen bir talebe teknik açıdan mesafeli yaklaşıldığında, kullanıcıdan “Ama bunun benzerini başka bir uygulamada gördüm” veya “Yapay zekayla yapılabiliyor” yorumları gelebiliyor.
Bence bu değişim kötü bir şey değil. Kullanıcıların teknolojiye daha yakın olması, ürün geliştirme süreçlerine daha bilinçli katkı sunmalarını da sağlayabilir.
Ancak burada gözden kaçırmamamız gereken bir ayrım var:
Bir şeyin teknik olarak mümkün olması, mevcut ürünümüzde aynı kolaylıkla uygulanabileceği anlamına gelmiyor.
Bir özelliğin görünmeyen maliyeti
Dijital ürünler dışarıdan bakıldığında ekranlardan, raporlardan, butonlardan ve işlevlerden oluşuyor gibi görünebilir.
Oysa arka planda birbirine bağlı sistemler, veri akışları, güvenlik gereksinimleri, iş kuralları ve farklı ekiplerin sorumlulukları bulunur.
Küçük görünen bir değişiklik, bazen birden fazla sistemin güncellenmesini gerektirebilir. Yeni bir özellik, mevcut kullanıcı deneyimini etkileyebilir veya ileride sürekli bakım gerektiren bir yapıya dönüşebilir.
Bütün bunlar zaman ve kaynak harcamak demektir.
Diyelim ki bir geliştirme kullanıcıya üç birim fayda sağlayacak, ancak bunun için on birim kaynak kullanmamız gerekiyor. O on birim kaynağı bu işe ayırdığımızda, başka hangi işleri ertelemiş olacağız? (Bu rakamlar temsili tabii ama asıl anlatmak istediğim, geliştirmenin fayda/maliyet hesabını yaparak karar almanın önemi)
Aynı kaynaklarla çok daha fazla kullanıcıyı etkileyen bir sorunu çözebiliriz. Hatta mevcut bir özelliği iyileştirerek daha büyük bir fayda da yaratabiliriz.
Ürün yönetimi, çalışan yeni bir ürünü devreye almak ya da mevcut bir ürüne yeni özellikler kazandırmaktan ibaret değil. Sınırlı kaynaklarımızı nerede kullanacağımıza karar vermek de işimizin önemli bir parçası.
Bir talebi ürünün bütünü içinde değerlendirmek
Bir talebi geliştirme sürecine almadan önce, Product Owner olarak bazı kriterlere göre değerlendiririm.
İlk adım, talebin hangi ihtiyaca karşılık geldiğini anlamak. Ancak karar verebilmek için daha geniş bir çerçeveden bakmak gerek. Kaç kişiyi etkiliyor? Ne sıklıkla karşılaşılan bir sorun? Mevcut çözüm gerçekten yetersiz mi?
Sonra ürünün bütünüyle ilişkisini irdelerim. Her ürünün bir amacı, hedefleri ve zaman içinde ulaşmak istediği bir yönü vardır. Bizden beklenen bu yeni özellik ürünün yönünü destekliyor mu, yoksa odağımızdan sapmamıza mı neden oluyor?
Bunun yanında yasal zorunlulukları, operasyonel etkileri, ticari beklentileri, teknik bağımlılıkları ve geliştirme maliyetlerini de karar alırken dikkate alırım.
Bu değerlendirmelerin sonucunda bazen oldukça faydalı görünen bir talebi hemen hayata geçiremeyiz ya da daha basit veya geçici bir çözüm önerebiliriz. Hatta bazı durumlarda teknik olarak mümkün ve kısa sürede yapılabilecek bir işi, ürünün öncelikleri açısından doğru bulmadığımız için hayata geçirmeyebiliriz.
Bu, kullanıcının talebini önemsemediğim anlamına gelmez tabii. Asıl mesele, o talebin arkasındaki ihtiyacı ürünün diğer ihtiyaçlarıyla birlikte değerlendirebilmek. Çünkü bir talep kendi başına çok anlamlı olsa bile ürünün bütünü açısından her zaman doğru öncelik olmayabilir.
Aynı ürüne farklı yerlerden bakıyoruz
Kullanıcıların teknolojiye daha hakim olması ve beklentilerinin artması bence ürün geliştiren ekipler için olumlu bir gelişme. Bu değişim bizi de talepler karşısında daha açık olmaya, alışkanlıklarımızı sorgulamaya ve teknik kısıtları gerekçe gösterirken daha iyi açıklamalar yapmaya yöneltebilir.
Öte yandan, ürün geliştirmek hala seçimler yapmayı gerektiriyor. Kullanıcı işini kolaylaştırmak, geliştirme ekibi güvenilir ve sürdürülebilir çözümler üretmek istiyor. Product Owner olarak benim sorumluluklarımdan biri de bu beklentileri ürünün hedefleri ve elimizdeki kaynaklarla birlikte değerlendirmek.
Sonuçta iyi bir ürün geliştirmek, yalnızca neyi yapabileceğimizi bilmek değil; neyi, neden ve ne zaman yapacağımıza birlikte karar verebilmek.
