‏إظهار الرسائل ذات التسميات سكرم. إظهار كافة الرسائل
‏إظهار الرسائل ذات التسميات سكرم. إظهار كافة الرسائل

الخميس، 25 فبراير 2016


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

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

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

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

اقرأ ايضا:

الأحد، 17 يناير 2016

هل تدرك مدى خطورة هندسة البرمجيات ... هل تدرك مدى تداخلها في انشطتنا اليومية ...

الطائرة البوينج تحوي على اكثر من 6 مليون سطر كود
السيارات الحديثة تحوي تقريبا نفس العدد من سطور الكود
انظمة المستشفيات والبنوك ونظم ادارة المنازل الحديثة ...

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

خطأ برمجي في برنامج ادارة بنوك الدم تسبب في اختلاط اكياس الدم المصاب بأمراض خطيرة بأكياس الدم السليمة، مما تتسبب في اصابة اكثر من 25 حالة بأمراض خطيرة مزمنة قبل اكتشاف المشكلة !!

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


الثلاثاء، 17 نوفمبر 2015


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

مبدئيا المشاريع المحروقة هي:

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

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

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

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

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



انصح ايضا بقراءة 




الجمعة، 6 فبراير 2015



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

تعد هذه ميزة مهمة من مميزات الأسكرم، فتلك المرونة نحتاجها بشدة حتى نستطيع التكيف مع المسلمات الصعبة لمجال البرمجيات (راجع مقالي حول مسلمات العمل في البرمجيات). نحتاج ان نطور من دورة العمل واجراءاتها متى شئنا وبمرونة.
لذلك توصف دورة العمل في الأسكروم، بأنها دورة تجريبية Empirical وليست دورة محددة. حيث اننا دائما ما نعقد اجتماعات لنأخذ منها تعليقات ومعلومات لنحسن بها دورة العمل.
  • اجتماعات دائمة بين مدير المنتج وفريق العمل والعملاء لفحص مخزن الاحتياجات Product backlog بشكل دائم لإعادة ترتيب اولويات التنفيذ واضافة المزيد من التفاصيل، وحذف ما تم الغاءه.
  • اجتماعات التخطيط للخطوة القادمة، والخطوة بطبيعة الحال مدتها بين 10 ايام و30 يوما كحد اقصى، وبالتالي فهناك تدارك سريع لأي مشكلة في الأحتياجات.
  • اجتماعات الأسكرم اليومية، وبها يتم تدارك اي مشكلة في التنفيذ او في فريق العمل.
  • اجتماعات مراجعة الخطوة، وفيها يتم تقييم العمل الذي كان قد تم التخطيط له من قبل.
  • اجتماعات مراجعة دورة العمل، وفيها يتم تدارك اي اخطاء في اجراءات دورة العمل.
لهذا كله يعد اطار الأسكرم اطار تجريبي، لأنه حيوي ومتجدد دائما. ولأنه كذلك فلابد ان يكون هناك ضوابط لتلك الحرية من خلال مجموعة من القيم والمبادئ ... سنحصرها الآن ونفصلها لاحقا.
قيم ومبادئ الأسكرم.
  • التغير والشك.
  • التوقع والضبط.
  • التحقق من المعلومات.
  • قيد التنفيذ.
  • التقدم والأنجاز.
  • الحفاظ على الأداء.
  • التركيز.
  • الأحترام.
  • الثقة.
  • الألتزام.
في التدوينات القادمة نتناول تفاصيل كل مبدأ ان شاء الله.

الأحد، 1 فبراير 2015

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

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

الأدوار الوظيفية:

جاء اطار عمل الأسكروم ليركز على دورين وظيفيين اساسيين هما:
  • مالك المنتج Product owner
  • مدير الأسكروم Scrum master.
