التجارب والاخطاء لمرتكبةا في ادارة المشاريع الكبيرة ...

[Mohammed-Saeed 33]

بسم الله الرحمن الرحيم

ما هي الأخطاء والتجارب التي ارتكبتها اثناء ادارتك للمشاريع ... لعل الآخرين يتعظوا منها ...

تحياتي

[System Down 557]

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

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

[Mohammed-Saeed 33]

شكراً جزيلاً ...

اشرت لمهم، ساعلق عليه فيما بعد ...

اضافتي: توثيق جميع التغييرات في الاصدارت المختلفة للبرنامج ...

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

من الطبيعي ان اخطاءً عديدة كانت فيه، وصلت لهم فقاموا بإصلاحها دون الاحتفاظ بالنسخة الاولى للبرنامج ... ودون حفظ التغييرات التي اُجريت في كل مرة ...

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

لي عودة ان شاء الله

[helaly 3]

1. ادرس موضوع البرنامج جيداً وتحدث كثيراً (brainstormings) مع اشخاص يعملون فى موضوع البرنامج. (تحدث مع موظفى الموارد البشرية اذا كان برنامج للموارد البشرية، تحدث مع موظفى المخازن اذا برنامج برنامج مخازن)

2. لا تحاول ان تخترج العجلة فى برنامجك.

3. اذا كنت تعمل ضمن فريق عمل، اتفقوا جميعاً على اللغة ومنصة العمل التى تناسب الجميع وتسهل العمل.

4. حدد لنفسك موعد لانجاز العمل deadline

5. حدد اولويات المهام التى ستنجزها فى البرنامج، (مثال: الادخال ثم التقارير ثم المهام المساعدة مثل النسخ الاحتياطى)

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

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

8. بعد الانتهاء من المشروع، اضف اليه بعض الخيارات التى من شئنها تسهل وتكبر المشروع.

9. لا تنزعج اذا استغرق منك انجاز المشروع وقت طويل، فهذا طبيعى .

[Night Coder 189]

سأسرد مشاكل شائعة بشكل عام

1 - تقدير الوقت Time Estimation سواء كان Over Estimation او Under Estimation

2 - عدم وجود منهجية متبعة Methodology فى المشروع --> واجهت هذه المشكلة باحد المشاريع الكبيرة و استفدت منها فى المشاريع التالية باختيار المنهجية المناسبة للمشروع قبل البدأ برمجياً فى المشروع

3 - عملية جمع المتطلبات Gathering Requirements قد لا تكون دقيقة مما ينتج عنه اخطاء فى مرحلتى التحليل و التصميم --> جعلت احد مستخدمى التطبيق يعمل معنا فى مرحلة التحليل و الاختبار مما قلل بشكل ما هذه المشكلة

4 - استنفاذ وقت افراد فريق المطورين بدون رقابة على وقت المهام --> هذه المشكلة واجهتنى كمدير فريق لعدة اسباب منها عدم خبرة المطورين و هذه تغلبت عليها باستخدام Pair Programming مما كان له اثر واضح اثناء المشروع و المشاريع التالية - سبب اخر كان بسبب الادارة التى استخدمت فريق العمل فى مهام اخرى

5 - لا يوجد Unit Testing او CI Tests اثناء العمل --> عدم فهم ال Testers Role اثناء او بعد البرمجة شخصياً اعتمد على نفسى فى كتابة ال Unit Test

6 - سوء إدارة التوثيق

7 - سوء إدارة ال Source Control(سبب المشكلة هو عدم تدريب المبرمجين جيداً على ال Source Control)

8 - عدم استخدام Bug Tracking System --> الشركات ليس لديها اهتمام فعلى بحل المشكل جذرياً و انما لحظياً

تم تعديل 20 Nov 2009 بواسطه طارق إبراهيم

[Harreni 0]

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

تم تعديل 30 Nov 2009 بواسطه Harreni

[Mohamed Metwaly 0]

موضوع رائع و مفيد

[ayash 43]

مشكورين وبارك الله فيكم

[Khaled Alshaya 826]

بصراحة أدرت مشروعاً واحداً عليه القيمة :S

المشروع كان معظمه في الإلكترونيات و جزء صغير فقط برمجة embedded systems. الفريق كان عبارة عن عشرة أشخاص, تسعة أشخاص للإلكترونيات واحد منهم فقط لديه خبرة بسيطة في البرمجة و أنا المبرمج الوحيد و المدير الفاشل أيضاً!

ببساطة كان المشروع يسير إلى الفشل لولا توفيق الله عز وجل, إضافة إلى التعديلات التالية في طريقة إدارة المشروع:

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

