ملحمة تسعير البرمجيات - الجزء الثاني

هذا هو الجزء الثاني لمقالة سابقة اسميناها "فرضيات مؤلمة حول ملحمة تسعير البرمجيات الدامية - الجزء الأول"

 سأتكلم في هذا المقال عن بعض اساليب التقييم والتقدير والتي انتهجناها في شركتنا على مدار اكثر من 10 سنوات وكيفية تطورها عبر هذه السنين.

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

الكثير منا درس في الكليات بعض التقنيات في عملية التقييم والمرتبطة بتصور عدد تقريبي لسطور الكود، وتكلفة سطر الكود في بعض اللغات ومن ثم حساب تكلفة المشروع كاملا !. هذه الوسيلة لم اجربها بشكل عملي، لكني لم احاول لأني مقتنع -على المستوى الشخصي- انها غير عملية في اللغات والمنصات الشائعة الآن ، وانها وسيلة تراثية ، قد تصلح مع من يبرمج بلغة مثل ++C مثلا، فضلا عن كونها تغفل مدى مهارة المبرمج واحترافيته كعامل في التقييم. ولا اتصور ان احد يعمل بها الآن.

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

1. فريق العمل المبتدئ تنقصه الخبرة في كيفية جمع الحد الأدنى من المتطلبات الوظيفية والتي سيبني عليها التقييم بعد ذلك، كما ينقصه خبرة توثيق هذه الاحتياجات حتى لو كان يعمل بمنهج مرن Agile.
   انصح القارئ بمشاهدة سلسلة سيناريو الحوار. فهي توضح كيفية كتابة الأحتياجات بشكل يساعد على التقييم ويفهمه العميل.
2. فريق العمل ينقصه خبرة تقييم المخاطر المرتبطة بأكثر من عامل مثل العميل، المشروع، طبيعة المتطلبات الوظيفية...الخ
3. فريق العمل غالبا ما تنقصه الخبرة في تقييم وحساب المصروفات الأدارية والنثرية والضريبة على المشروع. سنفرد لها مقالة خاصة.
4. اخيرا فأن الفريق سيجد ان المشروع قد واجه مشاكل قد تصل في معظم الأحيان الي الفشل في عاملي الزمن والميزانية، وغالبا لن يكون قادرا على تحديد اسباب الفشل بدقة، وسيعزيها بشكل عام دون تدقيق الي خطا في الحسابات.

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

التقييم وفقا لنموذج معياري.

في هذا النموذج قمنا بتحليل منظومة لنشر الأخبار على صفحة ويب News management system وهي منظومة تحوي بعض التقنيات والاحتياجات متوسطة التعقيد، وقمنا بتقييم جهد التحليل، وجهد البرمجة والأختبار بشكل دقيق جدا. هذا التقييم انتهى لعدد ساعات عمل محددة وتكلفة محددة. استخدمنا هذا التقييم على اعتبار انه وحدة، رمزنا لها بالرمز N .

اي مشروع يأتي الشركة يتم تكسير الأحتياجات الوظيفية له في صورة منظومات صغيرة small modules يقاس حجمها بوحدة الN. وبالتبعية يكون من السهل معرفة التقدير الزمني والنقدي لها.

في رأيي، التقييم وفقا لنموذج معياري رائع جدا ومناسب جدا، لكنه يحده بعض الأشياء مثل:

•  مرتبط بفريق عمل صغير لا تتغير عناصره، لأن معايرة الوحدة N تتم وفقا لأمكانيات فريق محدد، فلن يستقيم المعيار ان دخل فرد جديد للفريق او نقص فردا.
• الفريق نفسه امكانياته تتحسن مع الوقت، فيفترض دائما ان تقوم بمعايرة النموذج مرة اخرى، على الأقل مرة كل عام.
• اذا تغيرت ادوات الفريق فلابد ايضا من اعادة معايرة النموذج او بناء نموذج معياري اخر.
• النموذج هنا لم يتضمن بعض المصاريف الأدارية مثل جهد مدير المشروعات، ورجال البيع، والمحاسب ...الخ. لذلك فهو كما ذكرنا يصلح لفرق العمل الصغيرة التي لا يكون لديها اكثر من 3 مشاريع في نفس الوقت، او لايزيد حجم العمالة فيها عن 20 فرد مثلا.

--------

حين تكبر الشركة ويكون باستطاعتها الحصول على مشاريع اكر تعقيدا، مع جهات حكومية مثلا، فلا بد ان ينتهج منهج التقييم المرن او الـ Agile estimation.  هذه الوسيلة تحتاج لكتيب صغير لشرحها، وسأنوه عنها في هذه السطور.

التقييم المرن ( Agile Estimation )

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

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

يقوم المدير بطرح النقاط المعقدة في المشروع نقطة نقطة، ويتم التصويت على مدى تعقيد هذه النقطة وفقا لمقياس محدد لا وحدة له.

هذا المقياس عادة مايكون متسلسلة Fibonacci .

يقوم المحللanalyst  او مدير فريق العملteam leader او مدير المنتج او المشروع project manager or product manager بقيادة جلسة التقييم، حيث يشرح المتطلب الوظيفي ما امكنه ان يفعل، ثم يطلب من كل فرد في الفريق ان يقيم هذا المتطلب وفقا لرؤيته وباستخدام مقياس Fibonacci

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

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

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

وفيما يلي بعض الملاحظات على هذه الطريقة:

• تستغرق وقتا طويلا جدا، وتتطلب اكبر عدد من فريق العمل ان يكون متواجدا ومشاركا.
• لكنها دقيقة الي حد كبير.
• لايمكن ان تستخدم هذه الطريقة على كامل احتياجات المشروع، لأنك لن تنتهي (تستهلك وقت طويل)، وانما تستخدم في تقييم الأحتياجات المعقدة.
• هذه الطريقة لها مميزات اخرى في تقييم سرعة فريق وتوقع ما اذا كان المشروع سينتهي في الوقت المحدد ام قبله ام بعده، وذلك من خلال وحدة ال Story points (ليس هذا مكان شرحها). سأحاول ان افرد مقالا حول جدوى التقييم من خلال الــ Story points في القريب ان شاء الله.

 التقييم وفقا للـ Agile estimation هو الطريقة الأكثر نجاحا مؤخرا وفقا لكثير من اوراق البحث المنشورة على الأنترنت. التقييم وفقا لنموذج معياري، هي طريقة تم ابتكارها داخل شركتنا، لم نقرأ عنها مسبقا، وانما تولدت مع الوقت والتجربة والخطأ.

لو كنت الخص هذا المقال في جملتين لقلت.

 " عملية التقييم:

 عملية جماعية = لا تقم بها منفردا.

عملية تجريبية = استفد من تجاربك السابقة وادرسها جيدا "

في مقال قادم سأتحدث عن كيفية تقييم التكاليف الغير مباشرة على مشاريع البرمجيات.