إن عنوان هذا المقال (استراتيجية منتصف اللعبة) يعود إلى لعبة الشطرنج، حيث تقسم ألعاب الشطرنج إلى ثلاثة أجزاء: الافتتاحية ومنتصف اللعبة ونهاية اللعبة. تبدأ لعبة المنتصف عندما تصبح استراتيجية اللاعب العامة واضحة وتطبق بالحركات التي يجريها اللاعب. إن معظم الحركات في اللعبة يحصل في لعبة المنتصف، أما لعبة النهاية فهي نتيجة اللعب حيث تضعف الموارد ويحسب حساب كل حركة. يركز هذا الفصل على لعبة المنتصف أما الفصل التالي فيغطي نهاية اللعبة للمشروع.
الحظ يضل المهيئين
Louis Pasteur
إن لعبة المنتصف في المشاريع هي منتصف الجدولة العامة. وتعرف أنك في لعبة المنتصف عندما تنجح بعض الأشياء، وتفشل أشياء أخرى، وعندما يتم اكتشاف وحل بعض الأمور بينما تعلم أن أشياء أخرى لم تكتشف بعد. إن مرحلة منتصف اللعبة هي مرحلة تحد، لأن هناك الكثير من الأشياء يحصل في نفس الوقت ومن الصعب المحافظة على الوضوح في الأمور التي تجري على ما يرام والأمور التي تسير كما يجب. إن مصطلح ضباب الحرب - الذي استخدمه Clausewitz للإشارة إلى مدى التشويش الذي قد يبدو عليه الهجوم المضاد للعمل وعندما تكون فيه - ينطبق جيداً على منتصف اللعبة، حيث يوجد ضباب لا بد منه في مرحلة التطوير يحيط بالفريق ومن السهل أن يضيع فيه قليلو الخبرة. إنها مسؤولية قائد الفريق أن يتجاوز بالفريق مرحلة التأرجح في منتصف اللعبة ليمرره، إلى مرحلة نهاية اللعبة، عندما تتوضح الأمور مرة أخرى.
إن منتصف اللعبة ونهاية اللعبة بأبسط نظرة لها تدور حول المعالجة على أعلى مستوى:
1- إذا كانت الأمور تسير على ما يرام في نهاية اليوم الأول. فإن الهدف في اليوم التالي هو المحافظة على ذلك.
2- إذا لم تسر الأمور على ما يرام في أي يوم من الأيام المخصصة للمشروع. فإن عملك هو أن تستنتج ما المشكلات ومن ثم تتخذ الإجراءات لجعل المشروع يسير كما يجب مرة أخرى. إن هذا قد يستغرق ساعات، أو أياماً أو أسابيع.
3- كرر إلى أن يكتمل المشروع.
إن التحدي الواضح، حتى في هذه النظرة البسيطة، هو أن هناك عدداً لا نهائياً من الأشياء التي يمكن أن تحدث لجعل أمور المشروع تفشل، والأسوأ أن هناك زمنا محدداً لاكتشاف ما الخطأ ووقتا أقل لحل المشكلة، هذا ما عهد الجهد المطلوب لحماية الأجزاء الصحية في المشروع من المشكلات.
من أجل هذه الأسباب وأسباب أخرى، فإن مستويات الطاقة والضغط النفسي في مرحلة منتصف ونهاية اللعبة تكون عالية جدًّا. حيث يتحرك الفريق بسرعة متزايدة وهوامش الخطأ تتناقص كل يوم، وبعدها عندما تقترب نهاية اللعبة، يجب أن يجد أحدهم الطريقة الصحيحة، ليس فقط لتبطئ العمل وإنما لتبطئ التحرك حتى تنتهي الأمور على خير.
سوف أستخدم في هذا الفصل والفصل التالي، نفس الافتراضات الشاملة عن المنهجيات التي وضعتها في الفصل 2 (إن هذه النصيحة تطبق بنجاح، بغض النظر عن المنهجية التي تستخدمها). قد يستحق الأمراء قراءة سريعة للمقطع (الحلول البسيطة والمنهجيات) في الفصل الثاني قبل المتابعة هنا.
رغم أن هذا الفصل ينطبق تقريباً على مرحلة منتصف اللعبة والفصل الثاني على مرحلة نهاية اللعبة، فإن هناك تداخلا كبيراً في كيفية وتوقيت إمكانية تطبيق هذه التقنيات. (مثال: يمكن أن تعتبر نهاية اللعبة لمرحلة ما جزءا من منتصف اللعبة للمشروع بأكمله). وبالتالي، أحذر أنني أتأرجح أحيانًا بين هذين الموضوعين المختلفين.
ملاحظة
إن تغطية إدارة منتصف اللعبة ونهاية اللعبة في هذا الفصل والفصل الذي يليه شديدة التركيز. فإذا رأيت أسئلة أو حالات لا تنطبق عليك بسبب حجم فريقك أو مجال مشروعك، فأنت حر في قراءة هذا المقطع سريعاً أو تجاوزه. أنا لا أتوقع أن كل ما أغطيه هنا ينطبق على أي مشروع بعينه. من جهة أخرى، فإنني أحاول أن أقدم لك شيئاً قيما ليس من أجل مشروعك الحالي فقط، وإنما أيضًا من أجل التالي والذي يليه. هناك العديد من التساؤلات هنا التي ستكون مفيدة لك على المدى البعيد ولو لم ينطبق بعضها على ما تعمل عليه حالياً.
الطيران أمام الطيارة
إن قيادة الأشياء الكبيرة والخطيرة تتطلب أكثر من مجرد يد ثابتة. فكلما كان الشيء الذي تقوده أكبر، وعدد الأشخاص المتدخلون بالأمر أكثر، كانت مقاومته أكبر. تماماً كما في إدارة المشاريع حيث أن القادة الجدد للآلات الكبيرة (السيارات، الطائرات، إلخ) يخطئون في تقدير الزمن اللازم للتغييرات في القيادة لكي تنعكس في سلوكيات ما يقودون، فإن منحنى الحركة للعربات الكبيرة أو المشاريع يتغير بشكل كبير تبعاً لمقدار الزخم أو القوى الأخرى المتداخلة.
إن معظم الناس، خاصة قليلي الخبرة، يفشلون في وضع توقعاتهم بالشكل المناسب لنتائج أفعالهم. إن سبب هذا غالباً أنهم لا يفهمون كل القوى المشاركة في ديناميكية الأشياء التي يشغلونها. مثل شخص يتعلم القيادة، فينزلق في الثلج لأول مرة. فإن هناك الكثير جدًّا من القوى غير المفسرة المتفاعلة من أجل أن يبقى مسيطرا.
عندما يفقد الأشخاص المفترض أن يكونوا متحكمين بالوضع السيطرة، فإن استجابتهم العامة ستكون الذعر. قد لا يعترفون بهذا (فالناس الذين يمرون بحالة ذعر نادراً ما يعترفون بهذا)، ولكنه حقيقي. إن أول استجابة عادة هي اتخاذ إجراء تصحيحي يجري كاستجابة مباشرة للمشكلة. ولكن باعتبار أنهم لا يفهمون حقاً كل القوى. فإن هذا الإجراء التصحيحي سيكون نموذجيا أقوى بكثير، وعبر الوقت يدركون ما فعلوه، ويحتاجون إلى إجراء تصحيحي آخر، يقومون به مباشرة. ولكن طالما أنهم ما زالوا يستخدمون المنطق نفسه الذي قادهم إلى تلك الحالة الظريفة بالدرجة الأولى. فإن مشكلات أخرى سوف تنتج.
إن الحقيقة هي أنه عندما تصبح الطائرة أو السيارة أو المشروع غير مستقرة، فإن التحكم يصبح صعباً لدرجة خطيرة -حتى لشخص خبير ولديه المهارات. (إن المشاريع الأصغر هي بالتأكيد أكثر سرعة واستجابة، ولكن لها زخما أيضًا). إن عدم الاستقرار يجعل نتائج معظم الإجراءات غير متوقعة، لأن هناك الكثير من المتحولات التي تتغير بسرعة كبيرة جدًّا. وبالتالي، فإن الإدارة الجيدة للمشروع هي إلى درجة كبيرة الخطو إلى الأمام خطوة أو اثنين في المشروع، مستثمرا أي طاقة لازمة لتجنب الوصول إلى هذه الحالات بالدرجة الأولى.
لدى الطيارين المقاتلين عبارة تصف ما يحدث عندما يفشل الطيار في البقاء في المقدمة: الطيران خلف الطائرة. إنها تعني أن الطيار قد فشل في الخطو (على الأقل) خطوة واحدة سابقة لما يحدث مع آلة، وهو الآن ضحية لتفاعل القوى في مركبته. وكحالة قيادة الطائرات عالية الأداء، فإن المشاريع تتطلب إدارة القوى المتفاعلة والمختلفة العديدة. فكلاهما أنظمة غير خطية، مما يعني أن تغير عنصر واحد (السرعة، الزاوية، الجدولة، الأهداف) قد يكون له أكثر من أثر واحد، أو قد يؤثر على النظام بقوة أكثر من المتوقعة، لأنه قد تضخم عبر العوامل أو الأشخاص الكثر. إن ا لتحذير هو كالتالي: حتى في المشروع المستقر وعالي السرعة، فإن الطبيعة المعقدة لكل من أساس التشفير والفريق، تعني أن أي إجراء إداري قد تكون له عواقب غير متوقعة -وأحياناً لن تكون هذه العواقب ظاهرة لأيام أو أسابيع. وعندما تبرز هذه العواقب المتأخرة، فمن السهل جدًّا افتراض أن شيئاً ما حدث مؤخرا قد سبب المشكلة، مما يصعب جدًّا حل تلك المشكلة.
اختبر منطقك
إن الطريقة الأكثر فعالية لمدراء المشاريع لكي يحلقوا أمام الطائرة هي وجود اختبار يومي للمنطق، يستخدم المبرمجون مصطلح اختبار المنطق للتأكد من أن أشياء هامة معينة موجودة حقاً في شيفراتهم (في لغة)، مثلاً الإجراء assert ( ). إن هذه فكرة جيدة جدًّا لأن الافتراضات خطيرة. عندما يفشل أحد تلك الاختبارات، بالنسبة للتشفير، يمكن عندئذ للجميع تجاوز البحث عديم الجدوى عن الأمور المشتتة (وهي المشكلات غير الموجودة)، وطرح السؤال الرئيسي أساسية عن سبب دخول الحالة اللامنطقية إلى النظام.
فإذا أردت أن (تحلق أمام طائرة) عليك، أن تتأكد باستمرار أن الحالات التي تتوقعها ما زالت حقيقة، فإذا وجدت بعدها حالة كاذبة، فإنك ستعرف مباشرة إلى أين توجه اهتمامك.
إن التحدي هو وجود العديد من اختبارات المنطق الأخرى. ومن المستحيل أن تتأكد من كل شيء طوال الوقت، الأهداف والجدولة والتقنيات والدوافع والتنافس والميزانية والسياسات (رغم أن هذا لا يمنع بعض المدراء الذين لا يثقون بالآخرين، من المحاولة). إن قيادة الفريق عبر الإزعاج اليومي للتأكد من عشرات الافتراضات العشوائية، وكلما ازداد دفعك للفريق للتأكيد على تضييع وقتهم أكثر. حيث ترغب بمعرفة حالة المشروع دون إزعاج حالة المشروع.
هناك ثلاث طرق للقيام بهذا: الأسئلة التكتيكية، والأسئلة الاستراتيجية، وقياس التقدم الشفاف للفريق. سوف نغطي موضوع القياسات في الفصل التالي، أما الآن فدعنا نركز على الأسئلة الاستراتيجية والتكتيكية من أجل اختبار المنطق.
إن العملية بسيطة، احتفظ بقائمة صغيرة من الأسئلة التي تساعدك في الحليق أمام الطائرة، وشكل روتينا لطرح هذه الأسئلة. اسأل سؤال تكتيكيا واحداً في اليوم، واطرح سؤالاً استراتيجيا مرة كل أسبوع. عليك أيضًا أن تشجع أفراد الفريق، خاصة أولئك الذين يتمتعون بالخبرة أو المهارات المكتسبة من التدريب الطويل، على إجراء اختبارات منطق عالية المستوى مشابهة بأنفسهم، وأن يطابقوا نتائجهم مع نتائجك.
إن طريقتي للقيام بذلك كانت كالتالي: كنت أجري اجتماعا مع نفسي أسبوعياً (فإذا لم أحم أنا وقتي، من الذي سيفعل ذلك؟) عن الجدولة الخاصة بي، لقد كنت أغلق بابي، وأضع بعض الموسيقى، وابدأ المرور على قائمة الأسئلة. كان الأمر يستغرق غالباً بضع دقائق. أكون بعدها قادراً على وضع الأولويات مرة أخرى لعملي في ذلك اليوم أو للفريق تبعاً لما وجدته. لقد عملت بجد لأجعل هذا النوع من الأسئلة جزءا من ثقافة الفريق، كما قمت بطرح نسخ مشابهة من هذه النوعية من الأسئلة والإجابات خلال اجتماعات الفريق.
الأسئلة التكتيكية (اليومية) للبقاء في المقدمة
- ما أهدافنا والتزاماتنا؟ أما زالت هذه دقيقة؟ إن مقدار العمل الذي يجب إنجازه يومياً في كل يوم سيجعلك كل يوم يعيد ضبط التركيز والاولويات، وإن أهم أمر للفريق، هو أنه إذا لم تتطابق الأهداف الرسمية مع الأهداف الحقيقية (ولنقل بسبب تفضيلات شخص مهم) أو مع أهداف الفريق (تشكيل الأشياء التي تعتقد أنها ظريفة). فإن الأهداف عندئذ لا تكون دقيقة وإذا لم تكن كذلك فإن الفريق واقع في تناقض، وعندما يكون الأمر كذلك سوف تظهر الأعراض. لا تنتظر هذه الأعراض إذا كنت ترى تناقضات واضحة سوف تؤدي إليها في النهاية، ابق في المقدمة خاصة في الأمور التي تؤثر على الأهداف مباشرة.
- هل ما نفعله اليوم يساهم في تحقيق أهدافنا؟ انظر إلى بنود العمل التي يعمل عليها أعضاء فريق البرمجة عندك، اليوم وغداً، وهذا الأسبوع، هل مساهمتها في تحقيق الأهداف أو المتطلبات واضحة؟ إذا لم تكن كذلك فهذا يعني بداية الانحراف عن المسار الصحيح. اعمل مع المبرمجين المناسبين لإنعاش استيعاب الجميع للأهداف وقيمة العمل تجاه تحقيقها. ثم قم بتعديل واحد من هذه الأشياء الثلاثة: الأهداف، أو العمل أو كليهما. يدعي هذا أحيانًا بضبط العمل، تماماً مثل عجلات سيارتك، حيث إنك بحاجة إلى التأكد دوريا من أن جميع الأشياء تعمل بتناسق.
- هل أنجزت بنود العمل فحسب، أم أنها أنجزت بطريقة تحقيق المتطلبات والسيناريوهات؟ هناك 1.000 طريقة لإنجاز إحدى وحدات العمل، إلا أنها لا تحقق الروح الكاملة والهدف من التصميم. حيث إن أي تصميم أو توصيف جيد سيحتوي على أشياء معرفة جيداً حتى تحقق بنود العمل السيناريوهات الحقيقية للزبائن. من جهة أخرى، فإن صعوبة قابلية الاستخدام، ومتطلبات العمل، وتكامل العناصر والتصميم المرئي توضع دائماً عند المبرمجين بين 15 بند عمل آخر يجب إنجازه. وإذا وجد مصمم واجهات مخصص لهذا العمل (أو خبير آخر)، فإنه سيراجع باستمرار اختبارات العمل اليومي للتأكد من أن بنود العمل تحقق المتطلبات كاملة وليس البنود فقط.
الأسئلة الاستراتيجية (أسبوعياً/ شهريا) للبقاء في المقدمة
تشكل هذه الأسئلة غالباً عناوين الاجتماعات القيادية. فإذا كان هناك نقاش أسبوعي أو شهري عن الأوضاع، فإن هذه الأمور هي التي تستحق اهتمام القيادة. كما أنها تنطبق أيضًا على وضع مدير مشاريع واحد يعمل ضمن مساحة صغيرة.
- ما إمكانياتنا الحالية للوصول إلى التاريخ/ نقطة العلام/ المنتجات الممكنة التالية بمستوى الجودة المطلوبة؟ لقد تغيرت الأمور منذ وضعت التقديرات. كيف يشعر الناس الآن تجاه العمل أثناء قيامهم به؟ اسأل نفسك واسأل الأعضاء الأساسيين في فريقك، ما احتمالية النجاح في تحقيق التاريخ التالي؟ 100%؟، 90%؟، 50%؟، عالية؟، متوسطة؟، منخفضة؟ كن صادقاً واطلب من الآخرين أن يكونوا كذلك. كن حساسا مع الفريق: لا تجعل هذا الذنب أو التحدي يعطيهم شعوراً أنك تحاول إثبات أن تقديراتهم سيئة، أو أنهم بحاجة إلى العمل بمزيد من الجد. بدلاً من ذلك وضح أنك بحاجة حالياً إلى إجابات صادقة (لماذا كانت ثقتهم ضعيفة، أو أن اللوم على هذا لا يغير حقيقة وجود شكوك ملموسة. حيث عليك أن تعي وتحذر من الشكوك الملموسة).
- ما التعديلات المطلوبة لتحسين هذه الإمكانية؟ من النادر أن تحصل على ثقة 100% بالتاريخ القادم من أي شخص صادق ومنطقي. إن السؤال التالي لسؤال الإمكانية يجب أن يكن دائماً كيف نجعل هذه الإمكانية أكبر. أبمقاطعات واجتماعات أقل؟ أم قرارات أسرع؟ أم بإلغاء الميزات؟ أم بقرارات أفضل؟ أم بتوضيح الأهداف؟ أم بمراجعات أفضل للتشفير؟ كيف؟ اسأل الأشخاص الأكثر علاقة بالعمل اليومي الظاهر. واجعل طرح هذا السؤال واستثمار إجابته نشاطا ذا أولوية عالية لك وللفريق.
- كيف نجري التعديلات بحذر وبانعزال؟ دائماً فكر بشكل علاجي أولاً. ما أصغر عدد من الإجراءات اللازمة لحل المشكلة بنجاح وتحسين الإمكانية؟ باتصال هاتفي؟ أم بريد إلكتروني؟ أم بإصدار قرار هام؟ أم بطرد أحدهم؟ لا تخش من اتخاذ الإجراءات الكبيرة إذا كانت هي المقدار الأصغر من العمل الذي ستنجزه. فإذا لم تتوفر خيارات علاجية فكر عندها بالعمومية. هل تحتاج الأهداف إلى تعديل؟ أم أن عملية الاختبار هي التي تحتاج ذلك؟ ما عمليات أو سمات النظام التي يمكن تعديلها لإلغاء الأعراض والمسببات؟ (راجع المقطع التالي، [اتخاذ الإجراء الآمن]).
- ما المخاطر الأكبر أو الأكثر احتمالا اليوم/ الأسبوع القادم/ الشهر القادم؟ وما الأحداث المستقبلية غير الأكيدة إذا تحققت هذه المخاطر؟ إن مجرد ثلاث أو أكثر من المخاطر الخطيرة أو المحتملة، يعني أنك تخطو خطوة كبيرة تجاه منعها. فأنت بذلك تستعد لها وستكون حساسا لأي إشارات تحذيرية قد تشير إلى أن هذه المشكلات تحصل الآن. فإذا أمضيت 5 أو 10 دقائق أسبوعياً في سرد المخاطر المحتملة واستجاباتك الممكنة لها، فأنت تضع نفسك بذلك في مقدمة الطائرة. إن هذا النوع من التأمين على المشروع لا يكلف الكثير غالباً، مجرد بضعة دقائق أسبوعياً تعطيك حماية كبيرة.
- كيف يمكن أن يتغير العالم دون أن أعرف بذلك؟ أما زال الأشخاص الهامون أو المساهمون في العمل موجودين؟ هل تغيرت أهدافهم؟ هل الأعضاء الأساسيون في فريقي قلقين من شيء ما لا أعرفه سوف يؤثر على المشروع إذا كانوا محقين؟ ما الذي فعله المنافسون ونحن بحاجة إلى الاستجابة له؟ أما زال شركاؤنا والأشخاص الذين نعتمد عليهم متابعين معنا؟ ما الشيء الذي لم يسر كما يجب اليوم ولن أكتشفه حتى الغد؟ إن بعض المكالمات الهاتفية القصيرة أو التساؤلات السريعة تجيب مادة هذا السؤال. كن حريصا ألا تدير بضعف أو أن تتصرف من منطلق عدم الثقة بالآخرين، أو أن تنمي الخوف عند الآخرين، بل اجعل طر ح هذه التساؤلات أمراً لطيفا. وعلاوة على ذلك شجع وكافئ الأشخاص الذين يحصلون من أجلك على هذه المعلومات بشكل سباق (عن مسئولياتهم أو مسئوليات الآخرين).
من جهة أخرى، بغض النظر عن مدى خبرتك وتحضيرك وذكائك، ستأتي دائماً أيام تحلق فيها خلف مشروعك. تعلم أن ترى الفريق بين وجود طن من العمل اللازم إنجازه وأن تكن خلف الطائرة: فهي أشياء مختلفة. والاحتمالات كبيرة أنك ستشعر دائماً أن العمل الذي يجب أن ينجز أكبر من الوقت المتاح. لكن إذا كنت قد شكلت قوائم مرتبة لتحديد أولويات العمل (راجع الفصل 13) سوف تعرف أن هناك دائماً أشياء تنتظر وقتك. ولكن عندما تكون في الخلف، فإنك ستشعر بالإعاقة والاكتئاب أو بالإحباط. وسوف تعتقد أنك مهما بقيت لوقت متأخر في مكتبك، فإنك لن تستطيع أبداً أن تعيد المشروع إلى سيطرتك.
ثلاث أشياء هامة أخيرة:
1- عندما تكون في الخلف، اعرف ذلك تذكر أن الجدولة هي احتماليات. ما مدى ثقتك بأن ما يجب إنجازه سوف ينتهي هذا الأسبوع؟ 80%؟ أم 50%؟ فإذا كانت الاحتمالات 50-50 أو أسوأ من ذلك، فأنت عندئذ في الخلف. وهامش أخطائك صغير وسوف تقع في الأخطاء إذا لم تكن قد وقعت للتو.
2- عندما ترى الآخرين يحلقون خلف الطائرة، اعرض دعمك لهم: لا تنكر المشكلة. أخبرهم أنك تراها، وأنك ستحاول المساعدة. تجنب السماح لأي شخص واقع في محيط تأثرك أن يشعر بالذعر أو التردد. حافظ على هدوئك، وساعد الآخرين على ذلك، واعملوا معاً للعودة إلى المقدمة.
3- لا تتردد في الحصول على المساعدة من أندادك أو مشرفيك: قد تكون هذه هي الطريقة الوحيدة للنجاة والعودة إلى المقدمة. استخدم مساعدتهم في وضع الأولويات لوقتك ووقت الفريق بقيامهم ببعض أعمالك أو لمجرد إصغائهم لتحرير مشاعرك. استخدم المعونة التي تعرض عليك، واطلبها إذا لم يعرضها أحد.
اتخاذ الإجراء الآمن
إن معظم الإجراءات التي تتم في منتصف اللعبة، تكون أصغر وأقل من النشاط الذي يقوم به مدير المشروع أثناء التخطيط أو التصميم. فإذا فقدت إحدى المتطلبات وظهرت الحاجة لتضمينها مرة أخرى، فإن عملية تعريفها وتوثيقها ستتطلب مضاعفة كل ما حصل أثناء عملية المتطلبات (تفهم الحاجات، اعتبار تبادل المنافع، التعريف والتفضيل). أو إذا حصل خطأ غير مقصود في شيء ما في المواصفات، فإن عملية الحل هي ضعفاً أو ثلاثة أضعاف تكرار عملية المواصفات، حيث يتم توظيف القليل من المهارات الجديدة في منتصف اللعبة. ويتم استخدام نسخ أسرع وأكثر مرونة من المهارة التي استخدمت سابقًا. وتكون المشكلة في العمل بمخاطر متزايدة السرعة.
إن اتخاذ إجراء آمن في مرحلة منتصف اللعبة يعني ببساطة ألا تنتهك تكاملية المشروع دون قصد كنتيجة لهذا الإجراء. إن الإجراء الآمن صعب، لأن الذخيرة تكون حية في منتصف اللعبة. فالأمور مسبقاً في حالة حركة، والكثير من القرارات قد اتخذت. وهذا قد يتناقض مع أي إجراء جديد.
على سبيل المثال، إذا قررت في منتصف عملية بناء منزلك أن تغير المخطط من شكل إلى آخر أكثر تعقيدا، فإنك ستهدر الكثير من المواد والجهود، وربما تحتاج إنجاز عمل جديد تحت ضغط أكبر. إن تعلم كيفية أن تغيير إحدى المتطلبات أو إلغاء إحدى الميزات أو تعديل في التصميم سيؤثر على كل من أساس التشفير والفريق، يتطلب الخبرة.
إن هدف أي مدير مشروع يجب أن يكون اتخاذ الإجراء الآمن. فعليه أن يتحرك ويتصرف بطرق تحافظ على كون المشروع متوجهاً نحو الأهداف التي قد تتغير. وفي نفس الوقت التسبب بأقل ضرر ممكن للمشروع. إن بعض الأضرار لابد منها، ويجب أن تكون متوقعة. ولكن كلما كانت الإجراءات التي يتخذها المدير أكثر كفاءة، سيكون التأثير السلبي أقل.
كلما تقدمت مراحل المشروع، ازداد اتخاذ الإجراء الآمن صعوبة. إن السبب في ذلك هو احتمالية أن هذا الإجراء ستكون له عواقب مكلفة ترتفع عبر الوقت. إن الاحتمالات لأن يحتاج العمل المكتمل مسبقاً أن يعدل أو يستغنى عنه أعلى. إن هذه الكلفة قد تكون معروفة تماماً، ولكن اتخاذ الإجراء الآمن يعني أن هناك بعض المعرفة بالتكاليف قبل اتخاذ القرار.
إن الأسئلة الخمسة التي يجب اعتبارها عند التفكير بالتعديلات (السمات/ الهدف/ تغيير المتطلبات) في منتصف اللعبة هي كالتالي:
1- ما المشكلة التي نحاول حلها؟ هل نحتاج أن نحل هذه المشكلة لكي ننجح؟ هل نحتاج إلى حل هذه المشكلة في هذه المرحلة؟ هل يمكننا التعايش فقط مع المشكلة؟
2- أهذه المشكلة عرض أم سبب؟ هل يقبل حل العرض فقط؟
3- هل نفهم حالة الشيفرة أو الفريق جيداً بما يكفي لتوقع كيف يمكن أن يؤثر الإجراء عليها؟
4- هل تستحق فائدة التغيير (بما فيها الوقت اللازم لاستيعاب حالة الشيفرة/ الفريق، واعتبار البدائل، والحصول على الدعم السياسي للقرار) تكاليف التعديل؟ إن إيجاد ومن ثم حل الأسباب قد يسبب أكثر من مجرد التعايش مع الأعراض أو إصلاحها.
5- هل تستحق فائدة التغيير المخاطرة بحصول مشكلات جديدة؟
إن اتخاذ القرار للقيام بإجراء ما يعتمد على نفس استراتيجيات اتخاذ القرار التي تمت مناقشتها في الفصل الثامن. إن أي إجراء يتعلق بالتصميم أو المواصفات، أو السياسة أو التواصل يتطلب استخدام التكتيكات التي تمت مناقشتها في الفصول 6-7-9-16 بالترتيب. إن السمات والطريقة نفسها، ما عدا أن الخط الزمني وهامش الخطأ تصبح أصغر. إن نقص الزمن اللازم للتفكير بالخيارات يعني أمرين. أولاً: اعتمد على المعرفة المكتسبة من أي جهود تصميمية أو نماذج أولية حصلت في البداية. إن بعض التعديلات التي تفكر فيها يجب أن تظهر ثانية، وتستخدم معرفة الفريق لتساعد في التحليلات الحالية. ثانيًا: كن حذرا، فكلما كانت معرفتك أقل، ازدادت المخاطر التي لا تستطيع رؤيتها، وكلما تقدمت المرحلة في الجدولة، ارتفع المعيار اللازم لاتخاذ الإجراء.
مخالفة الالتزامات
إن أحد الأجزاء المكملة للإجراء الآمن هو الأخذ بالاعتبار، الالتزامات التي تعهد بها القائد للفريق. فإن الثقة التي يكتسبها القادة من الفريق معرفة بكيفية تدبر القادة لالتزاماتهم. إن كلا من وثيقة الرؤية والمتطلبات والجدولة هي نماذج الالتزام بين الإدارة، وقادة الفريق، والمبرمجين، والزبون. وأي إجراء تتخذه في منتصف اللعبة قد يجعل الالتزامات السابقة التي تعهدت بها غير صالحة.
لكي تحافظ على ثقة فريقك عند حصول التغييرات، عليك أن تحترم الالتزامات السابقة، كما عبر Humphrey « إذا تغير شيء ما يؤثر على أحد طرفي الالتزام، يجب أن يعطي علم مسبق بذلك ويتم التفاوض على التزام جديد ». إن التغييرات مسموحة، إلا أنها يجب أن تتبع عملية تفاوض مشابهة لتلك التي قادت إلى أول مجموعة من الالتزامات (الرؤية، المتطلبات والجدولة). ولست بحاجة إلى تسويد الوثائق، أو اللجوء إلى الاجتماعات الكبيرة. فما تحتاجه فعلاً هو إعلام الأشخاص بحدوث تغيير في الالتزامات، وإشراكهم في عملية اتخاذ القرار تجاه كيفية حدوث تلك التغييرات.
إذا كنت تطلب من فريقك رمي أسبوعين من العمل، تأكد من أنك حسبت تكاليف ذلك عند اتخاذك للقرار. وزودهم بالأسباب لكون التغيير الجديد هو الأمر الصحيح، وأخبرهم ما العوامل التي ساهمت في تكوين هذا الرأي، وإذا استطعت، أشرك أعضاء الفريق في النقاش قبل اتخاذ القرار النهائي.
لا تخش أن تجري التغييرات، فالتغيير جيد ولابد منه. لكن هناك العديد من الأنواع المختلفة للتغيير، والعديد من الطرق المختلفة ليدير فيها القائد فريقه بها، فإذا كنت تمضي في اتجاه وتريد الآن أن يمضي المشروع في اتجاه آخر، ستحتاج إلى تطبيق نفس المهارات (بضعفي السرعة ونصف الرسمية) المطلوبة لدفعهم في الاتجاه الجديد، كالتي كانت مطلوبة للاتجاه الأول.
مجرى التشفير
إن النظرة الواقعية للعمل في منتصف اللعبة تركز على كتابة الشيفرة من قبل المبرمجين فالطريقة الوحيدة التي تدفع المشروع إلى الأمام هي من خلال كل سطر من التشفير المكتوب الذي يقرب المشروع من الاكتمال (فالمزايا المرغوبة، والتفضيل غير الضروري، الخ، لا تدفع المشروع إلى الأمام). إن كل جهود التخطيط والتصميم التي حصلت قبل أن يكتب المبرمجون التشفير، سواء من قبلهم أو من قبل الآخرين، قد تمت لتشكيل تسلسل فعال للعمل الذي سيقومون به عبر الوقت.
إن وظيفة مدير المشروع هي التأكد من جريان مجرى التشفير بسهولة، وبينما يخول المبرمجون سلطة إدارة المجرى واتخاذ القرار تجاه من سيقوم بماذا، فإن التأكد من أن فريق المبرمجين يحظى بالدعم المطلوب لنجاح ذلك، هي مسئولية مدير المشروع. قد يتضمن هذا مهام gopher، حل ما تبقى من أمور التصميم. يجب على مدير المشروع أن يعمل بضعة أيام قبل المبرمج، لينهي التصاميم ويغذي مجرى التشفير. فإذا كان مدير المشروع مسئولا عن عم لعدة مطورين، فإن عليه وضع الأولويات لوقته بحذر للتأكد من أن بإمكانه قذف المتطلبات المتنافسة لمجاري التشفير المتعددة (سبب آخر لكون قائد المبرمجين يقم ببعض أو الكثير من هذا العمل).
يدعو الكاتب Ashley Friedlein هذه العملية في كتابه: إدارة مشاريع الويب: إنتاج مواقع الويب التجارية الناجمة (Morgan Kaufman, 2001) بإيجاز الفريق، والتفاصيل للجزء الثاني من العم الذي يجب القيام به يدعي الإيجاز. كما كتب Friedlein « لرفع الكفاءة وسرعة التطوير إلى أقصى حد ممكن، يجب أن تتشكل اختصاراتك بحيث تسبق دائماً الحالة الآنية للعمل. وفور انتهاء أي جزء من العمل، سيكون لديك الإيجاز اللازم للمقطع التالي من العمل، جاهزا ». إن هذه الاختصارات مشتقة من المواصفات (إذا حافظت على صلتها)، ولكنها تتضمن أي شيء جديد أو متغير قد يحتاج المبرمج إلى معرفته، ودون الاختصار الفعال للمبرمجين في مرحلة منتصف اللعبة، قد يكون هناك أي عدد من الأشياء التي تعيق أحد بنود العمل وتبطئ المجرى: أمور تخص قابلية الاستخدام، أو جهود التصميم المرئي، أو بنود العمل التي قام بها مبرمجون آخرون، أو أمور تتعلق بالتسويق، أو مشكلات تقنية، أو اعتماديات خارجية. وباعتبار أن مدراء المشاريع لديهم دائماً التنوع الأكبر من المهارات، فهم بالتالي أفضل الأشخاص لتشغيل مجرى التشفير، وتعليق أو حل الأمور وضبط الأشياء قبل أن يبدأ المبرمجون (يتضمن هذا البحث عن المبرمجين المنزعجين الذين تعطلوا عن العمل، إما أنهم لا يعترفون بهذا أو لم يدركوه بعد).
إليك أربعة أسئلة تعرف كيفية القيام بهذا بشكل جيد.
- ما بنود العمل التي تم تشفيرها بفعالية؟ هل هناك أي أمور تعيق المبرمجين عن إكمال بنود العمل النشطة حالياً؟ فإذا وجدت، أزلها (الأمور المعيقة، لا بنود العمل). إن هذه حالة تحذيرية للمشروع. فإذا أعيق المبرمج عن كتابة الشيفرة، فالمشروع متوقف إذا. حيث لا يوجد ما هو أكثر أهمية من حل مشكلة تعيق عمل المبرمج. اسألهم ببساطة « كيف يمكنني المساعدة في حل هذا الأمر؟ » وسوف يخبرونك إذا كنت تستطيع مساعدتهم. فإذا كان الأمر المعيق عبارة عن اعتمادية (مثلاً فريد يجب أن ينجز بند العمل 6 قبل أن يبدأ باسل بالعمل على البند 7). فكر بما يمكن أن يقوم به المبرمج كعمل آخر إلى أن يزال هذا العائق.
- هل يعرف المبرمج ويفهم كل ما هو لازم لتنفيذ بند العمل الحالي وفق المواصفة؟ هناك دائماً أسئلة وفجوات تظهر فقط أثناء التنفيذ. وبعض المبرمجين سباقون في إزالة هذه الفجوات بأسلوب ناضج، أكثر من غيرهم. يجب على مدير المشروع أو المصمم أن يتدخل في الأمر ويوفر جهوده للمساعدة في تحديد وإغلاق هذه الفجوات. وقد تكون أحيانًا متوقعة -على سبيل المثال، هل تم حل جميع الأمور التي ظهرت في مراجعة المواصفات بالنسبة لبند العمل هذا؟.
- ما مجموعة البنود التالية التي سيتم تشفيرها؟ هنا تبدأ الإدارة الحقيقية لمجرى التشفير: وهي اتخاذ خطوة سابقة للمبرمجين، فإذا كان بند العمل الفعال حالياً بحالة جيدة، ينتقل التركيز إلى البند التالي في المجرى، وهذا البند التالي يجب أن يكون أكثر أجزاء العمل أهمية للمشروع. حاول دائماً أن تنجز العمل الصعب أولاً، لو كان الأصعب. فكر بالأمور المعلقة الخاصة بكل عنصر في مجرى التشفير التي قد تبطئ أو تعيق المبرمج عندما يحين دور هذا العنصر، اعثر على هذه الأمور وحلها.
- هل اكتمل حقاً آخر بند عمل مكتمل؟ إن المهم هو ناتج مجرى التشفير. حيث يجب أن يراقب أحد الأشخاص نتائج الاختبارات للعمل، ويتأكد من أنها تنفذ ما هو مفروض من وجهة نظر الزبون. هل أضاف إكمال بند العمل الأخير حقاً الوظيفة والإجراءات المطلوبة؟ هل وافق عليه فريق الاختبار؟ هل اجتاز كل وحدات الاختبار؟ هل حدد شخص ما ما هو المفقود؟ إن الأعمال اليومية هي طريقة سهلة لتتبع هذا الأمر لأنه يمكنك دائماً أن تختبر الحالة الآنية للمشروع -وتجد الفجوات فيما قد تم إنجازه- لما هو مطلوب. وتزداد أهمية ذلك، كلما كان بند العمل أكبر.
يتحمل بعض المبرمجين المزيد من المسئولية تجاه مجرى التشفير الخاص بهم أكثر مما يفعل آخرون. حيث إن العديد من المبرمجين سيبحثون بجهد أكبر عن أنواع محددة من الأمور (التقنية) بينما يميلون لتجاهل أو تأخير أمور أخرى (العملية، السياسية). إن جزءا من علاقتك بكل مبرمج يتضمن معرفة مقدار التدخل الذي يجب عليك إبداؤه لإدارة مجرى التشفير الخاص بكل منهم. إن معرفة من يقوم بهذا ليس مهما طالما أنه قد أنجز، وأن شخصاً ما يتأكد ويحافظ باستمرار على جودة بنود العمل تلك.
مجاري التشفير المحافظة والشديدة
يحتاج مجرى التشفير غالباً أن يسبق الفريق البرمجي ببندين أو ثلاثة (إذا احتاج كل بند إلى يومين، فإن ثلاثة بنود تحتاج إلى أكثر من أسبوع من العمل). إن اتخاذ القرار تجاه التسلسل المنطقي التالي قد يحصل نتيجة نقاش غير رسمي بين مدراء المشروع والمبرمجين (أو يمكن اشتقاق ذلك المجرى من المسار الحرج الرئيسي أو مخططات Gantt إذا وجدت ولم تكن قد تجاوزت تاريخها بأسابيع). إن هذا يعطي فقط متسعا فإذا لم يكن التخلص من أمر معيق في الوقت المحدد، فإن المبرمج ومدير المشروع سيتوفر لهم الوقت الكافي لإيجاد بند عمل آخر مناسب لوضعه في المجرى ريثما يتم حل ذلك الأمر المعيق.
إن الفريق ذا الطبيعة الأصعب يمكن أن يراهن بثقة أكبر على مجرى التشفير لترتيب أولويات الأمور. فبدلا من تشكيل بنية تقسيم للعمل تفصيلية لكل بنود العمل، فإن الفريق يراهن بقوة على التغييرات الحاصلة وعلى إمكانية مدير المشروع أو قائد المبرمجين على إدارة المجرى. إن المخاطر هنا أعلى: فإذا تأخر تشغيل المجرى أو لم يسبق عمل الفريق، عندها ستتخذ قرارات سيئة وسيضيع الوقت. للمزيد من التفاصيل عن التقسيم الجيد لبني العمل (WBS) وتطبيقها على جدولة المشروع.راجع التحكم التام بالمشروع لـ (Wiley, 1999) Stephen Devaux أو أي مرجع تقليدي جيد لإدارة المشاريع.
أما الفرق ذات الطبيعة الحذرة، فإن إدارة مجرى التشفير هي عبارة عن تنقيح سلسل لقائمة بنود العمل الأصلية التي تشكلت أثناء التخطيط. لقد تم تخطيط المجرى لأسابيع أو أشهر من التعديلات، لكن المتوقع هو أن تبقى الخطة الأصلية صالحة في المرحلة الحالية على الأقل. وعندما تبدأ المرحلة الأساسية التالية، تتشكل قائمة بنود عمل جديدة كجزء من التخطيط، وتتكرر العملية. وبالتالي فإن التخطيط المسبق لمجرى التشفير يتم تبعاً لطول المرحلة الأساسية، أو لمدى استقرار المشروع.
من جهة أخرى، فإن الفكرة الأساسية من المجرى ليست في كيفية تشكيله، حيث تقدم كل منهجية طريقة مختلفة. بل المهم هو أن تتم إدارته بفعالية، حيث تنفذ بنود العمل الصحيحة في الوقت الصحيح، وأن يضيع ذلك الوقت القليل في اكتشاف ما الذي يجب تنفيذه في المرحلة التالية.
مجرى التشفير يتحول إلى مجرى تصحيح الأخطاء
في مرحلة متقدمة في المشروع، عندما يتم إنجاز كل بنود العمل. فإن مجرى التشفير يواصل عمله. والذي يتغير هو أنه سيمتلئ بالأخطاء/ العيوب الواجب إصلاحها، بدلاً من بنود العمل. عندما نناقش موضوع ترتيب أولويات الأخطاء -وهي عملية اتخاذ القرار تجاه كيفية التعامل مع الأخطاء.
تتبّع التقدّم
إن أبسط نموذج لعرض نتائج تتبع التقدم لمرحلة منتصف اللعبة هو قائمة بنود العمل: لا تنتهي مرحلة منتصف اللعبة إلى أن يتم إنجاز كل بند عمل مجدول بالمستوى المناسب من الجودة). حيث تتضمن كل استراتيجيات منتصف اللعبة إدراكاً لحالة المشروع والمحافظة على وجود الفريق على المسار الصحيح، وتجهيز الأمور لمرحلة نهاية اللعبة الناجحة. إن المعطيات الأساسية لتشكيل هذه المواصفات هي مجموع بنود العمل المكتملة.
| بنود العمل | مكتملة |
| A | نعم |
| B | نعم |
| C | لا |
| D | لا |
| E | لا |
لا تنتهي مرحلة منتصف اللعبة إلى أن تكتمل كل بنود المجدولة، حيث تبدأ عندها فقط نهاية اللعبة. وأي شيء لا يؤثر على نسبة إكمال بنود العمل يجب ألا يأخذ أولوية على الأشياء المؤثرة.
أنا أنصح باستخدام نظرة شديدة البساطة للمشروع، وجعلها مرئية قدر الإمكان للفريق (في المشاريع الكبيرة، اعرض نسبة مئوية لبنود العمل المكتملة بالمساحة). وإذا توفر موقع ويب خاص بالفريق، يجب أن تعرض دائماً خلاصة عن تقدم بنود العمل، ويتم تحديثها يومياً. ضع مخططا مشابها هناك أيضًا. يجب أن يبدأ كل اجتماع أسبوعي خاص بالفريق بمراجعة سريعة لحالة الفريق العامة. وبما أن بنود العمل يجب أن تكتمل في غضون يوم إلى ثلاثة أيام، فإن مخططا مثل الذي في الشكل 5-14 سيعرض التقدم على أساس شبه يومي. ويجب تشجيع الناس على الذهاب إلى هناك بانتظام، واكتشاف ما الذي تم إدخاله مؤخرا وما القادم قريباً.
إن المعلومات الثانوية عن الحالة، مثل الأيام المتبقية لكل بند عمل أو أيام العمل المتبقية لكل مبرمج، الخ، يجب أن تتم متابعتها بالطبع. لكن لا تسمح للمعطيات أن تشوش النظرة البسيطة. في مرحلة منتصف اللعبة، يكون تأمين الطرق ليحصل الفريق على حس شمولي لكيفية تقدم المشروع، هو الأمر الأكثر أهمية. حيث يتوفر لدى الأفراد دائماً إحساس تجاه مجالاتهم الخاصة، وأي مساحات تتعلق بعملهم اليومي.
هناك بالطبع المزيد لتعرفه عن تتبع التقدم بفعالية، وسوف أغطي هذا الموضوع بعمق في الفصل التالي، عندما تصبح الأخطاء والتوجهات ذات أهمية حساسة.
الوصول إلى الأهداف المتغيرة
« لم تربح أي معركة تبعاً لخطة، كما أن أي معركة لم تربح بدون خطة »
Dwight D. Eisenhower
إن أحد أقوى البراهين للدورات القصيرة للتطوير البرمجي الموسع والطرق الأخرى هو أن الاتجاهات تتغير باستمرار. باستخدام دورات تطوير قصيرة، يمكن للمشروع أن يتجاوب مع التغييرات الرئيسية في الاتجاهات دون التنازل عن توازن العمل. كما يمكن لأي جهود تخطيط أو تصميم أن تركز على المدى القصير الملموس. إن هذا يعتبر منطقيا جدًّا لي، تماماً مثل السلوك الضمني خلف استهداف الفوز على المدى القصير. ولكن هناك حقيقة واحدة إضافية. وهي أن المخططات على المدى الأبعد، ولو كانت تقريبية، فهي تميل لأن تجعل تغيير المدى القصير والمتوسط أسهل.
إن السبب في ذلك هو أنه عندما يحصل حالياً تغيير في الأهداف أو المتطلبات، أو التصميم فإن الخطة الأصلية نادراً ما يتم الاستغناء عنها بشكل كامل. وإنما تتم التغييرات (المعروفة سابقًا بالفروقات) نسبة إلى فكرة أساسية عما كان سيكون عليه المشروع إلى أن حصل التغيير الجديد. وكلما كانت الخطة الأصلية أكثر دقة، وإن كانت خطة تقريبية، فإنها ستشكل مرجعا أقوى كما يمكن أن تتم تلك التعديلات بسرعة أكبر. إن هذا يعني أن أفضل تأمين ضد تصعيد الأمور المتغيرة هو وجود خطة عملية من البداية ويمكنك تعديلها لاحقاً.
إن المهارة في استخدام الخطط حيث يتوقع تغير الأهداف هي في عدم السماح بضياع فترات زمنية طويلة دون تحديث الخطة. فإذا استطعت أعثر على الفواصل الزمنية المناسبة، فالأهداف لا تتغير كثيرًا دفعة واحدة: فهي تتتابع ببساطة في اتجاه محدد، وبسرعة محددة، في زمن محدد. فإذا كان لديك عدة مراحل أساسية أو مراحل في مشروعك (راجع الفصل الثاني)، فإنها تشكل الفواصل الزمنية الطبيعية لإجراء التعديلات (وإذا تم التخطيط لزمن تصميم جديد في كل من هذه المراحل، يمكنك أن تعود مرة أخرى إلى الأشياء المنجزة في أول مرحلة أساسية وتحتاج إلى تغيير). ولو ضمن مرحلة أساسية ذات ثلاثة أو ستة أسابيع، يمكنك أن تجد نقطة أو نقطتان وسطيتان لإعادة تقييم مسار المشروع بالنسبة لأي أهداف أو متطلبات محتمل أنها تغيرت. لهذا السبب يجب أن يتعلق طول المرحلة الأساسية بالتغييرات، بحيث كلما ازداد تقلب الاتجاه، كانت الرحلة أقصر.
يظهر الشكل 14-6 مثالاً بسيطا عن إجراء التعديلات للتوافق مع الأهداف المتغيرة. حيث يبدأ المشروع عند A ، ويتوقع أن ينتهي عند B . فإذا اتفق قادة الفريق بعد أسبوعين من بداية المشروع (ربما مع نهاية مرحلة أساسية قصيرة) أن الأهداف لـ B قد تغيرت، عندها يجب إزاحة المشروع ليبقى متوافقا مع B. وبعد أسبوعين، حصلت تعديلات أكثر، بالإضافة إلى تصحيحات جديدة. ربما يجب التخلي عن بعض العمل، ولكن عملاً أقل سيضيع مع تعديل الاتجاه باكرا منه عند ضبط الاتجاه لاحقاً. فإذا صادفت هذه التعديلات بداية/ نهاية المرحلة الأساسية سيكون لدى الفريق الوقت اللازم للقيام ببعض الأعمال التصميمية لتعويض التغييرات، وإضافة بنود عمل لتعديل العمل السابق، وإجراء الضبط.
وإن لم توجد فواصل مرحلية مناسبة، فإنه يمكن لمجرى التشفير أن يساعد في جعل هذه التعديلات الوسطية قابلة للتحكم من قبل فريق التطوير. وبما أن هذه التغييرات المرحلية تحصل في المجرى أمام فريق المبرمجين، فإن هناك مخزنا من التغييرات التي يجب أن تحصل. وكلما توفر وقت أكبر من المجرى كان ذلك المخزن أكبر.
في حال أنه يوجد شخص ما (مدير المشروع أو قائد المبرمجين) عنده الوقت لإدارة المجرى، عندها لن يضطر الفريق إلى الوصول إلى إعاقة كاملة حتى يجري التغيير، وإنما يكفي أن يتوفر ما يلزم من العمل (الصحيح) في المجرى.
من جهة أخرى، فإن هذا يفترض فعلياً أن التغييرات ليست بعيدة جدًّا عن الخطة الأولية: فأي مجهود تخطيطي يوفر إمكانية معتبرة للتحرك (انظر الشكل 14-7). فإذا تجاوزت المتطلبات أو الأهداف الجديدة نقطة معينة، عندها يجب إنجاز عمل تصميمي واستكشافي جديد، يتجاوز مقدار الزمن الأساسي الذي يدعمه مجرى التشفير (أو في بعض الحالات، مقدار الزمن التصميمي المخطط للمرحلة الأساسية التالية). على سبيل المثال، إذا كانت الخطة الأساسية هي تصنيع فرن فإنه قد يكون ممكنا تعديل المشروع في مرحلة منتصف اللعبة لجعله فرنا ذا حجم متوسط -لا لأن يصبح جهاز تسريع الجسيمات، أو شاحنة لنقل النفط.
يظهر نموذجا عاماً لمدى التنوع في المشروع، حيث تمثل المساحة فضاء التغييرات التي سمحت الجهود التخطيطية للفريق بالتخلص منها دون الحاجة إلى عمل أساسي جديد. يمكن رسم مخطط مشابه على المستوى المصغر لكل بند عمل. وتبعا لطريقة المبرمج، فإن خطته ستحتوي على مستويات متنوعة لتغطية تغييرات المتطلبات/ التصاميم بالنسبة لبند العمل.
هناك شيء واحد خاطئ عن ولكن لا قيمة له. إنه يمثل التقدم الزمني عموديا، متضمناً أن منطقة التغطية تقدم أكثر من فرصة للتغيير مع الوقت، وهذا ليس صحيحاً. إن الطريقة الأكثر دقة للتفكير بمنطقة التغطية هي أنها تتغير مع المشروع، فهي تنمو وتتقلص بالاعتماد على حالة المشروع بشكل عام، فإن مساحة التغطية تتقلص مع الوقت واكتمال بنود العمل، ولكن كل تغيير يؤدي إلى إزاحات في الخطة الفعالة، ومعها التغطية المحتملة للتغييرات المستقبلية.
التعامل مع غموض الإدارة
في المشاريع ذات الوظيفة الجيدة، في المنظمات الجيدة، يتم توقيت معظم التغييرات عالية المستوى مع المراحل الأساسية في المشروع (لأن طول المرحلة يتعلق عموماً بتغييرات القيم للمشروع أو المنظمة). ويكون لدى الإدارة الصبر والنضج لتنتظر انتهاء المرحلة قبل أن تجبر على إعادة الانضباط. ولكن لو في تلك المنظمات، قد تكون هناك موجهات إدارية تفرض أن يحصل التغيير في منتصف المجرى دون توفر الكثير من زمن زيادة العمليات بسبب زيادة المتطلبات، للتحضير لهذا التغيير.
في معظم الوقت، سيكون هناك المزيد من دعم الرضى من قبل الإدارة أو العميل أو هناك أسباب تنافسية لإجراء تصحيحات إجرائية بدلاً من أن تغير القرارات الفعلية الإجراءات. أحيانًا يكون طلب إزاحة الاتجاهات ضمن نطاق نفوذك، وأحياناً أخرى عليك ببساطة أن تنتظر شخصاً آخر ليقرر. وفي كلا الحالتين، يجب أن يتضمن جزء من تفكيرك خطة تقريبية لما قد تفعله إذا تحول التغيير المترقب إلى حقيقة. عادة، يمكن أن تجد بعض الكتابات على الجدار قبل أيام أو أسابيع من إصدار القرارات الكبيرة من قبل الإدارة، أو قبل أن يقوم المنافسون بأدوارهم -إذا كنت تبحث عنها. إنك معتمد على علاقاتك ومهاراتك السياسية لتحصيل المعلومات التي تحتاجها لتمنع مهاجمة مشروعك فجأة. ولا يمكن تجنب هذا دائماً، ولكنه ممكن أحيانًا.
خمن بين الحين والآخر أي الاتجاهات قد يتخذها التغيير باستخدام المعلومات التي لديك (دعم تقنية معينة؟ أو ميزة جديدة؟ أو هدف جديد)، وخطط التعديلات التي ستحتاجها لتحقيق ذلك. قد يكون هذا الأمر تقريباً جدًّا -على سبيل المثال، إجراء حوار موجز مع قائد المبرمجين عن الأشياء التي قد تتدخل. « ما الذي علينا أن نفعله يا فريد لدعم مجموعة وظائف API 2.0 بالإضافة إلى ما نستخدمه حالياً؟ » فهدفك ليس تشكيل خطة جديدة، وإنما تحصيل بعض المنطق تجاه ما سيبدو عليه ذلك الطريق إذا اضطررت أنت وفريقك اتخاذه. أعد اختبار قائمة الأولويات الخاصة ببنود العمل وانظر إذا كنت قد فكرت مسبقاً بالعمل الجديد الذي يجب عليك اتخاذه.
استكشاف تأثير التغييرات
إذا أصبحت احتمالية ذلك التغيير عالية، يمكنك أن تعدل العمل في مجرى التشفير لتهيئ نفسك بشكل أفضل للتغييرات. في استراتيجية الشطرنج، هناك طريقتان مختلفتان على الأقل للتخطيط للمعركة:
1- محافظة: ابحث عن الحركات التي تعطيك العدد الأكبر من الحركات المستقبلية، والتي تبقى خياراتك مفتوحة.
2- عدوانية: التزام التزاما كاملاً بخط واحد للاستراتيجية تراه واضحاً، وحول اللعبة على خصمك.
في المشاريع (أو في الشطرنج)، عندما تكون واثقا وتشعر أنك أقوى من خصمك (مثل غموض الإدارة، أو المنافسة)، فإن طريقتك يجب أن تكون عدوانية، أما عندما تكون الأمور غير أكيدة أو تشعر أن خصمك متفوق عليك، فإن الطريقة الأفضل هي الطريقة المحافظة. إن الطلب من فريقك أن يفكر بشكل محافظ قد يبطئ عملهم قليلاً، ولكن هذا ثمن للتأمين الذي تطلبه. أحيانًا يؤدي كونك عدوانيا إلى إجبار الآخرين على اتخاذ القرارات، وإذا لم تبال بالنتيجة واحتجت إلى قرار سريع يمكن أن تكون القرارات العدوانية في صالحك ولو كنت في موقع سياسي ضعيف. لكن انتبه إلى أن أخذ التعديلات بالاعتبار لا يعني دائماً زمنا إضافياً للتطوير أو تخفيضا لجودة التشفير. فقد تكون هناك خوارزمية بديلة بنفس درجة الوثوقية، ولكنها أكثر مرونة لدرجة هامة. اسأل المبرمج أو الفريق ببساطة « أيها الرفاق، أنا قلق من أن العميل أو قسم الإنتاج والاعتمادية سيجبرنا على دعم تخطيط مختلف لقاعدة البيانات. تأملوا ما تقومون به، وإذا كان هناك طرق سهلة وذكية للتحضير لهذا التغيير أثناء قيامكم بعملكم، نفذوها. ولكن لا تجروا تغييرات رئيسية، أو تضحوا بالنوعية، بسبب هذا، مفهوم؟ ».
أحيانًا، يكون هذا مستحيلا: فقد تستغرق الإجابة عن هذا السؤال ساعات من البحث. ولكن هناك حالات يكون فيها الأمر مباشرا. مثلاً قد يكون المبرمج قد أخذ ذلك الاتجاه مسبقاً بعين الاعتبار أو أن لديه رأيا منطقيا مبنياً على استيعابه للتشفير. إن تحضير فريقك بهذه الطريقة، قد لا يكلفك أكثر من محادثة بطول خمس دقائق. وربما ما الأهم هو أنه كلما استوعبت التكاليف المحتملة للتغيير بشكل أفضل، ستكون براهينك أفضل لمعارضة التغييرات (أو إذا كانت مناسبة، لدعمها).
التأثير الكامن للتغيير
انتبه أيضًا إلى أنه كلما كان المشروع أقرب إلى مجموعة الأهداف الأصلية (أو الفعالة الأخيرة) ابتعد أكثر عن أي تعديلات أو تغيير في الاتجاه. في الشكل 14-8 يتقدم المشروع رسميا باتجاه B، رغم وجود شائعات قوية عن تغيير الاتجاه (تظهر الشكل كـ «؟ »). حيث يخمن مدير المشروع كيفي سكون التغيير ويعدل تبعاً لذلك. ويشكل خطة مع فريقه لكيفية استجابتهم. ومع تقدم المشروع، يستمر التغيير الغامض في كونه إشاعة. ومع استمرار تقدم المشروع نحوB فإن زاوية التغيير سوف تنزاج لتصبح حادة أكثر وذات خطورة أكبر. ومع كل سطر مكتوب من التشفير، يتناقص الدعم الممكن تقديمه للبديل المحتمل للاتجاه. وكلما اقترب المشروع من الاكتمال عند B، فإن المسافة نحو التغيير الغامض (المسماة بتأثير التغيير في الشكل 14- 8) سوف تميل التكاليف لأن تصبح أكبر.
فإذا حصل التغيير ولم تنجح جهودك التخمينية، فليس لديك خيار، يجب أن يعود الفريق إلى البداية. وإذا جاء التغيير من دون موارد زمنية إضافية، عد إلى قوائمك التفضيلية واعثر على العناصر التي يمكنك الاستغناء عنها لتوفر لك الوقت الذي تظن أنك بحاجة إليه.
إدارة التغييرات (التحكم بالتغيير)
تتحكم بعض فرق العمل وتتابع بفاعلية أي تغيير في التصميم يتطلب وجود بند عمل جديد أو إلغاء بند موجود (يبدأ هذا بعد أن تتم مراجعة المواصفات رسميا). ولكن الخوف هو أنه إذا حصلت تغييرات التصميم دون تدخل بعض العمليات، فإن قرارات كبيرة وسيئة وشريرة سوف تتخذ دون أن يعلم بها الأشخاص المناسبون. وتبعا لثقافة وأهداف فريقك فإنك ربما تحتاج إلى هذا أو لا. كما أشار Fridlein « إن الطرية التي تدبر بها التغيير عبر المشروع سوف تعتمد على.. حجم وطبيعة المشروع. وبشكل عام، كلما كان المشروع أكبر وأكثر تعقيدا وكانت المواصفات أكثر ثباتا، كان عليك أن تتحكم بالتغيير بشدة أكبر ». فإذا لم يزعج فريقك نفسه بعملية المواصفات، فإنه على الأغلب لن يزعج نفسه بعملية تغيير أيضًا -حيث لا يوجد ما تجري عليه التغييرات.
من جهة أخرى، حتى في حال الفريق ذي القليل من العمليات الرسمية، فإنه كلما اقترب المشروع من الاكتمال، فإنه سيكون أكثر حساسية للتغييرات. ومن دون وجود بعض العمليات من أجل إشهار ومتابعة وإدارة التغييرات، فإنه من الصعب والمزعج إكمال المشروع. وكلما كان الفريق أكثر نضجا كانت رغبته بالسيطرة على التغيير أبكر. إنها ليست بالضرورة عملية نهاية اللعبة. وإنما فقط بسبب اقتراب نهاية اللعبة، فإن المخاطر ترتفع، ومعها الرغبة في السيطرة عليها.
إن الطريقة الأبسط لإدارة التغيير هي بوجود نسخة فائقة المرونة من عملية المواصفات. تدعو كل من NASA و Microsoft هذا بـ DCR أي طلب تغيير التصميم. ومن الأسماء الأخرى الشائعة أيضًا ECR (طلب التغيير الهندسي)، أو ECO (الأمر بالتغيير الهندسي) أو بأبسط ما يمكن CR (طلب التغيير).
إن أبسط عملية لهذا هي كالتالي:
1- يكتب أحد الأشخاص (مدير المشروع) ملخصا عن التغيير -يتضمن علاقته بأهداف المشروع أو المتطلبات -وبالحاجة إلى التغيير وتفسير لتصميم التغيير الذي سيتم (تعطي نقاط bug إضافية لتعريف المخاطر المحتملة لتأثير DCR على المشروع)، إن هذا الملخص نادراً ما يحتاج أن يكون أطول من صفحة أو اثنتين. ويجب تشكيل خطأ أو عيب معين (أو أي طريقة مستخدمة لتتبع الأمور) لتتبع DCR ويتم ربط هذه الوثيقة به.
2- يجب أن يساهم المبرمج ومسئول الاختبار وأي شخص يتأثر إلى درجة كبيرة بالتغيير بتجهيز ملخص DCR والاتفاق على أن هذا التغيير لازم ومصمم بالشكل المناسب. يقدم المبرمج تقديرات تطويرية، بينما يقدم مسئول الاختبار تقديرات اختبار (أو خطة اختبار عامة).
3- يعرض DCR على مجموعة صغيرة من قادة الفريق (راجع المقطع « فريق الحرب » في الفصل 15) أو إلى مدير المجموعة، الذي يعطي قرارا بالمواصلة أو التوقف عن التغيير، فإذا استمر التغيير، تتم معاملته كبند عمل إضافي في المشروع، ويتم إعلام الفريق بـ DCR (ويتم توكيل بند العمل إلى المبرمج المناسب). ويجب تحديث الجدولة وأي وثائق خاصة بالمشروع لتعكس هذا التغيير.
ولكن إذا رفض DCR فإنه سيبدأ بالانزواء حتى يتلاشى.
يمكن تجاوز الخطوة الأخيرة إذا كان الفريق صغيراً وكانت السلطة موزعة بشكل كبير. حيث يجتمع الأشخاص ذوو الصلة ويناقشون الخيارات، ويقررون أمر التغيير. ولكن إذا أجبر التغيير على انزلاق المشروع، أو أثر على مبرمجين آخرين أو تطلب موارد إضافية، عندها يجب أن يتدخل قادة الفريق.
إن DCR دائماً تكون أكثر كلفة من تقديراتها البرمجية والاختبارية. حيث إن نها تملك تأثيرات جانبية تفرعية على باقي أعضاء الفريق الهندسي، وهذا يجعل مدير المشروع يبدي اهتماما أقل بالمجرى والنشاطات المهمة الأخرى. وبما أن العمل التصميمي للـ DCR يتم في زمن الشك، فإن احتمالية وجود الأخطاء والقرارات السيئة مرتفعة. ومن الشائع أن يسبب DCR واحد حاجة إلى أخرى. إن تصرفي العام تاجه هو كالتالي: من الأفضل استخدام دورات تطويرية قصيرة ذات عمليات تصميم قوية، وتسمح ببعض DCRs من أن تخطط لجدولة تتوقع الكثير من تغييرات DCR. يجب أن تتوفر كل الدوافع عند أعضاء الفريق للرغبة في حل مشكلاتهم التصميمية باكرا وتجنب عمليات DCR .
خلاصة
- ترتبط نهاية ومنتصف اللعبة بنهاية ومنتصف المشروع.
- إذا لم يمض المشروع كما يجب يوماً ما، فإن عملك هو اكتشاف ما الخطأ وإصلاحه. كرر هذا في مرحلة منتصف اللعبة.
- إن المشاريع هي أنظمة غير خطية معقدة ذات مقاومة كبيرة. فإذا انتظرت لترى المشكلات الصعبة قبل أن تتخذ إجراء ما، فإنك قد تأخرت كثيرًا وربما جعلت الأمور أسوأ.
- عندما يخرج مشروعك عن السيطرة، فإنك تحلق خلف الطائرة، وهو مكان سيء لتكون فيه. واختبار المنطق هي الطريقة الأسهل للبقاء في المقدمة. يوجد اختبارات منطق تكتيكية وإستراتيجية.
- فكر كيف تتخذ إجراءً لتصحيح حالة بأكثر الطرق أمانا، وكلما كان الإجراء أكبر، والمشروع في تقدم أكبر، كانت الإجراءات أكثر خطورة.
- إن مجرى التشفير هو كيفية إدارة بنود العمل أثناء التنفيذ. وتوجد طرق مختلفة محافظة وعدائية لإدارة المجرى.
- تقدم كل من المخططات المعتمدة على نقاط العلام ومجرى التشفير فرصا لاتخاذ إجراءات تصميمية آمنة للمشاريع.
- إن التحكم بالتغيير (DCRs) هو كيفية تنظيم التغييرات ذات المستوى المنخفض والمتوسط، على المشروع.
المرجع
كتاب : فن إدارة المشروعات، تأليف : سكوت بيركان، ترجمة حلا قش قش، دار شعاع للطباعة والنشر والتوزيع.