Первый кейс, про который расскажу — грейдирование 🤘
Раз в полгода у нас проходит грейдирование разработчиков. Ребята оценивают сами себя, друг друга и получают оценку от руководителей. Необходимо ответить на вопросы о производительности разработчика и количестве задач, которые вернули после тестирования.
Чтобы определить грейд, необходимо знать точные цифры по каждому разработчику:
1️⃣ % задач, которые были возвращены QA после тестирования на доработку.
2️⃣ % задач, в которых разработчик уложился в оценку.
3️⃣ % задач, которые были сделаны быстрее, чем их оценивали.
Естественно, эти цифры не зависят от респондента, но долгое время каждый отвечал «по личным ощущениям», и они не всегда совпадали с правдой. Так как же считать эти показатели?
▫️С % задач, которые были возвращены QA после тестирования, мне повезло. У нас уже было кастомное поле WasInTesting, которое увеличивалось на 1 каждый раз, когда задача из разработки отправлялась в тестирование. Осталось только посчитать % задач, у которых этот показатель был >1.
▫️Что касается сравнения фактических результатов и планируемых, то количество залогированных часов в Jira есть (поле jiraissue.timespent). Плановые часы мы также сохраняем в отдельном кастомное поле Initial estimate (Original estimate не можем использовать для этого, так как мы его меняем каждый раз перед началом спринта). Остается сравнить количество потраченных часов на задачу и плановых.
У нас есть задачи на исследования, которые мы заранее не оцениваем. Для формирования корректной выборки необходимо исключить их. Это легко можно сделать, если помечать их отдельным лейблом (мы выбрали лейбл research).
▫️Как известно, аппетит приходит во время еды. Поэтому кроме необходимых показателей для ответов на вопросы грейдирования я вывел и ряд других, которые позволяют понять, как человек поработал в этом квартале, увидеть конкретные задачи, на которые ушло много времени. Кроме того, дашборд доступен для всей команды. Каждый видит свои результаты и результаты коллег. Всё прозрачно и непредвзято. Это повышает доверие команды к результатам грейдирования и компании в целом, а также мотивирует ребят на улучшение своих показателей.
Раз в полгода у нас проходит грейдирование разработчиков. Ребята оценивают сами себя, друг друга и получают оценку от руководителей. Необходимо ответить на вопросы о производительности разработчика и количестве задач, которые вернули после тестирования.
Чтобы определить грейд, необходимо знать точные цифры по каждому разработчику:
1️⃣ % задач, которые были возвращены QA после тестирования на доработку.
2️⃣ % задач, в которых разработчик уложился в оценку.
3️⃣ % задач, которые были сделаны быстрее, чем их оценивали.
Естественно, эти цифры не зависят от респондента, но долгое время каждый отвечал «по личным ощущениям», и они не всегда совпадали с правдой. Так как же считать эти показатели?
▫️С % задач, которые были возвращены QA после тестирования, мне повезло. У нас уже было кастомное поле WasInTesting, которое увеличивалось на 1 каждый раз, когда задача из разработки отправлялась в тестирование. Осталось только посчитать % задач, у которых этот показатель был >1.
▫️Что касается сравнения фактических результатов и планируемых, то количество залогированных часов в Jira есть (поле jiraissue.timespent). Плановые часы мы также сохраняем в отдельном кастомное поле Initial estimate (Original estimate не можем использовать для этого, так как мы его меняем каждый раз перед началом спринта). Остается сравнить количество потраченных часов на задачу и плановых.
У нас есть задачи на исследования, которые мы заранее не оцениваем. Для формирования корректной выборки необходимо исключить их. Это легко можно сделать, если помечать их отдельным лейблом (мы выбрали лейбл research).
▫️Как известно, аппетит приходит во время еды. Поэтому кроме необходимых показателей для ответов на вопросы грейдирования я вывел и ряд других, которые позволяют понять, как человек поработал в этом квартале, увидеть конкретные задачи, на которые ушло много времени. Кроме того, дашборд доступен для всей команды. Каждый видит свои результаты и результаты коллег. Всё прозрачно и непредвзято. Это повышает доверие команды к результатам грейдирования и компании в целом, а также мотивирует ребят на улучшение своих показателей.