Bir deneme sürecinin kanıtlayabildikleri — ve kanıtlayamadıkları

Bir deneme süreci tek bir şeyi güvenilir biçimde ölçer: başlangıcın nasıl hissettirdiğini. Kayıt, ilk izlenim, ilk hamleler. Bu hiç de az değildir, çünkü ağır hissettiren bir başlangıç nadiren düzelir. Ama kararınızın dayandığı şey de bu değildir.

Kararınızı taşıyan şey, işletme içindeki davranıştır: zaman baskısı altında, birikmiş verilerle, istisnai durumda. Standart bir deneme süreci tam olarak bunu yapısal olarak yakalayamaz — sağlayıcının sahtekârlığından değil, boş veritabanıyla geçen iki haftanın dolu veritabanıyla geçen iki yıldan başka bir sistem olmasından. Bunu bilen kişi, deneme sürecini yine de bir şey kanıtlayacak biçimde kurabilir.

İşleyen tarafından başlayalım, çünkü sanılandan fazlasıdır. Bir deneme süreci dört soruyu sağlam biçimde yanıtlar ve dördü de yanıtlanmaya değerdir.

Başlangıç ne kadar sürüyor? Kayıttan ilk gerçek işleme kadar. Doksan dakika sonra hâlâ bir randevu oluşturamıyorsanız, bu bir bulgudur, alışma sorunu değil.

Kılavuz olmadan yolunuzu buluyor musunuz? Bilinçli olarak önce yardım sayfalarına bakmadan tıklayın. Takıldığınız yerde işletmede de takılırsınız — yalnızca o zaman seyirci önünde.

Destek ne kadar hızlı yanıt veriyor? Deneme sürecinde gerçek bir soru sorun, deneme sorusu değil. Deneme sürecindeki yanıt süresi genellikle hiç olmayacak kadar iyisidir; ortalamanız değil, üst sınırınızdır.

En sık yaptığınız şey nasıl hissettiriyor? Nadir kullanılan özel işlev değil, günde yirmi kez yaptığınız hamle. İşlem başına iki saniyelik fark, günde yirmi işlemde yaklaşık kırk saniye eder — bir iş gününde göze çarpmaz, ama yaklaşık 250 iş günlük bir yılda üç saate yakındır.

Bu dört sorunun ortak yanı, hepsinin ilk günlerde ve ek hazırlık olmadan yanıtlanabilmesidir. Bu yüzden de bir deneme sürecinden gerçekten sıkmaya değer olan özsu budur. Bunların ötesine geçen her şey — dolu bir takvimde arama, yıl sonunda rapor, üç kişinin aynı anda çalışması — kurulum gerektirir ve aşağıdaki bölümler tam olarak o kurulumu anlatır.

Hemen her hizmet işletmesinin birbiriyle ilgisi olmayan haftaları vardır. Şubattaki bir salon ile bayram arifesindeki aynı salon iki ayrı işletmedir. Yazın bir oto servis ile kış lastiği dönemindeki aynı oto servis de öyle. Kasımın ikinci haftasındaki bir okul ile dönem sonundaki aynı okul hele ki öyle.

Bir yazılımı sakin haftada denerseniz, onu hemen her sistemin çalıştığı koşullar altında denemiş olursunuz. Deneme size zaten hiç tartışmalı olmayan bir şeyi doğrular ve size sonradan pahalıya patlayacak olan konuda susar.

Buna karşı, sanıldığından daha az emek yardımcı olur:

• Denemeyi bilinçli olarak yoğun bir haftaya koyun, tatile değil. İdeal koşullarda geçmektense gerçek koşullarda kalmak yeğdir.
• Ya da uzatma isteyin. Çoğu sağlayıcı, gerekçesini belirttiğinizde deneme sürecini talep üzerine uzatır. Bu tek e-posta iki dakikanızı alır.
• Ya da yoğunluğu yeniden kurun. Geçen yıldan gerçek bir cumartesi alın ve bir saat içinde deneme sistemine girin. Sonrasında dolu bir günün nasıl göründüğünü, onu beklemek zorunda kalmadan bilirsiniz.

Son maddenin yanında götürülmesi gereken bir yan etkisi var: bu sırada verilerin girilmesinin kendisinin ne kadar sürdüğünü fark edersiniz. Bu kötü bir alıştırma değildir, çünkü geçişte tam olarak bu işi bir kez daha yapacaksınız.

Boş bir sistem hızlı, anlaşılır ve derli topludur. Mükerrer kaydı yoktur, telefon numarası olmayan eski müşterisi yoktur, iki yıldır sunulmadığı hâlde listede duran hizmeti yoktur. Oysa günlük iş tam olarak bunlardan oluşur.

