الجمعة، 25 يوليو 2014

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

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

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

اذن في محاولة لوصف الواقع الذي بين ايدينا في صورة معطيات نستطيع ان نقول:
  •  مدخلات المشروع متغيرة بشكل دائم، حيث ان الصورة الذهنية تستمر في التحسن والنمو كلما بدأ المنتج يخرج الي النور.
  •  كما ان التقنيات المستخدمة تتطور بسرعة، كما اننا نتعامل مع منصات متعددة Frameworks  سواء من حيث البرمجة programming languages او قواعد البيانات او حتى انظمة التشغيل OS، وبطبيعة الحال دورة العمل هي في حد ذاتها دورة مرنة ومتغيرة تعتمد منهج تجريبي Empirical مثل الأسكرم مثلا SCRUM.
  • كما ان الموارد البشربة لديك تختلف في كفاءاتها وقد تتغير مع الوقت وخصوصا لو كان المشروع كبيرا وضخما.
اذن كيف يفترض ان يكون لوضع كهذا عملية تقييم واضحة ودقيقة ومحددة سواء من حيث الزمن او الميزانية !!! :)

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

دعوني اسوق لكم تجرتنا الشخصية داخل شركتنا وفريق عملنا.
عملية التقييم لدينا تمر على المراحل الآتية:
  • تقسيم الرؤية او الأحتياجات الموثقة او الصورة الذهنية المتوفرة الي مجموعة من الأنظمة الفرعية modules and sub-modules
  • وضع تقييم (مالي وزمني) لكل منظومة فرعية.
  • وضع معامل مخاطرة Risk Factor لكل منظومة لتحدد حجم العمل الذي من المتوقع ان يزيد في هذه المنظومة. مثال ذلك، منظومة تسجيل المستخدمينuser registrations  قد لا يتوقع ان يكون لها معامل مخاطرة كبير في معظم الحالات، حيث ان متطلباتها معروفة مسبقا الي حد كبير. في حين ان منظومة تقوم بحسابات مالية وتقارير سيكون لها معامل مخاطرة كبير جدا قد يصل في بعض الأحيان الي 300%. 
  • تقييم المخاطر المتعلقة بفريق العمل لديك. مهارة تنقصك، او مهارة قد تتوقع ان تغادر الفريق اثناء المشروع، وهكذا. 
  • تقييم وضع المشاريع الجاري تنفيذها داخل الشركة ومدى سماحية طاقة العمل لديك على استيعاب مشروع جديد. وبالتبعية تقدير مدى احتياجك لساعات عمل اضافية خارج ساعات العمل الأعتيادية، والتي بدورها تكلف اكثر.
  • معامل مخاطرة مرتبط بانطباعك عن العميل ومدى التزامه بمحددات العمل ومنهج العمل والسداد النقدي، ومرونته في تقبل التغيرات التي ستحدث على خطة المشروع، والتي حتما ستحدث ... الخ. 
  • معامل مخاطرة عام على كامل المشروع. عادة تكون نسبة صغيرة لأنها تتم على كامل المشروع، وتوضع للأطمئنان.
  • معامل الربحية.
استطيع ان اجزم ان مشروعا قد يتكلف التصور المبدئي له 100الف دولار قد يصل في عرضه النهائي الي قيمة بين 300 الف الي 500 الف دولار، في حين ان معامل الربحية سيكون بين 40% الي 70%.

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

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

وللحديث بقية في الجزء الثاني.


