نتاج التعلم أ: التحقيق في مبادئ ومنهجيات إدارة مشاريع تكنولوجيا المعلومات

إدارة المشاريع: مهارة تنقلك بين الوظائف

يعد فهم كيفية إعداد المشاريع وإدارتها مهارة أساسية إذا كنت تعمل في قطاع تكنولوجيا المعلومات.

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

المنهجية: كيف نختارها؟

• المنهجية: تستخدم جميع المنظمات تقريبًا منهجية المشروع، وتعتمد على عوامل مثل:
• مدى تعقيد المشروع
• شدة المخاطر المرتبطة بالمشروع
• العمليات المنهجية التي تتناسب مع طريقة عمل المؤسسة
• المنهجية المفضلة لدى المؤسسة أو مدير المشروع، وقد يؤثر العميل أيضًا
• تعريف المشروع: يجب أن تبدأ المشاريع بتعريف يحدد الجوانب الرئيسة، ويتفق جميع أصحاب المصلحة أنه دقيق ويعكس الاحتياجات والنتائج.
• أسباب بدء المشروع: تبدأ معظم المشاريع لسبب أو أكثر:
• ظهور فرصة عمل جديدة، لتطوير منتج أو خدمة جديدة
• اكتشاف مشكلة أو خلل في الأنظمة أو العمليات الحالية يؤثر في الربحية أو الكفاءة التشغيلية
• دخول تغييرات على التشريعات حيز التنفيذ تتطلب توافق الأنظمة، مثل اللوائح العامة لحماية البيانات في الاتحاد الأوروبي
• الرد على أنشطة المنافسين لضمان عدم فقدان الحصة السوقية الحالية
• الغرض والتعريف: يحدد الغرض التعريف: أهداف المشروع وغاياته ونطاقه والنتائج المتوقعة، ويُسجَّل رسميًا ويوافق عليه أصحاب المصلحة.
• لماذا الاتفاق الرسمي؟ تفشل مشاريع كثيرة بسبب التوسع في النطاق عند تقديم طلبات إضافية، قد تبدو بسيطة لكنها تتسبب في تحديات تتعلق بالموارد والوقت.
• طلبات التغيير: يجب دائمًا توجيه أي طلبات تغيير إلى مدير المشروع للنظر فيها بعناية، وإذا تم قبولها يجب تسجيلها رسميًا ومراعاة الوقت أو الموارد الإضافية
• قول "نعم" لكل شيء: يمكن أن يعرض المشروع للخطر، خاصة إذا أصبحت الطلبات مفرطة.

لماذا يجب أن يوافق أصحاب المصلحة رسميًا على تعريف المشروع؟

التواريخ والمراحل الأساسية والمخاطر

• التخطيط: بمجرد تحديد المشروع يبدأ مدير المشروع بتفصيل المهمة الإجمالية ليعرف الأنشطة المحددة ومتى يجب الانتهاء منها.
• الأدوات: غالبًا برامج إدارة المشاريع المتخصصة أو مخططات جانت التي أنشئت في برامج مثل ⁦Microsoft Excel⁩.

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

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

نطاق المشروع: ما بداخله وما خارجه

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

دورة حياة المشروع: من البدء إلى الإغلاق

• أبسط صورها: ثلاثة مكونات: التخطيط، ثم التنفيذ، ثم المراجعة.

• البدء: يحدد أصحاب المصلحة متطلبات المشروع والمخرجات ويدعمونها بالأدلة ويوافقون عليها، ولكل مشروع مجموعة مختلفة منهم.

• اختلاف الاحتياجات: لا يمكن للمديرين دائمًا ضمان تشابه احتياجات المجموعات؛ مثل مشروع تصنيع آلي يزيد شاحنات التوصيل عبر المجتمع المحلي ويضغط على البنية التحتية للنقل.
• الحل: لضمان دعم مجموعات أصحاب المصلحة للمشروع، قد تكون هناك حاجة إلى الكثير من التفاوض والتسوية خلال مرحلة البدء
• التخطيط: تستكشف مرحلة التخطيط كيف سيتم تنفيذ أعمال المشروع، وما المهام التي ستكون مطلوبة، ومن سيتولى المهام الفردية، ومتى ستبدأ المهام وتنتهي
• خطة المشروع: يتم إضفاء الطابع الرسمي على خطة المشروع، ويستخدمها المدير والفريق كوثيقة للتحكم والمراقبة وتقييم الأداء
• التنفيذ: تُجمع المواد الخام والموارد البشرية اللازمة، ويعمل الفريق بطريقة منهجية باستخدام الخطة كدليل.
• ترتيب المهام: بعضها يُنفَّذ في الوقت نفسه، وبعضها يجب إنجازه بالكامل قبل أن تبدأ المهمة المرتبطة التالية.
• في جميع الأوقات: سيتحقق فريق المشروع من أنهم ينفذون المشروع ضمن القيود الزمنية والميزانية المطلوبة، ومن أن نتائجهم ذات جودة مناسبة

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

