سجلّ القرارات: كيف توثّقون قراراتكم كي لا تضيع أسبابــها

اسألوا فريقًا عن سبب وجود سياسة ما، وغالبًا ما ستسمعون صمتًا قصيرًا. يتذكّر أحدهم اجتماعًا، ويظنّ آخر أن الأمر تعلّق بمورّد. أما الشخص الذي كان يعرف فقد غادر العام الماضي. بقي القرار، ولم تبقَ أسبابه.

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

لماذا تنسى المؤسسات أسباب قراراتها

ثلاث قوى تعمل ضد ذاكرة المؤسسة لقراراتها.

• الأسباب تعيش في المحادثات. تُتّخذ القرارات في الاجتماعات والمكالمات وسلاسل الرسائل. تصل النتيجة إلى سياسة أو خطة، أما السياق فنادرًا ما يصل.
• الناس يتنقّلون. من وازنوا بين الخيارات يغيّرون أدوارهم أو يغادرون، ويرحل فهمهم معهم.
• الذاكرة تعيد كتابة نفسها. في دراسة نُشرت عام 1975، وجد عالم النفس باروخ فيشهوف أن الناس، حين يعرفون النتيجة، يحكمون عليها بأنها كانت متوقّعة أكثر مما كانت فعلًا، وسمّى ذلك «الحتمية الزاحفة». بعد وقوع الأمر، يبدو القرار السليم الذي انتهى بنتيجة سيئة متهوّرًا، ويبدو القرار المحظوظ حكيمًا.

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

وتصف إرشادات مايكروسوفت المعمارية الكلفة بوضوح: القرار الذي لا يُسجَّل سيُنسى على الأرجح، ويقود إلى نقاشات متكرّرة.

ما تعلّمته فرق البرمجيات: سجلّ القرار المعماري

لدى هندسة البرمجيات جواب مُجرَّب. ففي نوفمبر 2011، اقترح مايكل نيغارد «سجلّ القرار المعماري» (ADR): وثيقة قصيرة لكل قرار مهم، مرقّمة بالتسلسل ومحفوظة مع المشروع. ويتكوّن نموذجه من خمسة أجزاء.

• العنوان. عبارة اسمية قصيرة مع رقم، مثل: «ADR 9: استخدام LDAP للتكامل متعدّد المستأجرين».
• السياق. القوى المؤثّرة: التقنية والسياسية والاجتماعية والمحلية. وطلب نيغارد أن يكون هذا القسم محايدًا، يصف الوقائع فقط.
• القرار. الاستجابة لتلك القوى، بجمل كاملة وبصيغة المعلوم: «سنقوم بـ…».
• الحالة. مقترح، أو مقبول، أو متقادم، أو مُستبدَل، مع إحالة إلى البديل إن وُجد.
• العواقب. الواقع الناتج بعد تطبيق القرار. وبحسب نيغارد، يجب أن تُدرج العواقب كلها، لا الإيجابية منها فقط.

انتشرت هذه الممارسة. فقد وضعت شركة Thoughtworks سجلّات القرارات المعمارية الخفيفة في حلقة «اعتمِدوا» (Adopt) من رادارها التقني، وهي أعلى درجات التوصية لديها، ونصحت بحفظها مع الشيفرة المصدرية لا في موقع ويكي منفصل. ويصف إطار Azure Well-Architected من مايكروسوفت سجلّ القرارات بأنه من أهم ما يسلّمه مهندس الحلول. وتضيف إرشاداته قاعدتين تستحقان الاقتباس: عاملوا السجلّ على أنه سجلّ إضافة فقط لا يُعدَّل، ودوّنوا مستوى الثقة مع كل قرار.

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

ماذا يجب أن يتضمّن سجلّ القرار

سجلّ القرارات هو مجموعة هذه السجلّات، مع فهرس يلخّص كلًّا منها. ويصفه دليل الممارسات الهندسية في مايكروسوفت بأنه جدول من الملخّصات التنفيذية، مع بيانات وصفية، للقرارات المحفوظة في السجلّات الكاملة. ويصلح النموذج التالي لما هو أبعد بكثير من الهندسة، ولكل حقل فيه سبب.

