Стоимость сторипоинта как индикатор эффективности разработки

Если вы решили оптимизировать команду разработки, или просто постоянно работаете с ее кадровым составом — вот инструмент, который вам поможет. Этот инструмент — отслеживание динамики стоимости произведенного storypoint’а.

Привет!

Сегодня я хочу поделиться простой метрикой, за динамикой которой я наблюдала годами, наступала на ее грабли и сделала из этих наблюдений кучу интересных выводов. Стоимость сторипоинта — это величина, характеризующая эффективность вашей команды разработки.

Стоимость сторипоинта считается по простой формуле:

А анализ динамики этого показателя удобно отобразить на графике:

Понимаю, что в каждой компании свой подход к оценке трудозатрат. Не пытаясь убедить кого-то в своей правоте, опишу как оценивались задачи в команде, с которой я работала:

• Все задачи, которые касаются кода, оцениваются в сторипоинтах. Менторинг новичков, выступления на конференциях и внутренних митапах, участие во встречах — не оценивается в сторипоинтах.
• Все команды и все компетенции (фронты, бэки, датасайнтисты, мобильные разработчики, аналитики) оценивают задачи по одной шкале, и их оценки можно сравнивать между собой. Это сложно, мы пришли к этому за несколько лет, и как мы это сделали — заслуживает отдельной статьи.
• Оценивать или не оценивать починку багов в сторипоинтах — вопрос дискуссионный. Если не оценивать — получится более чистый показатель, связанный с инновациям. Если оценивать — будет более общий показатель производительности команды. Мы оценивали и смотрели на общую производительность.
• Тестировщики оценивали свою работу своими способами, мы здесь это не учитываем. Зато их ФОТ, как и зарплаты менеджмента, входят в общий ФОТ отдела.
• Среди разработчиков есть стажеры, джуны, миддлы, сеньоры и лиды. Естественно, их зарплаты и производительность — разные.

Итак, у нас есть разработчики, которые оценивают свои задачи в общих единицах, и есть то, сколько бизнес тратит на их содержание. Команда постепенно трансформируется: джуны подрастают в миддлов, кто-то уходит из команды, а кто-то приходит, зарплаты растут. Но мы следим за динамикой стоимости сторипоинта во времени.

Если стоимость сторипоинта со временем падает — это хорошо?

Ответ — нет.

В естественных условиях и в хороших командах стоимость сторипоинта всегда постепенно растет, вот почему:

1. инфляция подгоняет рост зарплат. Если зарплаты разработчиков долго не индексировать вообще — они начнут искать другие места.
2. разработчики повышают свою квалификацию и хотят за это бОльшую компенсацию. Тот, кто год назад пришел стажером, сейчас уже уверенный джун, а значит, его зарплата выросла. Если у вас хорошая корпоративная культура и нет избыточной текучки — ваша команда постепенно «матереет» и становится дороже.
3. главный удивительный факт: джуны производительнее лидов. Это происходит из-за того, что они делают много мелких задач по 0,5-1,2 сторипоинта и за спринт могут переварить десяток-другой простых тасков. А лиды, как за ними не смотри, склонны зависать над «восьмеркой» непрогнозируемо долго. Плюс, чем лидовее специалист, тем больше времени он проводит на встречах, уделяет внимание новичкам, ходит на конференции — и собственно на код остается меньше и меньше времени. Поэтому, пока ваша команда «матереет» — она становится не только более дорогой, но и более медленной.

Если же вы не меняли принцип оценки и не меняли радикально процессы в разработке, а стоимость сторипонта существенно упала — это можно значит только одно: вслед за ней устремилось вниз качество вашего выходного продукта. Стоимость сторипоинта может падать, если:

• Вы потеряли нескольких ценных лидов на высоких зарплатах. Кто сейчас делает их работу — осуществляет код-ревью, проектирует сложные решения и согласовывает их с бизнесом, занимается корпоративной культурой? Скорее всего никто.
  
• Вы вывели толпу стажеров. Их много, они стоят дешево и кодят как не в себя. Качество их работы слабо контролируется, поскольку они не уравновешены достаточным количеством менторов и ревьюверов. Это закончится забагованным продом, откатами релизов и бардаком в кодовой базе.
• Вы пожертвовали непроизводящими кадрами. Это, в первую очередь, QA и менеджмент. Вроде как разработчиков столько же, но теперь они тестируют свои задачи сами, и формализуют требования к этим задачам тоже сами. А то и вместе с бизнесом участвуют в генерации гипотез. Вслед за падением стоимости, падет сначала скорость, а потом и качество, поскольку разработчики теперь заняты не своей работой.

Если стоимость сторипоинта не меняется, это значит что вы держите баланс качества и скорости вывода в продакшн на одном уровне, и этот уровень вас устраивает.

Как сделать так, чтобы стоимость сторипоинта не менялась? Нужно противодействовать силам удорожания, например вот так:

• Нанимайте старшим специалистам стажеров и джунов. Синьоры и лиды часто уже не хотят копаться в простых задачах, их квалификации хватает для работы со сложными решениями. Тем не менее, кто-то должен чинить баги и добавлять в продукт минорные фичи. Приставьте к лиду с ФОТом в 500к двух стажеров по 50к каждый, и ваш суммарный ФОТ этой банды вырастет всего на 20%, а польза вырастет многократно.
• При росте грейдов сотрудников поддерживайте пропорцию новичков и старичков. Ваши сотрудники развиваются — пятнадцать вчерашних миддлов стали пятнадцатью синьорами. Это совсем другой уровень расходов. Можете ли вы это потянуть? Есть ли у вас такое количество синьорских задач? В вашей ситуации лучше один синьор или три джуна за те же деньги? Если 15 синьоров для вас это благо — прекрасно. Идеально, если ваши возможности растут с ростом ваших специалистов. А если нет — оставьте наиболее талантливых, мотивированных и лояльных, остальным дайте хорошие рекомендации и посодействуйте в поиске нового места. Если этого не делать — команда будет двигаться в сторону увеличения качества и потери темпа. Хорошо это или плохо — решать вам. Конечно, такие принципы принятия решений в компании должны быть полностью прозрачны, и этот процесс не для кого не должен стать неожиданностью.
• Расставайтесь с теми, кому вы переплачиваете. Если у вас в команде есть люди на старших позициях, которые обладают уникальной экспертизой, но при этом и не производят достаточно поинтов, и не менторят кучку новичков — расставайтесь. Людям свойственна интертность, и этот сотрудник, скорее всего, не ищет себе другого места, его все устраивает. Он к вам привык, и вы к нему привыкли. Но объективно он тормозит всю команду. Передайте его экспертизу другим членам команды — через документацию, внутреннее обучение, подключение к сложным проектам. А потом на ФОТ этого сотрудника наймите двух бодрых замотивированных миддлов.
• Когда люди уходят сами — думайте дважды, прежде чем искать им замену. Допустим, у вас ушел миддл. Стоит ли сразу на его место искать другого миддла? Или может, оценить структуру оставшейся команды, и сделать вывод о том, что её уравновесят два хороших джуна? Или чуть доплатить и нанять сразу синьора? Или вообще потратить освободившийся ФОТ на дополнительных тестировщиков?
• Если у вас появились дополнительные ресурсы и вы готовы отмасштабировать команду — нанимайте пропорционально младших, средних, старших специалистов, а к ним — менеджмент и тестирование, чтобы стоимость, качество и скорость производства оставались на том же уровне.

До этого мы исходили из того, что вас устраивает скорость, качество и стоимость разработки. Это три фактора находятся в балансе. Но что, если нет?

Не устраивает скорость

• готов пожертвовать качеством, не готов к инвестициям. Я не одобряю, но убираем непроизводящих (менеджмент и QA) и сокращаем количество лидов и синьоров и на их место добавляем миддлов. Миддлы — основная производящая сила, они быстрее синьоров, но самоходные, не требуют столько внешнего внимания. Стоимость сторипоинта должна упасть.
• не готов пожертвовать качеством, готов к инвестициям. Масштабируем команду примерно в тех же пропорциях всех специалистов, которые есть сейчас. Стоимость сторипоинта не должна меняться.

Не устраивает качество

• готов замедлиться, не готов к дополнительным тратам. Например, у вас накопилась гора технического долга, вы осознанно хотите потратиться на стабилизацию системы и рефакторинг. Вам нужно не латать дыры, а найти системные проблемы. Сокращаем количество стажеров и джунов, которые расфокусируют синьоров и лидов. На освободившиеся деньги берем QA и хороший технический менджмент - СТО или архитектора. Занимаемся документацией, архитектурой, багами, пересобираем процессы, рефакторим, обновляем. Вывод инноваций тормозим. Стоимость сторипоинта будет стремительно расти.
• не готов замедляться, готов к дополнительным тратам. Оставляем немного джунов и чуть побольше миддлов, которые много делают и чинят баги, но усиливаем состав синьоров, лидов, менеджмента и тестирования. Сажаем дополнительных синьоров на архитектуру и рефакторинг. Стоимость сторипоинта будет не так стремительно, но тоже расти.

Все хорошо — качество и скорость, но очень дорого

• Аккуратно подрезаем на всех уровнях, стараясь сохранять пропорцию. Стоимость сторипоинта не должна меняться.

Не устраивает и качество, и скорость, не готов к дополнительным инвестициям.

Прекрасный кейс, на этот случай как раз есть картинка на все времена:

А если серьезно — то в этом случае уже точно нужно смотреть не на кадровые изменения, а на процессы. Процессы вообще надо оптимизировать во всех случаях. Кадровые изменения и изменения процессов должны идти рука об руку. Но это уже совсем другая история.

Закрепим набором решений, которые я видела своими глазами. Как не надо. Я даже не буду уже расписывать почему не надо, просто «нет»:

• Хотим улучшить качество и стабилизировать продукт — берем бесплатных стажеров.
  Индикатор неверного решения — падает стоимость SP.
  Результат: люди, которые должны были заняться архитектурой и стабилизацией рассказывают стажерам как кодить.
• Хотим оптимизировать команду без потери скорости — увольняем новичков, оставляем только старых матерых разработчиков.
  Кост SP растет.
  Результат: синьоры с 8-летним опытом не хотят ковыряться в багах и делать тривиальные задачи, никто ничего не делает, процессы вязнут в согласованиях.
• Хотим оптимизировать команду без потери качества — увольняем QA и менеджмент (потому что они же не пишут код). Что? Да!
  SP стали сильно дешевле.
  Результат: один менеджер пытается управиться с более чем десятком человек, один тестер разрывается на несколько команд, с прода регулярно откатываются релизы с критическими багами, новые фичи не релизятся месяцами.

Ну и все в таком духе. Перед тем, как принимать управленческие решения о составе команды, очень полезно провести этот мысленный эксперимент — как отреагирует на изменение метрика стоимости сторипоинта. Это поможет оценить адекватность и непротиворечивость вашего решения.

#projectmanagement #управлениепроектами #оптимизация #storypoints #оценказадач #productmanagement