التركيز العميق Deep Work: لماذا يحتاج المبرمج ساعات هادئة؟

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

وهذا الموقف ليس ضعفاً في تنظيمك لوقتك، وإنما هو طريقة عمل الذهن مع مهام تحتاج أن تحمل في رأسك نموذجاً كاملاً لجزء من النظام. وفي هذا المقال سوف نتحدث عن التركيز العميق Deep Work، وماذا تقول الدراسات عن تكلفة المقاطعة، ولماذا يختلف يوم المبرمج عن يوم المدير، ثم ثلاث حالات توضيحية من فرق تقنية، وفي كل حالة ما يحدث عادة وما يزيده سوءاً وما ينجح والعبارات التي تقولها. وفي آخر المقال اتفاقية تركيز Focus Agreement جاهزة يستطيع أي فريق أن يبدأ بها.

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

• ما هو التركيز العميق، ولماذا يحتاجه المبرمج أكثر من غيره.
• ماذا وجدت الدراسات عن المقاطعة Interruption: الوقت الضائع، والعودة إلى العمل، والضغط.
• جدول الصانع Maker's Schedule وجدول المدير Manager's Schedule، ولماذا يقسم اجتماع واحد يوم المبرمج.
• ثلاث حالات توضيحية: مبرمج يرد على كل رسالة فوراً، وقائد فريق Team Lead يقطع يوم فريقه، ومبرمج يختفي باسم التركيز.
• متى تقاطع زميلك، وكيف تكتب رسالة لا تحتاج خمس رسائل بعدها.
• دور مسؤول المقاطعات Interrupt Shield في الفريق، وكيف تطلب وقت التركيز من مديرك.
• اتفاقية تركيز للفريق، وقائمة تحقق، وأخطاء شائعة.

ما هو التركيز العميق Deep Work؟

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

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

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

ماذا تقول الدراسات عن المقاطعة Interruptions؟

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

الدراسة الأولى: كم مرة تقطع أعمالنا؟ في دراسة ميدانية نشرت في مؤتمر CHI سنة 2005 بعنوان No Task Left Behind?، راقبت Gloria Mark وزملاؤها عمال معرفة في شركة تقنية، ومنهم مطورون ومدراء ومحللون، لأكثر من 700 ساعة مراقبة مباشرة. ووجدوا أن الشخص يقضي في المتوسط نحو 11 دقيقة في «مجال عمل» واحد Working Sphere قبل أن ينتقل إلى غيره، وأن 57% من هذه المجالات تقطع قبل أن تنتهي. وعندما يعود الشخص إلى العمل المقطوع في نفس اليوم، وهذا حدث في 77.2% من الحالات، استغرق ذلك في المتوسط 25 دقيقة و26 ثانية. ولاحظ أن هذا ليس وقت المقاطعة نفسها، وإنما الوقت حتى يعود الشخص إلى ما كان يعمل عليه، وفي هذا الوقت يكون قد تنقل غالباً بين أعمال أخرى.

الدراسة الثانية: ماذا يحدث للمبرمج تحديداً؟ في ورقة Resumption strategies for interrupted programming tasks المنشورة في مجلة Software Quality Journal، حلل Chris Parnin وSpencer Rugaber نحو 10,000 جلسة برمجة مسجلة لـ 86 مبرمجاً، ومعها استبيان شارك فيه 414 مبرمجاً. والنتيجة التي تهمنا أن التعديل في الكود عاد خلال أقل من دقيقة بعد المقاطعة في 10% فقط من الجلسات، وأن 7% فقط من الجلسات بدأ فيها المبرمج التعديل دون أن يتنقل أولاً إلى أماكن أخرى في الكود. وهذا يعني أن المبرمج بعد المقاطعة لا يكمل الكتابة، وإنما يتجول في الكود ليعيد بناء ما كان في ذهنه، وهو بالضبط ما تشعر به عندما تعود من اجتماع وتسأل نفسك: لماذا فتحت هذا الملف؟

