Основы ТОС

Метрики, эффективность и здравый смысл: как не угробить систему, пытаясь её улучшить

2025-04-28 14:28 Почитать
Наверняка вы уже сталкивались с такой ситуацией. Вы из кожи вон лезли: выложились на 200%, упахались, выгорели, потушили все пожары, подняли мотивацию подгоревших сотрудников, победили сопротивление упрямого руководства, достигли эти чертовы вечно растущие KPI. Сделали всё, что могли. Но в итоге — удовлетворения нет.
Компания в каком состоянии была, в таком и осталась. Клиентов больше не стало, денег — тоже. Заказчики как бухтели, так и продолжают. Вроде бы старались. Вроде бы была эффективность. А вроде и не было.
Я верю, что неверное понимание того, что такое «эффективность», часто усложняет жизнь и мешает нам получать удовольствие от работы. Я не буду пытаться навязать вам свою картину миру, но хочу предложить другую перспективу. Возможно, вместе мы что-то новое поймём.
Меня зовут Александра Брызгалова. Я практик и сертифицированный эксперт по теории ограничений (Голдратт) и бизнес-консультант.
Здесь не будет простой инструкции, точнее, простая инструкция будет, но исполнить её не всегда просто, а иногда почти невозможно . Но если вы правда хотите не просто занятости, а смысла — то у вас нет выбора)
Ниже приведен текст моего доклада на одной ламповой ITшной конференции. Письменный вариант появился благодаря поддержке «Клуба главредов» в лице Данилы Терентьева, Community и Product Lead сообщества.

Метрики: любовь и ненависть

Прежде чем я расскажу вам о том, как я понимаю «эффективность» , у меня к вам вопрос:
Как вы считаете, метрики эффективности — это крайне важный и необходимый инструмент? Их обязательно надо считать, повышать и, в общем, стремиться к тому, чтоб были всё лучше и лучше? Или вы уже устали от этих зануд и ненавидите эти метрики, потому что: «сколько можно, они всё равно ничего не показывают!Все слишком сложно и постоянно меняется»?
Можно было бы здесь разместить ссылку на опрос, но, к сожалению, уравнения голосованиями не решаются. Я лично метрики и люблю, и ненавижу, потому что, как обычно, всё зависит от цели. Давайте расскажу, что я имею ввиду.

Когда все по отдельности молодцы, но вместе — провал

Жила-была одна компания, которая верила в метрики. Она была очень заряжена, замотивирована, она регулярно ходила по классным конференциям, находила на них способы улучшений, внедряла их классные идеи и фреймворки.
И вот у компании случился особенно удачный месяц. И относительно метрик, что мы видим:
  • Аналитик закрыл все требования по роадмапу, и не только на ближайшее время, а вообще на полгода вперед.
  • Разработчик также узнал что-то новое и выдал за сприн в 2 раза больше фич, чем обычно.
  • Тимлид прокачал свои софт-скилы, поэтому все у него загружены, мотивированы и продуктивны.
  • Продакт включил в релиз всё, что так давно откладывали, и то, за что его так мучили заказчики, собственники и руководство.
  • QA максимально снизил баги до релиза.
  • Маркетолог запустил три мощных компании, которые привлекли кучу лидов.
  • Саппорт ответил на 100 тикетов.
И вроде все молодцы, и вроде бы удачный месяц, но если мы посмотрим чуть издалека и еще через какое-то время, то мы узнаем, что:
  • То, что написал аналитик, так и не дошло до реализации, потому что требования успели устареть. А ещё, пока аналитик писал эти требования, он не очень много и классно отвечал на вопросы разработки, поэтому она сделала не то, и всё придётся переделывать, и, в общем, все очень на него сердятся.
  • Разработчик, вроде бы, молодец, в два раза больше написал фич, но тестирование не было к этому готово, фичи повисли в стейдже, и вместо ускорения получили торможение.
  • Команда действительно старалась на 200%, но так как всё в итоге увязло – все ходят злые и печальные.
  • Продакт включил в релиз все, но команда распылилась, устала, пользователи, при этом, не заметили разницы, хотя вроде давно просили. И оказалось, что они хотели вообще не этого.
  • QA настолько ужесточил правила проверки, что продакты и разработчики стали бояться ходить к нему проверять гипотезы, потому что слишком дорого по времени и ритуалам обходится QA. И в итоге ничего нового, гипотезы не проверяются — продукт не развивается.
  • Маркетолог со своими тремя мощными компаниями привел столько лидов, что отдел продаж не смог обработать даже то количество, которое обычно обрабатывал, бешенно переключался между лидами, и в итоге продажи упали, выручка не получена, репутация пострадала.
  • А саппорт так был занят ответами на тикеты, что не смог эскалировать проблему, она так и осталась не решена, и клиенты в бешенстве продолжают строчить однотипные тикеты.
