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

الثلاثاء، 27 سبتمبر 2016


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

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

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

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

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

لو نظرتم مثلا في قائمة الشركات المرشحة لجايتكس 2016، غالبا هاتلاقيهم كلهم او معظمهم ليسوا من المشاركين في اجتماعاتنا ... 

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

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

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

مبادرة دعم الشركات الصغيرة والمتوسطة MSE هي مبادرة عودت الشركات على (الأنتخة) والأسترخاء. تمويل يمكنه ان يعين شركة من فردين لمدة سنة ولايتطلب الكثير من العطاء وشروطه سهلة !!!

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

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

افيقوا قبل ان تشيخوا

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


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

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

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

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

اقرأ ايضا:

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

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

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

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

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

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


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


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

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

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

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

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

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

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



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




السبت، 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 ويمكنك الوصول لكل النماذج الخاصة به على هذا الرابط ، وقد وضعته عندي بهذا الشكل حتى اسهل على القارئ الوصول للملف بشكل سريع دون البحث عن النموذج نفسه وسط كل نماذج اطار عمل مايكروسوفت. 

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

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

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

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

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

السبت، 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- كمسئول عن شئون الموظفين استطيع ان احدد الموقف العائلي وان ادخل بيانات العائلة، ان وجدت.
وهكذا...

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

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

الأحد، 5 أكتوبر 2014

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

في تدوينة قديمة لي عام 2012 ذكرت ملاحظات حول اداء الهيئة في سياسة المؤتمرات، كما اني في كل محفل او اجتماع تنظمه الهيئة اشير الي كل الملاحظات التي ذكرتها في تلك التدوينة.

سأعرض فيما يلي خبرتي مع الهيئة محاولا تسليط الضوء بشكل عملي ومبسط على سلوك الهيئة الذي ذكرته في المقال الأول (العمل في منطقة الراحة).  وسأعرض ما اراه صحيحا من منظروي، كما سأقدم بعض التوصيات لكيفية ادارة المؤتمرات وهي كلها لاتلزم تكلفة اضافية وانما تغيير الروح او الــ Attitude 
خبرتي في المؤتمرات والمعارض مع الهيئة كانت في محفلين، سأتكلم عن اهمهم و كان في فرنسا European ICT2008

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

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

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

اولا: بالنسبة لمؤتمر  مثل European ICT.

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

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

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

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

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

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

 جيتكس و CeBIT

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

نوع آخر من المؤتمرات.

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

مؤتمرات محلية متخصصة.

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

كلمة اخيرة

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

الأحد، 7 سبتمبر 2014


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

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

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

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

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

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


على المستوى الشخصي لم يكن في استراتيجية الشركة حين -اعلان المبادرة- تنفيذ ما اسماه العامل في الهيئة (تطبيق موبايل يضرب) وكانت لدينا رؤية للخروج بتطبيق سحابي Cloud، بالطبع تمويله لن يقتصر على الـ 100 الف جنيه، ولكننا وجدناها فرصة ان نوفر من بند التمويل الذاتي، وقدمنا الفكرة كما ذكرت وحصلنا على التمويل.

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

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


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

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

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

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

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

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

الأربعاء، 3 سبتمبر 2014



هذه التدوينة هي مقدمة لمجموعة تدوينات قادمة ان امد الله في اعمارنا، اتناول فيها اداء هيئة تنمية صناعة تكنولوجيا المعلومات (ايتيدا) في الفترة من قبل الأزمة المالية العالمية، مرورا بها، ثم الثورة المصرية، وما بعدها.

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

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

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