الدراسة الثالثة: هل المقاطعة تبطئ العمل؟ والجواب المفاجئ في تجربة The Cost of Interrupted Work: More Speed and Stress سنة 2008 أنها لم تبطئه. فقد طلب الباحثون من 48 مشاركاً الرد على مجموعة رسائل بريد في بيئة مكتب محاكاة، مرة دون مقاطعة ومرتين مع مقاطعة كل دقيقتين تقريباً، فأنهى المشاركون المهمة المقطوعة في وقت أقل ودون فرق في الجودة. ولكن الثمن ظهر في مكان آخر: ارتفع عندهم الضغط والإحباط والشعور بضيق الوقت والجهد المبذول، وحدث ذلك بعد 20 دقيقة فقط من العمل المقطوع. وتفسير الباحثين أن الناس عندما يعرفون أنهم سوف يقاطعون يعملون أسرع ويكتبون أقل لتعويض الوقت، وهذا يعني أن الفريق الذي يقاطع طوال اليوم قد لا يرى التأخير في التقارير مباشرة، ولكنه يدفعه من أعصاب أفراده.

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

جدول الصانع وجدول المدير Maker's Schedule

في سنة 2009 كتب Paul Graham مقالاً قصيراً بعنوان Maker's Schedule, Manager's Schedule يشرح فيه لماذا يكره المبرمجون الاجتماعات أكثر من غيرهم. والفكرة أن هناك نوعين من الجداول: جدول المدير مقسم إلى ساعات، وكل ساعة لعمل مختلف، فإضافة اجتماع تعني فقط أن تجد ساعة فارغة. أما جدول الصانع، أي المبرمج والكاتب والمصمم، فيعمل بوحدات لا تقل عن نصف يوم، لأنك لا تستطيع أن تكتب جزءاً معقداً من النظام في ساعة واحدة، فساعة واحدة بالكاد تكفي لتبدأ. لذلك اجتماع واحد في منتصف بعد الظهر لا يأخذ ساعة من يوم المبرمج، وإنما يقسم بعد الظهر إلى قطعتين كل واحدة منهما أصغر من أن تكفي لعمل صعب.

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

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

أين يذهب يوم المبرمج؟ Meetings and Chat

في تقرير Work Trend Index الذي نشرته Microsoft في مايو 2023، وهو استبيان شمل 31 ألف موظف في 31 دولة إضافة إلى بيانات الاستخدام من منتجاتها، قال 68% من المشاركين إنهم لا يجدون وقتاً كافياً للتركيز دون مقاطعة خلال يوم العمل، وكان الموظف المتوسط يقضي 57% من وقته في التواصل، أي الاجتماعات والبريد والمحادثات، و43% فقط في إنتاج العمل نفسه. ورتب المشاركون الاجتماعات غير الفعالة كأول ما يعطل إنتاجيتهم، وجاءت كثرة الاجتماعات في المرتبة الثالثة. وهذه أرقام لعمال المعرفة عموماً وليست للمبرمجين فقط، ولكنها تعطيك صورة عن البيئة التي يعمل فيها أغلبنا.

وفي الفرق التقنية يأتي الوقت الضائع من مصادر متكررة، وإذا عرفتها تستطيع أن تتعامل مع كل واحد منها بطريقته:

• أداة المحادثة: مثل Slack أو Teams، وهي مفيدة جداً ولكنها تجعل كل سؤال يبدو عاجلاً، لأن النقطة الحمراء لا تفرق بين عطل في بيئة الإنتاج Production وسؤال عن موعد الغداء.
• الاجتماعات الموزعة: الاجتماع اليومي القصير Daily Standup في الساعة العاشرة والنصف، ومراجعة التصميم Design Review في الثانية عشرة، والاجتماع الفردي One-on-One في الثالثة، فلا يبقى في اليوم فترة متصلة.
• الأسئلة المتكررة: نفس السؤال عن طريقة تشغيل البيئة المحلية يصل كل أسبوع، لأن الجواب ليس مكتوباً في مكان واحد.
• الطلبات من خارج الفريق: الدعم الفني والمبيعات والفرق الأخرى، وكل طلب يذهب إلى الشخص الذي يعرفونه وليس إلى الشخص المناسب.
• المقاطعة الذاتية: وهذه لا يتحدث عنها أحد، فأنت تفتح البريد أو المتصفح كل عشر دقائق دون أن يطلب منك أحد ذلك، وفي دراسة Mark لسنة 2005 كان جزء كبير من المقاطعات داخلياً وليس من الآخرين.

ثلاث حالات توضيحية Case Studies

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

الحالة الأولى: مبرمج يرد على كل رسالة فوراً Always-on

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

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

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

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

عبارات تقولها أو تكتبها:

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

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