Вроде бы все старались, и вроде каждый был эффективным, но общего во всем этом — что система не достигла цель.

Локальные улучшения не суммируются

А почему тогда нам кажется, что каждый должен быть эффективен? Потому что мы верим, что улучшения суммируются — и если каждый будет эффективным, то система тоже будет эффективной.
Приведу максимально банальный пример. У нас есть цепь, состоящий из 10 звеньев. И мы решаем, что надо бы её улучшить. Улучшения суммируются, поэтому мы берем и каждое звено цепи улучшаем, повышая прочность на 10%. Насколько тогда возрастет прочность всей цепи? На 10% — не на 100% же. Хотя, если у мы улучшаем 10 звеньев на 10%, а улучшения суммируются, то она должна была бы стать прочней в два раза.
Но улучшения не суммируются! Более того, если мы будем рвать нашу цепь, она порвется всего в одном месте. И если мы усилим не 10 звеньев на 10%, а 9 звеньев — на 20%, но не попадем в самое слабое звено, то мы усилим прочность цепи на 0%. А с другой стороны, если мы усилим только слабое звено на 10, то результат будет такой же, как если бы мы усилили каждое звено.
Вроде бы супер простой пример, который доказывает, что локальные улучшения не суммируются. Но мы, судя по нашему поведению, думаем и верим, в локальную оптимизацию, а в это время локальные метрики эффективности просто подталкивают нас к занятости (на самом деле всё ещё хуже, но об этом позже).
Почему же мы так гонимся за локальными оптимумами? Потому что нам сложно смотреть на картину целиком, мы не можем управлять большой системой. Мы делим её на кусочки, считая, что это сработает. И для много это работает. Но не для эффективности.

Людям важно, чтобы их работа имела смысл

Когда я рассказываю историю эффективности топ-менеджменту, они очень часто говорят:
Это все классно и интересно, конечно, на нашем уровне. Мы-то понимаем, что у системы есть цель — и ее надо достичь. Но если опуститься на уровень рядовых разработчиков, тимлидов и тестировщиков, то они о таком не задумываются. Вот они достигли своего KPI — и им больше ничего не надо
Но я точно верю, что вы не такие.. Хотя бы потому, что одна из самых популярных жалоб линейных сотрудников, которую я слышу: «крайне обидно и досадно, что бОльшая часть работы оказывается в столе». И это уже намекает на то, что вы работаете не только за зарплату.

Когда денег хватает — включаются другие потребности

Еще одна банальность, которая поможет нам ответить на вопрос, за что мы работаем, — пирамида Маслоу. Она говорит нам о том, что, да, иногда мы действительно работаем просто за деньги, просто, чтобы хватило на кусок хлеба. Но в айтишке, зачастую, и на кусок масла уже хватает. И у нас начинают включаться более сложные запросы. Нам хотелось бы получить самореализацию. Но как получить самореализацию, когда ты всё сделал, а чтобы получить результат, тебе надо, чтобы все вокруг начали делать нормально. И кажется, что ты не можешь на это повлиять. Но вообще-то можешь.

Ты не можешь управлять всем, но можешь влиять на эффективность

Даже если ты не можешь изменить работу других, ты можешь сделать свою работу эффективнее с точки зрения системы, а не локальной оптимизации. И чтобы это сделать, надо, для начала, разобраться с тем, что же все-таки такое «эффективно». Кстати, с себя, начинать эффективнее)))

Эффективность ≠ продуктивность

