كيفية تقييم أداء الفريق

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


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



عن المتحدث: شارك Alexei Kataev ( deusdeorum ) في تطوير الويب لمدة 15 عامًا. تمكنت من العمل كخلفية ، واجهة أمامية ، مطور Fullstack وقائد فريق. تشارك حاليًا في تبسيط عمليات التطوير في Skyeng . قد يكون مألوفًا لقادة الفريق في التحدث عن عمل الفريق الموزع.

الآن أخيرا نمرر الكلمة إلى المتحدث. لنبدأ بالسياق وننتقل تدريجياً إلى المشكلة الرئيسية.



انضممت إلى Skyeng في عام 2015 وكنت واحدًا من خمسة مطورين - كانوا جميعًا مطورين في الشركة.

لقد مر أكثر من ثلاث سنوات بقليل ، والآن لدينا 15 فريقًا - هؤلاء هم 68 مطورًا .



يعمل جميع المطورين عن بُعد ، وهم منتشرون حول العالم.

دعونا نلقي نظرة على المشاكل التي تنشأ حتمًا عند توسيع نطاق شركة من 5 إلى 68 موظفًا.

في الصورة ، سيرجي هو مدير التطوير.


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

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


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

عليك أن تفهم ما إذا كان الفريق رائعًا .


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


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


أخيرًا - كيف نتأكد من أن جميع الفرق من سابسا وليست قطارات؟

1. نحدد مدى روعة فرقنا.

بالطبع ، أول ما يتبادر إلى الذهن هو قياس بعض المقاييس! الآن سأخبرك عن تجربتنا وكيف أخطأنا مرارًا وتكرارًا.


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

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

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

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


فشل أيضا في حساب عدد الحوادث .

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

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

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

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


هناك أيضا مشاكل مع الاستطلاعات. يبدو أن أداة فائقة العالمية - سنقوم بمقابلة الجميع (المنتجات وقادة الفرق والعملاء) عن المشكلات التي لدينا في الفرق. وفقًا لإجاباتهم ، سنقوم بإنشاء رسوم بيانية ، وسنكتشف كل شيء. ولكن هناك العديد من المشاكل.

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

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

أعطيت ثلاثة أمثلة ، في الواقع جربنا العشرات من المقاييس .

الآن نستخدم فقط:

• إنجاز الخطط.
• عدد الحوادث.
• استطلاعات + مقابلات.

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

المقابلة

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

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

في هذه الحالة ، يجب أن تكون الأسئلة:

• افتح . جواب السؤال: هل هناك مشكلة؟ "نعم!" "لن يخبرك بأي شيء."
• محايد سؤال حول مشكلة هو سؤال سيء. من الأفضل أن تسأل: "أخبرني عن عملية التخطيط في فريقك". يتحدث شخص عن العملية ، وقد بدأت بالفعل في طرح أسئلة أعمق عليه.

نهج آخر جيد جدا هو تحديد الأولويات . لديك جوانب مختلفة من حياة الفريق. تسأل الموظف الذي ، في رأيه ، هو الأروع ويجب أن يظل كما هو ، وأيًا ربما يجب تحسينه.

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

2. تقييم الموارد

الآن دعونا نتحدث عن تقييم الموارد .

لنبدأ بنهج المنتج - لأنه عادةً ما يقيم موارد فريقه. هناك 3 أشخاص ، 20 يوم عمل في الشهر - نحن نضرب الناس بالأيام ، نحصل على 60 مهمة.



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

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


أعلاه بيانات حقيقية باستخدام أحد الأوامر كمثال:

• 36.9٪ من الوقت الذي يقضيه في التواصل هو الاجتماعات والمناقشات والمراجعات الفنية ومراجعات الكود وغيرها.
• 63.1٪ - لحل المشاكل مباشرة.

هل يمكن للمنتج الاعتماد على هذه 63.1٪؟ لا ، لا يمكن ذلك ، لأن مهام المنتج ليست سوى جزء. لا تزال هناك حصة (حوالي 20٪) لإصلاح الخلل وإعادة البناء . هذا هو ما يوزعه المخطط الزمني ، ولم يعد المنتج يعتمد عليه في هذا الوقت.


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


والآن لدينا 287 ساعة! سيكون كل شيء رائعًا إذا احتسبنا دائمًا درجاتنا. ولكن في هذا الفريق ، تم حساب متوسط ​​الإنفاق الزائد - 1.51 ، أي في المتوسط ​​، استغرقت المهمة مرة ونصف أكثر مما كان مقدراً.


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

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

تم نصح البرنامج المساعد ل Jira و EazyBI . هذه أداة بالغة التعقيد ، أو لم يكن لدي ما يكفي من المهارات ، ولكن في الوسط استسلمت.

لقد وجدت طريقة لبناء أي تقارير بسرعة.