«أنا الآن في فترة تركيز، هل يمكن أن تكتب لي ما تحاول فعله وما الخطأ الذي يظهر؟ سأرد عليك قبل الواحدة.»

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

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

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

الحالة الثانية: قائد فريق يقطع يوم فريقه Meeting-heavy Lead

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

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

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

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

عبارات تقولها:

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

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

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

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

متى يكون الحل أن تغادر: لا يتعلق الأمر هنا بالمغادرة، وإنما بأن تعرف أن التحول من مهندس إلى قائد يغير جدولك، وأن من مسؤوليتك الجديدة أن تحمي جدول فريقك حتى لو لم يعد جدولك يشبهه.

الحالة الثالثة: مبرمج يختفي باسم التركيز Focus as Isolation

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

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

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

ما الذي ينجح: أن يفهم أن التركيز اتفاق جماعي وليس حقاً فردياً مطلقاً، فيحدد فترة تركيز واضحة، ويعطي خارجها وقتاً ثابتاً لمراجعة الكود Code Review والرد على الأسئلة، ويلتزم بوقت رد متفق عليه في الفريق، ويبقى متاحاً دائماً لقناة الحوادث. ويكتب ما يعرفه وحده حتى لا يكون هو نقطة الفشل الوحيدة Single Point of Failure في الفريق.

عبارات يقولها قائد الفريق له:

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

وعبارات يقولها هو إذا أدرك المشكلة:

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

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

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

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

قبل أن تقاطع زميلك Interrupt or Wait

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

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

وفي كل الحالات، اكتب رسالة كاملة. فالرسالة «مرحبا، عندك دقيقة؟» وحدها تقاطع زميلك مرتين: مرة عندما يقرؤها، ومرة عندما يرد ثم ينتظر سؤالك الحقيقي. أما الرسالة الكاملة فيستطيع أن يقرأها ويرد عليها في وقت واحد. والمثال التالي يبين الفرق:

«مرحبا، عندك دقيقة؟»

«أحاول تشغيل خدمة الطلبات محلياً، وعند docker compose up يفشل الاتصال بقاعدة البيانات بالخطأ connection refused على المنفذ 5432. جربت إعادة تشغيل الحاوية وتأكدت أن ملف .env منسوخ من المثال. هل هناك خطوة لم أفعلها؟ لست متوقفاً، أعمل على الاختبارات حتى ترد.»

والرسالة الثانية أطول، ولكنها توفر على الطرفين خمس رسائل، وتخبر زميلك أنه يستطيع أن يكمل ما في يده لأنك لست متوقفاً. وهذه العادة وحدها تقلل المقاطعات في الفريق أكثر من أي أداة.

مسؤول المقاطعات Interrupt Shield

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

ولكي ينجح هذا الدور، انتبه إلى أربعة أمور:

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

وهذا الدور يختلف عن المناوبة On-call، فالمناوبة للحوادث خارج وقت العمل وداخله وتحتاج تنبيهات وأدوات، ولها مقال مستقل في هذه السلسلة عن ضغط المناوبة، أما مسؤول المقاطعات فهو لأسئلة وقت العمل العادية.

كيف تطلب وقت التركيز من مديرك؟ Asking for Focus Time

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

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

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

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

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

اتفاقية التركيز للفريق Team Focus Agreement

الأداة العملية في هذا المقال اتفاقية مكتوبة يتفق عليها الفريق، وتجيب على الأسئلة التي سببت المشكلات في الحالات الثلاث: متى نركز، ومتى نجتمع، وما القناة المناسبة لكل نوع من الأسئلة، وما وقت الرد المتوقع، ومن يستقبل المقاطعات، وما الاستثناءات، وكيف نعرف أن الاتفاقية نجحت. والنسخة الكاملة محفوظة في الملف lab/team-focus-agreement.md، وهذا نصها:

# اتفاقية التركيز للفريق Team Focus Agreement

الفريق: ...............        تاريخ البداية: ..../..../....        تاريخ المراجعة: بعد أسبوعين

## 1. ساعات التركيز Focus Hours
- الأيام: الأحد إلى الخميس
- الفترة المحمية: من 9:00 إلى 12:00 بتوقيت السعودية
- خلال الفترة المحمية: لا اجتماعات داخلية، والحالة في أداة المحادثة «تركيز»، والإشعارات مغلقة إلا قناة الحوادث

