Özellik Şişmesi: Nedir ve Nasıl Önlenir?

Hepimizin, her zaman “bir özellik daha” varmış gibi göründüğü için bir türlü yayımlayamadığı bir ürünü olmuştur. Bazen yeni özellikleri kapsama ekleyen CEO olmuştur. Bazıları içinse mesele, her bir kullanıcı talebine yanıt vermeye çalışmaktır.

Nedeni ne olursa olsun, harika ürünlerin sessiz katili olan özellik şişmesini hepimiz deneyimledik.

Geliştirme ve ürün ekipleri gereksiz özellikler geliştirmekle meşgulken ürünleri zamanında yayımlayamadığı için kaç gelecek vadeden ürünün uçuruma sürüklendiğini hayal bile edemezsiniz.

Bu nedenle, bu yaygın tuzaktan kaçınmanıza yardımcı olmak için özellik şişmesinin ne olduğunu ve değişiklik kontrolü ile üst yönetimi yönetmek gibi basit taktikleri kullanarak bununla nasıl mücadele edebileceğinizi açıklayacağım.

Özellik Şişmesi (veya Kapsam Şişmesi) Nedir?

Çevremde bir ürünün özellik şişmesi yaşadığından söz edildiğinde, bunu her zaman, tüm ekstra eklentilerin ağırlığı altında yürümekte zorlanan, gereksiz vücut parçaları bulunan, özensizce şişirilmiş bir yaratık olarak hayal ederim. Yeni (ve oldukça etkileyici) ChatGPT görsel oluşturucusundan bu görüntüyü benim için hayata geçirmesini istediğimde ortaya çıkan sonuç buydu.

Not: Merak ediyorsanız yapay zekâ aslında kullanışlı ürün özellikleri hakkında beyin fırtınası yapma konusunda oldukça başarılıdır.

Başka bir deyişle, özellik şişmesi, somut bir vizyon veya yön olmaksızın ürününüze kontrolsüz biçimde özellikler eklenmesidir. Bu durum çoğu zaman sürüm bekleyen işler listenizin, özellikleri yayımlama hızınızdan daha hızlı büyümesine yol açar.

Bu durumu tanımlamak için çoğu zaman birbirinin yerine kullanılan kapsam şişmesi adı verilen bir terim de vardır. Ancak bu iki terim arasında ince bir fark bulunur.

• Kapsam şişmesi genellikle gecikmelere yol açan, sürüm planınıza durmaksızın özellik eklenmesini ifade eder.
• Özellik şişmesi ise daha çok sonuca odaklanır: gezinmesi veya kullanılması zor, Frankenstein benzeri bir ürün.

İlişkili üçüncü bir terim olan özellik fabrikası tuzağı da vardır. Ancak bunu yazının sonundaki Soru-Cevap bölümümüzde ele alacağız.

Özellik Şişmesiyle Karşı Karşıya Olduğunuzu Gösteren İşaretler

Ürününüzdeki özellik şişmesinin başlıca belirtileri genellikle açıktır ve kolayca fark edilir. Belirgin belirtilerden bazıları şunlardır:

• Sürüm kapsamı büyümektedir ve yeni özelliklere neden ihtiyaç duyduğumuza dair net bir açıklama yoktur.
• Sürüm gecikmelerinizin kaynağı, kapsama eklenen işlevlerdir.
• Paydaşlarınız, yanıt olarak HAYIR’ı kabul etmeden sürüm kapsamının yönetimine hâkim olmaktadır.

Özellik şişmesinin tehlikesi, bazen çok geç olana kadar fark edilmesi zor, sinsi bir yaratık olmasıdır.

Bu işaretleri görmediğinizi varsayarsak, bu özellik şişmesinden güvende olduğunuz anlamına mı gelir? Pek sayılmaz. Özellik şişmesinin tehlikesi, bazen çok geç olana kadar fark edilmesi zor, sinsi bir yaratık olmasıdır. Bu, bazı belirtilerini tespit etmenin o kadar da kolay olmadığı anlamına gelir. İşte bunlardan ikisi:

