إضفاء الهيكلية على فريق التطوير في الشركات الناشئة: دروس مستفادة من التجربة

مقدمة: تحديات الهيكلية في الشركات الناشئة

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

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

الأحداث التي قادت إلى التغيير

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

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

ثم جاء مشروع بلور مشكلتنا. كان المنتج الذي أعمل عليه يتضمن مفهومين: bills (المستحقات) و invoices (الفواتير). كنا نعمل على ميزة جديدة تسمح للمستخدمين بتحميل صورة فاتورة ليتم إدخالها يدوياً بواسطة خدمة. كانت المشكلة أن مدير المنتج كان يصر على استخدام كلمة "bills" بدلاً من "invoices". لم تكن هناك قصة مستخدم (user story)، ولا تذكرة (ticket)، كان كل هذا في ذهن مدير المنتج. كانت المتطلبات تُنقل شفهياً أو عبر رسائل Slack. المطور الذي يعمل على المشروع لم يُخبر إلا بـ "bills".

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

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

الحصول على دعم الفريق

أود أن أؤكد هنا أنني لا أحب إصدار الأوامر من الأعلى. أشعر أن العلاقة بين القائد والفريق هي علاقة تعاونية. قد ألعب دور القائد أحياناً لأنها طبيعتي، ولكن من المهم أن تُناقش الأفكار وأن يشعر الناس بأن آراءهم مسموعة ومقدرة.

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

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

نسختنا من منهجية Scrum

بعد وصف كيف ستبدو عملية Scrum "الكاملة"، أوضحت للفريق الغرض من كل جانب وطقس. أردت تسليط الضوء على الأماكن التي يمكن أن نحقق فيها أكبر المكاسب. لم يرغب أحد في 10 ساعات من الاجتماعات لكل sprint.

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

• اجتماع التخطيط والتحضير (Grooming/Planning Meeting): يبدأ الـ sprint باجتماع لمدة ساعتين صباح يوم الاثنين. في هذا الاجتماع، كنا (فريق التطوير ومدير المنتج) نراجع قائمة المهام المتراكمة (backlog). يتضمن هذا المراجعة توضيح قصص المستخدم (user stories) لإزالة سوء الفهم؛ التقدير باستخدام نقاط القصة (story points)؛ وتحديد الأولويات بناءً على خارطة طريق الشركة.
• اختيار المهام: يختار الفريق كمية العمل التي يشعرون أنهم يستطيعون إنجازها، بناءً على الأولوية، ويضعونها في الـ sprint الحالي. كان هذا العمل عبارة عن مجموعة من قصص المستخدم.
• تفكيك المهام: يغادر مدير المنتج، ويقوم فريق التطوير بتقسيم هذه القصص إلى مهام أصغر، ويحصلون على فكرة عامة عن من سيعمل على ماذا، ثم يبدأون العمل. وقد أعطى هذا مدير المنتج شفافية حول ما يمكننا تسليمه، وهو ما كان يفتقر إليه بشدة. كما منح الفريق عبء عملهم الكامل لمدة أسبوعين، مما سمح لنا بالتخطيط والعمل بوتيرة مناسبة.
• أيام التطوير: كانت الأسبوع ونصف التالية مخصصة لأيام التطوير. وشمل ذلك مراجعات الكود من الأقران (peer code reviews) على فروع الميزات (feature branches) قبل دمجها.
• تسليم التطوير (Dev Hands-off): كان يتم ظهر يوم الأربعاء من الأسبوع الثاني. كنا بعدها نُعد بناء ضمان الجودة (QA build)، وجدول بيانات ضمان الجودة (QA spreadsheet)، ونبدأ الاختبار اليدوي. كانت الفكرة هي إنهاء الفحص الأولي لضمان الجودة بحلول نهاية يوم الأربعاء، وقضاء يومي الخميس والجمعة في حلقة إصلاح الأخطاء والاختبار حتى نكون راضين عن البناء.
• المراجعة والنشر: في هذه المرحلة، يتم تسليم البناء إلى المدير التقني (CTO) لإجراء مراجعة نهائية للكود، ويتم نشره يوم الثلاثاء التالي. يتم إصلاح واختبار المشكلات التي يتم العثور عليها في مراجعة الكود يوم الاثنين إذا لزم الأمر.
• اجتماع الاستعراض اللاحق (Retrospective/Postmortem): بعد ظهر يوم الجمعة، كنا نعقد اجتماع استعراض لاحق خالٍ من اللوم (blameless retrospective/postmortem). هنا كنا نكشف الأمور على حقيقتها. من المهم الاعتراف بما سار بشكل سيء، ومعالجة الأسباب لتجنبها في المستقبل.

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

