تخطيط برنامج التدريب Internship في 12 أسبوعاً

في المقال السابق من هذه السلسلة عرفنا لماذا تحتاج الشركة برنامج تدريب Internship، وما أنواعه، وما الذي يجعل أغلب البرامج تفشل. وأكثر أسباب الفشل التي ذكرناها تحدث قبل أن يصل المتدرب Intern أصلاً: لا يوجد مشروع واضح، والمشرف Mentor عرف بالموضوع يوم الأحد الذي وصل فيه المتدرب، ولا أحد يعرف ماذا يعني «نجح البرنامج». لذلك فهذا المقال عن العمل الذي يحدث قبل اليوم الأول، فسوف نبني خطة برنامج تدريب لعشرة إلى اثني عشر أسبوعاً لفريق تقني صغير أو متوسط، من الأهداف والميزانية إلى خطة كل أسبوع، مع القوالب التي تحتاجها.

المواضيع في السلسلة:

• لماذا تحتاج شركتك برنامج تدريب Internship؟
• تخطيط برنامج التدريب Internship في 12 أسبوعاً (الموضوع الحالي)
• إدارة المتدربين Interns من الاستقطاب إلى قرار التوظيف
• برامج تدريب في شركات تقنية: ماذا نتعلم منها؟

وسوف نناقش في هذا المقال ما يلي:

• أهداف البرنامج ومؤشرات قياسه KPIs، وكيف تحسب كل مؤشر.
• بنود الميزانية Budget، وأكبرها الذي لا يظهر في الفاتورة: وقت المشرفين.
• اختيار المشرفين Mentors وتدريبهم، والفرق بين المشرف والمدير والرفيق Buddy.
• اختيار مشروع حقيقي محدد النطاق Scoped Project، مع قالب لتحديد النطاق.
• خطة الاثني عشر أسبوعاً أسبوعاً بأسبوع: الاستقبال Onboarding، وأول طلب دمج Pull Request، ومراجعة منتصف البرنامج، ويوم العرض Demo Day.
• قوالب Templates جاهزة للنسخ.

ماذا تريد الشركة من البرنامج؟ الأهداف Goals أولاً

قبل أن تكتب إعلاناً أو تختار متدرباً عليك أن تكتب في سطر أو سطرين لماذا تقيم الشركة هذا البرنامج، والسبب أن كل قرار بعد ذلك يعتمد على هذا السطر: فالبرنامج الذي هدفه التوظيف Hiring Pipeline يختار متدربين في سنتهم الأخيرة ويقيمهم بمعايير الوظيفة، والبرنامج الذي هدفه خدمة المجتمع أو بناء اسم الشركة Employer Brand بين الطلاب يقبل طلاباً في سنواتهم الأولى ويقيس شيئاً آخر تماماً. والخطأ الشائع أن تكتب الأهداف كلها معاً، فتخرج بأهداف لا يمكن قياس أي منها.

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

• مصدر للتوظيف Hiring Pipeline: تعرف المهندس الجديد اثني عشر أسبوعاً قبل أن تعرض عليه وظيفة، وهذا أدق من أي مقابلة.
• إنجاز عمل مؤجل Backlog: مشروع مفيد لم يجد الفريق وقتاً له، بشرط ألا يكون على المسار الحرج Critical Path كما سيأتي.
• تطوير المهندسين الحاليين: الإشراف Mentoring أول تجربة إدارة لكثير من المهندسين، وهو طريقة آمنة لاختبار من يصلح لقيادة فريق لاحقاً.
• اسم الشركة بين الطلاب Employer Brand: المتدرب الذي خرج بتجربة جيدة يتحدث عنها في جامعته، والذي خرج بتجربة سيئة يتحدث عنها أكثر.

مؤشرات القياس KPIs وكيف تحسبها

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

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

الميزانية Budget: ما الذي يكلفه البرنامج فعلاً؟

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

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

ساعات الإشراف لكل متدرب = عدد الأسابيع × ساعات المشرف في الأسبوع
                          + ساعات الاستقبال في الأسبوع الأول
                          + ساعات المقابلات للاختيار

مثال تخطيطي لمتدرب واحد في برنامج 12 أسبوعاً:
  12 أسبوعاً × 5 ساعات         = 60 ساعة
  الأسبوع الأول (إضافي)         = 8 ساعات
  المقابلات (3 مرشحين × ساعتان) = 6 ساعات
  المجموع                       = 74 ساعة من وقت مهندس متوسط أو خبير

التكلفة = 74 × تكلفة ساعة المهندس عندك

في الحساب أعلاه لاحظ التالي:

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

اختيار المشرفين Mentors وتدريبهم

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

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

من يصلح أن يكون مشرفاً؟

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

