Kavram kanıtı (POC) ve pilot proje yönetimi

Çarşamba öğleden sonra, kırk kişilik bir yazılım şirketinde iyi giden bir görüşmenin son beş dakikası. Alıcı tarafındaki müdür rahat bir cümle kuruyor: birkaç kullanıcıyla iki hafta deneyelim, sonra konuşuruz. Satış temsilcisi hemen kabul ediyor, çünkü bu bir ilerleme gibi görünüyor. Altı hafta sonra tablo şöyle: kurulum için iki geliştirici otuz saat harcamış, açılan beş hesaptan üçü sisteme iki kez girmiş, kimse neyin ölçüleceğini yazmamış ve alıcı tek cümleyle bitiriyor, açıkçası farkı göremedik. Kaybedilen yalnızca bu anlaşma da değil: artık o şirkette, denendi ve tutmadı diye kayda geçmiş bir kanaat var ve bu kanaat sizi en az bir yıl kapının dışında tutar.

Kavram kanıtı (POC) ve pilot proje, doğru kurulduğunda satış döngüsünün en güçlü ikna aracıdır; yanlış kurulduğunda ise ücretsiz danışmanlıktır. Bu yazıda POC ile pilotun neden farklı sorular sorduğunu, hangi talebi kabul edip hangisini reddetmeniz gerektiğini, pilot sözleşmesinin bileşenlerini, başarı kriterinin nasıl yazıldığını, kapsamı daraltmanın neden hayat kurtardığını, kimin hangi taahhüdü verdiğini, sürenin nasıl belirlendiğini, pilot boyunca satış ekibinin görevini, ücretsiz pilotun gizli maliyetini, karar anını ve pilot programınızın sağlığını gösteren göstergeleri sırayla ele alıyoruz.

PilotsözleşmesiBaşarı kriteriKapsamRollerTakvimÇıkış koşulu

POC ile pilot aynı şey değildir

İkisi farklı sorular sorar. Kavram kanıtı teknik bir soruya cevap arar: bu iş teknik olarak mümkün mü, bizim altyapımızda çalışır mı, şu veri şu sisteme akar mı? Katılımcısı genellikle teknik ekiptir, süresi kısadır ve çıktısı evet veya hayırdır. Pilot ise operasyonel bir soruya cevap arar: bu çözüm bizim günlük işimizde, gerçek kullanıcılarla, gerçek veriyle işe yarıyor mu? Katılımcısı işi yapan ekiptir, süresi daha uzundur ve çıktısı bir ölçümdür.

Bu ayrımı yapmayan ekipler iki tipik hataya düşer. Birincisi, teknik bir soruya operasyonel bir pilotla cevap vermeye kalkmaktır: haftalarca kullanıcı eğitimi verirsiniz, oysa alıcının merak ettiği tek şey entegrasyonun çalışıp çalışmadığıdır. İkincisi tersidir: alıcı gerçek hayatta işe yarayıp yaramadığını merak ederken siz üç günlük teknik bir kurulum gösterip pilot yaptık dersiniz. Hangi soruyu cevaplayacağınızı baştan söylemek, pilotun yarısını çözer.

Her POC talebine evet demek zorunda değilsiniz

Yaygın tavsiye, güven göstermek için her deneme talebini kabul etmektir. Küçük ekipler için bu tavsiye pahalıdır. Nitelendirilmemiş bir pilot, bir şirketin bedavaya verebileceği en maliyetli şeydir: mühendislik saati, destek saati, satış zamanı ve en önemlisi karar ivmesi. Üstelik talep her zaman ilgi anlamına gelmez; bazen bir erteleme aracıdır, bazen üç tedarikçiyi ucuza karşılaştırma yöntemidir, bazen de alıcının içeride kendini korumak için istediği bir belgedir.

Talebin arkasındaki gerçek soruyu bulun

Reddetmeden önce sorulacak tek bir soru vardır: pilot başarılı olursa ne olacak? Cevap bir imza tarihi ve bir karar mercii içermiyorsa ortada pilot değil, bir keşif gezisi vardır. İkinci soru da işe yarar: bu soruyu pilot yapmadan cevaplayabileceğimiz bir yol var mı? Çoğu zaman vardır — benzer bir kurulumun referansı, sınırlı bir teknik doğrulama veya iyi kurgulanmış bir senaryo gösterimi. ürün demosu nasıl yapılır yazısında anlattığımız gibi, doğru hazırlanmış bir demo pilot taleplerinin önemli bir kısmını daha ucuza karşılar. Karar sürecini altı boyutta okumak isterseniz MEDDIC satış metodolojisi bu nitelendirme için sağlam bir çerçeve verir.

