Наверх ▲

Сбалансированная система показателей в Agile: KPI с человеческим лицом

Борис Вольфсон Борис Вольфсон Борис Вольфсон занимается веб-разработкой и разработкой программного обеспечения с 2003 года. Карьеру начал в качестве программиста компании «Систем-Софт» в Оренбурге. С 2008 года – руководитель проектов и руководитель регионального отдела разработки в компании Softline.

Борис Вольфсон: Добрый день, меня зовут Борис Вольфсон. Сегодня я хочу поговорить с вами об очень интересной и "скользкой" теме: KPI в Agile. Как можно использовать KPI? Также я приведу несколько "антипаттернов" - примеров того, как KPI не стоит использовать.

Очень кратко о себе

Начинал я, как и многие, программистом. Руководил отделом разработки, а впоследствии и департаментом разработки в компании "SoftLine". Сейчас я начинаю работать техническим директором в компании "HeadHunter". Кроме того, мое хобби - выступать на конференциях, делиться опытом и периодически проводить тренинги, как правило, связанные с управлением проектами.

У меня есть Twitter. Если кто-то не успеет задать вопросы во время доклада, можно писать в Twitter. Я с удовольствием отвечу.

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

Это антипаттерн, естественно. Сейчас я более подробно расскажу, как стоит и как не стоит делать. Я также сообщал, что буду рассказывать с учетом того, что мы используем гибкие методологии.

У нас была такая шутка: что обсуждали на конференциях по управлению проектами раньше, когда не было Agile?

У нас сейчас везде применяются Agile, Scrum, Kanban. Собираюсь немного вас взбодрить.

Кто использует гибкие методологии в своей разработке?

Кто планирует использовать?

Кто в первый раз слышит про Scrum, Kanban?

Всего один человек! Мы тебя запомнили.

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

Впервые над измерениями для менеджмента и их популяризацией задумался американский ученый австрийского происхождения – Питер Друкер (Peter Drucker). Именно он впервые предложил научный подход к такого рода измерениям в середине прошлого века. Вот его фотография.

Он разработал концепцию MBO (управление по целям), но она была достаточно несовершенна. Ее часто критиковали – она была однобокой.

Я сейчас приведу пример того, как эта однобокость может выйти нам боком.

Почему измерения важны?

Еще я хотел бы объяснить, почему менеджеры, управленцы, руководители очень любят измерять. Дело в том, что в классическом понимании у менеджмента всего 4 функции. Две из них – контроль и планирование – очень тесно связаны с измерениями. 

Даже есть такое выражение: то, что мы не можем измерять, мы не можем контролировать. Соответственно, менеджеры обожают проводить какие-то измерения, при этом не всегда понимая, насколько это полезно, выгодно, и к чему такие измерения могут привести.

Классический пример.

Кто-то не слышал о компании "Xerox" – есть такие? Нет.

Компании уже больше 100 лет. Я хочу рассмотреть эпоху ее расцвета. В 1970-е годы бренд "Xerox" был синонимом копировальных аппаратов. Другие компании не выпускали такого оборудования, и фирма "Xerox" царила на рынке – она сдавала аппараты в аренду, в лизинг.

Какая при этом была цель у менеджмента компании? Заработать побольше. Фактически у компании была монополия. Клиенты оставались очень недовольны качеством: аппараты постоянно ломались, цены тоже были достаточно высокими. Но деньги текли рекой.

Как только появились американские и японские конкуренты, эта монополия практически полностью разрушилась. Компания "Xerox" была на грани банкротства, потому что она забыла обо всем, кроме денег.

Руководители компании "Xerox" в 1970-х годах очень хотели денег, а потом оказалось, что надо немного думать еще и о клиентах.    

Соответственно, возникает закономерный вопрос о балансе. Если мы хотим контролировать компанию, подразделение или даже отдельные команды с помощью цифр, надо найти определенный баланс, чтобы мы развивались гармонично.