Здесь я не буду устраивать голосование, я и так знаю, что самое распространенное определение эффективности — это быстрее, выше, сильнее, но чаще, это про продуктивность. В ТОС, эффективность — это приближаться к цели. И всё! Продуктивность в этом смысле вторична. Продуктивность может быть низкой, но мы приближаемся к цели быстро. Мы могли сделать какое-то маленькое изменение, которое решило кучу наших проблем. Мы могли даже не особо много времени на это потратить. Эффективность — это приближаться к цели. И это самое важное.
Чтобы быть эффективным, нужно знать цель.
И если мы говорим о том, что мы хотим заниматься эффективностью, а эффективность — это приближаться к цели, то, в первую очередь, мы должны определиться с целью.
И здесь у меня для вас сразу две новости: хорошая и плохая.
Хорошая новость в том, что есть простой ответ на вопрос, в чем цель. Для коммерческой организации цель — зарабатывание денег. Плохая новость в том, что этот ответ вообще не помогает. Но всё-таки нам важно разграничить и зафиксировать у себя в голове: нашей целью не является обогнать конкурентов, или совершить технологическую революцию на рынке, или решить все боли всех наших клиентов. Наша цель — зарабатывать деньги. Все остальное — средства достижения этой цели.
На всякий случай проговорю: цель «деньги» не означает, что мы срочно должны становиться беспринципными, нечестными, без идейными, мы можем выбирать то, как именно мы будем зарабатывать деньги, но цель — деньги.

Деньги — да. А что дальше?

Плохая новость в том, что этого ответа нам недостаточно. Окей, деньги. А как мне понять в моей работе, как я связана с деньгами, которые будут неизвестно когда и неизвестно кем заплачены.
И здесь мы идем дальше: после того, как мы поняли, что цель — зарабатывать деньги, мы должны понять, через что наша компания зарабатывает деньги. И это крайне важно для каждого, кто работает, и хочет действительно как-то влиять на результат, который выдает компания.
И здесь не очень много вариантов. Мы можем зарабатывать деньги через то, что нам платят клиенты за заказы, если мы занимаемся аутсорсингом или аутстаффингом. Нам могут платить клиенты за то, что покупают наш продукт.
Предостережение – самое частое возражение на этом этапе: «руководство само должно нам это всё разъяснить». В идеальном мире — да. Но «идеально– по словарю — это антоним слова «реально». Реально!!)) Так что может руководство и должно, но часто оно не просто не говорит, — оно не знает.
И здесь не нужно становиться занозой и душнилой, нужно помочь увидеть это пробел и заполнить его.
Нам важно понимать вот эти единицы цели — деньги. Через что они у нас появляются? Только в этом случае мы сможем понять, что будет или не будет для нас «эффективно». Но кроме этого, мы еще должны узнать, что происходит до и после нас. Потому что если мы не знаем, что происходит после нас, то у нас не будет шансов сделать свою работу эффективно. А правильно, если честно, не бывает.

Без контекста «до и после» — не сработает

Представим абсурдный, но, думаю, реалистичный пример) Мы с вами сделали классное приложение: лучше, чем у конкурентов, все новейшие технологии задействованы, никаких багов, всё супер. Но наш отдел маркетинга почему-то привлекал клиентов, которые говорят на другом языке, нежели созданный интерфейс. Мы молодцы или нет? Вроде да, но результата же нет. Если мы не знаем, что происходит до или после нас, у нас нет шансов сделать свою работу правильно и эффективно. Поэтому вывод такой:
  1. Определили цель — зарабатывать деньги.
  2. Поняли, через что мы их зарабатываем.
  3. Узнали, что и как происходит до и после нас.
Уже даже после этого вы можете сделать свою работу более эффективной, соотнеся её с целью и тем, как ваша компания приближается к этой цели.
Но да, это непросто. Но если вы хотите, чтобы ваша работа имела больше смысла - у вас нет другого варианта)

Как поток превращается в деньги — и почему не надо бояться ограничений

