Bir özelliğin tasarlanıp programlanıp dağıtılmasının her zamankinden daha hızlı olduğu bir dünyada, en büyük sorun artık oluşturma hızı olmaktan çıkıyor. Asıl sorun, gerçekten neyi yaratmanın değerli olduğuna karar vermektir.
Neredeyse her geliştirilen sistemin hayatında, özellikler listesi kendi başına yaşamaya başlar.
"Müşteri bunu sormuştu."
"Rakip bunu yapıyor."
"Bu sanırım zor olmamalı."
"Bu modül zaten varsa, şu da ekleyelim..."
"YZ bunu hızlıca yapar."
Ve bir anda yeni bir özellik backlog’a eklenir. Sonra bir diğeri. Ve bir diğeri. Birkaç yıl sonra şirket neredeyse her şeyi yapabilen bir uygulamaya sahip olur. Ancak kullanıcı, gerçekte neye ihtiyacı olduğunu bulmakta giderek daha fazla zorlanır.
Bu yalnızca bir UX sorunu değil. Bu bir iş sorunudur.
Daha fazla özellik neden daha iyi ürün anlamına gelmeyi bırakır
Yazılım geliştirme yıllarca oldukça basit bir mantığa dayanıyordu: kullanıcılar yeni yeteneklere ihtiyaç duyuyorsa, yeni özellikler ekleriz. Mantıklı geliyor.
Sorun, ürün geliştirme sürecinin teslim edilen özellik sayısına indirgenmeye başladığı anda başlar. O zaman ekip, kullanıcıya sağlanan değere göre değil, "teslim edilebilen" şeylerin sayısına göre optimize etmeye başlar.
Böylece sözde Feature Factory ortaya çıkar — ardı ardına özellik üreten ama bu özelliklerin gerçekten müşterilerin problemlerini çözüp çözmediğini ölçmeyen bir organizasyon.
Bu olgu yeni değil. Yeni olan, bugünün gelişim hızıdır.
YZ, fikirden çalışan bir prototipe giden yolu önemli ölçüde kısaltıyor. Atlassian bu değişimi açıkça tanımlıyor: geliştirici ajanlarla birlikte "ne inşa etmek istediğimizi biliyoruz" ile çalışan bir prototip arasındaki yol haftalardan saatlere inebilir.
Bu büyük bir fırsat. Ama aynı zamanda bir tuzak.
Çünkü inşa etmek ucuzlayıp hızlandıkça, daha önce kimsenin sipariş etmeye cesaret edemeyeceği şeyleri inşa etmek daha kolay hale gelir.
"Yapabiliyorsak, yapalım"
Bu, BT projelerindeki en pahalı cümlelerden biridir. Çünkü her ek özellik bir servet harcadığı için değil. Sorun, bir özelliğin yaşamının dağıtıma ulaştığı anda bitmemesidir.
Her yeni modülün daha sonra bakımı yapılmalıdır. Test edilmelidir. Gelecek değişikliklerde dikkate alınmalıdır. Davranışı dokümante edilmelidir. Hataları yönetilmelidir. Kullanıcılar eğitilmelidir. UX içinde hesaba katılmalıdır. Güvenliği sağlanmalıdır. Sistem içindeki diğer değişikliklerin bir şeyi bozup bozmadığı kontrol edilmelidir.
Bu yüzden bir özelliğin maliyeti yalnızca onu yaratmanın maliyeti değildir. Aynı zamanda gelecekte var olma maliyetidir.
Ve işte bu maliyet çoğu zaman şu cümle söylendiğinde görünmez:
"Şunu da ekleyelim..."
En pahalı özellik, kimsenin kullanmadığı özellik olabilir
Bir B2B paneli geliştiren bir şirket hayal edin.
Müşteriler sipariş verebiliyor, satın alma geçmişini görebiliyor, belgeleri indirebiliyor ve hesap yöneticisiyle iletişim kurabiliyor.
Gelişmiş bir raporlama sistemi fikri ortaya çıkıyor. Ekip tasarlıyor. Geliştiriciler inşa ediyor. Grafikler, filtreler, dışa aktarımlar, özetler ve birçok ek parametre oluşuyor. Özellik üretime gidiyor.
Ve sonra ortaya çıkıyor ki müşterilerin çoğu sadece bilmek istiyor: ne kadar aldım, neler yolda ve fiyat nedir.
Geri kalan varsayımdı. İhtiyaçları yoktu. Bu önemli bir farktır.
Müşteri bir özellik isteyebilir. Bu, isteğin gerçekten problemini çözecek olanın o özellik olduğu anlamına gelmez.
"Rakip bunu yapıyor"
Bu da diğer klasik bahane.
Firma rakibi inceler. Yeni bir modül görür.
Ve başlar: "Biz de buna sahip olmalıyız."
Oysa rakibin tamamen farklı bir iş modeli, farklı müşteri grubu, farklı satış süreçleri ve farklı ürün stratejisi olabilir.
Bir sistemde anlamlı olan bir özellik, başka bir sistemde tamamen gereksiz olabilir.
Bu, özellikle sipariş üzerine oluşturulan projelerde çok önemlidir. Her uygulamayı iyi yapacak evrensel bir özellik seti yoktur.
Endüstriyel bir üretici için tasarlanan bir sistem, bir eğitim şirketi için tasarlanan bir platformla aynı şekilde tasarlanmamalıdır.
Satış elemanları için bir CRM, sabit müşteriler için bir B2B paneli gibi çalışmamalıdır.
Premium ürün satan bir e-ticaret sitesi, ana argümanı fiyat olan bir mağazadan tamamen farklı bir alışveriş deneyimine ihtiyaç duyabilir.
Yazılım, rekabetin özellik kataloğundan değil, iş modelinden kaynaklanmalıdır.
Burada YZ gerçekten çok şeyi değiştiriyor
Ve bu yüzden bugün bu konu özellikle ilgi çekici.
Birkaç yıl öncesine kadar yeni bir özellik fikri, kullanıcının görebilmesi için birçok aşamadan geçmek zorundaydı.
Analiz.
Tasarım.
UX.
Geliştirme.
Testler.
Dağıtım.
Bugün bu aşamaların bir kısmı YZ ile önemli ölçüde hızlandırılabiliyor. Prototip daha hızlı oluşturulabiliyor. Arayüz daha hızlı hazırlanabiliyor. Kod daha hızlı yazılabiliyor. Testler daha hızlı üretilebiliyor. Veriler daha hızlı analiz edilebiliyor.
Ve bu yüzden geliştirme hızının tek başına bir avantaj olmaktan çıktığını söyleyebiliriz.
Eğer herkes bir şeyi daha hızlı inşa edebiliyorsa, avantaj onu neyi inşa edeceğini daha iyi seçen tarafın olur.
Atlassian’ın ürün yönetiminin geleceğine dair çalışması bu paradoksu vurguluyor: YZ iş hızını artırıyor ama hızın artması tek başına daha iyi ürünler demek değil. Aynı zamanda Atlassian tarafından ankete katılan yöneticilerin %89'u YZ sayesinde iş hızında artış bildirmişken, yalnızca %6'sı YZ'nin organizasyon çapında belirli bir YG'ye (ROI) güvenle işaret edebiliyordu.
Bu, daha hızlı yapmak ile daha iyi sonuç elde etmek arasındaki farkı çok iyi gösteriyor.
Önce problem. Sonra özellik
İyi bir ürün süreci şu soruyla başlamalıdır: Hangi problemi çözmeye çalışıyoruz?
Değil: "Hangi özelliği eklemeliyiz?"
Bu ufak fark gibi görünse de pratikte her şeyi değiştirir.
Müşteri derse: "Mobil bir uygulamaya ihtiyacımız var",
sormaya değer soru: Neden?
Gerçekten bir uygulamaya ihtiyaç duyuyor olabilir. Ama belki sorun telefonda panele rahat erişim eksikliğidir. Belki iyi tasarlanmış bir responsive arayüz yeterlidir. Belki PWA yeter. Belki sadece bir süreç için mobil bir modül gerekir. Ya da belki uygulamaya ihtiyaç var ama başlangıçta belirtilen nedenlerden hiçbiri gerçek nedeni yansıtmaz.
Aynı şekilde özelliklerle de işler böyle yürür.
"Otomatik raporlara ihtiyacımız var." — Neden?
"Satış ekibi zaman kaybediyor." — Ne üzerinde?
"Sistemdeki verileri kopyala-yapıştır yapıyorlar."
Bir anda sorunun rapor eksikliği değil, entegrasyon eksikliği olduğu ortaya çıkabilir.
İyi bir analiz, aylarca sürecek geliştirmeden tasarruf ettirebilir.
Bazen en iyi özellik, özelliğin olmamasıdır
Bu paradoksal geliyor ama deneyimli bir teknoloji ortağının rolü tam da bu olmalıdır.
Sadece uygulamak değil; gerekliyse varsayımları sorgulamak da.
Müşteri yirmi özellikten oluşan bir listeyle geliyorsa, yazılım evi bunu otomatik olarak taşlı yazılmış bir teknik şartname olarak görmemelidir.
Sormalıdır: Bu özelliklerin hangileri gerçek bir problemi çözüyor? Hangileri kritik? Hangileri satışı artırıyor? Hangileri işi kısaltıyor? Hangileri müşteri hizmetini iyileştiriyor? Hangileri yasal veya operasyonel olarak gerekli? Hangileri sadece "güzel bir ek"?
Ve en önemlisi: Bu özelliğin başarılı olduğunu nasıl anlayacağız?
Bu son soru olmadan kolayca sürekli büyüyen fakat gerçekten daha iyi olup olmadığı asla bilinmeyen bir ürün yaratılabilir.
Ürün "hayır" demeyi öğrenmeli
İyi bir ürün geliştirmede inşa edilecekler listesinden en az önemli olan, inşa etmeyeceklerimiz listesidir. Bu cesaret ister.
Çünkü söylemesi kolaydır: "Evet, yaparız."
Söylemesi zor olan: "Elimizdeki bilgilerle bunun için ödeme yapılmasını gerektirecek bir neden görmüyoruz."
Bunu fikriyle gelen bir müşteriye söylemek daha da zordur.
Ama işte o zaman gerçek partnerlik başlar.
Yazılım evi sadece komutları koda çeviren bir ekip olmamalıdır. Müşterinin teknolojik kararlar almasına yardımcı olmalıdır.
Bazen bu bir özelliği tasarlamak anlamına gelir.
Bazen onu basitleştirmek anlamına gelir.
Bazen başka bir çözüme dönüştürmek anlamına gelir.
Ve bazen fikrinden tamamen vazgeçmek anlamına gelir.
Hangi özellik muhtemelen gereksizdir nasıl anlarsınız?
Tek bir sihir testi yok ama birkaç soru coşkuyu hızla söndürebilir.
Bunu kim özellikle kullanacak?
Cevap "herkes" ise, netleştirmek gerekir.
Hangi problemi çözüyoruz?
Cevap "daha kolay olacak" ise, muhtemelen daha fazla analiz gerekir.
Kullanıcı bunu ne sıklıkla kullanacak?
Yılda bir mi? Ayda bir mi? Her gün mü?
Aynı problemi çözmenin daha basit bir yolu var mı?
Bu soru özellikle önemlidir.
Etkiyi nasıl ölçeceğiz?
Daha fazla satış mı? Daha az iş mi? Daha kısa süreç mi? Daha az hata mı? Daha yüksek korunma (retention) mı?
Eğer bu özelliği inşa etmezsek ne olur?
Cevap "aslında hiçbir şey" ise, belki de inşa edilmemesi gereken bir özellik bulmuşuzdur.
Her kullanıcı isteği backlog’a gitmemeli
Bu aynı zamanda önemli bir zihniyet değişimidir.
Kullanıcı geri bildirimi paha biçilmezdir. Ancak geri bildirim otomatik olarak ürünün şartnamesi değildir.
Kullanıcı kendi deneyimi perspektifinden probleminden bahseder.
Belki "X butonuna ihtiyacım var" der.
Ürün ekibinin rolü, körü körüne X butonunu yapmak değil.
Ekipin rolü: kullanıcının neden buna ihtiyaç duyduğunu anlamak.
Ancak o zaman en iyi çözümün gerçekten X butonu olup olmadığına karar verilebilir.
Belki otomasyon en iyi çözümdür.
Belki entegrasyon.
Belki süreçte değişiklik.
Belki daha iyi bir arayüz.
Belki kullanıcı eğitimi.
Ve bazen gerçekten yeni bir özellik gerekir.
İşte bu, feature delivery ile product development arasındaki farktır.
Veriler de "kaldıralım" diyebilir
Ürün geliştirme sadece eklemekle bitmemelidir.
Aynı zamanda mevcut olanı da gözden geçirmek gerekir.
Hangi özellikler kullanılıyor?
Hangileri yok sayılıyor?
Kullanıcılar nerede kopuyor?
Hangi süreçler en çok zaman alıyor?
Hangi öğeler destek taleplerinin çoğunu üretiyor?
Hangi özellikler dönüşümü artırıyor?
Hangileri sadece arayüzü karmaşıklaştırıyor?
Bazen en iyi geliştirme projesi yeni bir modül eklemek değil, üç gereksiz özelliği kaldırmaktır. Bu, bir aydan fazla geliştirmeden daha fazla UX iyileştirebilir.
YZ burada da yardımcı olabilir
İlginçtir ki, YZ sadece özellik oluşturmak için kullanılmak zorunda değildir.
Aynı zamanda özelliklerin mantıklı olup olmadığını analiz etmeye de yardımcı olabilir.
Kullanıcı geri bildirimlerini analiz edebilir.
Şikayetleri gruplayabilir.
Tekrarlayan problemleri tespit edebilir.
Destek verilerinden analizler çıkarabilir.
Müşteri görüşmelerini özetleyebilir.
Ekiplerin hipotezleri karşılaştırmasına yardımcı olabilir.
Çözüm varyantları hazırlayabilir.
Kullanıcı davranışı analizini destekleyebilir.
Yani paradoksal olarak, ürün geliştirmede YZ’nin en iyi kullanımı bazen onun sayesinde daha hızlı yeni bir özellik inşa etmek değil, daha hızlı keşfetmek olabilir: aslında o özelliği inşa etmememiz gerektiğini.
Web24: önce "niçin?" diye soruyoruz
Her yazılım projesi bir ihtiyaçla başlar.
Bazen müşteri tam olarak neye ihtiyaç duyduğunu bilir.
Bazen zaten hazır bir şartnameyle gelir.
Bazen sadece bir sorunla gelir: "Bu süreç bize günde üç saat alıyor."
Ve bu çok iyi bir başlangıç noktasıdır.
Çünkü o zaman önerilen çözümü nasıl kodlayacağımıza değil, problemi en iyi nasıl çözeceğimize odaklanabiliriz.
Bu, özel yazılım oluşturmayı hazır bileşenlerden bir ürün birleştirmekten ayıran şeydir.
Web24’te amaç her uygulamanın mümkün olduğunca çok özelliğe sahip olması değildir.
Amaç, her işletme için gerçekte ihtiyaç duyulan özelliklere sahip olmasıdır.
Bu yüzden iki benzer sistem tamamen farklı görünebilir ve çalışabilir.
Çünkü süreçleri farklıdır.
Kullanıcıları farklıdır.
Hedefleri farklıdır.
Satış yöntemleri farklıdır.
Müşteri hizmeti yöntemleri farklıdır.
Ve yazılımın çözmesi gereken problem farklıdır.
Sorgulanmayan backlog en pahalı olandır
YZ dünyasında yazılım geliştirme gerçekten ilginç bir evreye girebilir.
Teknoloji "Nasıl inşa edebiliriz?" sorusuna giderek daha iyi cevap verecek.
İnsanın ise giderek daha iyi cevaplaması gerekecek: "Bunu gerçekten inşa etmeli miyiz?"
Bu, yazılım yaratımında en önemli değişikliklerden biri olabilir.
Çünkü bir sonraki özelliğin maliyeti ve yapılma süresi düşerse, onu ekleme cazibesi artar.
Ve bununla birlikte ürün keşfi, UX, veri analizi, kullanıcı görüşmeleri ve stratejik ürün yönetiminin önemi artar. Gartner, YZ destekli hızlı ürün geliştirme temposunun, teknolojik hız ürün yönetimiyle eşleşmediğinde stratejik uyumsuzluklara ve artan teknik borca yol açabileceğine dikkat çekiyor.
Bu yüzden gelecek yalnızca daha hızlı inşa edebilen firmalara ait olmayacak; aynı zamanda ne inşa edileceğini daha iyi seçebilenlere de ait olacak.
Çünkü bazen en iyi teknoloji kararı şu cümleyle bitmez: "Bir işlev daha ekleyelim."
Bunun yerine: "Önce gerçekten buna ihtiyacımız olup olmadığını test edelim."