ويدع لك حرية التصرف في اي دور وظيفي اخر تحت مسمى فريق التطوير.
مالك المنتج: هو تقريبا محلل الأعمال Business analyst وملكيته للمنتج جاءت من معرفته التامة بكل تفصيلة فيه، وهو دائم القيام بأعمال تحليلية على خصائص المنتج (عملية النكش) ، حيث يضيف او يحذف خصائص، يعيد ترتيب اولوياتها، يقيمها، ... الخ.
مدير الأسكروم: هو تقريبا مدير المشروع، ودوره انه منسق عام. حيث يحل مشاكل الفريق، ويتعامل مع اي عقبة ادارية، وينسق الأجتماعات، ويتابع تقدم العمل وحجم الأنجاز، ... الخ
وسنوافيكم بالمزيد قريبا في المحاضرات القادمة ان شاء الله.

العمليات:

  • النكش Grooming : وهي التي يقوم فيها مالك المنتج بنكش مخزن الآحتياجات لأضافة خصائص او الغاء اخرى او اعادة تقييم خصائص او ترتيب اولوياتها.
  • التخطيط للخطوة sprint planning: يتم فيها فحص بعض عناصر المخزن ذات الأولوية العالية، واختيار بعضها ليتم تنفيذها في دورة العمل ( الخطوة Sprint) القادمة
  • تنفيذ الخطوة: حيث يقوم فريق التطوير بعمليات البرمجة والأختبار وكل ما يلزم لأنهاء المهام التي تم الأتفاق على تنفيذها في عملية التخطيط للخطوة.
  • اجتماع الأسكرم اليومي: وهو اجتماع موجز لايزيد عن 15 دقيقة بين كل اعضاء الفريق. اذا كان الأجتماع صباحي، يقوم فيه كل فرد بذكر ما قام به بالأمس وماسيقوم به اليوم واذا كان لديه اي مشاكل.
  • مراجعة نتائج الخطة Sprint Review: وهو الأجتماع الذي يتم في نهاية دورة العمل، ويتم فيه مراجعة العمل الذي كان مخطط تنفيذه في خطوة (التخطيط للخطوة) ... هل تم بناء كل شئ كما هو مطلوب، هل هناك اخطاء ... الخ.
  • مراجعة اجراءات الخطوة Sprint Retrospective: وهو اجتماع يتم فيه مناقشة اي خلل او تعديل مقترح على اجراءات العمل، وسنأتي له تفصيلا لاحقا.

العناصر:

  • مخزن الأحتياجات Product Backlog.
  • مخزن الخطوة او التشغيلة Sprint Backlog.
  •  الجزء من المنتج الذي تم تنفيذه.



الأربعاء، 28 يناير 2015



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

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

هذا هو الدرس الرابع في دورة احتراف الأسكرم (اسكروم) ... حيث نلخص الدروس الثلاثة السابقة من خلال دراسة حالة واقعية ومثيرة.
اترككم مع دراسة الحالة ...

الجمعة، 23 يناير 2015



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

مسلمات قطاع البرمجيات...

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

الثلاثاء، 20 يناير 2015


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

الواقع الذي لا يمكن انكاره هو ان نسب النجاح في المشاريع البرمجية والتي تعمل بنموذج الشلال waterfall model ضعيفة جدا، وفي احسن الأحوال فأن المشروع قد ينجح في تحقيق اهدافه، ولكن بعد ان خرج عن الوقت المحدد له والميزانية المرصودة!!

في اطار محاولاتنا لتشخيص المشكلة ... دعونا نتذكر الشكاوي التي نسمعها حين نقوم بتسليم المشروع للعميل:
  1. النظام لا يلبي احتياجاتنا: وهي شكوى تعكس مشكلة في الأحتياجات Requirements سواء كانت في طريقة جمعها او توثيقها او توصيلها للعميل والتأكد من كونه مستوعبا لها على الوجه الصحيح الكامل.
  2. المشروع تأخر وتجاوز الميزانية: وهي شكوى تعكس مشكلة في الأدارة. ادارة توقعات العميل فيما يخص خواص النظام او ميعاد تسليمه، او شكل تسليمه او ميزانيته، ادارة مواردك الفنية والأدارية، ...الخ.
  3. المشروع مختلف تماما عما توقعته ان يكون: وهي شكوى تعكس مشكلة في التواصل مع العميل والتاكد من فهمه الصحيح لوثيقة الأحتياجات.
  4. النظام غير مرن وصعب في الأستخدام: مشكلة في قابلية الأستخدام Usability.
  5. لايمكننا العمل على النظام بشكل جيد داخل بيئة عملنا: وهي شكوى تعكس مشكلة في طريقة تريب البرنامج Deployment او في ثقافة المكان، او في التدريب.
  6. النظام ملئ بالمشاكل Buggy: مشكلة في الكود او في توثيق الكود او في معمارية النظام Architecture .
