ما إجراءات المستخدم التي يجب أن يدعمها بناء ويب 3 أولاً؟
يجب أن يبدأ بناء ويب 3 بما يحتاج الشخص إلى فعله، وليس بقائمة من التقنيات. يساعد هذا الاختيار فريقك في تحديد الأجزاء التي تنتمي إلى السلسلة، والأجزاء التي تنتمي إلى الواجهة، وما يمكن تأجيله لوقت لاحق.
على سبيل المثال، قد يحتاج مشروع توكن إلى سلوك توكن محدد ودعم للنشر. قد يحتاج المنتج الذي يحتوي على إجراءات متصلة بالمحفظة إلى dApp يتيح للأشخاص عرض المعلومات أو إرسال المعاملات. قد تناسب تجربة المجتمع تطبيق تليغرام مصغر. نحول هذه الإجراءات المستخدمة إلى قطع برمجية محددة ونلاحظ الخدمات أو الوصول الذي تحتاجه كل قطعة.
قد تبدأ بالسؤال: ماذا يرى المستخدم الجديد، وماذا يمكنه فعله، وماذا يجب أن يحدث بعد ذلك؟ ثم صف السلوك المتوقع بعبارات بسيطة. يمكننا ربط إنشاء التوكن ونشره بـ تطوير التوكن. أو النظر في القواعد وراء التفاعل من خلال تطوير العقود الذكية. بالنسبة لرحلة المستخدم، قد يكون تطوير dApp الجزء المناسب من الخطة.
هذا يحافظ على عملية المحادثة الأولى عملية. نحدد ميزات الإطلاق الأساسية والتبعيات والأفكار اللاحقة بشكل منفصل، حتى يتمكن فريقك من مراجعة الخيارات قبل بدء التطوير.
تحديث خارطة الطريق أسهل مع حدود بناء واضحة
الحدود الواضحة تسمح لفريقك بشرح ما يتم بناؤه وما لا يزال بحاجة إلى قرار. كما تعطي الأشخاص الذين يراجعون العمل شيئًا ملموسًا للتحقق منه.
تخيل قائد برنامج السفراء على وشك إصدار تحديث لخارطة الطريق. يريد الفريق ذكر ميزة توكن وتجربة تليغرام، لكن رحلة المستخدم الدقيقة لا تزال قيد التشكيل. سنسأل عما يجب أن يكون السفير قادرًا على فعله، وما هي الشبكة التي يحتاجها المنتج، وما هي الخدمات الحالية التي يجب الاتصال بها. ثم نفصل الميزات المؤكدة عن الأسئلة المفتوحة، بحيث يصف التحديث خطة بدلاً من افتراض.
بالنسبة لمنتج يحتوي على عدة أجزاء، نسجل كيفية التقاء هذه الأجزاء. قد يوفر العقد سلوكًا محددًا، بينما تعطي الواجهة المستخدمين طريقة للتفاعل معه. قد يتولى تطبيق تليغرام المصغر رحلة منفصلة. إذا كان الفريق يحتاج أيضًا إلى موقع منتج عام، يمكننا ربط الخطة بـ تطوير موقع ويب 3. عندما يكون سلوك المحفظة محوريًا، قد يحتاج تطوير محفظة العملات المشفرة إلى قراراته ومراجعته الخاصة.
هذا النوع من المحادثة المبكرة يمكن أن يوفر المراجعات لاحقًا. تظل خارطة الطريق الخاصة بك مفيدة، ويبدأ البناء بتوقعات مشتركة.
ما يمكن أن يتوقعه فريقك من التسليم
تتسلم قطع البرامج المتفق عليها للمشروع، بالإضافة إلى المعلومات التي يحتاجها فريقك لمراجعة العمل ومواصلته. نوضح المحتويات قبل بدء التطوير، بدلاً من معالجة قائمة الميزات كخطة كاملة.
اعتمادًا على موجزك، قد يشمل العمل:
- كود المصدر لمكونات العقد أو التطبيق أو التطبيق المصغر المتفق عليها.
- تعليمات النشر أو التكوين للبيئة المختارة.
- حالات الاختبار والملاحظات التي تظهر السلوكيات المتوقعة التي تم التحقق منها.
- تفاصيل التكامل والافتراضات وملاحظات التسليم العملية.
- جولة نهائية مع الأشخاص الذين سيتولون العمل.
نستخدم قائمة تحقق للانطلاق لجمع الميزات والوصول والتبعيات ومعايير القبول. نتفق على نقطتي مراجعة. الأولى قبل التنفيذ، لتأكيد الخطة. الثانية قبل التسليم، للتحقق من النتيجة مقابل المعايير المتفق عليها. يمكنك إثارة عدم التطابق أثناء العمل. بهذه الطريقة، لن تكتشفه فقط في النهاية.
افترض أن فريقك لديه بالفعل dApp ولكنه يريد سير عمل ذكاء اصطناعي بجانبه. يمكننا مناقشة ذلك كقطعة منفصلة من خلال تطوير وكلاء الذكاء الاصطناعي، بحيث يكون للمنتج المواجه للمستخدم وسير العمل الآلي توقعات مختلفة.
أربعة قرارات تساعد في دفع البناء قدمًا
تجيب خطة تطوير ويب 3 المفيدة على أربعة أسئلة عملية قبل اعتبار الكود جاهزًا للبناء. الإجابات الواضحة تجعل المراجعات أسهل لكل من فريق المنتج الخاص بك وفريقنا.
| القرار | ما يجب كتابته |
|---|---|
| الشبكة | السلسلة المستهدفة وأي عناوين عقد أو تطبيق موجودة. |
| رحلة المستخدم | الإجراءات التي يجب أن يتمكن كل دور مستخدم من اتخاذها. |
| الاتصالات | المحافظ وواجهات برمجة التطبيقات والخدمات الأخرى المطلوبة، بالإضافة إلى من يمكنه توفير الوصول. |
| القبول | ما سيتحقق منه فريقك قبل الموافقة على كل ميزة متفق عليها. |
نراجع هذه التفاصيل مع فريقك ونسجل أي عناصر لم تتم الإجابة عليها. إذا كان هناك طريقان تقنيان معقولان، نشرح المقايضات بلغة يومية. ثم نلاحظ الطريق الذي تختاره. نتحقق أيضًا مما إذا كانت بيئة اختبار أو ملفات تصميم أو مستودع موجود متاحة.
في الأسبوع الأول، الهدف المفيد هو فهم مشترك للميزات ونقاط المراجعة. إنها ليست قائمة متسرعة من الوعود. إذا كان الوصول أو قاعدة المنتج مفقودة، نضع علامة عليها كقرار مفتوح. هذا يعطي فريقك إجراءً واضحًا تاليًا ويبقي التنفيذ قائمًا على الخيارات التي اتخذتها بالفعل.
حافظ على رؤية التبعيات الخارجية مع تطور المنتج
البناء الجيد يجعل السلوك المتفق عليه قابلاً للاختبار ويترك فريقك مع تسليم قابل للاستخدام. الأمور الرئيسية التي يجب تسويتها مبكرًا هي قواعد المنتج، ووصول التكامل، ومن سيراجع كل ميزة.
أدوات السلسلة، وسلوك المحفظة، وقرارات مراجعة تليغرام، وتوفر خدمة الطرف الثالث هي خارج سيطرتنا. لا يمكننا الوعد بموافقتها أو تشغيلها دون انقطاع. يمكننا الالتزام بالتنفيذ والفحوصات والتسليم الذي نتفق عليه معًا. نحدد أيضًا التبعيات قبل أن تصبح افتراضات خفية.
للبدء، أرسل إلى Brand Community موجز منتج قصير مع رحلة المستخدم والسلسلة المستهدفة. قم بتضمين الميزات المطلوبة وأي مراجع مستودع أو تصميم متاحة. ثلاث تفاصيل بداية مفيدة هي ما يجب أن يفعله المستخدمون، وما هي الخدمات الحالية التي يجب الاتصال بها، وما سيستخدمه فريقك لمراجعة العمل. إذا كانت إجابة واحدة لا تزال مفتوحة، قم بتضمينها أيضًا.
سنراجع ما تشاركه ونوضح النقاط التي لم تتم الإجابة عليها. ثم نحدد الميزات المقترحة ولحظات المراجعة والتسليم. سيكون لديك خطة ملموسة للنظر فيها قبل أن تقرر ما تبنيه أولاً.
الأسئلة الشائعة
ما الذي يجب أن أرسله قبل مناقشة بناء ويب 3؟
أرسل وصفًا قصيرًا للمنتج، والأشخاص الذين سيستخدمونه، والإجراءات التي يحتاجون إلى اتخاذها. قم بتضمين السلسلة المستهدفة، وأي كود أو عقود موجودة، ومراجع التصميم، والخدمات التي تستخدمها بالفعل. على سبيل المثال، إذا كان اتصال المحفظة مطلوبًا، فحدد إجراء المستخدم الذي يجب أن يستخدمه. الأسئلة المفتوحة مفيدة أيضًا؛ يمكننا المساعدة في تحديد ما يحتاج إلى قرار.
هل يمكنك بناء توكن والمنتج حوله؟
نعم، يمكننا تخطيط إنشاء التوكن ونشره جنبًا إلى جنب مع dApp أو واجهة ذات صلة. أخبرنا بسلوك التوكن المقصود، والسلسلة المستهدفة، وإجراءات المستخدم التي يجب أن يدعمها التطبيق. سنقوم بإدراج القطع الموجودة على السلسلة وقطع الواجهة بشكل منفصل، حتى يتمكن فريقك من مراجعة كل جزء. عنوان العقد أو التطبيق الموجود مفيد، لكن لا بأس من القول عندما لا يكون متاحًا.
هل يمكنك إضافة تطبيق تليغرام مصغر إلى منتج لدينا بالفعل؟
نعم. شارك رحلة المستخدم الحالية، والميزات التي تريدها داخل تليغرام، والخدمات التي يحتاج التطبيق المصغر إلى الاتصال بها. سنوضح ما يعالجه التطبيق المصغر وما يبقى في منتجك الحالي. مثال بسيط هو رحلة مع شاشة بداية، وإجراء مستخدم واحد، وخطوة تالية واضحة.
كم من الوقت يستغرق تطوير ويب 3 عادةً؟
نحدد التوقيت بعد مراجعة قائمة الميزات، والسلسلة المستهدفة، ووصول التكامل، واحتياجات المراجعة. المكون المركز مع معايير قبول واضحة أسهل في الجدولة من المنتج ذي القواعد غير المحلولة. سنحدد التسلسل المقترح ونقاط المراجعة بمجرد فهمنا لتلك التفاصيل. يساعد ذلك فريقك في التخطيط بناءً على قرارات حقيقية بدلاً من جدول زمني تخميني.
هل يمكنك الوعد بأن العقد الذكي سيجتاز تدقيقًا مستقلاً؟
لا. يقرر مراجع التدقيق ما إذا كان العقد سيجتاز، بناءً على العقد المقدم وتقييمه. يمكننا تنفيذ السلوك المتفق عليه، وتقديم ملاحظات الاختبار ذات الصلة، ومعالجة النتائج التي تشكل جزءًا من العمل المتفق عليه. على سبيل المثال، يمكنك مشاركة متطلبات المراجع مبكرًا حتى نتمكن من مناقشة ما يجب تضمينه.
هل سنتسلم كود المصدر والملاحظات عند التسليم؟
يمكن أن يتضمن التسليم كود المصدر للمكونات المتفق عليها، وملاحظات التنفيذ، وأدلة الاختبار، وجولة مع فريقك. نؤكد العناصر الدقيقة وترتيبات الوصول قبل بدء العمل. إذا كان فريقك يحتاج إلى مستودع معين أو بيئة اختبار، فاذكره في الموجز حتى نتمكن من أخذه في الاعتبار من البداية.
أخبرنا عن مشروعك
أجب عن أربعة أسئلة سريعة وسيرسل لك مدير الحساب خلال ساعة خطة وجدولا زمنيا ونطاقا للميزانية. كل شيء يبقى سريا.
جار تحميل النموذج…