Bir manuel işi dijital ürüne dönüştürmeden önce, işin neden manuel kaldığını anlamak gerekir. Tekrar eden adımlar otomasyona uygun olabilir; fakat her müşteride değişen kararlar, eksik veri veya belirsiz sorumluluklar yalnız bir arayüz eklenerek çözülmez. Ürün fikrinin çekiciliğiyle mevcut işin tekrarlanabilirliği ayrı değerlendirilmelidir.
Kurucu ve proje yöneticisi bakışıyla önerdiğim başlangıç, işi birkaç gerçek görev örneği üzerinden haritalamaktır. Buradaki çerçeve bir ürünün gelir veya kullanım sonucu değildir; ürünleştirme kararından önce toplanabilecek kanıtı tarif eder.
Görevin başlangıç ve bitişini yazmak
İş hangi ihtiyaçla başlıyor ve hangi sonuçla tamamlanıyor? Bir rapor dosyasının oluşması mı, yoksa o raporla bir karar verilmesi mi bekleniyor? Çıktıyı dar tanımlamak kolay olabilir, fakat müşterinin asıl faydasını gözden kaçırabilir.
Akışı girdi, işlem, kontrol, teslim ve kullanım adımlarına bölerim. Her adımda kim çalışıyor, hangi bilgi eksik kalıyor ve hangi istisna insan kararı gerektiriyor? Bu inceleme, yazılımın hangi kısmı standartlaştırabileceğini gösterir.
Tekrar ile benzerliği ayırmak
| Gözlem | Ürünleştirme açısından soru |
|---|---|
| Aynı dosya düzeni tekrar ediyor | Ortak veri modeli kurulabilir mi? |
| Aynı karar farklı gerekçelerle veriliyor | Kural mı, uzmanlık mı gerekiyor? |
| Her müşteri farklı çıktı istiyor | Ortak çekirdek gerçekten var mı? |
| İş sık yapılıyor ama kritik değil | Müşteri çözüm değiştirmeye istekli mi? |
| İş seyrek ama hata maliyeti yüksek | Güvenilirlik ve kontrol nasıl sağlanacak? |
Benzer görünen iki süreçte sorumluluk ve veri erişimi farklı olabilir. Ortak bir ekranın bulunması ortak bir ürün ihtiyacı olduğunu kanıtlamaz. Özellikle kurum içi onay adımları dışarıdan görünenden daha fazla iş yükü yaratabilir.
Mevcut çözümün gerçek maliyetini öğrenmek
Yalnız işi yaparken geçen süre değil, bekleme, yeniden çalışma, kontrol ve hata düzeltme de incelenir. Kullanıcı bazen manuel yöntemi esnekliği nedeniyle tercih eder. Yeni ürün bu esnekliği kaldırıyorsa kazanılan hız başka bir maliyet doğurabilir.
Müşteriye “bunu otomatik yapsak kullanır mısın?” demek yerine son yapılan görevi anlatmasını isterim. Hangi araçlar arasında geçtiği, nerede beklediği ve sonucun kim tarafından kullanıldığı daha güçlü kanıt sağlar. Prototip öncesi kanıt bu görüşmenin hazırlığını tamamlar.
Küçük bir hizmet denemesi yapmak
Tam yazılım geliştirmeden önce sınırlı bir işi yapılandırılmış biçimde teslim etmek, ortak ihtiyacı sınamaya yardımcı olabilir. Manuel destek varsa müşteriye bunun niteliği açıkça anlatılır; otomatik çalışan ürün varmış gibi sunulmaz.
Denemede teslim kalitesi, kontrol süresi, müşterinin çıktıyı kullanıp kullanmadığı ve yeniden talep oluşması izlenir. Bir kez ilgi göstermek ile düzenli kullanım ihtiyacı farklıdır. Ücretsiz denemede görülen talep, ödeme isteğinin yerine geçirilmez.
Ürün sınırını seçmek
İlk sürüm, bütün manuel işi kapsamak zorunda değildir. En tekrarlanabilir ve değerlendirilebilir adım seçilebilir. İstisnalar için açık bir insan yolu bırakılır. Kapsam dışı kalan işler belirtilmediğinde müşteri ürünün çözemediği kısmı hata olarak algılayabilir.
MVP kapsamı seçimi ilk öğrenme alanını; özellik talebinin arkasındaki problem ise çözüm isteğiyle gerçek işi ayırmayı anlatıyor. Manuel bir işi ürünleştirme kararı, kaç adımı kodlayabildiğimizden önce, tekrar eden faydayı ne kadar açık tanımlayabildiğimize dayanmalıdır.