تدريب المشرفين قبل البرنامج

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

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

اختيار مشروع حقيقي محدد النطاق Scoped Project

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

معايير المشروع الجيد

• له مستخدم حقيقي: شخص أو فريق ينتظره ويستطيع أن يقول في يوم العرض إنه سوف يستخدمه.
• جزؤه الأساسي ينتهي في ثمانية أسابيع: من اثني عشر أسبوعاً، والسبب أن الأسبوعين الأولين للاستقبال والتصميم، والأسبوعين الأخيرين للتوثيق والعرض، وأي مشروع يحتاج الاثني عشر كلها سوف يتأخر.
• يقسم إلى مراحل Milestones: مرحلة أساسية MVP يجب أن تنتهي، ومرحلة إضافية Stretch Goal لمن ينجز مبكراً، حتى لا يفشل المشروع كله إذا تأخر جزء.
• يمر بنفس طريق الفريق: نفس المستودع Repository ونفس مراجعة الكود Code Review ونفس خط النشر Pipeline، فالمتدرب يتعلم كيف يعمل الفريق فعلاً لا في نسخة معزولة.
• لا يحتاج صلاحيات خطرة: لا وصول مباشر إلى قاعدة بيانات الإنتاج أو بيانات العملاء الحقيقية، واستخدم بيانات اختبار Test Data.

وكتابة نطاق المشروع تشبه كتابة المتطلبات لأي ميزة، فإذا أردت التفصيل فقد شرحنا في مثال المتطلبات العملي كيف تحول فكرة غامضة إلى بيان مشكلة Problem Statement ومعايير قبول Acceptance Criteria، وتجد في فقرة القوالب قالباً مختصراً لنطاق مشروع المتدرب.

خطة الاثني عشر أسبوعاً أسبوعاً بأسبوع

الصورة التالية تبين الخطة كاملة، ثم نفصل كل مرحلة:

الأسبوع صفر: التحضير قبل الوصول

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

• الجهاز والحسابات: البريد، والمستودع Repository، وأداة المهام، وقناة المحادثة، وحساب بيئة التطوير Development Environment.
• مهمة أولى صغيرة جاهزة بعلامة good-first-issue: إصلاح صغير أو تحسين رسالة خطأ، يمكن دمجه في يومين.
• قالب نطاق المشروع مكتوب ومراجع من المشرفين الآخرين.
• جدول الأسبوع الأول مرسل للمتدرب قبل وصوله.

الأسبوع الأول والثاني: الاستقبال Onboarding وأول طلب دمج

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

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

الأسبوع الثالث إلى الخامس: المرحلة الأساسية

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

الأسبوع السادس: مراجعة منتصف البرنامج Mid-point Review

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

الأسبوع السابع إلى العاشر: إكمال المشروع

يكمل المتدرب المرحلة الأساسية ويبدأ الإضافية إذا سمح الوقت، ويقلل المشرف تدخله تدريجياً، فبدلاً من أن يقترح الحل يسأل «ما الخيارات التي أمامك؟»، والسبب أن جزءاً من قرار التوظيف هو هل يستطيع المتدرب أن يعمل بقدر أقل من التوجيه، ولن تعرف ذلك إذا بقيت تمسك يده حتى النهاية. وفي هذه الفترة اجعله يعرض تقدمه مرة واحدة في اجتماع الفريق أو في عرض نهاية السبرنت Sprint Review.

الأسبوع الحادي عشر والثاني عشر: التوثيق ويوم العرض Demo Day

لا تقم بإضافة ميزات في الأسبوعين الأخيرين، فهما للتسليم Handover: توثيق Documentation يكفي لمن سيصون الكود بعد خروج المتدرب، واختبارات Tests للمرحلة الأساسية، ونقل أي عمل لم يكتمل إلى مهام واضحة في أداة الفريق. ثم يوم العرض Demo Day، وفيه يعرض كل متدرب مشروعه في عشر دقائق أمام الفريق ومستخدم المشروع وإدارة الهندسة، ويركز على المشكلة وما بناه وما تعلمه وما لم يكتمل. ويقدم المشرف تقييمه النهائي المكتوب في نفس الأسبوع، ويعقد اجتماع القرار قبل خروج المتدرب، وتفاصيل التقييم والقرار والعرض الوظيفي في المقال القادم.

إذا كان البرنامج عشرة أسابيع

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

القوالب Templates

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

وثيقة البرنامج Internship Plan في صفحة واحدة

برنامج التدريب | الدورة: صيف ....  | المنسق: ...  | تاريخ آخر تعديل: ...

الهدف الرئيسي: (مثال: مصدر توظيف لمهندسي Backend مبتدئين)
الهدف الثانوي: (مثال: تجربة إشراف أولى لمهندسين متوسطين)