Burada bir istisna var ve önemlidir. Mevcut bir çözümün yerine geçmeye çalışıyorsanız, yani alıcının halihazırda kullandığı bir sistemi değiştirmesini istiyorsanız, atalet o kadar güçlüdür ki pilot çoğu zaman tek kırılma noktasıdır. Bu durumda maliyetine katlanmak akıllıcadır; çünkü rakibiniz başka bir tedarikçi değil, alışkanlıktır.

Yazıya dökülmeyen pilot, pilot değildir

Pilotların büyük kısmı kötü ürün yüzünden değil, mutabakatsızlık yüzünden başarısız olur. Taraflar farklı şeyler bekler, kimse bunu yazmaz ve sonunda başarının tanımını alıcı tek başına yapar. Bunu önleyen şey uzun bir sözleşme değil, tek sayfalık bir mutabakattır. İçinde şunlar bulunmalıdır.

• Cevaplanacak soru: Pilotun sonunda hangi tek soruya cevap verilmiş olacak, açık cümleyle yazılmalı; birden fazla soru varsa pilot değil, proje yapıyorsunuz demektir.
• Başarı kriteri: Ölçülebilir, önceden kabul edilmiş ve alıcının sahiplendiği bir eşik olmalı; kriteri yazan taraf tartışmayı da kazanır.
• Kapsam: Hangi ekip, hangi süreç, hangi veri ve hangi entegrasyon dahil; daha da önemlisi, neyin dahil olmadığı açıkça yazılmalı.
• Veri ve erişim: Gerçek veri mi kullanılacak, kim sağlayacak, ne zaman hazır olacak; veri gecikmesi pilotların en yaygın ölüm sebebidir.
• Roller ve zaman taahhüdü: Alıcı tarafında kimin haftada kaç saat ayıracağı yazılmalı; taahhüt edilmeyen zaman ayrılmaz.
• Takvim ve karar günü: Başlangıç, ara kontrol ve karar toplantısı daha pilot başlamadan takvime konmalı.
• Çıkış koşulu: Hangi durumda pilot erken sonlandırılır; bu madde iki tarafı da korur ve tuhaf biçimde güven artırır.

Bu mutabakatın karşılıklı bir takvim üzerine oturması, sürecin geri kalanını da kolaylaştırır. karşılıklı eylem planı yazısında anlattığımız mantık burada birebir işler: tarihleri iki tarafın birlikte koyduğu bir plan, tek taraflı bir proje planından çok daha fazla tutar.

Başarı kriteri nasıl yazılır?

İyi bir başarı kriterinin üç özelliği vardır: sayısaldır, alıcının kendi diliyle yazılmıştır ve pilot başlamadan önce kabul edilmiştir. Teklif hazırlama süresinin ortalamasının belirgin biçimde kısalması iyi bir kriterdir. Ekibin memnun kalması kriter değildir. Kriteri alıcı yazmalıdır, siz yalnızca ölçülebilir hale getirmelisiniz; çünkü kendi yazdığı eşiği aşan bir alıcı, sonucu içeride savunmak zorunda kalmaz, savunmak ister.

Ölçülmemiş bir öncesi varsa, pilotu kaybettiniz demektir

Pilotların en sinsi hatası burada. İyileşmeyi kanıtlamak için önce mevcut durumun ölçülmüş olması gerekir, ama neredeyse hiçbir ekip bunu yapmaz. Pilot bittiğinde daha hızlı olduk dersiniz, alıcının finans tarafı neye göre diye sorar ve cevabınız yoktur. Taban ölçümü pilotun ilk işi olmalıdır: bugün bu iş kaç dakika sürüyor, ayda kaç kere tekrarlanıyor, kaç kez hata çıkıyor. Bu üç sayı bir saatlik bir çalışmayla toplanır ve sonraki bütün konuşmanın zeminini kurar. Getiriyi rakamla konuşmanın nasıl kurgulandığını değer bazlı satış yazısında ele alıyoruz.

Başarı kriterini pilot bittikten sonra konuşan taraf, o tartışmayı çoktan kaybetmiştir.

Kapsamı daraltmak pilotu neden kurtarır?

