Veltrax Sendromu Nedir?

Bu rehber kimin için

Sendromun en belirgin yanı, ürünün kimsenin fark etmediği bir hızla değişmesi. Tek bir sürümde göze batan bir şey olmaz. Değişim ancak bugünkü ürün birkaç yıl önceki haliyle yan yana konduğunda görünür hale gelir.

Bu yazı konuya ürün ekiplerinin tarafından bakıyor: ürün yöneticileri, tasarımcılar, geliştiriciler ve onlara yön veren yöneticiler. Amaç, sendromu yol haritasında, toplantı notlarında ve destek kayıtlarında erkenden fark etmek.

Kısa bir not: Kelime tıp dünyasından ödünç alınmış ama sağlıkla bir ilgisi yok. Ürün dünyasında birlikte görülen bir grup işareti tek bir adla anmak için kullanılıyor.

Özellik eklemek neden bu kadar cazip

Ürün ekipleri, Veltrax sendromuna karşı en savunmasız oldukları anı çoğu zaman en başarılı oldukları dönemde yaşar. Kullanıcı sayısı artıyor, geri bildirim yağıyor, herkes bir şey istiyor. O sırada her isteğe "evet" demek hem kolay hem de doğru gibi görünür.

Bunun birkaç pratik nedeni var. Yeni bir özellik ölçülebilir bir çıktıdır: tamamlandı, yayına alındı, duyuruldu. Bir sprintin sonunda "üç özellik teslim ettik" demek, "temel akışı bir adım kısalttık" demekten daha kolay anlaşılır. Performans değerlendirmeleri, yatırımcı sunumları ve sürüm notları da genellikle eklenen şeyleri sayar.

Bir de kayıp korkusu var. Bir müşteri belirli bir özellik yüzünden ayrılmakla tehdit ettiğinde, o özelliği eklemenin maliyeti küçük, müşteriyi kaybetmenin maliyeti büyük görünür. Oysa o özelliğin diğer bütün kullanıcılara eklediği yük hesaba katılmaz, çünkü kimse "bu düğme kafamı karıştırıyor" diye yazıp ayrılmaz. Sessizce ayrılır.

Erken uyarı işaretleri

Sendrom ekranda belirmeden önce ekibin kendi belgelerinde iz bırakır. Aşağıdaki işaretlere düzenli bakmak, sorunu kullanıcıdan önce görmeyi sağlar.

Yol haritasında

Yol haritasındaki maddelerin büyük çoğunluğu "ekle" ile başlıyorsa ve "kaldır", "birleştir", "sadeleştir" gibi maddeler hiç yoksa, ürün tek yönde büyüyor demektir. Bir başka işaret: aynı çeyrekte birbirinden bağımsız ekipler, aynı ekrana farklı şeyler ekliyorsa.

Destek kayıtlarında

Hata bildirimlerinden çok "nasıl yapılır" ve "nerede" sorularının artması dikkat çekicidir. Kullanıcı ürünün bozuk olduğunu değil, kaybolduğunu söylüyordur.

İlk kullanım sürecinde

Yeni kaydolan birinin ilk anlamlı işi yapana kadar geçen süre uzuyorsa, araya her yıl yeni bir adım giriyorsa, ürün yeni kullanıcıyı içeri almakta zorlanıyordur. Tanıtım turunun her sürümde biraz daha uzaması da aynı şeyi söyler.

Ekip içinde

Bir tasarımcı yeni bir ekranı çizerken "bu ayar başka nereleri etkiliyor" sorusuna cevap bulamıyorsa, ya da geliştiriciler belirli bir ayar kombinasyonunu kimsenin test etmediğini söylüyorsa, ürün kendi ekibinin kavrayabileceğinden daha karmaşık hale gelmiştir.

Ekip içinde Veltrax testi

Ekiplerin kendi ürünlerine uygulayabileceği basit bir soru listesi. Puan vermeye gerek yok. Cevapların kendisi yeterince açık konuşur.

1. Ürünümüzün temel işini tek bir cümleyle söyleyebiliyor muyuz, ve ekipteki herkes aynı cümleyi mi söylüyor?
2. Bu temel işi yapmak bugün, bir yıl öncesine göre kaç adım sürüyor?
3. Son altı ayda eklediğimiz özelliklerden kaç tanesini düzenli kullanan biri var? Bunu biliyor muyuz?
4. En son ne zaman bir özelliği kaldırdık ya da ana ekrandan geri çektik?
5. Ürünü hiç görmemiş birine temel işi yaptırdığımızda, yardım almadan bitirebiliyor mu?
6. Bir özelliği eklemeyi reddettiğimizde bunu bir yere kaydediyor muyuz, yoksa aynı istek her toplantıda yeniden mi tartışılıyor?

