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