الكل يريد أن يعرف كم سيستغرق المشروع. في هذه المقالة ، سنشرح كيفية تزويد المدير بتنبؤ دقيق وغير مؤكد في نفس الوقت باستخدام أوقات الدورات وحساب القصص ، بالإضافة إلى النصائح حول متى يجب تجنب التقديرات تمامًا.شعرت سيليست الضغط. أراد مديرها باري عمل توقعات ربع سنوية لفريقها. كانت المهمة معقدة بسبب حقيقة أن مجموعة سيليست عملت على أكثر من منتج واحد: أراد باري الحصول على توقعات لمدة ثلاثة في وقت واحد. كان كل منهم جزءًا من مشروع مختلف.
لم يكن لدى المبرمجين من مجموعة Celeste معلومات كافية لإجراء بعض التوقعات على الأقل ، خاصة بالنسبة للربع بأكمله.
قررت سيليست الاعتراف باري ومعرفة ما يأتون إليه. قامت بتحديد موعد في اليوم التالي وجمعت البيانات.
وصلت الفتاة إلى مكتب باري في تمام الساعة العاشرة صباحًا. عندما طرقت الباب ، كان باري لا يزال يتحدث في الهاتف. طالبها بالدخول ورفع إصبع واحد لتوضيح ذلك: سيكون جاهزًا خلال دقيقة.
جلست على كرسي زائر مقابل مكتبه.
أغلق باري ووقف: "حسنًا ، دعنا نناقش توقيت المشاريع ، أليس كذلك؟"
أومأ سيليست برأسه وقال: "نعم. يبدو أن هذا ما يمكن القيام به في مثل هذه الحالة ".
باري عبوس. "يبدو؟" أحتاج إلى التزامات محددة. لا "يبدو"! "
جلست سيليست بشكل مريح: "باري ، هل تتعرض للضغوط لإطلاق هذه المنتجات الثلاثة؟"
"كيف عرفت؟" - هز باري رأسه. - إذا استمعت إلى الرجال من المبيعات والتسويق ، فستحدث كارثة إذا لم نطلق سراحهم الآن. لا أعرف ما الذي سأجيب عليه ، إلا أن كل شيء سيكون ".
تتذكر سيليست: "لكنك ناقشت الشهر الماضي مجموعة من المشاريع". "اعتقدت أن المنتج أ كان على رأس الأولويات."
قال "إنه كذلك". "والمنتجات B و C هي أيضًا أولوية قصوى."
دحبت سيليست عينيها: "لكنك تعلم أنه لا يمكن أن تكون هناك أولوية رئيسية واحدة ، أليس كذلك؟"
قال: "أعرف ذلك ، وأنت تعرف". "لكن زملائي لا يعرفون." أحتاج إلى توقع لما يمكنك القيام به - حسنًا ، الالتزامات - وبعد ذلك يمكنك التنفس بهدوء قليلاً. "
سألت سيليست: "ما المنتج الذي يجب أن نعمل عليه في المقام الأول؟"
قال "المنتج أ ، بالطبع". "إنه الأكثر مردودا."
قال سيليست "حسنا ، هذا ما سنفعله". "نحن متوترين وسنفرج عن أ في غضون شهر". مهمتك هي جعل هؤلاء الأشخاص اللطفاء يحضرون عروضنا التقديمية كل أسبوع. يجب أن
يروا ما نقوم به في غضون أسبوع. إذا لم يأتوا إلى العرض التوضيحي ، أرفض أن أعطيهم أي معلومات ".
انحنى باري: "انتظر. فهمت عن العرض التوضيحي. وماذا عن الشهرين الآخرين؟ ولماذا لا تقدم لهم أي معلومات؟ "
قالت سيليست: "إذا عملنا على منتج واحد فقط ، يمكنني حساب التصنيف بناءً على دورة التطوير لدينا. بالنسبة للمنتج "أ" ، نصدر من ثلاثة إلى أربعة طوابق [رمز للمهام المخصصة] أسبوعيًا. لكننا لا نعرف دورة التطوير الحقيقية للمنتجات B و C. "
أومأ باري رأسه: "لماذا لا؟"
وقالت سيليست: "تم التخطيط للمنتجات ب وج في غضون شهرين وثلاثة أشهر". - إنها بعيدة جدًا للتسويق. المشكلة هي أنه كلما زاد العمل ، قل "الوقت" الذي يعمل فيه قسم التسويق مع صاحب المنتج لتوضيح القصص. ليس لدينا أي فكرة عن الوظائف التي يجب تنفيذها في شهرين وثلاثة أشهر. سيتعين علينا عمل افتراضات تستند إلى العلم من الصفر (تخمين علمي جامح ، SWAG). هذا طبيعي ، أحب أن أفعل ذلك مع رفاقي ، لكننا بحاجة إلى مزيد من التفاصيل. وهو ليس كذلك ".
"إذن لماذا لا تخبرهم بأي شيء إذا لم يأتوا إلى المظاهرة؟" سأل باري.
قال سيليست: "إذا لم يكن من المهم بالنسبة لهم مراقبة تقدمنا وتقديم التعليقات ، فإنهم لا يهتمون كثيرًا بالتوقيت". "إنهم يريدوننا أن نلتزم بأنفسنا دون أن نقدم التزاماتنا في المقابل." لماذا أقضي بعض الوقت في التقييم إذا لم يرغبوا في المساهمة؟ "
وافق باري على "بيع"
"timebox" الشهري للمديرين الذين يضغطون عليه لتحديد المواعيد النهائية. ستضمن سيليست أن الفريق يركز فقط على المنتج أ. وقد حددت اجتماعات أسبوعية للعروض التوضيحية حتى يتمكن الفريق من إظهار عملهم وتلقي التعليقات.
هل تميل إلى القيام بالأشياء بشكل مختلف؟
تقدير المصطلحات - عمل غير تافه
تقدير المواعيد النهائية هو العمل أيضا. تضع العديد من الفرق مثل هذا الروتين في جدول عملهم العادي. ومع ذلك ، غالبًا ما يتطلب التقدير الفصلي
الدقيق أكثر من ساعة أو ساعتين من العمل.
هناك مشكلتان على الأقل في تقييم الأداء ربع السنوي. في كثير من الأحيان ، لا يتم تحديد المتطلبات بشكل كامل ، وكما هو الحال مع فريق سيليست ،
يفصل التقييم الفريق عن العمل العاجل في المشروع.
المشكلة هي أن تخطيط تطوير البرمجيات لا يشبه التخطيط لرحلة على الطريق. إذا كانت مدينتك بها أكثر من إشارة مرور واحدة ، فأنت على دراية بتقلبات حركة المرور. أنا أعيش في إحدى ضواحي بوسطن ، حيث يمكن أن تستغرق الرحلة إلى المطار 20 و 90 دقيقة. في أغلب الأحيان من 30 إلى 45 دقيقة. هذا اختلاف كبير لرحلة 13 كم.
وليس هناك ابتكار في هذه الرحلة. ذهبت إلى المطار عدة مرات وأعرف عدة طرق للوصول إلى هناك. لديّ تطبيقات جوّال تساعدني في
العثور على أسرع مسار حتى على طول الطريق. على الرغم من أن بعض الخيارات يمكن التنبؤ بها قليلاً ، إلا أن أياً منها لا يمكن أن يضمن أن تنتهي هذه الرحلة المحددة في غضون 20 دقيقة.
تتم الرحلة إلى المطار على طريق محدد مسبقًا ومعقبات مفهومة جيدًا. لكن تطوير المنتج أمر مختلف. هذا هو الابتكار. وبعبارة أخرى ، لم نفعل أي شيء من هذا القبيل من قبل. إذا كان الأمر خلاف ذلك ، فلن نضطر إلى كتابة تطبيق جديد أو
تحديث نظام قديم - سنستخدم النظام القديم.
لتقييم معقول ، لدينا العديد من الخيارات. في الواقع ثلاثة:
- يمكنك تقدير ترتيب المقدار. أعتقد أن هذا مفيد للمشروع بأكمله. نتوقع خمسة إلى تسعة أشهر من العمل. سنعرف بشكل أفضل عندما نجيب على هذه الأسئلة وننهي هذا الجزء من العمل المعقد. " SWAG مناسبة تمامًا لمثل هذه التقييمات.
- يمكنك جمع معلومات كافية حول المتطلبات وتقديم تقدير معقول. قد يحتاج الفريق إلى العمل مع قصص المستخدمين لإجراء توقعات مع فارق بسيط إلى حد ما في الوقت المناسب.
- هناك خيار لتقييم العمل لفترة قصيرة ، على سبيل المثال ، لمدة أسبوع أو أسبوعين. قد يتبين أن التوقعات النهائية ليست صحيحة تمامًا. ولكن عادة ما تكون قريبة بما يكفي من النتيجة حتى لا تخيب أمل الأشخاص الذين طلبوا القيام بذلك.
ما التوقعات التي تحتاجها لمدير؟
لقد لاحظت أن
المديرين غالبًا ما يحتاجون إلى تقدير لترتيب الحجم. في هذه الحالة ، يمكن للفريق وضع توقعات والإبلاغ عنها على النحو التالي:
نعتقد أن هذا المشروع سيستغرق خمسة أشهر بثقة 50٪ في دقة هذه التوقعات. نحن واثقون بنسبة 80٪ في تقييم ثمانية أشهر. عشرة أشهر ثقة بنسبة 90٪ ".
هذا يساعد المديرين على فهم أن هناك مجموعة من الثقة. إذا كانوا يريدون يقين بنسبة 100٪ ، فقد يستغرق ذلك أكثر من 14 شهرًا.
يمكنك استخدام الطريقة اللولبية: "نحن نركز على الربع الأول من العام المقبل. لا نعرف متى بالضبط في الربع الأول ، ولكننا نعتقد أنه يمكننا التعامل معها ". مع تقدم المشروع ، فإنك تحدد: "نحن نقوم بتحديث التقدير لفترة ما بين منتصف يناير ومنتصف مارس." بعد أن تعلمت أكثر ، قل: "في مكان ما في فبراير ، إذا لم تحدث عاصفة ثلجية". ثم في شهر يناير يمكنك أن تقول: "الأسبوع الثالث من فبراير".
أود أيضًا أن أوصي بمجموعة من ثلاثة تواريخ: "التاريخ المتفائل هو يناير. الأكثر واقعية هو نهاية فبراير. الأكثر تشاؤما هو نهاية أبريل ".
على أي حال ، لا تعطي أبدًا تقييمًا لا لبس فيه. يغري سانت مورفي (من قانون مورفي) بالشروع في مشروعك والقيام بأشياء سيئة.
في بعض الحالات وفي بعض الأوامر ، قد يطلب العميل معلومات إضافية. هنا يمكنك أن تناقش معه الوظائف المحددة التي يجري تنفيذها من أجل فهم أوجه عدم اليقين.
استخدم وقت الدورة بدلاً من التقييم
لا أحب التوقعات بشأن مدة تنفيذ مشاريع البرامج أو مشاريع تكنولوجيا المعلومات الأخرى ، خاصةً Agile. بدلاً من ذلك ، أفضل أن يقوم الفريق بنشر قصص صغيرة جدًا أو تقييم العمل حسب وقت الدورة.
إذا لم تكن على دراية بالمصطلحات:
- تصف قصص المستخدم كيفية استخدام العميل أو المستخدم لمنتج لغرض واحد ("أريد حجز مكان" أو "أحتاج إلى نشر بيانات المدينة الذكية لتلبية متطلبات الشفافية"). تختلف القصص عن تلك التي يطورها مطور ينظر إلى منتج من حيث قواعد البيانات وواجهات برمجة التطبيقات.
- يشير وقت الدورة إلى الوقت الإجمالي الذي يستغرقه الفريق لإطلاق العمل على قصة واحدة. يتضمن هذا وقت التطوير النشط ووقت التوقف عن العمل عندما يتوقع العمل شيئًا ما.
الفكرة هي فهم متوسط الوقت المستغرق لإنتاج شيء مفيد (التاريخ).
في حالة سيليست ، علمت أن بإمكان الفريق إنتاج ثلاث إلى أربع قصص أسبوعيًا للمنتج أ. بالنسبة للعديد من الفرق ، يعمل حساب القصص تمامًا مثل طرق التقييم الأخرى.
إذا لم يعمل الفريق مطلقًا على منتج مماثل ، فلن ينطبق وقت الدورة السابقة على هذا المنتج الجديد. قد لا يعرف الفريق كيفية تنقيح وتقسيم القصص من أجل إنتاج عدة قصص في الأسبوع. بالإضافة إلى ذلك ، قد لا تكون على دراية بحالة الرمز وتوافر عدد كاف من الاختبارات. إذا كان فريقك يعمل على القصص لأكثر من ثلاثة أيام ، فلا تهتم بالتنبؤ. عد القصص ولا تحاول أن تفعل أكثر من المعتاد.
عندما بدأ فريق في التعامل مع القصص في يوم أو يومين ، لا يُطلب منك أيضًا إجراء تقييم. غالبًا ما يكون الحساب البسيط أسهل وأكثر دقة.
لماذا لا تستخدم السرعة؟
لقد لاحظت أن أوصي بوقت الدورة وحساب القصة ، بدلاً من السرعة لتقدير وقت المشروع. لأن السرعة بديل.
على سبيل المثال ، أمشي كل يوم للحفاظ على لياقتك. أتبع نفس المسار كل يوم ، أتتبع سرعي النسبي. في يوم مشمس جميل ، أمشي حوالي 5.6 كم في الساعة. في يوم ممطر أو حار ورطب ، تنخفض السرعة إلى 4 كم / ساعة. في الثلج أو الجليد ، لا يمكنني الخروج على الإطلاق ، في هذه الحالة تكون سرعي 0.
انا ذاهب على نفس الطريق. (نعم ، إنها مملة ، لكنها مشكلتي). على الرغم من أنني أسافر على نفس المسافة ، تستغرق الرحلة أوقاتًا مختلفة اعتمادًا على الظروف. هنا تشبه الشروط قاعدة الكود واختبارات فريقك.
إذا كانت القصص صغيرة بما يكفي ، فإن السرعة تتوافق مع وقت الدورة. ولكن في كثير من الأحيان ، يحاول المديرون تقييم المشاريع ذات القصص الكبيرة جدًا. سيكون العد أكثر بساطة: "يمكننا إنهاء قصة أو قصتين في دورة. أي قصة أو قصتين تريد أن تختار؟ "
رفض التقييم ليس خدعة
عندما ناقش باري القضايا مع الزملاء ، قال أحدهم: "إن رفض تقييم المواعيد النهائية هو عملية احتيال!"
رد باري: "ليس صحيحا. تريد منا أن نطلق منتج ، أليس كذلك؟ "
كان الجواب "بالطبع.
كل من B و C. "
رد باري: "المشكلة هي أنهم بحاجة إلى القيام بدورهم". - إذا كنت حقًا بحاجة إلى المنتج "أ" ، فما الفائدة من توقع ما تبقى؟ يمكننا الوصول إلى العمل وإظهار تقدمنا. عندما نقوم بما يكفي ، سنكرر الإجراء الخاص بـ B و C. بالإضافة إلى ذلك ، سيكون لديك الوقت لتوضيح متطلبات B و C من أجل إعداد القصص لنا. "
أكمل فريق سيليست الجزء الأكبر من المشروع أ في شهر واحد. استغرق إصدار المنتج B وقتًا أطول - أقرب إلى شهرين. وبما أن الشركة تلقت دخلًا كافيًا من إطلاق المنتجين أ و ب ، فقد خفضت الضغط على إطلاق المنتج ج.
اعرف الدرجة التي يحتاجها مديرك. قدم لها ما يحتاجه. وإذا كان لديك القليل من الوقت ، فابدأ العمل.
تقييم مشاريع تكنولوجيا المعلومات: الدروس
- لا تقم بتضمين أي أرقام أو تواريخ محددة. بدلاً من ذلك ، امنح أمرًا لتقدير الحجم بثقة في إصدار في الوقت المناسب. أو اقترح تقديرات قصيرة المدى استنادًا إلى عوامل تحت سيطرتك.
- قسّم أهداف المشروع إلى قصص المستخدمين التي تحدد وظائف البرامج. ثم ضع تقديراتك بناءً على عدد قصص المستخدمين التي يمكنك معالجتها.
- تأكد من أنك تفهم المتطلبات قبل إجراء أي التزامات.