Есть ещё один момент, о котором следует подумать. Любая система может быть представлена в виде потока. У нас есть цель. Соответственно, наша система — это поток создания единиц цели, где на входе — клиенты, а на выходе — деньги. И абсолютно у любого потока, абсолютно у любой системы, всегда есть и будет ограничение. На всякий случай – это неплохо! Тот, кто у нас является ограничением, не плохой, он не негодяй. Это не тот, кого мы должны во всем обвинять. Ограничение всегда будет, в любой системе. Не бывает систем без ограничений.
Но то, что это неплохо, не значит, что мы не должны про это думать. Мы должны знать, где оно находится и учитывать это в своей деятельности.
Давайте посмотрим на поток и разберёмся, что к чему. Если, мы с вами находимся перед сужением, это значит, что если мы сделаем очень много работы, мы сделаем хуже системе, потому что мы создадим перед ограничением кучу незавершенки и увеличим переключения ограничения.
Переключения — это когда мы начали делать одну задачу, не доделали и переключились на другую. Переключение — это зло. Каждый раз, когда мы переключаемся, мы увеличиваем количество трудоемкости, которое будет потрачено на задачу. И увеличение трудоемкости не на 5-10%. Если мы не контролируем количество незавершенной работы, то переключения могут увеличивать трудоемкость в 2-3 раза (я не преувеличиваю).
И вот, банальный пример. Допустим, вы, как разработчик, можете выпускать 6 фич в неделю, а тестировщик может проверить только 4 фичи в неделю. Вы начали работать с нуля. Вы сделали 6 фич, тестировщик проверил только 4, а 2 фичи уходят в запас. На следующей неделе вы сделали еще 6 фичи, тестировщик опять проверил только 4, и уже 4 фичи в запасе. Если мы будем продолжать так достаточно долго, понятно, что в какой-то момент тестировщик проверит к концу недели уже 3. Почему? Потому что если перед ним будет лежать гора фичей на проверку, он не сможет взять только первые 4 и сделать только их, он будет переключаться между всеми. И времени, которое он потратит на все эти переключения, не хватит на четвертую фичу.
Незавершенка крайне губительно влияет на скорость. И если мы не учитываем, что в нашей системе, особенно после нас, есть ограничения, то у нас нет шансов. Поднимая эффективность до предела, мы гробим результативность всей системы.
А если, представьте себе, мало того, что вы делаете в этой задаче 6 фич в неделю, вы сходите на какую-нибудь конференцию, и на ней вам расскажут, как еще больше ускорится, и вы после этого вместо 6 фич начнете делать 8 фич в неделю. То что будет со всей системой? И если смотреть локально: вы — молодец, вы подняли свою эффективность. Вам даже возможно повысят зарплату, а тестировщика уволят и наймут нового.

Делать меньше, чтобы получилось больше? Да вы что!

Когда мы начинаем думать про ограничения, самое сложное в этой истории — это уйти от той самой локальной оптимизации, в которую мы так свято верим, про которую я говорила выше: что улучшения не суммируются.
То, что в тот момент, когда я пойму: тестирование не вывозит, — и мне, чтобы делать свою работу эффективно, не только для себя, но и для всей системы, надо будет начать делать меньше, да ещё и по-другому, — это, конечно, вызывает внутренний протест. Я делала 6, а начну делать 5. Что за дичь?
Более того, чтобы помочь всей системе, я не просто начну делать меньше — я ещё и заберу на себя часть задач тестирования, чтобы они смогли не 4 фичи проверить, а 5. Вообще дичь! Такой дорогой ресурс разработки — и мы его тратим на не такие уж дорогие задачи тестирования?
Но это не значит, что если у вас сейчас тестировщиков меньше, чем разработчиков, то надо срочно что-то менять в количестве. Хотя да, сейчас почему-то модный тренд — делать тестировщиков ощутимо меньше, чем разработчиков. И нет, мы сейчас не спорим с теми, кто считает, что «тестировщиков нужно заменить на автотесты!» Не про это речь.
Речь про то, что мы каким-то образом выстроили систему и сказали: окей, вот у нас сейчас ограничение здесь. И если мы хотим, чтобы система в целом давала больше результата, нам придется это ограничение учитывать. Придется под него подстраиваться. А не просто упарываться на каждом участке, выдавая всё больше и больше работы — и тем самым создавать горы незавершенки.
Да, если мы посадим ещё одного тестировщика, то система будет делать больше результата. Но и без дополнительного тестировщика у нас куча разбазаренных мощностей. Можно сделать больше результата и с текущим количеством людей.
Ещё раз
Если мы реально хотим делать свою работу эффективной, то первое, с чего надо начать — это разобраться с целью компании. Не просто в духе «деньги – не деньги», а в деталях. За что нам платят? Кто нам платит? Не фичи и даже не продукт.
Потом — понять, что должно произойти от начала и до конца, чтобы нам вообще заплатили. Цепочку целиком.
Потом — найти своё место в этой цепочке. Сказать: «Окей, я вот здесь. И где относительно меня находится ограничение?».
И вот тогда можно хотя бы свою работу организовать так, чтобы ограничение сделало как можно больше. А значит, и система в целом — тоже. А не просто — «чтобы как можно больше сделал я».
Ну и если уж во мне совсем много стремления, воли, амбиций, работоспособности, да ещё и есть поддержка со стороны руководства и команды — тогда я могу пересмотреть не только свою часть, но и всю систему целиком.