Развитие нужно обеспечить не только в финансовой перспективе, в финансовой сфере. Это будет, образно говоря, человек с перекачанными бицепсами, а остальные мускулы у него не развиты.

Решение предложили два ученых: Роберт Каплан (Robert Kaplan) и Дэвид Нортон (David Norton). Это не тот человек, который изобрел "Norton Commander", сразу предупреждаю!

В 1992-м году (в принципе, свежее исследование) они опубликовали в "Harvard Business Review" свою статью. Они предложили решение под названием "сбалансированная система показателей".

После этого они написали несколько статей и две книги. В конце я дам ссылки на русский перевод и названия. Если кто-то заинтересуется, можно будет подробнее почитать.

Они предложили следующую схему. Нужно разделить все показатели на 4 части:

  • на финансовую часть;
  • на внутренние процессы;
  • на обучение и развитие сотрудников и компании как обучающей организации;
  • на показатели по клиентам (очень важная сфера).

Эти сферы между собой взаимосвязаны. Идея сбалансированной системы показателей: если вы научитесь хорошо измерять эти 4 сферы, вы сможете грамотно и всесторонне развивать вашу компанию или ваше подразделение и укреплять свои лидерские позиции. Все это опирается на видение и стратегию развития вашей компании или подразделения.  

Первая отрасль – финансы

Какие показатели в финансовой сфере можно измерить для компании или подразделения? Может, кто-то делает это?

Верно: возврат инвестиций, выручку на клиента, EBIT (очень интересный), средний чек.

Я не буду подробно останавливаться на этих показателях. Обычно существует две категории таких показателей.

  • Показатели, связанные с прибылью, которые надо увеличивать.
  • Показатели, которые связаны с издержками, – их, соответственно, надо уменьшать.

Может быть, кто-то интересовался теорей ограничений Элияху Голдратта (Eliyahu M. Goldratt)? Голдратт утверждал, что достаточно трех показателей, чтобы измерять эффективность работы компании. Все они выражаются именно через финансы.

Второй аспект – внутренние процессы

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

Реплика из зала: Количество ошибок на итерацию.

Борис Вольфсон: Количество ошибок на итерацию. Ок.

Реплика из зала: Количество разных WTF в минуту.

Борис Вольфсон: "What's the fuck" в минуту. Давайте я сейчас некоторые варианты подскажу.

Две главных категории показателей, которые стоит измерять

Во-первых, изменять нужно качество. Можно придумать какие-то свои метрики. Самый хороший показатель – это количество критических дефектов в продакшне. Если мы говорим о разработке веб-сайтов, то это количество критических дефектов на "боевых" серверах.

Я встречал разные метрики, которые были более-менее полезными.

Количество дефектов на итерацию – интересный вариант.

Количество открытых дефектов на одного разработчика. Если у вас это количество начинает расти, разработчики начинают относиться к своему продукту как к не очень качественному, благодаря "эффекту разбитых окон".

Во-вторых, стоит обратить внимание на сроки.

Если вы используете Scrum, есть очень неплохая метрика: процент несделанных историй пользователей (элементов бэклога) или процент несделанных "story points" за спринт. Он позволяет оценить, сколько у вас команда не успевает, и связан с точностью планирования.

Если вы используете Kanban или Scrumban, и у вас нет жестких итераций, очень неплохо измерять время жизни задачи или параметр "lead time" и постепенно его уменьшать. Чем этот показатель меньше, тем эффективнее работает ваша система.

Приведу еще один очень интересный пример. На одной из конференций докладчик рассказывал про конфликты. Спросил у аудитории, какие бывают конфликты. Умные люди перечислили: производственные, личностные конфликты. Один мальчик с задних рядов вдруг сказал: "Вы знаете, у нас в команде постоянно возникают расовые конфликты". Над ним все посмеялись. Он пояснил: "Я не шучу! Я серьезно. Дело в том, что мы работаем с индусами, и мы их ненавидим!"

