كيف نحافظ على فيديوهات الدعم الفني محدثة بعد كل إصدار؟

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

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

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

ابدأ بتصنيف السؤال قبل إنتاج الإجابة

لا يستحق كل سؤال متكرر فيديو. أستخدم تقسيمًا قريبًا من منطق Diátaxis الذي يميز بين الدروس والإرشادات والشرح والمرجع.

السؤال المرجعي مثل «ما الحد؟» أو «ما اسم الحقل؟» يحتاج إجابة نصية قصيرة. إجبار المستخدم على مشاهدة دقيقة كاملة للوصول إلى رقم واحد تصميم سيئ.

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

السؤال التفسيري مثل «لماذا يحتاج النظام هذا الإذن؟» قد يستفيد من رسم أو شرح قصير، لكنه يحتاج أيضًا نصًا يمكن ربطه بالسياسة التقنية.

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

أضع لكل مرشح ثلاثة شروط:

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

إذا غاب شرط منها، يبقى المحتوى نصًا أو يدخل في تحسين المنتج نفسه.

الفيديو ناتج والمستند هو المصدر

هذه القاعدة تحل معظم مشكلات التقادم: الفيديو artifact، والمستند source.

المصدر قد يكون صفحة توثيق أو ملف Markdown أو إجراءً معتمدًا. يُراجع في pull request، ثم يُبنى منه الفيديو. إذا اختلف الاثنان فالمستند هو الصحيح ويُعاد إنتاج الفيديو.

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

يمكن استخدام Leadde.ai للبدء من مستندات أو نص ملصق وتوليد مخطط وسرد ومشاهد. هذه الخطوة تقلل العمل الميكانيكي، لكنها لا تلغي مراجعة الشروط والأرقام والتسلسل. النص المولد pull request يحتاج اعتمادًا، لا حقيقة جديدة.

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

أنشئ manifest يربط التوثيق بالفيديو

من دون خريطة تبعية، سيغير المطور واجهة أو اسم حقل ولن يعرف أن فيديو المساعدة ما زال يعرض النسخة القديمة.

يمكن أن يبدأ manifest بسيطًا هكذا:

videos:
  workspace-transfer:
    source: docs/workspaces/transfer.md
    dependencies:
      - ui/workspace-settings
      - api/transfer-ownership
      - permissions/workspace-admin
    owner: docs-platform
    published_url: /help/video/workspace-transfer
    last_reviewed: 2026-08-21

عندما يتغير ملف أو مكوّن مسجل في dependencies، يظهر تنبيه في المراجعة. التنبيه لا يقرر أن إعادة الإنتاج واجبة. هو يطلب من إنسان أن يجيب: هل تغير ما يراه المستخدم أو يفعله أو يتوقعه؟

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

فرّق بين تغييرات لا تؤثر وتغييرات تكسر الشرح

أستخدم ثلاث درجات لتأثير الإصدار.

تغيير داخلي: refactor، تحسين أداء، أو تعديل لا يراه المستخدم. لا عمل على الفيديو.

تغيير تفسيري: تغير السبب أو التوصية لكن المهمة نفسها باقية. يدخل الفيديو في دفعة تحرير قريبة.

تغيير في المهمة: اسم زر، خطوة، صلاحية، شرط، أو نتيجة متوقعة تغيرت. يُراجع الفيديو قبل أو مع الإصدار.

هذا التصنيف أكثر فائدة من ربط الفيديو بكل commit. hash دقيق جدًا لكنه لا يجيب عن أثر التغيير. والنسخة المستقلة للفيديو لا توضح علاقتها بحالة المنتج.

يمكن إضافة حقل viewer_contract إلى المصدر وزيادته يدويًا عند تغير ما يحتاج المستخدم إلى فعله. الفكرة ليست فرض Semantic Versioning على المحتوى، بل تسجيل أثر يهم المشاهد بدل عد التعديلات.

راجع الشروط قبل الأسلوب

النص المولد قد يكون سليمًا لغويًا وخاطئًا وظيفيًا. ألخص المراجعة في خمس عمليات بحث.

أبحث عن الأرقام والوحدات. «حتى خمسة» ليست «خمسة»، و«بعد عشر دقائق» ليست «خلال عشر دقائق».

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

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

أبحث عن أسماء الواجهة والأوامر كما تظهر فعلًا. لا ينبغي تحسين label في السرد إذا كان المستخدم سيبحث عن النص الأصلي.

وأبحث عن النتيجة المرئية. يجب أن يعرف المستخدم كيف يتأكد من نجاح الخطوة بدل أن تنتهي الرواية بعبارة عامة.

بعد ذلك فقط تأتي النبرة والاختصار. الدقة أولًا، ثم الوضوح، ثم الجمال.

لا تجعل الفيديو نسخة رديئة من تسجيل الشاشة

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

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

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

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