اسباب المشاكل التي ساتناولها في تدوينات لاحقة يمكن حصرها وضمها تحت ثلاث عوامل رئيسية يشكلون سمة واتجاه داخل الهيئة:
  1. اولا: العمل في منطقة الراحة: وللأيضاح اكثر، فأن معظم المبادرات ان لم يكن كلها تعتمد على تقييم اعمى، يعتمد على ماتكتبه الشركات في نماذج التقييم، دون مراجعة اوتحقق من خلال مقابلة للشركات. ومهما كان عدد الشركات فإنه ليس دافعا ابدا الا يتم مقابلتهم شركة تلو الأخرى. 
    * للتذكرة، فإن الهيئة نفسها قد ذكرت في 2011 ان عدد الشركات المسجلة في قاعدة بياناتها لا يتجاوز الــ 800 شركة، اعتقد ان هذا العدد قد تأثر كثيرا الآن. بمعنى اخر انه ليس امرا مستحيلا ان يتم مقابلة الشركات لمعرفة من يستحق المبادرة ومن لا يستحقها.
  2. ثانيا: ادارة المشاريع: في كل مرة يتم اطلاق مبادرة،  تبدأ بشكل جيد، ثم تبدأ في مواجهة مشاكل ، وهو امر عادي ومقبول، الغير عادي وغير مقبول الا نجد مسئول من داخل الهيئة لمتابعة هذه المشاكل. من تجربة شخصية، فأن مراسلة الهيئة من خلال البريد الأليكتروني او التليفون عبارة عن كابوس، لا تختلف فيه عن اي مؤسسة حكومية، سوى ان ردهم (الطف شوية، ودايما هاتلاقي حد يرد عليك)، لكن لن تصل -في اغلب الأحوال- للأمر الذي تريده. كثيرا جدا اطلب من متلقي المكالمة ان يوصلني بشخص ما (مش مدير الهيئة، دا مدير قسم داخل الهيئة) ويكون الرد ممنوع يافندم !! رغم اني مش شايف مشكلة ان مدير الهيئة يخصص يوم كامل وساعة يوميا للرد على اصحاب الشركات، متأكد هايكون لهذا اثر كبير وافضل في فهم مشاكل القطاع من قلبها.
    في ادارة المشاريع هناك المديرون الذي يخططون ويستبقون الأحداث ويصنعون الأفعال، وهناك من يستجيبون للأفعال التي تحدث حولهم بردود افعال Proactive and reactive ... النموذجين غير متواجدين في الهيئة !.
    انا فعلا لا ادري ان كان هناك وحدة لإدارة المشروعات داخل الهيئة ام لا. ان لم يكن فهم بحاجة ماسة اليها، وان كانت موجودة فهي بحاجة ماسة الي اعادة النظر في سبب وجودها.
  3. عدم الأعتراف بالأخطاء ومهاجمة كل من ينتقد ادائهم. رئيس الهيئة السابق ياسر القاضي كان اكثر تقبلا للنقد من موظفيه. !!!
 لا اعتقد ان احدا سينكر ان هذا القطاع اسسه وصنع فيه طفرة واضحة د.احمد نظيف حين كان وزيرا للأتصالات في الفترة من عام 99 حتى نهاية 2003 حيث تولى بعدها رئاسة الوزراء.  لسنا هنا بصدد الدخول في نقاش سياسي حول ذمة الرجل المالية ونزاهته، (محور كلامنا هو القطاع ومشاكله والهيئة باعتبارها الكيان الأكثر تأثيرا فيه). لكن من الأنصاف لأنفسنا وقطاعنا ان نتعلم من الدروس السابقة خيرها وشرها.
اهم ثلاث مبادرات قام بهم نظيف وادت الي نمو القطاع هما:
  • مبادرة حاسب لكل بيت: التي ادت الي انخفاض اسعار الأجهزة للمستوى الذي جعلها في كل بيت بعد ان كانت حكرا على فئة معينة من الناس.
  • الأنترنت المجاني.
  • مبادرات التدريب المجاني على شهادات مايكروسوفت واوراكل و IBM و سيسيكو ... الخ. والتي ادت بدورها الي خروج كفاءات ممتازة في هذا المجال وجعلت لمصر مكانة على خريطة اسواق التعهيد عالميا outsourcing.
هذا القطاع لازال يعيش على نتائج تلك المبادرتين حتى الآن، ولم يعقبهما اي مبادرات يمكن ان نرى انه كان لها اثرا واضحا في القطاع. كل من توالى بعد د.نظيف على الوزارة وحتى يومنا هذا لم يترك اي بصمة واضحة كما فعلها نظيف. !!!
وكل من اتوا بعد نظيف سواء في الوزارة او من تحتهم من رؤساء للقطاعات،  لم يكن لهم بصمة واضحة، وكل اعمالهم كانت نتيجة حتمية ومترتبة على المبادرات سالفة الذكر. بل ان التقدم في خدمات الأنترنت توقف من حينها، ومستوى المنح التدريبية ظل ينهار حتى انتهت تماما.
اداء الهيئة ونشاطها قبل الثورة كان افضل كثيرا منه بعد الثورة، وليس معنى انه كان افضل انه كان على المستوى المطلوب، اطلاقا.
وليس معنى ان اداء الهيئة نستطيع ان نصنفه انه الأفضل بين المؤسسات والهيئات الحكومية انها كذلك، فالمؤسسات تقريبا كلها هياكل لمؤسسات... مقولة (احسن الوحشين) مش ميزة ولا فخر !!!!!!

