مواءمة أصحاب المصلحة Stakeholders وسياسة المؤسسة

كتب مهندس في فريق المنصة اقتراحاً لنقل خطوط CI/CD في الشركة من Jenkins إلى Gitea Actions، وكان الاقتراح صحيحاً تقنياً: سيرفر Jenkins قديم ويحتاج صيانة مستمرة، وإضافاته Plugins تتعطل مع كل تحديث، والكود موجود أصلاً في Gitea. وعرض الاقتراح في اجتماع الإدارة التقنية الشهري، فاعترض مسؤول الأمن لأن أحداً لم يسأله عن الأسرار Secrets، وقال قائد فريق الجوال إن لديه إطلاقاً بعد ثلاثة أسابيع ولن يغير شيئاً قبله، وسأل المدير المالي عن تكلفة السيرفرات الجديدة ولم يجد أحد الرقم، فانتهى الاجتماع بعبارة «نعود لها في الربع القادم». والاقتراح لم يفشل لأنه خاطئ، وإنما لأن الناس الذين يملكون القرار سمعوا به لأول مرة في الاجتماع.

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

وسوف نناقش في هذا المقال ما يلي:

• ماذا تعني سياسة المؤسسة للمهندس، ولماذا هي انتقال للمعلومات وليست تلاعباً.
• خريطة أصحاب المصلحة Stakeholders حسب التأثير والاهتمام.
• مصفوفة RACI وأخطاؤها الشائعة.
• وثيقة التصميم Design Doc وطلب التعليقات RFC كأداة لمواءمة الناس، وليس للتوثيق فقط.
• التمهيد للقرار قبل الاجتماع Pre-wiring، ومبدأ «اختلف ثم التزم» Disagree and Commit.
• كيف تقول لا مع خيارات، وكيف تكتب للإدارة العليا بطريقة BLUF.
• التصعيد Escalation دون أن تحرق العلاقة، والإدارة نحو الأعلى Managing Up.
• مثال كامل لاقتراح الانتقال من Jenkins إلى Gitea Actions، مع قالب RFC مكتوب ومصفوفة RACI وقائمة تحقق.

سياسة المؤسسة Office Politics: انتقال المعلومات وليس التلاعب

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

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

خريطة أصحاب المصلحة Stakeholders

صاحب المصلحة Stakeholder هو أي شخص أو فريق يتأثر بالقرار أو يستطيع أن يؤثر فيه، والخطأ الأول أن تكتفي بمن تعرفهم أو بمن في فريقك. والطريقة البسيطة لرسم الخريطة أن تكتب كل الأسماء ثم تضع كل اسم على محورين: قدرته على التأثير في القرار Power، ومدى اهتمامه به Interest، فتحصل على أربع مجموعات، ولكل مجموعة طريقة تعامل مختلفة:

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

والجدول التالي خريطة مثالنا كاملة، ولاحظ عمود «ما يهمه»، فهو أهم من موقعه على الخريطة، لأنه يخبرك ماذا تكتب له:

مصفوفة RACI وأخطاؤها

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

• المنفذ Responsible: من يقوم بالعمل فعلاً، ويمكن أن يكون أكثر من شخص.
• صاحب القرار Accountable: من يملك القرار النهائي ويحاسب على النتيجة، وهو شخص واحد فقط في كل صف.
• المستشار Consulted: من يجب أن يسأل قبل القرار ويؤخذ رأيه، فالتواصل معه في الاتجاهين.
• المطلع Informed: من يجب أن يعرف بعد القرار، فالتواصل معه في اتجاه واحد.

والجدول التالي مصفوفة مثالنا، ولاحظ أنها للقرارات والمراحل المهمة فقط، وليست لكل مهمة صغيرة:

والمصفوفة سهلة الكتابة، ولكنها تفشل بطرق متكررة:

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

وثيقة التصميم وRFC: أداة لمواءمة الناس

وثيقة التصميم Design Doc، أو طلب التعليقات Request for Comments واختصاراً RFC، وثيقة تكتبها قبل التنفيذ تشرح المشكلة والحل المقترح والبدائل والمخاطر، وترسلها للأشخاص المعنيين ليعلقوا عليها كتابة. والفرق بينها وبين سجل القرار ADR الذي شرحناه في توثيق المعمارية: مخططات C4 وسجل القرار ADR أن الوثيقة تأتي قبل القرار وهدفها جمع الآراء، والسجل يأتي بعد القرار وهدفه حفظ ما قررناه ولماذا، وغالباً تنتهي الوثيقة بسجل قرار قصير.

وقد يتساءل البعض: لماذا وثيقة مكتوبة وليس عرضاً تقديمياً في اجتماع؟ والإجابة أن الكتابة تجبرك على أن تفكر في الحجة كاملة، والعرض يسمح لك بأن تقفز بين النقاط، وأن الوثيقة المكتوبة يقرؤها مسؤول الأمن في وقته ويكتب اعتراضه بدقة، بدلاً من أن يرفع يده في الدقيقة الأخيرة من الاجتماع. وفي رسالته لمساهمي Amazon عن سنة 2017 كتب Jeff Bezos أن Amazon لا تستخدم العروض التقديمية في اجتماعاتها، وإنما تكتب مذكرات سردية من ست صفحات Six-page Memos يقرؤها الحاضرون بصمت في بداية الاجتماع، ثم يبدأ النقاش. وفي المشاريع مفتوحة المصدر الكبيرة نفس الفكرة بأسماء مختلفة، مثل مقترحات تحسين Python المعروفة بالاسم PEP وطلبات RFC في لغة Rust ومقترحات التحسين في Kubernetes، وفي كلها التغيير الكبير يبدأ بوثيقة مكتوبة يعلق عليها المجتمع قبل أن يكتب الكود.