К чему я это рассказываю? Есть такое понятие – индусский код. Как оно возникло?

Хитрые менеджеры решили считать, сколько строк кода напишет разработчик. Чем их больше, тем лучше он поработал, тем больше ему надо за это платить – давать премии, бонусы и так далее. Это типичный антипаттерн.

Следующий аспект – это развитие обучения

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

Как узнать, насколько наши сотрудники хороши, довольны и развиваются? Есть у вас какие-то идеи по метрикам?

Реплика из зала: Сложные задачи.

Борис Вольфсон: Как численно измерить сложность задачи? Субъективная оценка. Еще варианты?

Реплика из зала: Сколько времени человек на работе проводит.

Борис Вольфсон: Если 8 часов, то плохо, если 12, то хорошо. 

Реплика из зала: По звездной карте вести статистику.

Борис Вольфсон: По звездной карте вести статистику? После доклада мне расскажешь, что это такое.

Реплика из зала: Число сценариев, число историй.

Борис Вольфсон: Число сделанных историй… А это не относится вот к этому паттерну? Ладно, давайте я свои варианты дам.

Очень простой способ проверить удовлетворенность сотрудников компанией –  посмотреть на текучесть кадров и сравнить ее с аналогичным показателем ваших конкурентов, крупных компаний вроде Google и Facebook.

Второй способ проверить удовлетворенность сотрудников тоже достаточно прост. Удовлетворенность очень просто измерить: нужно раз в квартал или раз в полгода проводить опрос по нескольким категориям. Так вы посмотрите, насколько ваши сотрудники удовлетворены различными аспектами работы в вашей компании.

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

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

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

Я сейчас говорил про внешние мероприятия. Это же касается и внутренних мероприятий. Сейчас многие компании проводят собственные внутренние семинары и вебинары и даже полноценные конференции.

О клиентах

Теперь поговорим о клиентах. Самая сложная и интересная часть. У кого-нибудь были разъяренные клиенты, заказчики? У кого не было таких клиентов? Так, один человек. Вы не пишете программы и не работаете в вебе, получается.

В самом начале доклада я рассмотрел пример с компанией "Xerox", которая о своих клиентах не особо заботилась. В итоге все клиенты разбежались.

Как можно понять, что клиенты нами удовлетворены? Как это можно численно измерить? Форумы читать? Давайте какие-то вебовские метрики приведем. Обратная связь…

Реплика из зала: Число негативных отзывов.

Реплика из зала: Конверсия.

Борис Вольфсон: Конверсия – это немного не то. Количество повторных возвратов на сайт, например, лояльность заказчиков и внешних пользователей… Если мы говорим про веб-магазины, внешними пользователями являются покупатели.

Классические способы измерения удовлетворенности клиентов

Доля рынка. Чем больше у вас доля рынка, тем больше удовлетворены вами клиенты. Что это означает? Практически по всем существующим отраслям в Интернете и в сфере разработки ПО проводятся исследования. Можете открыть журнал "CNews" и посмотреть, какую долю рынка вы занимаете. Растет ли эта доля рынка? Растет ли сам рынок? Как вы растете по отношению к рынку?

Второй пункт: клиентская база. Количество клиентов у вас должно, соответственно, увеличиваться. Мы говорили про средний чек, когда мы обсуждали финансы. У нас должны быть клиенты, которые к нам обращаются повторно (а в идеале и постоянно). Мы можем фиксировать, например, рекомендации, то есть случаи, когда клиент приводит нового клиента.

Про обратную связь тоже стоит рассказать. Очень важно измерять удовлетворенность клиентов: насколько хорошо мы как компания удовлетворяем их потребности. Обычно с помощью опросов измеряются три основные компоненты: 

  • насколько клиента удовлетворяет цена;
  • успеваем ли мы сделать в срок то, что хотим (особенно это важно, если мы используем гибкие методологии с "твердыми" сроками и изменяющимся объемом работ);
  • насколько клиента удовлетворяет качество.