المنهجية الأشهر: سبع عمليات

• خصائص المنهجيات: تجعلها مناسبة لإنجاز أنواع معينة من المشاريع.
• PRINCE2: من أشهر المنهجيات القياسية في المجال، وليست خاصة بتكنولوجيا المعلومات، ومناسبة لمعظم المشاريع بغض النظر عن حجمها أو تعقيدها.
• الوظائف: تُعلن وظائف مدير المشروع غالبًا مع ⁦PRINCE2⁩ كشرط أساسي أو مؤهل مرغوب فيه.
• الإطار: يحدد أفضل الممارسات، مقسمًا إلى سبع عمليات أو مراحل، ولكل عملية أنشطة معينة.
• بدء المشروع: إعداد لوحة المشروع، واختيار الفريق ومدير المشروع، وإعداد موجز المشروع، وتحديد النهج.
• كتابة مخطط دراسة الجدوى
• فحص تجارب المشاريع السابقة لتجنب الأخطاء السابقة
• تدشين المشروع: تُنفَّذ أنشطة التخطيط الرسمية، وتُحسَّن دراسة الجدوى للتركيز على المخرجات الرئيسة.
• يُصنَّف كل مخرج إما "أساسي" أو "مرغوب فيه" أو "سيكون رائعًا ولكنه ليس ضروريًا"
• يتم فحص أنشطة التخطيط لتحديد وتخفيف أي مخاطر محتملة وتحديد أي ضوابط ضرورية للمشروع
• تحديد أي ملفات مشروع ضرورية
• يُضفى الطابع الرسمي على كل ذلك في وثيقة بدء المشروع
• توجيه المشروع: قبل البدء يجب الحصول على موافقات وثيقة بدء المشروع، والنطاق العام، والعمليات أو المراحل الفردية.
• بعد البدء: توجيه مخصص إضافي من مدير المشروع، وفي نهاية المشروع يبدأ مدير المشروع الإغلاق الرسمي.

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

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

التطوير السريع: نماذج أولية متكررة

• RAD: بدأ في الظهور في الثمانينيات ولم يصبح سائدًا حتى أوائل التسعينيات، في وقت كانت فيه المنهجيات منظمة للغاية، مثل الشلال ⁦Waterfall⁩.
• المناسب له: تعتبر منهجية ⁦RAD⁩ مناسبة للتطبيقات قصيرة المدى وكبيرة الحجم للمؤسسات التي تتطلب موارد عالية الميزانية، وللمؤسسات الصغيرة والمتوسطة
• كيف يعمل: عملية تطوير مستمرة تُقسَّم إلى فترات قصيرة من النشاط، يؤدي كل نشاط إلى نموذج أولي يوافق عليه العملاء أو يرفضونه.
• يتطلب: مستويات عالية من التفاعل بين المطورين والعملاء/المستخدمين.

