كيف تختار مسميات حالة مفيدة للعمل الجماعي؟

اختيار مسميات حالات العمل يبدو بسيطًا، لكنه يؤثر في كيفية قراءة الفريق للوحة ومتى يعرف أن المهمة جاهزة أو تحتاج إلى تدخل. لا توجد في هذا المقال قائمة عالمية ملزمة؛ فالتسلسل المقترح هنا هو قالب تحريري يستند إلى أنماط سير العمل الموثقة، ويجب تكييفه مع التسليمات الفعلية في فريقك. يقترح القالب الأساسي: Backlog/Not started، ثم Ready، ثم In progress، ثم In review، ثم Done. ويمكن إضافة Blocked كحالة استثنائية وCanceled/Not planned كناتج نهائي عند الحاجة. هذا اقتراح تحريري مستخلص من أنماط سير العمل الموثقة، وليس معيارًا عامًا؛ راجع شرح Atlassian عن تصميم سير العمل مع الفريق.

ابدأ بالمعنى قبل الاسم

الحالة الجيدة تجيب عن سؤال واحد: أين توجد المهمة الآن في مسار إنجازها؟ وفق توثيق Atlassian، يمكن أن يبدأ سير العمل بثلاث حالات أساسية هي To do وIn progress وDone، ثم يضيف الفريق مراحل أكثر تفصيلًا عندما يحتاج إلى إظهار التسليمات أو المراجعات أو إعداد التقارير. المصدر نفسه يشرح التدرج من الحالات الأساسية إلى المراحل التفصيلية.

كما يوضح توثيق Jira أن حالات سير العمل تنتمي إلى فئات أوسع هي To do وIn progress وDone. لذلك، قد تكون لديك أسماء محلية متعددة، لكن من المفيد أن تعرف الفئة العامة التي تمثلها كل حالة. راجع تعريف Jira لفئة حالة سير العمل.

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

قالب الحالات المقترح

1. Backlog/Not started — المتراكم/لم يبدأ: المهمة مسجلة، لكنها لم تُجهز بعد للبدء. هذا تعريف عملي مقترح لهذا القالب، وليس تعريفًا صادرًا عن مزود بعينه.
2. Ready — جاهز: المهمة واضحة بما يكفي لكي يبدأ بها شخص ما. يوصي هذا القالب باستخدامها عندما تكون الخطوة التالية معروفة، مع ترك تفاصيل معيار الجاهزية للفريق.
3. In progress — قيد التنفيذ: يجري العمل على المهمة حاليًا. احجز هذه الحالة للعمل النشط، لا لمجرد أن المهمة موجودة في قائمة أحد الأشخاص.
4. In review — قيد المراجعة: تنتظر المهمة فحصًا أو موافقة أو اختبارًا. هذا تقسيم عملي مقترح عندما تكون المراجعة تسليمًا واضحًا في فريقك.
5. Done — مكتمل: لا تستخدمها لمجرد انتهاء النشاط؛ اربطها بقائمة إتمام مشتركة يعرّفها الفريق.
6. Blocked — متوقفة: أضفها عندما لا يمكن مواصلة العمل وتوجد حاجة إلى قرار أو اعتماد أو معلومة خارجية. هذا اقتراح تشغيلي للقالب؛ سجّل سبب التوقف والخطوة المطلوبة.
7. Canceled/Not planned — ملغاة/غير مخطط لها: استخدمها عندما تقررون عمدًا عدم إكمال العمل. هذه نتيجة نهائية مقترحة، وليست دليلًا على أن المهمة اكتملت.

افصل الحالة عن الصفات

لا تجعل كلمات مثل Urgent أو Finance أو Client A أو Bug حالات سير عمل. وفق توثيق Microsoft Planner، تصلح التسميات Labels لصفات مشتركة عبر المهام، مثل المتطلبات أو المواقع أو الاعتماديات أو القيود الزمنية، بدل أن تحل محل حالة سير العمل الرئيسية. راجع توثيق Microsoft Planner عن استخدام التسميات.

بناءً على ذلك، يمكن أن تكون In progress هي الحالة، بينما تكون Urgent أولوية، وClient A عميلًا، وBug نوعًا، وFinance قسمًا أو مجالًا. هذا تقسيم تصميمي مقترح في هذا المقال؛ اختبره على لوحة فريقك بدل اعتباره حقيقة مفروضة.

تدعم GitHub Projects الحقول المخصصة، والتصفية حسب الحالة، وأتمتة يمكنها ضبط حالة مثل Done عند إغلاق issue. تفاصيل هذه الإمكانات موجودة في إرشادات GitHub Projects. كما يوضح دليل Asana السريع أن أعضاء الفريق يمكنهم تحديث حالة المهمة واستخدام الحقول المخصصة أو تحديثات المشروع لمشاركة التقدم والسياق. راجع دليل Asana السريع.

عرّف Done قبل إطلاق اللوحة

كلمة Done قد تعني أشياء مختلفة لأفراد الفريق: قد يعني بعضها أن الملف كُتب، أو أن التغيير فُحص، أو أن الموافقة وصلت. لذلك أنشئ تعريفًا مشتركًا للإتمام قبل اعتماد الحالة. يوضح Atlassian أن Definition of Done ينبغي أن يوضح متى يكون العمل مكتملًا فعلًا، وأنه يساعد على تقليل إعادة العمل. اقرأ شرح Atlassian لتعريف الإتمام.

قالب تحريري لقائمة الإتمام:

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

هذه البنود أمثلة تصميمية وليست متطلبات موثقة لكل فريق. احذف ما لا ينطبق وأضف ما يعكس تسليماتكم الفعلية.

متى تضيف Blocked أو In review؟

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

يمكن تسجيل سبب التوقف بصيغة عملية مثل: «ينتظر قرارًا من…» أو «يحتاج مدخلًا من…» أو «لا يمكن البدء قبل…». هذه صياغات مقترحة في هذا المقال، وليست حقائق عن أداة محددة.

طريقة تطبيق سريعة على أي لوحة

1. اكتب الحالات الحالية التي يستخدمها الفريق، حتى لو كانت غير متسقة.
2. اجمع الحالات التي تصف المرحلة نفسها تحت اسم واحد.
3. اختبر التسلسل الأساسي: Backlog/Not started → Ready → In progress → In review → Done.
4. قرر هل تحتاجون فعلًا إلى Blocked وCanceled/Not planned.
5. اكتب جملة تعريفية لكل حالة، وحدد من يملك قرار نقل المهمة.
6. افصل الأولوية والنوع والقسم والعميل والاعتمادية في تسميات أو حقول أخرى.
7. اعرض القالب على الفريق وعدّله وفق نقاط التسليم الفعلية.

الخطوة السادسة والسابعة هنا توصيتان تحريريّتان لتقليل خلط المرحلة بالبيانات الوصفية، وليستا ضمانًا لنتيجة معينة.

أسماء ثنائية اللغة

إذا كان الفريق عربيًا وإنجليزيًا، استخدم اسمين ثابتين بجانب بعضهما، مثل: قيد التنفيذ / In progress، وقيد المراجعة / In review، ومكتمل / Done. وثّق المعنى بجوار اللوحة، ولا تبدّل الترجمة من مهمة إلى أخرى. هذا اقتراح تحريري لتحسين الاتساق اللغوي؛ لا يفترض أن كل فريق يحتاج إلى اللغة نفسها.

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