Web3 yapınız öncelikle hangi kullanıcı eylemlerini desteklemeli?
Bir Web3 yapısı, bir teknoloji listesiyle değil, bir kişinin ne yapması gerektiğiyle başlamalıdır. Bu seçim, ekibinizin hangi parçaların zincir üzerinde, hangilerinin arayüzde olması gerektiğine ve neyin daha sonraya bırakılabileceğine karar vermesine yardımcı olur.
Örneğin, bir token projesi tanımlanmış token davranışı ve dağıtım desteği gerektirebilir. Cüzdan bağlantılı eylemlere sahip bir ürün, kişilerin bilgileri görüntülemesine veya işlem göndermesine olanak tanıyan bir dApp gerektirebilir. Bir topluluk deneyimi bir Telegram mini uygulamasına uyabilir. Bu kullanıcı eylemlerini belirli yazılım parçalarına dönüştürüyor ve her parçanın ihtiyaç duyduğu hizmetleri veya erişimleri not ediyoruz.
Şunu sorarak başlayabilirsiniz: yeni bir kullanıcı ne görür, ne yapabilir ve sonra ne olmalıdır? Ardından beklenen davranışı sade bir dille tanımlayın. Token oluşturma ve dağıtımını token geliştirme ile eşleyebiliriz. Veya bir etkileşimin arkasındaki kurallara akıllı sözleşme geliştirme ile bakabiliriz. Kullanıcıya yönelik yolculuk için dApp geliştirme planın doğru parçası olabilir.
Bu, ilk görüşmeyi pratik tutar. Temel lansman özelliklerini, bağımlılıkları ve daha sonraki fikirleri ayrı ayrı belirleriz, böylece ekibiniz geliştirme başlamadan önce seçenekleri inceleyebilir.
Net bir yapı sınırıyla yol haritası güncellemesi daha kolaydır
Net bir sınır, ekibinizin neyin inşa edildiğini ve neyin hala bir karar gerektirdiğini açıklamasına olanak tanır. Ayrıca çalışmayı inceleyen kişilere kontrol edecek somut bir şey verir.
Bir elçi programı sorumlusunun bir yol haritası güncellemesi yayınlanmak üzereyken bunu düşünün. Ekip bir token özelliğinden ve bir Telegram deneyiminden bahsetmek istiyor, ancak tam kullanıcı yolculuğu hala şekilleniyor. Bir elçinin ne yapabilmesi gerektiğini, ürünün hangi ağa ihtiyacı olduğunu ve hangi mevcut hizmetlerin bağlanması gerektiğini sorardık. Ardından onaylanmış özellikleri açık sorulardan ayırırız, böylece güncelleme bir varsayımdan ziyade bir planı tanımlar.
Birkaç parçaya sahip bir ürün için, bu parçaların nasıl buluştuğunu kaydederiz. Bir sözleşme belirtilen davranışı sağlayabilirken, bir arayüz kullanıcılara onunla etkileşime geçmenin bir yolunu verir. Bir Telegram mini uygulaması ayrı bir yolculuğu yönetebilir. Ekibin ayrıca halka açık bir ürün sitesine ihtiyacı varsa, planı Web3 web sitesi geliştirme ile bağlayabiliriz. Cüzdan davranışı merkezi olduğunda, kripto cüzdan geliştirme kendi kararlarını ve incelemesini gerektirebilir.
Bu tür bir erken görüşme daha sonraki gidiş gelişleri önleyebilir. Yol haritanız kullanışlı kalır ve yapı paylaşılan beklentilerle başlar.
Ekip ne almayı bekleyebilir?
Proje için kararlaştırılan yazılım parçalarını ve ekibinizin çalışmayı incelemesi ve sürdürmesi için ihtiyaç duyduğu bilgileri alırsınız. İçeriği, bir özellik listesini eksiksiz bir plan olarak ele almaktansa, geliştirme başlamadan önce netleştiririz.
Özetinize bağlı olarak, çalışma şunları içerebilir:
- Kararlaştırılan sözleşme, uygulama veya mini uygulama bileşenleri için kaynak kodu.
- Seçilen ortam için dağıtım veya yapılandırma talimatları.
- Hangi beklenen davranışların kontrol edildiğini gösteren test senaryoları ve notlar.
- Entegrasyon ayrıntıları, varsayımlar ve pratik teslimat notları.
- Çalışmayı devralacak kişilerle son bir inceleme toplantısı.
Özellikleri, erişimleri, bağımlılıkları ve kabul kriterlerini toplamak için bir başlangıç kontrol listesi kullanırız. 2 inceleme noktası üzerinde anlaşırız. İlki, planı onaylamak için uygulamadan öncedir. İkincisi, sonucu kararlaştırılan kriterlere göre kontrol etmek için teslimattan öncedir. Çalışma devam ederken bir uyumsuzluğu gündeme getirebilirsiniz. Böylece, bunu yalnızca sonunda keşfetmezsiniz.
Diyelim ki ekibinizin zaten bir dApp'i var ancak yanında bir AI iş akışı istiyor. Bunu AI ajan geliştirme aracılığıyla ayrı bir parça olarak tartışabiliriz, böylece kullanıcıya yönelik ürün ve otomatik iş akışının farklı beklentileri olur.
Yapının ilerlemesine yardımcı olan dört karar
Yararlı bir Web3 geliştirme planı, kod inşa edilmeye hazır olarak ele alınmadan önce dört pratik soruyu yanıtlar. Net yanıtlar, hem ürün ekibiniz hem de bizim için incelemeleri kolaylaştırır.
| Karar | Ne yazılmalı |
|---|---|
| Ağ | Hedef zincir ve varsa mevcut sözleşme veya uygulama adresleri. |
| Kullanıcı yolculuğu | Her kullanıcı rolünün gerçekleştirebilmesi gereken eylemler. |
| Bağlantılar | Gerekli cüzdanlar, API'ler ve diğer hizmetler ile erişimi kimin sağlayabileceği. |
| Kabul | Ekibinizin, kararlaştırılan her özelliği onaylamadan önce neyi kontrol edeceği. |
Bu ayrıntıları ekibinizle birlikte inceler ve yanıtlanmamış öğeleri kaydederiz. İki makul teknik yol varsa, ödünleşimleri günlük dilde açıklarız. Ardından seçtiğiniz yolu not ederiz. Ayrıca bir test ortamının, tasarım dosyalarının veya mevcut bir deponun mevcut olup olmadığını kontrol ederiz.
İlk haftada, yararlı hedef, özellikler ve inceleme noktaları hakkında ortak bir anlayıştır. Aceleyle hazırlanmış bir vaatler listesi değildir. Erişim veya bir ürün kuralı eksikse, bunu açık bir karar olarak işaretleriz. Bu, ekibinize net bir sonraki eylem verir ve uygulamanın gerçekten yaptığınız seçimlere dayanmasını sağlar.
Ürün şekillenirken dış bağımlılıkları görünür tutun
İyi bir yapı, kararlaştırılan davranışı test edilebilir kılar ve ekibinize kullanılabilir bir teslimat bırakır. Erken netleştirilmesi gereken ana şeyler ürün kuralları, entegrasyon erişimi ve her özelliği kimin inceleyeceğidir.
Zincir araçları, cüzdan davranışı, Telegram inceleme kararları ve üçüncü taraf hizmet kullanılabilirliği bizim kontrolümüz dışındadır. Onların onayını veya kesintisiz çalışmasını vaat edemeyiz. Birlikte kararlaştırdığımız uygulamaya, kontrollere ve teslimata bağlı kalabiliriz. Ayrıca bağımlılıkları gizli varsayımlar haline gelmeden önce belirleriz.
Başlamak için Brand Community'a kullanıcı yolculuğunu ve hedef zinciri içeren kısa bir ürün özeti gönderin. İstenen özellikleri ve varsa mevcut depo veya tasarım referanslarını ekleyin. Yararlı üç başlangıç ayrıntısı, kullanıcıların ne yapması gerektiği, hangi mevcut hizmetlerin bağlanması gerektiği ve ekibinizin çalışmayı incelemek için ne kullanacağıdır. Bir yanıt hala açıksa, onu da ekleyin.
Paylaştıklarınızı inceleyecek ve yanıtlanmamış noktaları netleştireceğiz. Ardından önerilen özellikleri, inceleme anlarını ve teslimatı belirleyeceğiz. Önce neyi inşa edeceğinize karar vermeden önce değerlendirebileceğiniz somut bir planınız olacak.
Sık sorulan sorular
Bir Web3 yapısını görüşmeden önce ne göndermeliyim?
Kısa bir ürün açıklaması, onu kullanacak kişiler ve atmaları gereken eylemleri gönderin. Hedef zinciri, varsa mevcut kodu veya sözleşmeleri, tasarım referanslarını ve halihazırda kullandığınız hizmetleri ekleyin. Örneğin, bir cüzdan bağlantısı gerekiyorsa, hangi kullanıcı eyleminin bunu kullanması gerektiğini belirtin. Açık sorular da faydalıdır; bir kararın neye ihtiyacı olduğunu belirlemeye yardımcı olabiliriz.
Bir token ve onun etrafındaki ürünü inşa edebilir misiniz?
Evet, token oluşturma ve dağıtımını bir dApp veya ilgili arayüzle birlikte planlayabiliriz. Bize amaçlanan token davranışını, hedef zinciri ve uygulamanın desteklemesi gereken kullanıcı eylemlerini söyleyin. Zincir üzeri ve arayüz parçalarını ayrı ayrı listeleyeceğiz, böylece ekibiniz her parçayı inceleyebilir. Mevcut bir sözleşme veya uygulama adresi yardımcıdır, ancak bir tane mevcut olmadığında bunu söylemekte sorun yok.
Mevcut bir ürünümüze bir Telegram mini uygulaması ekleyebilir misiniz?
Evet. Mevcut kullanıcı yolculuğunu, Telegram içinde istediğiniz özellikleri ve mini uygulamanın bağlanması gereken hizmetleri paylaşın. Mini uygulamanın neyi yönettiğini ve mevcut ürününüzde neyin kaldığını netleştireceğiz. Basit bir örnek, bir başlangıç ekranı, bir kullanıcı eylemi ve net bir sonraki adımı olan bir yolculuktur.
Web3 geliştirme genellikle ne kadar sürer?
Zamanlamayı özellik listesini, hedef zinciri, entegrasyon erişimini ve inceleme ihtiyaçlarını inceledikten sonra belirleriz. Net kabul kriterlerine sahip odaklanmış bir bileşeni, çözülmemiş kuralları olan bir üründen daha kolay programlamak mümkündür. Bu ayrıntıları anladıktan sonra önerilen sırayı ve inceleme noktalarını ana hatlarıyla belirteceğiz. Bu, ekibinizin tahmini bir zaman çizelgesi yerine gerçek kararlar etrafında plan yapmasına yardımcı olur.
Bir akıllı sözleşmenin bağımsız bir denetimden geçeceğini garanti edebilir misiniz?
Hayır. Denetim incelemecisi, gönderilen sözleşmeye ve kendi değerlendirmesine dayanarak bir sözleşmenin geçip geçmediğine karar verir. Kararlaştırılan davranışı uygulayabilir, ilgili test notlarını sağlayabilir ve kararlaştırılan çalışmanın parçası olan bulguları ele alabiliriz. Örneğin, incelemecinin gereksinimlerini erken paylaşabilirsiniz, böylece nelerin dahil edilmesi gerektiğini tartışabiliriz.
Teslimatta kaynak kodunu ve notları alacak mıyız?
Teslimat, kararlaştırılan bileşenler için kaynak kodunu, uygulama notlarını, test kanıtlarını ve ekibinizle bir inceleme toplantısını içerebilir. Tam öğeleri ve erişim düzenlemelerini çalışma başlamadan önce onaylarız. Ekibinizin belirli bir depoya veya test ortamına ihtiyacı varsa, baştan hesaba katabilmemiz için bunu özette belirtin.
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…