• تخطيط المتطلبات: يجتمع فريق المشروع في البداية مع العميل/المستخدم لمناقشة ما يأتي والاتفاق عليه
• احتياجات الأعمال عالية المستوى التي يهدف المشروع إلى حلها
• نطاق المشروع: ما سيُضمَّن وما لن يُضمَّن
• القيود والحدود، مثل الوقت أو الميزانية
• المتطلبات: الوظيفة التي ستُطوَّر
• النتيجة: سجل رسمي للمناقشة الأولية يصرح به المديرون.
• تصميم المستخدم: يتم تنفيذ سلسلة من الأنشطة لتصميم الجوانب الوظيفية لحل المشروع
• تحليل المستخدم لتحديد ما يفعله فعليًا في دوره والمهام التي يؤديها وعدد مرات تكرارها
• إنشاء النماذج والنماذج الأولية لمشاركة رؤية الحل مع أصحاب المصلحة
• تحليل الأنظمة لتحديد الأنظمة الحالية التي يحتاج الحل للتفاعل معها
• التوثيق: يُسجَّل تحليل المستخدم والأعمال والأنظمة غالبًا في رسوم بيانية توثق العمليات والمدخلات والمخرجات.
• أدوات ⁦CASE⁩: يمكن استخدام أدوات هندسة البرمجيات بمساعدة الحاسوب ⁦(CASE)⁩، ومنها:
• تحليل الأعمال والنمذجة: مثل نماذج علاقات الكيانات ⁦(ERMs)⁩، وهي نماذج عرض رسومية للبيانات وعمليات النظام.
• التطوير والتصميم والبناء: مثل ⁦GNU Debugger⁩، وحدة تحكم تفاعلية تحلل التعليمات البرمجية وتفحص كل سطر لتحديد الأخطاء.
• التحقق من التعليمات البرمجية: قوائم المراجعة، والإرشادات التفصيلية للكود، ومراجعات الأقران، وأدوات تحلل التعليمات دون تنفيذها.
• التحقق من الصحة: إنشاء حالات الاختبار والنماذج الأولية وأدوات التحليل الديناميكي التي تحلل التعليمات عند تنفيذها.
• إدارة التكوين: مثل أنظمة إدارة المحتوى ⁦(CMS)⁩ التي تدير التحكم في الإصدار والتغييرات وإصدار البرامج.
• المقاييس: مثل تحليل التعقيد و⁦Big O⁩، يحدد كفاءة الخوارزمية ويقدر مدة التنفيذ بأحجام مختلفة من بيانات الإدخال.
• إدارة المشاريع: مثل مخططات وجداول جانت لتخصيص الأنشطة وإدارة الجداول الزمنية والمراحل الرئيسة.
• المولدات: لشاشات الحاسوب لتحديد شكل الشاشات، وللوثائق لإنشاء وثائق المستخدم والوثائق الفنية.

• البناء: يُنشأ النظام بإنشاء نموذج أولي واحد أو أكثر من تصميم المستخدم، ويُشارك مع المستخدمين ويُعدَّل بناءً على ملاحظاتهم.
• أنشطة البناء السريع:
• برمجة وتطوير التطبيقات: كتابة أكواد المكونات واختبارها عند اكتمال كل مكون
• ربط المكونات معًا للتأكد من أنها تعمل كحل واحد (تكامل الوحدة)
• اختبار الحل بالكامل
• إطلاق الحل النهائي (⁦cutover/⁩التحول)، مع إعداد البيانات إذا لزم الأمر قبل الاختبار النهائي
• التغيير: يُوقَف النظام القديم وتنتقل الأنشطة إلى الجديد، ويشمل تدريب المستخدم.
• منهجية غير رسمية نسبيًا: لأن الفريق يختار العمليات التي يستخدمها أو لا يستخدمها بحسب الحاجة.
• الفوائد: يرى العملاء المنتج في أثناء تطويره، وتُحدَّد المشكلات بسرعة وتُصحَّح، وتحكم أفضل في المخاطر والوقت والميزانية، وقد تُطرح الوظائف المكتملة قبل اكتمال النظام.
• القيود: إذا كانت الموارد شحيحة تحدث مشكلات مع فرق تحتاجها نفسها، وكثرة الفرق الصغيرة تصعّب التحكم وقد تسبب تعارضًا في التصميم.
• قيود أخرى: الفرق المعتادة على العمل المنظم قد لا تتكيف، وكثرة الفرق وأصحاب المصلحة تبطئ العمليات، فالمنهجية أفضل مع الفرق المتوسطة أو الصغيرة.

منهجية الشلال: مراحل لا رجوع فيها

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

لماذا يُطلق عليها منهجية الشلال ⁦(Waterfall)⁩؟

