Keşif görüşmesini, yapım başlamadan önce kullanıcıları, görevleri, kısıtları, örnekleri ve yapılmayacakları yakalayarak yapıma hazır promptlara nasıl dönüştüreceğinizi öğrenin.

Kopukluk genellikle toplantı sırasında değil, toplantı sonrası olur. Herkes keşif görüşmesinden uyumlu hissederek ayrılır, ama notlar yapıma uygun şekilde yeterince ayrıntılı değildir. Takımlar "onaylar gerekiyor", "yönetici görünümü" veya "müşteri portalı" gibi ifadeler yazar ve bunun yeterli olduğunu varsayar. Çoğu zaman yeterli değildir.
Kaybolan şey işin günlük gerçekliğidir. Bir görüşme özellikleri kapsayabilir ama işi kimin yaptığı, işlerin hangi sırayla gerçekleştiği, hangi kuralların kesinlikle uygulanması gerektiği ve normal bir haftada başarıyı neyin oluşturduğu gibi ayrıntıları kaçırabilir. Bu bağlam kaybolduğunda, ilk sürüm tahminlere dayanarak inşa edilir.
Bu tahminler zayıf ilk sürümlere yol açar. Bir ekran derli toplu görünebilir ama yanlış problemi çözdüğü için işe yaramaz. "Kullanıcılar istek gönderir" faydalı gibi duyulsa da bu, kullanıcının müşteri mi, saha çalışanı mı yoksa yönetici mi olduğunu veya gönderimden sonra ne olması gerektiğini söylemez.
İyi bir prompt'un sadece bir özellik listesi değil, iş bağlamı içermesi gerekir. Daha güçlü bir devretme şöyle duyulabilir: "Saha personeli mobilden servis talepleri gönderir, denetçiler aynı gün bunları inceler, acil işler normal kuyruğu atlar ve her değişiklik kaydedilmelidir." Bu, geliştiriciye gerçekten işe yarar bir şey verir.
Bu, bir ekip prompt'tan çalışan bir ürüne hızla geçebildiğinde daha da önem kazanır. Koder.ai gibi bir platformla hız gerçek bir avantajdır, ama sadece prompt iş mantığını beraberinde taşıyorsa işe yarar.
Amaç basit. Görüşmeden sonra bir kişi prompt'u okuyup hemen inşa etmeye başlayabilmelidir. Bir transkripti çözmek veya eksik detayların peşine düşmek zorunda kalmamalıdır.
İyi bir devretme insanlarla, özelliklerle değil başlar. Bu adımı atlayın ve ilk yapı genellikle sahibinin belli olmadığı bir dizi ekrana dönüşür. Keşif notlarını kullanışlı hale getirmenin en hızlı yolu: Bu ürünü kim açacak ve ne yapmaya çalışıyorlar?
Her kullanıcı türünü adlandırın, gruplar belirgin görünse bile. Bir kurucu, satış temsilcisi, yönetici, finans sorumlusu ve destek temsilcisi aynı sistemi tamamen farklı nedenlerle kullanabilir. Bu roller bulanıklaştığında prompt belirsizleşir ve ilk sürüm herkese birden hizmet etmeye çalışır.
Her aktörü gerçek işlerle bağlayın. Bir satış temsilcisi anlaşma aşamalarını güncelleyebilir, görüşme notları kaydedebilir ve sonraki adımları kontrol edebilir. Bir yönetici boru hattı rakamlarını gözden geçirebilir, indirimleri onaylayabilir ve haftalık raporlar dışa aktarabilir. Bu farklar her kişinin önce ne görmesi gerektiğini ve neleri değiştirmesine izin verilmesi gerektiğini belirler.
Basit bir ayrım yardımcı olur:
Bu, yaygın bir hatayı önler: her kullanıcıyı bir yönetici gibi inşa etmek. Çoğu insan tam kontrole ihtiyaç duymaz; olağan görevine ulaşmak için en kısa yola ihtiyaç duyar.
Bu ayrıntı, ilk prompt'un kalitesini değiştirir. "Bir CRM kur" belirsizdir. "Satış temsilcileri potansiyelleri günceller, yöneticiler teklif değişikliklerini onaylar, destek hesap geçmişini görüntüleyebilir ve finans kapanmış anlaşmaları dışa aktarır" ürüne gerçek bir biçim verir.
Kullanışlı bir prompt, işi insanların gerçekten yaptığı eylemlere böler. İşte keşif notlarının yapıma dönüşme noktası bu.
Birisi "Siparişleri daha iyi yönetmemiz lazım" derse, adımlar netleşene kadar devam edin. "Siparişleri yönetmek" bir görev değildir. "Bir sipariş oluşturmak, ödeme durumunu incelemek, sevkiyatı onaylamak ve bir onay göndermek" ise görevdir.
Kısa eylem fiilleri bulanık notları temizlemeye yardımcı olur:
Bu fiilleri kullanarak geniş ifadeleri görev satırlarına yeniden yazın. Bir klinik sahibi "personelin rezervasyonları daha hızlı halletmesini istiyorum" diyebilir. Yapıma hazır hali daha net olur: "Resepsiyonist bir randevu oluşturur, doktorun müsaitliğini kontrol eder, slotu onaylar ve hastaya hatırlatma gönderir."
Her görev ayrıca bir öncesi ve sonrası durumu gerektirir. Ne tetikliyor? Sonrasında ne olmalı? Bir yönetici iade onaylarsa, önceden ne var olmalı ve onaydan sonra ne değişmeli? Bu tür küçük detaylar ekranları, düğmeleri, durum etiketlerini ve bildirimleri şekillendirir.
Basit bir zincir iyi çalışır: tetikleyici, eylem, sonuç. Örneğin: "Yeni bir potansiyel geldiğinde satış temsilcisi detayları inceler, önceliği günceller ve ilk yanıtı gönderir." Bu, ilk yapıya dönüştürmesi çok daha kolaydır.
Ayrıca hangi görevlerin ilk günde önemli olduğunu işaretlemek faydalıdır. Eğer üç eylem her gün olurken iki eylem ayda bir gerçekleşiyorsa, önce günlük olanları inşa edin. Bu, ilk sürümü odaklı ve kullanışlı tutar.
İyi bir prompt sadece özellik listesi değildir. Ekiplerin uyması gereken sınırları da içermelidir. Bu sınırlar görüşme sırasında belirsiz kalırsa, ilk sürüm doğru görünüp pratikte başarısız olabilir.
İş kurallarını yalın bir dille yazmaya başlayın. Teknik veya yasal terimlerden kaçının; ekip zaten o dili konuşmuyorsa basit anlatın. "Rol tabanlı onay matrisi" demek yerine "satış temsilcileri indirim taslağı oluşturabilir ama sadece yöneticiler onaylayabilir" deyin.
Bazı kısıtlar tüm yapıyı şekillendirir ve erken yakalanmalıdır. Bu, gizlilik kuralları, veri saklama gereksinimleri ve sektör gereksinimleri gibi hususları içerir. Müşteri verileri belirli bir ülkede veya bölgede kalmak zorundaysa, bunu açıkça belirtin.
Ayrıca değiştirilmemesi gerekenleri kaydetmek yardımcı olur. Birçok ekip yeni bir uygulama ister ama hâlâ birkaç mevcut araca veya manuel adıma bağlıdır. Finans aynı muhasebe sistemini kullanmak zorunda olabilir. Destek, ticket'ların mevcut yardım masasında kalmasını isteyebilir. Bu sınırlar yeni özellikler kadar önemlidir.
Pratik kısıtlar için kısa bir bölüm tutun:
Bu detaylar ilk yapıyı kötü varsayımlardan korur. Aynı zamanda geliştiricinin daha iyi takaslar yapmasına yardımcı olur.
Örnekler belirsiz notları ekiplerin gerçekten inşa edebileceği bir şeye dönüştürür. "Siparişleri yönetmek" veya "potansiyelleri gözden geçirmek" gibi geniş ifadeler gerçek girdi, beklenen çıktı veya kalite standardını göstermez.
Bir normal örnekle başlayın. Son zamanlarda yapılmış, yaygın bir örnek seçin; nadir bir uç durumu değil. Eğer bir ekip potansiyelleri nitelendirecek bir uygulama istiyorsa, onlardan gerçek bir potansiyel kaydı, gelen detaylar ve gözden geçirme sonrası beklenen sonuç gösterilmesini isteyin.
Kullanışlı bir örnek genellikle dört şeyi içerir:
Sonra sık görülen, dağınık bir vaka isteyin. İşte gizli kuralların ortaya çıktığı yer budur. Belki bir form telefon numarası eksik gönderiyor. Belki aynı müşteri iki kez görünüyor. Belki istek belirsiz. Bunu şimdi yakalarsanız, ilk prompt uygulamanın bunu işaretleyip atlayıp veya daha fazla bilgi istemesini söyleyebilir.
Kalite hakkında spesifik olun. "Çalışmalı" yararlı bir hedef değildir. "Çift kayıtları gruplayacak, en yeni iletişim bilgilerini tutacak ve düşük güven skorlu eşleşmeleri inceleme için işaretleyecek" demek geliştiricinin harekete geçebileceği bir hedeftir.
Uygulamada, iki yapıştırılmış örnek genellikle uzun soyut açıklamalardan daha çok yardımcı olur. Bir temiz vaka ve bir dağınık vaka geliştiriciye takip edilecek bir desen verir.
Güçlü bir ilk prompt net sınırlar gerektirir. Bunlar olmazsa, birinci sürüm fazladan fikirlerle dolar ve sonuç dağınık, yavaş veya odaklanmamış olur.
Ürünün şimdilik ne yapmayacağını yazın. Bu, test etmeniz gereken ana akışı korur.
İstenmeyen ama hoş fikirler genellikle kolayca seçilir. Kullanışlı gibi duyulurlar ama uygulamanın çalıştığını kanıtlamak için gerekli değillerdir. Özel bir gösterge panosu, gelişmiş roller, derin raporlama veya cilalı bildirimler daha sonra önemli olabilir. Bunlar sürüm birin ana akışıyla rekabet etmemelidir.
Birkaç soru yardımcı olur:
Manuel çalışma çoğu zaman doğru geçici seçimdir. Potansiyeller günlük manuel olarak incelenebiliyorsa otomatik yönlendirmeye ilk etapta gerek olmayabilir. Faturalar dışa aktarılup manuel gönderilebiliyorsa tam faturalama otomasyonu bekleyebilir. Bu başarısızlık değil, odaklanmadır.
Aynı durum entegrasyonlar için de geçerlidir. Ekipler genellikle ödeme araçları, e-posta platformları, takvim senkronizasyonu ve CRM bağlantıları ister. Eğer ilk yapı tek bir iş akışını doğrulamak içinse, hangi sistemlerin sürüm bir dışında kalacağını not edin.
Örneğin, dahili bir CRM başlangıçta ileti yakalama, durum güncellemeleri ve temel bir görev listesi ile başlayabilir. Yapılmayacaklar arasında çoklu takım izinleri, gelişmiş analizler, mobil push bildirimleri ve dış araçlarla canlı senkronizasyon yer alabilir.
"Sürüm birde dahil değil" genellikle yeterlidir. Net sınırlar ilk sürümü daha hızlı göndermeyi ve test etmeyi kolaylaştırır.
Kullanışlı bir prompt kısa bir brif gibi okunmalı, bir not yığını gibi değil. Her seferinde aynı yapıyı kullanmak devretmeyi çok daha kolay hale getirir.
Sözcükleri yalın ve spesifik tutun. Eğer gerçekten "projeleri daha iyi yönet" demek istemiyorsanız, "takım liderleri bir proje oluşturabilir, görev atayabilir ve işi tamamlandı olarak işaretleyebilir" yazın.
Basit cümleler en iyi sonucu verir. Örnek: "Küçük bir satış ekibi için basit bir CRM oluştur. Aktörler: satış temsilcileri ve bir yönetici. Görevler: potansiyel ekle, anlaşma aşamasını güncelle ve takipleri görüntüle. Kısıtlar: mobil uyumlu, basit gösterge, CSV dışa aktarma. Örnek: bir temsilci 30 saniyeden kısa sürede bir görüşme kaydetmeli. Başarı: ekip aktif anlaşmaları elektronik tablolar yerine takip edebilmeli."
Bu, geliştiriciye tüm ürünü tanımlamadan net bir başlangıç noktası verir.
Küçük bir temizlik hizmeti gibi bir işletmeyi hayal edin. Görüşmede işletme sahibi, "Müşteriler çevrimiçi rezervasyon yapabilmeli, kolay ödeme yapabilmeli ve personelim randevuları basitçe yönetebilmeli" der. Bu faydalıdır ama ilk yapı için hâlâ çok gevşektir.
Yapıma hazır versiyon bu konuşmayı hemen kullanabilecek kadar net bir şeye dönüştürür:
Build a mobile-friendly booking app for a small cleaning service.
Actors:
- Customer: browse services, choose a time, pay, and get a confirmation.
- Staff: view bookings, block unavailable times, and manage refunds.
Rules and constraints:
- Bookings are available only during business hours: Monday to Friday, 9am to 5pm.
- Same-day bookings close at 2pm.
- Refunds are allowed only if the customer cancels at least 24 hours before the appointment.
- The main use case is mobile, so booking and payment screens must be simple on a phone.
Version 1 should include:
- service list with prices
- available time slots
- online payment at checkout
- booking confirmation for customers
- a basic staff view for upcoming jobs
Version 1 should not include:
- loyalty rewards
- advanced reporting
- multi-location support
- live chat
Bu işe yarar çünkü aktörleri net şekilde adlandırır ve belirsiz istekleri gerçek görevlere dönüştürür. Kısıtlar da aynı derecede önemlidir. Sınırlı çalışma saatleri sistemin imkânsız zaman dilimlerini teklif etmesini engeller. İade kuralları ileride karışıklığı önler. Mobil kullanım önceden düzeni şekillendirir.
Dışlanan hedefler yapıyı korur. Bunlar olmazsa, basit bir rezervasyon uygulaması hızla çok daha büyük bir projeye dönüşebilir.
Zayıf bir ilk sürüm genellikle ekibin bunu inşa edememesi yüzünden başarısız olmaz. Başarısız olmasının nedeni prompt'un çok bulanık olmasıdır.
Sık yapılan hatalardan biri, özellik fikirlerini iş kurallarıyla karıştırmaktır. Bir kurucu "Bir gösterge panosu, filtreler ve uyarılar lazım" diyebilir; ama gerçek kural "Sadece yöneticiler belirli bir miktarın üzerindeki iadeleri onaylayabilir" olabilir. Bu kural istek listesinin içinde gömülü kalırsa ilk sürüm şık görünebilir ama yanlış olur.
Diğer bir sorun sadece kurucunun bakış açısından yazmaktır. Kurucular genellikle görmek istedikleri şeyleri anlatır, her kullanıcının ne yapması gerektiğini değil. Bir satış temsilcisi, operasyon yöneticisi ve destek elemanı aynı uygulamayı farklı şekillerde kullanır. Prompt sadece liderlik hedeflerini yansıtıyorsa günlük işler atlanır.
En yaygın hatalar:
"Sipariş onayı" örneğini ele alalım. Net gibi duyulsa da değildir. Kim onaylıyor? Onaylayıcı yoksa ne oluyor? Her sipariş onaylanmalı mı yoksa sadece belli bir eşik üzerindekiler mi? Bu detaylar yapıyı değiştirir.
Ekipler hızlı uygulama oluşturma araçları kullandığında bu boşluklar çabuk ortaya çıkar. Daha temiz bir prompt, insanların gerçekten test edebileceği bir ilk sürüm verir; sadece tepki gösterecekleri bir demo değil.
Prompt'u bir geliştiriciye göndermeden önce kısa bir gözden geçirme yapın. İşte zayıf notların net talimatlara dönüştüğü yer.
Kısa bir örnek farkı ortaya koyar. "Personel rezervasyon oluşturur" zayıftır. Güçlü bir prompt der ki: personel rezervasyon oluşturabilir, düzenleyebilir ve iptal edebilir; yöneticiler istisnaları onaylar; çakışma engellenmeli; sürüm birde faturalama yok.
Bu parçalardan herhangi biri eksikse, durup düzeltin. Kısa ve eksiksiz bir prompt genellikle boşluklarla dolu uzun bir prompt'tan daha iyidir.
Görüşme bitince notları sohbetler, dokümanlar ve hafıza arasında dağınık bırakmayın. Bunları birkaç dakikada okunabilecek tek bir paylaşılan yapı brifine dönüştürün. Bu brif kullanıcıları, ana görevleri, kuralları, örnekleri ve dışlanan hedefleri yalın bir dille yakalamalıdır.
Sonra birinci sürümün kapsamı üzerinde onay alın. Tüm ürün için onay değil. Sadece sürüm birin ne yapacağı ve ne yapmayacağı konusunda anlaşma. Bu küçük adım, bir kişinin demo bekleyip diğerinin neredeyse bitmiş bir şey beklemesi gibi yaygın sorunları önler.
İyi bir ilk sürüm kapsamı dört soruyu yanıtlamalıdır:
Herhangi bir şey üretmeden önce planlama turu yapın. Ham notları kullanılabilir bir yapı prompt'una dönüştürün, eksik detayları kontrol edin ve "basit", "hızlı" veya "kullanıcı dostu" gibi belirsiz kelimeleri çıkarın. Bu kelimeler faydalı gibi görünür ama geliştiriciye ne yapılacağını nadiren söyler.
Örneğin, "müşteri onboarding'ini kolaylaştır" demek yerine şöyle yazın: "Yeni bir müşteri iş adını, iletişim bilgilerini, proje türünü ve bütçeyi tek bir formda gönderip ardından bir onay ekranı alacak."
Koder.ai ile çalışıyorsanız, bu planlama adımı planning mode ile doğal olarak uyum sağlar. Takımlar prompt'u üretmeden önce uygulamayı şekillendirmeye yardımcı olur ve snapshot'lar prompt değişikliklerini test ederken çalışır bir sürümü kaybetmemenizi sağlar.
Amaç ilk günde mükemmel bir prompt değil. Amaç, ilk sürüme doğru yön verecek paylaşılmış, onaylanmış bir prompt'tur. Brif net olduğunda, ilk sürüm değerlendirmesi daha kolay, geliştirmesi daha kolay ve gerçek iş ihtiyacını kaçırma olasılığı çok daha düşüktür.
The best way to understand the power of Koder is to see it for yourself.