• Sürekli kapsam değişiklikleri. Yalın ve Çevik metodolojilerinin gerçekliği içinde kapsamı değiştirmek normaldir. Kullanıcı değerinin bu özellikler olmadan kaybolacağını anladığınız için sürüm kapsamına bazen 1-2 özellik eklemeniz de normaldir. Ancak sürüm kapsamı sürekli büyüyor ve ek özellikler kullanıcı için yüksek değer taşımıyorsa, bu özellik şişmesidir.
• Paydaşlar ürünün nihai sürümünü geliştirmek için baskı yapmaktadır. Bir beta sürümünün veya MVP sürümünün paydaşlarınıza gelir kazandırmayacağını anlıyorum. Bu nedenle MVP’yi zaman kaybı olarak görmeleri ve bunun yerine nihai sürüme odaklanmak istemeleri doğaldır. Ancak MVP kullanıcıları temel özelliklerinizi önce doğrulamadan nihai sürümler geliştirmek, insanların ihtiyaç duymadığı şeyleri geliştirmenin garantili bir yoludur.

Bu belirtilere, özellikle de ince olanlara, yakından baktığımızda çoğumuz sahip olduğumuz kaotik proje kapsamının “Çevik olmak” olmadığını fark edeceğiz. Bu, eski ve bildik özellik şişmesidir.

Tamam, ama bu nasıl oldu? Kapsamı kontrol altında tutmak için elinizden geleni yapıyor gibiydiniz. Ürünlerin kapsam şişmesi yaşamasının yaygın (ve şaşırtıcı) nedenlerine bakalım.

Özellik Şişmesi Neden Olur?

İş listesini yönetmek için gösterdiğiniz çabalara rağmen buradasınız. Bu nasıl oldu? Çoğu zaman özellik şişmesinin temel nedenlerini fark etmek zordur ve bunları basit kapsam yönetimiyle düzeltmek daha da zordur.

The truth about project scope creep

Kariyerim olarak adlandırdığım engebeli yola dönüp baktığımda, benim de kendi payıma düşen özellik kapsamının kontrolsüzce büyümesi vakaları yaşadığımı fark ediyorum. Bunun altında yatan nedenler o zamanlar bariz değildi. Bu öğrendiklerimin çoğu, kariyerimin ilk yıllarında deneme yanılma yoluyla edinilmiş zorlu derslerdi. Ancak şimdi kıdemli bir ürün yöneticisinin gözünden bu olaylara baktığımda, işlerin nerede ters gittiğini görebiliyorum.

Genel olarak özellik kapsamının kontrolsüzce büyümesi şu nedenlerden biri nedeniyle gerçekleşir:

• Paydaş baskısı: Diğer adıyla “Eklenecek son bir şey daha var, hepsi bu”. Bunu siz de duydunuz, ben de duydum. Bazen paydaşlar, kapsamda yapılacak küçük eklemelerin sürüm tarihini değiştirmeyeceğini düşünür; çünkü bu gerçekten küçük bir şeydir. Sorun şu ki en küçük değişiklik bile günler sürebilen tüm kod inceleme - QA - CI/CD sürecinden geçmek zorundadır.
• Ürün yöneticilerinin yeterince HAYIR dememesi: Bunun zor olduğunu biliyorum—özellikle de paydaşlara karşı çıkmak söz konusu olduğunda. Ancak çoğu, ödünleşimleri açıkça açıklarsanız fikirlerini memnuniyetle geri çeker. Onların “küçük talebini” ek süreye, ilave QA döngülerine, mühendislik kapasitesine ve sürüm takvimine yönelik olası riske dönüştürebilirseniz bunun yalnızca hızlı bir düzenleme değil, gerçek sonuçları olan bir yatırım olduğunu anlayacaklardır.
• Her müşteri talebine evet demek: Bu cazip gelebilir—özellikle anlaşmaları kazanmaya, yüksek değerli müşterileri elde tutmaya veya duyarlılığınızı kanıtlamaya çalışırken. Ancak müşterilerin istediği her şeyi geliştirmek ürününüzü daha iyi hâle getirmez. Yalnızca onu şişkin, tutarsız ve bakımı daha zor bir duruma getirir.
  
  Zor gerçek mi? Tüm geri bildirimler eşit derecede değerli değildir. Harika ürün ekipleri ne zaman harekete geçeceğini, ne zaman erteleyeceğini ve ne zaman vazgeçeceğini bilir—çünkü her “evet”in bir maliyeti vardır: Önemli olan, girdileri stratejik biçimde önceliklendirmenize ve ürün vizyonunuzla uyumlu kalmanıza yardımcı olan net bir müşteri geri bildirim döngüsüne sahip olmaktır.
