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

ابدأ بالفجوة، وليس بالبرمجيات

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

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

استخدم موجز المشكلة عندما يكون السؤال غير واضح

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

يفصل ملصق المشروع (Project Poster) من Atlassian بين مساحة المشكلة، والتحقق، والتحضير للتنفيذ. وتوضح إرشاداته أيضاً أنه ليس كل مشروع بحاجة إلى ملصق. استعر التمييز بين المعلومات المعروفة والافتراضات؛ ولا تُنشئ وثيقة معقدة لسؤال يمكن لبضع جمل واضحة حسمه. اطلب من شخص خارج نطاق المهمة المباشرة أن يشرح المشكلة بأسلوبه الخاص، وإذا اختلف شرحه، فراجع الموجز قبل مقارنة الحلول.

ارسم فقط مراحل تسليم المهام المهمة

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

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

استخدم سجل القرارات عندما يكون الخيار جاهزاً

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

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

تحقق مما إذا كانت المادة فعالة ومجدية

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

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

متابعة استكشاف الموضوع