Метрики бывают разные. Особенно, когда они не ваши

И вот после всего этого, когда мы уже понимаем, что действительно является эффективностью для нашей системы, мы можем начать думать про метрики. Но прежде чем вообще думать про метрики, давайте снова вспомним: эффективность — это приближение к цели. А цель метрик в чём?
И тут, на самом деле, довольно много вариантов. Иногда мы хотим внедрить метрики, чтобы заметить проблему. Ну, типа: если что-то пойдёт не так — метрики изменятся, мы такие: «О, отклонение!» — и пойдём разбираться.
Иногда метрики нужны, чтобы понять, стало лучше или нет. Мы увидели проблему, решили: надо что-то поменять. Придумали решение, внедрили его — и теперь хотим проверить, стало ли реально лучше. Вот тут тоже нужны метрики.
Иногда метрики нужны, чтобы просто успокоиться. Это довольно популярная история, когда мы или руководство переживаем: а вдруг можно было бы работать быстрее? И в этот момент появляется идея — а давайте замерим скорость! Поймём вообще, нормально у нас или не очень. Может, всё в порядке — и можно просто выдохнуть и продолжать.
Иногда метрики помогают договориться. Вот мы с вами спорим: «У нас всё плохо!» — «Нет, всё хорошо!» — «Это решение плохое!» — «Да нет, норм!» Метрики тут могут быть как бы критерием: хорошо/плохо. Это снижает эмоциональный градус и помогает наконец договориться.
Будем честны, иногда метрики нужны просто ради квартального бонуса. И я никого тут вообще не осуждаю. Бывает по-всякому. Кто-то говорит: «Да у нас в системе вообще трэш, хотя бы зарплату пусть платят — остальное неважно». Ну, окей.
Но ещё один момент, который мне кажется суперважным. Вот мы сейчас говорим про ситуации, когда мы решаем внедрить метрики. Но у тех ребят, которые вначале голосовали против — наверное, были другие ситуации. Когда им метрики внедрили. И это вообще-то — дико бесит. Ты вроде понимаешь, как делать свою работу. А тебе сверху внедряют метрики, и ты понимаешь: если будешь работать так, чтобы эти метрики были красивыми — ты начнёшь делать свою работу плохо. Поэтому остаётся либо саботировать, либо включать «двойную бухгалтерию»: одна метрика для руководства, другая — для себя. Это раздражает.
И в такие моменты мы думаем: «Тот, кто это придумал, вообще, наверное, не думал». Но если честно — любое решение, даже самое дурацкое, всегда — это попытка решить проблему. И если вы хотите что-то поменять, то первое, что нужно сделать — это понять, какую проблему пытался решить человек, который эти метрики внедрил. И, чаще всего, руководство вводит метрики не потому, что им скучно. А потому что они в панике. Они понимают: под ними огромная система, и ею надо как-то управлять. Надо понимать: что-то вообще работает? Что-то приносит пользу? Люди стараются или нет? И всё, что им приходит в голову — это внедрить метрики.
Вот тогда появляется иллюзия контроля, иллюзия прозрачности. Но вместе с этим — и куча геморроя у тех, на кого эти метрики потом спустили. Что делать? Разговаривать)

Метрика — не цель, а сигнал. Главное — не дать системе сойти с ума