При опросах обычно используется 10-балльная шкала оценки. Я проводил такие опросы раз в квартал и считал среднее число.

К сожалению, я только какие-то основные вещи успею рассказать в рамках этого доклада.

Надеюсь, все знают, что это за игра. Есть, кто не играет? Никто не знает. Это "StarCraft II": стратегия в реальном времени.

Стратегия и система сбалансированных показателей очень сильно связаны. Дело в том, что есть разные показатели (их много). Сейчас мы назвали около 30, наверное.

Что вы хотите сделать за этот год в плане стратегии: вырасти, закрепиться на рынке, удержать позиции? Соответственно, выбираются нужные показатели. Выбираются те значения, которых мы хотим достичь. Я скажу, где об этом можно подробнее почитать.

Количество показателей тоже очень важно. У нас есть 4 сферы – по 4-5 показателей на каждую будет более чем достаточно. Если у вас количество показателей как в кабине самолета или шаттла, вы можете просто запутаться. Не надо их слишком много всего придумывать.

Работа с мотивацией на основе показателей 

У менеджеров всегда возникает желание наказать, депремировать кого-то из сотрудников на основе числовых показателей. Или, наоборот, образно говоря, предложить "две морковки вместо одной" – дать премию, повысить.

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

Не используйте относительные единицы изменения!

Очень важный момент. Если вы используете Scrum или Kanban, но оцениваете ваши задачи в story points, их ни в коем случае нельзя использовать для каких-то оценок производительности.

Если у вас команда сделала 30 story points и вы говорите, что через 2 месяца надо за спринт делать 40, они это очень легко реализуют. Поскольку story point – относительная единица, сотрудники могут просто уменьшить его размер и подогнать число story points под нужное количество. Это называется "инфляцией story points".

Есть более хитрые примеры. У меня в практике было, когда для крупных инвесторов нужна была финансовая оценка проекта. У нас команда уже сделала несколько спринтов. Мы определили скорость. Соответствующим образом делался бизнес-план. У нас Product Owner считал, сколько стоит в долларах 1 story point.

Можно использовать такую метрику, но если вы ее используете для KPI, надо понимать, что размер story points со временем (особенно в долгосрочной перспективе) может изменяться.

Наказания и скорость работы

Про это я проговорил. У нас есть одна сторона – наказание. Подогнать, сделать так, чтобы команда работала быстрее. Очень сомнительная идея – я общался со многими руководителями, тренерами, консультантами. Практически все в один голос говорят, что с помощью KPI-измерений не получится разогнать скорость работы вашей команды.

Если у вас команда действительно мотивированная, она это сможет сделать сама с помощью ретроспектив. KPI, наверное, для этого не подходит. По крайней мере, я такого способа не знаю.

Где, на каком уровне применять систему сбалансированных показателей?      

Я в основном рассказывал про 2 нижних уровня – они мне ближе, у меня там много опыта. Но систему сбалансированных показателей можно применять на уровне компании в целом, особенно когда речь идет о финансах.

Какие компании применяют эту систему? Очень много таких компаний среди крупных корпораций. Согласно последнему или предпоследнему исследованию, до 50 % компаний, которые входят в Fortune 500, используют ССП.

Если говорить про уровни, надо сказать, что очень легко, по-моему, применить эту систему на уровне подразделения. Оно может у вас называться "отделом" или как угодно. Суть в том, что несколько команд объединены в некоторый отдел, подразделение или филиал. На уровне команды (это касается производительности в том числе) многие компании, в принципе, измеряют показатели инструментами Scrum.

Что надо сделать, что успешно внедрить ССП? 

Договориться с руководством. Объяснить, какие плюсы это даст руководству. Практически никакие изменения в компаниях без поддержки менеджмента, а еще лучше – высшего менеджмента, "партизанскими методами" проводить не стоит.

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

