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

# هل يسلم الفريق الأكبر أسرع؟ قانون Brooks والذكاء الاصطناعي
- URL: https://arabroot.io/articles/هل-يسلم-الفريق-الاكبر-اسرع-قانون-brooks/
- Published: 2026-10-08T23:00:00.000Z
- Updated: 2026-10-09T12:59:47.000Z
- Description: ماذا تقول الدراسات عن حجم فريق البرمجة وسرعة التسليم، ومتى تفيد إضافة الأشخاص، وما الذي يغيره الذكاء الاصطناعي فعلاً.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الفرق والمنتج, DevOps وCI/CD, استراتيجية تقنية, الاستضافة الذاتية

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

وفي [المقال السابق عن Agile في عصر الذكاء الاصطناعي](https://arabroot.io/articles/agile-%D9%81%D9%8A-%D8%B9%D8%B5%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/) رأينا أن الأدوات الجديدة تسرع كتابة الكود ولكنها تنقل الضغط إلى المراجعة والاستقرار، وهذا يعيد السؤال القديم بصيغة جديدة: إذا كان كل مطور اليوم أسرع، فهل نحتاج إلى فرق أصغر؟ وهل صار ممكناً أن يبني شخص واحد شركة كاملة؟ وسوف نلتزم هنا بنفس القاعدة: ما قيس نذكره مع مصدره وحدوده، وما هو رأي أو توقع نكتب أنه رأي ونذكر من قاله، وسوف نناقش في هذا المقال ما يلي:

- من أين جاءت قصة «اطرد نصف الفريق»، وما الذي وجدناه موثقاً منها.
- قانون Brooks من كتاب The Mythical Man-Month سنة 1975، والأسباب الثلاثة خلفه، وما قاله Brooks نفسه عن حدوده.
- ما الذي تقوله البيانات عن حجم الفريق: دراسات QSM، وأبحاث التراخي داخل المجموعات Social Loafing، وProject Aristotle في Google، وفرق Amazon الصغيرة Two-Pizza Teams.
- ما الذي يغيره الذكاء الاصطناعي فعلاً، وما الذي يبقى على البشر، وماذا يعني ذلك لمن ينتظر أن تسند إليه المهام.
- علامات أن فريقك أكبر أو أصغر مما يجب، ومتى تضيف أشخاصاً، وقائمة تحقق قصيرة.

## «اطرد نصف الفريق»: هل لهذه القصة مصدر؟

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

### Brooks سنة 1975: «اطرد 175 شخصاً»، ثم يرد على نفسه

في الفصل الثالث من كتاب [The Mythical Man-Month](https://archive.org/details/mythicalmanmonth00broo) الذي نشره Fred Brooks سنة 1975، وهو الذي أدار تطوير نظام التشغيل OS/360 في IBM، يبدأ من أبحاث وجدت فروقاً كبيرة بين أفضل المبرمجين وأضعفهم في نفس المجموعة، ومن أن عدد العقول التي تحتاج إلى تنسيق يرفع تكلفة المشروع، ثم يكتب الاستنتاج الذي يبدو أنه أصل القصة: إذا كان في مشروع من 200 شخص 25 مديراً هم أكفأ المبرمجين وأكثرهم خبرة، فاطرد الباقين وأرجع المديرين إلى البرمجة، وبنصه:

> "fire the 175 troops and put the managers back to programming."

ولكن لاحظ ما يفعله Brooks في الصفحة التالية مباشرة، فهو يصف هذه الفكرة بأنها تتجنب المشكلة الصعبة، ويحسب أن فريقاً صغيراً من عشرة أشخاص ممتازين، حتى لو كان كل واحد منهم أكفأ بسبع مرات وكان التواصل الأقل يضاعف الإنتاجية سبع مرات أخرى، سوف يحتاج إلى عشر سنوات لبناء نظام بحجم OS/360 الذي أخذ قرابة 5000 سنة عمل، وعندها يكون المنتج قد تقادم. والنتيجة التي يصل إليها أن الفريق الصغير الممتاز هو الأفضل للجودة ووحدة التصميم، وأنه يرى بإجماع الخبراء ألا يزيد على عشرة أشخاص، ولكنه أبطأ من أن يبني نظاماً ضخماً وحده، ولذلك يقترح تنظيم الفريق مثل الفريق الجراحي Surgical Team الذي اقترحه Harlan Mills: شخص يكتب الجزء الأساسي، وحوله فريق يساعده، لا عشرة أشخاص يقطعون في المشكلة كل من جهته.

### InfoWorld سنة 1984: «خطة Bermuda»

والمصدر الثاني مقال عن البرامج التي يعلن عنها قبل أن تجهز Vaporware في مجلة [InfoWorld عدد 7 مايو 1984](https://books.google.com/books?id=ti4EAAAAMBAJ&pg=PA49&ref=arabroot.io)، حيث يذكر الكاتب قانون Brooks ثم يقول إن أحد الساخرين ابتكر طريقة لإنهاء البرامج يسميها «خطة Bermuda»: أن تضع 90% من مبرمجي الشركة على قارب وترسلهم إلى Bermuda، بينما يكتب الـ 10% الباقون البرنامج. والمقال نفسه لا يذكر اسم صاحب الخطة ولا يربطها بـ Microsoft، وإنما يقدمها على أنها نكتة متداولة، ثم يضيف أن إحدى شركات الألعاب وجدت أن أفضل منتجاتها كتبها مبرمجون أفراد بعقود، لا فريق البرمجة الدائم فيها.

والخلاصة من هذا القسم أن قصة Microsoft في أوائل الألفينات تتداول دون مصدر يمكن الاعتماد عليه، وأن الفكرة التي تحملها موثقة منذ 1975 و1984، وأن أهم من كتبها، وهو Brooks، لم يقدمها كحل وإنما كبداية لسؤال أصعب: كيف تجمع بين صغر الفريق وحجم العمل الكبير؟ وهذا ما سوف نحاول الإجابة عنه في بقية المقال.

## قانون Brooks: لماذا تؤخر الإضافة المشروع المتأخر؟

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

> "Adding manpower to a late software project makes it later."

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

### السبب الأول: وقت التأهيل Ramp-up

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

### السبب الثاني: خطوط التواصل Communication Paths

إذا كان كل جزء من العمل يحتاج إلى تنسيق مع كل جزء آخر، فإن الجهد يزيد كما يقول Brooks بمقدار `n(n-1)/2`، وهو نفس الحساب الذي شرحناه للأنفاق في [معمارية Hub and Spoke](https://arabroot.io/articles/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%AD%D9%88%D8%B1-%D9%88%D8%A7%D9%84%D8%A3%D8%B7%D8%B1%D8%A7%D9%81-hub-and-spoke/#the-problem)، فلن نعيده هنا، وإنما نطبقه على الأشخاص: ثلاثة أشخاص بينهم ثلاثة خطوط، وخمسة بينهم عشرة، وعشرة بينهم 45، وعشرون بينهم 190، والصورة التالية تبين ذلك:

![ثلاث لوحات: ثلاثة أشخاص بينهم ثلاثة خطوط باللون الأخضر، وخمسة أشخاص بينهم عشرة خطوط باللون الأصفر، وعشرة أشخاص بينهم 45 خطاً باللون الأحمر، وتحتها رسم أعمدة لعدد خطوط التواصل حسب حجم الفريق من شخصين إلى عشرين: 1 و3 و6 و10 و15 و21 و28 و36 و45 و66 و105 و190، مع ملاحظة أن كل شخص جديد يضيف n-1 خطاً جديداً](https://arabroot.io/content/images/2026/10/team-size-01-paths.webp)

عدد خطوط التواصل Communication Paths يكبر أسرع بكثير من عدد الأشخاص، فالشخص العاشر يضيف تسعة خطوط جديدة دفعة واحدة

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

### السبب الثالث: تقسيم العمل Task Partitioning

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

![أربعة رسوم توضيحية لعدد الأشهر مقابل عدد الأشخاص: عمل يقسم بلا تواصل حيث ينخفض الوقت باستمرار، وعمل لا يقسم حيث يبقى الوقت ثابتاً، وعمل يقسم مع تواصل حيث يقل الانخفاض مع كل شخص، وعمل فيه علاقات معقدة حيث ينخفض الوقت ثم يرتفع. وتحتها مثال Brooks: الخطة 12 شخص شهر لثلاثة أشخاص في أربعة أشهر بمعلم في كل شهر، والواقع أن المعلم الأول تحقق بعد شهرين، وإضافة شخصين تعني شهراً للتدريب ثم إعادة التقسيم على خمسة أشخاص فينتهي العمل في الشهر الخامس كما لو لم يضف أحد](https://arabroot.io/content/images/2026/10/team-size-02-brooks-curves.webp)

منحنيات الأشخاص مقابل الأشهر Man-Month توضيحية على طريقة الأشكال 2.1 إلى 2.4 في الكتاب، والمثال في الأسفل هو مثال Brooks نفسه بأرقامه

في المثال أعلاه لاحظ التالي:

- المهمة قدرت بـ 12 Man-Month، ووزعت على ثلاثة أشخاص لأربعة أشهر، مع معلم Milestone في نهاية كل شهر.
- المعلم الأول تحقق بعد شهرين بدل شهر، فإذا افترض المدير أن الجزء الأول فقط قدر بشكل خاطئ، فالباقي تسعة أشهر عمل في شهرين، فيضيف شخصين.
- الشخصان الجديدان يحتاجان إلى تدريب من أحد الثلاثة، فإذا أخذ ذلك شهراً فقد ذهبت ثلاثة أشهر عمل لم تكن في التقدير، ثم يجب أن يعاد تقسيم العمل من ثلاثة أجزاء إلى خمسة، فيضيع بعض ما أنجز ويطول الاختبار، والنتيجة كما يكتب Brooks أن المنتج يتأخر بنفس القدر كما لو لم يضف أحد.
- وعندما يرى المدير في نهاية الشهر الثالث أن الوضع ما زال سيئاً، فالرغبة قوية في تكرار نفس الحل وإضافة المزيد، ويسمي Brooks هذه الحلقة كارثة الجدول المتجددة Regenerative Schedule Disaster.

### ما الذي قاله Brooks نفسه عن حدود القانون؟

يشيع أن Brooks تراجع عن القانون في الطبعات اللاحقة، والصحيح أنه قدمه منذ البداية سنة 1975 بعبارة «Oversimplifying outrageously»، أي أنه يعرف أنه تبسيط مبالغ فيه، وأن القانون كما كتبه عن مشروع متأخر بالفعل، لا عن كل إضافة في أي وقت. وفي نفس الفصل لم يجعل البديل هو تقليل العدد، وإنما ذكر خيارات أخرى للمدير: أن يعيد الجدولة بوقت كاف، وينقل نصيحة مهندس اسمه P. Fagg بألا يأخذ تأخيرات صغيرة «Take no small slips» حتى لا يعيد الجدولة مرة أخرى، أو أن يقلص المطلوب Scope بشكل رسمي ومدروس، لأن المطلوب سوف يقلص على أي حال، إما بقرار واضح أو بتصميم مستعجل واختبار ناقص.

وفي [الطبعة العشرينية سنة 1995](https://www.informit.com/store/mythical-man-month-essays-on-software-engineering-anniversary-9780201835953?ref=arabroot.io) أضاف Brooks أربعة فصول، منها الفصل 18 الذي جمع فيه أفكار الكتاب الأصلي في صورة قضايا مجردة بعنوان «True or False?»، والفصل 19 «The Mythical Man-Month After 20 Years» الذي راجع فيه ما بقي صحيحاً وما تغير، وكتب في مقدمة الطبعة أنه فوجئ بقلة القضايا التي انتقدتها الأبحاث أو أثبتتها أو نفتها خلال عشرين سنة، ولذلك وضع القائمة لتكون دعوة للنقاش، وناقش في الفصل الأخير دراسات حاولت أن تختبر القانون بنماذج محاكاة Simulation Models، مثل عمل Tarek Abdel-Hamid وStuart Madnick. والذي نأخذه من هذا كله قاعدة عملية واحدة: القانون يصف ما يحدث عندما تضيف أشخاصاً إلى عمل متأخر ومترابط في آخره، أما الإضافة المبكرة إلى عمل يمكن فصله فقضية أخرى، وسوف نعود إليها في القسم العملي.

## ماذا تقول البيانات عن حجم الفريق Team Size؟

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

![ست بطاقات: Putnam من QSM على 491 مشروعاً من 35 إلى 95 ألف سطر وجد أن أفضل أداء لفرق من 3 إلى 7 وأن الجدول يسوء من 9 إلى 11 وأن الجهد يرتفع بسرعة من 9 أشخاص، وArmel من QSM سنة 2009 وجدت أن الفرق الكبيرة في المشاريع الكبيرة لم تكن أسرع بشكل واضح وأن عيوبها أكثر وتكلفتها من 3 إلى قرابة 8 أضعاف، والتراخي داخل المجموعات من مراجعة Karau وWilliams سنة 1993 على 78 دراسة، وProject Aristotle في Google حيث جاء الأمان النفسي أولاً ولم يكن حجم الفريق مؤثراً بشكل معنوي داخل Google، وفرق Amazon ذات البيتزاتين قاعدة شركة لأقل من عشرة أشخاص مع ملكية واحدة، وBrooks سنة 1975 ملاحظة من تجربة OS/360](https://arabroot.io/content/images/2026/10/team-size-03-evidence.webp)

الأخضر قيس من بيانات أو تجارب Experiments، والأصفر قاعدة شركة، والرمادي ملاحظة خبير Expert Opinion، ولكل منها وزن مختلف عندما تقرر

### دراسات QSM على المشاريع المنتهية Completed Projects

شركة QSM تبيع أدوات لتقدير المشاريع البرمجية، وعندها قاعدة بيانات كبيرة من المشاريع المنتهية، ونشرت عدة تحليلات عن حجم الفريق. وفي [مقال Doug Putnam](https://web.archive.org/web/20190818200225/https://www.qsm.com/articles/team-size-can-be-key-successful-project) اختار الباحثون 491 مشروعاً من أنظمة المعلومات متوسطة الحجم انتهت خلال السنوات الثلاث السابقة للدراسة، حجم كل منها بين 35 ألفاً و95 ألف سطر جديد أو معدل، وقسموها إلى خمس مجموعات بحسب حجم الفريق، فوجدوا أن مؤشر الإنتاجية Productivity Index كان متقارباً ومرتفعاً في الفرق حتى سبعة أشخاص، وأعلى من الفرق الأكبر بدرجتين أو أكثر، وأن أقصر متوسط للمدة كان في فرق من 5 إلى 7 أشخاص تليها فرق من 3 إلى 5، وعند 9 إلى 11 شخصاً بدأ متوسط المدة في الارتفاع، وأن الجهد Effort والتكلفة يرتفعان مع حجم الفريق بشكل أسي تقريباً ويبدأ الارتفاع الحاد قرب تسعة أشخاص، وكانت خلاصتهم أن فريقاً من 3 إلى 7 أشخاص هو الأفضل لهذا النوع من المشاريع.

وفي [تدوينة Kate Armel سنة 2009](https://www.qsm.com/blog/2009/empirical-examination-brooks-law?ref=arabroot.io)، المبنية على تحليل زميلها Don Beckett لعينة من المشاريع الكبيرة، كانت النتيجة أكثر دقة من القانون نفسه: الفرق الكبيرة لم تأخذ وقتاً أطول بشكل واضح من المتوسط، وفي المشاريع الصغيرة ساعدت على البقاء عند المتوسط أو تحته، ولكن هذه الميزة اختفت عند حجم 100 ألف سطر، أما الأثر الأكبر فكان في الجودة والتكلفة: عيوب Defects أكثر من المتوسط، وتكلفة أعلى بثلاث مرات لنظام من 50 ألف سطر وقرابة ثماني مرات لنظام من مليون سطر، ولذلك وصفت التضخيم الكبير للفريق بأنه استراتيجية قليلة الفائدة.

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

### التراخي داخل المجموعة Social Loafing

السبب الآخر لا يتعلق بالتنسيق Coordination وإنما بالدافع Motivation. فقد جمع Max Ringelmann، وهو مهندس زراعي فرنسي، بيانات في ثمانينيات القرن التاسع عشر عن عمال يسحبون أو يدفعون حملاً، ونشرها سنة 1913، ووجد أن ما ينتجه الفرد يقل كلما كبرت المجموعة، كما يشرح [Kravitz وMartin سنة 1986](https://doi.org/10.1037/0022-3514.50.5.936?ref=arabroot.io) بعد أن عثرا على مقاله الأصلي. وكان Ringelmann يفسر ذلك بضعف التنسيق بين العمال، مع أنه كان يعرف أن الدافع له دور أيضاً. ثم أجرى [Latané وWilliams وHarkins سنة 1979](https://doi.org/10.1037/0022-3514.37.6.822?ref=arabroot.io) تجربتين على التصفيق والصياح، فوجدوا أن جهد الفرد ينخفض بوضوح عندما يعمل ضمن مجموعة، وأن هذا الانخفاض يأتي فوق ما يضيع بسبب ضعف التنسيق، وسموا الظاهرة Social Loafing، أي أن يبذل الفرد جهداً أقل عندما يعمل ضمن مجموعة مما يبذله وحده.

والأهم للمدير هو [المراجعة التي نشرها Karau وWilliams سنة 1993](https://doi.org/10.1037/0022-3514.65.4.681?ref=arabroot.io) على 78 دراسة، فقد وجدت أن الظاهرة ثابتة عبر المهام والمجتمعات، وأن أقوى ما يقللها أن تكون مساهمة الفرد قابلة للتقييم، وأن تكون المهمة ذات معنى له، وتوقعاته عن أداء زملائه، وثقافة المجتمع. وترجمة ذلك إلى فريق برمجيات أن الفريق الذي يملك كل فرد فيه جزءاً واضحاً، وتظهر فيه مساهمة كل شخص في طلبات الدمج والقرارات، ويعرف لماذا يبني ما يبنيه، أقل عرضة لهذه الظاهرة من فريق كبير يذوب فيه الفرد. وتذكر أن هذه تجارب في علم النفس على مهام بسيطة، وليست على فرق برمجيات، فهي تفسر جزءاً من الصورة لا كلها.

### Project Aristotle في Google: الأمان النفسي Psychological Safety قبل الحجم

درس فريق تحليلات الموارد البشرية في Google فرقها الداخلية في مشروع سمته [Project Aristotle](https://web.archive.org/web/2022/https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/introduction/) ليجيب عن سؤال واحد: ما الذي يجعل الفريق فعالاً Effective في Google؟ و[بحسب ما نشرته Google](https://web.archive.org/web/2022/https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/identify-dynamics-of-effective-teams/) استخدم الباحثون أكثر من 35 نموذجاً إحصائياً على مئات المتغيرات، ووجدوا أن ما يهم أكثر هو طريقة عمل الفريق لا من فيه، وكانت العوامل بالترتيب: الأمان النفسي Psychological Safety، أي أن يشعر الفرد أنه لن يحرج أو يعاقب إذا اعترف بخطأ أو سأل سؤالاً أو قدم فكرة جديدة، ثم الاعتمادية Dependability، ثم وضوح الهيكل والأهداف Structure and Clarity، ثم معنى العمل Meaning، ثم أثره Impact.

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

### فرق Amazon ذات البيتزاتين Two-Pizza Teams

القاعدة المشهورة تأتي من Jeff Bezos كما تنقلها [وثيقة AWS عن DevOps](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html?ref=arabroot.io): «We try to create teams that are no larger than can be fed by two pizzas»، أي ألا يكون الفريق أكبر مما تكفيه بيتزاتان. وتشرح [صفحة AWS عن هذه الفرق](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/?ref=arabroot.io) أن الحجم المقصود أقل من عشرة أشخاص في الغالب، وأن القاعدة جاءت مع تحويل Amazon نظامها من كتلة واحدة Monolith إلى خدمات مستقلة Microservices، وأن الحجم ليس هو الفكرة الأساسية وإنما الملكية: لكل فريق ملكية واحدة مركزة Single-threaded Ownership لمنتج أو خدمة محددة. وتذكر الصفحة نفسها أثر Ringelmann كأحد الأسباب.

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

### قانون Conway: حجم الفريق وشكل النظام

شرحنا في [مقال التصميم والمعمارية](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%88%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%AA%D9%87%D8%A7-%D9%88%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9/#conway) أن النظام يشبه بنية التواصل في المؤسسة التي بنته، وهذا هو الجسر بين حجم الفريق والمعمارية Architecture: إذا قسمت فريقاً كبيراً إلى فرق صغيرة دون أن تقسم النظام، فسوف تعود خطوط التواصل بين الفرق في كل تغيير. وتذكر [صفحة DORA عن الفرق المستقلة Loosely Coupled Teams](https://dora.dev/capabilities/loosely-coupled-teams/?ref=arabroot.io) علامات واضحة لذلك، منها أن يستطيع الفريق تغيير تصميم نظامه دون إذن من خارجه، وأن ينجز عمله دون تنسيق دقيق مع أشخاص خارج الفريق، وأن ينشر خدمته متى شاء بشكل مستقل عن الخدمات الأخرى، وأن يختبر دون بيئة تكامل مشتركة.

### الفرق الصغيرة Small Teams المشهورة، وما الذي لا تثبته

تسمع كثيراً أمثلة عن شركات بنت منتجات استخدمها مئات الملايين بفرق صغيرة جداً، وقد ذكرنا الأرقام الموثقة لـ YouTube وInstagram وWhatsApp عند شرائها، مع مصادرها، في [مقال Acqui-hiring](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B4%D8%AA%D8%B1%D9%8A-%D8%A7%D9%84%D8%B4%D8%B1%D9%83%D8%A7%D8%AA-%D8%A7%D9%84%D9%83%D8%A8%D9%8A%D8%B1%D8%A9-%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D9%88%D8%A7%D9%84%D9%85%D9%88%D8%A7%D9%87%D8%A8-acqui-hiring/#youtube-instagram-whatsapp)، فلن نكررها هنا. ولكن لاحظ أن هذه أمثلة مختارة لأنها نجحت، فلا نعرف كم فريقاً صغيراً بنفس الحجم فشل ولم يسمع به أحد، وهذا ما يسمى انحياز الناجين Survivorship Bias، وهي تثبت أن الفريق الصغير يستطيع أن يبني منتجاً كبيراً، ولا تثبت أن كل فريق صغير يستطيع.

### ما الذي قيس، وما هو رأي؟

| قيس بأرقام منشورة Evidence                                                                                    | رأي أو خبرة أو قاعدة شركة Opinion                                 |
| ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| عدد خطوط التواصل يكبر بمقدار n(n-1)/2، وهذا حساب لا خلاف عليه                                                 | أن كل خط يتحول إلى تكلفة فعلية، فهذا يعتمد على مدى ترابط العمل    |
| في بيانات QSM كانت الفرق من 3 إلى 7 الأفضل لمشاريع أنظمة المعلومات المتوسطة، والفرق الكبيرة أغلى وعيوبها أكثر | أن الرقم نفسه ينطبق على منتجك وتقنيتك اليوم                       |
| التراخي داخل المجموعة ظاهرة ثابتة في 78 دراسة، ويقل عندما تكون المساهمة واضحة والمهمة ذات معنى                | حجم أثرها في فرق البرمجيات تحديداً                                |
| في Google كان الأمان النفسي أهم عامل، ولم يرتبط حجم الفريق بالفعالية داخلها                                   | أن الحجم غير مهم في كل مكان، وGoogle نفسها تقول عكس ذلك           |
| لا توجد دراسة منشورة تقيس هذه الثلاثة مباشرة                                                                  | قاعدة البيتزاتين في Amazon، وقانون Brooks، وقصة «اطرد نصف الفريق» |

## ماذا يتغير مع الذكاء الاصطناعي AI؟

### إنتاج الفرد Individual Output: ما الذي تقوله الأدلة

جمعنا الأدلة عن أثر الذكاء الاصطناعي على المطورين، من تقارير DORA وتجربة METR ودراسات GitHub وMicrosoft، مع حدود كل منها، في [مقال Agile في عصر الذكاء الاصطناعي](https://arabroot.io/articles/agile-%D9%81%D9%8A-%D8%B9%D8%B5%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/#evidence)، فلن نعيد أرقامها، والذي يهمنا منها هنا نتيجتان: أن المهمة الفردية الصغيرة تنجز أسرع في أغلب الدراسات، وأن هذا لا يتحول تلقائياً إلى تسليم أسرع أو أكثر استقراراً على مستوى الفريق، لأن العمل ينتقل إلى [المراجعة Code Review](https://arabroot.io/articles/agile-%D9%81%D9%8A-%D8%B9%D8%B5%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/#review-bottleneck) والاختبار Testing والتشغيل Operations. وهذا مهم لسؤال الحجم، فإذا كان الشخص الواحد يكتب أكثر، فإن كل شخص يضيف إلى الفريق كمية أكبر من التغييرات التي يجب أن يراجعها ويفهمها غيره.

### شركة المليار دولار بشخص واحد One-Person Unicorn: توقع لا نتيجة

في مقابلة مع Alexis Ohanian في مؤتمر في سبتمبر 2023، [نقلتها Fortune في فبراير 2024](https://fortune.com/2024/02/04/sam-altman-one-person-unicorn-silicon-valley-founder-myth/?ref=arabroot.io)، قال Sam Altman المدير التنفيذي لشركة OpenAI إن في مجموعة محادثة مع أصدقائه من مديري شركات التقنية رهاناً على أول سنة تظهر فيها شركة بقيمة مليار دولار يديرها شخص واحد، وإن هذا كان مستحيلاً دون الذكاء الاصطناعي «and now will happen». وهذا توقع من شخص يبيع الأداة التي سوف تجعله ممكناً، ولذلك نضعه في خانة التوقعات، ولا نعرف حتى كتابة هذا المقال دراسة منشورة تقيس شركة بهذا الشكل.

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

### الحدود الحقيقية: ما الذي يبقى على البشر

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

![عمودان: في اليسار باللون الأزرق ما يسرعه الذكاء الاصطناعي لشخص واحد، وهو المسودة الأولى للكود، والاختبارات والحالات الحدية المقترحة، وتلخيص التغيير الطويل، والكود المتكرر وإعادة الهيكلة، ونموذج أولي في يوم، وسهم بعنوان مخرجات أكثر للتحقق منها يتجه إلى العمود الأيمن باللون الأخضر وفيه ما يحتاج إلى شخص باسمه: المراجعة، والملكية، والمناوبة، ومعرفة مجال العمل، وBus Factor بحيث يعرف شخصان كل جزء مهم](https://arabroot.io/content/images/2026/10/team-size-04-ai-limits.webp)

كل ما يكتبه الذكاء الاصطناعي يزيد ما يحتاج إلى إنسان يراجعه Review ويملكه Ownership ويشغله Operations

- **المراجعة Review:** كل تغيير يحتاج إلى شخص يفهمه ويوافق عليه، وإذا كان شخص واحد يكتب بسرعة عشرة أشخاص، فإن المراجعة تصبح هي حد الفريق، وقد شرحنا كيف تضع حداً للعمل الجاري على المراجعة في المقال السابق.
- **الملكية Ownership:** الأداة لا يمكن أن تكون مسؤولة عن خدمة، فعندما يسأل العميل لماذا حدث هذا، يجب أن يكون هناك فريق باسمه يجيب ويصلح.
- **المناوبة On-call:** النظام الذي يعمل على مدار الساعة يحتاج إلى أشخاص يتناوبون على الاستجابة للحوادث، وشخص واحد لا يمكن أن يناوب كل ليلة طوال السنة، وقد شرحنا أخف شكل لها في [خارطة CTO لشركة SaaS ناشئة](https://arabroot.io/articles/%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-cto-%D9%84%D8%B4%D8%B1%D9%83%D8%A9-saas-%D9%86%D8%A7%D8%B4%D8%A6%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D9%81%D8%B1%D9%82/#on-call).
- **معرفة مجال العمل Domain Knowledge:** لماذا وضعت هذه القاعدة في الفوترة، ومن هو العميل الذي طلب هذا الاستثناء، وما الذي حدث آخر مرة غيرناه، وهذه معرفة تتراكم في رؤوس الناس وفي الوثائق التي يكتبونها.
- **Bus Factor:** أي أقل عدد من الأشخاص إذا غابوا توقف المشروع، وفي [دراسة Avelino وزملائه سنة 2016](https://arxiv.org/abs/1604.06766?ref=arabroot.io) على 133 مشروعاً مشهوراً على GitHub كان هذا الرقم شخصين أو أقل في 65% منها. وكلما صغر الفريق بسبب الذكاء الاصطناعي، صار هذا الخطر أقرب، والسبب أن الفريق الأصغر يعني معرفة في عدد أقل من الرؤوس.

### هل يغير الذكاء الاصطناعي قانون Brooks؟

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

### ماذا يعني هذا لمن ينتظر أن تسند إليه المهام؟

هذا السؤال حساس، ولذلك نبدأ بما قيس: في [دراسة Erik Brynjolfsson وزملائه في Stanford](https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/?ref=arabroot.io)، بنسختها المحدثة في نوفمبر 2025 على بيانات رواتب من شركة ADP، انخفض توظيف من أعمارهم بين 22 و25 سنة في المهن الأكثر تعرضاً للذكاء الاصطناعي AI Exposure بنسبة 16% مقارنة بغيرهم، بينما بقي توظيف أصحاب الخبرة مستقراً، وانخفض توظيف مطوري البرمجيات في هذه الفئة العمرية قرابة 20% عن ذروته في أواخر 2022، وتركز الانخفاض في المهن التي يؤدي فيها الذكاء الاصطناعي العمل بدل الإنسان، لا التي يساعده فيها. وهذه بيانات من سوق العمل الأمريكي، والكتاب أنفسهم يصفونها بأنها متسقة مع أثر الذكاء الاصطناعي، لا بأنها دليل قاطع على السبب.

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

- **فهم المشكلة Problem Understanding:** أن تسأل لماذا قبل كيف، وأن تكتب معايير القبول Acceptance Criteria قبل الكود، وقد شرحنا ذلك في [هندسة المتطلبات](https://arabroot.io/articles/%D9%87%D9%86%D8%AF%D8%B3%D8%A9-%D8%A7%D9%84%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-requirements-engineering/).
- **الملكية Ownership:** أن تتابع الميزة بعد النشر، وتعرف هل استخدمها أحد، وتصلحها عندما تتعطل، بدل أن تعتبر المهمة منتهية عند دمج الكود.
- **المراجعة Code Review:** أن تقرأ كود غيرك، وكود الأداة، وتجد ما هو «صحيح تقريباً»، وهذه مهارة تزداد قيمتها كلما زاد الكود المكتوب.
- **الاختبار Testing:** أن تقرر ما هو السلوك الصحيح، وتكتب اختباراً يفشل عندما يكون الكود خاطئاً، كما في [أتمتة الاختبارات بالذكاء الاصطناعي](https://arabroot.io/articles/%D8%A7%D8%AA%D9%85%D8%AA%D8%A9-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D8%A8%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/).
- **التشغيل Operations:** أن تعرف كيف يعمل النظام في الإنتاج Production، وتقرأ السجلات Logs، وتشارك في المناوبة On-call، وتحافظ على مهارتك بالتمرين كما في [تمارين Kata](https://arabroot.io/articles/%D8%AA%D9%85%D8%A7%D8%B1%D9%8A%D9%86-kata-%D8%AD%D8%A7%D9%81%D8%B8-%D8%B9%D9%84%D9%89-%D9%85%D9%87%D8%A7%D8%B1%D8%AA%D9%83-%D8%AF%D9%88%D9%86-%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/).

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

## كيف تعرف أن حجم فريقك Team Size مناسب؟

### علامات أن الفريق أكبر مما يجب

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

### علامات أن الفريق أصغر مما يجب

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

### تقسيم الفريق الكبير إلى فرق صغيرة مستقلة Autonomous Teams

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

![في اليسار فريق واحد من 24 شخصاً باللون الأحمر مع كود واحد وإصدار واحد و276 خطاً محتملاً للتواصل، وفي اليمين أربعة فرق خضراء من ستة أشخاص لكل منها: فريق الطلبات Orders وفريق الفوترة Billing وفريق الكتالوج Catalog يملك كل منها خدمته وبياناته، وفريق المنصة Platform يقدم الأدوات وخطوط النشر، وفي كل فريق 15 خطاً داخلياً وينشر وحده، وبين الفرق عقد API](https://arabroot.io/content/images/2026/10/team-size-05-team-split.webp)

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

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

- الفريق الواحد من 24 شخصاً فيه 276 خطاً محتملاً، بينما الفرق الأربعة فيها 15 خطاً داخل كل فريق، أي 60 في المجموع، إضافة إلى التواصل بين الفرق.
- التواصل بين الفرق لا يختفي، ولكنه يصبح عن عقود API وقرارات معمارية، لا عن كل سطر في كل تغيير.
- التقسيم لا يعمل إلا إذا كان النظام نفسه قابلاً للتقسيم، فإذا كان الكود كتلة واحدة مترابطة فابدأ بفصل الأجزاء قبل فصل الفرق، كما في [قانون Conway](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%88%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%AA%D9%87%D8%A7-%D9%88%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9/#conway).
- فريق المنصة Platform Team لا يملك ميزات للمستخدم، وإنما يجعل عمل الفرق الأخرى أسهل، وقد شرحنا أنواع الفرق ومتى تحتاج إلى كل منها في [خارطة CTO](https://arabroot.io/articles/%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-cto-%D9%84%D8%B4%D8%B1%D9%83%D8%A9-saas-%D9%86%D8%A7%D8%B4%D8%A6%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D9%81%D8%B1%D9%82/#team).

### متى تضيف أشخاصاً فعلاً؟

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

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

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

## قائمة تحقق قبل أن تغير حجم فريقك

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

## الخلاصة

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

- قصة «اطرد نصف الفريق» المنسوبة إلى مطور في Microsoft لا نعرف لها مصدراً موثوقاً، والفكرة موثقة عند Brooks سنة 1975 الذي رد عليها مباشرة، وفي «خطة Bermuda» الساخرة في InfoWorld سنة 1984.
- قانون Brooks يقول إن إضافة الأشخاص إلى مشروع متأخر تؤخره، لثلاثة أسباب: وقت التأهيل، وخطوط التواصل التي تكبر بمقدار n(n-1)/2، والعمل الذي لا يقسم، وBrooks نفسه وصفه بأنه تبسيط مبالغ فيه منذ البداية.
- بيانات QSM تشير إلى أن الفرق من 3 إلى 7 هي الأفضل لمشاريع أنظمة المعلومات المتوسطة، وأن الفرق الكبيرة أغلى وعيوبها أكثر دون أن تكون أسرع بشكل واضح.
- التراخي داخل المجموعة ظاهرة ثابتة، ويقل عندما تكون مساهمة الفرد واضحة وعمله ذا معنى، وفي Google كان الأمان النفسي أهم من الحجم، وقاعدة البيتزاتين في Amazon قاعدة شركة عن الملكية قبل أن تكون عن العدد.
- الذكاء الاصطناعي يزيد ما يكتبه الفرد، ولكنه لا يلغي المراجعة والملكية والمناوبة ومعرفة مجال العمل وBus Factor، وشركة المليار بشخص واحد توقع لم يقس بعد.
- المهارات التي تبقى ذات قيمة هي فهم المشكلة والملكية والمراجعة والاختبار والتشغيل، والفرق الصغيرة المستقلة التي يملك كل منها جزءاً من النظام هي الطريقة الأنسب لتكبر دون أن تبطئ.

[![](https://arabroot.io/content/images/2026/10/agile-ai-cover-cover.webp)دليلAgile في عصر الذكاء الاصطناعي: ما الذي تغير فعلاً؟ما الذي تقوله الأبحاث عن الذكاء الاصطناعي في فرق البرمجيات، وكيف تعدل طريقة عمل فريقك في Scrum وKanban دون أن تخسر الجودة.](https://arabroot.io/articles/agile-%D9%81%D9%8A-%D8%B9%D8%B5%D8%B1-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/)[![](https://arabroot.io/content/images/2026/10/agile-scrum-cover-cover.webp)دليلAgile بلا شعارات: Scrum وKanban كما يطبقان فعلاًمن أين جاءت Agile، وكيف تعمل Scrum وKanban كما تصفها أدلتها الرسمية، وما الأخطاء التي تحولها إلى اجتماعات بلا فائدة.](https://arabroot.io/articles/agile-%D9%88-scrum-%D9%88-kanban-%D8%A8%D9%84%D8%A7-%D8%B4%D8%B9%D8%A7%D8%B1%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/arch-intro-cover-cover.webp)دليلالتصميم والمعمارية: أربعة مستويات لنشاط واحدما الفرق بين تصميم البرمجيات ومعماريتها وتصميم الأنظمة ومعمارية المؤسسة، ومن يقرر في كل مستوى وكم يعيش قراره.](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%88%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%AA%D9%87%D8%A7-%D9%88%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9/)[![](https://arabroot.io/content/images/2026/10/saas-cto-blueprint-cover-cover.webp)دليلخارطة CTO لشركة SaaS ناشئة من اليوم الأول إلى خمسين موظفاًماذا يجهز المدير التقني في كل مرحلة من نمو شركة SaaS ناشئة، وما الذي يؤجله حتى يحتاجه فعلاً.](https://arabroot.io/articles/%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-cto-%D9%84%D8%B4%D8%B1%D9%83%D8%A9-saas-%D9%86%D8%A7%D8%B4%D8%A6%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D9%81%D8%B1%D9%82/)[![](https://arabroot.io/content/images/2026/10/acqui-hiring-cover-cover.webp)دليلAcqui-hiring: كيف تشتري الشركات الكبيرة الفرق والمواهبلماذا تدفع شركة مليارات في شركة ناشئة ثم تغلق منتجها، وكيف تطور شراء الفرق من Borland إلى صفقات الذكاء الاصطناعي.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B4%D8%AA%D8%B1%D9%8A-%D8%A7%D9%84%D8%B4%D8%B1%D9%83%D8%A7%D8%AA-%D8%A7%D9%84%D9%83%D8%A8%D9%8A%D8%B1%D8%A9-%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D9%88%D8%A7%D9%84%D9%85%D9%88%D8%A7%D9%87%D8%A8-acqui-hiring/)[![](https://arabroot.io/content/images/2026/10/katas-cover-cover.webp)دليللماذا تتمرن دون ذكاء اصطناعي؟ تمارين Kata لك ولفريقكما الذي تقوله الأبحاث عن تسليم التفكير للأدوات، وكيف يحفظ روتين صغير من التمارين تحلها بيدك مهارتك وحدك ومع فريقك.](https://arabroot.io/articles/%D8%AA%D9%85%D8%A7%D8%B1%D9%8A%D9%86-kata-%D8%AD%D8%A7%D9%81%D8%B8-%D8%B9%D9%84%D9%89-%D9%85%D9%87%D8%A7%D8%B1%D8%AA%D9%83-%D8%AF%D9%88%D9%86-%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A/)

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

- أكتوبر 2026: كتابة المقال من كتاب The Mythical Man-Month بطبعتيه 1975 و1995، ومقال InfoWorld سنة 1984، ودراستي QSM، وأبحاث Ringelmann والتراخي داخل المجموعة، وProject Aristotle، وصفحات AWS عن فرق البيتزاتين، ودراسة Stanford عن التوظيف، مع رسومات لخطوط التواصل ومنحنيات Brooks والأدلة وحدود الذكاء الاصطناعي وتقسيم الفرق.