Prototipi hazır olan girişimin sıradaki adımı ne olmalı?

Prototipi hazır olan girişimin sıradaki adımı, daha fazla özellik eklemekten önce hangi belirsizliği azaltacağını seçmektir. Çözümün teknik olarak çalışması, kullanıcının onu anlayabilmesi ve müşterinin bedel ödemeye hazır olması farklı kanıtlardır. Bu üç alanı ayrı değerlendirip kontrollü denemeler tasarlamak, prototipten kullanılabilir ve sürdürülebilir bir ürüne geçişi daha sağlıklı yönetmenizi sağlar.

Hazır kelimesinin neyi anlattığını açıklayın

Bir prototipin hazır olması ekipler arasında farklı anlamlara gelebilir. Tasarım dosyası tamamlanmış olabilir, parçalar birlikte çalışabilir veya gerçek bir görev baştan sona yapılabiliyor olabilir. Sunumda gösterilebilen bir akış ile başka bir kişinin yardım almadan kullanabildiği çözüm aynı aşamada değildir. Bu nedenle değerlendirmeye ilk olarak çalışan işlevleri ve henüz çalışmayan noktaları yazarak başlayın.

Prototipi tarif ederken sürüm, kullanım koşulu ve bilinen sınırlamalar birlikte belirtilmelidir. İnternet bağlantısı kesildiğinde çalışmayan bir cihaz, kontrollü laboratuvar koşullarında başarılı görünse bile saha için hazır sayılmayabilir. Yazılımda ise yalnız önceden hazırlanmış verilerle çalışan bir gösterim, gerçek müşteri verisinin sorunlarını henüz ortaya çıkarmamış olabilir. Bu sınırlamaları açıklamak ürünü zayıflatmaz; denemenin anlamını netleştirir.

Ekibiniz şu cümleyi tamamlayabilmelidir: “Bu sürüm, şu koşullarda şu görevi yerine getiriyor; şu durumları henüz sınamadık.” Ardından bu tanımı ürünü geliştirmeyen bir kişiye okutun. Aynı durumu anlıyorsa başlangıç noktanız yeterince açıktır. Anlatım sürekli açıklama gerektiriyorsa önce prototipin kapsamını sadeleştirmek gerekir.

Teknik olgunluğu ticari hazırlıktan ayırın

NASA’nın teknoloji hazırlık seviyeleri açıklaması, teknolojik olgunluğu aşamalarla değerlendiren bir yaklaşımı tanıtır. Bu teknik bakış, prototipin hangi ortamda sınandığını düşünmek için yararlıdır. Ancak yüksek teknik olgunluk, müşterinin ürünü istediğini veya girişimin satışa hazır olduğunu tek başına göstermez.

Kendi değerlendirme belgenizde üç ayrı sütun açabilirsiniz: teknik işlev, kullanıcı davranışı ve ticari koşullar. Teknik sütunda sistemin görevi yapabilmesi, kullanım sütununda insanın bu görevi tamamlayabilmesi, ticari sütunda ise satın alma ve hizmet beklentileri incelenir. Bu makaledeki üç sütunlu düzen, editoryal bir çalışma önerisidir; NASA’nın veya başka bir kurumun resmî sınıflandırması değildir.

Her sütunun kanıt türü farklıdır. Çalışma kaydı teknik soruya yanıt verebilir. Kullanıcının gözlemlenmesi kullanım sorunlarını gösterebilir. Kapsam ve bedelin konuşulduğu gerçek bir ticari görüşme ise ödeme isteğine ilişkin bilgi sağlar. Bir alandaki olumlu bulguyu diğer alanların da tamamlandığı şeklinde yorumlamamak, erken büyüme kararlarının temelidir.

En kritik varsayımı seçerek başlayın

Prototipten sonra aynı anda onlarca şeyi sınamak mümkündür; fakat ekibin zamanı sınırlıdır. Öncelik, yanlış çıkması halinde girişimin planını en çok değiştirecek varsayıma verilmelidir. Kullanıcı sorunu yeterince önemli bulmuyorsa arayüzü cilalamak erken olabilir. Temel teknik işlev güvenilir değilse geniş kapsamlı kullanıcı denemesine çıkmak da yanıltıcı sonuçlar doğurabilir.

Varsayımları bir listeye yazın ve her biri için iki soru sorun: Elimizde hangi kanıt var, yanlış çıkarsa hangi karar değişir? Güçlü kanıtı bulunmayan ve büyük karar etkisi olan maddeler öne alınabilir. Bu sıralama sayısal bir başarı puanı üretmek zorunda değildir. Amacı ekibin hangi belirsizlik için neden kaynak ayırdığını açıklamasıdır.

