تسويق المطورين للويب 3 وعلاقات المطورين: اجعل حزمة SDK سهلة التجربة والاستمرار

ما الذي يقدمه تسويق المطورين

اختبار سريع: اطلب من مطور خارج فريقك تشغيل دليل البدء السريع. قس الوقت. إذا استغرق أكثر من 15 دقيقة، أصلح الوثائق أولاً.

يساعد تسويق مطوري الويب 3 المنتج التقني على شرح قيمته وإعطاء المطورين خطوة تالية واضحة. علاقات المطورين هي العمل المستمر حول تلك العلاقة: التعليم والدعم والملاحظات وفرص تجربة المنتج. تكون الخدمة مفيدة عندما تكون حزمة SDK أو البروتوكول جاهزين للتقييم ولكن المطورين لا يزالون يجدون صعوبة في فهم من أين يبدأون.

نبدأ بتخطيط الرحلة من الاكتشاف إلى أول استخدام ذي معنى للمنتج. هذا يجعل الفجوات مرئية: قد يجد المطور المشروع لكنه لا يفهم حالة الاستخدام، أو يصل إلى الوثائق لكنه يتعثر في الإعداد، أو يكمل برنامجًا تعليميًا دون أن يعرف كيف يستمر. تربط الخطة كل فجوة باستجابة عملية بدلاً من معاملة النشاط المجتمعي كهدف بحد ذاته.

يمكن أن يشمل هذا العمل:

• مخطط لجمهور المطورين وحالات الاستخدام للمنتج.
• مراجعة للإعداد والوثائق وشروحات حزمة SDK.
• خطة للدعم المجتمعي والتعليم التقني والهاكاثونات.
• طريقة بسيطة لتتبع الأسئلة والمحتوى المنشور والإجراءات المتابعة.

إذا كان الإطلاق الأوسع يحتاج إلى تحديد موقع أو تنسيق قنوات، يمكننا ربط هذا العمل بـ استراتيجية الذهاب إلى السوق. للحصول على تشخيص أوسع لأولويات التسويق، راجع استشارات تسويق كريبتو.

كيف يجب أن تدعم الوثائق اعتماد حزمة SDK؟

تدعم الوثائق اعتماد حزمة SDK عندما يتمكن المطور من فهم حالة الاستخدام والمتطلبات الأساسية والإجراء الأول دون تخمين. نراجع المسار كما سيختبره مستخدم جديد، ثم نوصي بتغييرات تجعل الخطوة التالية أسهل في العثور عليها ومتابعتها.

عند الانطلاق، تجري MarketingExtra مراجعة للوثائق والإعداد مقابل المواد التي يمتلكها فريقك بالفعل. نبحث عن عدم تطابق بين لغة المنتج وتعليمات البدء السريع والمهمة الفعلية للمطور. يمكن للمراجعة أن تشير إلى مصطلحات غير واضحة، أو سياق مفقود، أو أمثلة قديمة، أو أماكن يُطلب فيها من القارئ اتخاذ قرار دون إرشاد كافٍ. يؤكد فريقك التقني تفاصيل التنفيذ؛ دورنا هو جعل مسار التعلم متماسكًا والمحتوى سهل التصفح.

تنتج المراجعة المفيدة إجراءات محددة، وليس طلبًا غامضًا بـ "تحسين الوثائق". على سبيل المثال، يمكنها فصل إرشادات الاستخدام الأول عن المواد المرجعية الأعمق، وتحديد أسئلة حزمة SDK التي تستحق مقالًا توضيحيًا، وتوضيح أين يجب أن يذهب المستخدمون للحصول على المساعدة. يمكننا أيضًا المساعدة في تخطيط المحتوى والتسلسل التحريري، مع مراجعة من خبراء الموضوع لديك قبل النشر.

حضر الوثائق الحالية ونظرة عامة على حزمة SDK وحالات استخدام المطور المستهدف والأسئلة التي يسمعها فريقك كثيرًا. إذا كانت الأولوية هي الدعم المستمر بدلاً من مراجعة لمرة واحدة، فاجمع هذا العمل مع دعم ما بعد الإطلاق.

متى يكون الهاكاثون مناسبًا؟

الهاكاثون مناسب عندما يتمكن المطورون من بناء شيء ذي معنى باستخدام المنتج خلال الفعالية ويمكن لفريقك دعمهم أثناء عملهم. يكون أقل فائدة كإعلان مستقل إذا لم تكن حزمة SDK أو الوثائق أو مسار المتابعة جاهزًا للمشاركين.

قبل اختيار فعالية أو تنسيق، تحقق من أنه يمكنك الإجابة على هذه الأسئلة:

