فرق العمل القائمة على المشاريع مقابل فرق العمل القائمة على المنتجات: أيهما أفضل لتطوير البرمجيات؟

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

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

تجربتي الشخصية: بين صيانة التطبيقات وتطوير المشاريع

قبل سنوات عديدة، انضممت إلى فريق التطوير المسؤول عن أحد الأنظمة الأساسية لشركة كبرى. كان أول منصب لي ضمن فريق Application Maintenance (AM)، وهو الفريق المسؤول عن الأجزاء القديمة (legacy parts) من التطبيق. كانت الأسباب التي أُخبرت بها واضحة ومباشرة: كنت جديدًا في الشركة، والمشاريع الجديدة كانت تسير بخطى سريعة، وتستخدم تقنيات حديثة لم يكن لدينا خبرة واسعة بها. لذا، كان فريق AM هو المكان المناسب لي لاكتساب الخبرة والنمو دون ضغط مفرط.

وعدوني بأنني بمجرد أن أجمع ما يكفي من المعرفة والخبرة، سأنتقل إلى فريق Project team. هذا الفريق كان يتولى تطوير الميزات الجديدة باستخدام أحدث التقنيات، وكان يضم نخبة المطورين ذوي الخبرة. بعد حوالي عام، تحقق هذا الانتقال بالفعل، لكنني لن أنسى أبدًا تلك الفترة التي قيل إنها “غير مرهقة” في فريق AM، والتي كانت في الواقع مليئة بالتحديات الخفية.

ديناميكية فرق المشاريع وفرق الصيانة: دورة متكررة

على الرغم من أن هذه الأحداث وقعت قبل سنوات، إلا أنني لاحظت تكرار هذا النمط مرارًا وتكرارًا منذ ذلك الحين، وفي كثير من الأحيان بأشكال أكثر تطرفًا. عندما تبدأ أي مبادرة جديدة، يتم تشكيل فريق Project team. يتولى هذا الفريق مسؤولية تطوير البنية المعمارية (architecture) والميزات الجديدة.

غالبًا ما يواجه فريق Project team تأخيرات متراكمة مقارنة بالخطة الأولية المتفائلة بشكل مفرط. ونتيجة لذلك، يبدأ أعضاء الفريق في العمل لساعات إضافية، متجاهلين بعض الممارسات الجيدة لإنهاء العمل في الوقت المحدد. غالبًا ما يتم التضحية بالجودة على مذبح “الخطة”، وتُنسى الاختبارات، وتُضاف التعديلات (patches) فوق التعديلات الأخرى. يبدأ المطورون في إضافة تعليقات مثل: "To be refactored as soon as we have some time"، مما يؤكد أن الدين التقني (Technical debt) موجود بالفعل وسيزداد فقط بمرور الوقت.

في نهاية المطاف، يتم إطلاق المشروع إلى بيئة الإنتاج (production)، وبعد فترة وجيزة من إطلاقه، يبدأ فريق Project team عملية الانتقال نحو فريق AM team. بعد فترة من التداخل، يُترك فريق AM team ليقوم بالمهمة بمفرده. عادةً ما يكون فريق AM team أصغر سنًا، وأقل خبرة، ولا يُعتبر بنفس قوة فريق Project team. لكن الجزء “الصعب” قد انتهى، والمشروع يعمل الآن. حان وقت فريق AM – يُفترض أن المهمة أسهل، ويجب أن تكون تكلفتها أقل، ويمكن للشركة تحمل فريق جديد من المطورين المبتدئين.

ماذا بعد عام من الإطلاق؟ تحديات فريق الصيانة

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

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

إذًا، لماذا إذا كانت مهمة فريق AM team أكثر صعوبة، يعمل جميع المطورين ذوي الخبرة في فريق Project team (وربما يكونون الآن في مكان آخر، يعملون على شيء “رائع” آخر)؟

لماذا يتولى الخبراء المشاريع الجديدة: بناء الأسس والتحديات الخفية

أحد الأسباب المحتملة لوجود الأشخاص الأكثر خبرة في بداية المشروع هو أننا نحتاج في البداية إلى وضع الأسس لما سيأتي. يجب علينا تحديد البنية المعمارية (architecture) واتخاذ قرارات أساسية حول تصميم الحل، مما يتطلب خبرة مناسبة. ومع ذلك، في بداية أي مشروع، غالبًا ما يكون لدينا معرفة محدودة بالمشكلة التي نُدعى لحلها. في بداية أي مشروع كبير، هناك العديد من “المجهولات المعروفة” (known unknowns) وأيضًا العديد من “المجهولات غير المعروفة” (unknown unknowns).