Örneğin “küçük işletmeler bu raporu her gün kullanır” varsayımı, yalnız bir görüşmedeki olumlu yorumla doğrulanmış sayılmaz. Kullanım sıklığı gerçek iş akışında gözlenebilir. “Cihaz farklı yüzeylerde ölçüm yapar” varsayımı ise uygun teknik düzenekle sınanmalıdır. Sorunun türünü doğru belirlemek, yanlış denemeden yanlış sonuç çıkarılmasını önler.

Her deneme için bir karar kartı hazırlayın

Deneme kartı, kısa bir araştırma planı gibi düşünülebilir. Sorulacak soru, kullanılacak sürüm, katılımcı veya ortam, gözlenecek durum ve sonuçtan sonra verilecek karar yazılır. Başarı ve durdurma koşulları mümkün olduğunca denemeden önce belirlenir. Sonuç görüldükten sonra ölçütü değiştirmek, ekibin kendi varsayımını korumasını kolaylaştırabilir.

Kartta ölçümün nasıl yapılacağı da belirtilmelidir. “Kullanımı kolay” ifadesi yerine, belirli bir görevin hangi yardımlarla tamamlandığı kaydedilebilir. “Hızlı çalışıyor” demek yerine hangi işlem koşulunda ne ölçüldüğü açıklanır. Her deneme için çok sayıda veri toplamak gerekli değildir. Kararı desteklemeyen veriler, hazırlık ve değerlendirme yükünü artırabilir.

Bir sorunun yanıtı bilinmiyorsa kartta boş bırakmak yerine açıkça bilinmiyor yazın. Böylece deneme sonunda eksikliği görmezden gelmek zorlaşır. Ayrıca denemenin neyi göstermeyeceğini belirtin. Küçük bir kullanım çalışması pazar büyüklüğünü kanıtlamaz; tek ortamda teknik başarı farklı ortamlardaki güvenilirliği garanti etmez. Sınırları iyi yazılan sonuç daha kullanışlıdır.

Deneme bütçesini de kartın parçası yapın. Bütçe yalnız para değildir; geliştirici zamanı, müşteri hazırlığı ve sonucun yorumlanması için gereken emek de hesaba katılır. Bir soruyu yanıtlamak için tam ürün geliştirmek gerekiyormuş gibi düşünmeyin. Bazen mevcut akışın elle yürütülmesi, ekranların sınırlı bir bölümünün gösterilmesi veya gerçek sistemden ayrılmış örnek veriler yeterli öğrenme sağlayabilir. Seçilen yöntemin sınırları dürüstçe açıklanmalıdır; elle yürütülen işlem otomatik sistem gibi sunulmamalıdır.

Ayrıca denemenin önceden belirlenen bir bitiş noktası olsun. Yeni bir soru ortaya çıktığında aynı çalışmayı sürekli genişletmek yerine ayrı bir deneme kartı açılabilir. Bu düzen, başlangıç sorusunun unutulmasını önler. Sonuç toplantısında yalnız nelerin yapıldığı değil, harcanan emeğe karşı hangi kararın mümkün hale geldiği konuşulur. Çok etkileyici bir gösterim hiçbir belirsizliği azaltmıyorsa, sonraki denemede daha küçük ama karar açısından daha yararlı bir kapsam seçmek gerekebilir.

Teknik denemeyi gerçek koşullara yaklaştırın

Teknik denemenin amacı yalnız prototipi çalıştırmak değildir; hangi koşullarda çalıştığını ve nerede bozulduğunu öğrenmektir. Normal kullanım kadar beklenen değişkenlik de düşünülmelidir. Donanımda çevre koşulları, güç kaynağı ve kurulum biçimi; yazılımda veri yapısı, bağlantı, kullanıcı yetkileri ve yük gibi unsurlar sonucu değiştirebilir.

Her değişkeni birden değiştirmek, sorunun kaynağını bulmayı zorlaştırabilir. Önce hangi değişikliğin neyi etkilediğini takip edebileceğiniz bir düzen kurun. Kullanılan sürüm ve ayarlar kayıt altına alınsın. Başarısız denemeler de saklansın; yalnız iyi çalışan gösterimleri seçmek, gerçek güvenilirlik hakkında yanlış bir izlenim oluşturur.

