Эта глава будет вместо предисловия
Представьте, что вы - руководитель команды разработки в 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 рубля, если опираться на вычисленные выше данные.