• Rekabet baskısı: Bir rakibin gösterişli bir yapay zekâ özelliği kullanıma sunması, benzer bir şeyi mevcut sürümünüze zorla eklemeniz gerektiği anlamına gelmez. Çok hızlı tepki vermek çoğu zaman gerçekten fark yaratmayan, yarım yamalak özelliklere yol açar—daha da kötüsü, yol haritanızı rayından çıkarabilir, ürün kalitesinden ödün vermenize ve lansmanların gecikmesine neden olabilir. Güçlü ürün liderliği çoğu zaman ne zaman duraklayacağını, değerlendirme yapacağını ve geliştirdiğiniz şeyin bütünlüğünü koruyacağını bilmektir.
• Net kapsamın olmaması: Nelerin kapsamda, nelerin kapsam dışında olduğu konusunda erkenden uzlaşmak, zaman çizelgenizi korumanın anahtarıdır ve bu da sağlam Scrum ürün yönetimi uygulamalarıyla kapsam konusunda ortak bir anlayış oluşturmakla başlar.
• Aşırı mühendislik: Aşırı mühendislik çoğu zaman iyi niyetlerle başlar—geleceğe hazırlama, optimizasyon yapma, çalışma arkadaşlarını etkileme—ancak sonunda kimsenin tam olarak anlamadığı kırılgan sistemlere dönüşür. Gerçek beceri karmaşık bir şey geliştirmek değildir. Önemli olan, ne zaman geliştirmemek gerektiğini bilmektir. Temel ürün yönetimi en iyi uygulamalarını benimsemek, ekiplerin gereksiz karmaşıklık olmadan değer sunmaya odaklanmasına yardımcı olabilir.
• Herkesin kullanım senaryolarını kapsamak: Son kullanıcılarınızın hepsi eşit değildir. Bazıları “diğerlerinden daha eşittir” (diğer adıyla size daha fazla para kazandırırlar). Aha! Kurucu Ortağı ve CEO'su Brian de Haaff'in kullanıcı geri bildirimini iş hedefleriyle dengeleme konusundaki sözleri şöyle:

Yukarıdaki listeye baktığınızda, muhtemelen kendi ürününüzde gizlenen birkaç suçluyu fark edeceksiniz. Tek başlarına zararsız görünebilseler de birlikte odağınızı, ilerleme hızınızı ve ürün bütünlüğünüzü sessizce aşındırırlar.

Özellik Kapsamının Kontrolsüzce Büyümesi Size Ne Kadara Mal Oluyor?

Kısa cevap? Çok fazla! Özellik kapsamının kontrolsüzce büyümesi, ürününüzün kalitesini, performansını ve ekibinizin moralini sessizce aşındıran gizli maliyetleri beraberinde getirir. Kullanıcı deneyimi üzerindeki etkisi kendi bölümünü hak edecek kadar zarar verici olsa da önce ürününüzü zayıflattığı diğer yöntemlere bakalım.

Sürüm Tarihlerinin Kaçırılması

Pazara çıkış süresi çoğu zaman kusursuzluktan daha önemlidir. İlk yapay zekâ özelliğimi geliştirirken bunu zor yoldan öğrendim. Hata oranını %0'a indirmeye takıntılıydım, ancak CEO'm bana sürekli şunu hatırlatıyordu: “Mükemmel olmak zorunda değil—yalnızca kullanıma sunulması gerekiyor.”

Haklıydı. Hızlı bir şekilde kullanıma sunduk ve özellik ham olsa da ilk bizdik. Bu özelliği rakipler arasından ilk kullanıma sunan biz olduğumuz için insanlar bu yapay zekâ yeteneğini (arama özetleme ile ilgiliydi; Microsoft Teams ve diğerlerinden çok önce kullanıma sunduk) markamızla ilişkilendirmeye başladı. Bu nedenle, Teams bu özelliği kullanıma sunduğunda bile birçok kişi aracımızı kullanmaya devam etti; çünkü ona alışmışlardı.

Bu erken sürüm, bize marka bilinirliği ve rakipler hâlâ yetişmeye çalışırken deneyimi iyileştirme konusunda bir başlangıç avantajı sağladı. Bekleseydik, bu fırsatı tamamen kaçırabilirdik.

Üstelik ilk biz kullanıma sunduğumuz için, diğerleri yalnızca ilk ham sürümlerini yayınlarken özelliği yineleme ve geliştirme konusunda da başlangıç avantajına sahip olduk.

Özellik Kapsamının Kontrolsüz Büyümesi Ekipleri Yavaşlatır ve Yıpratır

