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

يميل بعض الأشخاص إلى التأخر عن مواعيدهم. قد يكون هذا التأخير إما لبضعة دقائق بالمصادفة أو مرتين فقط خلال الأسبوع. ولكنهم غالبًا ما يتأخرون في تحقيق جداول المواعيد اليومية. (من جهة أخرى وباعتبار أن التبرؤ من أمر ما هو مهارة هامة يتقنها البشر، فإنني سأتفهم رفضك للاعتراف بأن هذا التصريح ينطبق عليك). وكذلك يتأخر طلاب المدرسة الثانوية عن صفوفهم والكبار عن اجتماعاتهم في العمل، كما أن الأصدقاء يصلون متأخرين مدة عشر دقائق عن المواعيد. يبدو أن هذا يحدث لأن اعتقادنا الضمني أن الحفاظ على المواعيد لا يعني الوصول في لحظة محددة، وإنما في مجال زمني، ويكون هذا المجال أكثر اتساعًا لدى بعض الناس من غيرهم. ومن الأمثلة المهمة عن هذا الموضوع هو عدد المضيفين الذين يرحبون بنا في المطاعم قائلين إن الطاولة ستكون جاهزة حالاً بينما في الواقع يجب علينا غالبًا أن ننتظر لفترة. إن هذا الاختبار للتأخيرات نجده أثناء الانتظار على الهاتف أو الانتظار في عيادة الطبيب، وقد دعانا هذا إلى التطرف في موضوع الجدولة لقد اختبرنا العديد من المواقف في حياتنا التي لم تنجح لهذا السبب. وبالتالي، ليس من المفاجئ أن يتأخر إنجاز العديد من المشاريع، حيث يصل أغلبنا إلى مهمة جدولة المشاريع مع التساؤل عن مدى تحقيق المواعيد في موضوع الاستلام أو التسليم للمهام. حيث إننا نميل عادة لأن نبني تقديراتنا على افتراضات ضعيفة، ونتوقع نتائج العمل بالاعتماد على أفضل الظروف الممكنة، وباعتبار خبراتنا السابقة، نتجنب في الوقت نفسه وضع الكثير من الثقة في أي جدولة نشاهدها أو نوجدها. لماذا نفعل ذلك؟ وكيف يؤثر هذا على جدولة أعمال المشروع؟ ماذا يمكننا فعله لتجنب هذه المشكلات؟ هذا هو موضوع هذا المقال.
لكن قبل أن نكتشف كيف يمكننا تنظيم جدولة بشكل أفضل، علينا أولاً أن نفهم ما المشكلات التي تحلها هذه العملية، وإذا لم تكن موثوقة إلى حد كبير، فلم نزعج أنفسنا بها أصلا؟ إن عملية الجدولة تخدم عدة أهداف مختلفة -يركز بعض منها فقط على قياس استغلال الوقت.
الجدولة لها ثلاثة أهداف
تخدم كل جدولة، سواء كانت من أجل التخطيط لحفلة نهاية الأسبوع، أم من أجل تطوير موقع انترانت، ثلاثة أهداف أساسية؛ الأول، وهو الأكثر شيوعًا، هو تحديد الالتزامات تجاه موعد إنجاز العمل. حيث تقدم الجدولة صيغة لعقد بين جميع المشاركين في فريق العمل أو في المنظمة، ليؤكد على ما سيقوم به كل شخص في الأسبوع أو الشهر أو العام القادم. عندما يفكر الناس عادة بجدولة المشروع، فإن هذا هو الهدف الأول الذي يخطر لهم.
غالبًا يكون الهدف من الجدولة خارجيًا، فتركيزها خارج مجال فريق العمل أكثر من تركيزها عليه، لأنها تساعد على إتمام الصفقة أو الخضوع إلى الزمن المحدد من قبل الزبون. فالزبون يدفع غالبًا مقابل زمن التسليم بالإضافة إلى دفعه مقابل الخدمة المقدمة (فكر بـ FedEx أو UPS). ومن أجل تسهيل وضع الخطط بالنسبة للزبائن أو الشركاء من أجل مشروع معين، يجب أن يتم الاتفاق فيما بينهم على زمن إنجاز أشياء محددة.
إن الهدف الثاني من الجدولة هو تشجيع كل شخص مساهم في المشروع على أن يرى جهوده جزءًا من العمل الكلي، واستثمار موضوع جعل أجزاء عمل هذا الشخص تتوافق مع عمل الآخرين. وإلى أن يتم إيجاد مسودة للجدولة تقترح تواريخ وأزمنة محددة لجاهزية الأعمال، فإنه على الأغلب لن يتم فحص العلاقات والارتباطات بين الأشخاص أو فرق العمل وإنما سيعمل كل شخص على إنجاز مهمته الخاصة، دون أن يفكر كيف سيؤثر عمله على الآخرين.
فقط عندما يتم تدوين التفاصيل وإلى جانبها أسماء الأشخاص، يمكن إجراء الحسابات وفحص الافتراضات. إن هذا ينطبق أيضًا على فرق العمل الصغيرة أو على الأشخاص الذين يعملون بمفردهم. تحتوي الجدولة على طاقة نفسية تؤدي إلى توسيع وتضخيم الالتزام المزمع عقده. بدلاً من أن تتراكم التواريخ والالتزامات فقط في ذاكرة أحد الأشخاص، فهي تسجل وتكون موجودة عند الجميع، كل بمفرده. ولن يكون من السهل حينها نسيان أو تجاهل أي شيء إذا كان مسجلاً على لوح أبيض موجود في الممرات ليذكرك أنت أو أعضاء الفريق بما يجب إنجازه. وبالنسبة لمدراء المشاريع خاصة: فإن وجود نسخة من الجدولة تساعد على طرح أسئلة عن مدى واقعية أمور معينة، وكذلك على إجراء مقارنات بين ما هو مطلوب من المشروع تحقيقه باستخدام ما يبدو ممكنًا إنجازه في فترة محددة من الزمن.
تسمى هذه الإزاحة أو الضغط النفسي بالوظيفة القسرية، وهي أن أي شيء -عندما يحين أوانه- يفرض بشكل طبيعي التغيير في وجهة النظر أو السلوك أو التصرفات. وبالتالي فإن جدولة هي إجراءات قسرية هامة للمشاريع. وإذا استخدمت بالشكل المناسب من قبل المدراء فإنها تجبر أي شخص له مهمة محددة ضمن الجدولة أن يفكر بعناية بما يجب أن يفعله وكيف يمكن ملاءمته مع أعمال الآخرين. إن هذا الإدراك للعلاقة بين الأجزاء يعتبر مستقلاً نوعًا ما عن الجدولة بحد ذاتها. كما يعتبر هذا الإجراء القسري خطوة حرجة بالنسبة إلى إدراك إمكانيات المشروع. ولو انزلقت الجدولة أو تمت مضاعفتها أو تنصيفها أو خضعت للعديد من التعديلات الهامة، فإن الالتزامات والعلاقات التي شكلها كل شخص مع الآخرين ستبقى كما هي. وبالتالي يمكن تحقيق الهدف الثاني من الجدولة وكذلك فهي تستحق كليًا الجهود المبذولة لتشكيلها، ولو كانت هذه الجدولة بحد ذاتها ليست دقيقة. فإذا تم إنجاز المشروع مثلاً متأخرًا جدًا، فإن وجود الجدولة سيكون بمنتهى الأهمية للمساعدة في الوصول إلى نهاية المشروع أصلاً.
إن الهدف الثالث للجدولة هو إعطاء فريق العمل أداة لمتابعة التقدم في العمل وتقسيمه إلى أجزاء يمكن إدارتها. إن تقسيم العمل إلى أعمال تحتاج إلى يوم أو يومين يساعد الأشخاص فعليًا في إدراك العمل الذي يجب عليهم إنجازه. تخيل أنه في مشروع بناء منزل، كتب المقاول في أحد البنود: «منزل: 120 يوم»، بمثل هذا التقسيم البسيط سيصعب على أي شخص حتى المقاول نفسه إدراك ما الأشياء التي يجب إنجازها أولاً، أو أي من بنود الأعمال هي الأكثر تكلفة أو استهلاكًا للوقت. بينما إذا تمكن المقاول من تأمين نشاطات مقسمة أسبوعيًا سيسهل على الجميع استيعاب أزمنة إنجاز المهام، وسيتسنى لكل عضو في فريق العمل فرصة أكبر لطرح أسئلة هامة واستيضاح الاقتراحات. من وجهة نظر مدير المشروع فإن الجدولة الجيدة تعطي نظرة أوضح عن المشروع والتحديدات والرؤى، وتزيد من احتمالات حدوث الأمور الجيدة.
كلما ازداد حجم وتعقيد المشروع، ازدادت أهمية الجدولة. حيث تزداد في المشاريع الكبرى الارتباطات بين الأشخاص، وكذلك تزداد احتمالات تأثر القرارات والأزمنة بعضها ببعض. عندما يعمل عندك مجموعة صغيرة من الأشخاص، فإن احتمالات إدراك كل فرد للمشكلات الموجودة في أعمال الآخرين تكون أعلى بكثير. إن انزلاق الجدولة في عمل الفرق الصغيرة ليس بالأمر الجيد، ولكنه في مثل هذه الحالة، يمثل الانزلاق بفترة نصف يوم أو بالمزيد من الطاقة لفترة نصف يوم بالنسبة لثلاثة أشخاص فقط، وعندها يكون التعويض ممكنًا. حيث يمكن أن يبقى أحد الأشخاص في مكان العمل حتى وقت متأخر ليوم واحد أو إذا دعت الحاجة، يمكن أن يأتي جميع أعضاء الفريق ويتفقوا على المساعدة في تعويض الوقت. بينما في المشاريع الأكبر، والتي تضم عشرات أو من مئات الأشخاص والمكونات، يمكن أن يتتابع تأخير يوم واحد ويخلق مشكلات بكل الأشكال غير المتوقعة، والتي تكون غالبًا غير قابلة للتعويض من قبل أعضاء الفريق. في كلتا الحالتين (الفرق الكبيرة والصغيرة)، فإن الجدولة تعطي للمدراء والمسؤولين الماليين الفرصة لطرح الأسئلة، وإجراء التعديلات ومساعدة الفريق على مواجهة المشكلات والاستجابة لها فور حدوثها.
باستيعاب هذه الأفكار الثلاثة يسهل اكتشاف أن الجدولة المثالية لا تحل جميع المشكلات الموجودة في المشروع، فالجدولة لا يمكنها معالجة التصميم السيئ أو المهارات الهندسية السيئة، كما لا يمكنها حماية المشروع من القيادة الضعيفة أو الأهداف غير الواضحة أو الاتصالات الضعيفة. وبالتالي، بقدر ما تستغرقه الجدولة من وقت، فإنها تبقى عبارة عن لوائح من الكلمات والأرقام، واستخدامها كأداة لإدارة وقيادة المشروع يبقى تابعًا لكل شخص. مع تذكر هذا، نجد أنه قد حان الوقت لشرح المفردات الهامة واستكشاف المنهجيات البرمجية- وهي الآليات الهامة في إدارة المشروع.
المنهجيات والحلول
توجد أنظمة عديدة مختلفة لكيفية التخطيط وإدارة التطوير البرمجي، تدعى عادةً بالمنهجيات. وهي تعني مجموعة من التمارين التي تهدف إلى تحقيق نوع معين من النتائج. من هذه الطرق الشائعة: نموذج الشلال، النموذج اللولبي، تطوير التطبيقات السريع، البرمجة القصوى والتطوير المقود بالمزايا. تحاول كل هذه الطرق حل مشكلات المنظمات ومشكلات إدارة المشاريع المتشابهة. وكل منها له نقاط قوة ونقاط ضعف، ويتطلب اتخاذ القرار بشأن أيها الأنسب لكل نوع من المشاريع، الخبرة أم المعرفة.
إن هدفي من هذا الفصل، وفي هذا الكتاب، ليس مناقشة ومقارنة الأنظمة والمنهجيات المختلفة لإنجاز الأشياء. وإنما أؤمن أن هناك مفاهيم وأمورًا تكتيكية ما وراء هذه الأنظمة يجب إتقانها واستيعابها من أجل إنجاح أي منها. في جميع الحالات، تحتاج المنهجيات إلى الضبط والملاءمة لتتناسب تحديدات الفريق والمشروع، ويكون هذا ممكنًا فقط إذا كان لديك أساس للمعرفة أعمق من المنهجيات بحد ذاتها. وبالتالي إذا تمكنت من استيعاب الأفكار الأساسية المشروحة في هذا الفصل وسائر الكتاب والتمرن عليها، فإن احتمالات فعاليتك ستزداد بغض النظر عن المنهجية التي تستخدمها. سوف أشرح نواح من طرق معينة عندما تدعو الحاجة إلى توضيح النقاط، ولكن إذا كنت مهتمًا باعتماد إحدى المنهجيات عندها عليك أن تبحث في مكان آخر.
على الرغم من شدة أهمية الطرق والعمليات للتطوير البرمجي فهي ليست شروطًا أو أنها بحد ذاتها تشكل حلولاً أو مسببات للنتائج الناجحة. إن أسوأ ما في الأمر هو الإتباع الأعمى لمجموعة من القواعد والإجراءات التي يكون من الواضح أنها لن تنجح، فقط لأنها ظهرت في كتاب مشهور أو نصح بها أحد المرشدين المحترمين. لقد اكتشفت وبثقة أن الهوس بالإجراءات هو إشارة تحذير من وجود مشكلة في القيادة. إنها قد تكون محاولة لتخفيف حمل التحديات والمسؤوليات الطبيعية التي يواجهها المدراء ضمن نظام من الإجراءات والبيروقراطية التي تشوش الحاجة إلى التفكير والأفعال الحقيقية. قد يكون الأمر الأكثر إحباطًا لفريق العمل هو أن تثبيت المنهجية يمكن أن يشير إلى ما اهو مهم فعليًا للمنظمة، كما أشار Tom DeMarco في كتابه «النواحي البشرية في تقنية المعلومات».
إن الهوس بالمنهجيات في مجال العمل هو مثال آخر عن وهم التقنية العالية، فهو ينتج عن الاعتقاد أن التقنية هي المهمة… ومهما كانت فائدة التقنية فهي قد تكون ثمنًا فقط للإساءة الكبيرة إلى نفسية فريق العمل.  
بالتركيز على الإجراءات والطرق بدلاً من بناء الإجراءات التي تدعم وتضخم القيمة الناتجة من الأشخاص، فإن المشاريع تبدأ بعملية الجدولة بالحد من مساهمة الأفراد. يمكنهم وضع آلاف من القواعد وواجبات إتباعها بدلاً من التفكير وضبط القواعد أو تحسينها. لذلك كن شديد الحذر إزاء كيفية تطبيق أي منهجية تستخدمها، حيث يجب ألا تلحق الضرر بالفريق، وإنما أن تدعم وتشجع وتساعد الفريق على القيام بعمل جيد في المشروع.
لذلك تذكر أن استخدام هذه التقنية أو تلك ليس هو السبب الوحيد ليلتزم أو يضيع المشروع تواريخه المحددة. وإنما هناك عوامل تؤثر على كل جدولة المشروع وعلى مدراء المشروع أن يتفهموها قبل إجراء أي جدولة للعمل. ولكن قبل أن نتكلم عن ذلك علينا أن نناقش مكونات الجدولة.
كيف تبدو الجدولة
يوجد اختصار أساسي وحيد لحل جميع المشكلات في الجدولة المشابهة للمشكلات القديمة، وهو قاعدة التقسيم الثلاثي. وهي عبارة عن أمر تقديري للغاية يعتمد بشدة على التخطيط العفوي، ولكنها تعتبر أبسط طريقة لتقريب واستيعاب فكرة الجدولة. إذا كنت خبيرًا بهذا الموضوع هيئ نفسك للتراجع، لأنني سأبسط العملية كاملة إلى أقصى درجة، وسوف أقوم بهذا لأؤمن أبسط قاعدة ممكنة للحديث عما يميل للذهاب بالاتجاه الخاطئ، ولم يحدث هذا وما الذي يمكن فعله حيال ذلك.
فيما يلي شرح لكيفية عمل النموذج الفائق البساطة لجدولة العمل: قم بتقسيم الزمن المتوفر لأي مشروع إلى ثلاثة أقسام: قسم للتصميم، وقسم للتنفيذ، وقسم للاختبار. إن المنهجية التي تستخدمها قد تؤدي إلى تغييرات في تسميات هذه المراحل، أو أنها قد تتداخل بعضها ببعض بطريقة ما، ولكن جميع المنهجيات فيها أوقات مخصصة لهذه النشاطات الثلاثة. ففي أي يوم ستكون إما مشغولاً بالبحث عما يجب إنجازه (التصميم)، أو تنفيذه فعليًا (وضع شيفرة المنتج)، أو التأكد والتحليل والتحديث لما قد تم إنجازه (الاختبار).
تطبيق قاعدة التقسيم
إن القاعدة الأساسية تفترض أنه في كل يوم تتوقع أن تكتب فيه شيفرة خاصة بالمنتج يجب أن تكون قد قضيت بالمقابل يومًا في تخطيط وتصميم العمل، ويومًا من أجل التخطيط لاختبار وتعديل ذلك العمل. إنها من أبسط ما يكون، وهي طريقة سهلة لاختبار أي جدولة موجودة مسبقًا أو تشكيل جدولة جديدة من البداية. إذا كان الزمن الكلي المتاح ليس مقسمًا تقريبًا إلى ثلاثة أنواع من الأعمال، عندها يجب أن يتم استيعاب أسباب تطلب المشروع لتوزيع غير متساو للجهود.
إن عدم التوازن في قاعدة التقسيم الثلاثي ولنقل أنه تم تخصيص 20% من الوقت زيادة للاختبار عن التنفيذ، يبقى مقبولاً طالما أن الجميع في حالة توازن.
لنعتبر حالة تطوير موقع وب افتراضي: إذا أتيح لك ستة أسابيع لإنجازه، فإن أول خطوة يجب أن تتم هي تقسيم ذلك الزمن بشكل تقريبي  إلى ثلاثة أقسام، وإجراء حسابات الزمن المحتمل لانتهاء العمل باستخدام هذه التقسيمات. إذا لم يؤمن هذا التقسيم الزمن الكافي للقيام بالعمل المطلوب على أعلى مستوى، إذن هناك خطأ ما أساسي. إما أن الجدولة بحاجة إلى تغيير أو أن مقدار العمل المتوقع إنجازه بحاجة إلى تخفيض (أو يجب تخفيض أي من التوقعات عن الجودة). إن التخفيض في زمن التصميم أو الاختبار سيزيد فقط من احتمالات أن الوقت المصروف فعليًا على كتابة الشيفرة سوف يستخدم بشكل خاطئ أو سينتج عنه شيفرة من الصعب إدارتها أو التعامل معها. إن فائدة قاعدة التقسيم الثلاثي عندئذ تكون في أنها تفرض على المشاريع حالة التساوي بين الربح والخسارة. إن إضافة المزايا الجديدة تتطلب أكثر من مبرمج لتنفيذ ذلك، ولكن هناك تكاليف للتصميم والاختبار لا يمكن تجنبها، ويجب أن يدفعها شخص ما. عندما تتعرض الجدولة للإزاحة، فإن هذا يكون بسبب وجود تكاليف مخفية، أو تم تجاهلها لم تؤخذ بالحسبان. 
التطوير المرحلي (مشروع مضاد المشروع)
إن هدف الوصول إلى الكمال يستحق أن نأخذ بالاعتبار أبسط حالة ممكنة، وهي أنه لا يوجد مشروع. يتم إنجاز كل العمل على مراحل -وهذا يتطلب إنجاز العمل ومن ثم تقويمه مقارنة بأعمال أخرى وبعدها وضعه في أول فراغ متوفر ضمن الجدولة. تعمل بعض فرق التطوير أو مطوري مواقع الوب أو المبرمجين المعلوماتيين بهذا الشكل. فنادرًا ما تقوم مثل هذه المنظمات بإجراء استثمارات أو التزامات بقيم متزايدة كبيرة. تنصح غالبًا هذه الفرق بطرق سهلة وسريعة (سنناقشها لاحقًا) باعتبارها أكثر الأنظمة طبيعية من أجل تنظيم العمل، حيث تؤكد هذه الطرق على المرونة والبساطة وتوقعات التغيير. فإذا كنت تعمل على إنجاز عدة مهام صغيرة (لا على مشاريع) في بعض الأوقات، عليك حينها أن تستنتج ما تحتاجه من توسيع الأمثلة عن المشاريع المركزية التي استخدمها في هذا الكتاب.
من جهة أخرى فإن قاعدة التقسيم الثلاثي تنطبق على مثل هذه الحالات، لو عمل كل مبرمج على حدة من أجل تنفيذ مهام صغيرة، فقد يقضي ثلث وقته الكلي في استكشاف ما يجب القيام به، وثلثه الآخر في إنجازه، والثلث الأخير من أجل التأكيد أن ما قام به يعمل بالشكل المناصب. إنه قد يتأرجح إلى الأمام والخلف بين هذه الاستخدامات للوقت، ولكن باعتبارها طريقة تقريبية لاستيعاب أي نوع من أنواع العمل، فإن قاعدة التقسيم الثلاثي تنطبق على جميع المقاييس.
التقسيم والسيطرة
(الجدولة الكبيرة = العديد من الجدولة الصغيرة)
إذا تأملت أغلب منهجيات التطوير البرمجي، يمكنك أن ترى الخطوط الأساسية لقاعدة التقسيم الثلاثي. قد تختلف الأهداف الخاصة والطرق المستخدمة في تصميم أو تنفيذ الأشياء بشكل كبير، إلا أنه وعلى أعلى مستوى، فإن النتائج المرجوة تكون متشابهة.
إن الأمر يعتقد عند العمل على المشاريع الأكبر أو ذات الزمن الأطول، حيث تنقسم الجدولة إلى أجزاء أصغر ويكون لكل جزء زمنه الخاص بالتصميم والتنفيذ والاختبار. تدعو منهجية البرمجة الموسعة (المعروفة بـ XP) هذه الأجزاء بالتكرارات، أما النموذج اللولبي فيسميها المراحل، وتدعوها منظمات أخرى بنقاط العلام. وبينما تعتبر البرمجة الموسعة أن هذه الأجزاء الزمنية هي عبارة عن بضعة أسابيع فقط، يعتبرها النموذج اللولبي أشهرًا، ولكن الفكرة الأساسية تبقى نفسها، وهي إيجاد جدولة مفصلة لفترات زمنية محدودة فقط.
كلما كان التغيير ومقدار المخاطرة بحجم التغييرات في قيم معطاة محددة أكثر توقعًا في المشروع، وجب أن تكون نقاط العلام أقصر زمنًا. وهذا يقلل مقدار المخاطرة الكلية في الجدولة لأن الخطة الأساسية تكون قد قسمت إلى أجزاء قابلة للإدارة. إن هذه التقسيمات بين أجزاء الجدولة تؤمن فرصًا طبيعية لإجراء التعديلات وتحسين الفرص بالنسبة لنقطة العلام التالية لكي تكون أكثر دقة.
الطرق السريعة والتقليدية
تفترض طرق البرمجة الموسعة والطرق السريعة الأخرى أن المستقبل دائمًا بحالة مخاطرة، لذلك فهي تراهن على عمليات تصوغ التغيير المباشر بسهولة. إن المشاريع ذات الكلفة العالية للإنتاج (لنقل مثلاً بناء ناطحة سحاب، أو لوحة تحكم بلعبة فيديو، أو نظام تشغيل مبرمج) تذهب في الاتجاه الآخر، وتعتمد بشدة على مهام التخطيط والتصميم. من الممكن أن يحدث ذلك، ولكن يجب على الجميع الالتزام بالقرارات المتخذة في مرحلة التخطيط، وعندها تكون التكاليف العالية جدًا للتغييرات هي الشيء الوحيد المتوقع حصوله.
تقع مشاريع التطوير البرمجي في مكان ما في المنتصف، فهي تحوي تخطيطًا أوليًا، ولكن من أجل إدارة المخاطرات المستقبلية للمتطلبات وطلبات الزبائن، يتم تقسيم العمل إلى مراحل تخصص زمنًا لكل من التصميم والتنفيذ، وضمان الجودة. فإذا طرأ أمر ما جديد يمكن عندها التعامل معه في المرحلة الحالية أو وضعه في دلو العمل ليتم استكشافه واستيعابه بالشكل المناسب في المرحلة القادمة.
إن الزمن المخصص للتخطيط الأولي في معظم المشاريع يستخدم في تجميع مقدارٍ كافٍ من المعلومات من الزبائن والمساهمين بالعمل لتحديد عدد المراحل اللازمة، وعلام يجب التركيز في كل منها. بالاعتماد على الخطة الأكبر، من الممكن أن تخصص لكل مرحلة المزيد من الزمن للتصميم أو الاختبار. كما يمكن أن تنقسم المرحلة إلى مرحلتين أصغر منها (باتجاه نموذج تطوير أسهل وأسرع) أو يمكن أن يتم دمج مرحلتين معًا (باتجاه أسلوب تطوير أكثر تماسكًا). ولكن في جميع الحالات، يجب تخصيص الزمن ضمن المراحل حتى يتم استغلال كل ما قد تغير. إن هذا يتضمن الاستجابة للمشكلات التي ظهرت في المرحلة السابقة، والتي لم يكن من الممكن تحديدها بشكل كامل في تلك المرحلة.
إن هذا هو أبعد مدى سأصل إليه في منهجيات الجدولة عالية المستوى، ولكن التركيز فيهما سيكون على النواحي الإدارية والقيادية -لا على تفاصيل كيفية تطبيقك لمنهجية معينة. فإذا استطعت متابعة الفقرات القليلة السابقة (ولو لم توافق كليًا على النقاط التي عرضتها).
بجميع الأحوال فإنني اعتذر لأي خبرات تطويرية تم تجاهلها، أو أصبحت غير صالحة في هذا المقطع. الآن وباعتبار أنه انتهى، أعدك أن هذه الرؤية البسيطة للجدولة هي تقريبًا كل ما يلزمك لتفهم المفاهيم الموجودة في ما تبقى من هذا المقال.
لم تفشل الجدولة
إن جدولة المشاريع هي أسهل شيء يمكن إلقاء اللوم عليه عندما يتجه أي جزء في المشروع بالاتجاه الخاطئ. فإذا أساء أحدهم التقدير، أو غفل عن مطلب ما، أو اصطدم بالحافلة، فإن السبب هو الجدولة (والشخص المسؤول عنه). وإذا نفد مصدر الطاقة في الدولة لمدة عشرة أيام أو أصيب أحد أفضل المبرمجين في الفريق بفيروس ما، فإن أحدهم سيقول بلا شك «أرأيتم، لقد أخبرتكم أن الجدولة ستفشل» وهو يشير بإصبعه إلى وجه الشخص المسؤول عن هذه الجدولة. إن هذا ليس عدلاً أبدًا، ولكنه يحصل دائمًا. وبقدر ما يبتعد الناس عن الجدولة فإنهم ما يزالون يعتبرونها مقياسًا لا يمكن الوصول إليه. حتى أفضل منظمي هذه الجدولة في العالم، الذين يملكون أذكى الأدمغة وأفضل الأدوات تحت تصرفهم، مازالوا يحاولون التنبؤ بالمستقبل- وهو أمر نادرًا ما يقوم به أشدنا عبقرية، بشكل جيد.
لكن إذا بدأ فريق العمل مشروعًا ما، وهم مدركون بشكل كامل للأسباب التي قد تتجزأ لأجلها الجدولة واتخذوا أفعالاً لتقليص تلك المخاطر، فإن الجدولة يمكن أن تصبح أكثر فائدة، وكذلك فإنها تعتبر أداة مناسبة لعملية التطوير.
التصويب الأعمى من مدى بعيد جدًا جدًا
إذا تم وضع الجدولة في مرحلة التخطيط الأولي، سيكون هناك المئات من القرارات التي قد تؤثر عليها ولم تتخذ بعد. بالإضافة إلى أمور وتحديات لا يمكن لأحد أن يتوقعها، ولا يمكن بأي شكل أن تحلها أي خطة فكرية مبدئية. وحتى يتم استيعاب المتطلبات ويجهز التصميم عالي المستوى جيدًا، فإن مدير المشروع يبقى جاهلاً ولديه القليل جدًا من المعلومات للتوصل إلى تنبؤات واقعية. يتم تشكيل الجدولة ما قبل النهائية، غالبًا باستخدام أرقام مرتبة ونظريات مألوفة، كما يتم تسليم هذا الشيء الذي يمكن برهان عدم صحته بسهولة إلى فريق العمل على أنه خطة موثوقة للمشروع. وغالبًا ما يقع الناس ضحية لفخ الفرق بين الإتقان والدقة: إن الجدولة ذات المظهر الآسر بسبب احتوائها على تواريخ وأزمنة محددة (دقيقة) ليس بالضرورة عكسًا للواقع (الدقة)، فالإتقان سهل ولكن الدقة هي أمر غاية في الصعوبة.
من جهة أخرى، صحيح أن جميع المشاريع والجدولة يجب أن تنطلق من نقطة ما. إلا أنه يمكن استخدام ضربة الحظ لتنشيط فريق العمل وفرض بعض القيود. حيث إنه من الممكن أن يؤدي ذلك إلى بداية عملية التحقيق والبحث لتزويد الجدولة بالتفاصيل وإلى طرح أسئلة هامة والإجابة عليها. ولكن إذا تم استخدام نظريات ذات مدى واسع، غير موثوقة أو غير مختبرة كأساس لجدولة المشروع - دون إجراء تعديلات لاحقة- فهناك احتمال للمخاطرة الكبيرة، وهناك دليل قوي أنه من الصعب على أي كان تقدير الزمن اللازم في مرحلة مبكرة من مراحل المشروع.
لقد وجد Barry Boehm عام 1989 في مقالته عن هندسة البرمجيات أن أخطاء الجدولة تتعلق إلى حد ما بمدى التبكير في تقدير هذه الجدولة بالنسبة للمشروع (كما يظهر في الشكل 2- 3). إذا تم التنبؤ باكرًا بكل توقعات الجدولة، فإنها ستفشل بنسبة 400%، وفي كلتا الحالتين (أشك أن الأخطاء تنحرف باتجاهنا، وتميل لأن تستغرق وقتًا أطول مما نتوقع، رغم أن بياناته لا تظهر ذلك). أما أثناء التصميم، حين يصبح الكثير من القرارات أكثر وضوحًا، فإن هذا الفرق يتقلص، ولكنه يبقى كبيرًا. إن تقديرات الجدولة تصبح منطقية فقط في مرحلة التنفيذ، ولكن حتى في تلك المرحلة يبقى التأرجح موجودًا بمقدار 20% بمدى احتمال كون قرارات الجدولة دقيقة.
إن هذا يعني أنه على مدراء المشاريع استيعاب أن تقديرات الجدولة تنمو باتجاه الدقة مع الزمن. وتتطلب هذه الجدولة بذل الانتباه لها أثناء التطورات وإجراء التعديلات عليها في مراحل تطور المشروع.
الجدولة هي عبارة عن احتمال
عندما تخرجت حديثًا من معهدي، وبدأت العمل على مشاريعي الأولى الكبيرة (نظام التشغيل Windows ومتصفح الانترنت)، كانت تسلم لفريق العمل الذي أعمل معه جدولة لأعمال المشروع ذات مستوى عال من قبل شخص أكثر أهمية مني. وبسبب كوني مبتدئًا جدًا لأتدخل في هذه العملية، فقد قدم إلي الجدولة في أحد الأيام، وكانت مهمتي هي تطبيق هذه الجدولة التخصصية على عدد صغير من المبرمجين ومسؤولي الجودة الذين عملت معهم. وقد قارنا بين الجدولة الأساسية والجدولة التي شكلها أعضاء الفريق بالاعتماد على بنود العمل. لقد بدت هذه الجدولة وكأنها قادمة من المجهول، كانت منظمة بشكل تنازلي، ومصوغة بعناية ومقسمة إلى عدة أعمدة جميلة من التواريخ والأرقام. لقد بدت وكأنها تحفة يدوية مسروقة من المستقبل.
لكن بغض النظر عن مدى تهكمنا أو تطرفنا في حينها، إلا أننا على الغالب اتبعنا تلك الجدولة بإخلاص، على الرغم من غموض منشئها، ولكن كان لدينا أسباب جيدة لنثق بقادتنا، وكنا مشغولين بما يكفي بعملنا الخاص، حيث لم يكن لدينا الوقت لنقلق كثيرًا بشأن تلك الجدولة. (في الحقيقة لقد زودونا غالبًا بشرح أساسي لتلك الجدولة الأولية، ولكننا كنا شديدي الانشغال وشديدي الثقة بهم، ولم نجد الوقت لنوليها المزيد من الاهتمام).
فيما بعد حين أصبحت مسؤولا عن موضوع الجدولة، أدركت الحقيقة الضمنية لها، إنها ليست هدايا مقدمة من المستقبل، ولا توجد صيغة سحرية أو علم محدد من أجل تشكيل الجدولة المثالية. وعلى الرغم من آرائي البدائية فإن الجدولة ليست مهمة منفصلة، إنها تقدم وتتضمن دائمًا نواح مختلفة عديدة من ماهية المشروع الآن، وما سيكون عليه لاحقًا. إن هذه الجدولة ببساطة هي نوع من أنواع التنبؤ، ولا يهم مدى الدقة التي تشكلت بها كمسودة أو كم كان مظهرها ملائمًا، فهي عبارة عن تجميع فقط للكثير من التقديرات التي يخضع كل منها بشكل أكيد إلى أنواع مختلفة من المشكلات وأخطاء الإهمال غير المتوقعة. وتنتج الجدولة الجيدة فقط من قبل قائد أو فريق عمل يتبع بشدة ويصدر أحكامًا جيدة في نواح مختلفة لعملية التطوير البرمجي. لا يمكنك أن تكون خبيرًا في مساحة ضيقة في عملية الإنجاز وتتوقع بعدها أن تنظم الجدولة جيدًا. وبالتالي فإذا اتفق كل أعضاء الفريق على أن الجدول هي عبارة عن مجموعة من الاحتمالات، عندها لن تكون المشكلة في الجدولة بحد ذاتها وإنما بطريقة استخدامها. وإذا صادف أنه تم عرض الجدولة ذات مرة في أحد اجتماعات الفريق أو تم إرسالها عبر البريد الالكتروني، فإن التساؤل الصحيح هو كالتالي: ما احتمال الالتزام بالخط الزمني المحدد؟ فإذا لم يكن هناك أي احتمال (مثلاً ما المخاطر الخمس الأكثر احتمالاً، بالإضافة إلى إلقاء نظرة على احتمال حدوثها) وبغض النظر عمن هو الشخص الذي أوجد الجدولة، فإنه لن يتمكن من تقديم شرح للافتراضات التي وضعها. يجب أن نفترض دائمًا أن الجدولة ممكنة وليست محتملة. كما يجب أن يتاح للفريق تقديم الاقتراحات حول الاعتبارات أو المعلومات التي يمكن إضافتها أو تغييرها في الجدولة لجعلها أكثر احتمالية للتحقق.
وهكذا فإن السر هنا هو أنه ليس من الضروري أن تكون الجدولة كاملة (وهي الحالة المثلى المريحة لنا) وإنما يجب أن تكون هذه الجدولة جيدة بما يكفي ليؤمن بها الفريق والقادة، وتشكل قاعدة لإصدار ومتابعة التعديلات، وفيها إمكانيات النجاح التي ترضي الزبون، والعمل أو الممول الكلي للمشروع.
التقدير موضوع صعب
في عملية التصميم يكون هناك جزء من عمل المصممين والمبرمجين ومختبري المنتجات متعلق بتقسيم التصميم إلى أجزاء عمل صغيرة يمكن تنفيذها، إن هذه الأجزاء التي تدعى بنود العمل أو بنية تقسيم العمل (WBS) هي التي ستتحول إلى عناصر خط الإنتاج في الجدول الرئيسية. إن بنود العمل هذه (كما آمل) موزعة بشكل ذكي بين فريق المبرمجين، ويتم إيجاد الجدولة من الإجماع عليها. يجب أن يخصص قدر معين من الوقت لكل من هذه البنود من قبل المبرمج، وعلى أساس هذه التقديرات يتم بناء الجدولة.
بأبسط تعريف ممكن يمكننا القول إن التقديرات الجيدة للعمل تكون ذات احتمالية عالية للدقة، والتقديرات السيئة تكون ذات احتمالية منخفضة. إنني لا أتوقع نيل الجوائز على إيجاد هذه التعريفات ولكنها تفترض فعليًا شيئًا واحدًا مفيدًا، وهو أن أحكام قادة الفريق هي التي تحدد المقاييس في مشروع ما. ويتطلب هذا عمليات فعالة من مراجعة التقديرات والدفع والقيادة والإلحاح على الآخرين لإيصالهم إلى المستوى المطلوب. واعتقد أنها خطوة ذكية أن تشرك فريق العمل المسئول عن الاختبار/ ضمان الجودة في عملية التقديرات، وذلك بالسماح لهم بالمشاركة في نقاشات التصميم وطرح الأسئلة أو عرض التعليقات. على الأقل فإن ذلك سيساعدهم في تقديراتهم الخاصة لاختبار العمل التي قد لا تتلازم مع تقديرات العمل البرمجي. حيث لدى غالبًا فريق ضمان الجودة أفضل التصورات عن أخطاء التصميم وحالات الفشل المحتملة التي قد لا يتوقعها الآخرون.
العالم مبني على التقديرات
إن أحد الأمور التي تصعب إيجاد الجدولة هي أن القليل فقط من الأشخاص يستمتعون بإعطاء التقديرات للأمور المعقدة التي تقع تحت مسؤوليتهم. من الممتع دائمًا التباهي والمراهنة على القدرات والمهارات «إن هذا الكتاب/ الفيلم/ موقع الانترنت ذو نوعية رديئة، ويمكنني إيجاد بديل أفضل بكثير»، وعندما يطلب منا العمل والتسليم -بأن نوقع عقدًا بتفاصيل مسؤولياتنا- فإن الأمور تتغير. نعلم جميعًا أنه من الممكن جدًا أن يكون ما نتعهد أنه يمكننا القيام به اليوم مستحيلاً أو خارجًا عن رغباتنا عندما يحين أوانه، فقد يصبح أكثر صعوبة مما نعتقد. والمبرمجون هم مثل أي شخص آخر، ولديهم أسباب منطقية للانزعاج من موضوع التقديرات، وعندما يقولون إنه يمكن إنجاز أحد الأشياء وفق فترة زمنية محددة، فهم يخاطرون بالخطأ في التقدير.
حسب خبرتي فإنه حتى المبرمجين الذين يستوعبون جيدًا موضوع التقدير ويؤمنون به، فإنهم لا يحبون القيام به. وجزء من هذا هو إساءة التخيل «كيف يمكن أن ينجح هذا مع اعتبار كمية المعلومات المتوفرة لدى؟» مع إساءة التقدير «أخبرني بالضبط، كم من الوقت سيستغرق إنجاز ذلك». ولكن العواطف يجب أن تكون محدودة في هذا المجال. إن كل من يعمل في الهندسة والبناء يواجه التحديات ذاتها، سواء كان يبني ناطحة سحاب، أم يعيد ترتيب أحد المطابخ، أم كان يجهز طائرة سوف تحط على كواكب أخرى. ومن قراءتي عن كيفية تمكن هؤلاء الأشخاص من وضع تقديرات لعملهم، رأيت أن التحديات أو التقنيات التي استعملوها لا تختلف في جوهرها عما يواجهه مطورو الوب ومهندسو البرمجيات. إن الفرق الأساسي هو في كم الوقت المعطى لهم لتوليد التقديرات وفي مدى انضباطهم في استخدام هذا الوقت.
التقديرات الجيدة تأتي من التصاميم الجيدة
فليضف المبرمجون في كل مكان إلى معلوماتهم أن أهم شيء تعلمته عن التقديرات الجيدة هو أنها تأتي من المتطلبات والتصاميم الموثوقة. إن التقديرات الهندسية الجيدة تكون ممكنة فقط إذا توفر لديك شيئان: معلومات جيدة، ومهندسون جيدون. أما إذا كانت مواصفات المشروع سيئة، وطلب من المبرمج تذكر رقم ما بالاعتماد على خربشة غير مفهومة أبدًا موجودة على اللوح الأبيض، يمكننا أن نعرف جميعًا ما النتيجة. خربشة غامضة من التقديرات. إن هذا يعني أن التقديرات الجيدة هي من ضمن مهام الجميع - مدراء المشاريع والمصممين على وجه التحديد- ليقوموا بما في وسعهم لدعم المهندسين في توليد التقديرات الموثوقة. إذا تحولت عملية توليد التقديرات إلى مهمة اعتيادية مملة أو إذا لم يشترك بها قادة الفريق، لا تتوقع حينها أن تحصل على تقديرات موثوقة أو ذات احتمال كبير.
من جهة أخرى، إذا رحب المدراء بالتقديرات الضعيفة وارتاحوا للمخاطر الكبيرة في الجدولة، إذن لا توجد مشكلة في التقديرات الضعيفة. فقد تكون التقديرات التقريبية هي كل ما يحتاجه المشروع في حالة المشاريع الصغيرة والسريعة. وحيث إن المتطلبات تتغير غالبًا، وكذلك فإن طبيعة الأعمال أو المنظمات تتطلب هيكلية أقل ومرونة أكبر، لا توجد مشكلة في التقديرات منخفضة الجودة، وذلك باعتبار أنه لا يوجد من سيخلطها بالتقديرات عالية الجودة.
لقد اكتشفت طريقة سهلة استخدمها في حال رفض المبرمج إعطائي تقديراته، وهي أن أسأله «ما الأسئلة التي بإمكاني الإجابة عليها، والتي قد تجعلك أكثر ثقة في إعطاء التقديرات؟». فمن فإيصاله إلى حالة التحديد الدقيق، أكون قد أعطيته الفرصة ليتغلب على الخوف أو القلق الذي قد يشعر به، مما يسمح لي بالمساعدة في حل مشكلته. بالطبع فإنني لن أساعده على إيجاد إجابات عن أسئلته، وربما أيضًا على مناقشة الأمور التي أشعر أن من واجبه التحري عنها. ولكننا نكون على الأقل قد تكلمنا عن الوصول إلى تقديرات أفضل.
فيما يلي بعض الطرق الإضافية للوصول إلى تقديرات جيدة:
• وضع مجالات ثقة الخطة القاعدية للتقديرات: التخيمن = 40% ثقة بدقته، التقدير الجيد = 70% ثقة بدقته، التقدير التفصيلي والتحليلي = 90%. يجب أن يتفق قادة الفريق على مدى الدقة في التقديرات التي يرغبون بها، بالإضافة إلى مقدار الوقت الذي سيستغرقه المبرمجون لإنجازها وكيف سيتم التعامل مع مخاطر التقديرات الناقصة. لا تركز على الأرقام، استعملها فقط للمساعدة في جعل التقديرات مقبولة. إن نسبة التقدير المعطاة 90% من الثقة بدقتها يجب أن تكون تمامًا بمقدار 9 من 10، وإذا قررت أن تطلب من فريقك تحسين جودة هذه التقديرات، عليك أن تقابل هذا الطلب بمزيد من الوقت المخصص لهم للقيام بذلك.
• قيادة المبرمجين يجب أن تحدد معايير جودة التقديرات بطرح أسئلة جيدة واتخاذ وسائل حكيمة يمكن للفريق تقليدها: قم بكل ما يلزم للتخلص من التحريض على التعليقات الكريهة أو التخاذل مثل «لا تطلب مني ذلك»، «إنه مجرد تخمين»، الخ. ابحث عن المتطلبات المنطقية التي يحتاجونها لإعطاء التقديرات الجيدة، وادعمها بالزمن اللازم للوصول إلى أهداف جودة التقديرات.
• عليك أن تثق بالمبرمجين: إذا أخبرك جراح الأدمغة أن عمليتك تستغرق خمس ساعات، هل كنت ستضغط عليه لينهيها في ثلاث ساعات؟ أشك في هذا. أحيانًا نحتاج إلى فرض الضغوطات على الناس حتى يكونوا مخلصين- ولكن فقط كمقياس للموازنة (تظهر الحاجة الملحة إلى هذه في حالة مبرمج يعطي تقديرات عالية للأشياء التي لا يحبها، وتقديرات منخفضة للأشياء التي يحبها)، بالمناسبة إن الحصول على عدة تقديرات (من مطورين مختلفين) قد يكون إحدى الطرق المتبعة لإجراء اختبار منطقي.
• تعتمد التقديرات على استيعاب المبرمج لأهداف المشروع: إن التقديرات تعتمد على تفسير المبرمج لأهداف المشروع بالإضافة إلى مواصفات التصميم (إن وجدت). في كتاب Gerald Weinberg: علم النفس في برمجة الحاسب (Dorest House, 1971) بيان لكيفية أثر نقص الوضوح في تحقيق الأهداف عالية المستوى بشكل مباشر على الافتراضات البسيطة التي يضعها المبرمج. وبقدر ما تكون المشكلة التقنية واضحة، فإن طريقة المبرمج لحلها تختلف كليًا تبعًا للأهداف الكبيرة للمشروع كاملاً.
• يجب أن تبنى التقديرات تبعًا للأداء السابق: إنها لعادة جيدة أن يتابع المبرمج تقديراته عبر كل المشاريع التي يعمل عليها. ويجب أن يكون هذا جزءًا من نقاشاته مع مدرائه، الذين يجب عليهم الاهتمام بتحديد من هو أفضل عضو في الفريق لتقدير أي نوع من الأمور. تستخدم البرمجة الموسعة مصطلح (نسبة الأداء) للإشارة إلى الأداء الاحتمالي للمبرمج (الفريق) بالاعتماد على الأداء السابق.
• يجب أن تصل جودة المواصفات أو التصميم إلى الحد المطلوب هندسيًا لإعطاء تقديرات جيدة: إن هذا يجب أن يكون موضوعًا للحوار بين إدارة المشروع والمبرمجين. وكلما ارتفعت جودة التقديرات المرغوبة، وجب أن تكون جودة المواصفات أعلى.
• توجد تقنيات معروفة لإعطاء تقديرات أفضل: إن التقنية الأكثر شيوعًا هي PERT وهي تحاول تقليص المخاطرات بحساب معدل التقديرات العالية والمتوسطة والمنخفضة للعمل. وهي طريقة جيدة لسببين، أولاً أنها تفرض على الجميع إدراك أن التقديرات هي تنبؤات وأن هناك مجالاً من النتائج المحتملة. ثانيًا أنها تعطي مدراء المشروع فرصة لحصر مدى الاعتدال أو المخاطرة في الجدولة (يمكن إيلاء المزيد من الأهمية للتقديرات العالية أو المنخفضة).
الأخطاء الشائعة
على الرغم من كون التقديرات تتجه نحو تحسين الجدولة، فإن العديد من العوامل التي تؤثر عليها تتقاطع مع أمور مستقلة. إن الفخ في ذلك هو أنه على الرغم من مدى أمثلية وروعة كل التقديرات لبنود العمل، فإن المخاطر في الجدولة هي عبارة عن أشياء غير مكتوبة. على الرغم مثلاً من أن احتمالات الإصابة بالطاعون تعتبر قليلة جدًا في معظم أنحاء العالم، فإن إمكانية أن يصاب أحد المهندسين الهامين بالأنفلونزا أو أن يذهب في إجازة يعتبر عاليًا نسبيًا. هناك مجموعة من الأخطاء الشائعة في الجدولة ويجب على جميع مدراء المشاريع التآلف معها، المشكلة هي أنك ستفكر غالبًا في البحث عن أحد الأخطاء في المشاريع فقط بعد أن تتأذى بسببه. لذلك تحتاج إدارة المشاريع وإدارة الجدولة إلى الخبرة حتى تكون احترافية، حيث يوجد العديد من الطرق المختلفة للفشل، وليس هناك من طريقة للتدريب على البحث عنها، دون التعرض لنتائجها.
فيما يلي أعرض لك قائمتي المحببة من الأسئلة التي ساعدتني على التقاط مشكلات الجدولة المحتملة باكرًا. حيث يأتي معظمها من طرح الأسئلة عن الأمورٍ التي فشلت، وذلك بعد انتهاء المشروع، والمحاولة لإيجاد أسئلة كان قد طرحها شخص ما مسبقًا كان بإمكانها أن تمنع المشكلة. (ما الذي لم ينفذ؟ ما الذي لم يحسب حسابه؟ ما الذي كان من الممكن أن يختلف أو قد يمكنني من اتخاذ إجراءات تصحيحية؟).
• هل أخذت الأيام المرضية وأيام الإجازات لجميع المشاركين في المشروع بالاعتبار بشكل ما ضمن الجدولة؟
• هل اطلع الأفراد على الجدولة، وهل طلب منهم رفع التقارير عن التقدم الدوري (بطريقة غير مزعجة)؟
• هل قام أحد ما بمراقبة كامل الجدولة على أساس يومي أو أسبوعي؟ وهل منح هذا الشخص السلطة الكافية ليسأل أسئلة هامة ويجري التعديلات اللازمة؟
• هل شعر أفراد الفريق بأهمية الجدولة والالتزام بها؟ وإذا كان الجواب لا، فلماذا؟ هل شارك الفريق في تعريف الجدولة والعمل المطلوب إنجازه، أم تم تسليمهم نسخة من ذلك؟  
• هل أضاف قادة الفريق المزيد من طلبات المزايا أكثر من مساعدتهم على تقليصها؟
• هل صادف أن رفض مدراء الفريق عملاً إضافيًا، وقدموا فلسفة منطقية لأعضاء الفريق عن كيفية الاستجابة للطلبات الجديدة (المتأخرة)؟
• هل تم تشجيع أو دعم الفريق في رفض طلبات العمل الجديد التي لا تتناسب مع الرؤية والأهداف؟
• ما هي الاحتمالات المستخدمة في إعطاء التقديرات؟ 50%، 70%، 90%؟ وهل تم التعبير عنها في الجدولة الأساسية على المستوى العالي؟ هل تم إعلام الزبائن بهذا؟ وهل تمت مناقشة خطة أخرى تحتاج زمنًا أطول، ولكنها ذات احتمال أعلى؟
• هل وجدت أزمنة متوقعة في الجدولة، تتيح إجراء التعديلات وإعادة مناقشة الجدولة من قبل القادة والإدارة؟
• هل تفترض الجدولة ساعات عمل أقل في مواسم الإجازات (يكون زمن الإنتاجية عادة أقل في أمريكا في مناسبات مثل عيد الشكر وعيد الميلاد)، وهل تم الأخذ بالاعتبار الاحتمالات المرتفعة لأحداث الطقس التي قد تعيق العمل ضمن الجدولة؟
• هل كانت المواصفات أو مخططات التصميم كافية للمهندسين لبناء تقديرات جيدة؟
• هل تم تمرين المهندسين أو اختبارهم في موضوع إعطاء تقديرات جيدة للعمل؟
الأثر التراكمي (كرة الثلج)
إن الأمر الأكثر إحباطًا في القائمة السابقة هو أنك ولو جعلت أغلبها صحيحًا، فإنه وبسبب اعتمادية كل بنود الجدولة بعضها على بعض، سيبقى انزلاق الجدولة سهلاً. فكل قرار يتخذه الفريق اعتبارًا من خيارات التصميم إلى التقديرات، يعتبر أساسًا للعديد من القرارات التالية. والأخطاء التي تحدث في مرحلة مبكرة من العملية والتي تكتشف لاحقًا سيكون لها أثر كبير على المشروع. إن هذا السلوك المركب في الجدولة يمكن عدم حسبانه بسهولة. وذلك لأنه غالبًا لا تتم ملاحظة السبب والنتيجة في الوقت نفسه (ربما ستلاحظ التأثير المباشر بعد وقوع السبب). وفي أسوأ الحالات عندما يحدث العديد من الأخطاء الهامة، فإن احتمال بناء الجدولة متماسكة سوف ينزلق إلى الصفر.