Bu yüzden her deneme sürecindeki en etkili önlem, içeriye gerçek veri sokmaktır — hiç değilse bir kesit. İki yüz müşteri kaydı ve üç aylık randevu geçmişi, beş deneme kaydıyla görünmez kalan soruları yanıtlamaya yeter: dört kişinin adı benzer olduğunda arama nasıl görünüyor? Sistem bir onay göndermek istediğinde, e-posta adresi olmayan bir kayda ne oluyor? İki mükerrer kayıt, geçmiş kaybolmadan birleştirilebiliyor mu?

Bu sırada iki şey önemlidir. Birincisi: deneme sistemi de içinde gerçek kişisel verilerin durduğu bir sistemdir. İşleme, gerçek kullanımdakiyle aynı hukuki sebebe muhtaçtır (KVKK m.5) ve sağlayıcı sizin adınıza işliyorsa veri işleyendir; KVKK m.12/2 uyarınca güvenlik tedbirlerinin alınmasından onunla müştereken sorumlu olursunuz. Bu sorumluluk faturayla değil, ilk deneme kaydıyla başlar.

İkincisi: daha deneme sürecindeyken deneme verilerinin silinebilir olmasını talep edin. Sağlayıcıya karşı karar verirseniz, o iki yüz kaydı dünyadan geri çekmek istersiniz. Bunu kendi başına yapamayan bir sistem, size çok daha büyük bir sorunun yanıtını vermiştir.

Deneme süreçlerinin sonuçsuz geçmesinin en yaygın nedeni zaman darlığı değildir. Neyin deneneceğini kimsenin önceden belirlememiş olmasıdır. Ortalıkta tıklanır, her şey oldukça düzgün bulunur ve on dördüncü günde soru olduğu gibi durur.

Kullanışlı bir plan yarım sayfaya sığar ve baştan sona oynadığınız üç gerçek işten oluşur — kurcalanmış değil, sonuna götürülmüş. Çoğu işletme için bunlar şunlardır:

1. Eksiksiz standart iş. Talepten randevuya, oradan ödenmiş belgeye kadar, sizde gerçekte nasıl işliyorsa öyle.
2. İstisnai durum. Son anda iptal, erteleme, kısmi ödeme, bir faturanın sonradan düzeltilmesi. İstisnai durumlar işlerin küçük bir bölümünü, sıkıntının ise en büyük bölümünü oluşturur.
3. Geriye bakış. Geçen ay ne oldu? Bir yıldır kim uğramadı? Bir raporu iki dakikada bulamıyorsanız, ona hiç bakmayacaksınız.

Buna, on dakika bile sürmeyen ve neredeyse kimsenin yapmadığı bir zorunlu alıştırma eklenir: bir kez eksiksiz veri dışa aktarımı başlatın ve dosyayı açın. Ona ihtiyacınız olduğu için değil, içinde ne yazdığını görmek için. Bu denetimin hiçbir şeye mal olmadığı tek an budur ve deneme sürecinin sonradan dönüş yolunu belirleyen tek bulgusudur.

Vazgeçme ölçütleri, insan onlara ihtiyaç duymadığı sürece abartılı görünür. Oysa her deneme sürecinin en güçlü etkisine karşı korurlar: harcanmış on saatten sonra kimse yazılımın uymadığını duymak istemez. O noktada yazılım değil, bir karar savunulmuş olur.

Bu yüzden ilk girişten önce, hangi durumda duracağınıza dair iki üç cümle yazın. Bir dışarıdakinin denetleyebileceği kadar somut olmalılar. Örneğin: standart bir randevuyu otuz saniyenin altında oluşturamıyorsam. Ya da: dışa aktarım randevu geçmişini içermiyorsa. Ya da: destek sorumu iki iş günü içinde yanıtlanmamışsa.

Böyle cümleler vazgeçmeyi ucuzlatır; bütün amaçları da budur. Ayrıca sizi en tatsız ihtimalden korurlar: deneme süreci dolduğu ve kimse itiraz etmediği için kurulan sözleşmeden. Bu yüzden ilk gün, deneme erişiminizin kendiliğinden ücretli bir aboneliğe dönüşüp dönüşmediğini ve bunu tam olarak nereden kapattığınızı denetleyin. Bu bilgi deneme sürecinin sonuna değil, başına aittir.

Ölçütleri yazarken bir noktaya dikkat edin: hepsi sizin denetiminizde olan şeylere bakmalı. Yazılımın hoşunuza gitmemesi bir ölçüt değildir, çünkü onuncu günde hoşunuza gitmeyen şey büyük olasılıkla alışkanlıktır. Standart bir işin kaç saniye sürdüğü, dışa aktarımın neyi içerdiği ve desteğin ne zaman yanıt verdiği ise ölçülebilir; bunlar iki hafta sonra da aynı anlama gelir.

Vazgeçerseniz: sağlayıcıya kısaca neden olduğunu söyleyin. Bu yaptığınız bir iyilik değildir — bir ürünün gerçekten öğrendiği tek geri bildirimdir.