قالب RFC مكتوب لمثالنا

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

ولاحظ أن الأسئلة المفتوحة مكتوبة صراحة، والسبب أن الوثيقة التي تبدو كاملة تجعل القارئ يبحث عن الثغرة ليثبت أنه قرأها، أما الوثيقة التي تقول «هذا ما لا نعرفه بعد» فتجعله يساعدك في الإجابة. وقد شرحنا إعداد Gitea Actions نفسه في Gitea Actions: تشغيل CI/CD على خادمك.

التمهيد قبل الاجتماع Pre-wiring

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

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

اختلف ثم التزم Disagree and Commit

في رسالته لمساهمي Amazon عن سنة 2016 نصح Jeff Bezos باستخدام عبارة «اختلف ثم التزم» Disagree and Commit، وشرح أنك إذا كنت مقتنعاً باتجاه ما مع غياب الإجماع، تستطيع أن تقول لزملائك إنك تعرف أنهم يختلفون معك، ثم تسألهم هل يراهنون معك عليه، ولاحظ أنه قال إنها تعمل في الاتجاهين، وإن المدير أيضاً يجب أن يلتزم بقرار فريقه وهو يختلف معه، وذكر مثالاً فعل فيه ذلك بنفسه.

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

كيف تقول لا Say No مع خيارات

يطلب منك مدير التقنية أن ينتهي الانتقال خلال شهر واحد بدلاً من ربع سنة، لأن عقد صيانة سيرفر Jenkins ينتهي قريباً. والإجابة البسيطة «لا، مستحيل» تجعلك تبدو كمن يعطل العمل، والإجابة «نعم» تجعلك تعد بشيء لن يحدث. والحل الأفضل أن تحول «لا» إلى خيارات، لكل خيار ثمن واضح، ويختار صاحب القرار بينها، وهذا ما نسميه عرض الموازنة Trade-off Framing:

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

الكتابة للإدارة العليا بطريقة BLUF

طريقة BLUF اختصار للعبارة Bottom Line Up Front، وتعني أن تضع الخلاصة أو الطلب في أول سطر، ثم الأسباب والتفاصيل بعده، والسبب أن المدير الذي يقرأ خمسين رسالة في اليوم يقرأ السطر الأول وقد لا يكمل، فإذا كان السطر الأول قصة عن تاريخ Jenkins فلن يصل إلى طلبك أبداً. والمثال التالي يبين الفرق بين رسالتين بنفس المعلومات:

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

التصعيد Escalation دون أن تحرق العلاقة

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

1. اتفق مع زميلك أنكما مختلفان، وأن الخلاف يحتاج قراراً من شخص أعلى، وأنكما سوف تصعدانه معاً.
2. اكتبا الخلاف في رسالة واحدة، فيها رأي كل منكما بعدل، وما يكسبه وما يخسره كل خيار، وكأن كل واحد منكما يكتب رأي الآخر.
3. حددا ما تحتاجانه بالضبط: قرار بين خيارين، أو أولوية بين مشروعين، أو موارد إضافية.
4. بعد القرار، طبقا مبدأ «اختلف ثم التزم» كما ذكرنا أعلاه.

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

الإدارة نحو الأعلى Managing Up

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

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

قائمة تحقق قبل أن تعرض اقتراحاً كبيراً

• هل كتبت خريطة أصحاب المصلحة، ومعها ما يهم كل واحد منهم؟
• هل جلست مع كل من في مربع التأثير العالي والاهتمام العالي قبل الاجتماع؟
• هل الوثيقة مكتوبة، وفي أولها ملخص بطريقة BLUF فيه الطلب والموعد والتكلفة؟
• هل فيها البدائل وسبب رفضها، والمخاطر وطريقة التراجع، والأسئلة المفتوحة؟
• هل في مصفوفة RACI صاحب قرار واحد لكل قرار، ويملك فعلاً صلاحيته؟
• هل أرسلت الوثيقة قبل الاجتماع بوقت كاف، مع موعد واضح لانتهاء التعليقات؟
• إذا رفض جزء من الاقتراح، هل لديك خيارات بديلة بثمن واضح؟
• بعد القرار، هل كتبت سجل القرار وأبلغت كل من في عمود المطلعين؟

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

دليلتوثيق المعمارية: مخططات C4 وسجلات القرارات المعمارية ADRكيف ترسم نظامك بمخططات C4 يفهمها المطور الجديد، وتحفظ سبب كل قرار مهم في سجل ADR داخل المستودع.دليلهندسة المتطلبات Requirements Engineering من الطلب إلى ما يبنىما هو المتطلب Requirement، وكيف تجمعه وتكتبه وتراجعه وتدير تغييره، ولماذا تفشل مشاريع كبيرة عندما تهمل هذه الخطوة.دليلإدارة المنتج: ماذا يفعل مدير المنتج Product Manager؟الفرق بين مدير المنتج ومدير المشروع ومالك المنتج Product Owner، وكيف يختار مدير المنتج ما يبنى ويرتب أولوياته ويقيس نتيجته.دليلهل يسلم الفريق الأكبر أسرع؟ قانون Brooks والذكاء الاصطناعيماذا تقول الدراسات عن حجم فريق البرمجة وسرعة التسليم، ومتى تفيد إضافة الأشخاص، وما الذي يغيره الذكاء الاصطناعي فعلاً.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

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

سجل التحديثات

• أكتوبر 2026: كتابة المقال، والتحقق من نصوص رسائل Amazon لمساهميها عن سنتي 2016 و2017 من مصادرها الرسمية بتاريخ 13 أكتوبر 2026.
• أكتوبر 2026: إضافة المصطلحات الإنجليزية إلى العنوان والعناوين الفرعية.