Комментарии 51
Но если я знаю, что соседняя команда стоит в 2 раза дешевле, но тоже делает 1000 SP при той же системе оценивания
"Та же система оценивания" - практически несбыточная вещь, на мой взгляд.
Даже внутри команды могут быть перекосы оценивания одной и той же задачи как 1:5, так и 5:1 из-за разного опыта разработчиков. А уже между командами - только если они одинаковые детали в одинаковых условиях производят.
В следующем квартале у тебя должны быть следующие показатели
Тогда я просто подроблю "правильные" задачи и оставлю/укрупню "неправильные".
У нас такое называется "красить заборы", т.е. внешне все выглядит как надо, а внутри как было, так и осталось.
Согласен, что сравнивать производительность с соседней командой - не лучшая идея, даже при той же системе оценивания. И также согласен, что даже внутри команды могут быть перекосы. Но на моей практике такие перекосы вполне умещаются в понятие "погрешность". В любом случае описанная система дает гораздо более точное понимание о производительности, чем простое "количество задач"
Насчет "красить заборы" - тут ведь вопрос не в том, чтобы удовлетворить своего руководителя. Тут вопрос в том, чтобы как-то осознать деятельность своей команды и честно дать в первую очередь себе понимание, что с ней происходит.
Тут вопрос в том, чтобы как-то осознать деятельность своей команды и честно дать в первую очередь себе понимание, что с ней происходит.
Для этого не нужны ни SP, ни, во многих случаях, таски.
Важно как выполняются таски. Если быстро, но тяп-ляп и с техдолгами, это часто хуже, чем дольше, но качественно и с оптимизацией/рефакторингом.
А как выполняются таски можно увидеть, например, при перекрестном code review (как внутри команды, так и между командами). Или по количеству инцидентов/паденией на Проме.
P.S. Это речь о разработке для внутреннего заказчика. Для разработки на сторону могут быть другие варианты.
Но на моей практике такие перекосы вполне умещаются в понятие "погрешность". В любом случае описанная система дает гораздо более точное понимание о производительности, чем простое "количество задач"
А как это можно замерить или доказать?
SP это метрика сложности, а не времени.
И на практике это не погрешность.
У меня два твёрдых синьера, но один подключился недавно и на незнакомый функционал добавляется ознакомление и погружение и, иногда, это много времени.
А разница между этими двумя и одним из мидлов ещё более ощутимая.
Ни сложности и времени, а трудоёмкости. Задача может быть не сложной, но потребовать много ресёрча, коммуникации и прочей активности. И она может быть оценена также, как и технически сложная задача.
У вас 2 сеньора, старый делает за спринт 15 SP, на нового закладываете минимум, например, 5 SP. На стоимость задачи в SP это не должно влиять никак.
Везде в проектах перешёл на часы. Это сразу решило все вопросы. Все знают как с этим работать, менеджеры, бизнес и сама разработка. Просто и понятно.
Мне необходимо получить точный расчёт когда задача будет готова. Поэтому нужны часы. Поэтому SP это прослойка которую можно убрать.
Бизнес не интересует трудоемкость (я назвал это сложностью). Бизнес интересует когда будет сделано, сколько будет стоит и качество.
Поинты, как решение задачи разной сложности будет зависеть от того - кто ее решает, джун-интерн или лид.
Нет, ровно наоборот. Оценка задачи в SP не должна зависеть от исполнителя, но сеньор выполняет больше SP, чем джун. При этом оценка одной и той же задачи может меняться со временем.
В SP необходимо оценивать сложность. Поэтому разница во времени реализации вполне может быть.
Как писал выше - трудоёмкости:
Выше сложность -> больше SP
Больше коммуникации -> больше SP
Больше неопределённости -> больше SP
и т.д.
Но привязки ни к исполнителю, ни к его уровню у вас быть не должно, иначе ваше планирование превращается в хаос. Как вы будете считать капасити квартала, если у вас одна и та же задача для Jun будет 8, а для Sen будет 3?
Вы смотрите ретроспективно предыдущий период и видите там, что команда выполнила 180 SP - это оценка по какому исполнителю?
В SP можно учитывать многое, это решается на уровне команды, но не исполнителя, от него задача должна быть отвязана.
В целом легче посчитать в часах и вести оценку эпика в человека/часах. Прозрачно и все знают как с этим работать, особенно все менеджеры и бизнес в целом.
Вот эти три пункта, без тд, что у вас, я сразу считаю в часах, плюс резерв, и тогда бизнес может посчитать конкретный дедлайн. А у меня всегда явная оценка времени на которую я могу ориентироваться в успеваемости.
привязки быть не должно - а как так то?
задачу оценивает обычно исполнитель и тут мы получаем поправку на исполнителя.
можно сделать покер планирования, он возможно устраняет такие флуктуации (хотя жрет время команды здорово)
может оценивать лид, но там тоже будет относительность.
кстати, во время покера команда что - вообще не учитывает производительность отдельных чуваков?
Расскажу как сделано у меня в команде.
Мы оцениваем задачи всей командой дважды в неделю по часу. В среднем в беклоге есть оценённых задач на 5 спринтов вперёд.
Сначала у нас была проблема - мы ужались до того, что все задачи укладывались в 1-3 SP. Мы провели аффинную оценку:
я вытащил из беклога 50 выполненных задач, то есть известных команде
сделал на доске (любой аналог Miro) несколько столбцов
всей командой двигали задачи туда-сюда, оценивая их относительно друг друга -> задачи отсортировались по сложности
выделили что-то общее у задач в каждом столбце
дальше на столбцы натянули стори поинты
из полученного сделали таблицу эталонов
Если на PBR есть разногласия, идём в эталоны. Если в эталонах нет подходящего варианта, дополняем.
В итоге у команды всегда есть "линейка" для задач, и эта линейка не привязана ни к одному исполнителю.
во время покера команда что - вообще не учитывает производительность отдельных чуваков?
Не учитывает, у нас есть прогнозируемый велосити команды и приблизительный каждого члена команды. Сама задача должна быть описана так, чтобы любой исполнитель знал что нужно сделать.
Понятно, что условный овнер сервиса сделает задачу быстрее того, кто с ним дела не имел, но это максимум влияет на метрики спринта, на горизонте квартала - это статистическая погрешность.
А ещё этой фигней можно вертеть как угодно, как угодно дробить задачи, как угодно вешать SP, и всегда посчитать так что все вообще зашибись.
Или вот наоборот, что показатели вообще плохие, хотя по факту команда сделала очень многое.
Разумеется. Все зависит от того, что вы хотите добиться. Если вы хотите показаться в хорошем свете перед своим руководителем, чтобы удостоиться повышения, что можете манипулировать данными, как хотите. Правда, в таком случае это не приведет ни к чему хорошему.
А если ваша цель - честно разобраться и осознать, что происходит у вас в команде, то вы не будете "вертеть как угодно". Вы будете выстраивать прозрачную и понятную систему, а потом пытаться понять, как сделать свою команду производительней.
Все зависит ещё от второй стороны, если она включает самодура, то какое тут честно разобраться.
только сначала надо определиться
вы хотите показаться в хорошем свете перед своим руководителем, чтобы удостоиться повышения
или
Вы будете выстраивать прозрачную и понятную систему
потому что если выстроить прозрачную и понятную систему, то есть некоторая вероятность что тот, кто такую прозрачную и понятную систему построит станет больше не нужен, потому что:
все же просто и понятно и сделать команду производительней может любой лояльный руководству деятель.
минусанул вас тут. потому что если мы говорим о финансовых показателях в контексте статьи "как рассчитывать производительность производства ИТ", то никаких "честно" тут быть не должно, есть только цифры и факты.
Но проблема ИТ производства как раз в том, что нет единого способа оценки задач. Можно оценивать в сторях, можно в часах (я кстати ваш метод вел в часах и отслеживал по периодам, у нас даже административка включалась автоматом в расчет и время простоя ресурса), можно оценивать статистически от потока.
НО
факт в том, что все эти оценки не будут точными. Ни одна. Впрочем, если выбирать между "нет данных вообще" или "субъективные оценки" то второе лучше.
И еще: сколько у вашей команды уходило на покер планирования в процентах от спринта? а лучше даже в стоимости по времени за период - считали?
У меня есть ненулевое подозрение, что покер - дорогое удовольствие и оценка в часах исполнителем отлично его заменяет.
Поддерживаю. Мне часто приходит бизнес и просит увеличить SP) команда может уже завтра увеличить их в 2 раза, просто оценивая в 2 раза больше. Но объем работы выполняется тот же)
Но если я знаю, что соседняя команда стоит в 2 раза дешевле, но тоже делает 1000 SP при той же системе оценивания, что и ваша команда, то становится очевидным, то ваша команда не такая уж и производительная
SP для задач проставляет команда. Никакой системы оценивания единой для двух команд быть не может, тем более если стоимость у них настолько различается.
Всё, что даёт SP это велосити, на основании которого старшие "товарищи" могут прикидывать, за сколько спринтов конкретная команда будет разгребать то, что уже наэстимировала в свой беклог.
В том то и суть, что такая система может быть, и на стоимость надо обращать внимание. Я говорю об этом в самом конце статьи. К тому же, мы это используем в своей компании, поэтому я знаю, о чем говорю.
Разумеется, если у вас одна команда стоит дороже, значит она по идее должна быть производительнее, так как там более квалифицированные и дорогостоящие сотрудники.
Конечно, можно ожидать, что эта команда при бОльшей себестоимости будет более производительнее. А вторая команда при меньше себестоимости будет менее производительнее, и это нормально.
Было бы ненормально, если было бы наоборот.
Но вообще я согласен, что сравнивать две команды - это не очень хорошо, поэтому в данной статье про это буквально два слова.
Цель - это сравнивать производительность своей команды с самой собой.
"Всё, что даёт SP это велосити" - это лишь ограничение вашего применения SP. И SP не всегда дает понимание, за сколько спринтов вы "разгребете", если вы не знаете динамику производительности своей команды.
Нет. SP это валюта которая имеет ценность только в рамках команды после некой ретроспективы. При смене проекта, предметки, или состава команды ее ценность должна быть переопределена. SP, попугаи, может использовать только для оценки времени поставки фичи конкретной командой и не может быть использована за ее пределами. SP и их производные нельзя исполосовать для сравнения эффективности команд или для оценок стоимости.
Сначала появилась производительность, как количественная метрика, потом динамика производительности.. много я всяких передовых идей в аджайле повидал, но с таким не сталкивался.
Задумайтесь, какой физический смысл имеют абстрактные сторипойнты, делённые на инфляционные рубли при такой кредитной ставке и так ли стоит на подобном шатком фундаменте строить какие то выкладки)
Прямо вот при первом же разговоре. "Шэф, за прошлый год мы реализовали фич которые дают расчетную экономию времени сотрудников выше чем наш фот на следующие 10 лет, поэтому в этом году мы тратим все силы на разработку вместо расчетов, пожалуйста, дайте нам спокойно работать и не заниматесь микроменеджментом."
И только так, потому что все что далее - заблуждение граничащее с манипуляцией. Ну например
Но если я знаю, что соседняя команда стоит в 2 раза дешевле, но тоже делает 1000 SP при той же системе оценивания, что и ваша команда, то становится очевидным, то ваша команда не такая уж и производительная.
становится очевидным? это еще почему? А если я назову 10000 SP? 1М SP?
Она не просто относительная, она относительная для конкретной команды если у вас нет задач вне вашей компетенции.
сколько будет стоить реализация этой задачи, вы сможете их более-менее сориентировать.
Для начала вам нужно будет узнать какую потребность закрывает эта задача и убедиться, что эта задача именно эту потребность и закрывает. Очень часто если начать спрашивать какая цель преследуется, быстро выясняется что задача с целью не имеет ничего общего. Бизнес хочет хорошо, и работа разработчиков - делать хорошо. Бизнес не знает как можно сделать хорошо, он не шарит в технологиях.
А вообще, нет не сможете. Тут недавно был классный пример про выкапывание в грунте ямы 1х1х1.
Если честно, я не очень понял ваш комментарий. Точнее мне показалось, что вы не очень поняли, о чем моя статья. Но я попробую ответить.
"Для начала вам нужно будет узнать какую потребность закрывает эта задача и убедиться, что эта задача именно эту потребность и закрывает." - разумеется, нужно будет узнать. Но причем тут это? Моя статья вообще не об этом. Она о том, как в том числе посчитать себестоимость производства той или иной задачи. И то, это не самый главный посыл статьи.
Про относительность - согласен, но кажется, я и не утверждал обратного. Наоборот, в статье я очень четко указал, что это относительный показатель. Да, в идеале измерять только конкретную команду с самой собой.
Я надеюсь, что хорошие руководители не сравнивают свои команды с другими, а пытается понять и улучшить производительность только своей команды.
Если честно, я не очень понял ваш комментарий
О том что если вы начали играть в эти сомнительные игры, то либо у вас шаблонные задачи, либо путь в никуда.
Но причем тут это
Там цитата из вашего же текста. Нет вы не сможете подсчитать себестоимость производства какой либо задачи, просто потому что а) задача может совершенно не быть направлена на решение той боли которую хочет бизнес, б) вы можете не знатьв сех условий задачи, с) etc
я и не утверждал обратного.
Но если я знаю, что соседняя команда стоит в 2 раза дешевле, но тоже делает 1000 SP при той же системе оценивания, что и ваша команда, то становится очевидным, то ваша команда не такая уж и производительная.
Утверждал. Статью точно вы писали?
Я надеюсь, что хорошие руководители не сравнивают свои команды с другими,
См выше
Что бы я добавил
Вы выделили 4 типа задач, на квартал можно задать определенный капаситет на каждый из типов задач: фичи 50%, баги 20% и так далее.
Таким образом мы заранее знаем капаситеты и приоритизируем задачи согласно плану.
Согласен, можно попробовать. Но обычно планам не суждено сбываться :)
Как это обычно бываем, неожиданно всплывают какие-то важные баги, которые нужно фиксить.
А при реализации фичи уперлись в такое легаси, что нужно рефачить, поэтому по итогу проценты могут сильно съехать. Но в целом схема вполне рабочая.
Ну раз пришли к SP, то нужно продолжать двигаться в эту сторону))
Пора тогда начинать считайть capacity каждой команды и они легко могут разнится если эталоны задач в 1 SP разные у команд, это нормально.
И уже дальше смотрите на какой объем задач вы планировались, какой вышел по факту и как капасити команды отклоняется, в идеале чем дольше команда вместе тем капасити должен ползти вверх потихоньку, оценка все больше совпадать в фактом.
И уже спустя парочку кварталов можно оперировать этими цифрами при расчете стоимости реализации фич.
Менеджеры до сих пор на полном серйозе думают, что это не магическое мышление. А оценки, прогнозы, планирование и успех.
Выше уже указали, что сторипойнты не имеют смысла в отдельности от конкретной команды. Почему бы тогда не сделать оценку прямо в рабочих днях (часах) или в деньгах (если этот аспект прозрачен для команды)? В этом случае в итоге получится прямо коэффициент эффективности. Если при этом ещё ввести соревновательность в стиле "угадай мелодию" и KPI, привязанную к личной эффективности сотрудника, то заодно будет стимул к оптимизации эффективности.
И ещё, получается, что раз в вашем примере в январе была самая эффективная работа, а после ухода сотрудника стала самой неэффективной, то получается, эта эффективность ушла с сотрудником? И руководитель виноват, что не удержал его?
Это та же самая разница, что и между весом и массой в физике. Часы - это масса. Часы, оцененные в задаче, это субъективные часы одного разработчика, а ведь есть еще менеджмент, его часы другие, есть тестирование, есть код-ревью, есть работа аналитика, есть работа сопровождения, и стоимость каждого часа разная, и сравнивать задачи по сумме часов не имеет смысла, ведь тогда надо нормировать общие часы предварительно на таблицу коэффициентов. Тогда есть смысл оценивать уж в деньгах, как универсальной валютой меры измерений задачи. А сторипоинт - это вес. С какой силой задача давит на бэклог))) Проще для оценки, но суть та же самая - в конце ты получаешь стоимостную оценку. Но ведь команда не только делает задачи, но еще и ходит на дэйли, обсуждает задачи, имеет какие-то активности вне задач со своими линейными руководителями и так далее. Как следствие, измерение денег в задаче должно считаться с коэффициентом утилизации 8ч сотрудника аля "х2". Сторипоинт же нивелирует все эти ограничения заранее - просто мера неясного генеза, где эмпирически за полгода можно примерно понимать и стоимость 1сп и не держать в голове вот эти таблицы пересчета на часики.
Главное не превращать инструмент измерения в ОКР/KPI, а руководителей, не знакомых с этим принципом, не допускать до управления. Потому что ровно в тот момент, когда ты вместо критерия получаешь цель, начинаются манипуляции с данными, дробление задач и так далее. Та же история, к слову, с T2m (time 2 market). Когда вместо выпуска функциональности команда ради хороших зарплат начинает фичерить и декомпозировать функциональности так, чтобы быстро их показывать, но приносить этими маленькими выпусками по факту ровно 0 пользы (зачем тебе задача со спрограммированной кнопкой умножить в калькуляторе, когда тебе нужен весь калькулятор). Поэтому цель - всегда бизнесовая, метрика - всегда бизнесовая в профит/лосс
не соглашусь с вашим сравнением. Чаты давят на беклог аналогично сторипойнтам.
Часы аналитика, куа и разраба стоят по разному, но для выполнения задачи поработать надо всем - именно так, с учетом их зп + административки можно получить стоимость фичи.
Часами можно манипулировать точно также как и сторипойнтами. А можно и нет. К примеру, разработчик может честно считать время выполнения (оценка/списание), а если у него списанного времени за неделю 30 часов, а все остальное - это митинги и прочий продолб времени - это очень хорошо становится видно товарищам менеджерам.
25% времени уходит на коммуникацию - это дорого, например. Снижаем. Или "ок, это приемлемо".
В моем примере выше, я получаю точную стоимость безо всяких х2. Можно еще ввести таски на встречи и прочую ерунду - тогда можно точно считать, на что уходило время. По моему опыту, можно и без этого обойтись.
Но вы не посчитали производительность, вы посчитали стоимость. Скорее всего, вы делаете аутсорсинг, поэтому вам подходит, но заголовок не о том
Решение задач в программировании это творчество. Я могу закрыть как 20-30 сложных за неделю, так и 5 простых. Очень часто это упирается в аналитика, в бизнес, в банальную мотивацию.
Вы скажите команде, что бонусы будут зависеть от количества поинтов, так они вам миллион нарисуют и закроют.
Алексей, очень рад за вас, что вы задаёте себе и команде сложные вопросы, двигаетесь в сторону agile - это всё правильно.
Сейчас вам кажется, что ваши предположения и стратегия принесут плоды, но вы заблуждаетесь. Примеров много в комментариях выше.
Ваши коллеги и я тоже, уже прошли этот путь и работающих решений всего несколько и они хорошо изучены. Сделайте инвестицию в себя и пройдите один из курсов Practitioner Scrum master, и вы поймёте, что SP это сложность, что такое системное мышление, как важно определить оптимизационную задачу и тд. Для меня эта веха разделила мой опыт на до и после. Вы не пожалеете, успехов вам.
Эджайл коучи атакуют(
Ваш пост содержит слова "вы делаете шаги в верном направлении" , "вам кажется"
а дальше несколько непрошенных советов. Это - типичная манипуляция. Учитывая, что вы не поделились опытом и критикой подхода, вы не рассказали, как вы решаете подобные задачи - ваш пост выглядит рекламой.
Для того, чтобы команда работала производительно, нужно доверие и уважение во всей команде разработчиков.
Периодически попадаю в места с обязательными KPI:
- Либо приходилось рвать задницу на немецкий крест,
- либо устраивать показательную декомпозицию и потом каждый мелкий чих-пых накручивать по максимуму.
И то и другое за 30 лет разработки значительно опротивило, поэтому не задерживаюсь.
Когда в команде хорошая атмосфера, то задачки раскидываем по компетенции разрабов.
На сложные задачи садимся вместе и кумекаем, пока решение не будет прозрачно ясным.
После этого разраб уже сам допиливает задачу с удовольствием и нет ощущения выгорания.
Впервые вижу понятное объяснение, зачем нужны стори пойнты: чтобы дурак-руководитель, который оценивает работу команды, деля ФОТ на количество закрытых задач, независимо от их сложности, отвязался, в конце концов.
Ваш метод очень хорош для руководителей, которые не готовы делегировать ответственность за результат в разработке. Такие руководители должны продолжать самостоятельно контролировать требования на входе в разработку. Помимо измерения TP/velocity (кол-во story points на ед времени) советую измерять ещё:
Lead time (большинство проблем закопано именно там)
Change failure rate (высокую скорость можно легко хакнуть, пожертвовав качеством)
Однако, если руководитель хочет делегировать ответственность за результат в разработке, такая система измерения эффективности не подойдёт. Придется вспомнить, что разработку нельзя назвать производством. Потому что финальное действие в конвейере - деплой/публикация в бой, который называется ещё прод (production, производство). Получается производство по изменению производства? Бред.
На самом деле выше уже верно отметили, что результат разработки - какое-то изменение в бизнесе заказчика, имеющее для него значение, ценность. Эффективность в этом случае измеряется иными, продуктовыми/бизнесовыми методиками. Например, стоимость операции, переменный расход в канале, NPS-like метрики удовлетворенности сервисом, и т.д. Более подробно про действенные метрики эффективности в разработке можно почитать в ebm guide.
А так в целом описанный вами подход подойдёт для 80% руководителей в разработке. Как правило никто не готов делегировать ответственность за результат.
Я уже выше написал, тут кратко сформулирую еще раз.
ИТ производство - НЕ завод и вы сами это доказали своей статьей. На данном этапе развития технологий оценки задач могут быть только примерными. И это - принципиальное отличие
Тем не менее, подход применим с оговорками (лучше так, чем никак)
Оценивать точно также можно в часах, избегая дорогостоящей истории с покером планирования.
А еще лучше ориентироваться на списанное время. Да я в курсе критики списаний, но вы же сами сказали, что везде должен быть разумный подход. Если не драть команду за задержки, списания - отличный инструмент, а вы получаете планфактный анализ.
В целом, радует, что люди стараются считать себест. В больших конторах эффективные менеджеры считают по утилизации из таймшитов (а она там всегда 100%, как вы понимаете)
Как посчитать производительность команды разработки?