اختر مكان العرض قبل بناء الفيديو

مركز المساعدة ليس المكان الوحيد ولا الأفضل دائمًا.

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

الرابط في رد التذكرة يقلل زمن الشرح، لكنه يأتي بعد فتح التذكرة.

الرابط داخل المنتج قرب النقطة التي يحدث فيها الالتباس قد يمنع السؤال، لكنه يحتاج قرارًا من فريق الواجهة، وقياسه جزء من تجربة المنتج لا من النشر وحده.

رسالة onboarding أو tooltip قد تقدم الفيديو في الوقت الصحيح، لكن الإزعاج المتكرر يحول مادة المساعدة إلى ضوضاء.

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

اكتب للمستخدم العالق لا للمستخدم المثالي

الوصف العام للجمهور مثل «مستخدم جديد» لا يكفي. أكتب الحالة: «مسؤول مساحة عمل نقل الملكية مرة واحدة، لا يرى الخيار بعد تغيير الصلاحيات، وجرب من حساب غير إداري».

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

النص الجيد يذكر الخطأ المتوقع. لا يقول فقط «اختر الحساب الجديد»، بل يوضح ما الذي يحدث إن كان الحساب غير مؤهل. دعم المستخدم يعني تصميم طريق للفشل، لا عرض الطريق المثالي فقط.

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

اجعل الترجمة إصدارًا مستقلًا

نسخة عربية ونسخة إنجليزية للفيديو لا تتحدثان تلقائيًا معًا بعد أول نشر.

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

أسماء headers وendpoints والحقول لا تُترجم عادة. توجد حالات تعرض فيها الواجهة اسمًا محليًا، وحالات يبقى فيها الاسم الإنجليزي هو المرجع. أستخدم MDN Web Docs ومراجع المنتج الرسمية لتثبيت المصطلحات التقنية بدل ترك النموذج يختار ترجمة تبدو فصيحة ولا يستخدمها أي مطور.

تُراجع الترجمة على مستوى المعنى والواجهة معًا. قد يكون الصوت صحيحًا بينما النص الظاهر يحمل label قديمًا. وقد تطول الجملة العربية فتختفي التسمية قبل نهاية القراءة.

قِس الوصول إلى الحل لا اكتمال المشاهدة فقط

معدل الإكمال مفيد لكنه قد يضلل. إذا حصل المستخدم على command المطلوب في منتصف الفيديو وخرج، فقد نجح المحتوى.

أربط الفيديو بإشارة أقرب إلى المهمة:

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

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

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

ضع سياسة حذف قبل امتلاء المكتبة

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

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

الإنتاج الرخيص يزيد الحاجة إلى الحذف. من السهل إنشاء شرح لكل سؤال، لكن كل شرح يضيف تكلفة مراجعة بعد كل إصدار. سؤال «هل يستحق هذا فيديو؟» هو جزء من الميزانية التقنية.

سياسة الحذف تحمي أيضًا الفريق من التعلق بالعمل القديم. القرار أسهل عندما يُتفق عليه قبل أن يصنع شخص ملفًا ويدافع عنه.

حالات لا تناسب الفيديو

البيانات المرجعية التي يحتاج المستخدم إلى نسخها أو مقارنتها تبقى نصًا.

الميزات التجريبية التي تتغير أسبوعيًا تنتظر الاستقرار.

الأعطال ذات الأسباب المتعددة تحتاج تشخيصًا تفاعليًا أو شجرة قرار.

الموضوعات الأمنية التي قد تكشف إعدادًا حساسًا تحتاج قناة مناسبة ومراجعة أعلى.

والخطوة التي تحتاج رؤية شاشة حقيقية لا تُستبدل بمشهد تقريبي.

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

أسئلة شائعة

كم يجب أن يكون طول فيديو الدعم؟

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

هل ننتج الفيديو تلقائيًا عند كل merge؟

يمكن أتمتة التنبيه وتجهيز المسودة، لكن النشر التلقائي خطر عندما يحتوي النص على شروط أو صلاحيات أو حدود. أُبقي مراجعة بشرية قبل render النهائي.

من يملك الفيديو: الدعم أم التوثيق أم التطوير؟

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

هل يجب الإبقاء على المقال المكتوب؟

نعم. النص قابل للبحث والنسخ والوصول، ويتحدث أسرع من الفيديو عند تغير معلومة صغيرة. يعمل الفيديو والمقال معًا، ولا ينبغي أن يصبح الصوت المصدر الوحيد.

ما أول فيديو مناسب للاختبار؟

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

تعريف عملي لـ «تم»

لا أعد الفيديو منتهيًا عندما يصبح ملف MP4 جاهزًا. ينتهي عندما يحمل مصدرًا معتمدًا، وخريطة تبعية، ومالكًا، ونصًا بديلًا، وتاريخ مراجعة، ومكان عرض، وشرط حذف.

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