• ما الذي يجب أن يكون المشاركون قادرين على بنائه أو اختباره أو تعلمه؟
• ما هي مواد المنتج التي سيحتاجونها، ومن يمكنه توضيح الأسئلة التقنية؟
• ما هي عملية التقديم والمراجعة، ومن سيشرحها؟
• كيف ستحصل المشاريع أو الملاحظات المفيدة على خطوة تالية بعد الفعالية؟

يمكننا المساعدة في تحديد تحدي المطور، وإعداد المحتوى الداعم، وتنسيق الاتصالات، وتنظيم خطة المتابعة مع فريقك. يجب أن تتناسب الخطة مع نضج المنتج: قد تتطلب حزمة SDK المبكرة إرشادًا مكثفًا وملاحظات، بينما قد يدعم مسار التكامل الأكثر رسوخًا موجز مشروع أوسع. في كلتا الحالتين، يحتاج المشاركون إلى نقطة بداية واضحة وطريقة موثوقة للحصول على إجابات.

بالنسبة لخطة الفعالية، اتفق داخليًا على جهة الاتصال التقنية ومسؤوليات المراجعة وأي معايير مشاركة قبل بدء الترويج. اربط الفعالية بـ خطة إطلاق التوكن والنمو فقط إذا كانت أهداف المنتج والمطور تدعم هذا النشاط الأوسع حقًا.

قائمة التحقق المكونة من 6 نقاط لعلاقات المطورين

تحقق من هذه النقاط الست قبل تخطيط الفعاليات. فهي تجعل حزمة SDK سهلة التجربة، وهو الشيء الوحيد الذي لا تستطيع الهاكاثونات والمحادثات والمنشورات إصلاحه بمجرد أن يستسلم المطورون في المحاولة الأولى.

1. شغّل دليل البدء السريع مع مطور خارجي.
2. قدم نموذج تطبيق واحد يعمل.
3. اربط المستودع والوثائق وسجل التغييرات.
4. حدد أين يطرح المطورون الأسئلة.
5. أجب على الأسئلة الجديدة خلال يوم.
6. خطط لفعالية واحدة بنتيجة واضحة.

مصطلحات في سطر واحد

SDK: حزمة تطوير برمجيات، الأدوات والكود الذي يستخدمه المطورون للبناء بمنتجك.

DevRel (بكلمات بسيطة: علاقات المطورين، العمل على مساعدة المطورين على النجاح مع منتج).

ما الذي يحافظ على فائدة مجتمع المطورين بين الفعاليات

قاعدة عامة: نموذج تطبيق واحد يعمل أفضل من عشر صفحات من الشرح.

يمنح المجتمع المفيد للمطورين مكانًا لطرح أسئلة المنتج ومقارنة الأساليب والعثور على إرشادات موثوقة. يجب أن يكمل الوثائق، لا أن يصبح المكان الوحيد الذي توجد فيه معلومات الإعداد الأساسية.

نساعد في تشكيل تجربة المجتمع حول الأسئلة التي يطرحها المطورون فعليًا: البدء، فهم مفهوم تقني، استكشاف أخطاء التكامل وإصلاحها، أو تحديد ما يجب بناؤه بعد ذلك. وهذا يعني تحديد أنواع الأسئلة التي سيجيب عليها الفريق، ومن المسؤول عن الردود التقنية، ومتى يجب أن يؤدي النقاش إلى تحديث الوثائق. الحدود الواضحة مهمة أيضًا؛ يجب أن يعرف أفراد المجتمع أي العبارات هي إرشادات رسمية للمنتج وأين يبلغون عن مشكلة.

قد تتضمن خطة التشغيل العملية:

• غرض المجتمع وجمهوره وإرشادات المشاركة.
• مسار استجابة وتصعيد للأسئلة التقنية.
• إيقاع محتوى متكرر يعتمد على احتياجات المطورين الشائعة.
• طريقة لنقل الملاحظات المفيدة إلى فريق المنتج.

يمكننا تنسيق تنشيط المجتمع والبرامج التعليمية بينما يحتفظ مهندسوك بملكية الدقة التقنية. إذا كان مشروعك يحتاج إلى عمليات مجتمع أوسع تتجاوز دعم المطورين، ففكر في إدارة المجتمع. الخيار الصحيح هو الخطة التي يمكن لفريقك الحفاظ عليها والتي تساعد المطور على التقدم، وليس فقط القناة التي تبدو الأكثر ازدحامًا.

كيف يتم تسليم التعاقد على علاقات المطورين