هناك 4 تعليقات:

  1. بعض هذه المخاطر يمكن تجنبه باستخدام ال agile contracting methods فهل لديكم خبرات يمكن مشاركتها في هذا المجال؟

    ردحذف
    الردود
    1. متفق معك جدا. لكن ليس كل العملاء مدركون لهذا النموذج او لديهم قدرة على استيعابه. عادة ما يتم توقيع مثل هذه العقود مع شركات برمجيات تعمل معنا بنظام التعهيد outsourcing اما مع الحكومات او القطاع فلم اصادف معهم من يقبل بهذا النموذج.

      هذا مجال واسع ، لو لديك فيه سؤال محدد سأكون سعيدا ان اجيبه ان كان باستطاعتي ذلك
      اشكر لك التفاعل

      حذف
  2. أتفق معك على أهمية هذه النقطة، و كما ذكر Hesham Amin من ضمن الحلول هو استخدام Agile methods في إدارة وتنفيذ المشروع وكذلك التعاقد نفسه ( فكثيرون يغفلون النقطة الأخيرة). لكن سواء هذه الطريقة أو أي طريقة أخرى هناك بعض النقاط من المهم مراعاتها:
    أولاً: عدم تعقيد طريقة أو أداة حساب تكلفة المشروع للدرجة التي تصعب تطبيقها بشكل عملي بصورة صحيحة كما تصعب عملية المراجعة سواء أثناء تقديم العرض أو حتى بداية المشروع.
    ثانياً: استخدام طريقة عملية لتسجيل التكلفة الحقيقية لمكونات المشروع أثناء التنفيذ، فعلى سبيل المثال نجد أن فريق العمل في كثير من المشاريع بشركات عدة، يكتفي بستجيل عدد ساعات العمل بشكل إجمالي على مهمة أو اثنين على المشروع و هذا بسبب أن مدير المشروع أغرق في تفاصيل المهام مما صعب التحديثات على فريق العمل، او العكس تماماً فقد يكتفي بمهمة عامة مثل كتابة الكود أو اللاختبار.
    ثالثاً: قد لا تختلف هذه النقطة في شكلها عن سابقتيها ولكنها مهمة جداً، ألا وهي الواقعية والوضوح في استخدام طريقة حساب التكلفة، فكثيراً - حتى لو كانت طريقة وأداة الحساب بسيطة - يقوم القائم على هذه المهمة بانجازها بشكل غير صحيح أو دقيق بالمرة وتتعدد الأسباب منها ضغط العمل وضيق الوقت، وعدم تطبيق الثواب والعقاب بعد ذلك بناء على مقارنة ما تم حسبه أثناء العرض بما يتم تسجيله أثناء تنفيذ المشروع، كما أن هناك سبب آخر وهو عدم فهم الطريقة أو الأداة وأذكر أنني عملت مع شخص متميز جداً من الناحية التقنية وكان من المفترض أن يقوم بحساب الوقت الللازم للمشروع وذلك عن طريق استخدام function point والتي تعتمد كغيرها من طرق sizing على حساب productivity لمشاريع مماثلة لنفس فريق العمل (موظفي الإدارة مثلاً) ... كل هذا كان يفهمه جيداً لكن تخيلوا ما هي المشكلة؟ انه يحسب الوقت بتقدير مباشر منه ثم يحسب بطريقة عكسية (عكس الطريقة الصحيحة) عدد function points . وجدت المشكلة ببساطة أنها رغم قوته التقنية في مجاله لا يتقن استخدام MS Excel وكان من الواضح ان كان يشعر بحرج أن يذكر ذلك وفي نفس الوقت لم يراها مشكلة ليحلها بنفسه. ولك أن تتخيل كل النتايج التي قد تترتب على استخدام طريقة حساب بشكل خاطئ.
    رابعاً: كثيرا ما يبالغ من يحسب التكلفة في التعامل مع المخاطر. من المهم أن يسرد كل المخاطر بقدر الإمكان لكن بعد ذلك يحسب risk score المعتمد على risk impact و risk probability ليرتب المخاطر تنازلياً على حسب risk score فتكون الميزانية المحجوزة لكل عنصر من تلك المخاطر كنسبة من التكلفة المتوقعة وليس كلها. كمان أن ميزانية المخاطر تكون لأهمها وليس لها كلها، وذلك بتطبيق القاعدة الشهيرة بانك لو تعاملت مع 20% من المخاطر فستحل 80% من المشاكل المتوقعة.

    ردحذف
  3. اتفق معك. خاصة ما ذكرته حول الحذر من الوقوع في فخ التفاصيل .

    ردحذف

Subscribe to RSS Feed Follow me on Twitter!