Bazı ürünlerin denenmesi özel standart, yetki veya uzmanlık gerektirebilir. Bu durumda ekibin kendi denemesi, gerekli profesyonel değerlendirme veya resmî uygunluk sürecinin yerine geçmez. Kritik bir sisteme bağlanmadan önce uygun teknik sorumlularla kapsam belirlenmelidir. Bu yazının yöntemi, ürünün niteliğine göre gereken güvenlik ve uygunluk değerlendirmelerini ortadan kaldırmaz; bunların zamanında fark edilmesini sağlar.

Kullanım denemesinde anlatmayı azaltıp gözlemleyin

Kurucu, ürünün mantığını bildiği için kullanıcının nerede zorlanacağını fark etmeyebilir. Kullanım denemesinde görev açıkça tarif edilir; fakat bütün adımlar gösterilmez. Kullanıcı ilerlerken nerede durduğu, hangi ifadeyi yanlış anladığı ve hangi bilgiyi aradığı gözlenir. Sürekli yönlendirme yapılırsa ürünün kendi başına ne kadar anlaşılır olduğu görülemez.

Katılımcıya sınananın kişi değil ürün olduğu açıklanmalıdır. Kullanıcının hata yapması, araştırmanın başarısızlığı değildir. Tam tersine ürünün tasarımına ilişkin bilgi sağlayabilir. Deneme sonrasında yalnız genel beğeni sorulmaz; hangi adımın beklenmedik olduğu ve normal işinde bu görevi nasıl yaptığı da konuşulur. Kısa bir zorlanma, uzun bir memnuniyet cümlesinden daha öğretici olabilir.

Yardım verildiyse bunu kayda alın. Yardımla tamamlanan görev ile bağımsız tamamlanan görev farklı bulgulardır. Bazı ürünler zaten uzman desteğiyle kullanılacaksa bu gerçek çalışma modeline dahil edilmelidir. Amaç bütün ürünleri aynı kolaylık ölçüsüne zorlamak değil, hedeflenen kullanıcı ve kullanım bağlamı için gereken desteği doğru anlamaktır.

Ödeme isteğini nezaket ifadelerinden ayırın

Kullanıcının prototipi beğenmesi, kurumun bütçe ayıracağı anlamına gelmez. Ticari değerlendirmede sorunun önemi, mevcut alternatif, karar süreci ve teslim edilecek kapsam konuşulmalıdır. Kullanıcı ile satın alma kararını veren kişi farklıysa her iki bakışın da anlaşılması gerekir. Ürün faydasını anlatan kişi, ödeme zamanını veya bütçeyi belirleyemeyebilir.

NSF I-Corps programı, teknolojilerin pazar potansiyelini değerlendirmede müşteri keşfi ve deneyim yoluyla öğrenmeye yer verir. Buradan çıkarılacak temel düşünce, laboratuvar dışındaki ihtiyacı araştırmaktır. Bu yaklaşım, belirli sayıda görüşme yapmanın satış garantisi olduğu veya yabancı programa ait şartların bütün girişimlere uygulanacağı anlamına gelmez.

Ticari denemede müşterinin gerçek bir sonraki adımı olup olmadığına bakın. Teknik inceleme istemesi, kapsam görüşmesine zaman ayırması veya teklif değerlendirmesi yapması farklı ciddiyet işaretleri olabilir. Bunların hiçbiri tek başına kesin satış değildir. Ne söylendiğini, ne yapıldığını ve hangi kararın hâlâ beklediğini ayrı kaydetmek daha dürüst bir değerlendirme sağlar.

Teslimatın görünmeyen işlerini hesaba katın

Prototipi geliştiren kişi onu kurabiliyor olabilir; başka bir çalışanın aynı kurulumu yapıp yapamayacağı bilinmeyebilir. Paketleme, kurulum, veri aktarımı, eğitim, destek ve bakım gibi işler ürünün gerçek hizmet yükünü oluşturur. Bu işler değerlendirilmeden yapılan satış, ekibi öngörmediği bir operasyonla karşılaştırabilir.

Bir denemede teknik geliştirme kadar teslimat sürecini de izleyin. Müşteriden hangi bilgi isteniyor, bu bilgi kaç kez eksik geliyor, kurulum sırasında hangi kararlar kurucuya dönüyor? Tek seferlik çözümle tamamlanan işler ayrıca işaretlenmelidir. Aynı iş her müşteride yeniden icat ediliyorsa ürünün tekrarlanabilirliği sınırlı olabilir.

