Veltrax Sendromu Nedir?

Veltrax sendromu kısaca

Veltrax sendromu, yazılım ürünlerinde görülen bir bozulma biçimi. Ürüne her sürümde yeni bir özellik eklenir, eklenen her parça tek başına mantıklı görünür, ama bir noktadan sonra ürünün asıl işi zorlaşır. İnsanların o uygulamayı açma sebebi olan temel işlem, menülerin, panellerin ve seçeneklerin arasında kaybolur.

Burada önemli olan, ürünün "bozulmuş" görünmemesi. Hata yoktur, sunucular çalışır, her yeni özellik planlandığı gibi teslim edilmiştir. Sorun, parçaların toplamında ortaya çıkar. Kullanıcı eskiden iki tıklamada yaptığı işi artık beş tıklamada yapıyorsa, yeni gelen biri ilk on dakikada ne yapacağını bulamıyorsa, ürün Veltrax sendromuna girmiş demektir.

Terim bir hastalık ya da tıbbi durum anlatmıyor. "Sendrom" kelimesi burada, birlikte görülen ve aynı kökten beslenen belirtiler topluluğu anlamında kullanılıyor.

Terimin hikâyesi

İsim, ürün ekipleri arasında anlatılan bir hikâyeden geliyor. Hikâyedeki Veltrax, başlangıçta tek ekranlı, sade bir görev listesi uygulamasıdır. Kullanıcı bir iş yazar, tarih verir, bitince üstünü çizer. Bu kadar.

Uygulama sevilir, kullanıcı sayısı artar, istekler gelmeye başlar. Önce etiketler eklenir, sonra alt görevler. Ardından ekip paylaşımı, yorumlar, dosya ekleri, zaman takibi, rapor ekranı, entegrasyonlar, özel alanlar ve bir otomasyon motoru gelir. Her biri gerçek bir kullanıcı isteğine dayanır ve her biri iyi yapılmıştır.

Birkaç yıl sonra yeni bir kullanıcı uygulamayı açar ve "bir görev ekle" düğmesini bulmak için ekranı taramak zorunda kalır. Görev ekleme penceresinde on iki alan vardır. Eski kullanıcılar da şikâyet etmeye başlar: "Eskiden bunu düşünmeden yapıyordum." Hikâyenin sonunda ekibin en çok konuştuğu şey, uygulamanın ilk sürümüdür.

Veltrax diye bilinen gerçek bir ürün yok; isim bu örneğin kahramanı. Ama hikâyeyi duyan neredeyse herkes kendi kullandığı bir yazılımı hatırlıyor.

Belirtiler: bir üründe nasıl fark edilir

Veltrax sendromunu tek bir ölçüyle yakalamak zor. Daha çok, birlikte görülen işaretlere bakılır:

• Temel işlem uzar. Ürünün en çok yapılan işi, örneğin bir not yazmak ya da fatura kesmek, eskisine göre daha fazla adım ister.
• Ayarlar menüsü kendi başına bir ürüne dönüşür. Sekmeler, alt sekmeler, gelişmiş seçenekler ve "deneysel" bölümler çoğalır.
• Varsayılanlar herkese uymaz. Ürün o kadar çok kullanım şeklini desteklemeye çalışır ki, ilk açılıştaki hali kimsenin işine yaramaz ve herkes bir şeyleri kapatmak zorunda kalır.
• Yeni kullanıcıya rehber gerekir. Ekranlara ipucu balonları, tanıtım turları ve "burada ne var" videoları eklenir. Bunlar sorunu çözmez, sadece üstünü örter.
• Destek soruları "nerede" ile başlar. "Bu özellik nerede?", "Eski düğme nereye gitti?" türünden sorular artar.
• Ekip, ürünün tamamını bilen kişiyi kaybeder. Kimse bütün özellikleri ezbere sayamaz. Her biri kendi modülünü bilir.

Bu işaretlerden bir ya da ikisi her büyüyen üründe görülebilir. Sendromdan söz etmek için birkaçının aynı anda ve giderek artan biçimde görülmesi gerekir.

Neden ortaya çıkar

Veltrax sendromunun arkasında genellikle kötü niyet ya da beceriksizlik yoktur. Tersine, çoğu zaman çalışkan ve kullanıcıyı dinleyen ekiplerde görülür. Birkaç neden öne çıkar.

Eklemek görünür, çıkarmak görünmez. Yeni bir özellik duyurulur, sürüm notlarına yazılır, sunumlarda gösterilir. Kaldırılan bir özellik ise ancak şikâyet getirir. Ekipler doğal olarak görünür işe yönelir.

