شخص واحد أم فريق؟ كيف تحدد الحد الأدنى لتشكيل المشروع بناءً على المهارات والاعتماديات والمخاطر

لا تدعم الأبحاث قاعدة بسيطة مثل "الفرق الأصغر أفضل دائماً" أو "الفرق الأكبر تنجز أكثر دائماً".

أظهر تحليل تلوي نُشر عام 2023 وشمل 208 تأثيرات مستقلة و21,435 فريقاً علاقة إجمالية تكاد تكون صفراً بين حجم الفريق وأداء المهمة، مع اختلاف كبير حسب السياق. ويبين المؤلفون أن أثر حجم الفريق يتغير، من بين أمور أخرى، مع تعقيد المهمة ومتطلبات التنسيق. [4]

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

الخلاصة العملية بسيطة: يجب أن ينتج عدد الأشخاص من طبيعة العمل، لا من رقم سحري.

يصف Scrum Guide لعام 2020 فريق Scrum بأنه صغير ومتعدد المهارات ويدير عمله ذاتياً. كما يذكر أن هذا الفريق يتكون عادة من 10 أشخاص أو أقل. [3]

هذه إرشادات مفيدة في سياق Scrum، لكنها ليست قانوناً عاماً لكل مشروع أو خدمة أو قطاع أو نموذج تنفيذ.

مشروع بناء، وحملة تسويقية، وتقييم أمني، ونظام مالي، وموقع معلومات صغير لها احتياجات مختلفة تماماً. لا ينبغي نقل رقم واحد مباشرة بين هذه الحالات.

يتطلب Service Standard البريطاني أن تكون فرق الخدمات الرقمية متعددة التخصصات وأن يكون لديها وصول إلى مجموعة مناسبة من المهارات. كما يوضح أن تشكيل الفريق يجب أن يتناسب مع ما يحتاج إلى تحقيقه في المرحلة المعنية. [1]

وتشير إرشادات GOV.UK الأخرى إلى أن حجم الفريق والأدوار المطلوبة يتغيران عبر مراحل بناء الخدمة. [2]

ومن ذلك تخرج قاعدة عملية:

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

لا يمكن تحديد حجم الفريق لنطاق غير واضح.

سجل على الأقل:

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

مشروع "إنشاء تطبيق" ومشروع "تصميم تطبيق وإنشائه وتأمينه ونشره وتشغيله لمدة عام" يحتاجان إلى تغطية عمل مختلفة تماماً.

بدلاً من كتابة المسميات فوراً، اذكر أنواع العمل التي يجب تنفيذها فعلياً.

في خدمة رقمية قد تشمل مثلاً:

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

سيكون لمشروع من نوع آخر قائمة مختلفة.

تشير GOV.UK إلى أن الفريق الذي يبني خدمة رقمية ويشغلها يحتاج إلى مجموعة واسعة من المهارات تشمل احتياجات المستخدمين والتصميم والبناء والاختبار والأمن والنشر والتشغيل. [2]

ليست كل مهارة مطلوبة بحاجة إلى شخص بدوام كامل داخل الفريق.

صنف كل مجال:

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

تسمح GOV.UK صراحة بأن تكون الخبرة المتخصصة متاحة للفريق من دون أن يكون صاحبها عضواً دائماً فيه. [1]

يساعد هذا غالباً على تجنب تضخيم الفريق من دون فقدان خبرة مهمة.

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

افحص:

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

تضع GOV.UK إدارة الاعتماديات على الفرق الأخرى ضمن القدرات اللازمة لبناء الخدمات الرقمية. [2]

وعندما تعمل عدة فرق على خدمة واحدة، تظهر حاجة إضافية لتنسيق الخطط والتقدم بينها. [8]

بعض الخبرات الضرورية لا تظهر في قائمة خصائص المنتج، لكن غيابها قد يكون مكلفاً.

بحسب المشروع قد تشمل:

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

توصي GOV.UK بإتاحة الخبرة المتخصصة عندما يحتاج إليها المشروع، كما تشير إلى أن تشكيل الفريق يجب أن يعكس أكثر افتراضات المرحلة الحالية خطورة. [1]

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

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

تؤكد مواد PMI الخاصة بتخطيط الموارد أهمية مواءمة المهارات والتوافر والتكلفة والخبرة مع احتياجات المشروع. [7]

لكل شخص افحص:

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

تغطية المهارات من دون تغطية الوقت ليست تغطية كاملة للمشروع.

يجب أن يراعي الحد الأدنى للتشكيل الاستمرارية أيضاً.

اسأل:

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

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

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

لا يحتاج المشروع إلى شخص منفصل لكل اسم دور.

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

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

لا تجمع المسؤوليات فقط لأن "أحداً يجب أن يقوم بها". يصبح الجمع منطقياً عندما يستطيع الشخص أداء المسؤوليتين بالمستوى المطلوب ولديه الوقت الكافي.