Teslimat listesini hazırlamak, hemen kapsamlı bir süreç kitabı yazmak değildir. İlk aşamada birkaç kontrol noktası yeterlidir: başlamadan gerekenler, tamamlandığının göstergesi ve sorun çıkarsa sorumlu kişi. Bu küçük kayıtlar, yeni ekip üyelerinin işi devralmasını kolaylaştırır. Ayrıca müşteriye verilecek hizmet sözünün gerçek kapasiteyle uyumunu değerlendirmeye yardımcı olur.

Varsayımsal örnek: Depo sayım prototipinin üç farklı sınaması

Bu senaryo açıklama amacıyla kurgulanmıştır; gerçek bir firma veya Orion TEKMER projesi değildir. İki kişilik bir ekip, küçük depolarda kutu etiketlerini okuyarak sayım kaydı oluşturan bir prototip geliştiriyor. Kontrollü masada etiketleri okuyabilmesi, ekibe ürünün hazır olduğunu düşündürüyor. Ancak saha kullanımında üç ayrı belirsizlik bulunuyor.

İlk teknik denemede farklı ışık ve etiket konumlarında okuma davranışı inceleniyor. Ardından kullanım çalışmasında depo görevlisinin tarama sırasını ve hatalı kaydı düzeltme yolunu anlayıp anlamadığı gözleniyor. Üçüncü görüşmede işletme yöneticisiyle çözümün mevcut sayım yöntemine göre hangi iş yükünü azaltabileceği ve satın alma süreci konuşuluyor. Bu çalışmalar aynı sonuç başlığı altında birleştirilmiyor.

Teknik sonuç kabul edilebilir olsa bile kullanıcıların hatalı kaydı bulamadığı görülürse bir sonraki adım yeni özellik eklemek değil, düzeltme akışını geliştirmek oluyor. İşletmenin düzenli sayım ihtiyacı bulunmadığı anlaşılırsa müşteri profili yeniden ele alınıyor. Örnek, prototipi yalnızca hazır veya hazır değil diye sınıflandırmak yerine teknik, kullanım ve ticari kanıtları ayrı değerlendirmek gerektiğini gösteriyor.

Olumsuz bulguları ürün kararına dönüştürün

Deneme sonunda kusur listesi çıkarmak kolaydır; hangi kusurun önce ele alınacağını seçmek daha zordur. Bulguları temel görevi engelleyenler, güveni azaltanlar ve deneyimi iyileştirenler şeklinde ayırabilirsiniz. Bu ayrım ürünün bağlamına göre yapılır. Görsel bir sorun bazı ürünlerde küçükken başka bir üründe kullanıcının kritik bilgiyi kaçırmasına neden olabilir.

Bulguyla öneriyi ayrı yazın. “Kullanıcı ayarı değiştiremedi” bir gözlemdir. “Yeni bir menü ekleyelim” ise çözüm önerisidir. Aynı gözleme birden fazla çözüm üretilebilir. Ekip doğrudan ilk öneriye atlarsa gereksiz geliştirme yapabilir. Önce sorunun nedenini ve hangi kullanıcı koşulunda ortaya çıktığını anlamak gerekir.

Başarısızlık tekrar denemeyi gerektirebilir; fakat sonsuz düzeltme döngüsüne de dönüşmemelidir. Belirli bir varsayım sürekli zayıf kalıyorsa ürün kapsamı, hedef kullanıcı veya yaklaşım değiştirilebilir. Denemenin amacı her durumda mevcut fikri savunmak değildir. Gerektiğinde durmak veya yön değiştirmek için yeterli bilgiyi üretmek de gerçek ilerlemedir.

Sonuç dosyasını başka birinin anlayacağı biçimde tutun

Deneme bilgileri yalnız kurucunun hafızasında kalırsa aynı sorular tekrar sorulur. Kısa bir sonuç dosyasında sürüm, koşul, katılımcı profili, gözlem, sınır ve karar yer alabilir. Fotoğraf, kayıt veya kullanıcı verisi tutulacaksa gerekli izinler ve paylaşım koşulları ayrıca değerlendirilir. Her denemeyi kaydetmek, her kişisel ayrıntıyı toplamak anlamına gelmez.

Dosyanın başında karar özeti bulunmalıdır. Hangi varsayım desteklendi, hangisi zayıfladı, hangisi hâlâ bilinmiyor? Ardından gerekçeler yazılır. Yalnız olumlu ifadeleri seçmek yerine karşıt bulgular da görünür tutulur. Özellikle küçük örneklerde sonuçların sınırlı olduğu belirtilir. Bu saydamlık, mentör veya uzman görüşmesinin daha doğru bilgiyle yapılmasını sağlar.