من ناحية اخرى فهناك مشاكل نواجهها دخل فريق العمل، فكثيرا ما نسمع الآتي:
  1.  لم نستوعب بشكل كافي المطلوب منا، ولم نفهم بشكل كافي منطق النظام Business logic ، ولم يكن لنا صلاحية على وثيقة الآحتياجات.
  2. لم نستطع جمع معلومات كافية تمكننا من بناء النظام.
  3. لم يكن هناك تواصل مع فرق العمل الآخرى، ولم نكن نعلم كيف سيؤثر عملهم على عملنا.

شاهدوا المحاضرة وشاركونا خبراتكم...
وفيما يلي بعض خبراتنا السابقة في بعض المشاريع البرمجية.

السبت، 17 يناير 2015



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

اطار عمل الأسكرم (سكروم) هو ليس خاصا فقط بالعاملين بقطاع البرمجة، وانما هو منهج اداري عام، لذلك فهذه الدورة تستهدف الفئات الآتية
  • كل العاملين في قطاع البرمجيات، حتى العاملون في اقسام الحسابات والموارد البشرية واي منصب تنفيذي.
  • طلبة علوم الحاسب، وخصوصا الذي يدرسون مادة (هندسة البرمجيات).
  • كل مديري المشروعات في اي قطاع اعمال.
  • كل ريادي الأعمال من اي مجال.
في نهاية الدورة سأسجل فيديو عن كيفية استخدام هذا الأطار حتى في ادارة شئون البيت، واستخدامه كوسيلة لتحقيق التواصل الفعال مع الزوجة والأولاد لإدارة الحياة الأسرية ... شخصيا، متحمس جدا لهذه الفكرة وبدأت اجهز لها.

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

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

الخميس، 1 يناير 2015


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

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

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

بدأت المشاكل بأن:

1- متطلبات العميل غير واضحة...

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

2- التغيير الدائم في المتطلبات ...

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

3- المشروع استنزف وقتا طويلا وخرج عن الميزانية ...

اليس هذا نتيجة حتمية ومنطقية لما ذكرناه في الأعلى!. التغيير الدائم في المتطلبات، سيؤدي حتما لجهد اضافي يتطلب لوقت اضافي وموارد اضافية وميزانية اضافية. الذي قد يؤدي الي ضجر العميل من المشروع ومن الفريق القائم عليه فيوقف العمل فيه ويلغيه... الم يحدث هذا كثيرا معنا ...
في احصائية اجريت سنة 95، وجدوا ان نسبة نجاح المشاريع البرمجية التي لاتنتهج منهجا مرنا Agile في اداراتها لا تتجاوز 31% !!!

4- لايوجد وقت لعمليات الأختبار ...

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

5- وقت كثير يستهلك فيما لاينفع

دراسة اكاديمية اجريت سنة 2003 ذكرت الآتي:
" 53% من المتطلبات في المشروع يتم الغائها، حيث يكتشف انها غير ذات قيمة حقيقية في المشروع، او الوضع الراهن نفسه قد تغير"
"64% من المتطلبات التي يتم بنائها لا تستخدم، وفي احسن الأحوال تستخدم مرة كل سنة مثلا"
كان لدي تجربة شخصية مع برنامج لأحد الجامعات. في هذا البرنامج تم بناء اكثر من 120 تقرير وفقا لاحتياجاتهم، وبعد الأنتهاء منها واثناء مراقبتنا لسير العمل وكفاءة النظام، وجدنا ان اقل من 10 تقارير هي التي تسخدم بشكل دوري، واكثر من 50 تقرير لم يستخدموا على مدار اكثر من 6 سنوات :)

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

