- أرباع السنة تخبي التراخي. الأسابيع تفرض الوضوح — نطاق ضيق، قرارات سريعة، شي حقيقي بحلول الجمعة.
- سر التسليم السريع مو العمل بشكل أسرع، بل تحديد نطاق أصغر والتوسّع لما يصير فيه زخم.
- التواصل غير المتزامن أولًا (تحديثات يومية، معاينات الجمعة) يرجّع الساعات اللي الوكالات تدفنها باجتماعات الحالة.
- ثلاثة عشر شخص سينيور، صفر مبتدئين مخفيين — اللي يحددون نطاق الشغل هم نفسهم اللي يبنوه.
- نسلّم عشان نتعلم، مو عشان نكون مثاليين. نسخة أولى مُطلقة تعلّمك أكثر بأسبوع من مواصفة تعلّمك بربع سنة.
ربع السنة هو العدو
أغلب الوكالات تسعّر بأرباع السنة لأن أرباع السنة تخبي التراخي. جدول زمني مدته ثلاثة أشهر يقدر يستوعب كثير من التردد — موافقة بطيئة هنا، رسالة سلاك فاتت هناك — بدون ما يظهر أبدًا بتقرير الحالة. محد يلاحظ الانحراف لين يصير الموعد النهائي بعد أسبوع ونص النطاق لسا مو محسوم.
إحنا نسعّر بالأسابيع بدل هذا، لأن الأسابيع ما تسيب مجال لهالنوع من الانحراف. جدول زمني مدته أربع أسابيع يفرض نقاش النطاق يصير باليوم الأول، مو الأسبوع العاشر. أحيانًا العملاء يترددون بالبداية — يحسّونها عدوانية مقارنة بالي متعودين عليه — بس هذا القيد هو اللي يخلّي كل شي بعده أسرع.
النطاق مشكلة تصميم
سر التسليم السريع مو العمل بشكل أسرع — بل تحديد النطاق بذكاء. أغلب المشاريع تفشل بالجدول الزمني مو لأن الفريق كان بطيء، بل لأن النطاق كان يكبر بهدوء بينما الكل متفق إنه 'نفس الشي تقريبًا'. إحنا نتعامل مع توسّع النطاق كفشل تصميمي، مو فشل من العميل.
فنقلّص المشروع لأصغر شي يقدر يسلّم قيمة حقيقية، نسلّمه، وبعدين نوسّع. بناء CRM يبدأ بثلاث سير عمل هي الأهم، مو الاثنا عشر اللي أحد رسمهم على السبورة. أغلب العملاء يبدؤون بنطاق ضيق ويكبّرون المشروع لما يشوفون الزخم — وهذا نمط نمو أصح بكثير من البداية الواسعة وتقليص النطاق تحت ضغط الموعد النهائي.
غير المتزامن أفضل من الاجتماعات
نشتغل بأسلوب غير متزامن أولًا: تحديثات Loom يومية، معاينات الجمعة، وسجل قرارات مكتوب يقدر أي أحد بالفريق يراجعه بدون ما يزعج أحد. الاجتماعات تصير بس لما التواصل غير المتزامن فعليًا يفشل — عادة مرات قليلة بكل مشروع، مو موعد أسبوعي ثابت.
هذا وحده يرجّع الساعات اللي الوكالات تدفنها باجتماعات الحالة. مزامنة أسبوعية مدتها 30 دقيقة عبر مشروع مدته أربع أسابيع تعني ساعتين من وقت شخص سينيور كان ممكن تروح للبناء الفعلي. اضربها على الفريق كامل والتوفير يتراكم بسرعة.
سينيور بس، بدون تسليم وتسلّم
إحنا ثلاثة عشر شخص وما فيه مبتدئين مخفيين خلف مدير حساب. اللي يحددون نطاق الشغل هم اللي يبنونه. هذا مو فلسفة توظيف لحد ذاتها — هو حل مباشر لأكثر نمط فشل شائع بشغل الوكالات: الشخص اللي فهم مشكلة العميل الحقيقية مو نفس الشخص اللي بينتهي يكتب الكود.
تسليم وتسلّم أقل يعني تفاصيل أقل تضيع وإعادة شرح أقل بكثير. نادرًا ما يضطر العميل يكرر السياق مرتين، لأن نفس الشخصين أو الثلاثة موجودين من الانطلاقة للإطلاق.
سلّم عشان تتعلم
إحنا ما نسلّم مثالي — نسلّم قابل للتعلم. حطّه قدام مستخدمين حقيقيين، قِس، وطوّر. نسخة أولى مُطلقة تعلّمك أكثر بأسبوع من مواصفة تعلّمك بربع سنة، لأن الاستخدام الحقيقي يكشف الافتراضات اللي محد فكّر يسأل عنها باجتماع التخطيط.
هذا كمان ليش 'الإطلاق' مو خط النهاية داخليًا — هو النقطة اللي أهم البيانات تبدأ توصل فيها. الفرق اللي تتعامل مع الإطلاق كنهاية تميل تتوقف عن الانتباه بالضبط بالوقت اللي لازم فيه ينتبهوا أكثر.