Как всё-таки сделать метрики такими, чтобы они не мешали, а помогали нам? Что такое хорошие метрики, а что такое плохие метрики?

Саботаж

Первое и самое главное, что надо помнить про метрики: худшие метрики — это те, которые можно саботировать. Но плохая новость в том, что абсолютно любые метрики можно саботировать. Невозможно придумать такую комбинацию, при которой, только правильно себя ведя, мы получим нужный результат по метрикам. Всегда можно хакнуть игру, всегда можно найти, как обойти правила.
И если мы не можем придумать метрики, которые вообще никак нельзя будет хакнуть, мы должны снизить мотивацию людей к саботажу. А это значит — не привязывать к метрикам финансовую мотивацию, и вообще любую мотивацию. Как только мы это делаем, мы запускаем закон Гудхарта. А он говорит, что как только метрика становится целью, сама система начинает менять свое поведение.
У меня есть очень понятный пример. Если вы хотите использовать градусник, чтобы просто померить температуру, — всё ок. Но как только вы скажете ребенку, что за 36,6 он получит мороженое, всё — в этот момент нельзя оставлять его одного с градусником. Потому что у него тут же появляются активности, никак не связанные с выздоровлением, а исключительно направленные на получение красивой цифры. И главная беда - больше нельзя верить градуснику.
Всегда, когда метрика становится самоцелью, система начинает делать всякую фигню. Поэтому хотя бы не надо привязывать деньги к метрикам. Возможно иногда лучше вообще не рассказывать людям, что именно мы измеряем. Почему это важно? Потому что хорошие метрики не говорят нам, что делать правильно. Они вообще не про это. Метрики нужны для того, чтобы понять, что что-то идёт не так.
Простой пример: у нас есть метрика удовлетворенности сотрудников, и она вдруг упала. Это не значит, что надо срочно бежать и поднимать её плюшками. Это значит, что надо идти и разбираться, почему она упала. В этом смысле, если мы как-то скроем метрики от людей, возможно, ничего плохого не случится. У нас же нет задачи — смотреть на метрику и пытаться напрямую её улучшить. Как только ты это начинаешь делать — всё становится хуже.
Поэтому иногда бывает полезно не афишировать метрики. Или как минимум постоянно проверять себя и коллег на закон Гудхарта.

Устаревание

Если мы с вами занимаемся улучшениями, то улучшение — это всегда не про больше, быстрее, выше, сильнее. Улучшение — это про «по-другому». А когда мы придумываем метрики, мы придумываем их в рамках того, как работает система сейчас.
А когда мы начинаем заниматься ростом эффективности — тем самым, при котором мы меняем способ работы системы, — метрики, как правило, очень быстро перестают работать. Они устаревают. Поэтому второе по значимости (после «не надо мотивировать людей на метрики») — это то, что метрики надо всё время пересматривать.
Метрики имеют свойство устаревать по разным причинам. Мы могли считать их вручную, а потом автоматизировали расчёт — и, допустим, что-то изменилось: флоу поменялся, метрики поехали, а мы всё равно продолжаем на них смотреть. Или у нас изменилась логика работы. Например, мы увидели, где у нас ограничение, и поняли, что надо делать не как можно больше всего, а как можно больше быстро проверяемого. Или не просто больше писать ТЗ, а писать такие ТЗ, которые максимально реализуемые. И это всё — про необходимость пересматривать метрики.
Но! Тут тоже нельзя впадать в крайности. Я уверена, многие из вас попадали в ситуацию с регулировкой воды в душе — особенно где-нибудь в отеле. Там бывает настолько странный смеситель, что ты не понимаешь, где горячая, где холодная. И если постоянно дёргать кран туда-сюда, вода нормальной не станет. То же самое и с метриками: у них есть инерция. Если мы будем постоянно их пересматривать, ничего не получится. Надо дать системе время адаптироваться. Дать матрикам возможность что-то показать, или показать, что зря мы выбрали эти метрики. Поэтому, с одной стороны нужно регулярно пересматривать метрики, но с другой — не надо каждый день дёргать рычаг горячей и холодной воды.

А делать то что???

