بناء فرق هندسية تتوسّع مع نمو الأعمال

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

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

وظّف بحسب المرحلة التي أنت فيها فعلًا

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

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

دع البنية تتبع التواصل

قانون كونواي (Conway's Law) ليس شعارًا، بل قيدٌ واقعي. ستؤول بنية نظامك إلى محاكاة مسارات التواصل لديك، خطّطتَ لذلك أم لم تخطّط. فإن عملت أربعة فرقٍ على خدمة الدفع (checkout) نفسها، فستنتهي إلى خدمةٍ لها أربعة ملّاك ولا مالك لها.

أبقِ الفرق صغيرة — من خمسة إلى ثمانية مهندسين — وامنح كلّ فريق نطاقًا يملكه من طرفه إلى طرفه، من قاعدة البيانات إلى مناوبة الطوارئ (on-call). الهدف فريقٌ قادر على تسليم معظم عمله دون انتظار أحد. كلّ اعتماد متبادل بين الفرق تُزيله هو اجتماعٌ لن تضطر إلى عقده.

وحدة التوسّع ليست المهندس، بل الفريق القادر على تقديم القيمة دون استئذان.

عامِل الأقدمية بوصفها نظامًا لا لقبًا

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

العلاج متعمَّدٌ ومنهجيّ: تعريفٌ مكتوب لما يفعله كلّ مستوى وظيفي فعلًا، ودفع القرارات إلى أدنى مستوى يملك السياق، وتوثيقٌ يكفي ليجيب الموظف الجديد عن أسئلته بنفسه. في تجاربي المهنية، وجدت أن الفرق التي تتوسّع بسلاسة هي دائمًا تقريبًا تلك التي دوّنت الأمور مبكرًا — قرارات المعمارية، وأدلّة التشغيل (runbooks)، والمنطق وراء المفاضلات. المعرفة الشفهية تتوقّف عن التوسّع عند خمسة عشر شخصًا تقريبًا.

احمِ الإنتاجية التي تملكها أصلًا

كلّ تعيين جديد ضريبةٌ مؤقتة على مهندسيك الحاليين. وإساءة إدماج شخصٍ قد تكلّفك من السرعة أكثر ممّا يضيفه هو في ربعه الأول. زمن الوصول إلى الإنتاجية (ramp) مقياسٌ يستحقّ المتابعة: كم يومًا يمرّ قبل أن يدمج المهندس الجديد شيئًا ذا قيمة في الإنتاج؟

• أتمِت حواجز الأمان. إنّ الـCI والاختبارات والتحقق من الأسلوب (linting) تتيح لك الوثوق بالناس أسرع ممّا يستطيعه مراجِعٌ بشري.
• اكتب الإدماج بوصفه كودًا. ينبغي أن يحصل المهندس الجديد على بيئة عمل جاهزة خلال بعد ظهيرة واحدة, لا أسبوعًا من التنقيب في أرشيف Slack.
• عيّن مسؤولًا لا قناة. كلّ موظف جديد يحتاج إلى شخص واحد باسمه يتحمّل مسؤولية أيامه الثلاثين الأولى.

من أين تبدأ يوم الاثنين

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

التوسّع الجيّد في جوهره انضباطٌ يجعلك تضيف الأفراد أبطأ ممّا تشتهي الأعمال — وتُصلح النظام قبل أن تغمره.

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