Что стоит почитать на эту тему?  

Есть две книги из разряда "must read".

Первая книга называется "Сбалансированная система показателей. От стратегии к действию". Это классическая работа. Она написана очень легко. Там много примеров, в том числе, по IT-компаниям типа "AMD", "Analog Devices" и так далее.

Вторая книга озаглавлена "Организация, ориентированная на стратегию". Там про то, что я пытался на одном слайде показать – как от стратегии, от целей, которые вы ставите, перейти к системе сбалансированных показателей.

Есть книжки, которые к разряду "must read" не относятся, но если вас, вашего руководителя, сотрудников и коллег заинтересует эта тема, я рекомендую еще вот эти три книжки посмотреть.

Спасибо!

Вопросы? Давайте.

Вопросы и ответы

Реплика из зала: Борис, спасибо за доклад. Меня зовут Илья. Вопрос такой... В теории все хорошо. Хочется практических примеров – что измерял, какие выводы сделал, какие последствия были?

Борис Вольфсон: Спасибо. 80 % из того, что я проговорил, применялось на практике в предыдущей компании, где я работал. Остался последний шаг к завершению. Мы снизу начали: выбрали показатели, которые хотим измерять. Фактически мы внедрили это на уровне подразделения. Осталось наш департамент (там более 100 человек работает) "под шапочку" ССП положить. Это, в принципе, не теоретические рассуждения, а именно из практики взято.

Реплика из зала: Сколько это по времени занимает?

Борис Вольфсон: В больших компаниях процесс перехода на такую систему может занять несколько лет. Если у вас IT-компания размером в 50–100 человек, по-моему, за полгода перейти на ССП вполне реально. У нас на это ушло где-то 5 месяцев, но мы весь процесс до конца не завершили.

Реплика из зала: Очень часто пишут, что KPI имеет смысл внедрять только для первых двух топ-уровней компании, а для более низких этого делать ни в коем случае нельзя. Можете это прокомментировать?

Борис Вольфсон: Да, могу это прокомментировать. У меня была такая картинка. Может быть, я это не совсем четко проговорил. Я как раз и сказал, что на уровне команды у вас KPI (особенно в виде ССП, как я описал), скорее всего, эффективно работать не будет.

Надо просто использовать инструменты для измерения, которые предоставляет Scrum. А вот на уровне подразделений и компании можно как раз эффективно применять KPI. С этим я на 100 % согласен.

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

Борис Вольфсон: Так и хочется ответить: ты живешь в России! Об этом подробно во второй книжке описано. Я сейчас описал инструмент для мониторинга. Дело в том, что к каждому показателю обычно "прикреплен" набор конкретных действий и мероприятий, которые следует делать для достижения нужных показателей.

Если у вас эти мероприятия запланированы и сделаны, но показатель не меняется, надо пробовать на следующий квартал или следующие полгода применять другие мероприятия. Либо, если вы считаете, что камень с места не сдвинется, как-то менять стратегию и подумать, как этот камень можно обойти. У вас соответствующим образом изменится набор показателей.

Реплика из зала: Понятно. Это делается из итерации в итерацию, но остается иногда на месте.

Борис Вольфсон: Да, но итерации лучше брать побольше – квартал или полгода.

Реплика из зала: Субъективные, как говорили раньше, ощущения заказчика не являются показателем? Дело вот в чем: раз существует "инфляция story points", точно так же может существовать и инфляция любого показателя. Те же менеджеры и разработчики могут любые показатели демонстрировать, но заказчик будет недоволен. Стоит ли овчинка выделки, и когда стоит?

Борис Вольфсон: Да, стоит. Там тоже есть различные моменты. Опросы заказчиков я проводил где-то полтора года. Там были разного рода искажения, но если случались реальные "косяки", это в оценках обязательно проскакивало.

