Detaylarda boğulmamak gerekiyormuş!

Yakın zamanda edinilmiş bir tecrübenin kaleme alınmasını içerir.

Kitapların ne kadar önemli olduğunu da hem Medium yazılarımda hem de çevremde oldukça sık sık dile getiririm.

Ancak “Tecrübe kitaptan okunmaz!” sözünü hepimiz duymuşuzdur. Geçenlerde bunun birebir örneğini yaşayıp, bu sözün değerini tekrardan farkına vardım.

Oppaze üzerine yazılım ve operasyon çalışmalarımız yaklaşık 1 senedir devam ederken, son zamanlarda oldukça detay ayrıntılar çıkmaya başladı ve bu ayrıntılar belirli bir zaman kaybıda yarattı açıkçası. Ancak bu zaman kaybı, psikolojik bir zaman kaybıydı.

Sürecin en başında olmasa da, belli bir süre sonra, operasyonu şu 2 temel üzerinde götürmeye gayret ediyoruz.

1- Bir pazaryerinin operasyonel mükemmelliği ve

2- Dropshipping’e karşı Türkiye’de ki olumsuz algı.

Artık 2000' lerde ki internet dünyasında yaşamıyoruz. Hangi proje veya web tabanlı girişim olursa olsun, operasyonel işlemler olarak mükemmelliği yakalamak gerekiyor. Çünkü insanlar, internetin sınırsız hızına erişir durumda, odakları ve sabırları da bu paralelde oldukça düşük seviyede.

Günümüzde bir web sitesi 5 saniye içerisinde (hatta bazen daha kısa) işlevini yerine getirmezse, alternatif başka web sitelerine yönelim ve müşteri kaybı çok hızlı olmakta. Burada bir MVP model mantığına düşmek hata olabilir çoğu girişim için.

İkinci durumda ise bizi ve Oppaze’ yi etkileyecek bir durum mevcut. Türkiye ekosisteminde o kadar fazla Dropshipping çatısı altında insanlar dolandırıldı ki, büyük bir olumsuz algı insanların zihnine yerleşti.

Oppaze’ nin tavuk yumurta vb. problemler dışında bir de bu sorunu mevcut. Bunun içinde hiçbir güvensizlik (normalde güvensiz görünmeyecek bir alan olsa bile) yaratacak alanın bulunmaması gerekiyor ki, insanlar Oppaze ile diğer dolandırıcıları algılarında farklı konumlandırabilsinler. Tasarımlar, detaylar ve işbirliklerimiz bu nedenle diğer projelere kıyasla daha titizlikle hazırlanıyor.

Şimdi böylesine bir algı temelinde operasyonel işlemler yapıyorsanız, detaylara ister istemez girip, bu detaylarda boğulmaya başlayabiliyorsunuz.

Her şeyin minimum da kusursuz olmasını istemek tabii ki doğal bir şey ama elimizde ki imkanlar çerçevesinde durumu iyi değerlendirmek gerekiyor.

İşte en son geldiğimiz noktada, bu detayların bazılarının tamamen kullanıcıyı daha fazla -GEREKSİZ- bilgilendirmeye veya işlerini bir tık daha kolaylaştırmaya yaradığını fark ettik.

Bunun üzerine artık herhangi bir ürün özelliği eklenmesi gündeme geldiğinde şu bağlamda gitmeye karar verdik.

Bir özelliğin eksikliği operasyonu durduruyorsa, en basit haliyle dahil et.Operasyonu durdurmuyorsa, sonraya bırak veya tamamen kaldır.

Bu size zaten MVP model tanımı gibi görünebilir ancak önceki “MVP / MLP” yazımda, MVP modelin her projeden projeye tanımının ve içeriğinin değiştiğini, hatta bazı projelerde hiç MVP olamayacağı hakkındaki düşüncelerimden bahsetmiştim.

O yüzden bu MVP’ nin başka bir boyutu bana göre. Bende hala tanımlayamadım. Tecrübesizlikten sanırım.

Aşağıda çok basit olan iki durum hakkında karar verme aşamasını bir excel tablosunda göstermeye çalıştım.

Bu rutini tüm operasyonel sürecinize yayabilirsiniz biz gibi. Bunlar zaten olması gerekenler yahu dediğinizi duyar gibiyim. Dışarıdan bir okuyucu olsam bende öyle derdim emin olun.

Ancak detayları veya mükemmelleştirme hamlelerini, elimizdeki imkanlar çerçevesinde uygulamaya koymanın önemini daha yeni kavrayabildim. Bir yazılım ordusuna sahip değildik ve her gereksiz detay, zaman kaybına yol açıyordu!

Belki tecrübesizlikten, belki de çok fazla detaylı düşünmemizden göremedik ancak artık sadece ana konulara değil, detaylara da hayati mi değil mi diye bakmaya başladık. Bu benim için ayrı bir tecrübe oldu.

Detaylara da hemen çok basit bir örnek vererek yazıyı noktalayalım.

Geri bildirim almak istiyoruz kullanıcılardan ve bu geri bildirimler her sayfaya özel olarak kategorize ediliyor. A sayfasından gönderilen bir geri bildirim, A sayfası özelinde değerlendirilecek kısacası.

Bu uyarıyı kullanıcılara vermek için bir çok seçenek var ancak hangisini uygulasak diye düşünürken 1 saatlik bir zamanı kaybettiğimi fark ettim.

Traşlama dediğimiz hamleyle birlikte sadece bir uyarı yazısı ekle ve devam et seçeneği ile birlikte aslında yazılımsal olarak sadece bir <p> tagı içerisine “Geri bildiriminiz, şu anda bulunduğunuz sayfa için değerlendirilecektir.” yazısı ekleyip geçtik.

Mükemmelleştirmeye kalksak, bize yük yaratacak onlarca afili seçenekte mevcuttu ama GEREK YOK.

İşin özü, elimizdeki imkanlarla yapılmak istenenleri bir düşünmeliyiz ve her ne kadar projeden projeye traşlama hamlesi değişkenlik gösterse de, operasyonel olarak en basite indirgemek şart! Yoksa detaylar zaman kaybı yarattığı gibi, psikolojik olarakta sizi yıpratıyor.

Bakalım ileride nasip olurda Oppaze’nin yan ürünlerine geçiş yaptığımızda, bir yazılım ordusuyla olan durumu da değerlendiririz belki, kim bilir.