Eklediğiniz her özellik yalnızca geliştirilmesi için zaman almaz; kendisinden sonra gelen her şeye de ek bir yük getirir. Zamanla ürün mimarinizi anlamak zorlaşır. Küçük değişiklikler bile veri modelleri, arayüzler, testler ve iş akışları genelinde beklenmedik bağımlılıkların zincirleme biçimde ortaya çıkmasına neden olabilir. Sonuç olarak yeni özellikleri kullanıma sunmak daha uzun sürer, hataları düzeltmek daha riskli hâle gelir ve kod tabanına duyulan güven azalır.

Bu yavaş yavaş artan karmaşıklık yalnızca teslimatı etkilemez; ekip moralini de olumsuz etkiler. Ekipler uç durumları çözmeye çalışırken veya eski kararların etrafından dikkatle dolaşırken ivme kaybolur. Kapsam sürekli büyüdüğü için sürümler gecikmeye devam ettiğinde, hiçbir şeyin gerçekten tamamlanmadığını hissetmek kolaylaşır. Tükenmişlik de burada başlar: çok çalışmaktan değil, hiçbir yere varılmıyormuş gibi hissettiren bir işten.

Özellik Kapsamının Kontrolsüz Büyümesi UX'i Nasıl Etkiler?

Özellik kapsamının kontrolsüz büyümesinin UX üzerindeki etkisi o kadar önemlidir ki bundan ayrı bir bölümde bahsetmem gerekiyor. İyi bir kullanıcı deneyimi, ürününüzün başarısının en kritik unsurlarından biridir ve büyük özen gösterilmesi gerekir. Ne de olsa iyi bir kullanıcı deneyimi oluşturmak için harcanan her dolar size 100 dolar gelir olarak geri dönebilir.

Elbette, korkulan özellik kapsamının kontrolsüz büyümesi de dâhil olmak üzere UX'inize zarar veren etkenlerden kaçınmak için elinizden gelen her şeyi yapmak istersiniz.

Peki özellik kapsamının kontrolsüz büyümesi UX'inize tam olarak nasıl zarar verir? İşte şöyle:

Arayüz Aşırı Yükü

İşin ironik yanı, daha fazla özelliğin daha iyi bir ürüne eşit olmamasıdır. Aksine, ürününüze çok fazla şey eklemek kullanılabilirliğine zarar verir.

Buradaki mantık basittir: kullanılabilirlik, arayüzünüzün ne kadar sade ve hafif olduğuyla doğrudan bağlantılıdır. Öte yandan, özellik kapsamının kontrolsüz büyümesiyle birlikte düzinelerce özelliği düğmeleriyle beraber arayüzünüze tıkıştırır ve gezinmeyi zorlaştırırsınız.

Harika ürünlerde, kullanıcı yolculuğundaki her ekranın tek bir temel amacı vardır. O ekranda temel amaca hizmet etmeyen tüm unsurlar kullanıcının dikkatini dağıtır ve hedefine ulaşmasını zorlaştırır. Bu nedenle ikincil kullanıcı arayüzü unsurlarınız ne kadar az olursa kullanılabilirliğiniz o kadar iyi olur.

Örnek olarak bu konut kredisi ödeme hesaplayıcısına bakalım.

Bu arayüzdeki her bir unsur tek bir amaca hizmet eder: konut kredisi ödemenizi hesaplamanıza yardımcı olmak. İlk kez gören kişiler için bile kullanımının kolay olmasının nedeni budur. Burada kafanızı karıştıracak veya sizi bunaltacak hiçbir ek özellik yoktur.

Şimdi Jira'nın otomasyon düzenleyicisine bakalım.

Sadece bakınca bile gözleriniz ağrıdı mı? Çünkü benim ağrıdı! Tamam, kabul ediyorum; bu, pek çok yeteneğe sahip güçlü bir özellik. Ancak Atlassian bunların hepsini tek bir arayüze eklemeyi başarmış ve bu da arayüzde gezinmeyi biraz göz korkutucu hâle getiriyor.

Dolayısıyla Jira otomasyonu, çok fazla özellik oluşturmanın (diğer adıyla özellik kapsamının kontrolsüz büyümesinin) kullanılabilirliğinize nasıl zarar verdiğinin canlı bir kanıtıdır.

Performans Düşüşü

Özellik kapsamının kontrolsüz büyümesi, arayüzünüzde gezinmeyi zorlaştırmasının yanı sıra ürününüzde önemli yavaşlamalara da yol açabilir.