Dışarıya hazırlanan sunum ile ekip içi öğrenme kaydı aynı ayrıntıyı taşımayabilir. Ancak birbirleriyle çelişmemelidir. Henüz denenmemiş işlevler çalışıyor gibi, araştırma görüşmeleri müşteri sözleşmesi gibi gösterilmemelidir. Açık sınırlar, ekibin güvenilirliğini korur ve sonraki iş birliğinde hangi konuların birlikte sınanması gerektiğini gösterir.

Bir sonraki sürümü öğrenilen bilgiyle sınırlandırın

Denemelerden sonra bütün geri bildirimleri aynı sürüme almak zorunda değilsiniz. Önce bir sonraki kararın verilmesini engelleyen eksikler seçilir. Bazı özellikler daha sonra ele alınabilir, bazıları ise hedef kullanıcıyla ilgisiz bulunabilir. Yol haritası, en çok önerilen özelliklerin listesi değil, en önemli belirsizlikleri azaltan işlerin sırası olmalıdır.

Sürüm planında her işin hangi bulguyla ilişkili olduğunu belirtin. Bir değişiklik yalnız ekip içi tercihe dayanıyorsa bunu da açıkça yazın. Her tasarım kararı için resmî araştırma yapmak gerekli değildir; fakat varsayım ile gözlemi karıştırmamak gerekir. Ekip, sınırlı zamanını hangi gerekçeyle kullandığını sonradan açıklayabilmelidir.

THK & Orion TEKMER’in hizmetler sayfasındaki iş geliştirme ve mentörlük başlıklarını incelerken prototipinizin mevcut durumunu ve sınamak istediğiniz soruyu hazırlayabilirsiniz. Görüşmeye çalışan bir gösterimin yanında karar kartı ve sonuç özeti getirmek ihtiyacınızı açıklaştırır. Sağlanabilecek katkı ayrıca değerlendirilir; prototip bulunması otomatik kabul, yatırım veya satış sonucu doğurmaz.

Sık sorulan sorular

Prototip çalışıyorsa doğrudan satışa başlamalı mıyım?

Ürünün niteliği, riskleri ve teslimat kapsamı belirleyicidir. Teknik çalışmanın yanında kullanım, destek ve ticari koşullar da değerlendirilmelidir. Bazı çözümler sınırlı kapsamla sunulabilirken bazıları ek teknik veya resmî süreç gerektirir. Müşteriye hangi sürümün ne yapabildiği açıkça anlatılmalıdır.

Kaç kullanıcıyla deneme yapmalıyım?

Evrensel bir sayı yoktur. Sorunun türü, hedef grubun çeşitliliği ve verilecek karar önemlidir. Küçük bir çalışma belirgin kullanım sorunlarını gösterebilir; fakat bütün pazara ilişkin sonuç çıkarmaya yetmeyebilir. Sayıdan önce hangi soruyu hangi yöntemle yanıtlamak istediğinizi belirleyin.

Teknik başarı müşteri talebini kanıtlar mı?

Hayır. Teknoloji belirlenen görevi yerine getirebilir, fakat müşteri mevcut çözümünü yeterli bulabilir veya değişim maliyetini yüksek görebilir. Ticari ihtiyaç ayrı araştırılmalıdır. Kullanım kolaylığı, teknik güvenilirlik ve ödeme isteği birbirini etkiler; yine de aynı kanıt türü değildir.

Her geri bildirimi ürüne eklemek gerekir mi?

Hayır. Geri bildirimin hangi ihtiyacı anlattığını ve hedeflediğiniz kullanıcılarla ne kadar ilişkili olduğunu inceleyin. Tek bir kişinin isteği bütün ürünün yönünü belirlememelidir. Öncelik, temel görevi engelleyen ve önemli kararı belirsiz bırakan bulgulara verilebilir.

Deneme sonucu olumsuzsa prototip boşa mı gitmiştir?

Olumsuz sonuç, hangi varsayımın yanlış olduğunu gösteriyorsa değerli öğrenme üretir. Ürün kapsamı, kullanıcı seçimi veya teknik yaklaşım değiştirilebilir. Asıl kayıp, aynı soruyu ölçmeden tekrar tekrar geliştirme yapmaktır. Sonucu kaydetmek ve sonraki kararla ilişkilendirmek öğrenmeyi kullanılabilir hale getirir.