1- قبل التعاقد قم بتوثيق الرؤية والأهداف وليس المتطلبات...

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

2- بعد التعاقد، قم بزيادة وعي العميل...

لا يوجد مشروع -ايا كانت طبيعته- لايواجه تحديات ومشاكل. لذلك من المفيد ان تقوم بعمل ورش عمل ومحاضرات لتوعية العميل عن طبيعة المشاريع البرمجية. حاول الا تخيفه بذكر نسب فشل المشاريع :) ... لكن ارفع وعيه بالشكل الذي يضمن لك ارضية تفاهم وتفاوض في حالات المشاكل. هذه تكتسب بالخبرة ومع الوقت.

3- التفاوض حول المتطلبات ...


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







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

روابط ذات صلة:

سلسلة صوتية عن ادارة المشاريع بمنهج اسكرم باللغة العربية.

مجموعة فيديوهات عن سيناريو الحوار باللغة العربية.

مواجهة العملاء -دروس وعبر- كلمات يكرهها العميل.

مواجهة العملاء -دروس وعبر- وثائق يكرهها العميل.

الأربعاء، 5 نوفمبر 2014


 اطار عمل اسكرم (سكروم) SCRUM هو واحد من اشهر اطر العمل المرنة Agile frameworks في تصنيع البرمجيات ان لم يكن اشهرها. الجدير بالذكر اني اكاد اجزم انه حتى اولئكم الخبراء في هذا الأطار لايكادون يعرفون معنى هذه الكلمة :)
بصراحة لم يمر على هذا الأمر مرور الكرام، ومنذ بدأت دراسة هذا الأطار في عام2010  وانا اسأل نفسي « ما معنى كلمة سكرم (سكروم) ، او ما هو مرادفها في اللغة العربية» ، او ماهي الترجمة الحرفية لها !!!

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

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

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


لقد اصبح هذا النموذج تراثيا، ولايعدو كونه نموذجا ايضاحيا او row model !!!
فالواقع ان كل شئ في دورة البرمجة متغير.
  • المدخلات والتي تمثل احتياجات العميل متغيرة دائما.
  • التقنيات التي نصنع بها البرامج ولغات البرمجة وقواعد البيانات وانظمة التشغيل ...متغيرة

انها بيئة عمل قاسية ومعقدة، فالمبرمج يحاول دائما ايجاد حل لمشكلة دائمة التغير بوسائل متغيرة دائما !!!

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

كعادتي سرحت بكم بعيدا عن موضوعنا الأساسي وتفرعت بكم في موضوع اخر :)

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

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

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

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

السبت، 25 أكتوبر 2014

كمحلل اعمال Business analyst  (تعريف اول، تعريف ثان) داخل شركتي، كان دائما ما يشغلني الكيفية التي يتم بها توثيق احتياجات العميل او كتابة الــ Requirement document . كل مرة ندخل فيها في مشروع جديد تترائى امامي المقولة القائلة:
افضل وثيقة احتياجات تمثل -على احسن الأحوال- 80% من احتياجات العميل النهائية
The Best ever written requirement document represents 80% of customer's needs
وتظل تترائي امامي طيلة الوقت، واذكرها مرارا وتكرارا امام العميل المرتقب، حتى انه قد يفزع من العمل معي ويتراجع، وقد حدث ذلك معي مسبقا اكثر من مرة. !!!

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

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

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

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

ثم تبدأ مرحلة تحليل كل ملحمة الي مشاهد تحوي  سيناريوهات.
سأكتفي بتحليل الملحمة الأولى والتي توضح نشأة الصعلوك:
1.1 مشهد للصعلوك وهو في مكان عمله المتواضع، حيث تبدأ شخصيات اخرى في التفاعل مثل المديره والزبائن.
1.2 مشهد لمشادة كلامية بين الصعلوك ومديره وتتطور الي تدافع بالأيدي ومعركة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Subscribe to RSS Feed Follow me on Twitter!