بالطبع فإن هذا يصبح أصعب. إن هذه الاحتمالية تحسب مثل احتمالية حدوث سلسلة من الأحداث المستقلة وتساوي جداء احتمالات حدوث كل حدث مستقل على حدة (وتسمى أيضًا الاحتمال المركب). وبالتالي فإذا كان احتمال أن تنهي هذا الفصل هو 9/10 وأن تنهي الفصل التالي هو 9/10، سيكون الاحتمال الكلي أن تنهي الفصلين لا يساوي 9/10 وإنما 81/100. إن هذا يعني أنه إذا كان احتمال أن ينجز فريقك عمله كل أسبوع هو 90%، فإن احتمالات الانزلاق الزمني ستزداد مع الوقت. إن الاحتمالية تساعدنا كثيرًا في تذكيرنا أن الفوضى موجودة في كل مكان، وأنها ليست من الأمور المفضلة للمشاريع أو مدرائها.
ما الذي يجب أن يحصل من أجل أن تؤدي الجدولة العمل المطلوب؟
الآن وقد أدركنا سبب صعوبة التعامل مع الجدولة يمكنني أن أقدم النصح على كيفية تخفيض المخاطر وتكبير الفوائد المرجوة من أي جدولة. إن هذه الطرق والسلوكيات تتقاطع مع الخلفيات والأدوار التقليدية، واعتقد أنها لا  تعكس الطبيعة الفعلية للجدولة. ولأن الجدولة تمثل كل ما هو موجود في المشروع، فإن الطريقة الوحيدة لاستخدامها بفعالية هي أن تعي بعض الأشياء عن كل الأشياء التي تحدث من أجل أن ينجح المشروع. إنها مهمة ذات مجالات متعددة، وليست فقط نشاطًا هندسيًا أو إداريًا.

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

خلاصة

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

 المرجع
كتاب : فن إدارة المشروعات، تأليف : سكوت بيركان، ترجمة حلا قش قش، دار شعاع للطباعة والنشر والتوزيع. من ص 31 إلى ص 53