المدة: .... أسبوعاً   | من .... إلى ....
النوع: صيفي / تعاوني Co-op / تمهير / غير ذلك: ....
العدد: .... متدربين  | الفرق: ....

المؤشرات KPIs والهدف لكل منها:
  نسبة الإكمال ............ الهدف: ....
  المشاريع المسلمة ........ الهدف: ....
  نسبة العروض ............. (لا هدف ثابت، تقرأ مع ما سبق)
  رضا المتدربين (0 إلى 10)  الهدف: ....
  البقاء بعد سنة ........... يقاس في: ....

الميزانية:
  المكافآت .......  الأجهزة والتراخيص .......  الاستقطاب .......
  ساعات الإشراف المخططة: .... ساعة (عدد الأسابيع × ساعات الأسبوع + الاستقبال + المقابلات)

المشرفون والمشاريع:
  المتدرب 1 | المشرف: .... | المشرف المساعد: .... | الرفيق: .... | المشروع: ....
  المتدرب 2 | ...

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

المتطلبات النظامية (تملؤها الموارد البشرية من المصادر الرسمية):
  نوع العقد أو الاتفاقية: ....  | التأمين: ....  | الجهة الخارجية (جامعة أو برنامج): ....

قالب نطاق مشروع المتدرب Project Scope

مشروع المتدرب | الاسم المقترح: ....  | المشرف: ....  | الفريق: ....

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

المرحلة الأساسية MVP (يجب أن تنتهي في الأسبوع ....):
  - ....
  معيار القبول Acceptance Criteria: ....
المرحلة الإضافية Stretch Goal (إن سمح الوقت):
  - ....

خارج النطاق Out of Scope:
  - ....

المستودع Repository: ....   | خط النشر Pipeline: نفس خط الفريق؟ نعم / لا
البيانات: بيانات اختبار Test Data فقط، لا وصول لبيانات الإنتاج
الصلاحيات المطلوبة: ....

المخاطر: ما الذي قد يجعل المشروع أكبر من المتوقع؟
أول مهمة صغيرة (good-first-issue) للأسبوع الأول: ....

مراجعة المشرفين الآخرين: هل ينتهي الجزء الأساسي في 8 أسابيع؟  نعم / لا / بعد التعديل

دليل المشرف Mentor Guide المختصر

دليل المشرف | يقرأ قبل اليوم الأول

قبل الوصول:
  [ ] الجهاز والحسابات جاهزة (تأكد بنفسك، لا تفترض)
  [ ] أول مهمة صغيرة جاهزة ويمكن دمجها في يومين
  [ ] قالب نطاق المشروع مراجع
  [ ] موعد 1:1 الأسبوعي في التقويم لكل أسابيع البرنامج
  [ ] خفضت التزاماتك في السبرنت بقدر 5 ساعات في الأسبوع

كل يوم (10 إلى 15 دقيقة):
  - هل هناك سؤال ينتظر إجابة؟ هل هناك طلب دمج ينتظر مراجعة أكثر من يوم؟

كل أسبوع:
  - اجتماع 1:1 لمدة 30 دقيقة (القالب في المقال القادم)
  - سطران في سجل الأدلة: ما الذي أنجزه، وموقف يدل على كفاءة أو مشكلة

قواعد المراجعة Code Review مع المتدرب:
  - اشرح السبب في كل تعليق، وفرق بين «يجب» و«رأي»
  - لا تكتب الكود بدلاً منه، واسأل «ما الخيارات؟» قبل أن تقترح

متى ترفع الأمر للمنسق:
  - لم يدمج إلا طلبه الأول بنهاية الأسبوع 3
  - غياب متكرر أو مشكلة سلوك
  - اتضح أن المشروع أكبر من 8 أسابيع
  - لم تستطع الوفاء بساعات الإشراف أسبوعين متتاليين

في النهاية:
  - التقييم النهائي على نفس المعيار Rubric قبل يوم العرض بيومين
  - توصيتك: عرض / لا عرض / غير متأكد، مع الأدلة

أخطاء شائعة في التخطيط

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

الخلاصة

وصلنا لنهاية الموضوع الثاني في السلسلة، وأهم ما فيه:

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

وفي المقال القادم بإذن الله سوف ندير البرنامج نفسه: من استقطاب المتدربين واختيارهم بعدل، إلى الاجتماع الأسبوعي ومعيار التقييم Rubric وقرار التوظيف والعرض الوظيفي، مع مقارنة الأدوات بأسعارها.

سجل التحديثات

• أكتوبر 2026: كتابة المقال مع خطة اثني عشر أسبوعاً وبديل من عشرة أسابيع، وقوالب وثيقة البرنامج ونطاق المشروع ودليل المشرف، ورسم للخطة الزمنية.