• أمثلة: نموذج أولي لحل برمجي، ومخططات الشبكة، ومخططات الميزات الأمنية الرئيسة.
• المخططات: تُستخدم في تصميم قاعدة البيانات، وتوضح تنظيم البيانات كجداول بحقول من سمات تمثل سجلاً.
• قواعد العمل: تصف عمليات وإجراءات المؤسسة والقيود، وغالبًا تتضمن العمل بأخلاقية أو بطريقة مستدامة.
• التصميم: المرحلة التالية هي تصميم النظام الجديد، وسيشمل ذلك
• الرسوم البيانية مع النص الداعم الذي يمثل خطة هندسة النظام الجديد
• تحديد تنظيم البيانات بالرسوم البيانية مثل نماذج العلاقات بين الكيانات
• توثيق كيفية عمل العمليات الجديدة بالمخططات الانسيابية
• واجهة المستخدم ⁦(UI)⁩: تُصمَّم أيضًا، بالاستعانة غالبًا ببرامج تمثل نماذج أولية للشاشات والتنقل بينها.
• التنفيذ: تُستخدم وثائق التصميم لتطوير النظام، وتُختبر المكونات الفردية (الوحدات) قبل تجميعها لتشكيل النظام الكامل.
• التكامل: يتحقق الفريق أن النظام الجديد سيتكامل مع أي برنامج تستخدمه المؤسسة.
• الاختبار: سيتم فحص النظام بشكل شامل للكشف عن أي مشكلات وعيوب حتى يمكن إصلاحها
• البيانات: في البداية بيانات مختلفة، وقبل التثبيت تُختبر بدقة بالبيانات الحقيقية من العميل/المستخدم.
• التشغيل: يُثبَّت برنامج النظام الجديد وتنتقل العمليات من القديم إلى الجديد.
• استراتيجيات الترحيل: إيقاف نظام في نهاية اليوم والبدء بالجديد في اليوم التالي، أو تشغيل القديم والجديد بالتوازي، ويوفر الأخير فرصة إضافية للاختبار والتحقق.

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

الإدارة المرنة: سباقات وتكرارات

• Agile: من أحدث المنهجيات، أُطلقت رسميًا في عام 2001، مناسبة للمنتجات متوسطة وطويلة الأجل، وتسمح بتغيير متطلبات المستخدم في أثناء التطوير.
• المراحل: تتشابه مع المنهجيات الأخرى، لكن المرحلة المركزية تتكرر في سلسلة من سباقات السرعة لكل منها تكرارات متعددة.
• النتائج: تُحدَّد نتائج المشروع الإجمالية في البداية، ويُخطَّط للمخرجات الفعلية لكل مرحلة في بداية كل سباق.

• ست مراحل: هناك ست مراحل لهذه المنهجية.
• المرحلة الأولى - المفهوم: يُدرس المشروع بدقة لتحديد المتطلبات وما يحتاج الحل إلى تحقيقه.
• تحديد نطاق المشروع للتأكد من تحديد جميع الوظائف والميزات الضرورية
• استثناء أي وظائف وميزات لن تشكل جزءًا من المشروع
• خطأ النطاق: الفشل في تحديده بشكل صحيح يمكن أن يؤدي إلى توسع النطاق، وقد يعرقل المشروع تمامًا.
• ثلاثة أنواع من الحلول البديلة:
• حل جاهز يحتوي على معظم الوظائف الضرورية ولكن ليس دائمًا كلها
• حل مُعدل يُعدَّل فيه منتج موجود لتضمين الميزات المفقودة
• حل مخصص، أي تصميم وبناء حل من الصفر
• التكلفة: عند اختيار الحل الأنسب تُحسب التكاليف، وتشمل التقنيات التي ستُشترى، واختيار أعضاء الفريق وحساب تكاليفهم، ثم إضافة حصة من النفقات العامة التشغيلية والربح المتوقع
• خارطة الطريق: أخيرًا تُنشأ خطة عالية المستوى بتواريخ رئيسة مثل تاريخ تسليم المشروع.

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

• اجتماع سريع عن المشروع: حيث يتم مراجعة التقدم وتوزيع المهام
• المرحلة الرابعة - الإصدار: عند إنشاء جميع المكونات تتم خطوات الإصدار:
• يخضع المنتج بأكمله لاختبار ضمان الجودة
• تُكتب أدلة المستخدم وتبدأ عملية إعداد المستخدمين، مثل التدريب
• تُعدّ البيانات التي ستُرحَّل ليتولى النظام الجديد العمليات بالكامل
• يُقرّ خطة التنفيذ، ثم يُدار الترحيل بعناية لضمان عدم تلف البيانات
• المرحلة الخامسة - الصيانة: تحدث هذه المرحلة عندما يتم تسليم المنتج العامل إلى العميل ويتم استخدامه، ويتم دعم المستخدم وحل أي أخطاء تظهر في أثناء الاستخدام العادي للنظام
• المرحلة السادسة - التقاعد: معظم حلول تكنولوجيا المعلومات ستصبح أقل فائدة مع مرور الوقت، لأن حلولًا أخرى ستأتي بمزيد من الوظائف أو الميزات الأفضل، وفي النهاية سيتم استبدال المنتج أو سحبه
• المزايا: مرنة للغاية تسمح للفرق بالتكيف بسرعة، ومخرجات واضحة ومرئية في نهاية كل تكرار، وأسهل في تخطيط الأنشطة وتخصيص الموارد لأن كل نشاط قصير ومركز.
• الطرح: تُطرح المنتجات في السوق أولاً وبعدها تخضع لإصدارات مستمرة بإمكانات جديدة.
• القيود: تعتمد على العمل الجماعي الفعال، وتتطلب التزامًا كاملاً وجهدًا من كل عضو، وتتطلب مطورين ذوي خبرة لضمان القرارات الصحيحة.