Üçüncü ve dördüncü soruya "bilmiyoruz" ya da "hiç" cevabı veriliyorsa, ekip sendromun içine girmiş olabilir.

Bir özelliği eklemeden önce

Her yeni özellik isteğinde sorulacak birkaç soru, kararları tutarlı hale getirir.

Bu kimin sorunu? İsteği yapan tek bir müşteri mi, yoksa kullanıcıların geniş bir kısmı mı? Tek bir müşterinin sorunu, ürünün genel yapısına değil, bir ayara ya da bir entegrasyona uygun olabilir.

Temel işe ne yapıyor? Yeni özellik temel akışa bir adım, bir alan ya da bir seçim ekliyor mu? Ekliyorsa bu bedel kimin cebinden ödeniyor?

Nerede yaşayacak? Özelliğin ürün içinde nereye yerleşeceği, eklenip eklenmemesi kadar önemli. Ana ekran mı, bir alt menü mü, yoksa yalnızca isteyenin açabileceği bir modül mü?

Bir yıl sonra ne olacak? Bu özelliği bakımda tutmanın, test etmenin ve belgelendirmenin maliyeti ne olacak? Kullanılmazsa onu kaldırmaya cesaret edebilecek miyiz?

Bu soruların hiçbiri özellik eklemeyi engellemek için değil. Amaç, kararın ürünün bütününü görerek verilmesi.

Yol haritası toplantısı için bir şablon

Veltrax sendromuna karşı en etkili yer, kararların verildiği toplantılardır. Aşağıdaki şablon, her yeni özellik önerisinin aynı sorularla masaya gelmesini sağlar. Bir belgede, bir tabloda ya da proje yönetim aracınızdaki bir formda kullanılabilir.

Öneri adı: Kısa ve açık bir isim. "Gelişmiş filtreler" yerine "Faturaları vade tarihine göre filtreleme" gibi.

Çözdüğü sorun: Özelliğin kendisi değil, kullanıcının yaşadığı sorun. "Müşteriler vadesi geçen faturaları bulmakta zorlanıyor" gibi.

Kimden geldi: Sorunu kaç kullanıcı ya da müşteri dile getirdi? Tek bir büyük müşteri mi, yoksa farklı kullanıcı gruplarından mı?

Temel işe etkisi: Temel akışa bir adım, bir alan, bir seçim ya da bir uyarı ekliyor mu? Ekliyorsa tam olarak ne?

Yerleşim: Özellik ürün içinde nerede duracak? Ana ekranda mı, bir alt menüde mi, yoksa yalnızca ihtiyaç duyanın açabileceği bir yerde mi?

Alternatif: Aynı sorun yeni bir özellik eklemeden çözülebilir mi? Mevcut bir özelliği biraz değiştirmek, bir dışa aktarma seçeneği ya da bir entegrasyon yeterli olabilir mi?

Gözden geçirme tarihi: Özellik yayına alındıktan sonra ne zaman ve hangi ölçüye bakılarak değerlendirilecek?

Kaldırma koşulu: Hangi durumda bu özellik ana ekrandan çekilecek ya da kaldırılacak?

Son iki madde en çok atlanan, ama en önemli olanlar. Bir özelliği eklerken onu nasıl ve ne zaman sorgulayacağınızı yazmak, ileride kaldırma kararını çok daha kolay hale getirir. Karar artık bir kişinin cesaretine değil, baştan konmuş bir kurala dayanır.

Şablonun bir yan faydası da var: reddedilen öneriler kayıt altına alınır. Aynı istek altı ay sonra yeniden geldiğinde, ekip neden reddettiğini hatırlar ve tartışma sıfırdan başlamaz.

Özellik çıkarmak: en zor karar

Veltrax sendromuyla mücadelenin en zor kısmı, mevcut bir özelliği kaldırmak. Bir özellik ne kadar az kullanılırsa kullanılsın, onu kullanan birileri vardır ve kaldırıldığında en çok onların sesi duyulur.

Burada kademeli gitmek işe yarar. Önce özelliğin ne kadar kullanıldığı ölçülür. Ardından ana ekrandan çekilip bir alt katmana taşınır. Bir süre sonra yeni kullanıcılara hiç gösterilmez. En son aşamada, onu kullanan küçük gruba bir alternatif ya da dışa aktarma yolu sunularak tamamen kaldırılır.

