> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # قرارات تقنية سيئة Bad Decisions: كيف تحمي النظام والثقة؟ - URL: https://arabroot.io/articles/قرارات-تقنية-سيئة-bad-technical-decisions-حماية-النظام-والثقة/ - Published: 2026-10-31T10:05:28.000Z - Updated: 2026-10-31T11:04:53.000Z - Description: ماذا يفعل القائد عندما تضر قرارات مهندس النظام مرة بعد مرة، وكيف يحمي النظام بمستويات مراجعة وسجل قرار دون أن يسحب منه الثقة أو يحكم عليه من نتيجة واحدة. - Author: فريق عرب رووت - Tags: الأدلة التقنية, القيادة التقنية شركة ناشئة تبني منصة حجوزات للعيادات، فيها ستة مهندسين ومؤسس تقني CTO يقضي نصف وقته مع العملاء، وظفت قبل أربعة أشهر مهندساً أول Senior Engineer جاء من شركة كبيرة تخدم ملايين المستخدمين، وأعطاه المؤسس من أول أسبوع «الكلمة الأخيرة في القرارات التقنية» لأنه أكثر الفريق خبرة. وخلال أربعة أشهر قسم المهندس النظام إلى تسع خدمات مصغرة Microservices، وأضاف Kafka كوسيط رسائل، وبدأ تجربة شبكة خدمات Service Mesh، واختار MongoDB لتخزين معاملات الدفع. والنتيجة أن الفريق صار يقضي أغلب أسبوعه في البنية التحتية بدل الميزات، وأن الإصدارات تباطأت، وأن نظام الدفع تعطل مرتين في شهر واحد بسبب بيانات غير متسقة، وأن مهندسين اثنين جاءا للمؤسس يشتكيان، وأحدهما قال: «كل قرار يجي جاهز، وإذا اعترضنا يقول إحنا ما نفهم في الأنظمة الكبيرة». والمؤسس الآن أمام سؤال صعب: هل هذا مهندس قراراته سيئة ويجب أن تسحب منه الصلاحيات، أو أن يغادر؟ أو أن المشكلة في شيء آخر؟ وهذا المقال عن هذا النوع من ضعف الأداء Underperformance بالتحديد: مهندس يعمل بجد ويعرف كثيراً، ولكن قراراته التقنية تضر النظام أو الفريق مرة بعد مرة، وكيف يحمي القائد النظام من القرارات الخاطئة دون أن يهدم ثقة المهندس بنفسه أو ثقة الفريق به، ودون أن يحول كل قرار إلى لجنة. وسوف نناقش في هذا المقال ما يلي: - ما الذي يجعل القرار سيئاً، ولماذا لا تحكم عليه من نتيجته وحدها. - الأنماط التي تتكرر في القرارات التقنية الخاطئة، وأسبابها بين المهارة Skill والرغبة Will والبيئة Context. - مربع الدين التقني Technical Debt Quadrant، والقرارات التي يمكن التراجع عنها والتي لا يمكن. - ثلاث حالات: شركة ناشئة ومهندس أول جاء من شركة كبيرة، وشركة متوسطة ومهندس يختصر الطريق، وجهة شبه حكومية وقائد تقني لا يراجع قراره. - سجل القرار المعماري ADR ومستويات المراجعة، كطريقة تحمي النظام دون أن تسحب الثقة. - كيف تتراجع عن قرار نفذ دون إهانة صاحبه، وماذا تفعل إذا كنت أنت المهندس الذي ترفض قراراته. - أداة عملية: سكربت يحدد مستوى المراجعة لكل قرار، وقالب لسجل القرار. ## القرار شيء والنتيجة شيء آخر (Decision vs Outcome) أول خطأ يقع فيه المديرون أن يحكموا على القرار من نتيجته. فإذا نجح القرار كان صاحبه ذكياً، وإذا فشل كان صاحبه متهوراً، وهذا الحكم يظلم الناس في الاتجاهين: يظلم المهندس الذي درس الخيارات بعناية وكتب خطة تراجع Rollback ثم تغير شيء خارج يده، ويكافئ المهندس الذي نشر تغييراً ضخماً يوم الخميس دون اختبار ومر بسلام بالصدفة. والخانة الثانية هي الأخطر، لأن الحظ فيها يعلم صاحبه أن الطريقة الخاطئة تنجح، فيكررها حتى يأتي اليوم الذي لا ينجح فيه الحظ. ![أربع خانات تفصل جودة القرار عن نتيجته: قرار جيد ونتيجة جيدة عندما يقارن ثلاثة بدائل ويختار الأبسط وينجح، وقرار جيد ونتيجة سيئة عندما يدرس الخيارات ويكتب خطة تراجع ثم يتغير السوق فلا لوم وإنما تعلم، وقرار سيئ ونتيجة جيدة عندما ينشر تغييراً كبيراً يوم الخميس دون اختبار ويمر بسلام وهي أخطر خانة لأنها تعلم الخطأ، وقرار سيئ ونتيجة سيئة عندما يختار تقنية جديدة لنظام الدفع دون بدائل ودون سجل قرار فيتعطل النظام](https://arabroot.io/content/images/2026/10/bad-technical-decisions-01-decision-outcome.webp) المهندس الذي «قراراته سيئة» هو من يتكرر عنده نفس الخلل في الطريقة، وليس من خسر رهاناً مرة لذلك عندما تقيم قرارات مهندس، لا تسأل «هل نجح القرار؟» فقط، وإنما اسأل عن الطريقة: هل فهم المشكلة الحقيقية قبل أن يختار الحل؟ هل قارن أكثر من بديل، ومنها بديل «لا نفعل شيئاً الآن»؟ هل عرف كم يكلف التراجع عن القرار لو كان خطأ؟ هل استشار من سيتأثر به، ومن سيشغله في الثالثة فجراً؟ هل كتب سبب القرار حتى يفهمه من يأتي بعده؟ وعندما يتكرر عند نفس الشخص نفس الخلل في الطريقة، في قرارات مختلفة، هنا يصبح عندك نمط يستحق أن تتحدث عنه، وليس قبل ذلك. وفي قصتنا، قرار MongoDB لمعاملات الدفع لم يكن سيئاً لأن النظام تعطل، وإنما لأنه اتخذ دون مقارنة بديل واحد، ودون أن يسأل أحد هل تحتاج المعاملات اتساقاً Consistency كاملاً، وهو سؤال جوابه معروف في أي نظام دفع. ولو تعطل النظام مع PostgreSQL بعد مقارنة جادة وخطة مكتوبة، لكانت المحادثة مختلفة تماماً. ## أنماط تتكرر في القرارات الخاطئة (Recurring Patterns) القرارات التقنية الخاطئة ليست عشوائية، وأغلبها يقع في أنماط معروفة، ومعرفة النمط تساعدك أن تصف المشكلة بدقة بدلاً من «قراراتك سيئة»: - **تقنية للسيرة الذاتية Resume-driven Development:** اختيار أداة لأنها جديدة ومطلوبة في سوق العمل، وليس لأنها تحل مشكلة الفريق. والمهندس قد لا يقصد ذلك، ولكن الحماس للتقنية الجديدة يجعله يرى المشكلة بحجم الأداة. - **التصميم لحجم غير موجود Over-engineering:** نظام مصمم لمليون مستخدم في شركة عندها ألف، وخدمات مصغرة لفريق من ستة. وهذا النمط شائع عند من جاء من شركة كبيرة، لأن ما كان صحيحاً هناك يبدو له صحيحاً في كل مكان. - **الاختصار المحلي Local Shortcut:** حل يسرع مهمته اليوم ويضر النظام كله، مثل قراءة جداول خدمة أخرى مباشرة، أو تجاوز مكتبة المصادقة Authentication المشتركة، أو مهمة مجدولة Cron Job على سيرفر واحد لا يعرف عنها أحد. - **القرار الصامت Undocumented Decision:** قرار كبير يتخذ في محادثة جانبية أو في طلب دمج Pull Request، ولا يكتب سببه في أي مكان، فلا يستطيع أحد أن يراجعه أو يفهمه بعد سنة. - **رفض المراجعة بعد الدليل Sunk Cost:** صاحب القرار يدافع عنه بعد أن ظهرت الأدلة على فشله، لأن التراجع يبدو له اعترافاً بالخطأ، أو لأن ما صرف عليه كبير. - **الشلل في القرار Analysis Paralysis:** وهو النمط المعاكس، فبعض المهندسين لا يتخذون قراراً أبداً، ويطلبون مزيداً من البحث، والتأخير نفسه قرار خاطئ يدفع الفريق ثمنه. والنمط الأول والثاني لهما وصف مشهور في مقال [Choose Boring Technology لـ Dan McKinley](https://mcfunley.com/choose-boring-technology?ref=arabroot.io)، حيث يقترح أن كل شركة عندها تقريباً ثلاثة «رموز ابتكار» Innovation Tokens فقط، تصرفها على التقنيات الجديدة، وأن كل تقنية جديدة، مثل لغة أو قاعدة بيانات أو أداة لم تعرفها الشركة من قبل، تستهلك رمزاً، والعدد ثابت لفترة طويلة. والفكرة ليست أن التقنية الجديدة سيئة، وإنما أن كل واحدة تحتاج تعلماً وتشغيلاً ومراقبة وأخطاء جديدة، وأن الشركة الصغيرة لا تتحمل منها إلا القليل في نفس الوقت. والمهندس في قصتنا صرف في أربعة أشهر أربعة رموز، كما سنرى في نتيجة سكربت الأداة. ## لماذا يتخذها؟ (Skill, Will, Context) في مقال تشخيص ضعيف الأداء Underperformer في هذه المرحلة نقسم الأسباب إلى المهارة Skill والرغبة Will والبيئة Context، وهذا التقسيم يعمل هنا أيضاً، ولكن بشكل خاص بالقرارات: **المهارة:** المهندس لا يعرف بنية النظام، أو لا يعرف كيف يقارن البدائل، أو لا يعرف تكلفة التشغيل لما يختاره، أو خبرته كلها في سياق مختلف، مثل شركة كبيرة فيها فريق منصة Platform Team يشغل كل شيء. وهذا الأخير ليس ضعفاً في القدرة، وإنما خبرة صحيحة في مكان خطأ، وعلاجها أن يفهم القيود الحقيقية للمكان الجديد. **الرغبة:** المهندس يعرف الطريقة الصحيحة، واتفقت معه على عملية واضحة للقرارات الكبيرة، ثم يتجاوزها مرة بعد مرة لأنه يراها بطيئة أو يرى نفسه فوقها. وهنا لا تتحدث عن جودة القرار، وإنما عن الالتزام باتفاق. **البيئة:** وهذه الأكثر حضوراً في هذا النوع، لأن القرارات السيئة تنمو غالباً في فراغ: لا توجد عملية مكتوبة لاتخاذ القرار، ولا يعرف أحد من يقرر ماذا، والقيود الحقيقية للشركة، من حجم الفريق إلى المدة التي يكفيها المال، لم تشرح للمهندس، والمدير أعطى صلاحية كاملة دون حدود ثم غاب. وفي قصتنا، المؤسس هو من قال «الكلمة الأخيرة لك»، ولم يقل له أبداً إن الشركة تحتاج أن تثبت منتجها خلال سنة بفريق من ستة. ![مربع الدين التقني عند Martin Fowler بأربع خانات: متهور ومتعمد بعبارة ما عندنا وقت للتصميم وتقابل في القيادة مشكلة رغبة أو ضغطاً من البيئة، وحكيم ومتعمد بعبارة ننشر الآن ونعالج النتائج وهو قرار محسوب يكتب في سجل قرار، ومتهور وغير مقصود بعبارة ما هي الطبقات وتقابل مشكلة مهارة علاجها تعليم ومراجعة، وحكيم وغير مقصود بعبارة الآن عرفنا كيف كان يجب أن نصممه وهو تعلم وليس خطأ](https://arabroot.io/content/images/2026/10/bad-technical-decisions-04-quadrant.webp) المربع يساعدك أن تعرف أي محادثة تحتاجها مع المهندس، قبل أن تقرر أن قراراته «سيئة» ويفيد هنا [مربع الدين التقني عند Martin Fowler](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html?ref=arabroot.io)، الذي يقسم الدين التقني على محورين: متهور Reckless أو حكيم Prudent، ومتعمد Deliberate أو غير مقصود Inadvertent. فالدين الحكيم المتعمد قرار محسوب: الفريق يعرف أنه يأخذ ديناً ليصل لإصدار، ويوازن بين الفائدة وتكلفة السداد، وهذا ما تريده من مهندسيك، والمكان الصحيح له سجل قرار مكتوب. والمتهور غير المقصود يأتي من فريق لا يعرف ممارسات التصميم الجيد، فيأخذ الدين دون أن يعرف كم هو، وهذه مشكلة مهارة. والمتهور المتعمد يأتي ممن يعرف ويستطيع ويختار الطريق «السريع والقذر» لأنه يظن أنه لا يملك الوقت، ويقول Fowler إن هذا غالباً دين متهور لأن الناس يقللون من تقدير الوقت الذي يصبح فيه التصميم الجيد أسرع. والخانة الرابعة، الحكيم غير المقصود، يقول عنها Fowler إنها حتمية حتى لأفضل الفرق، لأنهم يتعلمون أثناء العمل، فيكتشفون بعد أن ينتهوا كيف كان يجب أن يصمموا. وهذه الخانة لا تعامل كخطأ أبداً. ## باب باتجاهين أم باب باتجاه واحد؟ (Two-way Doors) ليس كل قرار يحتاج نفس الحذر، والمدير الذي يطلب مراجعة لكل قرار يقتل سرعة الفريق، والمدير الذي لا يطلب مراجعة لأي قرار يترك الباب مفتوحاً لقرار واحد يكلف الشركة سنة. والتقسيم العملي الأشهر جاء في [رسالة Jeff Bezos للمساهمين عام 2016](https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders?ref=arabroot.io): كثير من القرارات قابلة للتراجع، أي أبواب باتجاهين Two-way Doors، وهذه تكفيها عملية خفيفة، وإذا كانت خاطئة فالتراجع عنها سهل. وتقول الرسالة أيضاً إن أغلب القرارات يجب أن تتخذ بحوالي 70% من المعلومات التي تتمنى أن تكون عندك، وإن انتظار 90% يعني غالباً أنك بطيء، وإن المهم في الحالتين أن تكون سريعاً في اكتشاف القرارات الخاطئة وتصحيحها. ![ثلاث فئات للقرارات: باب باتجاهين قابل للتراجع مثل إعادة تسمية حقول داخلية في الواجهة وإضافة طبقة تخزين مؤقت ومكتبة لمفاتيح الميزات ويكفيه أن تقرر وتخبر الفريق، وتراجع مكلف مثل نقل خط النشر ووسيط رسائل جديد وتغيير المصادقة الداخلية ويحتاج استشارة من يعرف الجزء المتأثر، وباب باتجاه واحد لا رجوع عنه مثل قاعدة بيانات معاملات الدفع وتقسيم النظام إلى خدمات مصغرة وصيغة بيانات يعتمد عليها العملاء ويحتاج سجل قرار ومراجعة تصميم قبل الكود](https://arabroot.io/content/images/2026/10/bad-technical-decisions-02-doors.webp) القرار الذي يمكن التراجع عنه يتخذ بسرعة، والقرار الذي لا رجوع عنه يحتاج مراجعة مكتوبة والقرار الذي لا رجوع عنه بسهولة، أي الباب باتجاه واحد One-way Door، هو الذي يحتاج البطء والكتابة والمراجعة: قاعدة البيانات التي ستحمل معاملات الدفع، وتقسيم النظام إلى خدمات، وصيغة البيانات التي سيعتمد عليها العملاء في تكاملهم. وبين النوعين قرارات تراجعها ممكن ولكنه مكلف، مثل نقل خط النشر CI/CD Pipeline من أداة لأخرى، وهذه تحتاج استشارة قبل التنفيذ دون أن تحتاج لجنة. وهذا التقسيم هو أهم أداة عندك لحماية النظام من مهندس قراراته تخطئ كثيراً، لأنه يسمح لك أن تبقيه سريعاً وحراً في كل القرارات الصغيرة، وأن تضع الحماية فقط حيث يكون الخطأ مكلفاً. فمشكلة المهندس في قصتنا لم تكن أنه يقرر بسرعة، وإنما أنه عامل الأبواب باتجاه واحد كأنها أبواب باتجاهين. وفي نفس الرسالة عبارة مهمة لما بعد القرار: «اختلف والتزم Disagree and Commit». فعندما يكون لدى صاحب القرار قناعة باتجاه معين رغم غياب الإجماع، يطلب من المختلفين أن يلتزموا معه رغم اختلافهم، وتقول الرسالة إن هذا ليس في اتجاه واحد، فالمدير أيضاً يجب أن يفعله مع فريقه. وطريقة إدارة الخلاف التقني نفسه، قبل القرار، مشروحة في مقال الخلاف التقني Conflict، والمهم هنا أن الالتزام بعد القرار يحتاج قراراً واضحاً، ومن قرره، ولماذا، وهذا ما يغيب في أغلب حالات القرارات السيئة. ## الحالة الأولى: مهندس أول جاء من شركة كبيرة (Startup) نعود لقصتنا. المهندس الأول عمل سبع سنوات في شركة كبيرة، كان فيها فريق منصة يشغل Kafka وشبكة الخدمات، وفريق قواعد بيانات، ومناوبة On-call من عشرات المهندسين، وكل ما فعله في الشركة الناشئة كان صحيحاً تماماً هناك. وهو يعمل بجد، ويحب النظام، ويرى نفسه يبني الشركة «بالطريقة الصحيحة من البداية». ولم يقل له أحد أن الشركة عندها مال يكفي ثمانية عشر شهراً، وأن المهم الآن أن تصل لعشرين عيادة تدفع، وأن الفريق كله ستة أشخاص لا يعرف أحد منهم Kafka. ### ماذا يحدث عادة؟ (What Usually Happens) ما يحدث عادة أن المؤسس يتأرجح بين طرفين. في البداية يترك كل شيء للمهندس الأول لأنه «الخبير»، ثم عندما تتراكم الأعطال والشكاوى يسحب منه كل الصلاحيات دفعة واحدة، وقد يقول في اجتماع الفريق «من اليوم أي قرار تقني يمر علي»، فيفهم الفريق أن المهندس الأول فشل علناً، ويفهم المهندس أن سبعة أشهر من عمله صارت خطأً، فيبدأ يبحث عن وظيفة أخرى، أو يبقى ويتوقف عن اقتراح أي شيء. ### ما الذي يزيده سوءاً؟ (What Makes It Worse) - أن يسحب المؤسس الصلاحيات علناً دون محادثة خاصة قبلها. - أن يحكم على كل القرارات معاً، الجيد منها والسيئ، فلا يعرف المهندس ما الذي كان صحيحاً. - أن يأمر بالتراجع عن كل شيء دفعة واحدة، فيخسر الفريق شهرين آخرين في التراجع كما خسر شهرين في البناء. - أن يتجنب المؤسس الاعتراف بأنه هو من أعطى الصلاحية دون حدود ودون أن يشرح القيود. - أن يصبح المهندسان اللذان اشتكيا هما «من كانا على حق»، فينقسم الفريق إلى معسكرين. ### ما الذي ينجح؟ (What Works) الذي نجح هنا بدأ بمحادثة خاصة بدأها المؤسس بنصيبه: أنه أعطى الصلاحية دون أن يشرح القيود، ثم شرحها بالأرقام: المال الذي يكفي ثمانية عشر شهراً، والهدف التجاري، وحجم الفريق ومهاراته. ثم طلب من المهندس الأول نفسه أن يراجع قراراته الأربعة الكبيرة بهذه القيود، وأن يكتب لكل واحد منها سجل قرار ADR بأثر رجعي فيه البدائل والنتائج. والمهندس، عندما رأى القيود مكتوبة، وصل بنفسه لنتيجة قريبة مما كان الفريق يقوله: أن نظاماً واحداً مقسماً داخلياً إلى وحدات Modular Monolith يكفي الآن، وأن PostgreSQL هو الخيار الصحيح لمعاملات الدفع، وأن Kafka يمكن تأجيله بجدول قائمة انتظار في قاعدة البيانات، وأن شبكة الخدمات لا تحتاجها الشركة الآن. ثم اتفقا على مستويات واضحة للقرارات، سنراها في قسم الحماية: قرارات يقررها ويخبر بها، وقرارات يستشير فيها، وقرارات لا تنفذ دون سجل قرار ومراجعة. والمهم أن هذه المستويات طبقت على الجميع، ومنهم المؤسس، وليس عليه وحده. وبعد ثلاثة أشهر صار المهندس الأول أفضل من يكتب سجلات القرار في الفريق، وصار يراجع قرارات الآخرين بنفس الطريقة، لأن خبرته الحقيقية في الأنظمة الكبيرة صارت تظهر في أسئلته عن التشغيل والمخاطر، وليس في فرض الأدوات. وهذه حالة تحسن فيها الشخص لأن المشكلة الحقيقية كانت في البيئة وفي ملاءمة الخبرة، وليست فيه. ### عبارات تقولها (What to Say) بداية المحادثة الخاصة: > «أبغى أبدأ بشي يخصني أنا: أعطيتك الكلمة الأخيرة من أول أسبوع، وما شرحت لك وضع الشركة الحقيقي. خلني أشرحه الحين بالأرقام، وبعدين نشوف القرارات الكبيرة سوا.» عندما تطلب مراجعة القرارات: > «ما أبغى نرجع عن كل شي. أبغى لكل قرار من الأربعة سجل قرار فيه البدائل، وكم يكلفنا التراجع عنه. وأنت أعرف واحد فينا بهالأنظمة، فأبغاك أنت تكتبها.» للفريق كله، بعد الاتفاق: > «من اليوم عندنا ثلاث مستويات للقرارات التقنية، وتنطبق على الكل وأنا أولهم. والقرارات اللي ما ترجع تحتاج سجل قرار ومراجعة قبل أي كود.» ## الحالة الثانية: مهندس يختصر الطريق (Mid-size Company) شركة متوسطة تبني نظاماً لإدارة المستودعات، فيها أربعة فرق، وكل فريق يملك خدماته. ومهندس متوسط الخبرة Mid-level في أحد الفرق معروف بأنه «يخلص الشغل»، فكل مهمة تعطى له تنتهي قبل موعدها. ولكن فريق المنصة بدأ يلاحظ نمطاً: خدمته تقرأ جداول خدمة المخزون مباشرة من قاعدة بياناتها بدل أن تستدعي واجهتها API، وكتب في مرة طريقة مصادقة خاصة بدل المكتبة المشتركة لأنها كانت «معقدة»، وأضاف مهمة مجدولة على سيرفر واحد تنقل ملفات كل ليلة، وتعطلت عندما أعيد بناء السيرفر ولم يعرف أحد بوجودها. وكل واحد من هذه القرارات وفر عليه يوماً أو يومين، وكلف فرقاً أخرى أسابيع. ### ماذا يحدث عادة؟ (What Usually Happens) ما يحدث عادة أن كل اختصار يكتشف وحده، ويصلحه فريق آخر وحده، ولا يربط أحد بينها، والمهندس يستمر في تلقي المديح على سرعته من مدير المنتج Product Manager، فهو يرى نفسه من أفضل مهندسي الفريق، وفريق المنصة يرى أنه من أكثر من يسبب لهم المشاكل، وكلا الرأيين صحيح من زاويته. ### ما الذي يزيده سوءاً؟ (What Makes It Worse) - أن يستمر المديح العلني على السرعة دون أن يذكر أحد التكلفة على الفرق الأخرى. - أن يشتكي فريق المنصة لمديره في محادثات جانبية بدل أن يصل الكلام لمديره المباشر. - أن تكون مبادئ البنية Architecture Principles غير مكتوبة، فلا يعرف أن قراءة جداول خدمة أخرى ممنوعة. - أن يعامل كل اختصار كحادثة منفصلة، فلا يرى النمط هو ولا مديره. ### ما الذي ينجح؟ (What Works) هذه الحالة في الغالب مزيج من المهارة والبيئة: المهندس لا يعرف بنية النظام ككل لأنه لم يشرحها له أحد، والبيئة تكافئ السرعة المحلية ولا ترى التكلفة العامة. والذي نجح أن قائد الفريق جمع الحالات الثلاث في صفحة واحدة، ومعها تكلفة كل واحدة على الفرق الأخرى، وجلس معه وعرضها كنمط وليس كاتهام. ثم كتبت الشركة صفحة مبادئ بنية قصيرة للجميع، فيها قواعد واضحة مثل «لا تقرأ قاعدة بيانات خدمة أخرى، استخدم واجهتها» و«المصادقة دائماً بالمكتبة المشتركة». واتفق القائد مع المهندس على أن أي تغيير يمس شيئاً مشتركاً، أي قاعدة بيانات فريق آخر أو المصادقة أو البنية التحتية، يمر بجلسة تصميم قصيرة مع القائد قبل التنفيذ لمدة ربع سنة، وأن هذا الترتيب يرفع بعد ذلك إذا لم يتكرر النمط. والنتيجة كانت جزئية في البداية، فقد وقع في اختصار رابع بعد شهر، ولكنه هذه المرة جاء بنفسه وقال إنه وجد أنه قرأ جدولاً من خدمة أخرى في كود قديم له، واقترح كيف يصلحه. وفي نهاية الربع رفع القائد شرط الجلسة، وكتب في تقييمه أنه تحسن في فهم النظام ككل، مع بقاء سرعته. ### عبارات تقولها (What to Say) > «سرعتك شي حقيقي والفريق يستفيد منه. بس جمعت ثلاث حالات في آخر شهرين، كل وحدة وفرت عليك يوم أو يومين، وكلفت فريق المنصة أسبوع. أبغى نشوفها سوا كنمط، مو كأخطاء منفصلة.» > «لمدة ربع سنة، أي تغيير يلمس شي مشترك نجلس عليه نص ساعة قبل ما تبدأ. وهذا مو عقاب، هذا عشان تعرف النظام كله مثل ما تعرف خدمتك، وبعدها نرفعه.» ## الحالة الثالثة: قائد تقني لا يراجع قراره (Government Entity) جهة حكومية لديها منصة لتبادل البيانات مع جهات أخرى، وقائد تقني Tech Lead في الفريق اختار قبل أربع سنوات منصة تكامل تجارية من مورد Vendor، وكان القرار معقولاً وقتها. ولكن خلال السنتين الأخيرتين تغير كل شيء: الإصدار المستخدم خرج من الدعم، والمورد رفع أسعاره، وعدد الجهات المتكاملة تضاعف فظهرت مشاكل أداء، وفريق التطوير صار يكتب حلولاً جانبية حول المنصة أكثر مما يكتب عليها. وكلما اقترح أحد دراسة بديل، رفض القائد بحجج مختلفة، وأحياناً بحدة، ورأى الفريق أن الاقتراح نفسه صار يعامل كهجوم عليه. ### ماذا يحدث عادة؟ (What Usually Happens) ما يحدث عادة في الجهات الكبيرة أن الموضوع يبقى معلقاً سنوات، لأن القرار الأصلي مر بموافقات ولجان، والتراجع عنه يبدو كاعتراف بخطأ مؤسسي، والقائد التقني صاحب القرار هو أيضاً الوحيد الذي يعرف المنصة بعمق، فلا أحد يريد أن يخسره. والفريق يتعب، والمهندسون الأفضل يغادرون، والحلول الجانبية تتراكم حتى يصبح الانتقال أصعب من أي وقت. ### ما الذي يزيده سوءاً؟ (What Makes It Worse) - أن تعامل مراجعة القرار القديم كمحاكمة لصاحبه، فيصبح الدفاع عنه دفاعاً عن النفس. - أن يكون صاحب القرار هو نفسه من يقرر هل يراجع القرار. - أن ينتظر الجميع عطلاً كبيراً ليفرض المراجعة. - أن يتجاوز المدير القائد التقني فجأة ويستعين بمستشار خارجي دون علمه. ### ما الذي ينجح؟ (What Works) الذي نجح هنا كان فصل القرار عن الشخص. فقد طلب مدير الإدارة مراجعة معمارية Architecture Review مستقلة، يقودها فريق البنية في الجهة، بشروط مكتوبة: أن القرار الأصلي كان صحيحاً بمعلومات وقته ويذكر ذلك في أول المراجعة، وأن المراجعة تقارن الوضع الحالي ببديلين على الأقل بالأرقام، وأن القائد التقني عضو فيها ومصدر رئيسي للمعرفة وليس متهماً. وانتهت المراجعة بسجل قرار جديد يستبدل Supersede القديم، ويذكر أن القديم كان مقبولاً عام اتخاذه، وأن الظروف هي التي تغيرت. واكتشف المدير أثناء ذلك شيئاً آخر: أن القائد التقني متخصص ممتاز في التكامل، وأن دور القائد بصلاحيات القرار كان يضعه في موقع يدافع فيه عن كل قرار كأنه هو، بينما كان أداؤه في أفضل حالاته عندما يحل مشاكل تقنية صعبة. وبعد حديث صريح، انتقل إلى دور مهندس رئيسي Principal Engineer للتكامل، مسؤول عن نقل المعرفة والانتقال للمنصة الجديدة، وصار القرار المعماري عند لجنة صغيرة. وهذه حالة كان فيها جزء من المشكلة دوراً لا يناسب صاحبه، وكان الحل تغيير الدور وليس تغيير الشخص. ### عبارات تقولها (What to Say) > «القرار قبل أربع سنين كان صحيح بمعلومات ذاك الوقت، وبنكتب هذا في أول المراجعة. اللي تغير هو الظروف، وأنت أكثر واحد يعرف المنصة، ونحتاجك في المراجعة كمصدر، مو كطرف.» > «لاحظت إنك في أفضل حالاتك لما تحل مشكلة تكامل صعبة، وإن دور القرار يخليك تدافع عن كل شي. وش رأيك في دور يركز على اللي أنت أقوى فيه؟» ## سجل القرار المعماري (Architecture Decision Record) في الحالات الثلاث ظهر سجل القرار المعماري ADR كأداة أساسية، وهو فكرة بسيطة وصفها [Michael Nygard في مقال عام 2011](https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions?ref=arabroot.io): لكل قرار معماري مهم وثيقة قصيرة مرقمة، فيها عنوان قصير، والسياق Context، أي القوى والقيود التي تشد في اتجاهات مختلفة، مكتوبة كحقائق دون رأي، ثم القرار Decision بجمل كاملة تبدأ بـ «سوف»، ثم الحالة Status، مقترح أو مقبول، أو مستبدل بقرار لاحق، ثم النتائج Consequences كلها، الإيجابية والسلبية والمحايدة. ويقول Nygard إن الوثيقة كلها يجب أن تكون صفحة أو صفحتين، وإنها تكتب كأنها حديث مع مطور سيأتي في المستقبل، وإن القرار الذي يعكس لاحقاً لا يحذف، وإنما يعلم بأنه مستبدل، لأن معرفة أنه كان القرار مهمة حتى بعد أن لم يعد القرار. ![مثال سجل قرار معماري لقاعدة بيانات معاملات الدفع: الحالة مقبول ويستبدل سجلاً سابقاً، والسياق معاملات تحتاج اتساقاً كاملاً وفريق من أربعة يعرف PostgreSQL، والبدائل PostgreSQL أو MongoDB أو خدمة مدارة، والقرار سوف نستخدم PostgreSQL، والنتائج الإيجابية والسلبية ومنها ترحيل البيانات الحالية يأخذ أسبوعين، ومتى نراجعه، وبجانبه ما يفعله السجل للقرار بأن يجبر صاحبه على كتابة البدائل والنتائج السلبية، وما يفعله للثقة بأن النقاش يصبح على الورقة وليس على الشخص](https://arabroot.io/content/images/2026/10/bad-technical-decisions-03-adr.webp) صفحة أو صفحتان تكتب كأنها حديث مع مهندس سيأتي بعد سنة، والقرار القديم لا يمحى وإنما يستبدل وأضفنا في القالب قسمين لا يذكرهما مقال Nygard بالاسم، ولكنهما مهمان لموضوعنا: قسم البدائل Alternatives، لأن أكثر خلل يتكرر في القرارات السيئة هو غياب المقارنة، وقسم «متى نراجعه؟» Revisit، لأنه يحول القرار من حكم نهائي إلى رهان له موعد مراجعة، وهذا يسهل على صاحبه أن يتراجع عنه لاحقاً دون أن يشعر بالهزيمة. ولماذا يحمي هذا السجل الثقة وليس النظام فقط؟ لأن الاعتراض يصبح على وثيقة وليس على شخص. فبدلاً من «أنت دائماً تختار أدوات معقدة»، يقول المراجع «في البدائل ما ذكرنا خيار الجدول في قاعدة البيانات، وش رأيك نضيفه ونقارن؟». والمهندس الذي قراراته ضعيفة يتعلم من السجل أكثر مما يتعلم من أي ملاحظة، لأن كتابة البدائل والنتائج السلبية تجبره على التفكير الذي كان يقفز عنه. وموضوع سجل القرار وطريقة إدارته في الفريق له مقال مستقل في مرحلة قائد الفريق التقني Tech Lead. ## حماية النظام دون سحب الثقة (Guardrails, Not Takeover) عندما يكتشف المدير أن قرارات أحد المهندسين تضر النظام، يكون رد الفعل الطبيعي أن يسحب منه القرار كله: «من اليوم أي شيء يمر علي». وهذا يحمي النظام لأسابيع، ولكنه يرسل للمهندس وللفريق رسالة أنه فشل، ويحول المدير إلى عنق زجاجة Bottleneck لكل القرارات، ولا يعلم المهندس شيئاً، لأنه لم يعد يقرر. والبديل الأفضل أن تغير مستوى المراجعة حسب نوع القرار، لا حسب الشخص. ![ثلاثة مستويات للقرار: الأول قرر وأخبر لقرار يمكن التراجع عنه وأثره على الفريق فقط ويكفيه رسالة في القناة، والثاني استشر أولاً لتراجع مكلف أو أثر على المنتج برأي شخصين يعرفان الجزء المتأثر، والثالث مراجعة وسجل قرار لما لا رجوع عنه أو ما يؤثر على الشركة أو تقنية جديدة بمراجعة مكتوبة قبل الكود، وتحتها ما يحمي النظام من مفاتيح الميزات والنشر التدريجي وخطة التراجع، وما يحمي الثقة من نفس المستويات للجميع وأولهم القائد والاعتراض في المراجعة لا في القناة العامة وصلاحيات تعود بعد ثلاثة قرارات جيدة](https://arabroot.io/content/images/2026/10/bad-technical-decisions-05-guardrails.webp) بدل أن تأخذ القرار منه، غير مستوى المراجعة حسب نوع القرار، وأعده له عندما يثبت المستويات في الشكل أعلاه مثال يمكن أن تعدله لفريقك: - **المستوى الأول L1، قرر وأخبر:** للقرارات التي يمكن التراجع عنها بسهولة وأثرها على الفريق فقط، ويكفيها رسالة في القناة. وهنا يبقى المهندس حراً تماماً حتى لو كانت قراراته الكبيرة تحت المراجعة، وهذا مهم لثقته بنفسه. - **المستوى الثاني L2، استشر أولاً:** للقرارات التي تراجعها مكلف، أو تؤثر على المنتج كله، ويكفيها رأي شخصين يعرفان الجزء المتأثر قبل التنفيذ، دون اجتماع رسمي. - **المستوى الثالث L3، مراجعة وسجل قرار:** لما لا رجوع عنه بسهولة، أو يؤثر على الشركة كلها، أو يدخل تقنية جديدة، ولا يبدأ فيه كود قبل سجل قرار مكتوب ومراجعة تصميم Design Review. والتقنية الجديدة ترفع المستوى درجة، مهما كان القرار صغيراً، لأنها تستهلك أحد رموز الابتكار القليلة. ولاحظ أن هذه المستويات تطبق على الفريق كله، وأولهم القائد، وإلا تحولت إلى عقاب مقنع لشخص واحد، وفهمها الجميع كذلك. وفوق المستويات، هناك وسائل تقنية تقلل ثمن القرار الخاطئ نفسه، وتجعل الأبواب باتجاه واحد أقرب للأبواب باتجاهين: مفاتيح الميزات Feature Flags التي تسمح بإطفاء تغيير دون نشر جديد، والنشر التدريجي Staged Rollout لنسبة صغيرة من المستخدمين أولاً، وخطة التراجع المكتوبة قبل أي تغيير في قاعدة البيانات، والتجربة المحدودة بوقت Time-boxed Spike قبل الالتزام بتقنية جديدة. وكل واحدة من هذه تحمي النظام من قرارات الجميع، وليس من مهندس واحد. وأخيراً، الحماية المؤقتة يجب أن يكون لها طريق للعودة. فإذا وضعت قرارات مهندس في مستوى أعلى من غيره لفترة، كما في الحالة الثانية، فقل له متى وكيف يعود للمستوى العادي، مثل ثلاثة قرارات كبيرة متتالية بسجل قرار جيد ومراجعة نجحت، أو ربع سنة دون أن يتكرر النمط. والحماية التي لا نهاية لها تتحول إلى حكم. ## التراجع عن قرار نفذ (Reversing a Decision) أصعب لحظة في هذا الموضوع عندما يكون القرار الخاطئ قد نفذ، وأشهر من العمل مبنية عليه، ويجب أن تتراجع عنه. وهنا خطآن شائعان: أن تتراجع عن كل شيء دفعة واحدة، فيخسر الفريق وقتاً آخر بنفس حجم ما خسره، أو أن تكمل في القرار الخاطئ لأن التراجع مكلف، وهذا ما يسمى أثر التكلفة الغارقة Sunk Cost. والطريق العملي بينهما أن تسأل لكل قرار سؤالاً واحداً: من اليوم، بغض النظر عما صرف، أيهما أرخص: أن نكمل أم أن نتراجع؟ والجواب يختلف لكل قرار، ففي قصتنا كان التراجع عن شبكة الخدمات رخيصاً لأنها كانت في التجربة، والتراجع عن MongoDB في الدفع ضرورياً لأن كل يوم يضيف بيانات غير متسقة، أما الخدمات التسع فدمجت تدريجياً على شهرين دون إيقاف الميزات. والطريقة التي تتراجع بها تحدد هل يبقى المهندس في الفريق. فالمراجعة يجب أن تكون بلا لوم Blameless، كما تشرح Google في [فصل ثقافة المراجعة بعد الحوادث](https://sre.google/sre-book/postmortem-culture/?ref=arabroot.io)، أي أن تركز على الأسباب والعملية التي سمحت بالقرار، وليس على من أخطأ، لأن الهدف منع التكرار. وفي حالتنا كانت العملية نفسها هي السبب الأكبر: صلاحية كاملة دون حدود ودون قيود مشروحة. واكتب التراجع كسجل قرار جديد يستبدل القديم، فيه أن القديم اتخذ بمعلومات وقته، وأن الجديد يعالج ما تعلمه الفريق. وإذا كان صاحب القرار القديم هو من يكتب الجديد، كما في الحالة الأولى، فهذا أفضل ما يمكن، لأنه يحول التراجع من هزيمة إلى تعلم يملكه هو. ## المحادثة مع صاحب القرارات (The Conversation) طريقة صياغة الملاحظة الصعبة نفسها، مثل صيغة الموقف والسلوك والأثر SBI، مشروحة في مقال الملاحظات الصعبة Feedback. وما يخص القرارات التقنية بالتحديد: - **تحدث عن الطريقة، لا عن الذوق:** «ما قارنا بديل ثاني لقاعدة بيانات الدفع» ملاحظة يمكن العمل عليها، أما «ما أحب MongoDB» فرأي يستطيع أن يرد عليه برأي. - **اعرض النمط في عدة قرارات:** قرار واحد خاطئ يحدث لأي مهندس، وثلاثة قرارات كبيرة دون بدائل نمط. - **اذكر القرارات الجيدة أيضاً:** في أغلب الحالات هناك قرارات صحيحة بين الخاطئة، وذكرها يجعل الملاحظة دقيقة وعادلة، ويجعله يثق في الباقي. - **اشرح القيود التي ربما لا يعرفها:** المال، والوقت، والفريق، وأولويات العمل، فكثير من القرارات السيئة قرارات جيدة لشركة أخرى. - **اسأله عن منطقه قبل أن تحكم:** «وش كانت المشكلة اللي تبغى تحلها بـ Kafka؟» قد تكتشف مشكلة حقيقية لم تعرفها، أو يكتشف هو أنها لم تكن موجودة. - **اتفق على العملية، لا على القرار وحده:** المستويات وسجل القرار ومتى تعود الصلاحيات، واكتبها في رسالة بعد اللقاء. وانتبه ألا تتحول المحادثة إلى مناظرة تقنية بينك وبينه. فإذا كان هو أعرف منك بالتقنية، وهذا يحدث كثيراً، فلا تحاول أن تفوز في النقاش التقني، وإنما ركز على ما تعرفه أنت جيداً: القيود، والأثر على الفريق والعملاء، وأن العملية لم تتبع. ## إذا كنت أنت المهندس (The Engineer's Side) قد تكون أنت المهندس الذي ترفض قراراته، أو تراجع أكثر من غيرك، أو سحبت منه صلاحية كان يملكها. والشعور الطبيعي أنك تعرف أكثر من الفريق، وأن الآخرين يقاومون التغيير، وقد يكون هذا صحيحاً أحياناً. ولكن الطريق لاستعادة الثقة واحد تقريباً في كل الحالات: - **اكتب قبل أن تقرر:** سجل قرار قصير لكل قرار كبير، فيه بديلان على الأقل، ومنهما «لا نفعل شيئاً الآن». هذا وحده يغير صورتك أمام الفريق خلال أسابيع. - **اسأل عن القيود:** «كم يكفي المال؟ ومن سيشغل هذا؟ وما الأهم هذا الربع؟» فالقرار الصحيح تقنياً قد يكون خاطئاً تجارياً. - **اقترح تجربة محدودة بدل التزام كامل:** «خلنا نجرب Kafka أسبوعين على خدمة وحدة، ونقيس، ونقرر» أسهل في القبول من «ننقل كل شي». - **اختلف ثم التزم:** إذا قرر الفريق ضد رأيك بعد نقاش حقيقي، فالتزم بالقرار ولا تنفذه بنصف قلب، واكتب اعتراضك في السجل حتى يعود إليه الفريق إذا ظهر أنك كنت على حق. - **اعترف بالقرار الخاطئ مبكراً:** المهندس الذي يقول «أظن قراري في الكاش كان خطأ، وهذا اقتراحي للتراجع» يكسب ثقة أكثر من الذي لا يخطئ أبداً، وهذا ما يقصده Bezos بأن تكون سريعاً في تصحيح القرارات الخاطئة. - **اطلب أن تعرف طريق العودة:** إذا وضعت قراراتك تحت مراجعة إضافية، فاسأل بهدوء: «وش اللي يخلي هالترتيب ينتهي؟» من حقك أن تعرف. وإذا كنت ترى أن الفريق كله يرفض أي تغيير، وأنك تتبع العملية وتكتب البدائل ومع ذلك يرفض كل شيء، فهذه مشكلة أخرى في البيئة، وقد يكون الحديث مع مدير مديرك أو تغيير الفريق هو الطريق، وعلامات الفريق المؤذي في مقالها المستقل. ## متى يصبح الأمر مشكلة أداء؟ (When It Becomes a Performance Issue) أغلب حالات القرارات السيئة تنتهي بالعملية: مستويات واضحة، وسجل قرار، ومراجعة، وشرح للقيود. ولكن بعضها يتحول إلى مشكلة أداء تحتاج إجراء رسمياً، وعلامات ذلك: - العملية واضحة ومكتوبة ومطبقة على الجميع، والمهندس يتجاوزها مرة بعد مرة، مثل أن ينفذ قرارات من المستوى الثالث دون سجل قرار أو مراجعة. وهنا المشكلة رغبة وليست مهارة. - قرار تجاوز العملية تسبب في ضرر كبير على العملاء أو على أمن النظام. - المهندس يرفض المراجعة نفسها، أو يعامل كل اعتراض كإهانة، رغم محادثات واضحة. وفي هذه الحالات يكون الطريق التالي خطة تحسين الأداء PIP، ولها مقال مستقل في هذه المرحلة، وقبلها تحدث مع مديرك ومع الموارد البشرية HR. ولكن قبل أن تصل لذلك، فكر في الحالة الثالثة: أحياناً يكون الحل أن يتغير الدور، فمهندس ممتاز في حل المشاكل الصعبة قد لا يكون الشخص المناسب لصلاحية القرار المعماري، وهذا ليس نقصاً فيه، وإنما ملاءمة بين الشخص والدور. و[دليل GitLab عن ضعف الأداء](https://handbook.gitlab.com/handbook/leadership/underperformance/?ref=arabroot.io) يفتح باب الدور الآخر داخل الشركة عندما تكون المشكلة عدم توافق في المهارات، وليس قلة التزام. ## أخطاء شائعة (Common Mistakes) - **الحكم من النتيجة:** لوم القرار الجيد الذي لم ينجح، ومكافأة القرار المتهور الذي نجح بالحظ. - **صلاحية كاملة دون قيود:** إعطاء «الكلمة الأخيرة» دون شرح المال والوقت والفريق، ثم المحاسبة على النتيجة. - **سحب كل الصلاحيات دفعة واحدة:** يحمي النظام لأسابيع، ويهدم الثقة، ويحول المدير إلى عنق زجاجة. - **مراجعة لكل شيء:** معاملة الأبواب باتجاهين كأنها باب باتجاه واحد، فيتوقف الفريق. - **قواعد لشخص واحد:** مستويات مراجعة تطبق عليه وحده، فتفهم كعقاب. - **التراجع عن كل شيء دفعة واحدة:** أو العكس، الإكمال في الخطأ بسبب ما صرف. - **مراجعة القرار القديم كمحاكمة:** فيتحول الدفاع عن القرار إلى دفاع عن النفس. - **مناظرة تقنية مع المهندس:** بدل التركيز على العملية والقيود والأثر. - **حماية مؤقتة بلا نهاية:** لا يعرف المهندس كيف يعود للمستوى العادي. ## الأداة: مستويات المراجعة وسجل القرار (Decision Review Tool) الأداة في هذا المقال جزءان في مجلد `lab/`. الأول قالب في ملف `lab/adr-and-review-template.md` فيه أسئلة تحديد مستوى القرار، وسجل القرار المعماري بأقسامه، وأسئلة مراجعة التصميم، وعبارات للمحادثة. والثاني سكربت Node صغير في ملف `lab/decision-review.mjs` لا يحتاج أي مكتبة، يقرأ قائمة قرارات الفريق في ملف JSON، ويحدد لكل قرار مستوى المراجعة الذي يحتاجه حسب قابلية التراجع ومدى الأثر Blast Radius وأيام العمل اللازمة للتراجع، ويعد التقنيات الجديدة مقابل عدد رموز الابتكار، وينبه على القرارات التي تحتاج سجل قرار ولم تكتب، أو التي قورن فيها أقل من بديلين. وفي المجلد ملف `lab/decisions-sample.json` فيه القرارات الثمانية للفريق في قصتنا كما كانت قبل المحادثة، وكل قرار بهذا الشكل: ```json { "id": "D4", "title": "MongoDB for payment transactions", "reversible": "no", "radius": "company", "undoDays": 45, "adr": false, "alternatives": 0, "newTech": true } ``` والقواعد في السكربت بسيطة ومكتوبة في أعلاه: القرار الذي يمكن التراجع عنه وأثره على الفريق في المستوى الأول، والتراجع الجزئي أو الأثر على المنتج في الثاني، وما لا رجوع عنه أو أثره على الشركة أو يحتاج أكثر من عشرين يوم عمل للتراجع في الثالث، والتقنية الجديدة ترفع المستوى درجة. وعندما نشغله: ```bash node decision-review.mjs decisions-sample.json ``` تكون النتيجة: ```text id level undo adr alts title D1 L3 design review + ADR 60d no 1 Split the order service into 9 microservices D2 L3 design review + ADR 25d no 1 Kafka as the message broker D3 L1 decide and inform 1d no 0 Rename internal API fields D4 L3 design review + ADR 45d no 0 MongoDB for payment transactions D5 L2 consult first 3d yes 2 Add a feature flag library D6 L3 design review + ADR 20d no 1 Service mesh for internal traffic D7 L2 consult first 10d yes 3 Move CI from Jenkins to GitLab CI D8 L2 consult first 2d no 2 Cache layer in front of the menu API innovation tokens used: 4 of 3 <-- over budget flags (8): D1: needs an ADR and a design review, none written D1: only 1 alternative(s) compared D2: needs an ADR and a design review, none written D2: only 1 alternative(s) compared D4: needs an ADR and a design review, none written D4: only 0 alternative(s) compared D6: needs an ADR and a design review, none written D6: only 1 alternative(s) compared ``` ولنقرأ النتيجة: - **الجدول:** أربعة قرارات من ثمانية في المستوى الثالث، وهي القرارات الأربعة الكبيرة في القصة: تقسيم الخدمات وKafka وMongoDB وشبكة الخدمات. وعمود `undo` يوضح السبب، فالتراجع عنها يحتاج من 20 إلى 60 يوم عمل. - **القرارات الأخرى:** إعادة تسمية الحقول D3 في المستوى الأول، ولا تحتاج شيئاً. ومكتبة مفاتيح الميزات D5 ونقل خط النشر D7 في المستوى الثاني، ولكل منهما سجل قرار وبديلان أو أكثر، وهذان قراران أخذا بطريقة جيدة حتى في نفس الفترة، وهذا يستحق أن يذكر في المحادثة. - **طبقة الكاش D8:** في المستوى الثاني لأن أثرها على المنتج، مع أن التراجع عنها يومان فقط، ودون سجل قرار، والسكربت لا ينبه عليها لأن المستوى الثاني لا يحتاج سجلاً، وإنما استشارة. - **رموز الابتكار:** أربع تقنيات جديدة في أربعة أشهر، والحد ثلاثة، وهذا الرقم وحده يشرح لماذا صار الفريق يقضي أسبوعه في البنية. - **التنبيهات:** ثمانية تنبيهات كلها على القرارات الأربعة الكبيرة: لا سجل قرار، وأقل من بديلين. وهذا هو النمط الذي تتحدث عنه مع المهندس: ليست الأدوات نفسها، وإنما غياب المقارنة والكتابة في القرارات التي لا رجوع عنها. وماذا يحدث بعد أن طبق الفريق المستويات وكتب المهندس سجلات القرار؟ في المجلد ملف `lab/decisions-after.json` فيه نفس القرارات بعد المراجعة، وعندما نشغل السكربت عليه: ```bash node decision-review.mjs decisions-after.json ``` ```text id level undo adr alts title D1 L2 consult first 15d yes 3 Modular monolith, split later by ADR D2 L2 consult first 5d yes 3 PostgreSQL queue table, Kafka later D3 L1 decide and inform 1d no 0 Rename internal API fields D4 L3 design review + ADR 45d yes 2 PostgreSQL for payment transactions D5 L2 consult first 3d yes 2 Add a feature flag library D6 L1 decide and inform 0d yes 2 Service mesh: postponed, revisit in Q3 D7 L2 consult first 10d yes 3 Move CI from Jenkins to GitLab CI D8 L2 consult first 2d no 2 Cache layer in front of the menu API innovation tokens used: 0 of 3 no flags ``` لاحظ أن قاعدة بيانات الدفع D4 بقيت في المستوى الثالث، لأنها ما زالت باباً باتجاه واحد مهما كان الاختيار، ولكنها الآن بسجل قرار وبديلين. وأن تقسيم الخدمات D1 نزل للمستوى الثاني لأن النظام الواحد المقسم داخلياً أسهل في التراجع، وأن شبكة الخدمات D6 صارت قراراً بالتأجيل مع موعد مراجعة، وهذا أيضاً قرار يستحق أن يكتب. ورموز الابتكار صارت صفراً، وهذا ليس هدفاً بذاته، وإنما يعني أن الشركة عندها الآن ثلاثة رموز تصرفها عندما تحتاجها فعلاً. وتنبيه مهم عن حدود الأداة: القواعد في السكربت تقدير بسيط وليست علماً، وعتبة العشرين يوماً وحد الثلاثة رموز أمثلة تعدلها لفريقك. والسكربت لا يعرف هل القرار جيد، وإنما يعرف هل أخذ بالطريقة التي يحتاجها حجمه. وهذا بالضبط ما تريده من أداة في محادثة صعبة: أن تتحدث عن الطريقة بأرقام يراها الطرفان، بدلاً من أن تتحدث عن ذوق أو عن شخص. ## قائمة تحقق (Checklist) | إذا لاحظت | افعل | | --------------------------------------- | ------------------------------------------------------------------------------- | | قرار فشل مرة واحدة | قيم طريقة اتخاذه، لا نتيجته، ومراجعة بلا لوم Blameless | | قرارات كبيرة دون بدائل ولا كتابة | سجل قرار ADR لكل قرار لا رجوع عنه، فيه بديلان على الأقل | | تقنيات جديدة كثيرة في وقت قصير | حد لرموز الابتكار Innovation Tokens، والتقنية الجديدة في المستوى الثالث | | مهندس جاء من شركة أكبر بكثير | اشرح القيود بالأرقام: المال والوقت والفريق والأولويات | | اختصارات محلية تضر فرقاً أخرى | مبادئ بنية Architecture Principles مكتوبة، وجلسة تصميم مؤقتة للتغييرات المشتركة | | قرار قديم صاحبه يرفض مراجعته | مراجعة مستقلة تبدأ بأن القرار كان صحيحاً بمعلومات وقته | | تريد سحب صلاحياته كلها | مستويات قرار للجميع بدلاً من ذلك، مع طريق واضح للعودة | | قرار خاطئ نفذ | لكل قرار: أيهما أرخص من اليوم، الإكمال أم التراجع؟ وسجل قرار جديد يستبدل القديم | | يتجاوز العملية المتفق عليها مرة بعد مرة | مشكلة رغبة: توقع مكتوب، ثم خطة تحسين الأداء PIP مع الموارد البشرية HR | | متخصص ممتاز يتعثر في دور القرار | فكر في تغيير الدور، مثل مهندس رئيسي Principal Engineer | ومقالات الموقع التالية تكمل هذا الموضوع، من الخلاف التقني إلى الملاحظات الصعبة واللوم بعد الأعطال: [![](https://arabroot.io/content/images/2026/10/workplace-conflict-cover-cover.webp)دليلالخلاف التقني Conflict: كيف تختلف دون أن تخسر زميلكما الفرق بين الخلاف على الحل والخلاف على الشخص، وكيف تنقل النقاش التقني من الآراء إلى قرار مكتوب يلتزم به الجميع.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AE%D9%84%D8%A7%D9%81-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A-conflict-%D9%83%D9%8A%D9%81-%D8%AA%D8%AE%D8%AA%D9%84%D9%81-%D8%AF%D9%88%D9%86-%D8%A7%D9%86-%D8%AA%D8%AE%D8%B3%D8%B1-%D8%B2%D9%85%D9%8A%D9%84%D9%83/)[![](https://arabroot.io/content/images/2026/10/difficult-feedback-cover-cover.webp)دليلكيف تعطي الملاحظات الصعبة Feedback وتتلقاهالماذا يخفض بعض الملاحظات الأداء بدلاً من أن يرفعه، وكيف تقول الملاحظة الصعبة بوضوح واهتمام وتتلقاها دون أن تدافع.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D8%B7%D9%8A-%D8%A7%D9%84%D9%85%D9%84%D8%A7%D8%AD%D8%B8%D8%A7%D8%AA-%D8%A7%D9%84%D8%B5%D8%B9%D8%A8%D8%A9-feedback-%D9%88%D8%AA%D8%AA%D9%84%D9%82%D8%A7%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/blamed-for-incident-cover-cover.webp)دليلاللوم بعد العطل Blame: حين يلومك الفريق على ما لم تسببهماذا تقول في الساعة الأولى بعد عطل نسب إليك، وكيف توثق الحقائق بخط زمني، ومتى تصعد اللوم المتكرر ومتى تغادر.](https://arabroot.io/articles/%D8%AD%D9%8A%D9%86-%D9%8A%D9%84%D9%88%D9%85%D9%83-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%B9%D9%84%D9%89-%D8%B9%D8%B7%D9%84-%D9%84%D9%85-%D8%AA%D8%B3%D8%A8%D8%A8%D9%87/)[![](https://arabroot.io/content/images/2026/10/psychological-safety-cover-cover.webp)دليلالأمان النفسي Psychological Safety: ما وجدته Googleما معنى الأمان النفسي كما عرفته Edmondson، ولماذا كان أهم عامل في فعالية فرق Google، وكيف تقيسه في فريقك وتبنيه بسلوك يومي.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D9%85%D8%A7%D9%86-%D8%A7%D9%84%D9%86%D9%81%D8%B3%D9%8A-psychological-safety-%D9%85%D8%A7-%D9%88%D8%AC%D8%AF%D8%AA%D9%87-google-%D9%81%D9%8A-project-aristotle/)[![](https://arabroot.io/content/images/2026/10/code-quality-cover-cover.webp)دليلما هي جودة الكود Code Quality وكيف تقيسها؟ما الذي يجعل الكود سهل التغيير، وماذا تقيس أدوات الفحص فعلاً، ولماذا يحتاج كود الوكلاء الأذكياء إلى بوابة جودة.](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%AC%D9%88%D8%AF%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-code-quality-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D8%B3%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/dev-evaluation-cover-cover.webp)دليلكيف تقيم أداء المطورين Developer Performance دون قياس الأشياء الخطأ؟ماذا تقيس في أداء المطور والفريق، ولماذا تضلل أرقام مثل عدد الأسطر وطلبات الدمج، وكيف تقلل تحيز من يقيم.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D9%85-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%A7%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-%D8%AF%D9%88%D9%86-%D9%82%D9%8A%D8%A7%D8%B3-%D8%A7%D9%84%D8%A7%D8%B4%D9%8A%D8%A7%D8%A1-%D8%A7%D9%84%D8%AE%D8%B7%D8%A7/)[![](https://arabroot.io/content/images/2026/10/new-manager-old-team-cover-cover.webp)دليلمدير جديد يأتي بفريقه القديم: سحب المسؤوليات Quiet Firingكيف تفرق بين إعادة تنظيم مشروعة وسحب مسؤولياتك تدريجياً حتى تغادر، وماذا توثق وتقول، وما يقوله نظام العمل السعودي قبل أن تقرر.](https://arabroot.io/articles/%D9%85%D8%AF%D9%8A%D8%B1-%D8%AC%D8%AF%D9%8A%D8%AF-%D9%8A%D8%A7%D8%AA%D9%8A-%D8%A8%D9%81%D8%B1%D9%8A%D9%82%D9%87-%D8%A7%D9%84%D9%82%D8%AF%D9%8A%D9%85-quiet-firing/)[![](https://arabroot.io/content/images/2026/10/toxic-team-signs-cover-cover.webp)دليلعلامات الفريق المؤذي Toxic Team: كيف تميزه وماذا تفعلكيف تفرق بين فريق مرهق في فترة صعبة وفريق مؤذ فعلاً، وما الذي تفعله كعضو أو قائد، ومتى تصعد ومتى تحمي نفسك وتغادر.](https://arabroot.io/articles/%D8%B9%D9%84%D8%A7%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D9%85%D8%B1%D9%87%D9%82-%D8%A7%D9%88-%D8%A7%D9%84%D9%85%D8%A4%D8%B0%D9%8A-toxic-team-%D9%88%D9%85%D8%A7%D8%B0%D8%A7-%D8%AA%D9%81%D8%B9%D9%84/) ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - القرار السيئ يقاس بطريقة اتخاذه وليس بنتيجته وحدها، والمهندس الذي قراراته سيئة هو من يتكرر عنده نفس الخلل في الطريقة. - الأنماط المتكررة معروفة: تقنية للسيرة الذاتية، وتصميم لحجم غير موجود، واختصارات محلية، وقرارات صامتة، ورفض المراجعة بعد الدليل، والشلل في القرار. - القرارات السيئة تنمو غالباً في فراغ: صلاحية دون قيود مشروحة، ولا عملية مكتوبة، فابدأ بالبيئة قبل الشخص. - فرق بين الأبواب باتجاهين والأبواب باتجاه واحد، وضع المراجعة حيث يكون الخطأ مكلفاً فقط، واجعل المستويات للجميع. - سجل القرار المعماري ADR يحمي النظام ويحمي الثقة، لأن الاعتراض يصبح على وثيقة فيها بدائل ونتائج، والقرار القديم يستبدل ولا يمحى. - احم النظام بمستويات مراجعة ومفاتيح ميزات ونشر تدريجي، ولا تسحب كل الصلاحيات، واجعل للحماية المؤقتة طريق عودة. - في الحالات الثلاث تحسن الوضع: مهندس أول فهم القيود فصار أفضل من يكتب سجلات القرار، ومهندس سريع فهم النظام ككل، ومتخصص ممتاز وجد الدور الذي يناسبه. ## سجل التحديثات - أكتوبر 2026: كتابة المقال، والتحقق من مقال Michael Nygard عن سجل القرار المعماري لعام 2011، ومربع الدين التقني عند Martin Fowler، ورسالة Jeff Bezos للمساهمين لعام 2016، ومقال Choose Boring Technology لـ Dan McKinley، وفصل ثقافة المراجعة بعد الحوادث في كتاب Google SRE، وتشغيل سكربت الأداة على قائمتي القرارات قبل المراجعة وبعدها، بتاريخ 31 أكتوبر 2026.