Допустим, у вас есть три показателя по удовлетворенности клиента (сроки, цена, качество). Можно посмотреть, какой из этих показателей больше всего "хромает". К примеру, в течение квартала ваш сайт несколько раз был недоступен по несколько часов. У вас тут же 100 % просядет качество.

На этот показатель в следующем квартале выделить какие-то мероприятия по улучшению, провести code review, посмотреть, в каких модулях были проблемы (может, "железо" в серверах сдало). Соответственно, этот показатель "подтянуть".     

Реплика из зала: Ясно. Спасибо.

Реплика из зала: Добрый день, меня зовут Кирилл. У меня вопрос в продолжение к первому. Борис, не могли бы вы сказать об успешном применении системы? Вы что-то измерили, потом сказали: "Ага, я должен такие изменения произвести", - и какую-то системную проблему решили. Не разовую, понятное дело – не ошибку.

Борис Вольфсон: Давайте я по опросам продолжу. Мне удалось две проблемы решить. По одному из опросов выявилось, что есть проблемы со сроками. При этом формально сроки соблюдались, но все равно исполнение вызывало неудовольствие у заказчика.

Мы с несколькими заказчиками проговорили. Оказалось, что работа команд для них недостаточно прозрачна. Они по разным причинам не совсем понимали, что именно делает команда в течение соответствующего спринта.

Мы четче регламентировали, кому отсылать, какие работы у нас взяты в спринт, кого звать на демонстрацию. По одному из проектов эту проблему удалось решить. Точнее, мы поняли, что у нас есть проблемы с качеством. На этом проекте были дефекты, которые с точки зрения разработки не являлись критичными – надо было какой-то текст поправить.

С точки зрения заказчика они являлись важными, потому что у него из-за этого уходили клиенты.

Реплика из зала: Вы сказали, что заказчиков тоже опрашивали. Нет ли у вас положительного опыта применения такой метрики, как "Net Promoter Score"?

Борис Вольфсон: Что это такое?

Реплика из зала: Метрика. Вы опрашиваете своих клиентов и узнаете, будут ли они ваш продукт рекомендовать друзьям и соседям.

Борис Вольфсон: Понял. Нет, такое не использовали. У нас целый набор вопросов был. Если интересно, могу попозже его показать. Причем у нас там есть заказчики удаленные – мы использовали сервис webanketa.com (есть такой инструмент для опросов).

Реплика из зала: Спасибо большое за доклад. Мой вопрос носит практический характер. Что вы на практике используете для визуализации панели мониторинга, чтобы красиво довести достижения KPI?

Борис Вольфсон: "Excel" и "Visio".    

Реплика из зала: И все?

Борис Вольфсон: Да.

Реплика из зала: Автоматизацию какую-то используете?

Борис Вольфсон: Автоматизация очень простая. "Visio" позволяет красиво подгружать цифры из "Excel".

Реплика из зала: В "Excel" они попадают вручную?

Борис Вольфсон: Да, вручную от соответствующих подразделений.  

Реплика из зала: Я понял. Спасибо.

Борис Вольфсон: Я могу добавить. Есть специализированное ПО, но мы не использовали его. Оно обычно используется в каких-то больших компаниях.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Андрей Сумин

Андрей Сумин

Руководитель Frontend, Mail.ru.

Андрей Сумин (Mail.Ru) говорит, когда необходимо использовать v8 на сервере, и о собственном шаблонизаторе.

Евгения Фирсова

Евгения Фирсова

Руководитель отдела веб-интерфейсов, Яндекс.Деньги.

Я хочу рассказать или, если угодно, определиться и пожаловаться вслух (мне приятно жаловаться вслух) о том, как работать, когда работать некому.

Алексей Романенко

Алексей Романенко

Ведущий разработчик в Mail.Ru Group.

Алексей Романенко (РБК) демонстрирует полезность компиляции скриптов PHP для выполнения отдельных задач.