كيف أقوم ، قائد الفريق ، بتقييم المشاريع

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




قبل الحديث عن مناهج محددة ، يجدر بنا أن نتناول الصعوبات الرئيسية للعملية.

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

عمق دراسة مهمة التقييم هو سؤال فلسفي. يمكن مناقشة المهام لفترة طويلة ، ثم سيتم تأجيل تقييم السباق بأكمله. ولكن إذا لم تتعمق في الجوهر ، فقد تفوتك شيئًا مهمًا يؤثر على الموعد النهائي.

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

يساعد ما يسمى بوكر التخطيط على التحايل على هذه المشكلة ، عندما يشارك الفريق بأكمله في التقييم ، ولا يعرفون من ستكون المهمة ، ويقيمونها بشكل أعمى ، ولا يرون ما يقدمه الزملاء.


الكاتب: Hkniberg من الإنجليزية ويكيبيديا - تم نقله من en.wikipedia إلى ويكيميديا ​​كومنز. ، المجال العام الجميع يدير

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

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

بعض النصائح حول كيفية تجنب الأخطاء

لتقليل الخطأ في التقييم ، أتبع بعض القواعد البسيطة.

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

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

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

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

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

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

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


الصورة: مايكل دوباكوف @ متوسط

لا يمكن أن يكون هناك تقييم لمدة 40 ساعة للمهمة.هذا هو اختلاف آخر للقاعدة السابقة. توصي Agile بتحليل المشروع إلى مهام لا تزيد عن 20 ساعة. يجب ألا تكون هناك مهام غير قابلة للتجزئة لمدة أسبوع من العمل. في أجزاء صغيرة ، يكون التقدير أكثر دقة.

عند تحليل مهمة ، أحاول تسجيلها. وهي مفيدة في نفس الوقت من زاويتين.

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

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

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

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

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

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

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

لا أقوم بتقييمات من الأعلى أو الأسفل - أسمي مصطلحًا محددًا. وفقًا لقواعد التسويق ، عندما يقول أحد المطورين "من 4 إلى 12 ساعة" ، يعني "تنفيذ ذلك بشكل أسرع من 12 ساعة". يسمع العميل "4 ساعات". إذا اكتملت المهمة في 11 ، فسيعتبر المطور أن كل شيء على ما يرام ، ولن يكون العميل راضياً. يحدث أن العميل غير سعيد ، حتى إذا تم الانتهاء من المهمة في 4 ساعات و 15 دقيقة. لذلك ، حتى إذا تم وضع ملصق داخل الفريق (الشركة) بحد أدنى وأقصى مدة ، ثم يتم احتساب المتوسط ​​(هناك بعض المعنى في هذا النهج) ، يتم عرض النتيجة النهائية فقط للعميل.

أذكر التواريخ فقط بالساعات - ليس بالأيام أو الأشهر.يعتقد الكثير من الناس أنه إذا تم تقدير المشروع بـ 96 ساعة ، فسيتم الانتهاء منه في غضون 12 يومًا لمدة 8 ساعات ، شريطة أن يعمل عليه شخص واحد فقط. يتم استقراء الموقف بسهولة لمطورين اثنين ، وتسمية تصنيف 6 أيام. ولكن هذا ليس صحيحا. هناك العديد من المهام التي تعتمد على بعضها البعض. أولاً ، لا يمكن للمطورين بدء العمل حتى يتم إنشاء قالب مشروع مع جميع أنظمة التجميع والحوامل (ويتم إنشاؤه من 2-3 أيام مع مراعاة رغبات العميل). ثانياً ، يتوقف كل شيء عندما تكون هناك دعوات للتخطيط. ثالثًا ، هناك أخطاء حظر تمنعك من المضي قدمًا. بمعنى آخر ، 96 ساعة في مكان العمل لا تعني على الإطلاق أن 100٪ من الوقت (8 ساعات في اليوم) سيتم تخصيصه خصيصًا لهذه المهام. للتقييم في غضون أيام ، يمكننا أن نفترض أن المطور ليس لديه 8 ، ولكن دعنا نقول ،6 ساعات عمل في اليوم (يجب تحديد الرقم الدقيق من الممارسة).

أسأل المطورين دائمًا عن عدد الساعات التي ستستغرقها المهمة من جهاز كمبيوتر (وليس "بعد المدة التي ستكون جاهزة فيها"). هذا نتيجة للفقرة السابقة. التفاعل مع الفريق كجزء من التقييم ، من المهم صياغة السؤال بشكل صحيح.

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

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

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

أنا لا أعرض عوامل إضافية حتى لا أربك المشاركين الآخرين في العملية.كثيراً ما أرى أشخاصاً ، يجرون تقييماً على مستوى الفريق ، ويحددون الوقت للمساومة فيه. ولكن لا ينبغي لوحدة التقييم وضع هذا المخزون أو مراعاة أشياء غريبة أخرى. وتبين أن المطور قام بتصنيف المهمة عند الساعة 8 ، لكنه ضرب 2 في الإخلاص. ضاعف Timlid تقييمه مرة أخرى ، مع التكيف مع الفريق. ومدير 32 ساعة جعل 40 للعميل (لحساب متساو أو فقط بهدف المساومة ثم لمدة 30 ساعة). هذا أشبه بقول الحظ على القهوة. نعم ، والعميل ، الذي يرى تقديرًا لمدة 40 ساعة لمهمة تستغرق 8 ساعات ، سيقرر أن الفريق لا يعرف كيف.

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

أقف بحزم في دفاعي عن التقييم. النتيجة الطبيعية للفقرة السابقة - أقف دائمًا بحزم على تقييمي. إذا كنت أعلم أن المشروع سيتم تنفيذه لمدة 6 أشهر ، وهم يتوقعون إجراء تقييم من 3 مني ، فلن أذكر أبدًا 4 أشهر لـ "إرضاء" العميل أو المدير.
وتجدر الإشارة إلى أنه في بعض الأحيان يكون هناك مساومة داخلية. عندما تعلم أن المشروع يجب أن يكون جاهزًا للعام الجديد ، فإنك تبدأ دون وعي في التلاعب بنتائج التقييم بحيث تلبي الوقت المتبقي. يقوم الدماغ بتدوير هذه الأشياء بشكل مثالي. حتى إذا كان لديك قائمة تضم 200 مهمة فرعية هناك ، فستتقارب بعد ذلك بطريقة تقابل ليلة رأس السنة.

على الرغم من كل هذا ، أنا مستعد لتغيير التقييم. هذا أمر طبيعي - المشاريع تعيش وتتطور. عند تشكيل أي تقييم ، أفهم أن هذه هي سمة من سمات المشروع في هذا الوقت بالذات.

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

مؤلف المقال: Eugene Wetzel ( imater )

PS ننشر مقالاتنا على عدة مواقع في Runet. اشترك في صفحاتنا فيVK ، FB ، إينستاجرام أو قناة برقية للتعرف على جميع منشوراتنا وغيرها من الأخبار Maxilect.