• الرقم والعنوان. رقم وعبارة تقول ما الذي تقرّر.
• التاريخ. تاريخ اتخاذ القرار، لا تاريخ كتابته.
• المسؤول. الشخص المساءَل عن القرار، ومن استُشير فيه.
• السياق. المشكلة والقيود والقوى المتعارضة.
• الخيارات المدروسة. بما فيها ما رُفض ولماذا. وهذا أكثر الحقول غيابًا، وأكثرها حاجة.
• القرار. جملة واحدة واضحة تبدأ بـ«سنقوم بـ…».
• الأدلّة. روابط إلى البيانات أو التقارير أو التدقيقات أو الملاحظات التي استند إليها القرار.
• النتيجة المتوقّعة. ما الذي يجب أن يتحقّق إن نجح القرار، ومتى.
• مستوى الثقة. مرتفع أو متوسّط أو منخفض، مع سطر عمّا بقي غير مؤكّد.
• موعد المراجعة. متى سيُقارن القرار بنتيجته المتوقّعة.
• الحالة. مقترح، أو مقبول، أو مُستبدَل، أو منتهٍ، مع رابط إلى البديل إن وُجد.

يؤدّي حقلا النتيجة المتوقّعة ومستوى الثقة عمل «يوميات القرار»، فهما يدوّنان ما كنتم تعتقدونه قبل أن تعرفوا النتيجة، وهذا تحديدًا ما تمحوه معرفة ما حدث لاحقًا.

ونُلزم قرارات منتجاتنا بالعادة نفسها: يُكتب ما لوحظ بمعزل عمّا استُنتج، وتُحفظ الآراء المتعارضة كما هي، بلا تجميل. والقرار يستحق هذه العناية على الأقل.

اربطوا كل قرار بأدلّته وبنتيجته

السجلّ المعزول أفضل من لا شيء، لكن السجلّ المترابط أنفع بكثير.

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

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

اربطوا أفقيًا بالقرارات اللاحقة. حين يُلغى قرار، لا تعدّلوا سجلّه القديم. علّموه بأنه «مُستبدَل» وأحيلوا إلى القرار الجديد. فتاريخ تغيّر الاتجاه كثيرًا ما يكون أثمن ما في السجلّ.

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

أبقوه خفيفًا كي يدوم

تفشل سجلّات القرارات كما يفشل معظم التوثيق: تصبح عبئًا، ثم تتوقّف. وخمس قواعد تُبقيها حيّة.

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

القرار من دون أسبابه أمرٌ يُنفَّذ. أما القرار مع أسبابه فيمكن اختباره أو إبقاؤه أو تغييره بعناية.

كيف يحفظ Prism سجلّات القرارات

يحفظ Prism قرارات المؤسسة ومعرفتها عناصرَ لكلٍّ منها مستوى ثقة معلن: مُصادَق عليه، أو مدعوم بالأدلّة، أو مُلاحَظ، أو مُستنتَج. ويرتبط كل قرار بأدلّته، وبالخطوات التي تنفّذه، وبالنتائج ودروس «توقّف وتعلّم» التي تليه. وحين يُستبدَل قرار، يبقى القرار السابق ظاهرًا. ويمكن للمساعدات الذكية التي يستخدمها فريقكم أن تقرأ السجلّ أيضًا، فتكون الأسباب حاضرة حين يسأل أحد. الناس هم من يتّخذون القرارات، وPrism يحفظ أسبابها.

المصادر

1. Documenting Architecture Decisions. Michael Nygard, Relevance (now Cognitect) blog, 2011.
2. Architecture decision record (Azure Well-Architected Framework). Microsoft Learn, 2024.
3. Decision Log (Code-With Engineering Playbook). Microsoft, 2024.
4. Lightweight Architecture Decision Records (Technology Radar). Thoughtworks, 2018.
5. Hindsight ≠ foresight: The effect of outcome knowledge on judgment under uncertainty. Journal of Experimental Psychology: Human Perception and Performance 1(3) (B. Fischhoff), 1975.

التعليقات

اسمكمتعليقكم

تظهر التعليقات بعد أن يقرأها فريقنا. لا تذكروا تفاصيل شخصية عن مرضى أو زملاء.

أرسلوا التعليق