وجود شخص مسؤول عن عملية الـ Integration بحيث يعرف الفكرة العامة من البرنامج و المتطلبات و يقارن بينها و عمل النظام. كنا نقوم بعمل اجتماعات اسبوعية لعمل Integration و أحياناً تفشل و أحياناً تنجح و لكنها كانت تأخذ وقتاً طويلاً. و الأسوأ أنه في بعض الأحيان كانت بعض المجموعات تنتهي في يومين أو ثلاثة من المهمة الأسبوعية و بعض الفرق ينتهي بها الأسبوع دون إنتاج المطلوب. عندما أصبح لدينا Integrator أصبحنا نقوم بعمل نظام Helpers للمجموعات المتأخرة بحيث يدخل معهم لإنجاز المهام الجانبية دونه التدخل في عمل المجموعة الرئيسي. بحيث أن الـ Integrator مسؤول عن تكامل النظام في أي وقت بينما مهمتي كمنسق الجري بين المجموعات لمعرفة التطورات و توضيح المهام الجديدة المتفق عليها في الاجتماعات كجسر بين المجموعات. و أصبحت اجتماعاتنا الدورية تنتج خططاً للأسبوع القادم بعد أن كنا نغرق في متاهات تجربة النظام بشكل كامل بحيث نستمر في العمل دون وضوح في مهمات الأسبوع القادم!

تحياتي...

تم تعديل 11 Aug 2011 بواسطه Khaled.Alshaya

[W.A.R.D 13]

بصراحة أدرت مشروعاً واحداً عليه القيمة :S

المشروع كان معظمه في الإلكترونيات و جزء صغير فقط برمجة embedded systems. الفريق كان عبارة عن عشرة أشخاص, تسعة أشخاص للإلكترونيات واحد منهم فقط لديه خبرة بسيطة في البرمجة و أنا المبرمج الوحيد و المدير الفاشل أيضاً!

ببساطة كان المشروع يسير إلى الفشل لولا توفيق الله عز وجل, إضافة إلى التعديلات التالية في طريقة إدارة المشروع:

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

وجود شخص مسؤول عن عملية الـ Integration بحيث يعرف الفكرة العامة من البرنامج و المتطلبات و يقارن بينها و عمل النظام. كنا نقوم بعمل اجتماعات اسبوعية لعمل Integration و أحياناً تفشل و أحياناً تنجح و لكنها كانت تأخذ وقتاً طويلاً. و الأسوأ أنه في بعض الأحيان كانت بعض المجموعات تنتهي في يومين أو ثلاثة من المهمة الأسبوعية و بعض الفرق ينتهي بها الأسبوع دون إنتاج المطلوب. عندما أصبح لدينا Integrator أصبحنا نقوم بعمل نظام Helpers للمجموعات المتأخرة بحيث يدخل معهم لإنجاز المهام الجانبية دونه التدخل في عمل المجموعة الرئيسي. بحيث أن الـ Integrator مسؤول عن تكامل النظام في أي وقت بينما مهمتي كمنسق الجري بين المجموعات لمعرفة التطورات و توضيح المهام الجديدة المتفق عليها في الاجتماعات كجسر بين المجموعات. و أصبحت اجتماعاتنا الدورية تنتج خططاً للأسبوع القادم بعد أن كنا نغرق في متاهات تجربة النظام بشكل كامل بحيث نستمر في العمل دون وضوح في مهمات الأسبوع القادم!

تحياتي...

هههههههههههههههههههههههههههههههه جميل جميل

اسوأ شيئ هو التفائل الزائد

والاعتقاد انك ستنهي المشروع في اسبوع فقط

[Ala2 VB 95]

جزاكم الله خيراً على هذه النقاط القيمة .

أهم ما تعلمته من المشاريع التي قمت بها -الفردية القليلة- هي التخطيط الجيد وانه الجزء الاصعب والأهم والمفترض ان يأخذ وقتاً كافياً , فقد كنت بمجرد وضع رؤوس اقلام لفكرة المشروع ابدأ في كتابة الكود مباشرة ظناً ان التخطيط الذهني أثناء الكتابة كافي ,لكن بعد ملاحظة اني لم انهي أي مشروع مما بدأته مباشرة دون تصميم وتخطيط دقيق بدأت في أعادة التفكير في طريقة عملي فقمت بعمل برنامج للتجربة -صغير وفكرته تافهة- لكنني خططته بالتفصيل والحمد لله وتفاجأت أني أنهيته تماماً :)

تم تعديل 14 Jan 2012 بواسطه Delphawi

[أبوعزام 18]

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

[samyzidan 0]

شكراً جزيلاً ...

اشرت لمهم، ساعلق عليه فيما بعد ...

اضافتي: توثيق جميع التغييرات في الاصدارت المختلفة للبرنامج ...

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

من الطبيعي ان اخطاءً عديدة كانت فيه، وصلت لهم فقاموا بإصلاحها دون الاحتفاظ بالنسخة الاولى للبرنامج ... ودون حفظ التغييرات التي اُجريت في كل مرة ...

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

لي عودة ان شاء الله

مشكووووووووووور

[AlgeROI 0]

- عدم الاهتمام بالامور الشكلية التي تضيع الوقت : الاساس ثم الشكليات و الاضافات .