> ## 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.

# مديرك لا يفهم عملك التقني: كيف تشرح الأثر Business Impact
- URL: https://arabroot.io/articles/مديرك-لا-يفهم-عملك-التقني-كيف-تشرح-الاثر/
- Published: 2026-10-31T07:49:58.000Z
- Updated: 2026-10-31T10:14:20.000Z
- Description: كيف تترجم طلبك التقني إلى أثر يقرر به مديرك، وتتفاوض على التقديرات والدين التقني بخيارات واضحة بدل الصدام.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, المهارات المهنية للتقنيين

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

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

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

- لماذا لا يفهم المدير عملك، وما فجوة اللغة Translation Gap بين المهندس والإدارة.
- سلم الترجمة من الحقيقة التقنية إلى الأثر على العمل Business Impact.
- ثلاث حالات توضيحية: إعادة هيكلة Refactoring رفضت، وتقدير Estimate لم يصدقه المدير، ومدير يريد تقنية رائجة Hype.
- في كل حالة: ماذا يحدث عادة، وما يزيدها سوءاً، وما ينجح، وعبارات تقولها، وكيف توثق، ومتى تصعد، ومتى تغادر.
- متى يكون المدير على حق وتكون أنت جزءاً من المشكلة.
- الأداة العملية: ورقة الترجمة من صفحة واحدة One-Page Translation Sheet، وقائمة تحقق قبل أي طلب.

## لماذا لا يفهم المدير عملك؟ فجوة اللغة Translation Gap

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

