İş fikrinizi uygulanabilir projeye dönüştürün. Müşteri problemi, varsayımlar, doğrulama, ilk sürüm kapsamı, görev sahipleri ve kabul kriterleri.
Bir fikir, yapılacak ekranların veya özelliklerin listesine dönüştüğünde henüz proje haline gelmiş olmaz. Proje; kimin hangi problemini çözeceğini, ilk olarak neyin denenmesi gerektiğini, işi kimin yürüteceğini ve tamamlandığının nasıl anlaşılacağını açıklar. Bu ayrım, özellikle web sitesi, dijital ürün, hizmet markası veya yeni bir pazarlama modeli kurarken önemlidir. Başlangıçta her şeyi bilmeniz gerekmez. Bilmediğiniz noktaları görünür hale getirip doğru sırayla test etmeniz gerekir. Aşağıdaki çerçeve, fikri erken bir teknoloji kararına sıkıştırmadan uygulanabilir çalışmaya dönüştürmek için kullanılabilir.
1. Fikri, müşterinin yapmaya çalıştığı iş üzerinden anlatın
“Bir platform yapmak istiyorum” çözüm biçimini söyler; neden gerekli olduğunu açıklamaz. Önce müşterinin bugün hangi işi nasıl yaptığını, nerede zorlandığını ve bu zorluğun sonucunu yazın. Ardından önerdiğiniz değişikliği ekleyin. Böylece aynı probleme daha basit bir hizmet, içerik veya operasyon düzenlemesiyle çözüm bulunup bulunamayacağını da değerlendirebilirsiniz.
GOV.UK’un keşif rehberi, geliştirmeye bağlanmadan önce kullanıcı problemini ve kısıtları anlamayı önerir. Ticari projelerde de bu yaklaşım yararlıdır; ancak kamu hizmetleri için hazırlanmış süreçleri birebir kopyalamak gerekmez. Sizin kararınız, müşterinin ihtiyacı ile işletmenin sunabileceği çözüm arasındaki ilişkiyi yeterince açıklayabilmelidir.
2. Bildiklerinizi varsayımlardan ayırın
Müşterinin problem yaşadığına, çözüm değiştirmeye istekli olduğuna veya belirli bir bedeli ödeyeceğine dair düşünceler aynı derecede doğrulanmış olmayabilir. Her önemli kabulün yanına dayanağını yazın. Görüşme, mevcut satış kaydı, destek talebi veya yalnızca ekip tahmini birbirinden ayrılmalıdır. Bir araştırma notunun olması, bütün pazar için sonuca varılabileceği anlamına gelmez.
Önceliği projenin devam edip etmeyeceğini değiştiren varsayımlara verin. Renk tercihi test edilebilir; fakat müşterinin bu işi çözmek için yeni bir araç kullanıp kullanmayacağı daha önce yanıtlanmalıdır. Teknoloji, veri erişimi, içerik üretimi ve operasyon kapasitesi gibi bağımlılıkları da görünür tutun. Sadece müşteri ilgisini doğrulamak, çözümün sunulabileceğini doğrulamaz.
| Varsayım türü | Sorulacak soru | İlk öğrenme yöntemi |
|---|---|---|
| Problem | Bu güçlük gerçekten yaşanıyor mu? | Son deneyim üzerinden müşteri görüşmesi |
| Davranış | Müşteri çözüm için ne yapıyor? | Mevcut sürecin gözlemlenmesi |
| Teklif | Önerilen kapsam anlamlı mı? | Somut teklif veya prototip görüşmesi |
| Teslimat | Bu deneyimi sağlayabiliyor muyuz? | Sınırlı operasyon denemesi |
| Teknoloji | Kritik bağlantı çalışabiliyor mu? | Dar teknik doğrulama |
3. Görüşmelerde beğeni değil, geçmiş davranış arayın
“Böyle bir uygulamayı kullanır mıydınız?” sorusu kolayca olumlu ama zayıf bir cevap üretebilir. Bunun yerine müşterinin sorunu en son ne zaman yaşadığını, nasıl çözdüğünü, kimden destek aldığını ve hangi noktada vazgeçtiğini sorun. Uygunsa kullandığı mevcut belge veya akışı göstermesini isteyin. Gerçek geçmişi anlamak, fikrinize verilen genel beğeniden daha uygulanabilir bilgi sunar.
Görüşülen kişilerin aynı ihtiyaca sahip olduğunu varsaymayın. Satın alma kararını veren kişiyle ürünü kullanan kişi farklı olabilir. İlk hedef grubunu bu farkları dikkate alarak daraltın. Bulguları müşterinin cümleleri ve gözlemlediğiniz davranışlarla kaydedin; duymak istediğiniz cevaba göre yeniden yazmayın.
4. İlk sürümü en küçük özellik listesiyle değil, tamamlanan işle tanımlayın
İlk sürümün amacı müşterinin anlamlı bir işi baştan sona tamamlayabilmesidir. Bu nedenle kayıt ekranını yapmak tek başına yeterli olmayabilir. Müşterinin talebi nasıl ileteceği, ekibin bunu nasıl işleyeceği ve sonucun nasıl bildirileceği birlikte düşünülmelidir. Bazı arka plan işleri başlangıçta insan tarafından yürütülebilir; bunun kapasitesi ve sorumlusu açık olmalıdır.
Örnek senaryo: Yerel atölyeleri kurumsal etkinlik talebiyle buluşturan bir fikirde ilk sürüm, geniş bir pazaryeri yerine talep formu, elle eşleştirme ve teklif takibinden oluşabilir. Bu yaklaşım talep niteliği ve operasyon güçlüğü hakkında öğrenme sağlayabilir. Senaryo varsayımsaldır; başarılı iş modeli veya gerçekleşmiş müşteri sonucu olarak sunulmamaktadır.
5. Proje brief’ini karar verilebilir hale getirin
Brief; hedef müşteri, problem, önerilen deneyim, ilk sürüm kapsamı, kapsam dışı işler, bağımlılıklar ve kabul kriterlerini içermelidir. “Modern bir site” yerine müşterinin hangi görevleri yapabilmesi gerektiğini yazın. Tasarımın tonu ve marka hedefi ayrıca anlatılabilir; ancak işlevsel teslim koşullarının yerini almamalıdır.
Strateji, marka, içerik, tasarım, geliştirme, pazarlama ve proje yönetimi işlerini tek bir zaman çizelgesinde ilişkilendirin. Kim karar verecek, kim içerik sağlayacak ve kim teslimi kontrol edecek? Bir işin birden fazla katılımcısı olabilir, ancak sonucu takip eden sorumlu belirsiz kalmamalıdır. Yeni isteklerin kapsam ve takvime etkisinin nasıl değerlendirileceğini de önceden tanımlayın.
- Hedef: İlk sürüm hangi müşteri problemini ele alıyor?
- Kapsam: Hangi uçtan uca iş tamamlanabilecek?
- Sınır: Bu sürümde özellikle hangi işler yapılmayacak?
- Bağımlılık: Hangi bilgi, erişim veya üçüncü taraf gerekli?
- Kabul: Hangi senaryolar çalıştığında teslim tamamlanmış sayılacak?
6. Yayını bitiş değil, değerlendirme noktası olarak planlayın
İlk kullanım sonrasında yalnızca ziyaretçi sayısını izlemeyin. Müşterinin işi tamamlayıp tamamlamadığını, nerede desteğe ihtiyaç duyduğunu ve ekibin hizmeti sürdürebilip sürdüremediğini değerlendirin. Sonuçları ilk varsayımlarla karşılaştırın. Talep yokluğu, yanlış hedef grup, anlaşılmayan teklif veya erişim eksikliği gibi farklı nedenlerle ortaya çıkabilir.
Bir sonraki sürüme geçmeden önce neyin öğrenildiğini ve neyin hâlâ belirsiz olduğunu yazın. Gerekirse kapsamı daraltmak veya yaklaşımı değiştirmek de ilerlemedir. Projelendirme, fikri koşulsuz büyütmek değil; emek ve kaynakları müşteri ihtiyacına dayanarak doğru sıraya koymaktır.