كم تستغرق سباقات السرعة؟

متطلبات المستخدم: ماذا يفعل الموقع وكيف؟

• هياكل إدارة المشاريع: هياكل ومصطلحات تدعم إدارة المشروع، ولن تتناول كل هيكل في كل مشروع، وقد تستخدم المنظمات مصطلحات مختلفة.
• مثال: فني دعم تكنولوجيا المعلومات قد يُسمى أخصائي دعم أو محلل مكتب خدمة أو أخصائي مكتب المساعدة.
• متطلبات المستخدم: تُصنَّف على أنها وظيفية أو غير وظيفية.
• الوظيفية: الأشياء التي يحتاج موقع إلكتروني إلى أن يكون قادرًا على القيام بها
• غير الوظيفية: سمات الجودة التي تتعلق بكيفية أداء الموقع
• المتطلب الوظيفي الرئيس (منظور الأعمال): تمكين العملاء من شراء السلع عبر الإنترنت، وهو يلبي الاحتياجات المركزية للأعمال.
• من منظور المستخدم، السماح لهم بـ:
• تصفح المنتجات بحسب الفئة واستكشاف العناصر الفردية
• فحص ميزات المنتج والأسعار والتحقق من مستويات المخزون
• التحقق من شروط التسليم، مثل تاريخ التسليم ورسوم التسليم
• وضع العناصر والكميات المطلوبة في سلة التسوق وإضافة رسوم توصيل
• معالجة الدفع وتأكيد الشراء عبر البريد الإلكتروني
• المعلومات اللازمة: تعريف المدخلات (اختيار العنصر والكمية)، وتعريف العمليات (حسابات مثل إجمالي السلة وتكاليف التسليم)، وتعريف المخرجات (الاتصال بخدمة الدفع وإرسال التأكيد والطلب للتوزيع).
• المتطلبات غير الوظيفية للموقع:
• وقت الاستجابة، مثل سرعة تحميل الصفحات
• قابلية التوسع: التعامل مع أحجام مختلفة من حركة المرور
• أمان الموقع: تسجيل دخول آمن كالمصادقة الثنائية، واختبار الموقع بانتظام للتأكد من خلوه من نقاط الضعف
• استخدام التشفير لحماية البيانات الحساسة مثل التفاصيل الشخصية وكلمات المرور
• أخرى:
• سهولة الاستخدام: تنقل بسيط بتقليل النقرات غير الضرورية، وواجهة بديهية ومتسقة
• الموثوقية: معالجة الأخطاء حتى لا يتعطل الموقع، ونسخ احتياطي وخطة لاستعادته وبياناته
• سهولة الوصول: يستطيع الأفراد ذوو الإعاقة استخدام الموقع
• التوافق: العمل على أجهزة محمولة ومتصفحات مختلفة مثل ⁦Edge⁩ و⁦Safari⁩ و⁦Chrome⁩ و⁦Firefox⁩
• سهولة الصيانة: وثائق واضحة للمطورين والصيانة، وتحكم واضح في الإصدار
• أهميتها: تنطبق على تطوير البرامج وتطبيقات الأجهزة المحمولة والبنية التحتية والشبكات، وتسهم في الاستقرار ورضا المستخدم ونجاح المشروع.

الأدوار في فريق المشروع

