دراسات حالة

مدير تقني جزئي: تحويل مشروع فينتك متعثّر إلى خارطة طريق قابلة للتنفيذ

كيف ساعد مديرٌ تقني جزئي شركة فينتك في جولة Series A على تقليص النطاق وتبسيط البنية وتحويل ثلاثة مواعيد إطلاق فائتة إلى إصدار يستخدمه العملاء يوميًا.

MA
محمود الحرازيناستشارات الأمن والذكاء الاصطناعي
Nov 2024· 4 دقيقة قراءة
شارك

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

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

الوضع كما وجدناه

جمعت الشركة تمويلها اعتمادًا على عرضٍ تجريبي مقنع وزاويةِ دخولٍ حقيقية: مدفوعات عابرة للحدود موجَّهة للشركات الصغيرة التي أهملها اللاعبون الكبار. وحين وصلنا، كان المهندسون الثمانية عشر موزَّعين على أربعة فرق (squads)، يعمل كلٌّ منها بإيقاعه الخاص. لم يكن هناك مدير هندسة؛ فالرئيس التنفيذي يحسم نقاشات البنية بين اجتماعٍ وآخر، وتحوّل أقدمُ مهندسي الـ backend بهدوء إلى بوّابة يمرّ منها كل إصدار.

كانت خارطة الطريق تحمل ثلاثة مواعيد إطلاق موزَّعة على تسعة أشهر، تأجّلت جميعها. ولم يكن أحدٌ قادرًا على تفسير السبب بدقة، لأن كلمة «مُنجَز» كانت تعني شيئًا مختلفًا لدى كل فريق، ولأن أول إصدارٍ قابل للشحن لم يُكتَب يومًا بوصفه هدفًا واحدًا متّفقًا عليه.

أين كان الخلل فعلًا

ثلاث مشكلات كان بعضها يغذّي بعضًا. أولًا، تضخّم النطاق: صار الـ MVP يضمّ محافظ متعددة العملات، وواجهة API عامة للشركاء، ولوحة تحكّم للتجّار — كلٌّ منها مبرَّر بمفرده، ولا واحد منها ضروريًا لأول عميل يدفع. ثانيًا، انحراف البنية: قرارٌ مبكر بتبنّي الـ microservices أنتج سبع خدمات حيث تكفي اثنتان، فصارت كل ميزة تمسّ ثلاثًا منها، وبات الدمج (integration) متأخّرًا ومؤلمًا دائمًا. ثالثًا، غياب إيقاعٍ مشترك: فمن دون تعريفٍ واحد لـ«الجاهز» و«المُنجَز»، حسّن كل فريق أداءه محليًا، ولم تلتقِ الفرق إلا في النهاية — وهي بالضبط اللحظة التي تطفو فيها المشكلات الصعبة.

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

كيف تعاملنا مع الأمر

منحنا أنفسنا أسبوعين لفهم المنظومة قبل أن نمسّها.

الإنصات قبل إعادة الهيكلة

تحدّثنا مع كل مهندس على انفراد، وحضرنا تخطيط كل فريق، وراجعنا آخر ثلاثة أشهر من طلبات الدمج (pull requests) والحوادث. أردنا خريطة الاعتماديات الحقيقية، لا تلك المدوَّنة على الـ wiki.

إعادة رسم خطّ أول إصدارٍ صادق

عملنا مع المؤسّس على تعريف إصدارٍ واحد يستطيع عميل حقيقي استخدامه، وشطبنا كل ما لا يخدمه. انتقلت المحافظ وواجهة الشركاء إلى خانة «لاحقًا، عن قصد» — ظاهرة للعيان، غير محذوفة.

تبسيط البنية في مكانها

بدل إعادة البناء، أعدنا دمج الخدمتين الأكثر «ثرثرة» في واحدة، ورسمنا حدًّا صارمًا حول دفتر قيد المدفوعات (ledger) حيث تكون الصحّة الحسابية أهمّ ما يكون.

ترسيخ إيقاعٍ يملكه الفريق

تعريفٌ واحد مشترك لـ«الجاهز» و«المُنجَز»، ونقطة تحقّق أسبوعية للدمج، واعتماد feature flags كي يُدمَج العمل غير المكتمل من دون أن يعطّل أحدًا.

ما فعلناه على أرض الواقع

خلال الشهرين التاليين أدرنا برنامجًا محكمًا وواضحًا. عيّنّا قائدَي فريق من داخل الصفوف ومنحناهما صلاحيات قرارٍ فعلية، ما أخرج المؤسّس من نقاشات البنية اليومية. وقلّصنا الخدمات من سبعٍ إلى نواةٍ من ثلاث زائد اثنتين مساندتين، ونقلنا دفتر القيد إلى فريقٍ واحد يملكه. وأنشأنا بيئة staging لائقة وخط CI يعطي إشارة صادقة، فلم يَعُد «اكتمال الكود» يعني «الآن يبدأ الألم». وأدخلنا feature flags لفصل النشر عن الإطلاق. وكتبنا صفحة واحدة للاستراتيجية التقنية يقرؤها مجلس الإدارة في خمس دقائق — وكانت أول وثيقة يثق بها الجميع، بمن فيهم المؤسّس.

إلى أين انتهى الأمر

المؤشرقبلبعد
من اكتمال الكود إلى الإنتاجنحو ثلاثة أسابيعأقل من أسبوع
الخدمات في المسار الحرجسبعثلاث
الفرق التي تفي بالتزام الـ sprintنحو واحدة من ثلاثنحو ثلاث من أربع
أول إصدار قابل للاستخدام من العميلبلا تاريخ، تأجّل ٣ مراتصدر خلال ~١٠ أسابيع
الإصدارات المُصعَّدة إلى المؤسّسمعظمهانادرة

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

ما صنع الفارق

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

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

شارك
★ عن الكاتب
MA

محمود الحرازين — استشارات الأمن والذكاء الاصطناعي. يساعد المؤسسات والفرق التقنية على تحويل الأنظمة المعقّدة إلى بنية آمنة وموثوقة وقابلة للتوسّع — من الفكرة حتى التشغيل.

«يتحدّث إليك خبيرٌ مباشرةً. نطاقٌ وسعرٌ واضحان، وتنفيذٌ سريع.»
احجز استشارة

مكالمة 30 دقيقة · بدون التزام

ALHARAZIN

قيادة التحول الرقمي من خلال بروتوكولات الأمن السيبراني المتقدمة وابتكارات الذكاء الاصطناعي. جسر يربط بين التقنية المعقدة والإدارة الاستراتيجية للأعمال.

© 2026 محمود الحرازين. جميع الحقوق محفوظة.