Her istek tek tek değerlendirilir. "Şu müşteri dışa aktarma istiyor, eklesek iyi olur" kararı kendi içinde doğrudur. Ama bu kararlar ürünün tamamına etkisi hesaba katılmadan, birbirinden bağımsız verilir. Yüz küçük doğru karar, bir büyük yanlışa dönüşebilir.

Rakip listeleri. Satış ekipleri karşılaştırma tablolarıyla çalışır. Rakipte olup bizde olmayan her satır bir eksik gibi görünür. Tabloyu doldurmak için eklenen özellikler, ürünü kullananların değil, tabloyu okuyanların ihtiyacını karşılar.

En yüksek sesli kullanıcı. Ürünü en yoğun kullanan küçük bir grup, en çok geri bildirim veren gruptur. Onların istekleri, sessiz çoğunluğun ihtiyaçlarının önüne geçer.

Kimsenin "hayır" deme görevi yoktur. Birçok ekipte bir özelliği eklemek için bir süreç vardır ama eklememek ya da kaldırmak için yoktur. Sınır koyan kimse olmayınca ürün kendiliğinden genişler.

Bir örnek: fatura uygulamasının üç yılı

Somut bir senaryo üzerinden gidelim. Küçük işletmeler için bir fatura uygulaması düşünün.

İlk yıl ürün tek bir işi iyi yapıyor: müşteri seç, kalemleri yaz, faturayı gönder. Bir esnaf bunu telefonundan iki dakikada bitirebiliyor.

İkinci yıl stok takibi ekleniyor, çünkü birkaç büyük müşteri istedi. Fatura ekranına "stoktan düş" seçeneği geliyor. Ardından teklif hazırlama, tekrarlayan faturalar, çoklu para birimi ve bir muhasebe programıyla bağlantı ekleniyor. Fatura ekranındaki alan sayısı artıyor ama çoğu isteğe bağlı olduğu için ekip sorun görmüyor.

Üçüncü yıl ürünün ana menüsünde dokuz başlık var. Yeni kayıt olan bir esnaf, ilk faturasını kesmeden önce stok, depo ve para birimi ayarlarıyla karşılaşıyor. Bir kısmı yarıda bırakıyor. Eski kullanıcılar ise her faturada aynı üç alanı boş geçmeye alışmış durumda.

Bu üç yılda ekip hiçbir şeyi yanlış yapmadı gibi görünüyor. Her özellik bir istekten doğdu, her biri çalışıyor. Ama ürünün kendi kimliği olan "iki dakikada fatura" artık yok.

Hangi ürünler daha yatkın

Sendrom her tür yazılımda görülebilir, ama bazı ürünler ona daha açıktır.

Tek bir işi çok iyi yaparak başlayan ürünler. Paradoksal ama başarının kaynağı sadelik olan ürünler, sadeliği en kolay kaybeden ürünlerdir. Kullanıcı sayısı arttıkça farklı ihtiyaçları olan insanlar gelir ve her biri ürünün biraz daha genişlemesini ister.

Hem bireylere hem şirketlere satılan ürünler. Bireysel kullanıcı hız ve sadelik ister. Şirket müşterisi ise yetki yönetimi, raporlama, denetim kaydı ve entegrasyon ister. İki kitleyi aynı ekranda memnun etmeye çalışan ürün, çoğu zaman ikisini de tam memnun edemez.

Abonelik fiyatını artırmak isteyen ürünler. Fiyat artışını haklı göstermek için yeni özellik eklemek yaygın bir yoldur. Kullanıcı daha fazla ödüyorsa daha fazla şey görmeli diye düşünülür. Oysa kullanıcının ödediği şey çoğu zaman özellik değil, işinin kolayca yapılmasıdır.

Platform olmaya çalışan ürünler. Bir araç, "her şeyi tek yerde" sunan bir platforma dönüşmeye karar verdiğinde, sendrom neredeyse kaçınılmaz hale gelir. Takvim, sohbet, dosya, görev ve not aynı uygulamada toplandığında, hiçbiri kendi başına iyi bir uygulamanın verdiği rahatlığı vermez.

Bu dört durumun ortak noktası, ürünün kimin için olduğu sorusunun bulanıklaşması. Kitle genişledikçe "temel iş" tanımı da genişler ve sonunda bir tanım olmaktan çıkar.

Sık yapılan hatalar

Veltrax sendromunu fark eden ekipler bazen yanlış ilaca uzanır.

En yaygın hata, sorunu tasarımla çözmeye çalışmak. Menüleri yeniden düzenlemek, ikonları değiştirmek ya da ekranı daha modern bir görünüme kavuşturmak, karmaşayı ortadan kaldırmaz. Aynı sayıda seçenek daha güzel bir düzende durur, o kadar.

