عندما لم تكن «احتياجات اليوم» كافية لعام كامل؛ تجربة في تحليل برنامج للتأمين

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

تتعلق التجربة التي تقرأها هنا بمشروع في مجال بيع التأمين؛ وهو مشروع أظهر لي من خلال التغييرات المستمرة في نموذج احتساب العمولات أن تحليل المتطلبات لا يعني فقط فهم احتياجات اليوم، بل ينبغي أيضًا، قدر الإمكان، أخذ التغييرات المحتملة في الأعمال مستقبلًا في الاعتبار.

في هذا المشروع طُلب مني تصميم نظام لإدارة التسويق والمبيعات بالعمولة.

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

في بداية المشروع، كان عدد المسوقين محدودًا؛ لكن فكرة الشركة كانت أن تتوسع شبكة المبيعات بشكل مستمر من خلال تنفيذ خطط تحفيزية وزيادة الدافع لدى المسوقين.

سؤال مهم طُرح قبل بدء المشروع

كان لدى العميل في بداية المشروع نموذج محدد لاحتساب العمولات والمكافآت، وكان يتوقع أن يقوم البرنامج بتنفيذ هذا النموذج.

لكن بالنسبة لي كان هناك سؤال أهم:

إذا لم ينجح هذا النموذج عمليًا كما نتوقع، فما الذي يجب أن يفعله البرنامج؟

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

ولهذا السبب، وقبل تحديد السعر وبدء التطوير، عقدت حوالي 10 جلسات عمل مع العميل والخبراء الفنيين، من أجل دراسة وتحليل احتياجات المشروع وتفاصيله.

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

أدى هذا التحليل إلى تصميم البرنامج منذ البداية مع مراعاة إمكانية تغيير وتطوير نماذج احتساب العمولات.

عندما يتغير النموذج في العالم الحقيقي

وكما توقعت خلال مرحلة التحليل، تغيّر نموذج احتساب العمولات والمكافآت عدة مرات خلال عام واحد، وفي كل مرة كان يتم تعديله وتحسينه استنادًا إلى النتائج التي تم الحصول عليها.

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

لكن أحد القرارات المهمة في التصميم الأولي كان أن يتم الاحتفاظ بكل إصدار من النموذج والقواعد المرتبطة به إلى جانب سجلات الفترات السابقة.

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

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

لماذا كانت دقة الحسابات مهمة؟

كان من المقرر دفع عمولات المسوقين في بداية كل شهر. لذلك لم يكن النظام مجرد أداة لتسجيل البيانات؛ بل كانت مخرجاته مرتبطة مباشرة بالمدفوعات المالية لأعضاء الشبكة.

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

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

في الواقع، لم يكن المطلوب من البرنامج مجرد تنفيذ معادلة ثابتة؛ بل كان يجب أن يكون بنية تحتية قادرة على التطور بالتزامن مع تغير نموذج الأعمال وتطوره.

تجربة أظهرت أهمية التحليل الأولي بشكل أوضح

طرح مدير هذه المجموعة لاحقًا نقطة جديرة بالتأمل حول تجربته في اختياري لتنفيذ المشروع.

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

بعد فترة، اتصل بي شخص آخر وقال إن مجموعتهم نفذت أيضًا مشروعًا مشابهًا مع فريق برمجي آخر. لكن بعد مرور عدة أشهر، واجهوا مشكلات في النظام، وتراجعت شبكة المبيعات لديهم.

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

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

ما الذي تعلمته من هذه التجربة؟

أوضحت لي هذه التجربة نقطة مهمة بشكل أكبر:

تحليل البرمجيات لا يعني فقط إعداد قائمة بالوظائف المطلوبة اليوم؛ بل ينبغي، قدر الإمكان، أخذ التغييرات والاحتياجات المحتملة في المستقبل في الاعتبار عند التصميم.

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

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

ولهذا السبب، فإن أحد أهم الأسئلة التي ينبغي طرحها قبل بدء تطوير أي مشروع برمجي ليس:

«ماذا نريد اليوم؟»

بل:

«إذا تغيرت احتياجاتنا غدًا، فما مدى قدرة هذا البرنامج على التغيير؟»