Geliştirdiğiniz her yeni özellik, kullanıcının tarayıcısının ayrıştırması için ek JavaScript ve sunucularınızın işlemesi için arka uç mantığı içerecektir. Bu nedenle, düşük değerli birçok özellik eklemek hem kullanıcı cihazlarında hem de sunucularınızda aşırı yüklenmeye neden olur.

Ürünün yavaşlaması, karşılaşabileceğiniz en etkili kullanılabilirlik sorunları arasındadır. Ünlü Amazon araştırması, 100 ms'lik bir yavaşlamanın gelirlerinde %1 kayba yol açtığını gösterdi.

Özellik Kapsamının Genişlemesi Nasıl Yönetilir (ve Önlenir)?

Özellik kapsamının sürekli genişlemesi ürününüzün ilerlemesine zarar verir ve bu durum her zaman yaşanır. Ancak iyi haber şu ki, nasıl yapılacağını bildiğinizde bunu yönetmek ve önlemek de oldukça kolaydır.

Bunu kontrol altında tutmanın 6 adımlı rehberi burada.

1. Her Kararı Ürün Vizyonuna Dayandırın

Bir ürünün net ve ortak bir vizyonu olmadığında her fikir geçerli görünebilir ve özellik kapsamının genişlemesi tam olarak böyle başlar. Vizyon, ekiplerin odaklanmasına olanak tanır. Yalnızca ne inşa ettiğinizi değil, neyi inşa etmediğinizi de tanımlar.

Örneğin Figma'yı ele alalım. Ekip, ilk günlerinde birçok kullanıcı yerel bir masaüstü uygulaması talep etmesine rağmen tarayıcı tabanlı kalma konusunda bilinçli bir seçim yaptı. Bu karar geri bildirimleri görmezden gelmekle ilgili değildi; erişilebilirlik ve gerçek zamanlı iş birliği konusundaki uzun vadeli vizyona bağlı kalmakla ilgiliydi. Her talebe boyun eğmiş olsalardı, onları Figma yapan en önemli farklılaştırıcıyı kaybedebilirlerdi.

Güçlü bir vizyon ilham vermek için değil, filtrelemek için vardır. Net bir vizyon olmadan önceliklendirme bir müzakereye dönüşür. Tek bir vizyonla, kendinizden emin bir şekilde “şimdi değil” veya “hiçbir zaman” diyebilirsiniz. Neyin ürüne ait olmadığı açıkça görülür.

2. Bir Yol Haritasıyla Acımasızca Önceliklendirin

Doğru şekilde uygulanan önceliklendirme, özellik kapsamının genişlemesini önlemenin başka bir yoludur. Buradaki anahtar kelime “doğru şekilde uygulanan”dır. Her özellik fikrini “olmazsa olmaz” olarak etiketlemek önceliklendirme değildir.

Bu durumdan kaçınmak için vizyonunuza ve kullanıcılarınızın temel ihtiyaçlarına bakın. Özellik fikri aynı anda her ikisine de katkıda bulunmuyorsa, neredeyse kesinlikle olmazsa olmaz değildir.

Önceliklendirme çerçeveleri açısından kişisel favorilerim şunlar:

MoSCoW: Fikirlerin “olmazsa olmaz”, “olmalı”, “olabilir” ve “olmayacak” şeklinde basit bir sınıflandırmasıdır. MoSCoW ile önceliklendirilmiş bir iş listesi şöyle görünür:

RICE: Her satırın bir özellik fikrini, her sütunun ise şunlardan birini temsil ettiği bir tablodur:

• Özelliğin hizmet ettiği kullanıcı sayısı (erişim)
• Kullanıcı sorunlarını ne ölçüde çözeceği (etki)
• Özelliğin başarısından ne kadar emin olduğunuz (güven)
• Özelliği geliştirmek için gereken kaynaklar (çaba).

Şöyle görünür:

Bu çerçevelerin her ikisi de bir elektronik tablo veya sunum dosyası üzerinde iş listenize öncelik vermeniz için yeterince basittir. Ancak bunun yerine bir uzmanlaşmış ürün yönetimi aracı kullanmanızı öneririm (ör. Aha! veya ProdPad); çünkü bu araçlar çalışmalarınızın çoğunu otomatikleştirir ve görev yönetimi yazılımınızla entegre olur.

3. Yapım Öncesinde Özellikleri Doğrulayın

Deneyimlerime göre fikir doğrulama, işe yaramaz özellik fikirlerini engellemenin en verimli yollarından biridir. Paydaş baskısıyla karşı karşıya olduğunuzda özellikle faydalıdır. Uygulamanız için bir fikirleri varsa önce bunu doğrulayın.

