İş fikrini projeye dönüştürmek için önce kimin hangi sorununu çözeceğinizi yazın. Ardından bu kişinin baştan sona tamamlayacağı tek işi seçin ve küçük bir sürümle deneyin. İlk adım bütün özellikleri geliştirmek değil, müşterinin ihtiyacını ve sizin çözümü sunabilmenizi sınamaktır.
Müşterinin yaşadığı sorunu 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.
Bilgi ile varsayımı 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 |
Görüşmede geçmiş deneyimi sorun
“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.
İlk sürümde tek işi tamamlatın
Temsili fikir: Şirketler etkinlikleri için uygun atölyeyi bulmakta zorlanıyor. İlk sürüm, bütün atölyelerin kendini kaydettiği büyük bir pazaryeri olmak zorunda değil. Talep formu, ekibin elle eşleştirmesi ve müşteriye seçenek sunmasıyla hizmetin temel akışı denenebilir.
Bu denemede hangi bilginin eksik kaldığını ve eşleştirme için ne kadar insan işi gerektiğini kaydedin. Müşterinin öneriyi neden kabul veya reddettiğini sorun. Kullanıcı talep oluşturamıyorsa arayüzü; talep oluşuyor ama uygun atölye bulunamıyorsa tedarik ve iş modelini inceleyin.
| İlk sürümdeki adım | Ne öğrenilir? | Başlangıçta nasıl yapılabilir? |
|---|---|---|
| Etkinlik talebini almak | İstenen tarih, içerik ve katılımcı bilgisi | Kısa form ve doğrulama görüşmesi |
| Uygun atölyeyi seçmek | Seçeneklerin gerçekten karşılanabilirliği | Ekibin elle eşleştirmesi |
| Öneriyi paylaşmak | Müşterinin seçim nedenleri | Açık seçenekler ve geri bildirim |
| Talebi sonuçlandırmak | Operasyonun devam edip edemediği | Takip listesi ve hizmet onayı |
Proje brief’ini hazırlayın
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?
İlk kullanımdan sonra neyi değiştireceksiniz?
İ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.