من يتولى طلب العمل غير المسند؟ قوائم الانتظار واستلام العمل وتسليمه في تطبيق الأعمال
اجعلوا لكل طلب جديد مكانًا واضحًا ينتظر فيه، ولكل طلب نشط شخصًا معروفًا مسؤولًا عن الخطوة التالية. يمكن لقائمة مشتركة أن تجمع الأعمال غير المسندة، لكن عبارة «سيراه الفريق» ليست قاعدة توزيع مكتملة. قبل تطوير تطبيق لسير العمل، حددوا من يراقب القائمة، وكيف يستلم أحد الموظفين طلبًا، وماذا يحدث عند انتقال المسؤولية.
المقصود هنا مسؤولية تنفيذ العمل، لا ملكية بيانات العملاء أو صلاحية قراءة السجل. إسناد الطلب لا ينبغي أن يمنح وصولًا غير محدود بصورة عرضية، وإلغاء الإسناد لا ينبغي أن يمحو العمل المنجز سابقًا.
افصلوا القائمة عن المسؤول عن الخطوة التالية
توضح قائمة الانتظار مكان العمل قبل توزيعه. ويوضح الإسناد من ينبغي له اتخاذ الخطوة التالية. أما المتابع فقد يريد الاطلاع على المستجدات فقط. لا تجعلوا هذه العلاقات الثلاث متطابقة.
قد تختارون مسؤولًا واحدًا مع عدة مساهمين، أو مرحلة يتولاها الفريق ثم تُسند إلى شخص عند بدء التنفيذ. كلاهما قد يناسب نشاطًا معينًا. اكتبوا القاعدة بدل ترك المطور يستنتجها من عدد الأسماء الظاهرة على بطاقة المهمة.
تقدم وثائق مهام Asana مثالًا على إمكان فصل العلاقات في البيانات: يصف مخطط تحديث المهمة حقل assigned_by للشخص الذي أسندها، ومجموعة followers لمن يتابعونها. لا يثبت ذلك أن المستلِم قبل المسؤولية أو أن إشعارًا وصل إليه. يحتاج سير العمل إلى اتفاق واضح بشأن هذين الأمرين.
متى يصبح استلام الطلب نافذًا؟
في مثال افتراضي لفريق صيانة، تدخل الطلبات الجديدة إلى قائمة مشتركة. يضغط فني على «استلام هذا الطلب». النتيجة المهمة هي إسناد محفوظ، لا مجرد اختفاء البطاقة من القائمة على شاشة ذلك الفني.
اطلبوا من المطور عرض محاولة شخصين استلام طلب اختباري واحد غير مسند في الوقت نفسه. إذا كانت القاعدة تسمح بمسؤول واحد، فينبغي أن تنجح محاولة واحدة فقط. ويجب أن يرى الشخص الآخر الإسناد الحالي وأن يعرف أن محاولته لم تُقبل. استبدال الإسناد الأول بصمت يترك الطرفين مع تصور غير موثوق للمسؤولية.
تحذر وثائق تحديث مهام Asana من إرسال حقول إضافية لا يُقصد تعديلها، لأن ذلك قد يستبدل تغييرات أجراها مستخدم آخر منذ آخر جلب للمهمة. يدعم هذا الحذر من التحديث اعتمادًا على نسخة قديمة، لكنه لا يثبت أن عملية استلام معينة تضمن حصر الطلب بشخص واحد. اطلبوا سلوك التعامل مع المحاولات المتزامنة صراحة في تطبيقكم.
هل النقل فوري أم عرض لتسليم المسؤولية؟
إعادة الإسناد الفورية تغيّر المسؤول مباشرة. أما عرض التسليم فيبقى معلقًا حتى يقبله الشخص الآخر أو يحسمه مسؤول مخول.
اختاروا المسار المطلوب. إذا كان التسليم معلقًا، فحددوا من يبقى مسؤولًا خلال الانتظار، وهل تنتهي صلاحية العرض، وما الذي يحدث إذا رفضه المستلِم. لا ينبغي أن يعتقد كل طرف أن الآخر هو الذي ينتظر منه اتخاذ الخطوة التالية.
ينبغي أن يحمل التسليم سياقًا يكفي للاستمرار: الخطوة المقبلة، والموعد المهم، والمشكلة المفتوحة. لكن لا تنسخوا الملاحظات المقيدة إلى إشعار الإسناد لمجرد تسمية شخص مستلِمًا للطلب. تحققوا من صلاحية الوصول بصورة مستقلة.
وفروا مسارًا حين يصبح المسؤول غير متاح
حددوا من يتعامل مع أعمال شخص في إجازة، أو حسابه معطل، أو لم يعد مؤهلًا للعمل ضمن تلك القائمة. يمكن أن تعرض شاشة مراجعة الطلبات النشطة المتأثرة والخطوات التالية. ولا ينبغي أن تعيد كتابة التاريخ المكتمل كأن البديل هو من أنجز العمل السابق.
قرروا أيضًا مصير العمل الجديد حين لا يتوفر أحد. إبقاؤه غير مسند بوضوح، أو تصعيده إلى مسؤول محدد عن القائمة، أو إيقاف استقبال الطلبات مؤقتًا خيارات مختلفة. لا تعرضوا محاولة توزيع لم تجد شخصًا مؤهلًا على أنها إسناد ناجح.
الإشعار ليس بديلًا عن الحالة المحفوظة. إذا فشل إرسال الرسالة، فيجب أن يظل التطبيق يوضح المسؤول عن الطلب، أو أن التوزيع لم يُحسم بعد. اسألوا كيف يكتشف الموظفون الإشعارات الفائتة من دون إنشاء إسنادات مكررة.
اختبروا الانتقالات الصعبة
استخدموا سجلات وهمية، وأدرجوا الحالات التالية ضمن معايير قبول المشروع:
- يظهر الطلب الجديد غير المسند في القائمة المطلوبة، مع تحديد من يراقبها.
- تتبع محاولات الاستلام المتزامنة قاعدة المسؤول الواحد أو المسؤولية المشتركة المتفق عليها.
- تُظهر المحاولة غير المقبولة نتيجتها من دون استبدال الإسناد الذي قُبل.
- يوضح التسليم المعلق من يبقى مسؤولًا إلى حين القبول.
- توجد طريقة محددة لحسم الرفض وعدم توفر المستلِم.
- يكشف تعطيل الحساب العمل غير المكتمل المسند إليه للمراجعة، من دون تغيير نسبة العمل السابق إلى أصحابه.
- لا يجعل فشل الإشعار إسنادًا غير محسوم يبدو مكتملًا.
عند مناقشة تطبيق مخصص لسير العمل، أحضروا مثالًا لتسليم عادي وآخر لاستثناء صعب، بعد إزالة التفاصيل السرية. إذا استطاع الجميع تحديد من عليه التصرف في كل مرحلة، أصبح من الممكن كتابة قواعد توزيع واضحة. وإن لم يستطيعوا، فلن تحل لوحة مهام أكثر تعقيدًا هذا الغموض.
المصادر وحدود الاستناد إليها
Asana، مرجع المهام: https://developers.asana.com/reference/tasks
Asana، تحديث مهمة: https://developers.asana.com/reference/updatetask
الحقائق المستندة إلى المصدر هي حقول العلاقات المذكورة والتحذير من استبدال تغييرات أحدث عند التحديث. قوائم الانتظار وحصر الاستلام وقبول التسليم والتصعيد متطلبات مقترحة، وليست ضمانات لسلوك Asana أو لوصول الإشعارات.