Fikir ya doğrulamadan geçer ve onu geliştirmenin değerli olduğunu fark edersiniz ya da başarısız olur ve onlara HAYIR derken paydaşlarınıza sunabileceğiniz ampirik kanıtlara sahip olursunuz.

Doğrulama açısından aşağıdaki yaklaşımları kullanabilirsiniz:

1. Kullanıcıların buna ihtiyaç duyup duymadığını anlamak için onlarla görüşün.
2. Tıklanabilir prototipler oluşturun ve kullanıcıların bunlarla etkileşime girerek size geri bildirim vermesini sağlayın.
3. İnsanların bu fikri kullanıp kullanmadığını veya görmezden gelip gelmediğini gösteren analitik veriler elde etmek için A/B testleri yürütün.
4. Özelliğin bir MVP (minimum uygulanabilir ürün) sürümünü oluşturun, kullanıma sunun ve test edin.

Bu listedeki yaklaşımlar en ucuzdan (görüşmeler) en pahalıya (MVP) doğru sıralanır. Bu nedenle size tavsiyem ilkinden başlamanızdır. Böylece kötü bir özellik fikrini çok fazla zaman ve çaba harcamadan geçersiz kılabilirsiniz.

4. Kapsam Sınırlarını Belirleyin ve Bunlara Bağlı Kalın

Sürüm kapsamını doğrudan değiştirmeyi reddetme taktiği de vardır. Gerçi %100 ret uygulamak yerine, yapılması gereken kritik bir şey ortaya çıkmadıkça ilk kapsamı sabit tutmaktan söz ediyoruz. 

Kapsamı değiştirmenin uygun olduğu tek zaman, ilk planınızın özelliğin geliştirildiği kullanım senaryosunu karşılayamayacağını fark ettiğiniz zamandır.

Örneğin, vergi belgelerini işleyen bir yapay zekâ aracı geliştirdiğinizi ve aracın yalnızca görüntü dosyalarını desteklediğini düşünün. Bir noktada vergi belgelerinin çoğunun görüntü değil PDF olduğunu fark edersiniz. Dolayısıyla PDF'leri desteklememek özelliğinizi kullanışsız hâle getirecektir. Kapsamı değiştirmenin uygun olduğu durum budur.

Bu süreç değişiklik kontrolü olarak bilinir ve kapsam genişlemesini yönetmek için elinizdeki harika bir araçtır.

5. Paydaşları Bilgilendirin ve Uyumlu Hâle Getirin

Yarım düzine CEO ile çalışma deneyimime göre çoğu “hayır” cevabını duymaktan rahatsız olmaz; yeter ki nedenini açıklayabilesiniz.

Yöneticiler hızlı ilerlemek ister, ancak küçük bir talep gibi görünen şeyin sonraki etkilerini ortaya koymanız için size güvenirler.

Mary Abbajay, Üst Yönetime Yönetmek kitabında

Abartılı bir savunma yapmanıza gerek yok; yalnızca ödünleşimleri açıkça ifade etmeniz yeterli. Bir talebin teslimatı nasıl geciktirebileceğini veya diğer önceliklerden nasıl ödün verebileceğini gördüklerinde çoğu kişi yalnızca itirazınızı saygıyla karşılamakla kalmaz, birilerinin anlık “evet” cevabının ötesini düşündüğünü görmekten de memnun olur.

 6. Düzenli Olarak Denetleyin ve Ayıklayın

Hepimiz iş listelerimizi düzenli tutmamız gerektiğini biliyoruz, ancak bunların yarım yamalak fikirlerle ve uzun süredir unutulmuş özellik talepleriyle dolu bir mezarlığa dönüşmesine izin vermek kolaydır. İş listesi iyileştirmesini üç aylık bir suçluluk seansı olarak görmek yerine, bunu bitkilerinizi sulamak veya masaüstünüzdeki ekran görüntülerini silmek gibi rutin bir bakım olarak düşünün.

Şaşırtıcı derecede faydalı bir çalışma (burada bana katlanın) benim ürün ağacını budamak olarak adlandırmayı sevdiğim çalışmadır. Ürününüzün özelliklerini bir ağacın gövde, dal ve yaprakları gibi haritalandırır; ardından ekip olarak hangilerinin geliştiğine, hangilerinin budanması gerektiğine ve hangilerinin tamamen kesilebileceğine karar verirsiniz. 