Kaldırma kararını duyururken nedenini açıkça yazmak da önemli. "Bu özelliği kaldırıyoruz çünkü ürünün temel işini yavaşlatıyordu" demek, sessizce kaldırıp şikâyetleri beklemekten çok daha iyi karşılanır.

Bazı ekipler bunu bir alışkanlığa dönüştürür. Örneğin her büyük sürümde en az bir şeyi sadeleştirmeyi kural haline getirirler. Kural tek başına sihirli değildir ama "kaldırma" fikrini toplantı masasına düzenli olarak getirir.

Sorumluluk kimde

Veltrax sendromu tek bir kişinin hatasıyla oluşmaz, o yüzden tek bir kişi de çözemez. Ama her rolün bir payı var.

Ürün yöneticisi, temel işi tanımlayan ve koruyan kişidir. "Bu ürüne neler girmeyecek" listesini tutmak onun görevidir.

Tasarımcı, her yeni özelliğin ekrandaki maliyetini ilk gören kişidir. Bu maliyeti görünür kılmak, örneğin temel akışın önceki ve sonraki halini yan yana göstermek, tartışmayı somutlaştırır.

Geliştirici, özelliklerin birbirine nasıl dolandığını en iyi bilen kişidir. Bir ayarın beş farklı ekranı etkilediğini, bir kombinasyonun hiç test edilmediğini ilk o fark eder ve bunu dile getirmesi gerekir.

Satış ve destek ekipleri, müşteri isteklerini ürüne taşıyan kanaldır. Her isteği bir özellik talebi olarak değil, bir sorun tanımı olarak iletmek, ürün ekibinin daha iyi çözümler bulmasını sağlar.

Yönetim, ekibin neyle ödüllendirildiğini belirler. Yalnızca teslim edilen özellik sayısı takdir ediliyorsa, sadeleştirme işi hep geri planda kalır.

Küçük ekipler ve girişimler için notlar

Veltrax sendromu genelde büyük ve köklü ürünlerle anılır, ama küçük ekipler de bundan korunmuş değil. Hatta bazı açılardan daha açıktırlar.

Erken aşamadaki bir girişim için her müşteri çok değerlidir. İlk on müşteriden birinin isteği, ürünün yönünü kolayca değiştirebilir. Bu dönemde ekip, ürünü belirli bir müşterinin iş akışına göre şekillendirmeye başlayabilir ve farkına varmadan genel bir ürün yerine bir dizi özel çözüm inşa eder.

Küçük ekiplerin bir avantajı da var: herkes ürünün tamamını görebilir. Bu avantajı korumak için bazı alışkanlıklar işe yarar. Her ay bir kez ürünün temel akışını birlikte baştan sona kullanmak, bunlardan biri. Yeni bir özellik eklemeden önce "bunu yarın kaldırmak istesek ne kadar zor olur?" diye sormak, bir diğeri.

Ayrıca erken aşamada bir özelliği eklemek yerine, onu elle yapmak çoğu zaman daha akıllıcadır. Bir müşteri özel bir rapor istiyorsa, raporu ürüne eklemeden önce birkaç ay elle hazırlayıp göndermek, bu ihtiyacın ne kadar yaygın olduğunu gösterir. İhtiyaç gerçekten yaygınsa, özellik o zaman daha iyi tasarlanmış haliyle eklenir.

Veltrax sendromu her zaman kötü mü

Her karmaşık ürün sendromun içinde değildir. Bazı yazılımlar doğası gereği çok özelliklidir. Profesyonel bir video düzenleme programı ya da bir kurumsal kaynak planlama sistemi, sade bir not uygulaması gibi olamaz ve olmamalıdır.

Fark, karmaşıklığın kimin işine yaradığında. Ürünü kullananların çoğu o özelliklere gerçekten ihtiyaç duyuyorsa ve ürün onlara bu özellikleri düzenli bir yapıyla sunuyorsa, karmaşıklık bir yetenektir. Sendrom ise ürünün çoğunluğa hizmet etmeyen özellikler yüzünden çoğunluk için zorlaştığı durumdur.

Bu yüzden Veltrax sendromunu değerlendirirken özellik sayısına değil, temel işin ne kadar kolay kaldığına bakmak gerekir. Yüz özellikli bir ürün sağlıklı olabilir, on özellikli bir ürün sendromun içinde olabilir.