تي شيرت ، نقود ، كعكتان: كيف نسينا كيفية تقييم المهام

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



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

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

كيف تتعلم الإجابة على السؤال "متى؟" إذا كانت إمكانية التنبؤ غير واردة؟

كيف شككنا في تقدير

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



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





"جاهز للتطوير" له حد WIP - لا يمكن أن يكون هناك أكثر من 8 مهام في نفس الوقت. هناك أيضًا قاعدة معاكسة: بمجرد أن يكون هناك عدد قليل من المهام في العمود ، نبدأ مراجعة فنية جديدة.



حقيقة: نقضي وقتًا طويلاً في التقييم. عادة ما تتم المراجعة الفنية مرتين في الأسبوع ؛ يمكن أن تستغرق 4 مهام مع تفصيل وتقييم مفصل 1.5-3 ساعات. لكن! ثم لا يزال بإمكاننا تخصيص بعض الوقت لمعرفة سبب تجاوز التقدير.



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

"القميص جاف تمامًا ..." وليس XS

قررنا: دعونا نجرب مناهج التقييم. اقترحت التمسك بحجم القميص - يتم استخدام أحجام القميص كوحدة قياس في هذه التقنية. تحتاج إلى العثور على أصغر مهمة عليك القيام بها ، واتخاذها لـ XS. بعد ذلك ، يتم تقييم المهام المتبقية على أساس مبدأ "كم هي أكبر حجمًا XS" - وبناءً على ذلك ، يتم تعيين حجم S أو M أو L أو XL.





رشوة الفرصة لتقييم "بالعين". كانت الفكرة بسيطة: نقوم بتجميع إحصاءات عن المدة التي يفي بها التطوير بمهمة من بعد أو آخر ، ونحسب المتوسط ​​ويمكننا التنبؤ بالتوقيت.



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

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

اتضح أن XS ، مثل S ، نقوم بذلك في يوم واحد ، ثم في 10. وفي L نقضي 5 أو 15 يومًا. لأنه في الواقع ، نأخذ بعض العمل في المقام الأول ، والبعض في الثاني ، والبعض في المركز الخامس - والمهام من نفس البعد تقضي أوقاتًا مختلفة في حالات الانتظار. عفوًا ، إليك المتوسط.



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

"الجميع يحب الكعك. نفخة! " حمار من شريك

وأنا أحب. بالإضافة إلى ذلك ، يعد عيد ميلاد الطفل مناسبة رائعة! أذهب إلى موقعي المفضل وأبدأ في اختيار:

• يمكنك أن تكون هكذا ، لكن لا يمكنك ،
• يمكنك التزيين ، ولكن لا يمكنك التزيين ،
• يمكن أن يكون وزنه 2 كجم ، ويمكن وزنه 5 كجم

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

بالطبع ، أنا لست نيوتن ، والكعكة ليست تفاحة ، لكن البصيرة قد حان.

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



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

نشأت فكرة اتفاقية مستوى الخدمة لأنني قرأت عنها في دليل كانبان

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



دعونا نتذكر مجلسنا:





تتكون الخدمة من عدة مراحل (التطوير ، مراجعة الكود ، الاختبار) ، والعمود "جاهز للتطوير" هو نقطة التزامنا تجاه العميل.



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

كيفية تقييم اتفاقية مستوى الخدمة الخاصة بفريقك: بناء مخطط طيفي (الأمر بسيط)

لفهم فئات الخدمة التي لدينا وما هي اتفاقيات مستوى الخدمة لديهم ، يقترح كانبان بناء الرسم البياني التالي:

• Lead Time (LT) — . « » «».
• Y — LT1, LT2, LT3 ..

لقد أغلقنا المهام على مدار الأشهر القليلة الماضية وحصلنا على ما يلي:





أغلقنا 3 مهام في يوم واحد ، 6 - في اثنتين ، والأهم من ذلك كله - في 5 ، وفي مكان ما قاتلنا حول المهمة لأكثر من أسبوعين ...



حسنًا ، حان الوقت الآن للتحليل. ما هي هذه المهام؟ لماذا انتهى بهم الأمر هنا؟ لماذا نفعل في بعض LT أكثر من الآخرين ، ما هو هناك؟ يمكنك البحث للعملاء والفنانين ، بالإضافة إلى دراسة التعليقات على المهمة.



إليك ما يجب أن نحفره. هذه هي وظيفتنا العادية .





الفارق كبير جدا ، لكنه قابل للتحليل.



بشكل عام ، تم توزيع الجزء الأكبر من المهام في الفترة من 7-14 يومًا ، وتوجه الزوجان بعيدًا جدًا - في هذا الذيل كانت هناك العديد من المهام (وليس كلها) من العلاقات العامة إلى الخدمات الأخرى. تلك المهام التي اكتملت في 3-4 أيام هي على الأرجح استثناء من القاعدة.

, , , 75% 10 .

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



دعنا نذهب أبعد من ذلك. أطلقنا على هذا الفصل "هام" .





لسبب ما ، يتم أخذ هذه المهام للعمل في وقت أبكر من غيرها: إما أن تكون هناك قيمة أكبر أو أن تكلفة التأخير أعلى.



وهنا يمكننا أيضًا التعبير عن اتفاقية مستوى الخدمة: باحتمال 75٪ ، سيتم بيع المهمة في 5 أيام ، باحتمال 90٪ في 7. لنواصل؟



إن المهام التي نتخلى عن كل شيء من أجلها ورأيناها ، رأيناها ، هي حاصرات .





في 100٪ من الحالات ، تعد هذه تحسينات طفيفة لم نأخذها في الاعتبار عند تنفيذ الميزة الرئيسية ، أو الأخطاء التي تؤثر على الوظائف الحيوية في الإنتاج.



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



منجز! يمكننا أن نتفق مع Vanya على اتفاقية مستوى الخدمة لجميع فئات الخدمة:





لقد اخترنا 90٪ بالضبط من حيث الشروط - وهذا في الواقع هو تسامح العميل مع عدم الامتثال. بمعنى ، إذا لم تتوافق مهمة واحدة من كل 10 مهام مع اتفاقية مستوى الخدمة ، فنحن على استعداد للتسامح معها.



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

بدلا من الاستنتاج

- وما الذي يمنع فانيا من اكتساب المهام أو الحاصرات المهمة فقط؟

- حدود WIP الأفقية.

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



شكرا لكم على اهتمامكم والتخطيط الناجح!