Эксперты Кент Бек (имеет 40-летний опыт разработки программного обеспечения и почти все это время занимался вопросом измерения производительности разработчиков) и Гергелий Орош (15-летний опыт разработки программного обеспечения, включая 5 лет руководства инженерными командами) проанализировали статью крупной консалтинговой организации McKinsey про недавно созданный подход к измерению производительности разработчиков программного обеспечения, и, будучи несогласными с таким подходом, поделились своим мнением про более эффективные методы.
Мы также хотим познакомить наших читателей с методикой Кента Бека и Гергелия Ороша и посвящаем этому вопросу серию статей.
Что происходит, когда вы начинаете все измерять?
Кент Бек проработал в Facebook 7 лет и имеет непосредственный опыт в подобной ситуации. Как он рассказал:
“В Facebook мы ввели такие опросы, которые рекомендует McKinsey. Это было хорошо в течение года. Опросы давали ценную информацию о текущем состоянии настроений разработчиков.
Затем специалисты решили, что нужно сделать результаты опроса более наглядными, чтобы можно было отслеживать тенденции во времени. Они также вычислили общую оценку по результатам опроса. Вполне разумный поступок. Так продолжалось еще год. 4,5 балла стали 4 баллами. Что произошло?
Потом эти оценки стали появляться в обзорах эффективности, в виде фразы “и они так хорошо работают, что их оценка составляет 4,5”. Это было хорошо еще год.
Затем эти оценки стали складываться в иерархию. Оценка менеджера представляла собой среднее арифметическое оценок его подчиненных. Оценка директора складывалась из средних оценок его подчиненных менеджеров.
И вот тут-то все стало уже не очень хорошо. Директора оказывали давление на менеджеров, требуя от них более высоких оценок. Менеджеры начали договариваться с отдельными сотрудниками о получении более высоких оценок. “Дайте мне 5 баллов, и я позабочусь о том, чтобы вы получили оценку “превосходит ожидания””. Директора начали сокращать менеджеров и команды с плохими показателями, независимо от того, имело это организационный смысл или нет”.
Ситуация изменилась от “мы хотели бы знать, как обстоят дела” до “мы знаем еще меньше о том, как обстоят дела. Но они определенно ухудшаются, потому что люди теперь играют с системой”.
Почему это произошло? Потому что в компании начали измерять и стимулировать (деньгами и статусом) изменения в показателях! А измерение ведет к изменению поведения – в том числе к поиску творческих путей улучшения результатов измерения даже за счет результатов, важность которых признается всеми.
В этой статье, Кент Бек и Гергелий Орош попытаются помочь руководителям отделов разработки ответить на вопрос: Можно ли измерить производительность разработчиков? Это совокупность их взглядов, профессионального опыта и того, что они видели на собственными глазами.
Какие задачи стоят перед нами на практике?
Статья консалтинговой компании, не поддерживаемая Гергелием Ошером и Кентом Беком, но послужившая толчком к данной статье, была написана не просто так: генеральные и финансовые директора все чаще разочаровываются в том, что технические директора разводят руками и говорят, что программная инженерия слишком сложна для измерения, в то время как у отделов продаж есть индивидуальные показатели и квоты, которые нужно выполнить, а у отделов по подбору персонала – количество вакансий, которые нужно заполнить. Руководители рассуждают так: если другие группы могут измерять индивидуальные показатели, то абсурдно, что разработчики не могут этого делать.
Реальность такова, что сегодня руководители подразделений программной инженерии не могут избежать вопроса о том, как измерить производительность разработчиков. Если они попытаются это сделать, то рискуют тем, что генеральный или финансовый директор обратится на помощь к какой-нибудь консалтинговой компании, которая привезет свой собственный фреймворк, развернет его – даже если технический директор будет протестовать – и начнет отчитываться по таким показателям, как ” Бенчмарк-индекс скорости работы разработчиков”, “Анализ вклада в результат” и ” Способность к развитию таланта”.
Эксперты считают, что введение такой системы является ошибочным и может привести к обратному результату. Скорее всего, такой подход принесет организациям и культуре разработки в компаниях гораздо больше вреда, чем пользы. На ликвидацию такого ущерба могут уйти годы. Так что Кент и Гергелий попробуют не уклоняться от ответа на этот вопрос и дать требовательным руководителям и финансовым директорам то, что они хотят.
Будут рассмотрены следующие темы:
- Концептуальная модель цикла создания программного обеспечения
- Откуда берется потребность в измерении производительности?
- Как удается так точно измерять производительность в отделах продаж и при подборе персонала?
- Компромиссы в измерении производительности в сфере создания программного обеспечения
- Опасность измерения только результатов и влияния.
- Командная и индивидуальная производительность
- Почему создание программного обеспечения стоит так дорого?
- Как решить, сколько нужно инвестировать в разработку?
- Как измерить разработчиков?
Для кого эта статья?
Эта статья написана для разработчиков программного обеспечения и их руководителей, а также для всех, кто заботится о воспитании высокоэффективных команд разработчиков программного обеспечения. Под “высокоэффективными” в данной статье понимаются команды, в которых разработчики удовлетворяют потребности своих заказчиков, с удовольствием приходят на работу и не чувствуют, что их постоянно измеряют по бессмысленным метрикам, которые работают против создания программного обеспечения, решающего проблемы заказчиков. Цель этой публикации – помочь практическим руководителям внести предложения по измерению, не причиняя вреда, и помочь разработчикам программного обеспечения стать более продуктивными.
Читая статьи, подобные упомянутой консалтинговой статье выше, помните, что они написаны для совершенно другой и специфической аудитории: нетехнических руководителей компаний и финансовых директоров, имеющих практически нулевой опыт разработки ПО. Для них отдел разработки – это просто другой отдел. Они относятся к созданию ПО так же, как к продажам или подбору персонала, и будут относиться, невзирая на ущерб, который наносят культуре разработки неверно выбранные фреймворки.
1. Концептуальная модель цикла создания программного обеспечения
Прежде чем перейти к нашему решению, давайте определимся с контекстом. Как программная инженерия создает ценность? Возьмем типичный пример: создание функции, ее запуск для заказчиков и последующая итерация. Как выглядит этот цикл? Допустим, мы говорим о достаточно автономной и наделенной полномочиями команде разработчиков программного обеспечения, работающей в стартапе, которая находится в постоянном контакте с заказчиками:
Мы начинаем с того, что решаем, что делать дальше, а затем делаем это. Это такие усилия (effort), как планирование, кодирование и т.д. В результате этих усилий мы получаем осязаемые вещи: саму функцию, код, проектную документацию и т.д. Это и есть выход (output). В результате заказчики будут вести себя по-другому, что и является нашим результатом (outcome). Например, благодаря этой функции они могут реже застревать при входе в систему. В результате такого изменения поведения мы увидим, как к нам возвращаются такие ценности, как отзывы, доход, рекомендации. Это и есть влияние (impact).
Итак, давайте обновим нашу концептуальную модель с помощью этих терминов:
Модель “Усилие/Выход/Результат/Влияние” описывает программную инженерию и одинаково хорошо подходит как для небольших задач, так и для моделирования разработки функций или отправки сложных проектов.
Все дальнейшие размышления и выводы будут ссылаться именно на эту модель.
Продолжение следует…