أين يضيع الوقت فعلا
أكبر مسرّع لإطلاق البرمجيات الذي وجدناه ليس framework جديد، ولا CI أسرع، ولا منهجية سحرية. إنما تنظيم الناس بالشكل الصحيح حول المشكلة — والثقة فيهم لتسليم العمل.
لسنوات، اعتمدنا على الهيكل التقليدي: فريق تصميم، فريق هندسة، ومدير مشروع يربط بينهم. الـ Handoffs بتحصل في Figma، المواصفات في Linear، والمهندسون يترجمون mockups لكود. كانت بتشتغل، لكن كل انتقال يضيف احتكاك. مصممون ينتظرون مهندسين. مهندسون ينتظرون توضيحات. الشغل يتحرك بمحاولات متقطعة.
“السرعة جاءت من تقليل حلقات الانتظار، لا من مطالبة الناس بالعمل أكثر.”
كيف يغير الـ pod دورة العمل
من سنتين، أعدنا الهيكلة. بدل أقسام، بنينا pods — من ثلاثة لخمسة أشخاص لكل pod، يجمع بين مهندسين كبار، مصمم منتج، وقائد منتج. الـ pod بيمتلك جزء من المنتج من البداية للنهاية. يحدد النطاق، يصممه، يبنيه، يطلقه، ويراقب التليمتري.
النتائج فاجأتنا حتى نحن. السرعة تضاعفت تقريباً، ليس لأن أحداً اشتغل أكتر، بل لأن round-trip latency بين نية التصميم والكود المُسلّم انهار. مصمم يلاحظ مشكلة قابلية استخدام أثناء البناء، يطرحها في Slack channel للـ pod، ومهندس يعدّل في الصباح التالي. لا تذاكر. لا handoffs. لا اجتماعات حالة.
متى ينجح هذا النموذج
الـ Cross-functional pods ليست رصاصة فضية. تطلب أكتر من المساهمين الفرديين — مهندسين يفكرون في تنازلات التصميم، مصممين يفهمون القيود التقنية، وكل واحد يحتاج يتواصل. لكن للشغل الموجّه نحو المنتج، خاصة في مرحلة 0-to-1، لم نجد طريقة أسرع للبناء.
لو فريقك صغير وحاسس بطء، انظر بعناية إلى كيفية عمل الـ handoffs. المشكلة عادة ليست في الناس. بل في الحدود بينهم.
حوّل الفكرة إلى خطة تنفيذ
أرسل لنا المنتج أو المشكلة التي تريد تحسينها، وسنرد بخطوة عملية واضحة خلال 24 ساعة.