Bu yöntem görsel, iş birlikçi ve tuhaf biçimde tatmin edicidir; ayrıca sonunda iş listenizle barışmanıza yardımcı olabilir.

Özellik Kapsamının Kontrolsüz Genişlemesine Dair Gerçek Dünya Örnekleri

Çoğumuz özellik kapsamının kontrolsüz genişlemesinin nadir görülen bir durum olduğunu veya kariyerimizin başlarında karşılaştığımız ve sonrasında ustalaştığımız bir şey olduğunu düşünürüz. Aslında öyle değil. Teknoloji devleri ve gelecek vadeden girişimler bile ürünlerini neredeyse yok eden bir özellik kapsamı genişlemesi vakasıyla karşı karşıya kaldı. İşte öne çıkan birkaç örnek.

Örnek 1: Windows Vista

Microsoft'un her iki Windows sürümünden birini berbat ettiğine dair bir teori var. XP harikaydı. Dolayısıyla doğal olarak Vista felaket olan sürüm olacaktı.

Öyle de oldu. Fazlasıyla şişirilmiş, gereğinden karmaşık bir işletim sistemiydi; çok fazla işlem gücü gerektiriyor ve istikrarsızlığıyla nam salıyordu.

Bu dağınık sürümün ardındaki nedenlerden biri özellik kapsamının kontrolden çıkmasıydı. Microsoft tek bir yeni sürümde her şeyi aynı anda iyileştirmek istedi. Gösterişli bir kullanıcı arayüzü eklediler, güvenlik mimarisini değiştirdiler, tam geriye dönük uyumluluk istediler ve güzel araç takımları eklediler.

Tüm bunların sonucu, insanların XP’den Vista’ya yükseltmeyi reddetmesi oldu. PC dünyası bunu bir başarısızlık olarak değerlendirdi ve Microsoft itibarını ancak Vista’nın ardından çıkardığı harika sürüm olan Windows 7 ile toparlayabildi.

Örnek 2: Google Wave

Açıkçası, bu ürünün neyle ilgili olduğunu hiçbir zaman anlayamadım. Google Wave’in belgeler gibi varlıklar üzerinde gerçek zamanlı iş birliğini mümkün kılan bir araç olduğu söyleniyor. Ancak ben onu, harika ama anlamsız özelliklerden oluşan düzensiz bir yığın olarak görüyorum.

Bu, vizyon ve strateji olmadan bir şeyler oluşturmanın harika bir örneği. Evet, Google Wave’in gerçek zamanlı iş birliği özellikleri sonunda Google Dokümanlar’a aktarıldı ve temel özelliklerinden biri hâline gelerek gerçek kullanıcı ihtiyaçlarını karşıladı. Ancak özgün ürün, pratik bir amacı olmayan bir grup özelliğin bir araya getirilmesinden ibaretti.

Örnek 3: Snapchat’in Yeniden Tasarımı

Snapchat 2018’de kapsamlı arayüz yeniden tasarımını kullanıma sunduğunda insanlar öfkelendi.

Listedeki diğer örneklerde olduğu gibi, yeni tasarımın kimse tarafından beğenilmemesinin nedeni, net bir yönlendirme olmadan çok fazla özelliğe sahip olmasıydı. Snapchat ekibi o kadar çok “havalı” özellik eklemeye odaklanmıştı ki tutarlı kullanıcı yolculuklarını korumayı tamamen unuttular.

Sonuç olarak insanlar yeni arayüzde kullanmak istedikleri özelliği bulamayınca büyük bir kafa karışıklığı yaşandı.

Özellik Kapsamını Genişletmek Ne Zaman İyi Bir Fikirdir?

Daha önce de belirttiğim gibi, kapsamın genişletilmesi her zaman kötü değildir. Sürüm kapsamına yeni özellikler eklemenin uygun olduğu nadir durumlar vardır.

Temel kural, yeni özellik fikrinin kapsama dâhil edilmeye uygun olması için aşağıdaki üç ölçütü aynı anda karşılaması gerektiğidir:

• Kullanıcılar bunu doğrulamıştır. Prototiplerinizi veya MVP’nizi denedikten sonra kullanıcılar belirli bir özelliğin eksik olduğunu ve bunun kendileri için önemli olduğunu belirtmiştir.
• Stratejiyle uyumludur. Kullanıcıların talep ettiği özellik, vizyonunuza ve stratejinize katkıda bulunur.
• Bunu geliştirmeyi karşılayabilirsiniz. Bu özelliğin eklenmesi sürüm takvimini önemli ölçüde değiştirmeyecek ve şirketinizde bunu geliştirecek fazladan çalışanlarınız var.