قد يكون شخص واحد تشكيلاً منطقياً إذا تحققت هذه الشروط معاً:

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

قد يكون ذلك مادة معلومات صغيرة، أو تحليلاً بسيطاً، أو استشارة لمرة واحدة، أو تنفيذًا محدوداً في بيئة مألوفة.

ومع ذلك يعتمد القرار على النطاق الفعلي. تسمية "مشروع صغير" لا تحسم الأمر وحدها.

يصبح الفريق أكثر تبريراً عندما تظهر عدة شروط من الآتي:

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

في هذه الحالات، إضافة القدرات الناقصة أهم من مجرد زيادة عدد الأشخاص.

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

أظهرت دراسة لمشاريع برمجية منشورة في Journal of Systems and Software أن العلاقات بين حجم الفريق والإنتاجية والجهد والزمن معقدة ولا تتوافق دائماً مع التوقعات البديهية. [6]

كما يبين التحليل التلوي لحجم الفرق أن النتائج تعتمد على سياق المهمة وتكاليف العمليات الجماعية. [4]

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

ليست كل مهارة مهمة بحاجة إلى وجود يومي.

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

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

هناك شرط واحد: يجب أن يكون التوافر حقيقياً. ينبغي أن يكون واضحاً:

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

قد يبدو الوصول إلى متخصص بلا مسؤولية محددة جيداً في المخطط التنظيمي ولا يعمل في مشروع حقيقي.

افترض أن الهدف إطلاق نظام حجز عبر الإنترنت.

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

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

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

نوع المنتج العام واحد، لكن اختلاف النطاق والمخاطر ونموذج التشغيل يخلق احتياجات مختلفة للفريق.

1. تبدأ بقائمة جاهزة من المسميات بدلاً من العمل المطلوب.

2. تفترض أن كل دور يحتاج إلى شخص منفصل.

3. تنظر إلى المهارات فقط وتتجاهل الوقت المتاح.

4. تضيف أشخاصاً من دون إزالة الاعتماديات والاختناقات.

5. تتجاهل المهارات التي تفرضها المخاطر لأنها لا تنتج خاصية ظاهرة.

6. تجعل عدة مجالات حرجة تعتمد على شخص واحد من دون قبول واع للمخاطرة.

7. تعامل التشكيل في بداية المشروع على أنه ثابت حتى النهاية.

تذكر GOV.UK صراحة أن حجم الفريق وأدواره يتغيران عبر مراحل تطوير الخدمة. [2]

وهذا مبدأ معقول خارج الخدمات الحكومية أيضاً:

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

الحد الأدنى للتشكيل خاص بالمرحلة والنطاق، وليس رقماً ثابتاً يُلصق بالمشروع إلى الأبد.

لكل مجال مهم، سجل خمسة أشياء:

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

بعد ذلك فقط عيّن الأشخاص المحددين.

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

1. هل لكل مجال عمل إلزامي مسؤول؟
2. هل لكل مسؤولية حرجة شخص يمتلك المهارة المناسبة؟
3. هل يجمع أحد عدة أدوار، وهل لديه وقت كاف فعلاً؟
4. هل يحتاج المشروع إلى عمل متواز لا يستطيع التشكيل الحالي دعمه؟
5. هل نعرف الاعتماديات الرئيسية على أشخاص وفرق وموردين آخرين؟
6. هل المخاطر المهمة لديها وصول إلى الخبرة المتخصصة الصحيحة؟
7. هل يمكن لغياب شخص واحد أن يوقف المشروع كله؟
8. هل التشكيل كاف للبناء وللإطلاق والتشغيل أيضاً إذا كان ذلك ضمن النطاق؟
9. هل نعرف المهارات التي يمكن أن تكون دورية بدلاً من دائمة؟
10. هل حددنا نقاطاً نعيد فيها تقييم التشكيل بعد تغير النطاق أو المرحلة؟

لا ينبغي أن يبدأ تصميم الفريق بسؤال:

"كم شخصاً تحتاج المشاريع المشابهة عادة؟"

الترتيب الأفضل هو:

النتيجة -> العمل -> المهارات -> الاعتماديات -> المخاطر -> القدرة -> الأشخاص.

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

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

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

[1] GOV.UK Service Standard - Have a multidisciplinary team
فتح المصدر

[2] GOV.UK Service Manual - Set up a service team at each phase
فتح المصدر

[3] The Scrum Guide, 2020 - Scrum Team
فتح المصدر

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
فتح المصدر

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
فتح المصدر

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
فتح المصدر

[7] Project Management Institute - Solving The Resource Puzzle
فتح المصدر

[8] GOV.UK Service Manual - Running more than one service team
فتح المصدر

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