Özellik taleplerinin faydaları veya kullanmadığınız şeyler için ödeme yapmayı nasıl durduracağınız

Üreticilerin blok zincirine tırnak törpüsünden penseye kadar maksimum sayıda alet eklediği bir İsviçre bıçağı hayal edin.
Bunların kaç tanesi gerçekte kullanılacak? Müşteriler, tek işi yer kaplamak ve ceplerini boşaltmak olan diğer aletler için ödeme yapmaya istekli mi? Bu anlamda, bazı kurumsal düzeydeki uygulamalar bir küp içindeki İsviçre bıçakları gibidir. Üreticiler, müşterilerin gerçek ihtiyaçlarını dikkate almadan, onları çılgın bir fazlalıkla mümkün olan her işlevle doldururlar. Bu makalede, gereksiz işlevselliğin kullanıcılar için neden dezavantajlı olduğunu ve bundan nasıl kaçınılacağını anlatacağız.

Kurumsal çözümleri kullanan tüketicilerin %90’ı bu çözümlerin yeteneklerinin yalnızca %5’ini kullanıyor

Kurumsal düzeydeki ürünlerle ilgili sorun, geliştiricilerin bunlara eklediği çok sayıda gereksiz özelliktir. Her çözüm düzenli güncellemelere ihtiyaç duyduğundan, hedef kitlenin küçük bir bölümüne yönelik daha fazla özellik eklerler.

Aynı zamanda, kurumsal düzeydeki ürünler karmaşık kod tabanı, yüksek güvenilirlik gereksinimleri, uzun geliştirme süresi ve uzun kullanım süresi ile karakterize edilir. Bu nedenle, üreticileri geliştirmedeki mevcut trendlere ayak uydurmaya çalışmazlar, ancak istikrara güvenirler. Genellikle bu tür ürünlerin geliştiricileri kullanıcıların gerçek ihtiyaçlarını bilmezler, çünkü gerçek tüketicilerden gelen ek işlevsellik taleplerini dikkate almazlar.

Sonuç olarak, sadece gereksiz işlevsellik değil, kullanıcıların yalnızca %1-5’inin ihtiyaç duyduğu bir dizi özellik vardır. Örneğin, Amerikan devi VMware’in çözümü, çoğu sıradan tüketiciler tarafından kullanılmayan devasa bir özellik yapıcısıdır. Ve kullanıcıların yaklaşık %90’ı platformun özelliklerinin yalnızca %5’ine ihtiyaç duymaktadır.

Parkinson yasası artı Moore yasası

Parkinson Kanunu’na göre herhangi bir faaliyet ne kadar zaman alırsa o kadar sürer. Benzer şekilde, kurumsal düzeydeki yazılımlar, sağlanan tüm kaynakları kullanana kadar özellikleri artırabilir.

Moore Yasası uzun bir süre Parkinson Yasası ile paralellik göstermiştir. Moore Yasası’na göre her iki yılda bir çiplerdeki transistör sayısı iki katına çıkıyordu. Bu, yazılım üreticilerinin yeterli performans olup olmadığını düşünmek zorunda olmadıkları anlamına geliyordu. Bu yüzden donanımın yeteneklerine bakmadan daha fazla özellik eklediler. Ancak Moore Yasası artık işlemiyor. Bu arada, büyük satıcılar gereksiz işlevselliğe sahip yazılımları piyasaya sürmeye devam ediyor. Bunun birkaç nedeni olabilir:

• Müşterilerden gelen ek işlevsellik taleplerinin ele alınmaması nedeniyle, geliştirici müşterilerinin çoğunun gerçek ihtiyaçlarını bilmiyor;
• müşteriler çok farklıdır ve her birinin farklı işlevlere ihtiyacı vardır;
• Satıcı için, uygulamada zaten olmayan herhangi bir işlevsellik ekleyerek düzenli güncellemeler yayınlaması önemlidir.

Gereksiz işlevselliğin nesi yanlış

Görünüşe göre çok şey az değil. Gelecekte ihtiyaç duyulabilecek bazı gereksiz işlevler içeren bir ürünün nesi yanlış? Gereksiz işlevsellikten kaçınmak için çeşitli nedenler vardır.

Birincisi, bu tür ürünlerin kullanımı ve anlaşılması daha zordur. Çok sayıda fonksiyonla çalışmak için birkaç üst düzey uzman gerekir. Ayrıca, gereksiz işlevlere sahip bir program hafifliğini kaybeder. Çalıştırması daha zordur, daha fazla kaynağa ihtiyaç duyar ve böyle bir çözümün fiyatı analoglardan daha yüksek olacaktır. Aynı zamanda, müşteriler asla veya neredeyse hiç kullanmayacakları özellikler için para öderler.

Çözüm YAGNI ve yeni özellikler eklenmesi talep ediliyor

“Yalnızca gerçekten ihtiyacınız olan özellikleri uygulayın, gelecekte ihtiyaç duyacaklarınızı değil.”
Ron Jeffries, Extreme Programming and the Agile Manifesto kitabının ortak yazarı

Gereksiz işlevsellik uygulama sorununa yanıt olarak YAGNI kavramı doğdu. Bu kısaltmanın açılımı You ain’t gonna need it (Buna ihtiyacınız olmayacak) ya da You won’t need it (Buna ihtiyacınız olmayacak) şeklindedir. YAGNI ilkesinin temelinde, yazılım geliştirmede gereksiz işlevselliğin ürünün temel değerlerinden biri olarak reddedilmesi yatmaktadır. Geliştirici, ürüne yalnızca gerçekten ihtiyaç duyulan özellikleri ekler.

Tüketiciler için hangi işlevselliğin uygun olacağını anlamanın basit bir yolu, yeni özellikler ekleme taleplerini işlemektir.

Örneğin, projemizde çözümün basitliği ve hafifliği üzerinde durduk. Kullanıcılar şu ya da bu özelliğe ihtiyaç duyup duymadıklarına kendileri karar veriyor. İhtiyaç duydukları özellikler etkinleştirilebilir ve ihtiyaç duymadıkları özellikler etkinleştirilemez. Tüm paket için değil, yalnızca gerçekten kullandığınız özellikler için ücretlendirileceksiniz. Bir müşteri bazı ekstra işlevlere ihtiyaç duyarsa, yeni bir işlev eklemek için talepte bulunabilir ve bunu bireysel olarak alabilir.

Bu yaklaşım, şirketin kullanılmayan özelliklerden tasarruf etmesini ve yine de ihtiyaç duydukları tüm işlevselliği elde etmesini sağlar.