• الأدوار: يتكون فريق المشروع من أدوار مختلفة، وليس بالضرورة شخص لكل دور، وقد يؤدي الشخص أكثر من دور، فالمطور الرئيس يكتب الكود وقد يشارك في الاختبار.
• مدير المشروع: يشرف على المشروع، وقد يكون غير تقني، لكن لديه خبرة في إدارة المشروع وأصحاب المصلحة.
• تطوير خطط المشروع: النسخة النهائية من الخطة، وتحديد الجداول الزمنية وتخصيص الأنشطة وتوثيق المشروع
• إدارة أصحاب المصلحة وإيجاد حل وسط بين الاحتياجات المتضاربة بمهارات الاستماع والتفاوض
• إدارة الاتصالات عبر الفريق: يتحقق من تقدم كل فريق فرعي ويمرر الرسائل بينهم
• إدارة الأفراد في الفريق ضمن مدة المشروع، ولهم غالبًا مدير منفصل يتحمل المسؤولية النهائية ويجري المراجعات السنوية
• إدارة المخاطر: يُتوقع من المدير تحديد المخاطر والمشكلات ثم التخفيف أو إيجاد حل.
• التعامل مع النزاعات: يساعد الأعضاء على حل النزاعات قبل تفاقمها.
• إدارة تسليم المنتج النهائي: يشرف على التسليم إلى العميل/مالك المنتج والمستخدمين، ويتأكد من اكتمال الوثائق وأدلة المستخدم وتحديث الوثائق الفنية.
• مهندس النظام: محيط بالأجهزة والبنية التحتية التي ستدعم المنتج، ودوره ضروري حتى في تطبيق برمجي أو جوال.
• مع الأجهزة والبنية الحالية: يتحقق أن التصميم متوافق مع التقنيات الحالية
• مع الجديدة: يضمن أن يكون تصميم التكنولوجيا مناسبًا لمتطلبات النظام
• مهندس الإلكترونيات: تحتوي معظم الأجهزة على لوحات دوائر تشغّل برامج محددة، فيعمل مع مطوري البرامج.
• مهندسو الإلكترونيات يصممون المكونات والدوائر والأنظمة
• مطورو البرامج يبرمجون الواجهات ويطورون البرامج لإدارة البرامج الثابتة

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

• فريق المطورين: يعملون معًا لإيجاد أفضل حل.
• الاختبار: يختبر المطورون كل وحدة أو مكون مكتمل، غالبًا ببيانات وهمية يختارونها.
• مثال: إذا كان الإدخال بين قيمتين (10 و20) اختاروا 9 و10 و15 و20 و21، وقيمًا يجب رفضها كالأحرف والرموز.
• في النهاية: يُختبر النظام كله بالبيانات الحقيقية المقدمة من العميل عبر مالك المنتج.
• قائد اختبار ضمان الجودة ⁦(QA)⁩: أحد أكثر المشاركين خبرة في فريق الاختبار، يتحمل مسؤولية إنشاء خطط الاختبار وإعداد حالات ومجموعات الاختبار.
• التفويض: يفوّض العمل إلى أعضاء فريق الاختبار ويوجّه المختبرين المبتدئين.
• أخصائي اختبار ضمان الجودة: يجرون اختبارات تغطي المتطلبات الوظيفية وغير الوظيفية، ويجب تخطيطها وتنفيذها بعناية.
• الاختبار الوظيفي: يؤكد أن المنتج يقوم بالغرض المراد منه، ويمكن ببيانات وهمية.
• الاختبار غير الوظيفي: يُجرى مع المستخدمين للتحقق من رضاهم عن جوانب مثل أداء البرنامج وسهولة استخدامه.
• تسجيل النتائج: يسجل المختبر نتائج الاختبار ويثبت الإصلاحات المطلوبة في خطة الاختبار، وهو نشاط رئيس يسهم في المراجعة النهائية.
• اختبار عام: من المعتاد أن تجري الفرق اختبارًا عامًا للميزات التي اختبرها الأعضاء الآخرون.
• فني دعم تكنولوجيا المعلومات: يسجل ويحل أي مشكلات وأعطال يواجهها المستخدمون، ويدعم فريق المشروع والمستخدمين.
• الحفاظ على تشغيل البنية التحتية وضمان عمل جميع الأجهزة
• تثبيت البرامج وصيانتها، عادةً باستخدام البرامج المصغرة أو الترقية
• تثبيت أنظمة الأمان وصيانتها على الأجهزة وعبر الشبكة
• التصحيحات: تصلح الأخطاء المرتبطة بالأداء وتحسّن أداء البرنامج أو نظام التشغيل، وقد توفر ميزات أمان إضافية.

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

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

تمرين تقييمي: شرائح عن الشلال

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

دراسة حالة: نظام واحد لعملاء الشركات المدمجة

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