• الدروس المستفادة:
• قسّم واجمع الاجتماعات بناءً على احتياجات فريقك. لا تفعل الأشياء "لمجرد أنها كذلك".
• شارك تقدمك خارج قسمك. أحياناً يمكن لأفكارك أن توفر فوائد خارج فريقك.

إطار عمل للاختبار يمكن الوثوق به

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

كان لدينا مجموعة جيدة من الاختبارات الآلية (unit and integration tests)، ولكن لم تكن لدينا اختبارات شاملة (end-to-end tests). أفضل أيضاً أن يكون هناك بعض الاختبارات الاستكشافية (exploratory testing) كذلك. في الماضي، رأيت أنها تكشف عن سلوكيات غريبة قد تفوتها الاختبارات الآلية.

قمنا بإعداد مستند Google Doc يحتوي على جميع تذاكر المهام (بما في ذلك روابط قصص المستخدم) في العمود الأول، وجميع أسماء المطورين (ومدير المنتج) في الصف الأول. كانت الفكرة هي أن كل تذكرة يجب أن تحصل على علامتي X، وكلاهما من أشخاص لم يعملوا على الميزة. سمحت لنا استراتيجية "فرق تسد" هذه بالاختبار بدقة شديدة في فترة زمنية قصيرة نسبياً.

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

النجاح المحقق

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

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

نهاية مفاجئة

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

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

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

أخطاء ارتكبت

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

• عدم القياس: كيف تعرف أنك فعلت ذلك بشكل صحيح إذا لم تأخذ قياسات قبل وبعد؟ لم يكن لدينا قياس عن بعد (telemetry)، وقليل جداً من التنبيهات، وبصراحة، إذا كان للميزة تأثير سلبي، لم نكن نعرف عنه.
• الكثير من الاختبار اليدوي، وعدم تبني الأتمتة: ما كنا نفتقده حقاً هو مجموعة جيدة من اختبارات E2E الآلية. بدأنا العمل على هذه الاختبارات قرب النهاية، لكننا لم نعطها الأولوية الكافية. كان يمكن اكتشاف العديد من الأخطاء التي وجدناها أثناء الاختبار اليدوي خلال بعض اختبارات القبول باستخدام Cucumber، أو بعض اختبارات E2E Selenium.
• الإصدارات الكبيرة (Big Bang Releases): أعلم أن جزءاً شائعاً من Scrum للعديد من الشركات هو فكرة أن جميع أعمال الـ sprint يتم عرضها وإصدارها معاً. المشكلة في هذا ذات شقين. أولاً، في شركة ناشئة تحتاج إلى التحرك بشكل أسرع. تحتاج إلى التغلب على المنافسين وتقديم قيمة للعملاء والحصول على ملاحظات منهم بأسرع وقت ممكن. وكلما كانت حلقة التغذية الراجعة أقصر، كان ذلك أفضل. لذلك، كان من الأفضل إجراء إصدارات متعددة لكل sprint. من الصعب تنسيق الاختبار وضمان الجودة، لكن لا يزال من الأفضل الإصدار بسرعة وبشكل متكرر. ثانياً، كلما كان الإصدار أكبر، زادت المخاطر. إصدار أجزاء أصغر يعني أن عدداً أقل من التغييرات يتم إصدارها في وقت واحد. إذا كانت هناك أي مشكلة، فمن الأسهل تحديدها وإصلاحها، ولن يؤثر التراجع (rollback) على الميزات الأخرى التي تعمل بشكل صحيح. لذلك تعلمت أن الإصدار في قطاعات رأسية (verticals) صغيرة قدر الإمكان هو الطريقة الأكثر أماناً والأقل ارتباطاً لإصدار البرمجيات.

الخلاصة

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

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

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