Kurumsal alıcılara yapay zekâ ile oluşturulmuş bir ürünü basitçe nasıl açıklayacağınızı öğrenin: barındırma, erişim kontrolü, dışa aktarma ve dağıtım hakkında net noktalar.
Bir alıcı "yapay zekâ ile oluşturuldu" dediğinizde genellikle değeri duymadan önce riski duyar. Ürünün çalışıp çalışmadığını sormaktan öte, herhangi bir kurumsal yazılımda soracakları soruları sorarlar: ne teslim ediliyor, erişimi kim kontrol ediyor, nerede çalışıyor ve daha sonra taşınmak isterlerse ne olur?
Bu yüzden ilk açıklama bir ürün demosu gibi değil, satın alma diliyle olmalıdır. Ajantlardan, model isimlerinden veya uygulamanın nasıl oluşturulduğuna dair soyut konuşmalardan başlarsanız, alıcılar temel konuların hâlâ belirsiz olduğunu varsayabilir. İhtiyaçları olan, hukuki, güvenlik ve finans ekiplerine sizin sunumunuzu yeniden yazdırmadan tekrarlayabilecekleri basit gerçeklerdir.
Çoğu satın alma ekibi kısa bir pratik soru listesine cevap arar. Tam olarak ne satın alıyoruz? Kim kullanabilir? Kodu veya veriyi dışa aktarabilir miyiz? Bugün hangi barındırma seçenekleri var? Hangi parçalar satıcıya bağlı kalıyor?
Bu sorular abartı ile ilgili değil. Sahiplik, kontrol ve yedek plan seçenekleriyle ilgili. Kurumsal alıcılar sizi normal yazılım satıcılarıyla karşılaştırır. Açıklamanız sıradışı veya belirsiz gelirse onay yavaşlar.
Koder.ai gibi bir platform iyi bir örnektir. Sohbetten web, sunucu ve mobil uygulamalar oluşturabilir, ancak bu alıcının önce işlemesi gereken ilk şey değildir. Alıcının duyması gereken, sonucun açık dağıtım seçenekleri olan bir yazılım varlığı olduğu, kaynak kodunun dışa aktarılabildiği ve tanımlı bir barındırma düzeninin olduğu bilgisidir. Bu netleşince, yapay zekâ kısmı çok daha az riskli görünür.
Kısa bir özet çok iş yapar. Alıcılara jargonu açıklamaya uğraşmadan bir toplantıda yüksek sesle tekrarlayabilecekleri bir ürün versiyonu verir.
En iyi özetler sıradan dille dört temel soruyu yanıtlar: ürün ne yapar, kim içindir, nerede çalışır ve satıcı lansmandan sonra neyi yönetir. Bu noktaların biri eksikse, alıcılar boşlukları kendileri doldurur ve bu genellikle sürtüşme yaratır.
Özet üç veya dört cümleyle sınırlı olsun. Teknolojiden önce iş görevinden başlayın.
Örneğin: Koder.ai, ekiplerin sohbet yoluyla web, sunucu ve mobil uygulamalar oluşturmasına yardımcı olan bir platformdur. Kurucular ve uzun bir geliştirme döngüsü istemeyen işletmeler tarafından kullanılır. Platform AWS üzerinde çalışır ve veri gizliliği ile sınır ötesi transfer gereksinimlerini desteklemek için uygulamaları farklı ülkelerde çalıştırabilir. Ayrıca dağıtım, barındırma, özel alan adları, anlık görüntüler, geri alma ve kaynak kodu dışa aktarımı desteklenir.
Bu işe yarar çünkü somuttur. Bir alıcının platformun arkasındaki sistemi anlamasını zorunlu kılmaz; önce sonucu anlarlar.
Basit bir test yardımcı olur: Satın alma ekibinden biri özetinizi toplantıda çevirmeden yüksek sesle okuyabilir mi? Eğer hayırsa, tekrar basitleştirin.
Alıcılar barındırma sorduğunda genellikle birkaç temel noktaya düz yanıtlar isterler. Uygulama nerede çalışıyor? Hangi bölge seçenekleri mevcut? Bugün barındırma kurulumundan kim sorumlu? Bu kurulum daha sonra değiştirilebilir mi?
Şu an doğru olanla başlayın. Bulut sağlayıcısını ve geçerli dağıtım modelini adlandırın. Örneğin Koder.ai hakkında konuşuyorsanız, platformun AWS üzerinde çalıştığını ve uygulamaları gizlilik ve veri transferi gereksinimlerini karşılamak için farklı ülkelerde çalıştırabildiğini söylemek adildir. Platformun küresel olduğunu söyleyip bununla bırakmaktan daha nettir.
Veri konumu dilini de basit tutun. Alıcılar uygulamanın nerede çalıştığını ve bunun iç politika ile eşleşip eşleşemeyeceğini bilmek ister. Bölge seçimini destekliyorsanız bunu doğrudan söyleyin. Desteklemiyorsanız bunu da doğrudan söyleyin.
Bir ayrıntı ekiplerin beklediğinden daha fazla önemlidir: şu anki gerçekliği gelecekteki planlardan ayırın. Alıcılar bir şeyin planlandığını duymaktan rahatsız olmaz. Bir gelecekteki seçeneğin sanki zaten varmış gibi sunulmasından rahatsız olur. Net sınırlar güven oluşturur.
Alıcı dostu bir açıklama şöyle olur: bugün uygulama AWS üzerinde barındırılıyor ve dağıtım müşterinin ihtiyaç duyduğu ülkeye göre uyarlanabilir. Yeni barındırma modelleri daha sonra eklenirse, bunlar mevcut seçenekler değil gelecekteki seçenekler olarak tanımlanmalıdır.
Erişim kontrolünü finans veya hukuk ekibinin ilk okumada takip edebileceği dille açıklayın. Teknik etiketlerle başlamayın. İnsanlarla, eylemlerle ve onaylarla başlayın.
Alıcılar kimin giriş yapabileceğini, farklı kullanıcıların neler yapmaya yetkili olduğunu ve biri katıldığında, rol değiştirdiğinde veya ayrıldığında erişimin ne kadar hızlı değiştirilebileceğini bilmek ister. Ürününüz farklı izin seviyelerine sahipse, bunları basit terimlerle açıklayın. Örneğin bir kişi ayarları yönetebilir, bir başkası uygulamayı düzenleyebilir, bir başkası yalnızca inceleyip onaylayabilir.
Amaç sofistike görünmek değil, sorumluluğu açık etmek. Satın alma, her kullanıcının tam kontrole sahip olmadığını ve hassas eylemlerin sınırlandırılabileceğini görmek ister.
Erişim yaşam döngüsünü normal dille açıklamak da yardımcı olur. İyi bir açıklama yeni bir kullanıcı için erişimin nasıl verildiğini, birisi takım değiştirince nasıl güncellendiğini ve artık gerekmediğinde nasıl kaldırıldığını kapsar. Taşeronlar veya dış ortaklar için geçici erişim varsa, bunu da açıklayın.
En güvenli kural basittir: bugün gerçekten var olan kontrolleri açıklayın. Ekibiniz daha sonra daha ayrıntılı izinler eklemeyi planlıyorsa bunu planlanmış olarak etiketleyin. Alıcılar abartılı bir cevaptan ziyade kesin bir güncel cevap duymayı tercih eder.
Bu genellikle satın alma incelemesinin tonunu değiştiren noktadır. Hukuki ifadelerin altında alıcının sorduğu tek basit soru şudur: bu platformu kullanmayı bıraktığımızda neye sahip oluruz ve neyi yanımıza alabiliriz?
Bunu süslü laflardan kaçınarak yanıtlayın. Kaynak kodu dışa aktarımı varsa bunu erken söyleyin. Koder.ai kaynak kodu dışa aktarımını destekler ve bu, alıcılara platform dışında geliştirmeye devam etme yolunu açıkça verir.
Aynı şekilde, uygulamanın kendisini platform etrafındaki hizmetlerden ayırın. Dışa aktarılabilir kod her zaman barındırılan hizmetlerin, iş akışlarının veya platform kolaylıklarının birebir taşınabileceği anlamına gelmez. Alıcı bu ayrımı açıkça anlarsa iyi olur.
Örneğin uygulama kodu dışa aktarılabilirken, platform tarafından yönetilen barındırma, yerleşik dağıtım akışı, özel alan adı ayarları, anlık görüntüler veya geri alma satıcı yönetimli ortamın bir parçası olarak kalabilir; müşteri bu parçaları başka yerde yeniden oluşturmak zorunda kalabilir.
Bu, satın alma tarafından gerçekten kullanılabilecek bir dildir. Hem taşınabilirliği abartmaktan hem de satıcı bağımlılıklarını hafife almaktan kaçınır.
Bir alıcı devralma işleminin nasıl çalıştığını sorarsa, cevabı kısa tutun. Nelerin dışa aktarıldığını, nelerin taşınması gerektiğini ve taşınmadan sonra hangi testlerin yapılacağını açıklayın. Dramatik bir çıkış hikâyesine gerek yok; inandırıcı bir süreç yeterlidir.
Satın alma incelemeleri, alıcı birkaç net seçeneği karşılaştırabildiğinde daha hızlı ilerler; sizin mimarinizi çözmeye çalışmak yerine.
En basit yoldan başlayın. Satıcının uygulamayı barındırıp dağıtabildiğini önce söyleyin. Koder.ai platformunun bir parçası olarak dağıtım ve barındırma sunduğu için, bu hızlı başlamak ve daha az iç kurulum isteyen ekipler için kolay bir başlangıçtır.
Sonra kontrol yolunu açıklayın. Kaynak kodu dışa aktarımı varsa, alıcılar tek bir geleceğe bağlı olmadıklarını bilir. Satıcı tarafından yönetilen bir kuruluma başlayabilir ve yine de uygulamayı daha sonra taşımak için bir yol tutabilirler.
Burada birkaç ürün detayı önemlidir çünkü teknik olmayan alıcılar için anlaşılması kolaydır. Özel alan adları uygulamanın alıcının markası altında görünmesine yardımcı olur. Anlık görüntüler ve geri alma değişikliklerin riskini azaltır çünkü ekip bir şey bozulursa önceki çalışan sürüme dönebilir.
Bu noktalar uzun teknik açıklamalardan daha faydalıdır. Bir alıcının dağıtım teorisi dersine ihtiyacı yok; seçimlerinin ne olduğu, pratikte nasıl göründüğü ve ne kadar esnekliklerinin olduğu bilgisini ister.
Temiz bir özet şöyle seslenir: hızlı başlamak için satıcı-barındırmalı dağıtımla başlayabilirsiniz, markalı bir deneyim için özel alan adı kullanabilirsiniz ve yine de kaynak kodu dışa aktarımıyla bir yedek yol tutabilirsiniz. Bir güncelleme sorun çıkarırsa, anlık görüntüler ve geri alma kararlı sürüme geri dönmeyi sağlar.
Güçlü bir alıcı özeti kısa olmalıdır. Slayt gösterisi değildir ve teknik bir doküman da değildir. Satın alma ekibinin muhtemelen soracağı ilk soruları yanıtlayan bir sayfalık nottur.
Bunu oluşturmak için ürün, güvenlik ve operasyonlardan cevapları toplayın, sonra bu cevapları günlük dile çevirin. Bir cümle hâlâ sadece ürün ekibinin anlayacağı şekildeyse, henüz hazır değildir.
Çoğu özetin yalnızca dört bölüme ihtiyacı vardır:
Bir şey hâlâ teyit edilmemişse, belirsiz ifadelerle gömmek yerine açıkça açık olarak etiketleyin. Örneğin "SSO detayları teyit edilecek" gibi bir not, çok az şey söyleyen cilalı bir paragrafa göre çok daha iyidir.
Notu göndermeden önce, teknik olmayan bir meslektaşınızla test edin. Onlara neyin belirsiz geldiğini ve bir sonraki olarak neyi soracaklarını sorun. Temel terimlerde duraksıyorlarsa, satın alma görmeden önce bu kısımları tekrar yazın.
Küçük bir satış ekibinin dahili bir CRM gerektiğini düşünün. Kurucu uzun bir özel geliştirme istemediği için ekip sohbet yoluyla Koder.ai kullanarak uygulamayı oluşturur ve geleneksel sürece göre çok daha hızlı çalışan bir ürün elde eder.
Satın alma süreci başladığında, yararlı sorular basittir. Nerede çalışıyor? Kim kullanabilir? Şirket daha sonra kodu dışarı alıp başka bir ekipten uygulamayı sürdürmesini isteyebilir mi?
En iyi cevap derin teknik bir tur değildir. Kısa bir alıcı özeti, sade İngilizceyle hazırlanmış bir açıklamadır. CRM'in Koder.ai üzerinden dağıtıldığını ve barındırıldığını, platformun AWS üzerinde çalıştığını ve uygulamaların alıcının gizlilik gereksinimlerine uyan ülkede çalıştırılabileceğini söyleyebilirsiniz. Erişimin şirketin kendi iç kurallarına göre onaylanmış personele sınırlı olduğunu söyleyebilirsiniz. Ayrıca kaynak kodu dışa aktarımının mevcut olduğunu, böylece şirketin gerektiğinde platform dışında geliştirmeye devam edebileceği bir yolun olduğunu söyleyebilirsiniz.
Böyle bir açıklama abartmaz. Basitçe alıcının karşılaştırabileceği somut bir ürün verir. Temeller netleşince, takip soruları daha kolay ve daha odaklı olur.
Çoğu duraklamış inceleme ürünün kendisinden kaynaklanmaz. Açıklama biçiminden kaynaklanır.
Sorun genellikle demo basit görünürken satın alma görüşmesinin belirsizleşmesiyle başlar. Bir ürün bir toplantıda anlaşılır görünüp sonraki görüşmede nedense tanımlanamaz hale gelince güven hızla düşer.
Birkaç hata sık tekrar eder. Ekipler işlevsel adımlar yerine model isimleri ve mimariyle başlar. Bir ürünün güvenli olduğunu söylerler ama bunun günlük anlamda ne demek olduğunu açıklamazlar. Satıcı bağımlılıklarını — örneğin barındırılan altyapı veya platforma özgü hizmetler — söylemekte gecikirler. Farklı toplantılarda farklı cevaplar verirler. Veya henüz var olmayan dağıtım seçeneklerine ima yaparlar.
İyi bir iç kontrol basittir: bir satın alma yöneticisi açıklamanızı hukuk, güvenlik ve finans ekiplerine yeniden yazmadan aktarabilir mi? Eğer hayırsa, mesaj hâlâ çok bulanık.
İki tarzı karşılaştırın. Zayıf versiyon "platform birçok ajan ve ileri modeller kullanır" gibi bir şey der. Güçlü versiyon ise "platform gereksinimlerden uygulama oluşturur, barındırma ve dağıtım sağlayabilir, kaynak kodu dışa aktarımı sunar ve alıcının incelemesi için net bir işletme modeli verir" der. Biri etkileyici, diğeri satın alınabilir görünür.
Daha fazla detay ekleyerek bir tedarik çağrısını kazanmazsınız. Ürünü açıklamayı kolaylaştırarak kazanırsınız.
Toplantıya ürünün ne yaptığını, nerede çalıştığını, erişimi kimlerin kontrol ettiğini, müşterinin neyi dışa aktarabileceğini ve şu an hangi dağıtım seçeneklerinin mevcut olduğunu kapsayan kısa bir özetle girin. Alıcıların muhtemelen bilmediği terimler (ör. özel alan adı, geri alma veya kaynak kodu dışa aktarımı) duyulacaksa kısa bir sözlük getirin.
Ayrıca gerçekçi bir devralma senaryosu hazırlamak yardımcı olur. Örneğin: alıcı satıcı-barındırmalı dağıtımla başlarsa ve daha sonra kendi ekibinin devralmasını isterse, ne dışa aktarılır, ne yeniden oluşturulması gerekir ve kodu kim alır? Net bir süreç, güven verici bir sözden daha iyidir.
Koder.ai kullanıyorsanız, özet çok kısa kalabilir: platform sohbetten web, sunucu ve mobil uygulamalar oluşturur, AWS üzerinde çalışır, dağıtım ve barındırmayı destekler, özel alan adları sunar, anlık görüntüler ve geri alma içerir ve kaynak kodu dışa aktarımı sağlar. Bu, satın alma ekibine yazılımın nasıl yapıldığı tartışmasına girmeden karşılaştıracakları somut bir şey verir.
Görüşmeyi tek bir doğrudan soru ile bitirin: onay için hâlâ ne eksik? Bu soru sık sık belirsiz bir endişeyi kısa bir listeye çevirir ve haftalar kazandırır.
İş sonucuyla başlayın. Ürünün ne yaptığını, kimler için olduğunu, nerede çalıştığını ve lansmandan sonra satıcının neyi yöneteceğini söyleyin. Koder.ai için bu, sohbetten web, sunucu ve mobil uygulamalar oluşturduğunu, AWS üzerinde çalıştığını, barındırma ve dağıtımı desteklediğini ve kaynak kodu dışa aktarımı sunduğunu açıklamak demektir.
Basit ve olgusal tutun. Koder.ai AWS üzerinde çalışır ve uygulamalar gizlilik ve sınır ötesi veri transferi gereksinimlerini desteklemek için farklı ülkelerde çalıştırılabilir. Şu an mevcut olanı söyleyin; gelecekteki barındırma planlarını şu an varmış gibi sunmayın.
Erişimi insanlara ve onay süreçlerine göre açıklayın, teknik etiketlerle başlamayın. Alıcılar kimin giriş yapabildiğini, her kullanıcının neler yapabildiğini ve birinin görevi değiştiğinde veya ayrıldığında erişimin nasıl eklendiğini, değiştirildiğini veya kaldırıldığını bilmek ister.
Kaynak kodu dışa aktarımı, alıcıya net bir yedek yol verir. Daha sonra uygulamayı platformun dışına taşımak ve başka bir ekip tarafından sürdürülmesini istemek isterlerse, kodu alıp başka yerde geliştirmeye devam edebilirler.
Her zaman değil. Dışa aktarılabilir kod uygulamanın kendisini verir, ancak satıcı tarafından yönetilen hizmetler aynı şekilde taşınmayabilir. Barındırma, dağıtım akışı, özel alan adı ayarları, anlık görüntüler ve geri alma gibi özellikler platforma bağımlı olabilir; müşteri bunları başka yerde yeniden oluşturmak zorunda kalabilir.
En açık varsayılan seçenek, hız ve sadelik için satıcı tarafından barındırılan dağıtımdır. Koder.ai ile alıcılar platform barındırması ve dağıtımıyla başlayabilir, özel bir alan adı kullanabilir ve yine de kaynak kodu dışa aktarımıyla bir yedek yol tutabilirler.
Güncellemelerin riskini azaltırlar. Bir değişiklik sorun çıkardığında, anlık görüntüler ve geri alma ekibin her şeyi canlı tamir etmek zorunda kalmadan önce önceki çalışan bir sürüme dönmesini sağlar.
Dört basit soruyu günlük dilde yanıtlamalıdır: ürün ne yapar, nerede çalışır, erişim nasıl işler ve müşteri daha sonra neleri dışa aktarabilir veya taşıyabilir. Kısa ve procurement yöneticisinin tekrar edebileceği uzunluktan daha uzun olmamalıdır.
Genellikle AI terimleriyle başlamak yerine temel işletme gerçekleriyle başlamak gecikmelere neden olur. Ayrıca barındırma konusunda belirsizlik, satıcı bağımlılıklarının atlanması veya farklı toplantılarda farklı cevaplar verilmeye başlanması onay sürecini yavaşlatır.
Pratik olun. Neyin dışa aktarıldığını, kimin aldığına, platform dışında yeniden oluşturulması gereken parçalara ve taşındıktan sonra hangi testlerin yapılacağına dair kısa bir açıklama yapın. Dramatik bir ayrılma hikâyesine gerek yok; inanılır bir süreç yeterlidir.
