Bülten #44: Ürün borcu (ve Ürün Yönetimi Raporu 2022!)
Teknik borçtan farkı, sebepleri, neler yapılabilir, faydalı kaynaklar..
Bültene hoş geldin 👋
Bu sayıda “ürün borcu”, yani “product debt” kavramını inceliyoruz. Son iki haftanın gündem maddesi birazdan gelecek duyuru olduğundan bu sayı yalın, ama her zamanki gibi düşünmeye yönlendiren bir konu olsun istedik. Umarız faydalı olur!
İyi internetler,
Burcu
📬 Hem ihtiyacımız olan hem de hak ettiğimiz anket: Ürün Yönetimi Anketi 2022
Bu sene Üretim Bandı & Migros One iş birliğinde hayata geçen “Ürün Yönetimi Anketi 2022” yayında!
Amacımız Türkiye’de ve dünyanın başka yerlerindeki ürün yöneticilerini tanımak, şirketlerindeki ürün geliştirme yaklaşımlarını ve pratiklerini öğrenmek. Anket sonuçlarını kullanarak bir rapor hazırlayacağız ve Üretim Bandı’nın çeşitli mecralarından bu raporu paylaşacağız. 2020 raporunu merak edersen, o da şurada.
Katılıp çevreni de katılmaya davet etsen ne güzel olur, birlikte öğreniriz. Yazıya geçmeden, 7-8 dakikada tamamlamak için:
Ayrıca raporun destekçileri TalentGrid ve Basework’e de teşekkürler!
Ürün borcu
Tahmin ediyorum ki “teknik borç” kavramını herkes en az bir kere çalıştığı yazılım ekibi üyelerinden duymuştur. Ward Cunnigham’ın ilk kez ortaya attığı düşünüldüğü bu metafor aslında özetle şu: İçsel kaliteden ödün verilen bir dizi karar sonucunda geliştirme hızının gitgide yavaşlaması. Önceleri verilen bir kararın hızlıca uygulanabilmesi için gelecekteki hızdan çalmak. Her bir yeni kararın da bu geçmişten etkilenmesi, zamanla bir şeyleri değiştirmenin ya da yeni bir şeyler yapmanın olması gerekenden çok daha fazla zaman almaya mahkum olması. “Bir ara üzerine düşmemiz lazım” denilen nice ayak bağı bunlar aslında. Genelde de özellikle hızlı hareket etmek gereken, stratejik önemi olan noktalarda, ya da ürünün başlarında geleceği net öngörülemeyen noktalarda ürün ekibinin yazılım ekibinden helallik alıp taşın altına çok bakmamak konusunda anlaşması şeklinde gerçekleşiyor bu durum.
Ürün borcunun teknik borçtan ayrıştığı nokta da bu içsel olma durumu: Ürün borcu aslında dışsal, yani kullanıcının yaşayacağı bazı kötü deneyimleri, farkında olarak ya da olmayarak, hızlı olma kaygısı ile es geçmek. Hızlı olunmazsa ürünün çeşitli sebeplerden zarar görüleceğine karar verildiğinde gelecekte daha odaklı bir yol haritasına sahip olmaktan çalmayı kabul etmek. Bu kararın kullanıcıya sürtünmeler yaratması, hatta zamanla yol haritasını dahi bloklayabilecek hale gelmesi. Aslında ürünün mevcut haliyle ürün/pazar uyumu arasına giren her şey. Riski büyük, çünkü hızlı hareket edebilen rakiplerin biraz daha kullanışlı ya da kullanıcı odaklı olup ortaya koyduğu ürün rahatlıkla bizden çalabilir. Bu konuya ilk değinenler de “ürün tasarımı borcu” kavramıyla Andrew Chen ve “kullanıcı deneyimi borcu” ile Vijay Sundaram olmuş (linkleri faydalı kaynaklar’a bırakıyorum).
Ürün borcunu anladık, peki sebepleri neler? Genel hatlarıyla şöyle özetleyebiliriz:
Kısayoldan gitme düşüncesi. Görece kolay işlerin bile “Bir ara çözeriz zaten” yaklaşımıyla backlog’da aşağılara itilmesi.
Devamlı yeni özellik üretmeye odaklanmak. Ürünün gittikçe kompleksleşmesi ve birbirine bağımlı olan yapıların yeni her özellik için daha da iç içe geçmesi.
Bir probleme en uygun çözüm için yeterince keşif yapmaya vakit ayırmadan, kısa sürede bulunabilen yöntemle ilerleme alışkanlığı. Daha iyi bir çözüm fark edildiğinde çoktan bir sürü yerde değişiklik yapmanın gerekmesi.
Kullanıcıların istediği şeyleri değil, pazarın gerektirdiği şeyleri önceliklendirmek.
Ürün vizyonunun ve stratejisinin net olmaması, dolayısıyla bir sene sonrasını etkileyecek bir kararı alırken o zamanın da gereklerine uygun hareket etmenin mümkün olmaması. Ya da ürüne dair kararları veren ekibin bu vizyondan ya da birbirlerinin kararlarından yeterince haberdar olmaması. Özetle güçlü bir yönetim kültürünün eksikliği.
Ürün borcu gözünüze canavar gibi görünmesin. Tamamıyla kabul edilebilir ve gayet makul sebepleri var, ve aslında farkında olmak ve erkenden önlem almak yepyeni fırsatları getirebilir. Peki daha az ürün borcu için, ya da mevcut borçları kapatmak için ne yapılabilir?
Öncelikle mevcut borçları görünür hale getirmek gerekli. Bunun için de direkt ya da indirekt etkileri saptamak gerekiyor. Kullanıcıların churn etme sebepleri, destek ekiplerine ya da satış ekiplerine gelen şikayetvari öneriler, yeni bir stratejiye yönelmenin önündeki engeller, tüm bunlara yol açan kök sebepleri ve potansiyel etkilerini ortaya koymak, ekibin de anlamasını ve içselleştirmesini sağlamak ilk adımda yapılabilecek en doğru şey. Bazı ortak kök sebepler yukarıdaki listede var, bunlar üzerine konuşularak işe başlanabilir.
Yeni borç yaratmamaksa diğer bir önemli adım. Yaratılıyorsa da en azından farkında olmak kritik. Yeni borç yaratmamak için aslında bir önceki adımda fark edilen kök sebeplerin üzerine gitmek yeterli olacaktır. Yeni borç yaratmamanın bana göre en temel ve kesin çözümü şu: Ürün stratejisinin net olması, ürün ekibinin bu stratejiyi içselleştirmesi ve her aldığı kararda bu kontrolü yapması. Buna bir de “her bir yeni özelliğin ortalığı eskisinden daha derli toplu hale getirmesi” gibi bir hedef eklenirse tam olur. Tasarımın daha tutarlı ve tasarım sistemine uygun olması, veri modellerinin bir tık daha düzenli hale gelmesi, daha çok test otomasyonu, gibi gibi.
Mevcut borçları kapatmaksa güzel bir sonun başlangıcı. Bunun için belirli ekiplerin öncelikli odağını bu konu haline getirmek, ya da her ekibin düzenli olarak bu konuya vakit ayırmasını sağlamak gerekli. En kritik kök sebepleri saptamak ve onlardan başlamak, en hızlı etkiyi de yaratacak muhtemelen. İlla bir “baştan tasarım” noktasına gitmeye gerek yok, küçük parçalar halinde temelden başlayan iyileştirmeler çok daha hızlı gün yüzü görür. Kullanıcıyı elde tutmanın yeni kullanıcı edinmekten daha kolay olması gibi, karşılanmayan mevcut ihtiyaçlar da eksik birkaç yeni özellikten çok daha önemli. Şunu unutmamak lazım: Borç kapanmadıkça büyüyecek, yani ne kadar erken kapanırsa o kadar hızlanacağız. O yüzden ertelemenin de pek bir manası yok.
Ürün borcu doğru zamanda, doğru şekilde ödendiğinde ürünün sürdürülebilir olması, dükkanı kapatmasına bir sebep yaratmaması sağlanmış oluyor. Bu yüzden de ürün daha çok kazanmaya başladığında, ekip büyüdüğünde, kaynaklar arttığında, yepyeni sulara yelken açmayı düşünmeden önce bu borçları yavaş yavaş ödemeye başlamak lazım diye düşünüyorum.
Faydalı kaynaklar
Product design debt versus Technical debt - Link — Andrew Chen’den konuya erken bir dikkat çekiş.
User Experience Debt - Link — Vijay Sundaram’dan konuya erken bir dikkat çekiş daha.
A practical guide to solving product debt - Link — Borçların üzerine gidebilmeye dair rehber niteliğinde bir blog.
Debt Metaphor - Link — Kavramın ortaya atanı Ward Cunnigham’dan bir video.
Technical Debt: Adding Math to the Metaphor - Link — Teknik borç konseptini sayılarla tahminleyerek etkisini görebilmeyi sağlamak üzerine bir blog.
Önceki Sayılar 📚
Bülten #43:
Bülten #42:
Bülten #41:
İş İlanları
🔭 Ürün Yönetimi alanında iş mi arıyorsunuz? İlginizi çekebilecek pozisyonlardan haberdar olmak ister miydiniz? ☝️
Üretim Bandı network’ünde PM, Head of Product, APM vb. ürün pozisyonları için takım arkadaşı arayan ve bizimle iletişime geçen şirketler oluyor. Bu sebeple firmalarla ilgilenen kişileri bir araya getirdiğimiz bir havuz oluşturmaya başladık.
Siz de pozisyonlardan haberdar olmak istiyorsanız bu formu doldurabilir misiniz?
Bu sayılık bu kadar!
Yazılarımızı seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz: