Yazmaya başlamadan önce nereden başlamalısınız?
Belgenin kime hizmet edeceğine ve o okuyucunun neyi anlaması gerektiğine karar vererek başlayın. Kısa bir hazırlık süreci, ilk taslağın odaklı kalmasını sağlar.
- Okuyucuyu adlandırın. Ana kitlenizi seçin: ürün kullanıcıları, geliştiriciler, ortaklar veya token holder'lar.
- Belgenin görevini belirleyin. Bir kişinin belgeyi okuduktan sonra neyi anlamış olması gerektiğini yazın.
- Projeyi açıkça tanımlayın. Sorunu, önerdiğiniz çözümü ve projenin mevcut aşamasını belirtin.
- Soruları listeleyin. Bu okuyucu için önemli olan ürün kullanımı, sistem tasarımı ve token rolüyle ilgili soruları ekleyin.
- Kaynak sahiplerini bulun. Her konuyu doğrulayabilecek bir kişi veya belgeyle eşleştirin.
Küçük bir ortaklık ekibini, bir AMA'dan önceki akşam düşünün. Projenin basit bir açıklamasına ihtiyaçları var, birbirinden kopuk iddialar yığınına değil. Onların, belgenin açıklaması gerekenleri listelemesine, ardından paylaşılmadan önce hangi noktaların ekip kontrolüne ihtiyacı olduğunu işaretlemesine yardımcı olurduk.
Ekip projeyi birkaç basit cümleyle açıklayamıyorsa, durun. Bölümleri yazmadan önce ana fikri birlikte netleştirin. Bu küçük duraklama, tekrarlanan açıklamaları ve her kitleye aynı anda hitap etmeye çalışan bir belgeyi önleyebilir.
Okuyuculara proje boyunca bir yol haritası verin
Kullanışlı bir yapı, okuyucunun sorunundan projenin yanıtına, ardından sisteme ve açık sorularına doğru ilerler. Temel açıklamayı erken koyun ki okuyucular projenin amacını aramak zorunda kalmasın.
Esnek bir sıralama kısa bir özetle başlayabilir. Ardından sorunu ve etkilenen kişileri tanıtın. Ürünü ve ana kullanıcı yolculuğunu açıklayın. Sistemin nasıl tasarlandığını gösterin, ardından varsa token'ın rolünü tanımlayın. Projenin durumu, bağımlılıkları ve riskleriyle kapatın. Okuyucuların materyali değerlendirmesine yardımcı olduğunda ekip detaylarını, kaynakları ve açıklamaları ekleyin.
Örneğin, bir okuyucunun ürünün ne yaptığını öğrenmeden önce bir token tahsis tablosu gördüğünü düşünün. Bu tahsislerin neden önemli olduğunu anlamakta zorlanabilir. Ürün açıklamasını ilk sıraya koyun, ardından her token işlevini sistemin gerçek bir parçasına bağlayın.
Bunu bir rota olarak düşünün, zorunlu bir bölüm listesi olarak değil. Belgenin amacına hizmet etmeyen materyali çıkarın ve bir eksiklik okuyucular için kafa karıştırıcı olabilecekse bunu açıklayın. Bir diyagram, kimin hareket ettiğini, neyin aktığını ve kullanıcının ne gözlemleyebileceğini etiketlediğinde akışı netleştirebilir. Yazılı açıklamayla tutarlı olmasına dikkat edin. Token lansman kontrol listesi, belgenin diğer lansman materyalleriyle nasıl uyumlu olduğunu kontrol etmenize yardımcı olabilir.
Belgede neler olmalı ve ne zaman?
Bir konuyu, okuyucuların projeyi anlamasına veya önemli bir iddiayı kontrol etmesine yardımcı olduğunda ekleyin. Aşağıdaki tablo pratik bir başlangıç noktası sunar; projenize ve kitlenize göre ayarlayın.
| Ne alıyorsunuz | Ne zaman eklenmeli |
|---|---|
| Sorun ve çözümün kısa bir özeti | Başlangıçta, okuyucuların projeyi konumlandırabilmesi için |
| Ürün detayları ve kullanıcı rolleri | Sistem tasarımından önce, teknik detaylara bağlam sağlamak için |
| Sistem bileşenleri, akışlar ve bağımlılıklar | Okuyucuların tasarımın nasıl çalıştığını anlaması gerektiğinde |
| Token amacı, arz koşulları ve tahsis detayları | Token, projenin tasarımının bir parçası olduğunda |
| Durum, varsayımlar ve açık sorular | Bir planın canlı bir özellik gibi algılanabileceği her yerde |
| Kaynaklar, ekip sorumlulukları ve açıklamalar | Okuyucuların kontrol etmek isteyebileceği iddiaların yanında |
Her konuya eşit yer vermeniz gerekmez. Teknik bir okuyucu, bileşenler ve bağımlılıklar hakkında daha ayrıntılı bir açıklamaya ihtiyaç duyabilir. Daha geniş bir kitle, ürün yolculuğunu ve token amacını daha basit bir dille isteyebilir. Her iki durumda da, uzmanlık terimlerini ilk geçtikleri yerde tanımlayın.
Bir özellik hâlâ geliştiriliyorsa, canlı değil planlanmış olarak belirtin. Token rakamlarının kesinleşmiş mi yoksa öneri mi olduğunu söyleyin. Bir detay belgenin amacı dışındaysa, okuyucuların tahmin yürütmesine izin vermek yerine bunu açıkça belirtin. Whitepaper ve litepaper yazma sayfamız, yazma desteğinin belgeyi şekillendirmeye nasıl yardımcı olabileceğini açıklar.
Okuyucular her önemli iddiayı kontrol edebilir mi?
Okuyucular, önemli ifadelerin net bir durumu ve kaynağı olduğunda bir belgeyi daha kolay değerlendirebilir. Taslak oluşturma sırasında her iddiayı mevcut bir gerçek, bir tasarım niyeti, bir varsayım veya bir plan olarak işaretleyin. Bu basit ayrım, ekibin gelecekteki çalışmaları insanların zaten kullanabileceği bir şey olarak sunmasını önlemeye yardımcı olur.
Taslağın yanında çalışan bir iddia listesi tutun. Her nokta için ifadeyi, durumunu, kaynağını ve onaylayabilecek kişiyi not edin. Bir ürün özelliğiyle ilgili bir ifade, bir demoya veya ürün belgesine işaret edebilir. Sistem davranışıyla ilgili bir ifade, teknik sorumluya gitmelidir. Bir token açıklaması, ekibin mevcut onaylı bilgilerine göre kontrol edilmelidir.
Diyagramlarda, tablolarda ve gövde metninde aynı adları ve terimleri kullanın. Önemli bir iddianın kaynağı yoksa, ekibin bunu başka bir şekilde destekleyip destekleyemeyeceğini sorun. Gerekli değilse kaldırın. Hâlâ belirsizse, belirsizliği ve nedenini açık bir dille tanımlayın.
İkinci bir kontrol için, yazma grubunun dışından birinden özeti okuduktan sonra projeyi açıklamasını isteyin. Duraksadıkları veya farklı bir açıklama yaptıkları anlara dikkat edin. Bu anlar, belgenin yalnızca daha akıcı bir ifadeye değil, daha net bir açıklamaya ihtiyacı olduğunu gösterir.
Büyük sorulara yol açan küçük taslak tuzakları
Tespit edilmesi en zor sorunlar genellikle bölümler arasındaki boşluklardır. Son bir inceleme, yalnızca yazım ve düzene değil, çelişkilere ve eksik bağlamlara da bakmalıdır.
- Bulanık bir amaç: okuyucular ürünün kime hizmet ettiğini veya neyi değiştirdiğini anlayamaz.
- Gerçekmiş gibi yazılan planlar: gelecekteki özellikler bugün mevcutmuş gibi duyulur.
- Etiketsiz token detayları: okuyucular bir rakamın neyi tanımladığını veya kesinleşip kesinleşmediğini anlayamaz.
- Kontrolsüz iddialar: tasarım, güvenlik veya performansla ilgili ifadelerin adlandırılmış bir kaynağı yoktur.
Basit bir okuma deneyin. Projeye yeni olan bir kişiden neyin canlı olduğunu, neyin planlandığını ve token'ın nasıl uyduğunu açıklamasını isteyin. Ardından onların açıklamasını ekibin amaçladığı açıklamayla karşılaştırın. Kafa karıştıran pasajı düzeltin ve ilgili bölümleri aynı sorun için kontrol edin.
Bir whitepaper bir projeyi açıklayabilir, ancak yasal uyumluluğu sağlayamaz veya bir borsadan kabul alamaz. Bu kararlar, incelemeleri ve gereksinimleri belge yazarının kontrolü dışında olan ilgili danışmanlara ve platformlara aittir.
Bir yazma planına ihtiyacınız varsa, hangi desteğin uygun olduğuna karar vermeden önce whitepaper yazma ücret rehberi ile ilgili işi karşılaştırın.
Proje değiştikçe belgeyi güncel tutun
Yayınlanmış bir belge, birisi onu okuyucuların görebildiği projeyle uyumlu tuttuğunda kullanışlı kalır. Ürün özellikleri, token detayları veya önemli bağımlılıklar değiştiğinde fark edebilecek bir sorumlu seçin.
Net bir sürüm etiketi tutun ve belgeyi her revize ettiğinizde neyin değiştiğini kaydedin. Düzyazıyla birlikte diyagramları, referansları ve tanımlanmış terimleri yeniden kontrol edin. Önceki bir sürüm mevcut kalırsa, okuyuculara sürümler arasında neyin değiştiğini anlamalarına yardımcı olacak kısa bir not verin.
Ekibin belge yayınlandıktan sonra bir ürün akışını güncellediğini düşünün. Sorumlu, yeni akışı belgeyle karşılaştırabilir ve onu tanımlayan her pasajı bulabilir. Ardından teknik sorumludan yedek metni onaylamasını isteyin. Bu kontrol, bakımı yazma planının bir parçası haline getirir, sonradan akla gelen bir şey olmaktan çıkarır.
Web sitesi özetini, token materyallerini ve lansman iletişimlerini belgenin anlatımıyla tutarlı tutun. İkinci bir göz isterseniz, mevcut taslağınızı veya notlarınızı Brand Community'a gönderin. Hedef okuyucuyu ve ürün, teknik ve token detaylarını onaylayabilecek kişilerin adlarını ekleyin. Taslağı inceleyerek ve yazmadan önce çözülmesi gereken soruları belirleyerek başlayacağız. Daha fazla pratik okuma için Blog sayfasını ziyaret edebilirsiniz.
Nasıl çalışır
- Okuyucuyu ve amacı belirleyinBelgenin kimin için olduğunu ve neyi anlamaları gerektiğini yazın. Canlı, planlanmış veya kararsız olanı işaretleyin.
- Kaynakları ve sahipleri toplayınÜrün notlarını, teknik materyali ve onaylanmış token detaylarını toplayın. Her konuyu onaylayabilecek bir kişi belirleyin.
- Taslağı düzenleyinOkuyucunun ana sorularını net bir sıraya koyun. Taslak oluşturmadan önce eksik bilgileri çözün.
- Taslak oluşturun ve kontrol edinSade bir dil kullanın ve varsayımları etiketleyin. İlgili ekip üyelerinden iddialarını kaynak materyale göre kontrol etmelerini isteyin.
- Revize edin ve bakımını yapınYorumları çözün, terimleri kontrol edin ve onaylanan sürümü kaydedin. Proje detayları değiştiğinde belgeyi inceleyecek birini atayın.
Sık sorulan sorular
Whitepaper ve litepaper arasında nasıl seçim yapmalıyım?
Seçimi, okuyucuların neyi anlaması gerektiğine göre yapın. Bir whitepaper, tasarımı, mekaniği ve varsayımları açıklamak için daha fazla alan sunarken, bir litepaper daha kısa bir genel bakış sağlar. Örneğin, bir okuyucunun bir sistem akışını takip etmesi gerekiyorsa, kısa bir özet tek başına sorularını yanıtlamayabilir.
Bir kripto whitepaper yayınlanmadan önce kim kontrol etmeli?
Ürün, teknik tasarım ve token detaylarından sorumlu kişilerden kendi konularını incelemelerini isteyin. Ardından yazma grubunun dışından birini özeti okumaya ve projeyi size geri anlatmaya davet edin. Onların soruları, yayın öncesinde net olmayan terimleri veya eksik bağlamı ortaya çıkarabilir.
Bir whitepaper hazır olmayan özellikleri nasıl tanımlamalı?
Bunları planlanmış olarak etiketleyin ve okuyucunun anlayışını etkilediğinde neyin çözülmemiş olduğunu belirtin. Mevcut yetenekleri yol haritasından ayırın. Örneğin, okuyucular henüz kullanamıyorsa bir özelliği planlanmış olarak tanımlayın, zaten mevcutmuş gibi yazmak yerine.
Taslak oluşturmadan önce ne hazırlamalıyım?
Kısa bir proje açıklaması, ürün ve teknik materyaller, varsa güncel token bilgileri ve hedef okuyucuyu hazırlayın. Her konuyu onaylayabilecek kişileri adlandırın. Basit bir kaynak listesi, ekibin taslak oluşturma tekrarlanan bir doğrulama sürecine dönüşmeden önce soruları yanıtlamasına yardımcı olabilir.
Ana belge ne kadar teknik detay içermeli?
Hedef okuyucunun ana bileşenleri, önemli bağımlılıkları ve kullanıcıya yönelik akışı anlaması için yeterli detayı ekleyin. Uzmanlık terimlerini ilk kullanımda tanımlayın. Daha derin detaylar başka bir yere aitse, okuyucuları ilgili materyale yönlendirin ve belgenin özetinin onunla çelişmediğinden emin olun.
Bir whitepaper, bir projenin uyumlu veya onaylı olduğunu gösterir mi?
Hayır. Bir whitepaper bir projeyi tanımlar; bir düzenleyicinin veya borsanın onu nasıl değerlendireceğine karar vermez. Bu incelemeler, ilgili otoritenin veya platformun gereksinimlerini takip eder. Örneğin, bir token'ın rolünün net bir açıklaması, kendi başına bir onay veya yasal görüş değildir.
Projenizi anlatın
Dört hızlı soruyu yanıtlayın, yöneticiniz bir saat içinde plan, zamanlama ve fiyat aralığı göndersin. Her şey gizli kalır.
Form yükleniyor…