Özellik fikrinizin bu üç ölçütü karşıladığını görüyorsanız, bu muhtemelen gerçekten önemli bir şeydir ve bunu görmezden gelmek sürüm sonrasında kötü bir kullanıcı deneyimine yol açacaktır. Dolayısıyla bunu kapsama eklemek uygundur.

Odağımızı kaybetmeden iyi fikirleri nasıl değerlendirebiliriz?

İyi fikirler her zaman yol haritanızı takip etmez. Sprintin ortasında, bir kahve sohbeti sırasında veya hiç de “kısa bir Slack mesajı” olmayan bir “kısa Slack mesajı” şeklinde ortaya çıkabilirler. Zorluk fikirleri durdurmak değil, yönümüzü kaybetmeden onları nasıl koruyacağımızı bilmektir.

Kapsamınızın kontrolden çıkmasına izin vermeden yeni fikirlere açık kalmanın yolu şu:

• Şimdilik uygun olmayan fikirler için bir yer belirleyin. Bir birikim sütunu, ekip dokümanı veya Notion panosu kullanın. Önemli olan bunun görünür olması, düzenli olarak gözden geçirilmesi ve fikir mezarlığı gibi görülmemesidir.
• Yalnızca depolamayı değil, önceliği de gösteren çerçeveler kullanın. Ürün ağaçları, Şimdi/Sonra/Daha Sonra panoları veya kademeli yol haritaları, ödünleşimleri görselleştirmeye yardımcı olur.
• Tepkisel değil, bilinçli bir şekilde gözden geçirin. Fikirleri yeniden değerlendirmek için düzenli zaman ayırın. Hangileri aciliyet kazanıyor, hangileri hâlâ ilgi çekici ancak faydalı değil, belirleyin.
• Paydaşlara nelerin dahil edildiğini ve nelerin beklemeye alındığını açıkça belirtin. Talebi kabul edin, nereye uyduğunu veya uymadığını açıklayın ve kayda geçirildiğinden emin olun.

Özetle: Her şeyin şimdi kullanıma sunulması gerekmez. Fikirleri panikle değil, özenle kayda geçirin. Gelecekteki yol haritanız size teşekkür edecek.

Sonuç: Vizyonu Duvar Değil, Filtre Olarak Kullanın

Özellik kapsamının kontrolsüz genişlemesi fikirlerle ilgili değildir; ödünleşimlerle ilgilidir. Bazı yeni talepler, sprintin ortasında bile buna değebilir. Ancak net bir vizyon ve etkiyi tartacak bir süreç olmadan, yalnızca gürültüye “evet” demiş olursunuz.

Yeni bir özellik gündeme geldiğinde yalnızca şunu sormayın:

“Bunu geliştirmeli miyiz?”

Şunu sorun:

“Bunu yaparsak ne geliştirilmeyecek?”

Gerçek maliyet budur.

SSS

Özellik kapsamının kontrolsüz genişlemesiyle ilişkili başka hangi terimler vardır?

Yaygın olarak ilişkilendirilen terimler arasında kapsam genişlemesi, özellik fabrikası tuzağı, gereksiz yazılım şişkinliği ve altın kaplama bulunur.

Özellik kapsamının kontrolsüz genişlemesi, özellik fabrikası tuzağıyla aynı şey midir?

Bunlar benzerdir ancak aynı sorunun farklı yönlerini ifade eder. Kapsam genişlemesi, özelliklerin sürüm kapsamına durmadan eklenmesidir. Özellik fabrikası tuzağı ise yeni özelliklerin KPI'ları iyileştirmek amacıyla eklendiği, ancak ürünü gereksiz yazılım şişkinliğine dönüştürdüğü durumdur.

Hangi ekip alışkanlıkları fark edilmeden özellik kapsamının kontrolsüz genişlemesine davetiye çıkarır?

• Sonuca değil, hacme göre sürüm yayınlamak
• Paydaşları memnun etmek için varsayılan olarak “evet” demek
• Yol haritası güncellemelerini vizyon değişiklikleriyle karıştırmak
• “Şimdi değil” diyebilecek bir sürece sahip olmamak

Sırada Ne Var

Daha fazla ürün yönetimi kaynağı ve rehberinin yanı sıra sektör liderleri ve uzmanlarından en güncel podcast'leri, röportajları ve diğer içgörüleri almak için bültenimize abone olmayı unutmayın.