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