اهم المبادرات التي سأعلق عليها في التدوينات القادمة.
  1. مبادرة دعم الشركات الصغيرة والمتوسطة. بدأت بعد الثورة مباشرة عام 2011 وتكررت مرتين بعدها.
  2.  مبادرة دعم الأبداع.
  3. مبادرة التعاون البحثي مع الأتحاد الأوروبي ITEA عام 2007و 2008.
  4. سياسة المؤتمرات والمعارض وتجربة مؤتمر ICT 2008 في ليون - فرنسا.
  5. دور SECC في التدريب، وهل هي تساعد في تنمية القطاع ام تنافس شركات التدريب !.
  6. ITAC.
  7. GO TO FINANCE  !!!!
  8. GO TO GULF. لم اشارك فيها بنفسي لكن زملاءنا شاركوا فيها وكانت تعليقاتهم عليها محبطة ومخيبة للآمال جدا.
  9. مبادرة دعم الشركات بأدوات البرمجة MS visual studio  والتي تمت سنة 2006 وكانت فاشلة لأقصى درجة.
  10. مبادرة دعم الشركات بأدوات البرمجة MS visual studio (نفس المبادرة السابقة) والتي تمت سنة2010 وكانت ايضا فاشلة. نفس الأخطاء !!!
وساحاول ايضا التعرض لمجموعة من المهام والأدوار التي يجب تقوم بها الهيئة وهي متجاهلاها  تماما.

اخيرا وقبل ان ابدأ في نقد المبادرات اذكركم. البداية من الهيئة ان تتقبل النقد، والبداية من الشركات ان تنتقد بصوت جهوري.

السبت، 23 أغسطس 2014

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

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

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

اولاً: تكاليف الوظائف الإدارية في الشركة.

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

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

ثانيا: التكلفة الحقيقية للعمالة على مدار السنة

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


نلاحظ ان عدد ايام العمل الفعلية في السنة تمثل 48% من السنة، اي ان الشركة تدفع مرتبات الموظفين شهريا على مدار السنة في حين ان الموظف يعمل فترة اقل من نصف السنة ! ... مبدئيا هذا ليس اعتراض، فكل ايام العطلات هذه عبارة عن استحقاقات، نحن فقط ننبه عليها.
بعد هذه الاحصائية التي تدعو للتشائم قمت باحصائية اخرى على العمالة الفنية -تحديدا مبرمجين ومختبرين.
عدد ساعات العمل الرسمية : 8 ساعات يوميا، منها ساعة راحة. بالطبع الـ 7 ساعات الأخرى ليست في اجتماعات او جلوسا على المكتب، فهناك اوقات الصلاة، والشاي والقهوة، والحمام، وبعض الأحاديث الجانبية، والحضور المتأخر ... الخ. في تجربتنا طلبنا من الموظفين ان يسجلوا ساعات العمل الفعلية، وكانت النتائج كالآتي:
اقل عدد تم تسجيله في يوم هو ساعتين.
اكبر عدد ساعات تم تسجيله هو 5 ساعات !.
اي ان نسبة ساعات العمل الفعلية لعدد ساعات العمل المفروضة بين 28% الي 70% كحد اقصى !!! وهو مايمثل بين 30% الي 40% من اجمالي السنة.
دعونا نذكر ان هذا ليس مقالا عن تحسين الأنتاجية ، واننا نذكر بهذا -فقط- كي نأخذه في الأعتبار حين التسعير لمشروع جديد.
هذا معناه ان تكلفة العمالة المهنية في اي مشروع حال تقييمه لاتمثل الا 30% من القيمة الحقيقية لتكلفة نفس البند (تكلفة العمالة المهنية). بمعنى اخر :
 التكلفة الحقيقية للعمالة المهنية (الفنية) في المشروع = التكلفة الفنية المرصودة * 3.3
قترات الركود بين المشروعات هي امر اخر خطير، في العادة لا تأتي المشروعات تباعا، وانما هناك فترات ركود بين كل مشروع واخر، هذه الفترات  يمكن ان تستنفذ كل المكسب، حيث انك لازلت تدفع فيها مرتبات رغم عدم وجود اي اعمال تعود بربح على الشركة.
هذا بافتراض ان المشروع سار على مايرام من حيث الفترة الزمنية والميزانية المرصودة، والعميل السابق لم يتأخر في الدفع ولم يخصم غرامات تأخير، والعميل القادم لم يتلكأ في التعاقد. !!!
اذن يجب اخذ فترات الركود بين المشاريع في اعتبارات عملية التسعير، ونسبتها تعتمد على خططك المستقبلية وحجم المبيعات المتوقعة واحتمالية كل عملية بيعية !

ثالثا: مصروفات ادارية اخرى.

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

نصائح اخيرة

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

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

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


Subscribe to RSS Feed Follow me on Twitter!