قم بتحميل البيانات من متعقب المهام إلى أي DBMS تعرفه (PostgreSQL لنا) ، ثم اطلب من المحلل حساب كل شيء. لدينا ديما ، وقد حسب كل شيء في ساعتين.


في الوقت نفسه ، قدم مجموعة من البيانات الإضافية - العمل الإضافي للمطورين ، والعمل الإضافي لأنواع المهام ، وبعض العوامل ، أخبرنا عن رؤيته وافتراضاته الجديدة - ممتعة وقابلة للتطوير: يمكنك استخدامها على الفور في جميع الفرق.

كيفية زيادة الموارد

الآن حول كيفية تسريع فريق - زيادة موارده دون زيادة عدد المطورين.

بادئ ذي بدء ، من أجل تسريع شيء ما ، يجب عليك أولاً قياسه. عادةً ما نحسب مقياسين:

1. تقييم موجز أولي لمهام التكرار في ساعات. على سبيل المثال ، طرحنا المهام لمدة 100 ساعة في الأسبوع.
   
2. وأحيانًا يكون متوسط ​​وقت التدوير هو الوقت من لحظة بدء المهمة في التطوير ، قبل أن تبدأ في الإنتاج. هذا مقياس أكثر للأعمال ومثير للاهتمام للمنتج ، وليس المطور.
   

لن أتعب من إخبار الروبوت Arseny ، الذي كتبته خلال عطلة نهاية الأسبوع. ينشر ملخصًا كل أسبوع - كم عدد المهام التي نشرناها.



هناك شيئان مثيران للاهتمام هنا:

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

السرعة مقياس متخلف ؛ لا يمكننا التأثير عليه بشكل مباشر. إنه يظهر شيئًا ، ولكن هناك مقاييس تؤثر على أي منها يمكننا التأثير على السرعة. في رأيي ، هناك نوعان رئيسيان:

1. دقة مهام التقييم.
هنا تم مساعدتنا مرة أخرى من قبل المحلل المسؤول لدينا ديما ، الذي حسب الوقت الفعلي للمهمة ، اعتمادًا على التقييم الأولي.


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

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

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

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

3. التعامل مع الديون الفنية

عندما أقول "واجب فني" ، أتصور أنه شيء ضبابي - ليس من الواضح كيف يمكن قياسه؟


إذا أخبرتك أن لدينا 648 ساعة من الخدمة الفنية في أحد الفرق ، فلن تصدقني. ولكن سأخبرك الخوارزمية التي نقيس بها.


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

وهنا لدينا 150 تذكرة في جيرا - ماذا نفعل بها؟



بعد ذلك ، نجري استبيانًا يستغرق 10 دقائق لمطور واحد. يعطي كل مطور تقييمًا من 1 إلى 5 ، حيث 1 - "يومًا ما سنفعله في الحياة القادمة" ، و 5 - "نحن بحاجة إلى القيام به الآن ، فهو يبطئنا كثيرًا." نضيف هذا التصنيف مباشرة إلى التذكرة في جيرا. لقد صنعنا حقلاً مخصصًا ، أطلق عليه اسم "إعادة هيكلة الأولوية" ، وبهذه الطريقة نحصل على قائمة ذات أولوية لديوننا ومشاكلنا الفنية. بعد تقييم أول 10-20 ، ثم ضرب الذيل في متوسط ​​التصنيف (نحن كسالى جدًا لتقييم جميع التذاكر الـ 150) ، نحصل على دين فني في ساعات .

لماذا نحتاج هذا؟ نجري هذا التقييم مرة كل ربع سنة. إذا كان لدينا 700 ساعة في الربع الأول ، ثم أصبحت ، على سبيل المثال ، 800 ، فكل شيء في محله. وإذا أصبح عام 1400 ، فهذا يعني أن هناك تهديدًا ومن الضروري زيادة حصة إعادة الهيكلة - اتفق مع العمل الذي سنقوم به حاليًا بإعادة هيكلة شهر كامل أو 40٪ من جميع الأوقات.

حسنًا ، لقد حللنا مشكلة الديون الفنية ، فهي تحت القفل والمفتاح.


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

مراجعة رمز سيئة

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

• 1 - "أنا لا أفهم ما هو ، لقد سمعت عدة مرات."
• 2 - "يمكنني القيام بالمهام من هذه المنطقة".
• 3 - "أنا خبير كبير في هذا المجال".

, , , .

bus-factor' ?

, , . , , , -, , -, . - , . - , . يوما ما سنكتب.


code review, . , review code review. pull requests, code review . , , - , review. - — , — , code review .

. — , .

4.

. , , cross review . -, : , , , . , . , .

, Google Suite : , , , .

— - .


-, . , , Continuous Integration ..

- — , . — , . , , , , , , . -.

:

• , , .
• - .
• , .
• .

, .

• QA- — 10 , .
• , - Skyeng - . — , , .
• open source, , .

Telegram (@ax8080) facebook , .

, Call for Papers TeamLead Conf 2019, 25–26 , . , , , .

! , .