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