Sezgi geniş kapsamdan yanadır: ne kadar çok şey gösterirsek o kadar ikna edici oluruz. Pratikte tersi doğrudur. Geniş kapsamlı pilot, kurulum süresini uzatır, katılımcı sayısını artırır, dolayısıyla dikkat dağıtır ve sonunda hiçbir alanda net bir sonuç üretmez. Dar kapsamlı pilot ise tek bir süreçte tartışmasız bir fark gösterir ve o fark, geri kalan her şeyin argümanı olur.

Pratik ölçü şudur: tek bir süreç, tek bir ekip, gerçek veri. Gerçek veri kısmı pazarlık konusu olmamalı. Temiz demo verisiyle çalışan bir pilot, alıcının kendi verisinin ne kadar dağınık olduğunu gizler ve canlıya geçildiğinde herkesi şaşırtır. Pilotun içinde yaşanan küçük bir veri temizliği krizi, canlıya geçişten sonra yaşanacak büyük krizden çok daha ucuzdur.

Pilota kim katılır?

Pilotun sonucunu ürün kadar katılımcı seçimi belirler. Alıcı tarafında dört rol gerekir: kararı verecek sponsor, süreci içeriden yürüten şampiyon, işi günlük yapan kullanıcılar ve gerektiğinde bilgi teknolojileri veya güvenlik tarafı. Şampiyonun rolü özellikle kritiktir; pilot boyunca sizin göremediğiniz her toplantıda sizi o temsil eder. iç şampiyonu geliştirmek yazısında bu ilişkinin nasıl kurulacağını anlatıyoruz.

Buradaki yaygın tavsiyenin tersini söylemek gerekiyor. Pilota yalnızca en hevesli kullanıcıları koymak cazip gelir ama öğretici değildir; hevesli kullanıcı zaten ikna olmuştur ve zorlukları kendisi aşar. Pilotun içine en az bir şüpheci koyun. Şüpheci kullanıcı size gerçek itirazları pilot sırasında verir; o itirazları satın alma toplantısında duymak çok daha pahalıdır. Kurumsal alıcılarda ayrıca güvenlik ve uyum tarafının erkenden dahil olması gerekir; bu sürecin nasıl yürütüleceğini güvenlik ve uyum soru formları yazısında ele alıyoruz.

Pilot ne kadar sürmeli?

Süre, cevaplamak istediğiniz soruya bağlıdır ve her sürenin bir bedeli vardır. İki hafta cümlesi çoğu zaman bir nezaket ifadesidir, gerçek bir plan değil.

Süre	Cevaplayabildiği soru	Bedeli
Üç-beş gün	Kurulabiliyor mu, veri akıyor mu?	Gerçek kullanım ve alışkanlık görülmez
İki hafta	Günlük akışa oturuyor mu?	Dönem sonu işleri kapsam dışında kalır
Bir ay	Tam bir iş döngüsünü taşıyor mu?	Katılımcı ilgisi düşmeye başlar
İki-üç ay	Ekip gerçekten benimsiyor mu?	Karar ivmesi kaybolur, sponsor değişebilir
Süresiz	Hiçbiri	Pilot sessizce ücretsiz kullanıma dönüşür

Son satır şaka değil. Bitiş tarihi olmayan pilotların önemli bir kısmı, kimsenin kötü niyeti olmadan, aylar süren bedava kullanıma dönüşür ve bir noktadan sonra karar vermek herkes için gereksiz hale gelir. Bitiş tarihi, pilotun en önemli tek alanıdır.

Pilot sürerken satış ekibi ne yapar?

Pilot başladıktan sonra geri çekilmek, satış ekiplerinin en sık yaptığı hatadır. Alıcıya alan tanımak nezaket gibi görünür ama pratikte pilotun ölmesine izin vermektir: kullanım düşer, sorular birikir, kimse çözmez ve sonuçta ürün suçlanır. Pilot dönemi, satış sürecinin en yoğun temas dönemidir.

Sağlıklı bir ritim şöyledir: ilk hafta kurulum ve eğitim, ikinci hafta ara kontrol, sonrasında haftalık kısa bir durum bakışı ve pilotun bitiminde karar toplantısı. Ara kontrol toplantısı bu ritmin kalbidir; kullanım verisini birlikte açıp bakarsınız, hangi kullanıcı giriş yapmamış görürsünüz ve kriterin gerisindeyseniz kalan sürede ne değişeceğine karar verirsiniz. Pilot süresini disiplinli yönetmek, toplam döngüyü de kısaltır; bunun diğer kaldıraçlarını satış döngüsünü kısaltma yazısında topladık.

