عند الحديث عن مشاريع البرمجيات، هل سبق لك أن رأيت كيف تصف شركات تطوير البرمجيات أو شركات تصميم خدمات البرمجيات مشروعًا؟ بعد قراءة وصفهم، هل يمكنك بسرعة فهم متطلبات المشروع والخلفية بشكل واضح؟

الطريقة الشائعة لوصف مشاريع البرمجيات عادة ما تتضمن النقاط الأربع التالية:

مقدمة عن صناعة العميل

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

المشكلات التي تواجهها في عملية العمل (مكان الحاجة)

هذا هو الدافع الأكبر لظهور العميل، فما هي المشاكل التي يواجهها العميل في بيئة عمله؟ هل تحتاج العمليات الحالية إلى التحول الرقمي، أو هل يحتاج النظام الحالي إلى إعادة تنظيم بعد سنوات من الاستخدام، أو هل هناك حاجة لاتخاذ تدابير رقمية استجابة للاتجاهات الجديدة في الصناعة؟ هنا، من الضروري فهم الوضع الذي يواجهه العميل بموضوعية ومن منظور العميل.

الحلول المقترحة

بعد التوصل إلى توافق مع العميل، تقدم شركة البرمجيات تخطيطًا وتنفيذًا مخصصًا يلبي المتطلبات بنجاح ويمكن تطبيقه في عملية عمل العميل.

النتائج

بالمقارنة مع الحلول القديمة، بعد تطبيق الحل الجديد، يتم تقديم استنتاج موضوعي حول الفرق والتغيير الذي أحدثه للعميل، مثل: تحسين كفاءة عملية الإنتاج، تقليل وقت تجميع المعلومات، توفير قنوات جديدة للوصول إلى العملاء...

من خلال الجمع بين النقاط الأربع المذكورة أعلاه حول وصف مشاريع البرمجيات، يمكننا الحصول على فهم أولي للمشروع. وخلال عملية المناقشة مع العميل، يجب على مدير المشروع التأكد من أن هذه الأوصاف واضحة في أذهاننا. لأن وصف مشروع البرمجيات مرن، يمكن أن يكون قصيرًا بحيث يصف المشروع في جملة واحدة، أو طويلًا بحيث يتضمن تقريرًا يصف محتوى المشروع. في هذه الحالة، يمكن المحاولة:

إنشاء "قيمة أساسية"، بحيث يمكن لهذه القيمة الأساسية أن تحدد نطاق المشروع

المشروع هو مشروع لأنه يحقق هدفًا محددًا بموارد محدودة. ومع ذلك، في عملية تحقيق الهدف المحدد، إذا لم يكن هناك تحديد للنطاق، فقد تظهر وظائف "ذات صلة". قد تضيف هذه الوظائف ذات الصلة قيمة كبيرة للحل الكامل، ولكنها قد تتطلب وقتًا أطول للتطوير، مما يؤدي إلى عدم القدرة على الإطلاق في الوقت المحدد؛ أو قد لا تضيف في الواقع أي تأثير ملموس للحل الكامل.

مثال:

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

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

في إطار زمني محدود للتطوير، ماذا نفعل عندما تتعارض وظائف التطوير مع واجهة النظام المتوقعة من العميل؟

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

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

وفقًا لكل مشروع، حدد "القيمة الأساسية" الأكثر ملاءمة مع العميل أثناء المناقشة

القيمة الأساسية للمشروع، تتيح لنا سواء كنا في مناقشة فريق التطوير، أو في مقابلة مع العميل أو عند القبول، أن نكون كما لو أننا بنينا منارة، تقودنا في بحر المناقشات الواسع، دون الانحراف عن الموضوع، والعودة إلى محور المشروع لمناقشته.

إذا كنت تقرأ المقال اليوم وأنت تعاني من الطلبات التي قدمها العميل، فلماذا لا تدرج القيمة الأساسية للمشروع لإقناع نفسك والعميل!