سؤال جيد. في المنشور أعلاه، كنت أفكر من منظور الإطلاق الأول، لكن الواقع ليس بهذه البساطة. في الشركات الكبيرة، يوجد دائماً مجتمع سابق في شكل ما.
لإعطاء مثال ملموس لما أعنيه، كانت المجتمعات التي سبقت منصتنا Discourse منتشرة عبر منصات متعددة:
- يامر (Viva Engage)
- شيربوينت
- مايكروسوفت تيمز
وهذا جعل إدارة التوقعات أكثر صعوبة بشكل كبير.
كان لدى المستخدمين القادمين من Viva Engage توقعات مفادها “يمكنني نشر أي شيء أشاء” لم يقم الفريق المشغل بإدارة المحتوى، واكتفى بالموافقة على رغبات كل مدير اتجه إليهم. وقد أدى ذلك إلى إنشاء مجتمعات فقط لإرضاء مؤشرات الأداء الرئيسية (KPI) للمدير. كانت هناك مجتمعات جديدة، وارتفاع في النشاط لمدة ثلاثة أشهر، ثم موتها. ولا يحتاج الأمر إلى ذكر أن هناك جهداً كبيراً في التوجيه والتواصل كان ضرورياً للتغلب على هذا النمط من التفكير والدفاع عن سبب فشل هذا النهج بعد بضعة أشهر، ولماذا سيوفر لهم نهجنا المنظم طويل الأمد نتائج أفضل بعد 6-12 شهراً (ولكن سيكون أبطأ في البداية).
أنشأ شيربوينت توقعات مفادها “يمكنني رفع أي ملف أريده”. على مستوى الشركات الكبيرة، يجب أن تكون حذراً للغاية بشأن مشاركة الملفات بشكل مفتوح. كل عميل وموفر خدمة لديه عقد خاص بالشركة، وكل ملف يشاركونه معنا له متطلبات سرية مختلفة. يسمح شيربوينت للمستخدم بتكوين من يمكنه الوصول إلى هذا الملف بالضبط، لكن Discourse لا يفعل ذلك (وهذا صحيح، فهو ليس منصة مشاركة ملفات). وقد تجاوزت هذه المشكلة من خلال تشجيع المستخدمين على رفع الملفات إلى شيربوينت ومشاركة الروابط لهذه الملفات. إذا لم يتمكن شخص ما من الوصول إلى الملف المشترك، فيمكنه طلب الإذن في الموضوع. إنه إزعاج، لكنه أرخص من الدعوى القضائية.
أنشأ MSTeams توقعات مفادها “يمكنني أن يكون لدي قناتي/مجتمعي الخاص هنا”. لا، إن الهدف الكامل من Discourse هو أن يكون عكس ذلك تماماً. كان هدفنا للمشروع هو إنشاء مشاركة المعرفة بدلاً من صوامع المعرفة. كانت قنوات الفرق حلاً جيداً للمعرفة السرية أو الخاصة بالمشروع، لكن أي شيء يمكن تعميمه في سياق أكثر عمومية شجعنا على مشاركته في Discourse.