بناء المنتج لعبة جماعية: كيف ينتقل العمل فعليًا داخل Omnexa

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

المنتج لا يبدأ بمهمة… يبدأ بشكوى

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

صفحة واحدة قبل أول سطر كود

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

التصميم والهندسة يختلفان مبكرًا… عن قصد

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

نقسّم العمل حتى يبقى التقدم مرئيًا

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

السياق أولًا… ثم المهمة

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

حين ينكسر شيء، سرعة المعلومة أهم من البحث عن مذنب

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

المراجعة والاختبار: أن تكون مخطئًا مبكرًا شيء رخيص

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

الإصدار نقطة مراجعة… لا خط نهاية

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

حماية الفريق من كل ما هو "عاجل"

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

دائرتا تغذية راجعة: واحدة للمنتج وأخرى للناس

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

ما تعلمته فعلًا من بناء المنتجات مع فريق

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