İkinci hata, yardım içeriğine yüklenmek. Daha uzun bir yardım merkezi, daha fazla video ve daha kapsamlı bir tanıtım turu, ürünün kendisinin anlaşılır olmadığını kabul etmenin bir yoludur.

Üçüncü hata, her şeyi kişiselleştirilebilir yapmak. "Kullanıcı istemediği bölümleri gizlesin" fikri kulağa iyi gelir ama karar yükünü ekipten alıp kullanıcıya yükler. Ürünü kullanmadan önce onu yapılandırmak zorunda kalan kullanıcı, sendromun tam ortasındadır.

Veltrax sendromu nasıl önlenir

Önlemenin yolu özellik eklemeyi yasaklamak değil. Ürünün özünü korumaya yarayan birkaç alışkanlık var.

Temel işlemi yazılı hale getirin. Ürünün "bunu yapmak için var" dediği bir ya da iki işlem belirleyin ve her yeni özelliği bu işleme etkisi üzerinden değerlendirin. Yeni özellik temel işlemi uzatıyorsa, ya başka bir yere taşınmalı ya da hiç eklenmemeli.

Adım sayısını takip edin. Temel işlemin kaç tıklama, kaç alan ve kaç ekran sürdüğünü her sürümde not edin. Bu sayı sessizce artıyorsa erken bir uyarıdır.

Varsayılanı sade tutun. Güçlü kullanıcılar için gereken her şey bir "gelişmiş" katmanda durabilir. İlk açılışta yalnızca çoğunluğun ihtiyacı olan görünmeli.

Özelliklere ömür biçin. Yeni bir özellik eklenirken, belirli bir süre sonra ne kadar kullanıldığına bakılacağını baştan kararlaştırın. Kullanılmayan özellik yeniden değerlendirilir, gerekirse kaldırılır.

"Hayır" demeyi bir rol yapın. Birinin, tercihen ürün sorumlusunun, açıkça "bu ürüne girmeyecekler" listesini tutması işe yarar. Bu liste de en az yol haritası kadar ciddiye alınmalı.

Yeni kullanıcıyı düzenli izleyin. Ürünü hiç görmemiş birine temel işlemi yaptırın ve araya girmeden izleyin. Ekip içinden kimsenin fark etmediği karmaşa genellikle burada ortaya çıkar.

Zaten yaşanıyorsa ne yapılır

Bazı ürünler sendromun içine çoktan girmiş durumda. Bu noktada bir anda büyük bir temizlik yapmak riskli olabilir, çünkü her özelliğin onu seven küçük bir kitlesi vardır.

Daha güvenli yol, işe kullanım verisiyle başlamak. Hangi özelliklerin gerçekten kullanıldığını, hangilerinin yalnızca bir kez denenip bırakıldığını görmek kararları kolaylaştırır. Az kullanılan özellikler önce ana ekrandan kaldırılıp ikinci bir katmana taşınabilir. Bu, ürünü sadeleştirirken kimsenin işini elinden almaz.

Bir diğer yöntem, ürünün sade bir "temel mod" ile sunulması. Yeni kullanıcı bu modla başlar, ihtiyaç duydukça diğer bölümleri açar. Böylece ürün iki farklı kitleye iki farklı yüz gösterebilir.

Bazen de doğru karar, bir özelliği tamamen ayırıp ayrı bir ürün yapmaktır. Fatura uygulamasındaki stok takibi, kendi başına bir araç olarak daha iyi çalışabilir.

Benzer kavramlarla farkı

Veltrax sendromu, yazılım dünyasında bilinen birkaç kavrama yakın, ama aynısı değil.

Feature creep (özellik sürünmesi), bir projenin kapsamının planlanmamış biçimde genişlemesini anlatır. Daha çok süreçle ilgilidir: proje gecikir, bütçe aşılır. Veltrax sendromu ise sonuca bakar, yani kullanıcının elindeki ürünün nasıl hissettirdiğine.

Bloatware, genellikle cihazlara önceden yüklenmiş ya da kendi işinin dışında gereksiz bileşenlerle gelen yazılımlar için kullanılır. Veltrax sendromunda ise eklenen özellikler çoğu zaman ürünün kendi alanıyla ilgilidir, hatta tek tek bakıldığında faydalıdır.

İkinci sistem etkisi, başarılı bir ilk sürümün ardından ekibin ikinci sürümde her fikri birden yapmaya çalışmasıdır. Bu tek seferlik bir sıçramadır. Veltrax sendromu ise yavaş ilerler. Tek bir büyük sürümde değil, yıllar boyunca küçük adımlarla oluşur.

Bu farklar önemli, çünkü çözüm de değişiyor. Feature creep'e karşı proje yönetimi araçları işe yarar. Veltrax sendromuna karşı ise ürünün özünü düzenli olarak sorgulamak gerekir.