لهذا السبب، يجب دائمًا اعتبار بنية النظام (system architecture) تطورية. يجب أن نكون مدركين أن العديد من القرارات الحاسمة لا يمكن اتخاذها في البداية، بل يجب اتخاذها عندما تبدأ المجهولات في الكشف عن نفسها. نادرًا ما يمكن اتخاذ القرارات المعمارية بشكل نهائي في بداية المشروع. قد تظهر أسئلة معمارية حرجة في أي وقت خلال دورة حياة نظام البرمجيات (SW system).

وقد تحتاج تلك القرارات الحاسمة المتخذة في بداية المشروع إلى إعادة تقييم أو تغيير لاحقًا – ربما بسبب متطلبات جديدة، أو تقنيات جديدة مثل الحوسبة السحابية (Cloud)، أو ربما لأنها كانت ببساطة القرارات الخاطئة للمشكلة المراد حلها. لذا، نعم، صحيح أن فريق Project team يتخذ قرارات معمارية، لكن فريق AM team أيضًا يتخذ قرارات معمارية، ويجب أن يتخذها في بيئة أكثر تعقيدًا بكثير.

لماذا لا يمكن عكس الأدوار؟

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

الدوافع الخفية: لماذا يفضل الخبراء المشاريع الجديدة؟

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

التحول من فرق المشاريع إلى فرق المنتجات: نموذج “أنت تبنيه، أنت تديره”

في عام 2006، صاغ Werner Vogels، المدير التقني التنفيذي (CTO) في Amazon، الشعار الشهير: "you build it, you run it" (أنت تبنيه، أنت تديره). نقل هذا الشعار فكرة أن الفريق المسؤول عن منتج معين يجب أن يعتني به من بدايته وحتى مرحلة التشغيل (run phase)، حيث تشمل مرحلة التشغيل جوانب العمليات (Ops aspects) بالإضافة إلى جوانب التطور المستمر.

ببساطة، يكون نفس الفريق مسؤولاً عن جميع المراحل اللازمة لنجاح المنتج: التصميم (design)، البناء (build)، التشغيل (run)، والتطوير (evolve). هذا هو النموذج الذي تبنته الشركات الرقمية العملاقة التي ظهرت في العقد الماضي، من Amazon إلى Facebook وحتى Airbnb. إن نجاحها بلا منازع هو دليل على أن هذا النموذج هو الأنسب للعصر الرقمي.

في الوقت الحاضر، يؤكد عدد متزايد من الخبراء على ضرورة الانتقال من طريقة تنظيم العمل الموجهة بالمشاريع (project-oriented) إلى نموذج موجه بالمنتجات (product-oriented). هذا التحول معقد ويتضمن العديد من جوانب المؤسسة. ولكن بالنسبة للموضوع الذي نناقشه هنا، فإنه يعني بالتأكيد أننا بحاجة إلى التخلي عن فكرة فرق Project و AM المنفصلة، وإنشاء فرق منتجات (Product teams) أكثر استقرارًا.

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

الخاتمة: نحو نموذج المنتج في العصر الرقمي

في العصر الذي نعيش فيه، وهو العصر الرقمي، يجب أن نكون حذرين عندما نسمع عبارات مثل: “وعندما ينتهي المشروع، سننتقل إلى فريق الصيانة (AM)”. هذا لا يعني أنه لا يوجد مكان لفرق الصيانة على الإطلاق. لا تزال هناك أنظمة قديمة (legacy systems)، تخدم عادةً المهام المكتبية الخلفية (back office)، والتي تؤدي عملها بكفاءة عالية، وتتميز بالاستقرار الشديد، وتحتاج فقط إلى بعض الصيانة الدورية.

ولكن عندما يتعلق الأمر بتطوير قدرات رقمية جديدة ومميزة، نحتاج إلى الابتعاد عن نموذج Project/AM وتبني نموذج موجه بالمنتجات (Product-oriented model). في هذا النموذج، يتم تصميم الفرق لتكون مسؤولة ليس فقط عن بناء الإصدار الأول من المنتج، بل أيضًا عن تشغيله وصيانته. ويتعلمون من تشغيله بينما يطورونه بمرور الوقت لضمان بقائه ذا صلة باحتياجات مستخدميه النهائيين.

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

الخلاصة التقنية

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

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