Стоимость сторипоинта как индикатор эффективности разработки
Если вы решили оптимизировать команду разработки, или просто постоянно работаете с ее кадровым составом — вот инструмент, который вам поможет. Этот инструмент — отслеживание динамики стоимости произведенного storypoint’а.
Привет!
Сегодня я хочу поделиться простой метрикой, за динамикой которой я наблюдала годами, наступала на ее грабли и сделала из этих наблюдений кучу интересных выводов. Стоимость сторипоинта — это величина, характеризующая эффективность вашей команды разработки.
Стоимость сторипоинта считается по простой формуле:
стоимость SP =
ФОТ разработки / количество вышедших в прод сторипоинтов
А анализ динамики этого показателя удобно отобразить на графике:
Понимаю, что в каждой компании свой подход к оценке трудозатрат. Не пытаясь убедить кого-то в своей правоте, опишу как оценивались задачи в команде, с которой я работала:
- Все задачи, которые касаются кода, оцениваются в сторипоинтах. Менторинг новичков, выступления на конференциях и внутренних митапах, участие во встречах — не оценивается в сторипоинтах.
- Все команды и все компетенции (фронты, бэки, датасайнтисты, мобильные разработчики, аналитики) оценивают задачи по одной шкале, и их оценки можно сравнивать между собой. Это сложно, мы пришли к этому за несколько лет, и как мы это сделали — заслуживает отдельной статьи.
- Оценивать или не оценивать починку багов в сторипоинтах — вопрос дискуссионный. Если не оценивать — получится более чистый показатель, связанный с инновациям. Если оценивать — будет более общий показатель производительности команды. Мы оценивали и смотрели на общую производительность.
- Тестировщики оценивали свою работу своими способами, мы здесь это не учитываем. Зато их ФОТ, как и зарплаты менеджмента, входят в общий ФОТ отдела.
- Среди разработчиков есть стажеры, джуны, миддлы, сеньоры и лиды. Естественно, их зарплаты и производительность — разные.
Итак, у нас есть разработчики, которые оценивают свои задачи в общих единицах, и есть то, сколько бизнес тратит на их содержание. Команда постепенно трансформируется: джуны подрастают в миддлов, кто-то уходит из команды, а кто-то приходит, зарплаты растут. Но мы следим за динамикой стоимости сторипоинта во времени.
Больше или меньше?
Если стоимость сторипоинта со временем падает — это хорошо?
Ответ — нет.
Парадоксально, но ваша задача — поддерживать стоимость сторипоинта примерно на одном уровне.
В естественных условиях и в хороших командах стоимость сторипоинта всегда постепенно растет, вот почему:
- инфляция подгоняет рост зарплат. Если зарплаты разработчиков долго не индексировать вообще — они начнут искать другие места.
- разработчики повышают свою квалификацию и хотят за это бОльшую компенсацию. Тот, кто год назад пришел стажером, сейчас уже уверенный джун, а значит, его зарплата выросла. Если у вас хорошая корпоративная культура и нет избыточной текучки — ваша команда постепенно «матереет» и становится дороже.
- главный удивительный факт: джуны производительнее лидов. Это происходит из-за того, что они делают много мелких задач по 0,5-1,2 сторипоинта и за спринт могут переварить десяток-другой простых тасков. А лиды, как за ними не смотри, склонны зависать над «восьмеркой» непрогнозируемо долго. Плюс, чем лидовее специалист, тем больше времени он проводит на встречах, уделяет внимание новичкам, ходит на конференции — и собственно на код остается меньше и меньше времени. Поэтому, пока ваша команда «матереет» — она становится не только более дорогой, но и более медленной.
Если же вы не меняли принцип оценки и не меняли радикально процессы в разработке, а стоимость сторипонта существенно упала — это можно значит только одно: вслед за ней устремилось вниз качество вашего выходного продукта. Стоимость сторипоинта может падать, если:
- Вы потеряли нескольких ценных лидов на высоких зарплатах. Кто сейчас делает их работу — осуществляет код-ревью, проектирует сложные решения и согласовывает их с бизнесом, занимается корпоративной культурой? Скорее всего никто.
- Вы вывели толпу стажеров. Их много, они стоят дешево и кодят как не в себя. Качество их работы слабо контролируется, поскольку они не уравновешены достаточным количеством менторов и ревьюверов. Это закончится забагованным продом, откатами релизов и бардаком в кодовой базе.
- Вы пожертвовали непроизводящими кадрами. Это, в первую очередь, QA и менеджмент. Вроде как разработчиков столько же, но теперь они тестируют свои задачи сами, и формализуют требования к этим задачам тоже сами. А то и вместе с бизнесом участвуют в генерации гипотез. Вслед за падением стоимости, падет сначала скорость, а потом и качество, поскольку разработчики теперь заняты не своей работой.
Фиксируем стоимость сторипоинта
Если стоимость сторипоинта не меняется, это значит что вы держите баланс качества и скорости вывода в продакшн на одном уровне, и этот уровень вас устраивает.
Как сделать так, чтобы стоимость сторипоинта не менялась? Нужно противодействовать силам удорожания, например вот так:
- Нанимайте старшим специалистам стажеров и джунов. Синьоры и лиды часто уже не хотят копаться в простых задачах, их квалификации хватает для работы со сложными решениями. Тем не менее, кто-то должен чинить баги и добавлять в продукт минорные фичи. Приставьте к лиду с ФОТом в 500к двух стажеров по 50к каждый, и ваш суммарный ФОТ этой банды вырастет всего на 20%, а польза вырастет многократно.
- При росте грейдов сотрудников поддерживайте пропорцию новичков и старичков. Ваши сотрудники развиваются — пятнадцать вчерашних миддлов стали пятнадцатью синьорами. Это совсем другой уровень расходов. Можете ли вы это потянуть? Есть ли у вас такое количество синьорских задач? В вашей ситуации лучше один синьор или три джуна за те же деньги? Если 15 синьоров для вас это благо — прекрасно. Идеально, если ваши возможности растут с ростом ваших специалистов. А если нет — оставьте наиболее талантливых, мотивированных и лояльных, остальным дайте хорошие рекомендации и посодействуйте в поиске нового места. Если этого не делать — команда будет двигаться в сторону увеличения качества и потери темпа. Хорошо это или плохо — решать вам. Конечно, такие принципы принятия решений в компании должны быть полностью прозрачны, и этот процесс не для кого не должен стать неожиданностью.
- Расставайтесь с теми, кому вы переплачиваете. Если у вас в команде есть люди на старших позициях, которые обладают уникальной экспертизой, но при этом и не производят достаточно поинтов, и не менторят кучку новичков — расставайтесь. Людям свойственна интертность, и этот сотрудник, скорее всего, не ищет себе другого места, его все устраивает. Он к вам привык, и вы к нему привыкли. Но объективно он тормозит всю команду. Передайте его экспертизу другим членам команды — через документацию, внутреннее обучение, подключение к сложным проектам. А потом на ФОТ этого сотрудника наймите двух бодрых замотивированных миддлов.
- Когда люди уходят сами — думайте дважды, прежде чем искать им замену. Допустим, у вас ушел миддл. Стоит ли сразу на его место искать другого миддла? Или может, оценить структуру оставшейся команды, и сделать вывод о том, что её уравновесят два хороших джуна? Или чуть доплатить и нанять сразу синьора? Или вообще потратить освободившийся ФОТ на дополнительных тестировщиков?
- Если у вас появились дополнительные ресурсы и вы готовы отмасштабировать команду — нанимайте пропорционально младших, средних, старших специалистов, а к ним — менеджмент и тестирование, чтобы стоимость, качество и скорость производства оставались на том же уровне.
Меняем стоимость сторипоинта
До этого мы исходили из того, что вас устраивает скорость, качество и стоимость разработки. Это три фактора находятся в балансе. Но что, если нет?
Не устраивает скорость
- готов пожертвовать качеством, не готов к инвестициям. Я не одобряю, но убираем непроизводящих (менеджмент и QA) и сокращаем количество лидов и синьоров и на их место добавляем миддлов. Миддлы — основная производящая сила, они быстрее синьоров, но самоходные, не требуют столько внешнего внимания. Стоимость сторипоинта должна упасть.
- не готов пожертвовать качеством, готов к инвестициям. Масштабируем команду примерно в тех же пропорциях всех специалистов, которые есть сейчас. Стоимость сторипоинта не должна меняться.
Не устраивает качество
- готов замедлиться, не готов к дополнительным тратам. Например, у вас накопилась гора технического долга, вы осознанно хотите потратиться на стабилизацию системы и рефакторинг. Вам нужно не латать дыры, а найти системные проблемы. Сокращаем количество стажеров и джунов, которые расфокусируют синьоров и лидов. На освободившиеся деньги берем QA и хороший технический менджмент - СТО или архитектора. Занимаемся документацией, архитектурой, багами, пересобираем процессы, рефакторим, обновляем. Вывод инноваций тормозим. Стоимость сторипоинта будет стремительно расти.
- не готов замедляться, готов к дополнительным тратам. Оставляем немного джунов и чуть побольше миддлов, которые много делают и чинят баги, но усиливаем состав синьоров, лидов, менеджмента и тестирования. Сажаем дополнительных синьоров на архитектуру и рефакторинг. Стоимость сторипоинта будет не так стремительно, но тоже расти.
Все хорошо — качество и скорость, но очень дорого
- Аккуратно подрезаем на всех уровнях, стараясь сохранять пропорцию. Стоимость сторипоинта не должна меняться.
Не устраивает и качество, и скорость, не готов к дополнительным инвестициям.
Прекрасный кейс, на этот случай как раз есть картинка на все времена:
А если серьезно — то в этом случае уже точно нужно смотреть не на кадровые изменения, а на процессы. Процессы вообще надо оптимизировать во всех случаях. Кадровые изменения и изменения процессов должны идти рука об руку. Но это уже совсем другая история.
Типичные ошибки
Закрепим набором решений, которые я видела своими глазами. Как не надо. Я даже не буду уже расписывать почему не надо, просто «нет»:
- Хотим улучшить качество и стабилизировать продукт — берем бесплатных стажеров.
Индикатор неверного решения — падает стоимость SP.
Результат: люди, которые должны были заняться архитектурой и стабилизацией рассказывают стажерам как кодить. - Хотим оптимизировать команду без потери скорости — увольняем новичков, оставляем только старых матерых разработчиков.
Кост SP растет.
Результат: синьоры с 8-летним опытом не хотят ковыряться в багах и делать тривиальные задачи, никто ничего не делает, процессы вязнут в согласованиях. - Хотим оптимизировать команду без потери качества — увольняем QA и менеджмент (потому что они же не пишут код). Что? Да!
SP стали сильно дешевле.
Результат: один менеджер пытается управиться с более чем десятком человек, один тестер разрывается на несколько команд, с прода регулярно откатываются релизы с критическими багами, новые фичи не релизятся месяцами.
Ну и все в таком духе. Перед тем, как принимать управленческие решения о составе команды, очень полезно провести этот мысленный эксперимент — как отреагирует на изменение метрика стоимости сторипоинта. Это поможет оценить адекватность и непротиворечивость вашего решения.