I’d like to be able to filter results when on assigned messages and topic lists, to for example filter by one or more tags. I can’t help but think this used to be possible but I am having trouble with it now.
On my discourse, when looking at my own assigned list or assigned list for a colleague, selecting displays search with “Search posts by @tobiaseigen” tickbox. It would make more sense to see “Search assigned to @tobiaseigen”.
There is no UI on the advanced search to filter by “assigned to” but I think for sites that use the assigned plugin it would be hugely beneficial - is adding it on the roadmap somewhere?
While searching I came across an old topic about creating a help interface for “magic filters” for search - don’t know what happened to that idea but I think it would be a great idea! Or at least if there is a complete list of what is possible somewhere, I’d love to see it.
سيكون ذلك تحسينًا رائعًا للبحث المتقدم! نحن نستخدم Discourse حاليًا كأداة لإدارة المهام ونظام دعم فني، وتطبيق هذا الفلتر سيعزز بالتأكيد قدرتنا على تحديد المهام العالقة التي لا تزال قيد التنفيذ. نستخدم Discourse منذ شهر وقد أحببناه بالفعل! شكرًا جزيلاً على هذا المنتج الرائع!
شكرًا جزيلاً لك على توجيهاتك @tobiaseigen بخصوص Discourse for Teams. كما أن هذه أخبار رائعة يا @david! سيكون إدارة الأعمال المعلقة أسهل بكثير الآن. أود أن أستخدم هذا المنشور لأخبركم ما هي الميزات القاتلة التي جعلتنا ننتقل إلى Discourse.
الخلفية
نحن فريق من مطوري البرمجيات، والمحللين الوظيفيين، ومديري الأنظمة مكرسون لبناء حلول إدارة الأعمال للسوق الكولومبي، ومع ذلك، فإن العالم بأسره موجود في خطتنا المستقبلية نبني برمجيات مخصصة لعملائنا ولدينا منتجاتنا الأصلية، لكن خط عملنا الرئيسي حاليًا هو تقديم الخدمات والإضافات فوق نظام Odoo ERP. من بين جميع التطبيقات التي يتضمنها Odoo، تخصصنا في تطبيقات المحاسبة، وإدارة المخزون، وإدارة الموارد البشرية. كما قد تتوقع، نستخدم Odoo على نطاق واسع، ومنذ تأسيسنا في عام 2015، كان تطبيق إدارة المشاريع لدينا أفضل حليف لنا، والذي بفضل واجهة Kanban (على غرار Trello) يتيح لفريقنا إدارة سير عمل المهام المتفق عليها في كل مشروع تنفيذي. ومع ذلك، فإن تنفيذ المشروع هو مجرد بداية العلاقة مع شركة عميل، وفي فترة الصيانة يمكن أن تتعقد الأمور إذا لم يتم توفير إدارة فعالة وتواصل مباشر مع المستخدم. لكن Odoo يحتوي على تطبيق Helpdesk يمكنك استخدامه لإدارة التواصل القائم على التذاكر مع مستخدمي برمجتك عبر البريد الإلكتروني، وبالطبع، مرة أخرى، كنا نستخدمه لتقديم خدمات الدعم لدينا. كانت الإجابات السريعة على الأسئلة الوظيفية سهلة الإدارة من خلال هذه الأداة، ولكن عند استلام تقرير معقد عن خلل تقني، يجب إنشاء مستند منفصل لمساعدة عملية التطوير. في هذه الحالات، كنا نستخدم Gitlab و Github Issues وحتى ملفات restructuredtext خاضعة لإصدار التحكم المخصص (يتم تحليلها باستخدام أدوات Python مطورة داخليًا) لإنشاء تنسيق للإبلاغ عن المشكلات بغض النظر عن المورد. في النهاية، وجدنا أنفسنا في موقف حيث كان يجب البحث عن العمل المطلوب في ثلاثة أماكن مختلفة على الأقل، باستخدام واجهات وسير عمل مختلفة. كان كل من التواصل الخارجي والداخلي اللازم للقيام بأنشطتنا اليومية معرضًا للخطر، مما دفعنا إلى البحث عن عمليات وأدوات بديلة، حتى لو كان ذلك يعني تفكيك “مركزية Odoo” لدينا. اشتهر Discourse كبرنامج منتديات منذ سنوات عديدة، لكننا عرفنا عن ميزات إدارة العمل فيه فقط مؤخرًا بعد إجراء بعض الأبحاث. ما دفعنا لتجربته كان ثلاثة أشياء: التواصل غير المتزامن، توحيد تعريف العمل، والتحكم في العمل قيد التنفيذ (WIP).
التواصل غير المتزامن
منشورات Discourse تشبه البريد الإلكتروني، ولكنها أفضل. في عالم يتسم بـ Whatsapp و Slack و Messenger و Mattermost و Odoo Chat والعديد من التطبيقات الأخرى، اعتدنا على أن نكون دائمًا في حالة “تنبيه”. وبما أن كل شيء يبدو عاجلاً، فإنك تدفع للرد بردود قصيرة وسريعة وسطحية. لا وقت للتفكير، لا وقت للتعديل. فقط اكتب وأرسل. كتابة هذا المنشور، على سبيل المثال، استغرقت مني وقتًا أطول بكثير مما كنت أتوقع، لكنني أقوم بذلك بعد إنهاء مهام أخرى أكثر إلحاحًا، لذا يمكنني التركيز في تقديم ملاحظاتي الأكثر صدقًا وتفصيلاً (أقل ما يمكن فعله حقًا لأداة رائعة مثل Discourse). كتابة منشور تشبه إرسال بريد إلكتروني، لكن قراءته قصة مختلفة تمامًا. قصة أفضل بكثير. المنشورات مركزية ومشتركة بين جميع أعضاء الفريق (أو المصرح لهم). يمكن البحث فيها حسب محتواها أو موقعها (أي المواضيع والفئات)، وحتى يمكن أن تكون متاحة للمستخدمين الخارجيين أو الموظفين الذين لم يشاركوا في المحادثة الأصلية، وهو أمر رائع لتخزين السجل التاريخي لكيفية اتخاذ القرارات وما هو سياقها. ملاحظة سريعة: النظر إلى كيفية تبني python.org لـ Discourse كتطبيق لإدارة مجتمعه، بدلاً من قوائم البريد أو الحلول الأخرى القائمة على Python، يُظهر أن ما لدينا هنا استثنائي حقًا من حيث الملاءمة والأداء وإمكانية الوصول.
توحيد تعريف العمل
هذا هو السبب الرئيسي لانتقالنا إلى Discourse. من الخلفية المقدمة سابقًا، قد تتخيل بيئة عمل ملونة ومعقدة للغاية. بالتأكيد كنت مبالغًا قليلاً لأننا كان لدينا فعليًا عمليات موثقة وأدوات رقمية لإدارة أنشطتنا منذ التأسيس. لكن ما حدث لنا مع مرور الوقت هو أننا لم نتمكن من الحفاظ على تمثيل واحد للعمل داخل الشركة. نعم، كان لدينا مهام لأنشطة الاستشارات وتذاكر للدعم. كان التطوير مدفوعًا بمتطلبات موثقة كنصوص عادية أو بالمشكلات المعروفة المرتبطة بـ Git. لم يكن الأمر يتعلق بالنقص، بل على العكس، الزيادة. كانت هناك مصادر معلومات كثيرة جدًا، وحتى داخل تطبيق مشترك (مثل Odoo) كانت هناك تنسيقات متعددة (مثل Task و Ticket و Issue). بالطبع كان بإمكاننا اختيار أي من الأدوات المذكورة أعلاه كمصدر وحيد للحقيقة، لكن لم يوفر أي منها عنصرًا حاسمًا واحدًا: ملاحظات خارجية متكاملة. بعد شهر واحد فقط من استخدام Discourse، نشعر أخيرًا بأننا نتواصل مع مستخدمينا. لا يوجد تمييز بين هم و نحن لأننا نستخدم جميعًا نفس الواجهة. ومع ذلك، لا نحتاج إلى التنازل عن السيطرة على كيفية إدارة عملنا حيث يمكن تقييد بعض المناطق والقدرات. لكن الأفضل من ذلك كله هو أنه من خلال المواضيع في Discourse، يمكن استخدام نفس العناصر، التي تشبه تعليقات المدونات أو تذاكر المساعدة، التي نستخدمها لفهم احتياجات عملائنا، من قبلنا في فئات استخدام داخلي خاص لتمثيل المهام المخطط لها، أو المشكلات التي يجب معالجتها، أو الأنشطة التشغيلية التي يجب تنفيذها. بالنسبة لنا، للموضوع مرادفات متعددة، جميعها صحيحة حسب السياق: Issue، Task، Ticket، Activity، Checklist، وما إلى ذلك. شكل موحد للعمل يكون مفتوحًا، وسهل الوصول إليه، ويتم إدارته مركزيًا. قرأت أنه مع Discourse for Teams تخطط لتقديم منتج منفصل، مختلف عن منتدى Discourse، أو بعبارة أخرى، أن Discourse (المنتدى) و Discourse for Teams مقصود أن يتم نشرهما كحالتين مختلفتين. أود أن أنصحك بالتفكير في ذلك بصبر، لأن هذا التصميم سيؤدي حتمًا إلى تفكيك التكامل الحالي بين الأطراف الخارجية والداخلية في المنظمة.
التحكم في العمل قيد التنفيذ (WIP)
أخيرًا، واحدة من أفضل المفاجآت التي واجهناها من خلال استخدام Discourse هي أننا نستطيع أخيرًا إنشاء تحكم في العمل قيد التنفيذ داخل المنظمة. لأن العمل المطلوب له نفس “الشكل”، فمن السهل تحديد سياسات لتقييد كمية العمل التي يجب أن تمتلكها المنظمة في أي لحظة. من خلال إضافة Assign، تُعطى المهام مسؤولًا فريدًا يجب عليه البحث عن المساعدة عند الحاجة (وهو ‘@’ بعيد)، ثم باستخدام واجهة موحدة (توجد في ‘/g/staff/assigned/everyone’) يمكن التحكم في كمية الأنشطة الجارية (أي WIP) في النظام بأكمله. حاليًا، على سبيل المثال، نقوم بالتكرار مع WIP لكل شخص يساوي 5 مهام/مواضيع/مشكلات. بما أننا 14 شخصًا، فهذا يعني أن سعتنا القصوى كفريق يجب أن تكون 70. هذا مهم جدًا بالنسبة لنا لأنه يساعد في توفير الاستقرار لواحد من أصعب المشاريع في الحياة: التقدير. وفقًا لقانون ليتل (Little's law - Wikipedia)، فإن متوسط عدد العناصر في الطابور على المدى الطويل يساوي معدل وصولها أو إنتاجيتها، مضروبًا في متوسط وقت الانتظار الذي يقضيه كل عنصر في النظام. لذا، مع WIP مقيد بـ 70 عنصرًا، إذا تلقينا 140 تذكرة في الأسبوع، فسيتم إكمالها في المتوسط خلال 0.5 أسبوع، وسيكون ذلك 0.33 أسبوع في المتوسط إذا تلقينا 210 تذكرة. هذا يفترض بالطبع أن النظام في حالة مستقرة وأن قائمة الانتظار لا تنمو إلى ما لا نهاية، لذا يجب إجراء معايرة مناسبة لـ WIP بشكل تكراري. لا يزال لدينا (وسنظل دائمًا) كميات أقل من أنواع العمل التي لا يمكن تمثيلها في Discourse، مثل إدارة رسائل البريد الإلكتروني لدينا أو خط أنابيب CRM، ولكن بما أن الغالبية العظمى من العمل المطلوب لدينا أصبح الآن له شكل واحد كمواضيع Discourse، فإن تنفيذ ممارسات Kanban و Agile مثل تقييد WIP سيكون أسهل بكثير. لذلك أنصح بأنه إذا كان مقصودًا بـ Discourse for Teams أن يكون مثيلًا منفصلاً لمنتدى Discourse، فسيكون من المؤسف عدم وجود طريقة موحدة للحفاظ على عرض مركزي ومركب لـ WIP في كلا النظامين.
آمل أن يساعد هذا المنشور في تحسين Discourse كمنصة للتواصل وبناء المجتمعات. مرة أخرى، شكرًا جزيلاً لكم جميعًا، وأتمنى لكم كل التوفيق!
displays search with “Search posts by @tobiaseigen” tickbox. It would make more sense to see “Search assigned to @tobiaseigen”.
نبني برمجيات مخصصة لعملائنا ولدينا منتجاتنا الأصلية، لكن خط عملنا الرئيسي حاليًا هو تقديم الخدمات والإضافات فوق نظام Odoo ERP. من بين جميع التطبيقات التي يتضمنها Odoo، تخصصنا في تطبيقات المحاسبة، وإدارة المخزون، وإدارة الموارد البشرية. كما قد تتوقع، نستخدم Odoo على نطاق واسع، ومنذ تأسيسنا في عام 2015، كان تطبيق إدارة المشاريع لدينا أفضل حليف لنا، والذي بفضل واجهة Kanban (على غرار Trello) يتيح لفريقنا إدارة سير عمل المهام المتفق عليها في كل مشروع تنفيذي. ومع ذلك، فإن تنفيذ المشروع هو مجرد بداية العلاقة مع شركة عميل، وفي فترة الصيانة يمكن أن تتعقد الأمور إذا لم يتم توفير إدارة فعالة وتواصل مباشر مع المستخدم. لكن Odoo يحتوي على تطبيق Helpdesk يمكنك استخدامه لإدارة التواصل القائم على التذاكر مع مستخدمي برمجتك عبر البريد الإلكتروني، وبالطبع، مرة أخرى، كنا نستخدمه لتقديم خدمات الدعم لدينا. كانت الإجابات السريعة على الأسئلة الوظيفية سهلة الإدارة من خلال هذه الأداة، ولكن عند استلام تقرير معقد عن خلل تقني، يجب إنشاء مستند منفصل لمساعدة عملية التطوير. في هذه الحالات، كنا نستخدم Gitlab و Github Issues وحتى ملفات restructuredtext خاضعة لإصدار التحكم المخصص (يتم تحليلها باستخدام أدوات Python مطورة داخليًا) لإنشاء تنسيق للإبلاغ عن المشكلات بغض النظر عن المورد. في النهاية، وجدنا أنفسنا في موقف حيث كان يجب البحث عن العمل المطلوب في ثلاثة أماكن مختلفة على الأقل، باستخدام واجهات وسير عمل مختلفة. كان كل من التواصل الخارجي والداخلي اللازم للقيام بأنشطتنا اليومية معرضًا للخطر، مما دفعنا إلى البحث عن عمليات وأدوات بديلة، حتى لو كان ذلك يعني تفكيك “مركزية Odoo” لدينا. اشتهر Discourse كبرنامج منتديات منذ سنوات عديدة، لكننا عرفنا عن ميزات إدارة العمل فيه فقط مؤخرًا بعد إجراء بعض الأبحاث. ما دفعنا لتجربته كان ثلاثة أشياء: التواصل غير المتزامن، توحيد تعريف العمل، والتحكم في العمل قيد التنفيذ (WIP).
