Метрики,
эффективность
и здравый смысл
эффективность
и здравый смысл
как не угробить систему, пытаясь её улучшить
Наверняка вы уже сталкивались с такой ситуацией. Вы из кожи вон лезли: выложились на 200%, упахались, выгорели, потушили все пожары, подняли мотивацию подгоревших сотрудников, победили сопротивление упрямого руководства, достигли этих чёртовых вечно растущих KPI. Сделали всё, что могли. Но в итоге — удовлетворения нет.
Компания в каком состоянии была, в таком и осталась. Клиентов больше не стало, денег — тоже. Заказчики как бухтели, так и продолжают. Вроде бы старались. Вроде бы была эффективность. А вроде и не было.
Я верю, что неверное понимание того, что такое «эффективность», часто усложняет жизнь и мешает нам получать удовольствие от работы. Я не буду пытаться навязать вам свою картину мира, но хочу предложить другую перспективу. Возможно, вместе мы что‑то новое поймём.
Меня зовут Александра Брызгалова. Я практик и сертифицированный эксперт по Теории ограничений (Голдратт) и бизнес‑консультант.
Компания в каком состоянии была, в таком и осталась. Клиентов больше не стало, денег — тоже. Заказчики как бухтели, так и продолжают. Вроде бы старались. Вроде бы была эффективность. А вроде и не было.
Я верю, что неверное понимание того, что такое «эффективность», часто усложняет жизнь и мешает нам получать удовольствие от работы. Я не буду пытаться навязать вам свою картину мира, но хочу предложить другую перспективу. Возможно, вместе мы что‑то новое поймём.
Меня зовут Александра Брызгалова. Я практик и сертифицированный эксперт по Теории ограничений (Голдратт) и бизнес‑консультант.
Здесь не будет простой инструкции, точнее — простая инструкция будет, но исполнить её не всегда просто, а иногда почти невозможно. Но если вы правда хотите не просто занятости, а смысла — у вас нет выбора.:)
Ниже приведён текст моего доклада на одной ламповой IT‑конференции. Письменный вариант появился благодаря поддержке «Клуба главредов» в лице Данилы Терентьева, Community и Product Lead сообщества.
Метрики: любовь и ненависть
Уравнения голосованиями
не решаются
не решаются
Прежде чем я расскажу вам о том, как я понимаю «эффективность», у меня к вам вопрос: Как вы считаете, метрики эффективности — это крайне важный и необходимый инструмент? Их обязательно нужно считать, повышать и, в общем, стремиться к тому, чтобы они становились всё лучше и лучше? Или вы уже устали от этих зануд и ненавидите метрики, потому что: «сколько можно, они всё равно ничего не показывают! Всё слишком сложно и постоянно меняется»?
Можно было бы здесь разместить ссылку на опрос, но, к сожалению, уравнения голосованиями не решаются. Я лично метрики и люблю, и ненавижу — потому что, как обычно, всё зависит от цели. Давайте расскажу, что я имею в виду.
Можно было бы здесь разместить ссылку на опрос, но, к сожалению, уравнения голосованиями не решаются. Я лично метрики и люблю, и ненавижу — потому что, как обычно, всё зависит от цели. Давайте расскажу, что я имею в виду.
Когда все по отдельности молодцы, но вместе — провал
Жила‑была одна компания, которая верила в метрики. Она была очень заряжена, замотивирована, регулярно ходила на классные конференции, находила на них способы улучшений и внедряла новые идеи и фреймворки.
И вот у компании случился особенно удачный месяц. И если смотреть на метрики, мы видим:
Вроде бы все молодцы, и вроде бы удачный месяц. Но если посмотреть чуть издалека — и особенно спустя какое‑то время — выясняется:
И вот у компании случился особенно удачный месяц. И если смотреть на метрики, мы видим:
- Аналитик закрыл все требования по роадмапу — и не только на ближайшее время, а вообще на полгода вперёд.
- Разработчик узнал что‑то новое и выдал за спринт в два раза больше фич, чем обычно.
- Тимлид прокачал софт‑скилы: все в команде загружены, мотивированы и продуктивны.
- Продакт включил в релиз всё, что так давно откладывали, и то, за что его так мучили заказчики, собственники и руководство.
- QA максимально снизил количество багов до релиза.
- Маркетолог запустил три мощные кампании, которые привлекли кучу лидов.
- Саппорт ответил на 100 тикетов.
Вроде бы все молодцы, и вроде бы удачный месяц. Но если посмотреть чуть издалека — и особенно спустя какое‑то время — выясняется:
- То, что написал аналитик, так и не дошло до реализации: требования устарели. Пока аналитик писал их на полгода вперёд, он меньше общался с разработкой — и в результате команда сделала не то. Всё придётся переделывать, все злятся.
- Разработчик вроде бы молодец — фич в два раза больше, — но тестирование не было к этому готово. Фичи повисли в стейдже, ускорение превратилось в торможение.
- Команда старалась на 200%, но поскольку всё увязло — все ходят злые и печальные.
- Продакт включил в релиз всё, что просили, но команда распылилась, устала, а пользователи разницы не заметили. Более того, оказалось, что хотели они вовсе не этого.
- QA настолько ужесточил проверки, что продакты и разработчики стали бояться к нему идти: проверка гипотез теперь требует слишком много времени и ритуалов. В итоге гипотезы не проверяются, продукт не развивается.
- Маркетолог привёл столько лидов, что отдел продаж не справился даже с обычным объёмом. Продажи упали, выручка не получена, репутация пострадала.
- Саппорт был настолько занят ответами на тикеты, что не успел эскалировать серьёзную проблему. Она так и осталась не решённой, и клиенты в бешенстве продолжают строчить однотипные тикеты.
Улучшения
не суммируются
не суммируются
А почему тогда нам кажется, что каждый должен быть эффективным? Потому что мы верим, что улучшения суммируются — и если каждый будет эффективным, то система тоже будет эффективной.
Приведу максимально банальный пример. У нас есть цепь, состоящая из 10 звеньев. Мы решаем, что её надо бы улучшить. Улучшения, как мы верим, суммируются, поэтому мы берём и каждое звено усиливаем, повышая прочность на 10%. Насколько тогда возрастёт прочность всей цепи? На 10% — но уж точно не на 100%. Хотя если бы улучшения действительно суммировались, и мы усилили бы 10 звеньев на 10% каждое, прочность должна была бы удвоиться. Но улучшения не суммируются!
Приведу максимально банальный пример. У нас есть цепь, состоящая из 10 звеньев. Мы решаем, что её надо бы улучшить. Улучшения, как мы верим, суммируются, поэтому мы берём и каждое звено усиливаем, повышая прочность на 10%. Насколько тогда возрастёт прочность всей цепи? На 10% — но уж точно не на 100%. Хотя если бы улучшения действительно суммировались, и мы усилили бы 10 звеньев на 10% каждое, прочность должна была бы удвоиться. Но улучшения не суммируются!
Более того, если мы начнём рвать нашу цепь, она порвётся всего в одном месте — в самом слабом звене. И если мы усилим 9 звеньев на 20%, но не попадём в самое слабое звено, прочность всей цепи не изменится вообще. А если наоборот — усилим только слабое звено на 10%, — прочность цепи реально увеличится. Причём ровно так же, как если бы мы усиленно прокачивали каждое звено.
Пример вроде бы супер простой и явно показывает: локальные улучшения не суммируются. Но судя по нашему поведению, мы свято верим в локальную оптимизацию. И в это время локальные метрики эффективности толкают нас не к результату, а к занятости (на самом деле всё ещё хуже, но об этом позже).
Пример вроде бы супер простой и явно показывает: локальные улучшения не суммируются. Но судя по нашему поведению, мы свято верим в локальную оптимизацию. И в это время локальные метрики эффективности толкают нас не к результату, а к занятости (на самом деле всё ещё хуже, но об этом позже).
Нас пугает
сложность
сложность
Почему же мы так упорно гонимся за локальными оптимумами? Потому что нам сложно смотреть на картину целиком. Мы не умеем управлять большой системой. Поэтому делим её на кусочки — и надеемся, что это сработает. И во многом это действительно работает. Но не в случае с эффективностью
Людям важно, чтобы их работа имела смысл
Когда я рассказываю историю про эффективность топ‑менеджменту, они очень часто говорят: «Это всё классно и интересно, конечно, на нашем уровне. Мы‑то понимаем, что у системы есть цель — и её надо достигать. Но если опуститься на уровень рядовых разработчиков, тимлидов и тестировщиков, то они о таком не задумываются. Вот они достигли своего KPI — и им больше ничего не надо».
Но я точно верю, что вы — не такие. Хотя бы потому, что одна из самых популярных жалоб линейных сотрудников, которую я слышу: «Крайне обидно и досадно, что бóльшая часть работы оказывается в столе». А это уже намекает: вы работаете не только за зарплату.
Но я точно верю, что вы — не такие. Хотя бы потому, что одна из самых популярных жалоб линейных сотрудников, которую я слышу: «Крайне обидно и досадно, что бóльшая часть работы оказывается в столе». А это уже намекает: вы работаете не только за зарплату.
Да, иногда мы действительно работаем просто за деньги. Просто чтобы хватило на кусок хлеба. Но в айтишке, зачастую, и на кусок масла уже хватает. И тогда начинают включаться более сложные запросы.
Нам хочется самореализации. Хочется понимать, что наш труд не впустую. Но как получить самореализацию, если ты всё сделал, а чтобы появился результат — нужно, чтобы все вокруг начали делать нормально? Кажется, что ты на это не можешь повлиять.
Но вообще‑то — можешь.
Ты не можешь управлять всем, но можешь влиять на эффективность
Даже если ты не можешь изменить работу других, ты можешь сделать свою работу эффективнее — с точки зрения системы, а не локальной оптимизации. А чтобы это получилось, сначала нужно разобраться, что вообще такое «эффективно».
Кстати, начинать с себя — эффективнее всего:)
Нам хочется самореализации. Хочется понимать, что наш труд не впустую. Но как получить самореализацию, если ты всё сделал, а чтобы появился результат — нужно, чтобы все вокруг начали делать нормально? Кажется, что ты на это не можешь повлиять.
Но вообще‑то — можешь.
Ты не можешь управлять всем, но можешь влиять на эффективность
Даже если ты не можешь изменить работу других, ты можешь сделать свою работу эффективнее — с точки зрения системы, а не локальной оптимизации. А чтобы это получилось, сначала нужно разобраться, что вообще такое «эффективно».
Кстати, начинать с себя — эффективнее всего:)
Эффективность ≠ продуктивность
Здесь я не буду устраивать голосование — я и так знаю, что самое распространённое определение эффективности звучит как «быстрее, выше, сильнее». Но чаще всего это про продуктивность.
Я просто дам определение Теории ограничений. Эффективность — это приближаться к цели. И всё! Продуктивность в этом смысле — вторична.
Она может быть низкой, но если мы приближаемся к цели — мы эффективны. Мы могли сделать крошечное изменение, которое решило кучу проблем. Могли потратить на это совсем немного времени.
Я просто дам определение Теории ограничений. Эффективность — это приближаться к цели. И всё! Продуктивность в этом смысле — вторична.
Она может быть низкой, но если мы приближаемся к цели — мы эффективны. Мы могли сделать крошечное изменение, которое решило кучу проблем. Могли потратить на это совсем немного времени.
Чтобы быть эффективным, нужно знать цель
Если мы говорим о том, что хотим заниматься эффективностью, а эффективность — это приближаться к цели, то, в первую очередь, мы должны определиться с этой целью.
И здесь у меня для вас сразу две новости: хорошая и плохая.
Хорошая новость: на вопрос «в чём цель?» есть простой ответ. Для коммерческой организации цель — зарабатывание денег. Плохая новость: этот ответ почти не помогает.
Тем не менее важно чётко зафиксировать у себя в голове: нашей целью не является обогнать конкурентов, совершить технологическую революцию на рынке или решить все боли всех наших клиентов. Наша цель — зарабатывать деньги. Всё остальное — средства достижения этой цели.
На всякий случай проговорю отдельно: цель «деньги» не означает, что мы должны срочно становиться беспринципными, нечестными или безидейными. Мы можем — и должны — выбирать, как именно мы будем зарабатывать деньги. Но цель остаётся прежней: деньги.
Деньги — допустим. А что дальше?
Плохая новость в том, что одного этого ответа нам недостаточно. Окей, деньги. Но как мне понять, при чём здесь моя работа? Как я связана с деньгами, которые будут заплачены неизвестно когда и неизвестно кем?
И здесь мы делаем следующий шаг: после того как мы признали, что цель — зарабатывать деньги, нужно понять, через что именно наша компания эти деньги зарабатывает. И это критически важно для каждого, кто работает и хочет реально влиять на результат, который выдаёт компания.
Хорошая новость — вариантов не так уж много. Чаще всего клиенты в IT платят за проекты — если мы занимаемся аутсорсингом или аутстаффингом, либо за продукт — если у нас продуктовая компания.
И здесь у меня для вас сразу две новости: хорошая и плохая.
Хорошая новость: на вопрос «в чём цель?» есть простой ответ. Для коммерческой организации цель — зарабатывание денег. Плохая новость: этот ответ почти не помогает.
Тем не менее важно чётко зафиксировать у себя в голове: нашей целью не является обогнать конкурентов, совершить технологическую революцию на рынке или решить все боли всех наших клиентов. Наша цель — зарабатывать деньги. Всё остальное — средства достижения этой цели.
На всякий случай проговорю отдельно: цель «деньги» не означает, что мы должны срочно становиться беспринципными, нечестными или безидейными. Мы можем — и должны — выбирать, как именно мы будем зарабатывать деньги. Но цель остаётся прежней: деньги.
Деньги — допустим. А что дальше?
Плохая новость в том, что одного этого ответа нам недостаточно. Окей, деньги. Но как мне понять, при чём здесь моя работа? Как я связана с деньгами, которые будут заплачены неизвестно когда и неизвестно кем?
И здесь мы делаем следующий шаг: после того как мы признали, что цель — зарабатывать деньги, нужно понять, через что именно наша компания эти деньги зарабатывает. И это критически важно для каждого, кто работает и хочет реально влиять на результат, который выдаёт компания.
Хорошая новость — вариантов не так уж много. Чаще всего клиенты в IT платят за проекты — если мы занимаемся аутсорсингом или аутстаффингом, либо за продукт — если у нас продуктовая компания.
Без контекста «до и после» — не сработает
Представим абсурдный, но, думаю, реалистичный пример :)
Мы с вами сделали классное приложение: лучше, чем у конкурентов, все новейшие технологии задействованы, никаких багов, всё супер. Но отдел маркетинга почему-то привлёк клиентов, которые говорят на другом языке, чем интерфейс приложения.
Мы молодцы или нет? Вроде бы да. Но результата-то нет.
Если мы не знаем, что происходит до или после нас, у нас нет шансов сделать свою работу правильно и эффективно. Поэтому ещё раз:
Уже даже после этого вы можете сделать свою работу более эффективно — соотнеся её с целью и с тем, как ваша компания к этой цели движется.
Но да — это непросто.
Но если вы хотите, чтобы ваша работа имела больше смысла — у вас нет другого варианта. :)
Представим абсурдный, но, думаю, реалистичный пример :)
Мы с вами сделали классное приложение: лучше, чем у конкурентов, все новейшие технологии задействованы, никаких багов, всё супер. Но отдел маркетинга почему-то привлёк клиентов, которые говорят на другом языке, чем интерфейс приложения.
Мы молодцы или нет? Вроде бы да. Но результата-то нет.
Если мы не знаем, что происходит до или после нас, у нас нет шансов сделать свою работу правильно и эффективно. Поэтому ещё раз:
- Определили цель — зарабатывать деньги.
- Поняли, через что мы их зарабатываем.
- Узнали, что и как происходит до и после нас.
Уже даже после этого вы можете сделать свою работу более эффективно — соотнеся её с целью и с тем, как ваша компания к этой цели движется.
Но да — это непросто.
Но если вы хотите, чтобы ваша работа имела больше смысла — у вас нет другого варианта. :)
Предостережение
На этом этапе чаще всего звучит возражение: «Руководство само должно нам это всё разъяснить!» В идеальном мире — да. Но «идеально», если верить словарю, — антоним слова «реально». Реально!!))
Так что, может, руководство и должно, но на практике оно не просто не объясняет — оно часто само не знает/не понимает. И здесь не нужно становиться занозой или душнилой. Нужно постараться помочь.
Нам важно понимать, через что в нашей системе появляются единицы цели — деньги.
Только тогда мы сможем разобраться, что для нас действительно будет «эффективно», а что — просто занятость.
И кроме этого — мы обязательно должны понимать, что происходит до нас и после нас.
Потому что если мы не знаем, что происходит после, у нас не будет ни одного шанса сделать свою работу эффективно.
Можно продолжать просто пытаться делать свою работу правильно, но "правильно" — если честно не бывает.
На этом этапе чаще всего звучит возражение: «Руководство само должно нам это всё разъяснить!» В идеальном мире — да. Но «идеально», если верить словарю, — антоним слова «реально». Реально!!))
Так что, может, руководство и должно, но на практике оно не просто не объясняет — оно часто само не знает/не понимает. И здесь не нужно становиться занозой или душнилой. Нужно постараться помочь.
Нам важно понимать, через что в нашей системе появляются единицы цели — деньги.
Только тогда мы сможем разобраться, что для нас действительно будет «эффективно», а что — просто занятость.
И кроме этого — мы обязательно должны понимать, что происходит до нас и после нас.
Потому что если мы не знаем, что происходит после, у нас не будет ни одного шанса сделать свою работу эффективно.
Можно продолжать просто пытаться делать свою работу правильно, но "правильно" — если честно не бывает.
Как поток превращается в деньги — и почему не надо бояться ограничений
Ограничение всегда есть
и всегда будет
и всегда будет
Есть ещё один важный момент, о котором стоит подумать: любую систему можно представить в виде потока. У нас есть цель. Значит, наша система — это поток создания единиц цели, где на входе — клиенты, а на выходе — деньги. И абсолютно у любого потока, абсолютно у любой системы всегда есть ограничение. И — на всякий случай — это неплохо.
Тот, кто в системе является ограничением, — не плохой, не некомпетентный и уж точно не тот, кого нужно во всём обвинять. Ограничение — это естественная часть любой системы. Не бывает систем без ограничений. Но то, что это неплохо, не значит, что можно про это не думать. Мы должны знать, где находится наше ограничение, и учитывать это в своей деятельности.
Тот, кто в системе является ограничением, — не плохой, не некомпетентный и уж точно не тот, кого нужно во всём обвинять. Ограничение — это естественная часть любой системы. Не бывает систем без ограничений. Но то, что это неплохо, не значит, что можно про это не думать. Мы должны знать, где находится наше ограничение, и учитывать это в своей деятельности.
Давайте посмотрим на поток и разберёмся, что к чему. Если мы находимся перед сужением потока (то есть перед ограничением), и начинаем делать очень много работы, мы делаем системе хуже.
Почему? Потому что мы создаём перед ограничением гору незавершённой работы (WIP) и увеличиваем число переключений. Переключения — это когда мы начали делать одну задачу, не доделали, переключились на другую, потом на третью. И это зло. Потому что каждое переключение увеличивает трудоёмкость задачи. Причём не на 5−10%.
Если не контролировать незавершёнку, переключения могут увеличить трудоёмкость в 2−3 раза. (Нет, я не преувеличиваю.)
Допустим, вы — разработчик. Вы можете стабильно выпускать 6 фич в неделю. А тестировщик может проверять только 4 фичи в неделю. Вы начали с нуля. Сделали 6 фич. Тестировщик проверил 4, а 2 ушли в запас. На следующей неделе вы снова сделали 6 фич. Тестировщик проверил ещё 4 — и уже 4 фичи в запасе. Если так продолжать, то через какое-то время тестировщик сможет проверять не 4 фичи, а только 3. Почему?
Потому что перед ним уже лежит гора незавершённой работы. И он физически не может просто взять 4 штуки и спокойно их доделать. Он будет переключаться: тут кусочек проверил, там отвлёкся, здесь уточнил, а вот это надо переделать… В итоге время уходит на переключения, и четвёртая фича просто не успевает пройти.
Почему? Потому что мы создаём перед ограничением гору незавершённой работы (WIP) и увеличиваем число переключений. Переключения — это когда мы начали делать одну задачу, не доделали, переключились на другую, потом на третью. И это зло. Потому что каждое переключение увеличивает трудоёмкость задачи. Причём не на 5−10%.
Если не контролировать незавершёнку, переключения могут увеличить трудоёмкость в 2−3 раза. (Нет, я не преувеличиваю.)
Допустим, вы — разработчик. Вы можете стабильно выпускать 6 фич в неделю. А тестировщик может проверять только 4 фичи в неделю. Вы начали с нуля. Сделали 6 фич. Тестировщик проверил 4, а 2 ушли в запас. На следующей неделе вы снова сделали 6 фич. Тестировщик проверил ещё 4 — и уже 4 фичи в запасе. Если так продолжать, то через какое-то время тестировщик сможет проверять не 4 фичи, а только 3. Почему?
Потому что перед ним уже лежит гора незавершённой работы. И он физически не может просто взять 4 штуки и спокойно их доделать. Он будет переключаться: тут кусочек проверил, там отвлёкся, здесь уточнил, а вот это надо переделать… В итоге время уходит на переключения, и четвёртая фича просто не успевает пройти.
Переключения губят производительность
Если мы не учитываем, что после нас есть ограничение — у нас нет шансов. Мы вроде бы поднимаем собственную эффективность, но гробим результат всей системы.
А теперь представьте: вы делали 6 фич в неделю, потом сходили на какую-нибудь конференцию, вам там рассказали, как делать быстрее — и теперь вы делаете 8 фич в неделю. Что произойдёт с нашей системой?
Вы — молодец, эффективность и метрики растут, может быть вам даже поднимут зарплату. А тестировщика возможно уволят.
А теперь представьте: вы делали 6 фич в неделю, потом сходили на какую-нибудь конференцию, вам там рассказали, как делать быстрее — и теперь вы делаете 8 фич в неделю. Что произойдёт с нашей системой?
Вы — молодец, эффективность и метрики растут, может быть вам даже поднимут зарплату. А тестировщика возможно уволят.
Делать меньше, чтобы получилось больше? Да вы что!
Когда мы начинаем думать про ограничения, самое сложное в этой истории — это уйти от той самой локальной оптимизации, в которую мы так свято верим, про которую я говорила выше: что улучшения не суммируются.
То, что в тот момент, когда я пойму: тестирование не вывозит — и мне, чтобы делать свою работу эффективно не только для себя, но и для всей системы, надо будет начать делать меньше, да ещё и по-другому — это, конечно, вызывает внутренний протест. Я делала 6, а начну делать 5. Что за дичь?
Более того, чтобы помочь всей системе, я не просто начну делать меньше — я ещё и заберу на себя часть задач тестирования, чтобы они смогли не 4 фичи проверить, а 5. Вообще дичь! Такой дорогой ресурс разработки — и мы его тратим на не такие уж дорогие задачи тестирования?
Но это не значит, что если у вас сейчас тестировщиков меньше, чем разработчиков, то надо срочно что-то менять в количестве. Хотя да, сейчас почему-то модный тренд — делать тестировщиков ощутимо меньше, чем разработчиков. И нет, мы сейчас не спорим с теми, кто считает, что «тестировщиков нужно заменить на автотесты!» — не про это речь.
Речь про то, что мы каким-то образом выстроили систему и сказали: окей, вот у нас сейчас ограничение здесь. И если мы хотим, чтобы система в целом давала больше результата, нам придётся это ограничение учитывать. Придётся под него подстраиваться. А не просто упарываться на каждом участке, выдавая всё больше и больше работы — и тем самым создавать горы незавершёнки.
Да, если мы посадим ещё одного тестировщика, то система будет делать больше результата. Но и без дополнительного тестировщика у нас куча разбазаренных мощностей. Можно сделать больше результата — и с текущим количеством людей.
Когда мы начинаем думать про ограничения, самое сложное в этой истории — это уйти от той самой локальной оптимизации, в которую мы так свято верим, про которую я говорила выше: что улучшения не суммируются.
То, что в тот момент, когда я пойму: тестирование не вывозит — и мне, чтобы делать свою работу эффективно не только для себя, но и для всей системы, надо будет начать делать меньше, да ещё и по-другому — это, конечно, вызывает внутренний протест. Я делала 6, а начну делать 5. Что за дичь?
Более того, чтобы помочь всей системе, я не просто начну делать меньше — я ещё и заберу на себя часть задач тестирования, чтобы они смогли не 4 фичи проверить, а 5. Вообще дичь! Такой дорогой ресурс разработки — и мы его тратим на не такие уж дорогие задачи тестирования?
Но это не значит, что если у вас сейчас тестировщиков меньше, чем разработчиков, то надо срочно что-то менять в количестве. Хотя да, сейчас почему-то модный тренд — делать тестировщиков ощутимо меньше, чем разработчиков. И нет, мы сейчас не спорим с теми, кто считает, что «тестировщиков нужно заменить на автотесты!» — не про это речь.
Речь про то, что мы каким-то образом выстроили систему и сказали: окей, вот у нас сейчас ограничение здесь. И если мы хотим, чтобы система в целом давала больше результата, нам придётся это ограничение учитывать. Придётся под него подстраиваться. А не просто упарываться на каждом участке, выдавая всё больше и больше работы — и тем самым создавать горы незавершёнки.
Да, если мы посадим ещё одного тестировщика, то система будет делать больше результата. Но и без дополнительного тестировщика у нас куча разбазаренных мощностей. Можно сделать больше результата — и с текущим количеством людей.
И ещё раз
Если мы действительно хотим делать свою работу эффективной, то первое, с чего надо начать — это разобраться с целью компании. Не просто в духе «деньги — не деньги», а в деталях: за что нам платят? кто нам платит? Уж точно не фичи и не продукт.
Потом — понять, что должно произойти от начала и до конца, чтобы нам вообще заплатили. Цепочку целиком.
Затем — найти своё место в этой цепочке. Сказать: окей, я вот здесь. А где относительно меня находится ограничение?
И вот тогда уже можно хотя бы свою работу организовать так, чтобы ограничение сделало как можно больше. А значит, и система в целом — тоже. А не просто — «чтобы как можно больше сделал я».
Ну, а если уж во мне совсем много стремления, воли, амбиций, работоспособности —
да ещё и есть поддержка со стороны руководства и команды —
тогда я могу пересмотреть не только свою часть, но и всю систему целиком.
Потом — понять, что должно произойти от начала и до конца, чтобы нам вообще заплатили. Цепочку целиком.
Затем — найти своё место в этой цепочке. Сказать: окей, я вот здесь. А где относительно меня находится ограничение?
И вот тогда уже можно хотя бы свою работу организовать так, чтобы ограничение сделало как можно больше. А значит, и система в целом — тоже. А не просто — «чтобы как можно больше сделал я».
Ну, а если уж во мне совсем много стремления, воли, амбиций, работоспособности —
да ещё и есть поддержка со стороны руководства и команды —
тогда я могу пересмотреть не только свою часть, но и всю систему целиком.
А теперь немного про метрики. Они бывают разные, особенно когда они не ваши
А метрики — это вообще зачем?
И вот после всего этого, когда мы уже понимаем, что действительно является эффективностью для нашей системы, мы можем начать думать про метрики.
Но прежде чем вообще думать про метрики, давайте снова вспомним:
эффективность — это приближение к цели
А цель метрик в чём? На самом деле — вариантов много. Иногда мы хотим внедрить метрики, чтобы заметить проблему. Типа: если что-то пойдёт не так — метрики изменятся, мы скажем: «О! Отклонение!» — и идём разбираться.
Иногда метрики нужны, чтобы понять, стало лучше или нет. Мы увидели проблему, решили: надо что-то поменять. Придумали решение, внедрили — и теперь хотим проверить: стало ли лучше?
Иногда метрики нужны просто чтобы успокоиться. Это довольно популярная история:
мы (или руководство) начинаем переживать: «А вдруг можно было бы работать быстрее?»
И тут появляется идея: «Давайте замерим скорость!» Поймём вообще, всё ли в порядке — и, может, просто выдохнем.
Иногда метрики помогают договориться. Вот мы спорим: «У нас всё плохо!" — «Нет, всё хорошо!" — «Это решение плохое!" — «Да нет, норм!» Метрики тут становятся своего рода критерием «хорошо/плохо». Снижается эмоциональный градус — и можно хотя бы о чём-то договориться.
Будем честны: иногда метрики нужны ради квартального бонуса. И я никого не осуждаю. Бывает по-всякому. Кто-то говорит: «Да у нас в системе вообще трэш, хотя бы зарплату пусть платят — остальное неважно».
И вот после всего этого, когда мы уже понимаем, что действительно является эффективностью для нашей системы, мы можем начать думать про метрики.
Но прежде чем вообще думать про метрики, давайте снова вспомним:
эффективность — это приближение к цели
А цель метрик в чём? На самом деле — вариантов много. Иногда мы хотим внедрить метрики, чтобы заметить проблему. Типа: если что-то пойдёт не так — метрики изменятся, мы скажем: «О! Отклонение!» — и идём разбираться.
Иногда метрики нужны, чтобы понять, стало лучше или нет. Мы увидели проблему, решили: надо что-то поменять. Придумали решение, внедрили — и теперь хотим проверить: стало ли лучше?
Иногда метрики нужны просто чтобы успокоиться. Это довольно популярная история:
мы (или руководство) начинаем переживать: «А вдруг можно было бы работать быстрее?»
И тут появляется идея: «Давайте замерим скорость!» Поймём вообще, всё ли в порядке — и, может, просто выдохнем.
Иногда метрики помогают договориться. Вот мы спорим: «У нас всё плохо!" — «Нет, всё хорошо!" — «Это решение плохое!" — «Да нет, норм!» Метрики тут становятся своего рода критерием «хорошо/плохо». Снижается эмоциональный градус — и можно хотя бы о чём-то договориться.
Будем честны: иногда метрики нужны ради квартального бонуса. И я никого не осуждаю. Бывает по-всякому. Кто-то говорит: «Да у нас в системе вообще трэш, хотя бы зарплату пусть платят — остальное неважно».
Метрики сверху
Но есть ещё один момент, который, как мне кажется, суперважный. Сейчас мы говорили о ситуациях, когда мы сами решаем внедрить метрики. Но у тех ребят, которые вначале голосовали против, — наверняка были другие ситуации. Когда метрики внедрили им. И это, честно говоря, иногда это действительно бесит.
Ты вроде понимаешь, как делать свою работу и делаешь её как тебе кажется хорошо. Потом тебе сверху спускают метрики. И ты понимаешь: если будешь работать по ним, чтобы метрики были красивыми — ты начнёшь делать свою работу плохо.
Появляется два варианта: либо саботировать, либо включать «двойную бухгалтерию»:
одна метрика — для руководства, другая — для себя. И это раздражает. В такие моменты мы думаем: «Тот, кто это придумал, вообще думал?»
Но если честно — любое решение, даже самое дурацкое, всегда — это попытка решить какую-то проблему. Если вы хотите что-то поменять, первое, что нужно сделать —
понять, какую проблему пытался решить человек, который эти метрики внедрил. Чаще всего руководство внедряет метрики не потому, что им скучно. А потому что им страшно.
Они понимают: под ними огромная система. Её надо как-то контролировать. Надо понимать: что-то вообще работает? что-то приносит пользу? люди стараются или нет?
И иногда единственное, что приходит им в голову — это внедрить метрики.
Так появляется иллюзия контроля, иллюзия прозрачности. А вместе с этим — и куча геморроя у тех, на кого эти метрики спустили. Что делать? Разговаривать. :)
Но есть ещё один момент, который, как мне кажется, суперважный. Сейчас мы говорили о ситуациях, когда мы сами решаем внедрить метрики. Но у тех ребят, которые вначале голосовали против, — наверняка были другие ситуации. Когда метрики внедрили им. И это, честно говоря, иногда это действительно бесит.
Ты вроде понимаешь, как делать свою работу и делаешь её как тебе кажется хорошо. Потом тебе сверху спускают метрики. И ты понимаешь: если будешь работать по ним, чтобы метрики были красивыми — ты начнёшь делать свою работу плохо.
Появляется два варианта: либо саботировать, либо включать «двойную бухгалтерию»:
одна метрика — для руководства, другая — для себя. И это раздражает. В такие моменты мы думаем: «Тот, кто это придумал, вообще думал?»
Но если честно — любое решение, даже самое дурацкое, всегда — это попытка решить какую-то проблему. Если вы хотите что-то поменять, первое, что нужно сделать —
понять, какую проблему пытался решить человек, который эти метрики внедрил. Чаще всего руководство внедряет метрики не потому, что им скучно. А потому что им страшно.
Они понимают: под ними огромная система. Её надо как-то контролировать. Надо понимать: что-то вообще работает? что-то приносит пользу? люди стараются или нет?
И иногда единственное, что приходит им в голову — это внедрить метрики.
Так появляется иллюзия контроля, иллюзия прозрачности. А вместе с этим — и куча геморроя у тех, на кого эти метрики спустили. Что делать? Разговаривать. :)
Метрика — не цель, а сигнал
Как всё-таки сделать метрики такими, чтобы они не мешали, а помогали нам? Что такое хорошие метрики, а что такое плохие метрики?
Любые метрики можно саботировать
Первое и самое главное, что надо помнить про метрики: худшие метрики — это те, которые можно саботировать. Но плохая новость в том, что абсолютно любые метрики можно саботировать. Невозможно придумать такую комбинацию, при которой, только правильно себя ведя, мы получим нужный результат по метрикам. Всегда можно хакнуть игру, всегда можно найти, как обойти правила.
Раз мы не можем придумать метрики, которые вообще никак нельзя будет хакнуть, мы должны снизить мотивацию людей к саботажу. А это значит — не привязывать к метрикам финансовую мотивацию и вообще любую мотивацию. Как только мы это делаем, мы запускаем закон Гудхарта. А он говорит, что как только метрика становится целью, сама система начинает менять своё поведение.
У меня есть очень понятный пример. Если вы хотите использовать градусник, чтобы просто померить температуру — всё ок. Но как только вы скажете ребёнку, что за 36,6 он получит мороженое — всё, в этот момент нельзя оставлять его одного с градусником. Потому что у него тут же появляются активности, никак не связанные с выздоровлением, а исключительно направленные на получение красивой цифры. И главная беда — больше нельзя верить градуснику.
Всегда, когда метрика становится самоцелью, система начинает делать всякую фигню. Поэтому хотя бы не надо привязывать деньги к метрикам. Возможно, иногда лучше вообще не рассказывать людям, что именно мы измеряем.
У меня есть очень понятный пример. Если вы хотите использовать градусник, чтобы просто померить температуру — всё ок. Но как только вы скажете ребёнку, что за 36,6 он получит мороженое — всё, в этот момент нельзя оставлять его одного с градусником. Потому что у него тут же появляются активности, никак не связанные с выздоровлением, а исключительно направленные на получение красивой цифры. И главная беда — больше нельзя верить градуснику.
Всегда, когда метрика становится самоцелью, система начинает делать всякую фигню. Поэтому хотя бы не надо привязывать деньги к метрикам. Возможно, иногда лучше вообще не рассказывать людям, что именно мы измеряем.
Показатели нужны чтобы показывать, что мы всё делаем правильно, а не что нам правильно делать.
Почему это важно? Потому что хорошие метрики не говорят нам, что делать правильно. Они вообще не про это. Метрики нужны для того, чтобы понять, что что-то идёт не так.
Простой пример: у нас есть метрика удовлетворённости сотрудников, и она вдруг упала. Это не значит, что надо срочно бежать и поднимать её плюшками. Это значит, что надо идти и разбираться, почему она упала.
В этом смысле, если мы как-то скроем метрики от людей — возможно, ничего плохого не случится. У нас же нет задачи — смотреть на метрику и пытаться напрямую её улучшить. Как только ты это начинаешь делать — всё становится хуже.
Поэтому иногда бывает полезно не афишировать метрики. Или как минимум — постоянно проверять себя и коллег на закон Гудхарта.
Простой пример: у нас есть метрика удовлетворённости сотрудников, и она вдруг упала. Это не значит, что надо срочно бежать и поднимать её плюшками. Это значит, что надо идти и разбираться, почему она упала.
В этом смысле, если мы как-то скроем метрики от людей — возможно, ничего плохого не случится. У нас же нет задачи — смотреть на метрику и пытаться напрямую её улучшить. Как только ты это начинаешь делать — всё становится хуже.
Поэтому иногда бывает полезно не афишировать метрики. Или как минимум — постоянно проверять себя и коллег на закон Гудхарта.
Устаревание
Если мы с вами занимаемся улучшениями, то улучшение — это всегда не про больше, быстрее, выше, сильнее. Улучшение — это про «по-другому». А когда мы придумываем метрики, мы придумываем их в рамках того, как работает система сейчас.
А когда мы начинаем заниматься ростом эффективности — тем самым, при котором мы меняем способ работы системы, — метрики, как правило, очень быстро перестают работать. Они устаревают. Поэтому второе по значимости (после «не надо мотивировать людей на метрики») — это то, что метрики надо всё время пересматривать.
Метрики имеют свойство устаревать по разным причинам. Мы могли считать их вручную, а потом автоматизировали расчёт — и, допустим, что-то изменилось: флоу поменялся, метрики поехали, а мы всё равно продолжаем на них смотреть. Или у нас изменилась логика работы. Например, мы увидели, где у нас ограничение, и поняли, что надо делать не как можно больше всего, а как можно больше быстро проверяемого. Или не просто больше писать ТЗ, а писать такие ТЗ, которые максимально реализуемые. И это всё — про необходимость пересматривать метрики.
Но! Тут тоже нельзя впадать в крайности. Я уверена, многие из вас попадали в ситуацию с регулировкой воды в душе — особенно где-нибудь в отеле. Там бывает настолько странный смеситель, что ты не понимаешь, где горячая, где холодная. И если постоянно дёргать кран туда-сюда, вода нормальной не станет. То же самое и с метриками: у них есть инерция. Если мы будем постоянно их пересматривать, ничего не получится. Надо дать системе время адаптироваться. Дать метрикам возможность что-то показать, или показать, что зря мы выбрали эти метрики. Поэтому, с одной стороны нужно регулярно пересматривать метрики, но с другой — не надо каждый день дёргать рычаг горячей и холодной воды.
Если мы с вами занимаемся улучшениями, то улучшение — это всегда не про больше, быстрее, выше, сильнее. Улучшение — это про «по-другому». А когда мы придумываем метрики, мы придумываем их в рамках того, как работает система сейчас.
А когда мы начинаем заниматься ростом эффективности — тем самым, при котором мы меняем способ работы системы, — метрики, как правило, очень быстро перестают работать. Они устаревают. Поэтому второе по значимости (после «не надо мотивировать людей на метрики») — это то, что метрики надо всё время пересматривать.
Метрики имеют свойство устаревать по разным причинам. Мы могли считать их вручную, а потом автоматизировали расчёт — и, допустим, что-то изменилось: флоу поменялся, метрики поехали, а мы всё равно продолжаем на них смотреть. Или у нас изменилась логика работы. Например, мы увидели, где у нас ограничение, и поняли, что надо делать не как можно больше всего, а как можно больше быстро проверяемого. Или не просто больше писать ТЗ, а писать такие ТЗ, которые максимально реализуемые. И это всё — про необходимость пересматривать метрики.
Но! Тут тоже нельзя впадать в крайности. Я уверена, многие из вас попадали в ситуацию с регулировкой воды в душе — особенно где-нибудь в отеле. Там бывает настолько странный смеситель, что ты не понимаешь, где горячая, где холодная. И если постоянно дёргать кран туда-сюда, вода нормальной не станет. То же самое и с метриками: у них есть инерция. Если мы будем постоянно их пересматривать, ничего не получится. Надо дать системе время адаптироваться. Дать метрикам возможность что-то показать, или показать, что зря мы выбрали эти метрики. Поэтому, с одной стороны нужно регулярно пересматривать метрики, но с другой — не надо каждый день дёргать рычаг горячей и холодной воды.
А делать то что???
Если бы моей целью было получить от вас лайки и репосты за данную заметку, мне бы следовало дать вам понятную готовую инструкцию и сделать статью сильно короче. Но у меня другая цель — побудить вас к настоящим изменениям.
А я искренне верю, что готовые инструкции не помогают изменениям. Готовые инструкции создают иллюзию, что всё уже понятно, уже вот лежит — потом возьму, сделаю, будет окей. Книги, интернет, головы коллег и консультантов полны готовых инструкций. Но они либо не внедряются, либо запускают каргокульт: когда ты не до конца понимаешь, что и зачем ты делаешь, просто что-то делаешь.
Вместо инструкции я скажу другую штуку: если эффективность — это приближение к цели, то первый вопрос, который надо себе задать: а в чём ваша цель? Личная цель?
А я искренне верю, что готовые инструкции не помогают изменениям. Готовые инструкции создают иллюзию, что всё уже понятно, уже вот лежит — потом возьму, сделаю, будет окей. Книги, интернет, головы коллег и консультантов полны готовых инструкций. Но они либо не внедряются, либо запускают каргокульт: когда ты не до конца понимаешь, что и зачем ты делаешь, просто что-то делаешь.
Вместо инструкции я скажу другую штуку: если эффективность — это приближение к цели, то первый вопрос, который надо себе задать: а в чём ваша цель? Личная цель?
И да, это всё очень непросто. Но в чём цель?
BONUS-TRACK для редакторов и не только
Эта заметка создавалась в сотрудничестве с «Клубом главредов». И будет странно, если после всех этих рассуждений мы не приземлимся на реальную ситуацию из редакционной жизни.
Представим, есть редакция. Это такой механизм внутри компании, который может производить материалы как для внутрянки компании (презентации, скрипты, лендинги), так и для внешних коммуникаций: бренд-медиа, соцсети, рассылки, SEO-контент и прочее.
Одно из направлений работы этой редакции — SEO-статьи. Они должны приводить органический трафик из интернета, конвертировать его в лиды (через лид-формы, виджеты и другие инструменты), а дальше лиды передаются в отдел продаж, где менеджеры доводят их до сделки.
И вот она, система: поиск → сайт → лиды → продажи → деньги для бизнеса.
В теории — всё очень понятно. Но здесь может случиться катастрофа.
Допустим, редакция работает как часы: клепает одну SEO-статью за другой, лид-формы шикарные, конверсии бьют рекорды. Кажется, всё супер. Но дальше — провал. Отдел продаж захлёбывается. Лидов слишком много, менеджеры не справляются. Кому-то не отвечают вообще, кому-то — с опозданием. Клиенты не ждут. Они просто уходят. И деньги, которые бизнес вот-вот должен был получить, буквально утекают сквозь пальцы. Зато редакция получила свои премии.
Что в такой ситуации может сказать главред: «Слушайте, мы свою работу сделали. Лиды пришли? Пришли. Мы даже план перевыполнили. А то, что дальше не сработало — не наша зона ответственности. С нас все взятки гладки».
То есть с точки зрения редакции — всё эффективно: материалы выпускаются, план по лидам — огонь. Всё отлично. Но с точки зрения всей системы — нет. Деньги не пришли. Цель не достигнута.
Цель бизнеса — зарабатывать деньги. И это значит, система работает эффективно только тогда, когда деньги действительно приходят. А в этом кейсе — наоборот: чем больше лидов, тем хуже. Потому что нагрузка на отдел продаж превышает их возможности.
Что делать?
— Во-первых, сократить объём. Да-да. Начать делать меньше. Посмотреть на качество лидов: кто эти люди, приходящие из SEO? Насколько они подходят? Может, нужно не просто штамповать статьи, а пересмотреть контентную стратегию, чтобы привлекать более релевантную аудиторию.
— Во-вторых, идти к продажам и спрашивать: «Чем мы можем помочь?». Может, скрипты хромают — давайте перепишем. Может, можно подключить чат-бота, чтобы часть запросов автоматизировать и разгрузить команду.
Здесь главред выходит за рамки редакции и смотрит на всю систему целиком. Не просто «делаю хорошо свою часть», а «помогаю системе достигать цели».
И вот только тогда это можно назвать эффективностью. Не локальной, а системной.
BONUS-TRACK для редакторов и не только
Эта заметка создавалась в сотрудничестве с «Клубом главредов». И будет странно, если после всех этих рассуждений мы не приземлимся на реальную ситуацию из редакционной жизни.
Представим, есть редакция. Это такой механизм внутри компании, который может производить материалы как для внутрянки компании (презентации, скрипты, лендинги), так и для внешних коммуникаций: бренд-медиа, соцсети, рассылки, SEO-контент и прочее.
Одно из направлений работы этой редакции — SEO-статьи. Они должны приводить органический трафик из интернета, конвертировать его в лиды (через лид-формы, виджеты и другие инструменты), а дальше лиды передаются в отдел продаж, где менеджеры доводят их до сделки.
И вот она, система: поиск → сайт → лиды → продажи → деньги для бизнеса.
В теории — всё очень понятно. Но здесь может случиться катастрофа.
Допустим, редакция работает как часы: клепает одну SEO-статью за другой, лид-формы шикарные, конверсии бьют рекорды. Кажется, всё супер. Но дальше — провал. Отдел продаж захлёбывается. Лидов слишком много, менеджеры не справляются. Кому-то не отвечают вообще, кому-то — с опозданием. Клиенты не ждут. Они просто уходят. И деньги, которые бизнес вот-вот должен был получить, буквально утекают сквозь пальцы. Зато редакция получила свои премии.
Что в такой ситуации может сказать главред: «Слушайте, мы свою работу сделали. Лиды пришли? Пришли. Мы даже план перевыполнили. А то, что дальше не сработало — не наша зона ответственности. С нас все взятки гладки».
То есть с точки зрения редакции — всё эффективно: материалы выпускаются, план по лидам — огонь. Всё отлично. Но с точки зрения всей системы — нет. Деньги не пришли. Цель не достигнута.
Цель бизнеса — зарабатывать деньги. И это значит, система работает эффективно только тогда, когда деньги действительно приходят. А в этом кейсе — наоборот: чем больше лидов, тем хуже. Потому что нагрузка на отдел продаж превышает их возможности.
Что делать?
— Во-первых, сократить объём. Да-да. Начать делать меньше. Посмотреть на качество лидов: кто эти люди, приходящие из SEO? Насколько они подходят? Может, нужно не просто штамповать статьи, а пересмотреть контентную стратегию, чтобы привлекать более релевантную аудиторию.
— Во-вторых, идти к продажам и спрашивать: «Чем мы можем помочь?». Может, скрипты хромают — давайте перепишем. Может, можно подключить чат-бота, чтобы часть запросов автоматизировать и разгрузить команду.
Здесь главред выходит за рамки редакции и смотрит на всю систему целиком. Не просто «делаю хорошо свою часть», а «помогаю системе достигать цели».
И вот только тогда это можно назвать эффективностью. Не локальной, а системной.
