Эта глава будет вместо предисловия
Представьте, что вы - руководитель команды разработки в IT-компании. Живете себе спокойно, никого не трогаете, делаете с командой проекты, закрываете задачи. И вот в какой-то момент к вам приходит ваш непосредственный руководитель и спрашивает вас:
Слушай, а твоя команда вообще производительна?
И тут вы понимаете, что вопрос застал вас врасплох. В вашей голове запускается мыслительный процесс:
Так, ну мы делаем много задач. Конечно, что-то мы периодически не успеваем, но команда и так на пределе своих возможностей. Периодически мы даже не все успеваем сделать из того, что хотели, но вроде как бизнес не страдает...
Руководитель замечает на вашем лице неоднозначную задумчивость и говорит:
В общем, смотри, что мне нужно. Посчитай, сколько задач вы сделали за предыдущий квартал. И собери информацию, сколько стоила твоя команда в этот период. С этими данными приходи ко мне.
И вот вы идете в свой трекер задач, собираете информацию и видите следующую картину:
После этого идете собирать финансовые данные за предыдущий квартал по вашей команде и видите такие данные:
С этой информацией вы возвращаетесь к своему руководителю, он смотрит на это, после чего между вами завязывается следующий диалог:
— Руководитель: А почему у тебя так скачет стоимость команды от месяца к месяцу?
— Ты: В конце середине февраля ушел один разработчик, мы на его место пока никого не нашли. А в марте были плановые повышения.
— Руководитель: Хорошо. Вижу, что у вас почти половина реализованных задач за квартал — это баг‑фиксинг. Очень плохо! Почему такие плохие показатели?
— Ты: Если честно, я сам не ожидал. Конечно, мы действительно исправляем ошибки, но у меня не было ощущения, что это занимает столько времени у команды.
— Руководитель: Цифры говорят все сами за себя! Давай смотреть дальше... Вы сделали 217 задач за квартал. В первом квартале у нас 90 дней. То есть вы делали чуть меньше, чем 2.5 задачи в день, так? Тоже не внушительный показатель... Когда я руководил командой, которая стоит столько же, сколько и твоя, мы могли делать по 7 задач в день!
— Ты: Но ведь в первом квартале много праздников. Рабочих дней было на самом деле 56. Это значит, что мы делали почти по 4 задачи в день.
— Руководитель: Согласен... Но это все‑равно не самый лучший показатель! Теперь давай посчитаем, сколько стоит одна задача, реализованная твоей командой. Стоимость всей команды за квартал получается 5 701 518 рублей. Если это поделить на весь объем задач, то получается, что средняя стоимость одной задачи будет 26 274 рубля.
— Ты: Да, действительно.
— Руководитель: Можешь иметь это ввиду в следующий раз при оценке стоимости проекта. Так, ладно, показатели надо улучшать, понятно?
— Ты: Понятно...
— Руководитель: В следующем квартале у тебя должны быть следующие показатели: 6 задач в день, а значит 366 задач за квартал — вот это показатель! Большая часть из них должна быть фичами! Раз больше задач, тогда и стоимость задачи у тебя станет меньше. Будет примерно 15 000 рублей. Бизнес будет доволен. Все, иди!
И вот возвращаетесь вы на свое рабочее место и в голове вашей созревают сомнения...
Ничего не понимаю! Да, мы действительно сделали меньше фичей в количественном соотношении, чем баг-фиксинг. Но ведь я помню, что мы делали большие фичи, которые заняли большую часть времени команды. А большинство ошибок вообще фиксилось за 5 минут!
И что это за странная цена за стоимость задачи? То есть, если ко мне придут за оценкой любой задачи, то я должен сказать, что любая задача стоит 26 274 рублей? Ну это же бред! А если задача очень большая? Или наоборот, очень маленькая?! Что-то с этими показателями не так!
И вы действительно правы. С этими показателями не просто что-то не так, с ними совершенно нельзя работать, и на них совершенно нельзя полагаться!
Но, к сожалению, в нашей индустрии очень многие руководители оперируют этими показателями. Я сам множество раз сталкивался с таким.
Что ж, давайте разберемся, как на самом деле нужно считать производительность команд разработки. Но прежде чем начать, нужно ответить на один любопытный вопрос.
В чем отличие команд разработки от производства на заводе?
На самом деле, практически ничем с фундаментальной точки зрения.
Что такое завод? Завод — это предприятие, на котором производят некую продукцию.
А что такое команда разработки? Это группа лиц, которая точно также производит некую продукцию, только не физическую, а цифровую.
Только вот на заводе по большей части производят одинаковую продукцию. Например, завод, который производит конкретную марку автомобиля. Помимо этого, на заводе обычно все гораздо понятнее с количеством сотрудников, а также их заработной платой. Например, на заводе есть конвейер, который включает в себя 50 рабочих мест. Из них:
6 мест для руководителей с окладом 100 000 рублей
12 мест для ведущих инженеров с окладом 80 000 рублей
20 мест для обычных инженеров с окладом 50 000 рублей
12 мест для младших инженеров с окладом 30 000 рублей
Итого стоимость всего конвейера: 2 920 000 рублей
Так как эта команда производит всего одну и ту же марку автомобиля, абсолютно ничем не отличающуюся друг от друга, то описанные показатели в первой главе действительно можно применить к заводу.
Например, произвели в январе 89 автомобилей, в феврале 91, а в марте 87. Итого 267 автомобилей за квартал. А в следующем квартале при той же себестоимости произвели почти столько же - 271, хотя рабочих дней во втором квартале гораздо больше, чем в первом. Значит что-то не так, значит второй квартал был менее эффективным и производительным.
Или, например, была придумана система, при которой получилось сократить штат, но не снизить производительность завода. И по итогу получилось сделать одинаковое количество автомобилей за одинаковое количество дней, но в первом случае на команду ушло 2 920 000 рублей, а во втором случае 2 220 000 рублей.
Так вот, отсюда вытекает следующий вопрос, на который необходимо ответить.
Каким образом реализовать в IT такую же систему, как на заводе?
Оказывается, очень просто!
В первую очередь необходимо ввести единицу измерения, которая отвечала бы на вопрос: является та или иная задача большой или маленькой?
К счастью, умные люди давно уже придумали такую систему измерения и назвали ее Story Point. Story Point (далее SP) — это единица измерения, которую команды в Agile (особенно Scrum) используют для оценки относительной сложности или объёма работы, необходимого для реализации задачи.
Конечно, оценка в SP никогда не даст вам универсальности, потому что произвести 1 SP командой разработки никогда не будет ровняться тому же самому, что произвести 1 деталь на заводе. Но все-таки эта единица измерения действительно даст вам некую систему, которая сможет гораздо более точно ответить вам на вопрос: какая производительность у моей команды?
Далее вам необходимо выработать некие правила в оценке задач в SP. Например, это могут быть такие правила:
1 SP — задача требует минимальных усилий в реализации, но при этом не является задачей на 5 минут
2 SP — реализация понятна, никаких подводных камней не предвидится, но нужно приложить немного времени и усилий к реализации
3 SP — реализация задачи также понятная, столкновение в подводными камнями минимальны, но требуется больше времени для реализации
5 SP — либо есть какие‑то неопределенности в разработке, либо все понятно, но реализация задачи уже наверняка объемная и займет пару‑тройку рабочих дней
8 SP — определенно объемная задача, которая займет несколько дней реализации, но пока еще не требующая декомпозиции
13 SP — большая задача, которая уже явно требует декомпозиции
и т. д.
После того, как вы определили правила, вам необходимо начать оценивать каждую задачу на разработку через SP. Таким образом, у вас начнет появляться некий показатель, отвечающий за реальный объем производства команды.
Для того, чтобы оценивать задачи в SP, есть процесс, который называется Покер планирования. Но моя статья не об этом, так что предлагаю вам самим поискать в интернете, как проводится это мероприятие.
Так каким образом все-таки посчитать производительность?
Допустим, вы начали применять описанные выше практики в своей команде разработки. Давайте вернемся в самое начало статьи и представим, будто вы с командой оценили в SP все задачи, реализованные за тот квартал. После чего снова собрали диаграмму, показывающую все закрытые задачи в квартале, но отображающие не количество этих задач, а их объем в SP. Что же вы можете теперь увидеть?
Теперь мы видим, что 217 реализованных задач превратились в 718 SP. Но что еще важнее, теперь мы видим, как этот объем задач в SP распределялся по типам задач. Для наглядности давайте я еще раз продублирую изначальную диаграмму.
Какие выводы можно сделать теперь?
Да, больше всего реализованных задач (34%) - это баг-фиксинг, НО оказывается, что лишь 22% всех трудозатрат команды ушло на решение ошибок. Это объясняется тем, что большая часть ошибок была маленькими по трудозатратам.
Всего 45 задач на рефакторинг (20%) превращаются в 28% трудозатрат команды, потому что обычно рефакторинг - это объемная переработка текущего функционала, требующая много времени.
Ну и самое главное! Оказывается, что все-таки большая часть ресурсов команды уходит на реализацию нового функционала, даже не смотря на то, что по количеству задач этот показатель на втором месте. Объясняется это также тем, что новый функционал часто бывает большим по объему реализации.
Теперь это действительно объективный показатель, с которым можно идти к своему руководителю. А чтобы ему было еще понятнее, давайте вернемся к тем показателям, которыми он оперировал, но теперь на основе SP.
Метрики производительности команды разработки
В первую очередь надо понять, что производительность - это относительный показатель. Например, если вы скажете мне, что ваша команда сделала в этом месяце 1000 SP, то я в любом случае не смогу ответить на вопрос, является ли ваша команда производительной.
Но если я знаю, что соседняя команда стоит в 2 раза дешевле, но тоже делает 1000 SP при той же системе оценивания, что и ваша команда, то становится очевидным, то ваша команда не такая уж и производительная.
Или, например, я знаю, что та же самая команда под моим руководствам год назад делала 1300 SP, тогда я также могу заявить, что команда явно не на пике своей производительности.
Что ж, давайте все-таки уже поймем, как нам начать отслеживать производительность команды!
Во-первых, нужно начать отслеживать объем выполненных задач в SP в разрезе каждого отведенного промежутка времени, например, каждый месяц. Давайте на примере выше поймем, как это может выглядеть.
У нас было всего 718 SP за первый квартал. Собрали информацию по месяцам и увидели, что февраль был самым производительным месяцем - целых 284 SP.
Но на самом деле сравнивать в таком формате месяц к месяцу можно только в том случае, если они нормированы, то есть в каждом месяце одинаковое количество рабочих дней.
Но чаще всего месяцы не нормированы: в одних может быть больше рабочих дней, чем в других. Как быть в таком случае?
Вводим новую метрику - среднее количество SP в один рабочий день в рамках месяца. То есть нужно понять, сколько рабочих дней было в конкретном месяце и весь объем выполненных задач поделить на количество рабочих дней. Получаем следующую картинку.
Да, февраль действительно был самым производительным месяцем, потому что в среднем каждый день производилось 15 SP. А вот январь, который на первый взгляд был самым непроизводительным, оказался на втором месте.
Тут руководителю стоит задаться вопросом: что произошло с командой в марте? Почему она вдруг так снизила темпы производства? Забегая вперед, могу сказать, что найти ответ на этот вопрос является одной из самых главных задач руководителя, но об этом мы с вами поговорим как-нибудь в другой раз.
А сегодня нам снова нужно вспомнить про относительность производительности, а также стоимость производства. Как мы помним по самому началу статьи, в феврале из команды ушел разработчик. Возможно, он перед уходом решил ускоренно доделать все задачи, а в марте уход этого разработчика сказался уже полноценно, поэтому спад производительности ожидаем?
Что самое главное в такой ситуации стоит понять руководителю? Ответ следующий: как производительность отразилась на финансовой эффективности команды?
Давайте попробуем понять, как нам ответить на этот вопрос.
Экономическая составляющая
На самом деле, в итоге нам надо понять, сколько стоит один SP, сделанный этой командой разработки.
Для этого сперва берем вычисленный ранее показатель - среднее кол-во SP в день и делим на 8 = количество рабочих часов в сутки. Таким образом мы получаем количество SP, реализованных в час.
Также надо понять среднюю стоимость команды в час в конкретный месяц. Для этого всю стоимость команды делим на количество рабочих часов в этом месяце.
Теперь, если мы поделим среднюю стоимость команды в час на стоимость одного SP в час, то получим стоимость в деньгах 1 SP в конкретном месяце.
Давайте посмотрим наглядно, что у нас получилось.
Январь | Февраль | Март | |
Количество SP час | 12 / 8 = 1,5 | 15 / 8 = 1,875 | 11 / 8 = 1,375 |
Стоимость команды в час (в рублях) | 2 091 841 / (17*8) = 15 381 | 1 741 319 / (19*8) = 11 456 | 1 741 319 / (20*8) = 11 677 |
Цена 1 SP (в рублях) | 15 381 / 1,5 = | 11 456 / 1,875 = | 11 677 / 1,375 = |
В среднем по итогу квартала получаем (9 961 + 6 131 + 8 341) / 3 = 8 144 рубля
Думаю, вы уже догадались, что именно мы с вами посчитали. Цифры, к которым мы пришли, являются реальной себестоимостью производства!
Вы можете мне возразить, якобы себестоимость производства - это операционные затраты на команду разработки. Тут я с вами могу отчасти согласиться, но я немного про другое.
Теперь мы с вами видим, что производство в феврале было самым дешевым, потому что за отведенное количество дней (19) и определенную стоимость команды (1 741 319 рублей) производство 1 SP стоило всего 6 131 рубль.
А производство в марте было самым дорогим, потому что с учетом 17 рабочих дней и 2 091 841 затраченных рублей производство 1 SP стоило 9 961 рублей.
И вот теперь наконец-таки уже можно делать настоящие выводы о том, насколько ваша команда является производительной!
По итогу все сводится к тому, чтобы отслеживать 2 показателя:
Среднее количество SP в один рабочий день. В идеале этот показатель должен уменьшаться только в том случае, если вместе с ним уменьшается и стоимость стоимость реализации 1 SP.
Стоимость реализации 1 SP. В идеале этот показатель должен увеличиваться только в том случае, если у вас увеличивается среднее количество SP в один рабочий день.
Если ни одно из описанных выше правил не соблюдается, значит над производительностью команды стоит поработать. А вот каким образом - об этом я напишу как-нибудь в другой статье.
P.S
В конце небольшой бонус. Теперь, когда бизнес придет к вам с задачей и попросит оценить, сколько будет стоить реализация этой задачи, вы сможете их более-менее сориентировать.
Все, что вам для этого надо, лишь оценить задачу в SP и умножить ее на вашу среднюю себестоимость производства. Например, задача на 8 SP обойдется вашей команде в 65 152 рубля, если опираться на вычисленные выше данные.
