Если честно, я не очень понял ваш комментарий. Точнее мне показалось, что вы не очень поняли, о чем моя статья. Но я попробую ответить.
"Для начала вам нужно будет узнать какую потребность закрывает эта задача и убедиться, что эта задача именно эту потребность и закрывает." - разумеется, нужно будет узнать. Но причем тут это? Моя статья вообще не об этом. Она о том, как в том числе посчитать себестоимость производства той или иной задачи. И то, это не самый главный посыл статьи.
Про относительность - согласен, но кажется, я и не утверждал обратного. Наоборот, в статье я очень четко указал, что это относительный показатель. Да, в идеале измерять только конкретную команду с самой собой.
Я надеюсь, что хорошие руководители не сравнивают свои команды с другими, а пытается понять и улучшить производительность только своей команды.
В том то и суть, что такая система может быть, и на стоимость надо обращать внимание. Я говорю об этом в самом конце статьи. К тому же, мы это используем в своей компании, поэтому я знаю, о чем говорю.
Разумеется, если у вас одна команда стоит дороже, значит она по идее должна быть производительнее, так как там более квалифицированные и дорогостоящие сотрудники.
Конечно, можно ожидать, что эта команда при бОльшей себестоимости будет более производительнее. А вторая команда при меньше себестоимости будет менее производительнее, и это нормально.
Было бы ненормально, если было бы наоборот.
Но вообще я согласен, что сравнивать две команды - это не очень хорошо, поэтому в данной статье про это буквально два слова.
Цель - это сравнивать производительность своей команды с самой собой.
"Всё, что даёт SP это велосити" - это лишь ограничение вашего применения SP. И SP не всегда дает понимание, за сколько спринтов вы "разгребете", если вы не знаете динамику производительности своей команды.
Разумеется. Все зависит от того, что вы хотите добиться. Если вы хотите показаться в хорошем свете перед своим руководителем, чтобы удостоиться повышения, что можете манипулировать данными, как хотите. Правда, в таком случае это не приведет ни к чему хорошему.
А если ваша цель - честно разобраться и осознать, что происходит у вас в команде, то вы не будете "вертеть как угодно". Вы будете выстраивать прозрачную и понятную систему, а потом пытаться понять, как сделать свою команду производительней.
Согласен, что сравнивать производительность с соседней командой - не лучшая идея, даже при той же системе оценивания. И также согласен, что даже внутри команды могут быть перекосы. Но на моей практике такие перекосы вполне умещаются в понятие "погрешность". В любом случае описанная система дает гораздо более точное понимание о производительности, чем простое "количество задач"
Насчет "красить заборы" - тут ведь вопрос не в том, чтобы удовлетворить своего руководителя. Тут вопрос в том, чтобы как-то осознать деятельность своей команды и честно дать в первую очередь себе понимание, что с ней происходит.
Абсолютно согласен!
Да, мы как раз в данный момент уже оцениваем план/факт, и я про это думал также как-нибудь написать отдельно.
А вот насчет capacity каждой команды пока еще не думал, но подумаем :)
Спасибо за наблюдение!
Согласен, можно попробовать. Но обычно планам не суждено сбываться :)
Как это обычно бываем, неожиданно всплывают какие-то важные баги, которые нужно фиксить.
А при реализации фичи уперлись в такое легаси, что нужно рефачить, поэтому по итогу проценты могут сильно съехать. Но в целом схема вполне рабочая.
Если честно, я не очень понял ваш комментарий. Точнее мне показалось, что вы не очень поняли, о чем моя статья. Но я попробую ответить.
"Для начала вам нужно будет узнать какую потребность закрывает эта задача и убедиться, что эта задача именно эту потребность и закрывает." - разумеется, нужно будет узнать. Но причем тут это? Моя статья вообще не об этом. Она о том, как в том числе посчитать себестоимость производства той или иной задачи. И то, это не самый главный посыл статьи.
Про относительность - согласен, но кажется, я и не утверждал обратного. Наоборот, в статье я очень четко указал, что это относительный показатель. Да, в идеале измерять только конкретную команду с самой собой.
Я надеюсь, что хорошие руководители не сравнивают свои команды с другими, а пытается понять и улучшить производительность только своей команды.
В том то и суть, что такая система может быть, и на стоимость надо обращать внимание. Я говорю об этом в самом конце статьи. К тому же, мы это используем в своей компании, поэтому я знаю, о чем говорю.
Разумеется, если у вас одна команда стоит дороже, значит она по идее должна быть производительнее, так как там более квалифицированные и дорогостоящие сотрудники.
Конечно, можно ожидать, что эта команда при бОльшей себестоимости будет более производительнее. А вторая команда при меньше себестоимости будет менее производительнее, и это нормально.
Было бы ненормально, если было бы наоборот.
Но вообще я согласен, что сравнивать две команды - это не очень хорошо, поэтому в данной статье про это буквально два слова.
Цель - это сравнивать производительность своей команды с самой собой.
"Всё, что даёт SP это велосити" - это лишь ограничение вашего применения SP. И SP не всегда дает понимание, за сколько спринтов вы "разгребете", если вы не знаете динамику производительности своей команды.
Разумеется. Все зависит от того, что вы хотите добиться. Если вы хотите показаться в хорошем свете перед своим руководителем, чтобы удостоиться повышения, что можете манипулировать данными, как хотите. Правда, в таком случае это не приведет ни к чему хорошему.
А если ваша цель - честно разобраться и осознать, что происходит у вас в команде, то вы не будете "вертеть как угодно". Вы будете выстраивать прозрачную и понятную систему, а потом пытаться понять, как сделать свою команду производительней.
Согласен, что сравнивать производительность с соседней командой - не лучшая идея, даже при той же системе оценивания. И также согласен, что даже внутри команды могут быть перекосы. Но на моей практике такие перекосы вполне умещаются в понятие "погрешность". В любом случае описанная система дает гораздо более точное понимание о производительности, чем простое "количество задач"
Насчет "красить заборы" - тут ведь вопрос не в том, чтобы удовлетворить своего руководителя. Тут вопрос в том, чтобы как-то осознать деятельность своей команды и честно дать в первую очередь себе понимание, что с ней происходит.