## 2. الاجتماعات Meetings
- الاجتماعات الداخلية بين 13:00 و15:00 فقط
- كل اجتماع له جدول أعمال مكتوب قبل يوم، وإلا يلغى أو يتحول إلى رسالة
- يوم بلا اجتماعات: ........ (اختياري)

## 3. قنوات التواصل ووقت الرد Channels and Response Time
| القناة | متى نستخدمها | وقت الرد المتوقع |
|---|---|---|
| مكالمة أو قناة الحوادث | الإنتاج متوقف أو عميل يتضرر الآن | فوراً |
| رسالة مباشرة | سؤال يوقف عملك تماماً | خلال ساعتين في وقت العمل |
| قناة الفريق | سؤال أو رأي يحتمل الانتظار | نفس اليوم |
| تذكرة Ticket | طلب عمل أو خلل غير عاجل | في التخطيط القادم |

## 4. مسؤول المقاطعات Interrupt Shield
- الدور يتنقل أسبوعياً حسب الجدول: ..............
- يستقبل أسئلة الفرق الأخرى والدعم الفني، ويرد أو يوجه أو يسجل تذكرة
- لا يأخذ مهمة كبيرة في أسبوعه، ويعمل على المهام الصغيرة والتوثيق

## 5. الرسالة الكاملة Complete Message
كل سؤال مكتوب يحتوي: ماذا تحاول أن تفعل، ماذا جربت وما النتيجة، الخطأ أو الرابط كما هو، ومتى تحتاج الرد.
لا نرسل «مرحبا» وحدها وننتظر.

## 6. الاستثناءات Exceptions
- الحوادث، والإطلاق المجدول، والعميل الذي ينتظر رداً تعاقدياً
- أي عضو يستطيع أن يطلب استثناء لأسبوع بكتابته في قناة الفريق

## 7. كيف نقيس Measure
- كل عضو يسجل أطول وقت متصل للتركيز في يومه (بالدقائق) لمدة أسبوعين
- نقارن قبل الاتفاقية وبعدها، ومعها: المهام المنجزة، والأسئلة التي تأخر ردها، وشكوى أي فريق آخر
- في المراجعة نقرر: نبقي الاتفاقية، أو نعدلها، أو نلغيها

وفي هذه الاتفاقية لاحظ التالي:

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

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

أخطاء شائعة Common Mistakes

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

متى تكون المشكلة أكبر من التركيز؟ When It Is Not About Focus

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

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

قائمة تحقق Checklist

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

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

دليلالاحتراق الوظيفي Burnout عند المبرمجين: العلامات والأسبابما تقوله منظمة الصحة العالمية عن الاحتراق الوظيفي، ومن أين يأتي في الفرق التقنية، وما يفعله المهندس لنفسه وقائد الفريق لفريقه.دليلضغط المناوبة On-call والحوادث: كيف تحمي نفسك وفريقكما الحدود التي يضعها كتاب Google SRE للمناوبة المستدامة، وكيف تقلل التنبيهات وتصمم الجدول وتطلب التعويض والراحة دون صدام.دليلالتوازن بين العمل والحياة في العمل عن بعد Remote Workماذا تقول الدراسات عن العمل الهجين، ولماذا يتمدد يوم العمل في البيت، وكيف تضع حدوداً يحترمها فريقك دون أن تختفي عنه.دليلكيف تقول لا Saying No للمهام فوق طاقتك والمواعيد المستحيلةكيف ترد على عمل لا يتسع له وقتك بخيارات واضحة يختار منها من يملك القرار، ومتى يكون الجواب الصحيح نعم بشروط.دليلمدير يحبطك: الإدارة الدقيقة Micromanagement والتجاهلكيف تتعامل مع مدير يراقب كل سطر أو يتجاهلك أو ينتقدك أمام الفريق، بعبارات تقولها ومذكرة أسبوعية تعيد لك قراراتك.دليلالأمان النفسي Psychological Safety: ما وجدته Googleما معنى الأمان النفسي كما عرفته Edmondson، ولماذا كان أهم عامل في فعالية فرق Google، وكيف تقيسه في فريقك وتبنيه بسلوك يومي.

الخلاصة

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

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

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

• أكتوبر 2026: كتابة المقال، ومراجعة نتائج دراسات Mark وزملائها (2005 و2008) وParnin مع Rugaber ومقال Paul Graham وتقرير Microsoft Work Trend Index لسنة 2023 من مصادرها بتاريخ 31 أكتوبر 2026.