Ücretsiz pilotun gizli maliyeti nedir?

Ücretsiz pilot, alıcı tarafında hiçbir kayıt bırakmaz. Bedelsiz olan şey bütçelenmez, bütçelenmeyen şey takip edilmez ve takip edilmeyen şey öncelik listesinde sona düşer. Bir tür taahhüt istemek — ister sembolik bir bedel, ister yazılı bir zaman taahhüdü, ister üst yönetimin katıldığı bir açılış toplantısı — pilotun içeride görünür olmasını sağlar.

Ama burada da bir sınır var. Bazı kurumlarda ücretli bir pilotu satın alma sürecinden geçirmek, doğrudan alım yapmaktan daha uzun sürer; sözleşme, tedarikçi kaydı ve onay zinciri devreye girer ve iki haftalık pilot altı haftalık evrak işine dönüşür. Böyle bir alıcıda ücret talep etmek, korumaya çalıştığınız ivmeyi bitirir. Karar kuralı basit: bedel istemek taahhüdü artırıyorsa isteyin, süreci uzatıyorsa istemeyin. Satın alma tarafının işleyişini satın alma departmanıyla müzakere yazısında ayrıntılı ele alıyoruz. Kendi kendine ilerleyen deneme akışlarının mantığını ise deneme sürümünü ücretliye çevirmek yazısında bulabilirsiniz.

Pilot bittiğinde karar nasıl verilir?

Pilotun en büyük riski başarısız olması değildir; başarılı olup kimsenin karar vermemesidir. Bunu önlemenin tek yolu, karar toplantısını pilot başlamadan takvime koymak ve o toplantının gündemini baştan yazmaktır: kriter neydi, sonuç ne oldu, hangi koşulda devam ediyoruz. Toplantıda ürünü tekrar tanıtmayın; yalnızca kriteri ve ölçümü konuşun.

Pilot başarısız olduysa, iyi kaybetmenin de bir yolu vardır. Neyin tutmadığını açıkça yazın, hangi koşul değişirse konunun yeniden açılabileceğini söyleyin ve o koşul için bir tarih bırakın. Pilot sonucunda kazandıysanız, asıl iş yeni başlıyor demektir: pilot kurulumunun canlı kuruluma nasıl döneceği, hangi verinin taşınacağı ve eğitimin nasıl genişleyeceği yazılı olarak devredilmelidir. satıştan müşteri başarısına devir teslim yazısında bu geçişin nasıl kurgulandığını anlatıyoruz.

Pilot programınızın sağlığını hangi göstergeler söyler?

Pilotları tek tek değerlendirmek yanıltıcıdır; program olarak bakınca gerçek ortaya çıkar. Dört gösterge yeterlidir. Pilota giren fırsatların kapanma oranını, pilota girmeyenlerle karşılaştırın; fark yoksa pilot ikna etmiyor, yalnızca geciktiriyordur. Pilot başına harcanan mühendislik ve destek saatini ölçün; bu sayı görünmediği sürece pilotlar bedava sanılır. Pilot süresinin planlanan süreye oranı, kapsam kontrolünüzü gösterir. Son olarak, yarıda kalan pilotların oranı ve nedenleri, nitelendirme kalitenizin en dürüst aynasıdır.

Bu göstergeleri gördüğünde çoğu ekip aynı kararı verir: daha az pilot, daha iyi kurgulanmış pilot. Yılda on beş dağınık pilot yapan bir ekip, altı disiplinli pilot yapan bir ekipten hem daha az kazanır hem daha çok yorulur. Pilotu bir satış aşaması gibi değil, sınırları belli küçük bir proje gibi yönetmek, bu farkı yaratan tek şeydir.

Pilotları yönetmek, aslında bir fırsat kaydının etrafında görev, tarih ve sorumluluk toplamaktır: kriter, katılımcılar, ara kontrol, karar günü ve devir notu aynı yerde durmalıdır. Rocketly'de fırsat aşamaları, görev ve hatırlatmalar, doküman geçmişi ve raporlama tek kayıt üzerinde birleşiyor; ücretsiz hesap açarak kendi pilot akışınızı kurabilirsiniz.