والأمر الثاني أن كثيراً من المديرين في الشركات التقنية لم يختاروا الإدارة لأنهم يملكون مهاراتها، وإنما لأنهم كانوا جيدين في عمل آخر، وقد قدرت Gallup في [بحثها عن ندرة المديرين الجيدين](https://www.gallup.com/workplace/231593/why-great-managers-rare.aspx?ref=arabroot.io) أن شخصاً واحداً تقريباً من كل عشرة يملك الموهبة الطبيعية للإدارة، وأن المدير مسؤول عن 70% على الأقل من التباين في درجات تفاعل الموظفين Engagement بين الوحدات المختلفة. وهذا الرقم يقول شيئين في نفس الوقت: أن المدير يؤثر عليك أكثر مما تظن، وأن احتمال أن يكون مديرك متوسطاً في التواصل احتمال كبير، فلا تنتظر أن يأتي هو إلى لغتك، وإنما اذهب أنت إلى لغته، والسبب أنك الطرف الذي يملك المعلومة التقنية، ومن يملك المعلومة هو من يستطيع ترجمتها.

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

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

## سلم الترجمة إلى الأثر Business Impact

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

![سلم من أربع درجات يصعد من اليمين إلى اليسار: الدرجة الأولى الحقيقة التقنية مثل أن خدمة الدفع مكتوبة في ملف واحد من ثمانية آلاف سطر دون اختبارات، والثانية الأثر على النظام مثل أن كل تعديل فيها يأخذ ثلاثة أيام ويسبب عطلاً كل شهر، والثالثة الأثر على العمل مثل تأخر ميزات الدفع وتوقف المبيعات ساعتين في كل عطل، والرابعة الرقم والطلب مثل أسبوعان الآن يوفران يومين في كل ميزة قادمة، وتحت السلم سؤال وماذا يعني ذلك بين كل درجتين](https://arabroot.io/content/images/2026/10/manager-doesnt-understand-01-translation-ladder-1.webp)

كل درجة تجيب عن سؤال «وماذا يعني ذلك؟»، والمدير يقرر عند الدرجة الأخيرة

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

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

ومن أين تأتي بالأرقام؟ من الأماكن التي تملكها أصلاً: سجل التذاكر ومدة كل تذكرة في هذا الجزء من الكود، وعدد الحوادث Incidents المرتبطة به في سجل الحوادث، وعدد مرات التراجع Rollback عن إطلاقات لمسته، والوقت الذي قضاه الفريق في الدعم بسببه. وهناك أرقام عامة تستطيع أن تستشهد بها لتبين أن المشكلة ليست خاصة بفريقك، مثل تقرير Stripe المسمى [The Developer Coefficient](https://stripe.com/files/reports/the-developer-coefficient.pdf?ref=arabroot.io) الصادر في 2018، والذي وجد في استطلاعه أن المطور يقضي في المتوسط 17.3 ساعة في الأسبوع على الصيانة، أي التعامل مع الكود السيئ والأخطاء والتعديل وإعادة الهيكلة، منها 13.5 ساعة على الدين التقني. ولكن تذكر أن الرقم العام يفتح الباب فقط، والقرار يأتي من رقمك أنت، لأن المدير يقرر على فريقه وليس على متوسط عالمي.

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

## الحالة الأولى: إعادة الهيكلة Refactoring التي رفضت

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

### ماذا يحدث عادة؟ What Usually Happens

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

### ما الذي يزيدها سوءاً؟ What Makes It Worse

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

### ما الذي ينجح؟ What Works

الطريقة التي تنجح غالباً أن تحول الطلب من «توقف لنصلح» إلى «استثمار صغير بعائد واضح»، وأن تقدمه مع خيارات وليس طلباً واحداً، وأن تربطه بشيء مخطط أصلاً في خارطة الطريق Roadmap، فإذا كانت هناك ميزة خصومات مخططة في الشهر القادم وتمر بوحدة الفوترة، فهذه هي فرصتك، لأن إعادة الهيكلة تصبح جزءاً من تسليم الميزة وليست بديلاً عنها. وقد شبه Ward Cunningham الكود الذي يكتب بسرعة دون أن يعاد ترتيبه بالدين، في [شرحه لاستعارة الدين](https://wiki.c2.com/?WardExplainsDebtMetaphor&ref=arabroot.io)، حيث تأخذ وقتاً اليوم وتدفع فائدته في كل تعديل لاحق، وهذه الاستعارة مفيدة مع المدير لأنها من لغته: كل تعديل في وحدة الفوترة يدفع فائدة، والسؤال ليس هل نسدد الدين، وإنما متى وكم نسدد في كل مرة.

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

![مقارنة بين رسالتين: على اليمين قبل الترجمة رسالة تطلب سبرنتاً كاملاً لأن الكود سيئ وصعب الصيانة ونتيجتها رد سوف نعود لها لاحقاً، وعلى اليسار بعد الترجمة رسالة تذكر أن آخر ثلاث ميزات فوترة أخذت ضعف تقديرها وأن عطلين في الربع الماضي جاءا من نفس الوحدة، وتقترح ثلاثة خيارات: إعادة هيكلة جزئية مع ميزة الخصومات بثلاثة أيام إضافية، أو عشرين في المئة من كل سبرنت، أو تأجيل مع قبول المخاطرة، ونتيجتها موافقة على الخيار الأول](https://arabroot.io/content/images/2026/10/manager-doesnt-understand-02-refactor-before-after-1.webp)

نفس المهندسة ونفس الكود، والفرق في لغة الطلب وحجمه

### عبارات تقولها أو تكتبها Sample Sentences

هذه عبارات تستطيع أن تستخدمها كما هي أو تعدلها لتناسب أسلوبك، والمهم فيها أنها تبدأ من الأثر وتنتهي بطلب محدد:

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

> «لا أطلب إيقاف الميزات. عندي ثلاثة خيارات، ولكل خيار ثمنه، وأحتاج قرارك في أيها نختار.»

> «إذا قررنا التأجيل فأنا موافقة، ولكن أريد أن نكتب أن المخاطرة معروفة، وأن نعيد النظر فيها بعد ميزة الخصومات.»

ولاحظ في العبارة الأخيرة أنها تقبل قرار المدير ولا تعانده، ولكنها تحول القرار من «تجاهل» إلى «قبول مخاطرة معروفة بموعد مراجعة»، وهذا فرق كبير، لأن القرار المكتوب بموعد مراجعة يعود إلى الطاولة وحده، أما الرفض الشفهي فينسى.

### كيف توثق؟ Documenting

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

```text
الموضوع: ملخص اجتماع اليوم عن وحدة الفوترة

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

إذا فاتني شيء صححني.
```

### متى تصعد ولمن؟ When to Escalate

الدين التقني في الغالب لا يحتاج تصعيداً، لأنه قرار أولويات من صلاحية المدير، وحتى لو اختلفت معه فهو صاحب القرار. والاستثناء الوحيد أن يتحول الدين إلى مخاطرة لا يملك المدير صلاحية قبولها، مثل ثغرة أمنية معروفة في مكون منتهي الدعم End of Life، أو مخالفة لمتطلب نظامي Compliance أو تعاقدي، أو خطر على بيانات العملاء، وفي هذه الحالات يصبح الموضوع من صلاحية من يملك قبول المخاطرة، مثل مسؤول الأمن Security Officer أو مدير التقنية CTO، والطريقة الصحيحة لذلك نشرحها في مقال تجاوز المدير والتصعيد Skip-level في نفس المرحلة، وأهم قاعدة فيها أن تخبر مديرك قبل أن تصعد.

### ومتى يكون الحل أن تغادر؟ When to Leave

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

## الحالة الثانية: لماذا ثلاثة أسابيع؟ التقدير Estimate تحت الضغط

لنفرض حالة ثانية في فريق تطبيق جوال في شركة توصيل، حيث طلب مدير المنتج Product Manager ميزة تتبع الطلب على الخريطة، فقدر مهندس الفريق الميزة بثلاثة أسابيع، فرد المدير: «ثلاثة أسابيع لخريطة؟ هذه شاشة واحدة، Google Maps فيها كل شيء جاهز»، وطلب أن تسلم في أسبوع لأن هناك حملة تسويقية مخططة. والمهندس يعرف أن الخريطة نفسها سهلة، ولكن الصعب هو تحديث موقع المندوب كل ثوان دون أن تستهلك البطارية، وحالات انقطاع الشبكة، والخصوصية، وتعديلات الخادم Server.

### ماذا يحدث عادة؟ What Usually Happens

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

### ما الذي يزيدها سوءاً؟ What Makes It Worse

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

### ما الذي ينجح؟ What Works

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

والصورة التالية تبين كيف تعرض نفس الميزة كخيارات بدل رقم واحد، ولكل خيار ما يحصل عليه العميل وما يكلفه الفريق وما المخاطرة فيه:

![ثلاث بطاقات خيارات لميزة تتبع الطلب: الخيار أ في أسبوع واحد يعرض حالة الطلب والوقت المتوقع نصاً دون خريطة ومخاطرته قليلة، والخيار ب في أسبوعين يعرض خريطة يتحدث موقعها كل دقيقة دون معالجة انقطاع الشبكة ومخاطرته متوسطة، والخيار ج في ثلاثة أسابيع يعرض خريطة حية كل خمس ثوان مع معالجة البطارية والانقطاع والخصوصية ومخاطرته قليلة، وتحتها سؤال للمدير أي خيار يخدم الحملة](https://arabroot.io/content/images/2026/10/manager-doesnt-understand-03-estimate-options.webp)

الرقم وحده يدعو للتفاوض عليه، والخيارات تدعو لاختيار أحدها

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

### عبارات تقولها أو تكتبها Sample Sentences

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

> «ما الذي تحتاجه الحملة بالضبط؟ إذا كان المطلوب أن يعرف العميل أين طلبه، فنستطيع أن نسلم في أسبوع نسخة تعرض الحالة والوقت المتوقع، والخريطة الحية تأتي بعدها.»

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

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

### كيف توثق؟ Documenting

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

### متى تصعد؟ ومتى تغادر؟ Escalate or Leave

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

## الحالة الثالثة: مدير يريد تقنية رائجة Hype وأنت لست على حق تماماً

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

### ماذا يحدث عادة؟ What Usually Happens

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

### ما الذي يزيدها سوءاً؟ What Makes It Worse

- **الرفض قبل السؤال:** القائد لم يسأل ما المشكلة التي يريد المدير حلها، فقد يكون السبب أن طابور الدعم Support Queue طويل وأن العملاء يشتكون من وقت الانتظار، وهذه مشكلة حقيقية.
- **التعالي التقني:** «أنت لا تفهم كيف تعمل النماذج» قد تكون صحيحة، ولكنها تغلق النقاش وتجعل المدير يدافع عن كرامته بدل فكرته.
- **المبالغة في المخاطر:** صحيح أن النماذج قد تعطي إجابات خاطئة بثقة، ولكن هناك طرق معروفة لتقليل ذلك، مثل حصر الإجابات في قاعدة معرفة Knowledge Base الشركة وتحويل الأسئلة الحساسة لموظف.

### ما الذي ينجح؟ What Works

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

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

### عبارات تقولها أو تكتبها Sample Sentences

> «قبل أن نتكلم عن الحل، ما المشكلة التي نريد أن نحلها؟ هل هي وقت الانتظار، أم عدد التذاكر، أم تكلفة فريق الدعم؟»

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

> «إذا نجحت التجربة فأنا أول من يدعم التوسع. وإذا لم تنجح، نكون عرفنا ذلك بتكلفة أسبوعين وليس ربعاً كاملاً.»

### كيف توثق؟ ومتى تصعد؟ Document and Escalate

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

## متى يكون المدير على حق؟ When the Manager Is Right

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

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

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

## ماذا تفعل بعد الرفض؟ After a No

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

![شجرة قرار تبدأ من رفض المدير لطلبك: السؤال الأول هل كان الطلب مترجماً إلى أثر ورقم، فإذا لا فأعد صياغته بسلم الترجمة واطلب مرة أخرى، وإذا نعم فالسؤال الثاني هل فيه خطر لا يملك المدير قبوله مثل الأمن أو النظام أو بيانات العملاء، فإذا نعم فصعد لمن يملك قبول المخاطرة بعد إخبار مديرك، وإذا لا فالسؤال الثالث هل تكرر الرفض لكل طلب لأكثر من سنة رغم الأرقام، فإذا لا فاقبل القرار ووثقه بموعد مراجعة، وإذا نعم ففكر في الانتقال داخلياً أو المغادرة](https://arabroot.io/content/images/2026/10/manager-doesnt-understand-04-after-no-tree-1.webp)

أغلب حالات الرفض تنتهي عند الفرع الأول أو الثالث، والتصعيد والمغادرة استثناء

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

وفي فرع «اقبل القرار ووثقه» هناك مهارة يحتاجها المهندس الجيد كثيراً، وهي أن تختلف ثم تلتزم Disagree and Commit، أي أن تقول رأيك بوضوح قبل القرار، ثم بعد القرار تعمل عليه كأنه قرارك، دون أن تقلل منه أمام الفريق أو تنتظر فشله. وهذا لا يعني أن تنسى رأيك، وإنما أن تتركه في سجل القرار بموعد مراجعة، وتعود له بالأرقام عندما يحين الموعد. وشرحنا هذا المبدأ بتفصيل أكثر في مقال [مواءمة أصحاب المصلحة Stakeholders](https://arabroot.io/articles/%D9%85%D9%88%D8%A7%D8%A1%D9%85%D8%A9-%D8%A7%D8%B5%D8%AD%D8%A7%D8%A8-%D8%A7%D9%84%D9%85%D8%B5%D9%84%D8%AD%D8%A9-%D9%88%D8%B3%D9%8A%D8%A7%D8%B3%D8%A9-%D8%A7%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A9/).

## الأداة العملية: ورقة الترجمة One-Page Translation Sheet

هذه الورقة تكتبها قبل أي طلب مهم لمديرك، سواء كان وقتاً للدين التقني أو تغييراً في تقدير أو اعتراضاً على فكرة، ولا ترسلها كما هي بالضرورة، وإنما تستخدمها لترتب أفكارك قبل الاجتماع، ثم تنقل منها ما تحتاجه إلى رسالتك أو كلامك. وهي محفوظة في مجلد المقال باسم `lab/translation-sheet.md`، والصورة التالية تبين أقسامها:

![ورقة من ستة أقسام مرقمة: الطلب في سطر واحد، والحقيقة التقنية، والأثر على النظام بالأرقام، والأثر على العمل والعميل، والخيارات الثلاثة مع ثمن كل خيار بما فيها خيار عدم فعل شيء، وما أحتاجه من المدير وموعد المراجعة، وبجانبها ملاحظة أن الورقة كلها يجب أن تقرأ في دقيقتين](https://arabroot.io/content/images/2026/10/manager-doesnt-understand-05-translation-sheet-1.webp)

إذا لم تستطع أن تملأ قسم الأثر برقم حقيقي، فالطلب يحتاج بحثاً قبل أن يطلب

```markdown
# ورقة الترجمة: طلب لمديري

## 1. الطلب في سطر واحد
(ماذا أريد، ومتى، وكم يكلف)
مثال: 3 أيام إضافية مع ميزة الخصومات لإعادة ترتيب جزء حساب الفاتورة.

## 2. الحقيقة التقنية (لنفسي أولاً)
(ما الذي أراه في الكود أو النظام، بجملتين)

## 3. الأثر على النظام والفريق (بأرقام من السجلات)
- مدة آخر 3 تذاكر في هذا الجزء: ___ مقابل التقدير ___
- عدد الحوادث المرتبطة به في آخر ربع: ___
- مرات التراجع عن الإطلاق: ___
- ساعات الدعم بسببه: ___

## 4. الأثر على العمل والعميل
(ماذا يرى العميل، أو ماذا يتأخر، أو ما المخاطرة: إيراد، أمن، التزام تعاقدي)

## 5. الخيارات وثمن كل خيار
| الخيار | ما نحصل عليه | ما يكلفه | المخاطرة |
|---|---|---|---|
| أ (أصغر خطوة) | | | |
| ب | | | |
| ج: لا نفعل شيئاً الآن | | لا شيء اليوم | ___ |

## 6. ما أحتاجه من المدير
- القرار المطلوب: ___
- موعد المراجعة إذا أجلنا: ___
- ما يعرفه المدير ولا أعرفه (أسأله): ___

## قبل الإرسال
- [ ] هل الطلب في أول سطر؟
- [ ] هل في القسم 3 رقم حقيقي واحد على الأقل؟
- [ ] هل يوجد خيار "لا نفعل شيئاً" وثمنه؟
- [ ] هل حذفت كل حكم على من كتب الكود؟
- [ ] هل تقرأ الورقة في دقيقتين؟
```

في الورقة أعلاه لاحظ التالي:

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

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

## قائمة تحقق قبل أي محادثة صعبة مع مديرك Checklist

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

والمقالات التالية في نفس المرحلة تكمل هذا المقال: تجاوز المدير والتصعيد Skip-level عندما يكون الخطر أكبر من صلاحيته، وعندما يجعلك المدير تكره عملك عن الإدارة الدقيقة Micromanagement والتجاهل، وكيف تقول لا أمام مهام فوق طاقتك ومواعيد مستحيلة.

[![](https://arabroot.io/content/images/2026/10/skip-level-escalation-cover-cover.webp)دليلتجاوز المدير والتصعيد Skip-level: متى يجوز وكيف تفعلهمتى يكون رفع الموضوع إلى مدير مديرك مشروعاً، وكيف تكتب رسالة التصعيد وتخبر مديرك قبلها حتى تحل المشكلة دون أن تخسر العلاقة.](https://arabroot.io/articles/%D8%AA%D8%AC%D8%A7%D9%88%D8%B2-%D8%A7%D9%84%D9%85%D8%AF%D9%8A%D8%B1-%D9%88%D8%A7%D9%84%D8%AA%D8%B5%D8%B9%D9%8A%D8%AF-skip-level-%D9%85%D8%AA%D9%89-%D9%8A%D8%AC%D9%88%D8%B2-%D9%88%D9%83%D9%8A%D9%81/)[![](https://arabroot.io/content/images/2026/10/manager-demotivates-cover-cover.webp)دليلمدير يحبطك: الإدارة الدقيقة Micromanagement والتجاهلكيف تتعامل مع مدير يراقب كل سطر أو يتجاهلك أو ينتقدك أمام الفريق، بعبارات تقولها ومذكرة أسبوعية تعيد لك قراراتك.](https://arabroot.io/articles/%D9%85%D8%AF%D9%8A%D8%B1-%D9%8A%D8%AD%D8%A8%D8%B7%D9%83-%D8%A7%D9%84%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%AF%D9%82%D9%8A%D9%82%D8%A9-micromanagement-%D9%88%D8%A7%D9%84%D8%AA%D8%AC%D8%A7%D9%87%D9%84/)[![](https://arabroot.io/content/images/2026/10/saying-no-cover-cover.webp)دليلكيف تقول لا Saying No للمهام فوق طاقتك والمواعيد المستحيلةكيف ترد على عمل لا يتسع له وقتك بخيارات واضحة يختار منها من يملك القرار، ومتى يكون الجواب الصحيح نعم بشروط.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%88%D9%84-%D9%84%D8%A7-%D8%A8%D8%A7%D8%AD%D8%AA%D8%B1%D8%A7%D9%81%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D9%87%D8%A7%D9%85-%D9%88%D8%A7%D9%84%D9%85%D9%88%D8%A7%D8%B9%D9%8A%D8%AF-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%AD%D9%8A%D9%84%D8%A9/)[![](https://arabroot.io/content/images/2026/10/stakeholders-cover-cover-1.webp)دليلمواءمة أصحاب المصلحة Stakeholders وسياسة المؤسسةكيف تجعل المؤثرين في القرار شركاء في اقتراحك التقني قبل الاجتماع، وتقول لا مع خيارات، وتصعد خلافاً دون أن تخسر زملاءك.](https://arabroot.io/articles/%D9%85%D9%88%D8%A7%D8%A1%D9%85%D8%A9-%D8%A7%D8%B5%D8%AD%D8%A7%D8%A8-%D8%A7%D9%84%D9%85%D8%B5%D9%84%D8%AD%D8%A9-%D9%88%D8%B3%D9%8A%D8%A7%D8%B3%D8%A9-%D8%A7%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A9/)

## الخلاصة

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

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

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

- أكتوبر 2026: كتابة المقال، والتحقق من أرقام Gallup عن المديرين وتقرير Stripe عن وقت الصيانة والدين التقني من مصادرهما بتاريخ 31 أكتوبر 2026.