علاقات المطورين DevRel: ماذا يفعل الفريق وكيف يقاس؟

في المقال السابق من هذه السلسلة وصلنا إلى أن المطور يتعلم من التوثيق أولاً، ويثق في رأي مطور آخر أكثر من رأي الشركة، ويجرب المنتج قبل أن يوصي به. والسؤال الذي يأتي بعد ذلك مباشرة: من في الشركة يكتب هذا التوثيق ويجيب في المنتدى ويتحدث في المؤتمرات ويحمل ملاحظات المطورين إلى فريق المنتج؟ في الشركات التقنية هذا عمل فريق اسمه علاقات المطورين Developer Relations، واختصاراً DevRel، وهو فريق يصعب على كثير من الشركات أن تحدد مكانه وطريقة قياسه، فبعضها يضعه في التسويق ويحاسبه بعدد العملاء المحتملين Leads، وبعضها يضعه في الهندسة ثم لا يعرف ماذا ينتج.

المواضيع في سلسلة التسويق للمطورين DevRel:

• التسويق للمطورين Developer Marketing: لماذا يتجاهلون الإعلانات؟
• علاقات المطورين DevRel: ماذا يفعل الفريق وكيف يقاس؟ (الموضوع الحالي)
• التوثيق أداة تسويق: صفحة البداية Quickstart التي تقنع
• المصادر المفتوحة قناة للنمو: من المستخدم إلى العميل

دليلالتسويق للمطورين Developer Marketing: لماذا يتجاهلون الإعلانات؟لماذا لا يقتنع المطور بالإعلان، وما الذي يجعله يجرب أداة ويوصي بشرائها، بأرقام استبيان Stack Overflow 2025 وأمثلة حقيقية.

وفي هذا المقال سوف نتناول:

• تعريف DevRel، والاتجاهين اللذين يعمل فيهما الفريق.
• أعمال الفريق الأربعة، مع مثال حقيقي لكل منها.
• أين يوضع الفريق في الشركة، وماذا فعلت GitLab بفريقها.
• كيف يقاس عمل الفريق، بمؤشرات GitLab المنشورة.
• ماذا حدث عندما كافأ برنامج Hacktoberfest العدد بدل الجودة.
• خطة DevRel بسيطة لشركة ناشئة ليس عندها فريق.

ما هو DevRel؟

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

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

ماذا يفعل الفريق؟

تختلف أسماء الأدوار من شركة لأخرى، ولكن عمل الفريق يقع غالباً في أربعة أجزاء:

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

أين يوضع الفريق في الشركة؟

لا توجد إجابة واحدة، ولكل مكان ثمنه:

• تحت التسويق Marketing: يحصل الفريق على ميزانية الفعاليات والمحتوى، ولكنه يتعرض للمحاسبة بعدد العملاء المحتملين Leads، فيتحول المحتوى التقني إلى إعلان ويفقد ثقة المطورين.
• تحت المنتج أو الهندسة Product, Engineering: يقترب الفريق من الكود والقرار، ويصل صوت المطورين إلى من يبني المنتج مباشرة، ولكنه قد يفقد الوصول إلى الجمهور لأن هذه الفرق لا تقيس الوصول أصلاً.
• فريق مستقل: يحمي الفريق من الطرفين، ولكنه يحتاج إلى مدير يدافع عن ميزانيته بأرقام يفهمها مجلس الإدارة.

وأوضح مثال منشور هو GitLab نفسها، فالدليل يذكر أن فريق Developer Relations قسم إلى فريقين: فريق Developer Advocacy انتقل إلى التسويق التقني وتسويق المنتج Product and Technical Marketing، وفريق المساهمات والمجتمع Co-Create and Community Engineering انتقل إلى تسويق النمو Growth Marketing، والدليل نفسه ما زال في طور النقل وقت كتابة هذا المقال. أي أن شركة كبيرة لها سنوات في هذا العمل ما زالت تعيد ترتيب مكان الفريق، فلا تقلق إذا لم تجد المكان المثالي من أول مرة، والأهم أن تحدد ما الذي سوف يقاس به الفريق قبل أن تحدد لمن يتبع.

كيف يقاس عمل الفريق؟

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

وتنشر GitLab مؤشرات أداء فريقها علناً، وهي مثال جيد لأن كل مؤشر فيها يقع على درجة من هذا السلم:

ولاحظ أن MRARR مؤشر غريب للوهلة الأولى، ولكنه يربط عمل المجتمع بالإيراد بطريقة يفهمها المدير المالي، وهذا ما تحتاجه عندما تدافع عن ميزانية الفريق. ولاحظ أيضاً أن الصفحة نفسها تصف بعض المؤشرات بأنها طريقة جديدة في القياس وأن الفريق ما زال يتعلم أفضل طريقة لتتبعها، وهذا طبيعي، فقياس DevRel صعب حتى على شركة بحجم GitLab التي بلغت إيراداتها 955.2 مليون دولار في السنة المالية 2026 بحسب إعلان نتائجها.

عندما كافأ البرنامج العدد بدل الجودة

برنامج Hacktoberfest من أشهر برامج DevRel، وهو شهر في أكتوبر من كل سنة للمساهمة في المصادر المفتوحة ترعاه DigitalOcean، وكانت المكافأة فيه قميصاً لمن يرسل عدداً معيناً من طلبات الدمج Pull Requests إلى أي مستودع مفتوح المصدر.

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

خطة DevRel بسيطة لشركة ناشئة

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

وأما مكان المجتمع، فابدأ بما يستخدمه جمهورك أصلاً، مثل نقاشات GitHub Discussions إذا كان المنتج مفتوح المصدر، وإذا أردت قناة محادثة على سيرفرك فقد شرحنا تثبيت Mattermost، ولخدمة العملاء والأسئلة من الموقع تثبيت Chatwoot. ولا تقم بفتح خمس قنوات في نفس الوقت، والسبب أن القناة الفارغة تقول للزائر إن لا أحد هنا.

أخطاء شائعة

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

الخلاصة

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

وفي المقال القادم بإذن الله سوف نتحدث عن أهم ما ينتجه هذا الفريق، وهو صفحة البداية Quickstart. والمقالات المرتبطة:

دليلالتوثيق أداة تسويق: صفحة البداية Quickstart التي تقنعكيف تبني صفحة بداية Quickstart توصل المطور إلى أول نتيجة في دقائق، بما تفعله صفحات Stripe وTwilio وSupabase وقالب تبدأ منه.دليلالمصادر المفتوحة قناة للنمو: من المستخدم إلى العميلكيف تحول الشركات مستخدمي مشروعها المفتوح إلى عملاء، ونماذج الربح من الخدمة المستضافة إلى Open Core، ودروس تغيير الرخص بعد النمو.دليلخطة التسويق Marketing Plan لشركة تقنية ناشئةكيف تكتب خطة تسويق في صفحة واحدة لتسعين يوماً، من هدف مرتبط بالإيراد إلى القنوات والميزانية والمراجعة، مع قالب جاهز.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، ومراجعة دليل GitLab ومؤشرات أداء فريقها وصفحات برامج Google Developer Experts وAWS Heroes وGitHub Stars وHacktoberfest في 25 أكتوبر 2026.