Если бы моей целью было получить от вас лайки и репосты за данную заметку, мне бы следовало дать вам понятную готовую инструкцию и сделать статью сильно короче. Но у меня другая цель — побудить вас к настоящим изменениям.
А я искренне верю, что готовые инструкции не помогают изменениям. Готовые инструкции создают иллюзию, что всё уже понятно, уже вот лежит — потом возьму, сделаю, будет окей. Книги, интернет, головы коллег и консультантов полны готовых инструкций. Но они либо не внедряются, либо запускают каргокульт: когда ты не до конца понимаешь, что и зачем ты делаешь, просто что-то делаешь.
Вместо инструкции я скажу другую штуку: если эффективность — это приближение к цели, то первый вопрос, который надо себе задать: а в чём ваша цель? Личная цель?
И да, это всё очень непросто. Но в чем цель?

BONUS-TRACK для редакторов и не только

Эта заметка создавалась в сотрудничестве с «Клубом главредов». И будет странно, если после всех этих рассуждений мы не приземлимся на реальную ситуацию из редакционной жизни.
Представим, есть редакция. Это такой механизм внутри компании, который может производить материалы как для внутрянки компании (презентации, скрипты, лендинги), так и для внешних коммуникаций: бренд-медиа, соцсети, рассылки, SEO-контент и прочее. Одно из направлений работ этой редакции — SEO-статьи. Они должны приводить органический трафик из интернета, конвертировать его в лиды (через лид-формы, виджеты и другие инструменты), а дальше лиды передаются в отдел продаж, где менеджеры доводят их до сделки.
И вот она, система: поиск → сайт → лиды → продажи → деньги для бизнеса.
В теории — всё очень понятно. Но здесь может случиться катастрофа.
Допустим, редакция работает как часы: клепает одну SEO-статью за другой, лид-формы шикарные, конверсии бьют рекорды. Кажется, всё супер. Но дальше — провал. Отдел продаж захлебывается. Лидов слишком много, менеджеры не справляются. Кому-то не отвечают вообще, кому-то — с опозданием. Клиенты не ждут. Они просто уходят. И деньги, которые бизнес вот-вот должен был получить, буквально утекают сквозь пальцы. Зато редакция получила свои премии.
Что в такой ситуации может сказать главред: «Слушайте, мы свою работу сделали. Лиды пришли? Пришли. Мы даже план перевыполнили. А то, что дальше не сработало — не наша зона ответственности. С нас все взятки гладки».
То есть с точки зрения редакции — все эффективно: материалы выпускаются, план по лидам — огонь. Всё отлично. Но с точки зрения всей системы — нет. Деньги не пришли. Цель не достигнута.
Цель бизнеса — зарабатывать деньги, и это значит, система работает эффективно только тогда, когда деньги действительно приходят. А в этом кейсе — наоборот: чем больше лидов, тем хуже. Потому что нагрузка на отдел продаж превышает их возможности.
Что делать?
— Во-первых, сократить объём. Да-да. Начать делать меньше. Посмотреть на качество лидов: кто эти люди, приходящие из SEO? Насколько они подходят? Может, нужно не просто штамповать статьи, а пересмотреть контентную стратегию, чтобы привлекать более релевантную аудиторию.
— Во-вторых, идти к продажам и спрашивать: «Чем мы можем помочь?». Может, скрипты хромают — давайте перепишем. Может, можно подключить чат-бота, чтобы часть запросов автоматизировать и разгрузить команду.
Здесь главред выходит за рамки редакции и смотрит на всю систему целиком. Не просто «делаю хорошо свою часть», а «помогаю системе достигать цели».
И вот только тогда это можно назвать эффективностью. Не локальной, а системной.

Полезные материалы

01/ Что такое эффективность? [посмотреть]
02/ Метрики: за и против [посмотреть]
03/ Неограниченные хотелки и ограниченные возможности [почитать]
04/ У вас нет выбора. Либо вы управляете ограничением, либо оно управляет вами [почитать]
05/ Как Теория ограничений помогает улучшать процессы в редакции [посмотреть]
Мой телеграм-канал, где я оповещаю о новых заметках и делюсь короткими инсайтами и мыслями, которые не попадают сюда. Ещё там можно обсуждать идеи и смотреть на ТОС с разных сторон вместе с другими