يبدأ التعاقد على علاقات المطورين بمراجعة منتجك والمواد الحالية وأهداف المطور الفورية. من تلك المراجعة، نتفق على ما سيسلمه الفريق ومن يحتاج إلى الموافقة على المحتوى التقني وكيف سيتم الإبلاغ عن التقدم.

التسلسل النموذجي هو:

1. مشاركة نظرة عامة على المنتج ومواد حزمة SDK الحالية والأسئلة التي يسمعها مطوروك أكثر.
2. مراجعة الإعداد والوثائق ونقاط الاتصال المجتمعية الحالية مع فريقك.
3. اختيار الأولويات التي تتناسب مع جاهزية المنتج والدعم التقني المتاح وتوقيت الإطلاق.
4. إنتاج أو تنسيق المحتوى المتفق عليه أو النشاط المجتمعي أو التحضير للهاكاثون.
5. مراجعة العمل المنجز والأسئلة المفتوحة والمتابعة الموصى بها مع فريقك.

يمكن أن تكون الخطة مراجعة مركزة أو دعمًا مستمرًا؛ لا ينبغي أن تفترض أن مهندسيك لديهم وقت غير محدود للمراجعات أو المشاركة في الفعاليات. نأخذ في الاعتبار دورات الموافقة عند تحديد الجدول الزمني، ونبقي القرارات التقنية مع الأشخاص الذين يمتلكون المنتج. يجب أن توضح التحديثات ما هو مكتمل وما ينتظر الإدخال وما هو القرار المطلوب بعد ذلك.

لتقييم ما إذا كان العمل مفيدًا، تتبع الإشارات العملية التي يمكن لفريقك ملاحظتها: الأسئلة التي تم حلها، فجوات الوثائق التي تمت معالجتها، خطوات الإعداد المكتملة ومحادثات حزمة SDK ذات الصلة. يجب أن يجعل تنسيق التقارير تلك الملاحظات مفيدة للتخطيط، لا أن يحول النشاط إلى ادعاء بالاعتماد. للعمل الذي يشمل أولويات إطلاق متعددة، اربط الخطة بـ دعم تسويق النمو.

ما الذي يجب التحقق منه قبل الالتزام بخطة

خطة علاقات المطورين السليمة تطابق جاهزية المنتج مع قدرة الفريق على دعم المطورين. قبل الالتزام، تأكد من أن حزمة SDK لها حالة استخدام واضحة، وأن الوثائق تعكس المنتج الحالي، وأن مالكًا تقنيًا يمكنه مراجعة الإرشادات العامة. واتفق أيضًا على من يتعامل مع الأسئلة التي تحتاج إلى مدخلات هندسية وما يعتبر متابعة مفيدة بعد الهاكاثون أو النقاش المجتمعي.

يحدد منظم الفعاليات قواعدهم وجداولهم وقرارات الاختيار الخاصة بهم، ويقرر المطورون ما إذا كانوا سيواصلون التكامل بعد الفعالية. يمكننا تسليم الوثائق والدعم وعمل الفعاليات المتفق عليها، لكن لا يمكننا الوعد بالقبول في فعالية طرف ثالث أو تكاملات حزمة SDK الناتجة.

أرسل 3 أشياء: رابط وثائقك ومستودع حزمة SDK الخاص بك ومجموعة المطورين التي تريد الوصول إليها. بهذه، نراجع المسار من النظرة الأولى إلى أول اتصال ونؤكد التكلفة كتابيًا قبل بدء العمل.

كيف نعمل

1. مشاركة سياق المنتجأرسل نظرة عامة على منتجك ومواد حزمة SDK وجمهور المطورين والأولويات الحالية. تضمين الأسئلة التي يسمعها فريقك بشكل متكرر.
2. مراجعة رحلة المطورنقوم بتقييم المسار عبر وثائقك ونقاط الاتصال الداعمة، ثم نحدد الفجوات التي تمنع إجراءً تاليًا واضحًا.
3. الاتفاق على الخطة وأصحاب المسؤوليةاختر العمل الذي يتناسب مع جاهزية المنتج، وحدد مسؤوليات المراجعة وأكد أي قرارات تقنية تبقى مع فريقك.
4. تسليم العمل المتفق عليهنقوم بتنسيق الوثائق أو الدعم المجتمعي أو التحضير للهاكاثون ونبقي الطلبات المفتوحة مرئية لأصحاب المسؤولية المعنيين.
5. المراجعة وتخطيط المتابعةتتلقى حسابًا موجزًا للعمل المنجز والأسئلة غير المحلولة والإجراءات التالية الموصى بها لإعداد المطورين.