لا تحفظ النتيجة فقط: كيف تبني سجل قرارات يحمي ذاكرة مشاريعك؟

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

النتيجة وحدها لا تكفي

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

ما هو سجل القرارات؟

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

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

لا تسجل كل قرار

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

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

كلما كانت تكلفة نسيان سبب القرار مرتفعة، زادت قيمة تسجيله.

القرارات المؤقتة أخطر من القرارات الدائمة

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

اربط القرار بالواقع الذي صنعه

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

سجل البدائل المرفوضة

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

سطران ربما يوفران ساعات مستقبلية.

أين نضع سجل القرارات؟

المكان المثالي هو المكان الذي سيبحث فيه الشخص أصلًا. في مشروع برمجي قد يكون:

docs/decisions/

أو:

DECISIONS.md

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

سجل القرار ونقطة الاستئناف ليسا الشيء نفسه

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

بينما:

الاثنان معًا يصنعان ذاكرة أفضل بكثير للمشروع.

القرار المكتوب يقلل العبء على العقل

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

قالب يكفي لمعظم القرارات

لا تحتاج إلى نظام أكثر تعقيدًا من هذا:

ليس ضروريًا ملء كل خانة دائمًا. الغرض من القالب أن يجعل التفكير منظمًا، لا أن يصنع بيروقراطية جديدة.

المرونة هي أيضًا الحفاظ على ذاكرة النظام

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