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

Наверняка вы уже сталкивались с такой ситуацией. Вы из кожи вон лезли: выложились на 200%, упахались, выгорели, потушили все пожары, подняли мотивацию подгоревших сотрудников, победили сопротивление упрямого руководства, достигли эти чертовы вечно растущие KPI. Сделали всё, что могли. Но в итоге — удовлетворения нет.

Компания в каком состоянии была, в таком и осталась. Клиентов больше не стало, денег — тоже. Заказчики как бухтели, так и продолжают. Вроде бы старались. Вроде бы была эффективность. А вроде и не было.

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

Меня зовут Александра Брызгалова. Я практик и сертифицированный эксперт по теории ограничений (Голдратт) и бизнес-консультант.

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

Ниже приведен текст моего доклада на одной ламповой ITшной конференции. Письменный вариант появился благодаря поддержке «Клуба главредов» в лице Данилы Терентьева, Community и Product Lead сообщества.

Прежде чем я расскажу вам о том, как я понимаю «эффективность» , у меня к вам вопрос:

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

Можно было бы здесь разместить ссылку на опрос, но к сожалению уравнения голосованиями не решаются. Я лично метрики и люблю, и ненавижу, потому что, как обычно, всё зависит от цели. Давайте расскажу, что я имею ввиду.

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

И вот у компании случился особенно удачный месяц. И относительно метрик, что мы видим:

И вроде все молодцы, и вроде бы удачный месяц, но если мы посмотрим чуть издалека и еще через какое-то время, то мы узнаем, что:

Вроде бы все старались, и вроде каждый был эффективным, но общего во всем этом — что система не достигла цель.

А почему тогда нам кажется, что каждый должен быть эффективен? Потому что мы верим, что улучшения суммируются — и если каждый будет эффективным, то система тоже будет эффективной.

Приведу максимально банальный пример. У нас есть цепь, состоящий из 10 звеньев. И мы решаем, что надо бы её улучшить. Улучшения суммируются, поэтому мы берем и каждое звено цепи улучшаем, повышая прочность на 10%. Насколько тогда возрастет прочность всей цепи? На 10% — не на 100% же. Хотя, если у мы улучшаем 10 звеньев на 10%, а улучшения суммируются, то она должна была бы стать прочней в два раза.

Но улучшения не суммируются! Более того, если мы будем рвать нашу цепь, она порвется всего в одном ме��те. И если мы усилим не 10 звеньев на 10%, а 9 звеньев — на 20%, но не попадем в самое слабое звено, то мы усилим прочность цепи на 0%. А с другой стороны, если мы усилим только слабое звено на 10, то результат будет такой же, как если бы мы усилили каждое звено.

Вроде бы супер простой пример, который доказывает, что локальные улучшения не суммируются. Но мы, судя по нашему поведению, думаем и верим, в локальную оптимизацию, а в это время локальные метрики эффективности просто подталкивают нас к занятости (на самом деле всё ещё хуже, но об этом позже).

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

Когда я рассказываю исто��ию эффективности топ-менеджменту, они очень часто говорят:

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

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

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

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

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

Чтобы быть эффективным, нужно знать цель.

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

И здесь у меня для вас сразу две новости: хорошая и плохая.

Хорошая новость в том, что есть простой ответ на вопрос, в чем цель. Для коммерческой организации цель — зарабатывание денег. Плохая новость в том, что этот ответ вообще не помогает. Но всё-таки нам важно разграничить и зафиксировать у себя в голове: нашей целью не является обогнать конкурентов, или совершить технологическую революцию на рынке, или решить все боли всех наших клиентов. Наша цель — зарабатывать деньги. Все остальное — средства достижения этой цели.

На всякий случай проговорю: цель “деньги” не означает, что мы срочно должны становиться беспринципными, нечестными, без идейными, мы можем выбирать то, как именно мы будем зарабатывать деньги, но цель - деньги.

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

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

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

Предостережение – самое частое возражение на этом этапе: “руководство само должно нам это всё разъяснить”. В идеальном мире - да. Но “идеально” по словарю - это антоним слова “реально”. Реально!!)) Так что может рудоводство и должно, но часто оно не просто не говорит, оно не знает.

И здесь не нужно становиться занозой и душнилой, нужно помочь увидеть это пробел и заполнить его.

Нам важно понимать вот эти единицы цели — деньги. Через что они у нас появляются? Только в этом случае мы сможем понять, что будет или не будет для нас «эффективно». Но кроме этого, мы еще должны узнать, что происходит до и после нас. Потому что если мы не знаем, что происходит после нас, то у нас не будет шансов сделать свою работу эффективно. А правильно, если честно, не бывает.

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

Уже даже после этого вы можете сделать свою работу более эффективной, соотнеся её с целью и тем, как ваша компания приближается к этой цели.

Но да, это не просто. Но если вы хотите, чтобы ваша работа имела больше смысла - у вас нет другого варианта)

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

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

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

Переключения - это когда мы начали делать одну задачу, не доделади и переключились на другую. Переключение — это зло. Каждый раз, когда мы переключаемся, мы увеличиваем количество трудоемкости, которое будет потрачено на задачу. И увеличение трудоемкости не на 5-10%. Если мы не контролируем количество незавершенной работы, то переключения могут увеличивать трудоемкость в 2-3 раза (я не преувеличиваю).

И вот, банальный пример. Допустим, вы, как разработчик, можете выпускать 6 фич в неделю, а тестировщик может проверить только 4 фичи в неделю. Вы начали работать с нуля. Вы сделали 6 фич, тестировщик проверил только 4, а 2 фичи уходят в запас. На следующей неделе вы сделали еще 6 фичи, тестировщик опять проверил только 4, и уже 4 фичи в запасе. Если мы будем продолжать так достаточно долго, понятно, что в какой-то момент тестировщик проверит к концу недели уже 3. Почему? Потому что если перед ним будет лежать гора фичей на проверку, он не сможет взять только первые 4 и сделать только их, он будет переключаться между всеми. И времени, которое он потратит на все эти переключения, не хватит на четвертую фичу.

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

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

Когда мы начинаем думать про ограничения, самое сложное в этой истории — это уйти от той самой локальной оптимизации, в которую мы так свято верим, про которую я говорила выше: что улучшения не суммируются.

То, что в тот момент, когда я пойму: тестирование не вывозит, — и мне, чтобы делать свою работу эффективно, не только для себя, но и для всей системы, надо будет начать делать меньше, да ещё и по-другому, — это, конечно, вызывает внутренний протест. Я делала 6, а начну делать 5. Что за дичь?

Более того, чтобы помочь всей системе, я не просто начну делать меньше — я ещё и заберу на себя часть задач тестирования, чтобы они смогли не 4 фичи проверить, а 5. Вообще дичь! Такой дорогой ресурс разработки — и мы его тратим на не такие уж дорогие задачи тестирования?

Но это не значит, что если у вас сейчас тестировщиков меньше, чем разработчиков, то надо срочно что-то менять в количестве. Хотя да, сейчас почему-то модный тренд — делать тестировщиков ощутимо меньше, чем разработчиков. И нет, мы сейчас не спорим с теми, кто считает, что “тестировщиков нужно заменить на автотесты!» Не про это речь.

Речь про то, что мы каким-то образом выстроили систему и сказали: окей, вот у нас сейчас ограничение здесь. И если мы хотим, чтобы система в целом давала больше результата, нам придется это ограничение учитывать. Придется под него подстраиваться. А не просто упарываться на каждом участке, выдавая всё больше и больше работы — и тем самым создавать горы незавершенки.

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

Ещё раз

Если мы реально хотим делать свою работу эффективной, то первое, с чего надо начать — это разобраться с целью компании. Не просто в духе «деньги – не деньги», а в деталях. За что нам платят? Кто нам платит? Не фичи и даже не продукт.

Потом — понять, что должно произойти от начала и до конца, чтобы нам вообще заплатили. Цепочку целиком.

Потом — найти своё место в этой цепочке. Сказать: окей, я вот здесь. И где относительно меня находится ограничение?

И вот тогда можно хотя бы свою работу организовать так, чтобы ограничение сделало как можно больше. А значит, и система в целом — тоже. А не просто — «чтобы как можно больше сделал я».

Ну и если уж во мне совсем много стремления, воли, амбиций, работоспособности, да ещё и есть поддержка со стороны руководства и команды — тогда я могу пересмотреть не только свою часть, но и всю систему целиком.

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

И тут, на самом деле, довольно много вариантов. Иногда мы хотим внедрить метрики, чтобы заметить проблему. Ну, типа: если что-то пойдёт не так — метрики изменятся, мы такие: «О, отклонение!» — и пойдём разбираться.

Иногда метрики нужны, чтобы понять, стало лучше или нет. Мы увидели проблему, решили: надо что-то поменять. Придумали решение, внедрили его — и теперь хотим проверить, стало ли реально лучше. Вот тут тоже нужны метрики.

Иногда метрики нужны, чтобы просто успокоиться. Это довольно популярная история, когда мы или руководство переживаем: а вдруг можно было бы работать быстрее? И в этот момент появляется идея — а давайте замерим скорость! Поймём вообще, нормально у нас или не очень. Может, всё в порядке — и можно просто выдохнуть и продолжать.

Иногда метрики помогают договориться. Вот мы с вами спорим: «У нас всё плохо!» — «Нет, всё хорошо!» — «Это решение плохое!» — «Да нет, норм!» Метрики тут могут быть как бы критерием: хорошо/плохо. Это снижает эмоциональный градус и помогает наконец договориться.

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

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

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

Вот тогда появляется иллюзия контроля, иллюзия прозрачности. Но вместе с этим — и куча геморроя у тех, на кого эти метрики потом спустили. Что делать? Разговаривать)

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

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

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

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

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

Простой пример: у нас есть метрика удовлетворенности сотрудников, и она вдруг упала. Это не значит, что надо срочно бежать и поднимать её плюшками. Это значит, что надо идти и разбираться, почему она упала. В этом смысле, если мы как-то скроем метрики от людей, возможно, ничего плохого не случится. У нас же нет задачи — смотреть на метрику и пытаться напрямую её улучшить. Как только ты это начинаешь делать — всё становится хуже.

Поэтому иногда бывает полезно не афишировать метрики. Или как минимум постоянно проверять себя и коллег на закон Гудхарта.

Если мы с вами занимаемся улучшениями, то улучшение — это всегда не про больше, быстрее, выше, сильнее. Улучшение — это про «по-другому». А когда мы придумываем метрики, мы придумываем их в рамках того, как работает система сейчас.

А когда мы начинаем заниматься ростом эффективности — тем самым, при котором мы меняем способ работы системы, — метрики, как правило, очень быстро перестают работать. Они устаревают. Поэтому второе по значимости (после «не надо мотивировать людей на метрики») — это то, что метрики надо всё время пересматривать.

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

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

Если бы моей целью было получить от вас лайки и репосты за данную заметку, мне бы следовало дать вам понятную готовую инструкцию и сделать статью сильно короче. Но у меня другая цель — побудить вас к настоящим изменениям.

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

Вместо инструкции я скажу другую штуку: если эффективность — это приближение к цели, то первый вопрос, который надо себе задать: а в чём ваша цель? Личная цель?

И да, это всё очень непросто. Но в чем цель?

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

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

И вот она, система: поиск → сайт → лиды → продажи → деньги для бизнеса.

В теории — всё очень понятно. Но здесь может случиться катастрофа.

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

Что в такой ситуации может сказать главред: «Слушайте, мы свою работу сделали. Лиды пришли? Пришли. Мы даже план перевыполнили. А то, что дальше не сработало — не наша зона ответственности. С нас все взятки гладки».

То есть с точки зрения редакции — все эффективно: материалы выпускаются, план по лидам — огонь. Всё отлично. Но с точки зрения всей системы — нет. Деньги не пришли. Цель не достигнута.

Цель бизнеса — зарабатывать деньги, и это значит, система работает эффективно только тогда, когда деньги действительно приходят. А в этом кейсе — наоборот: чем больше лидов, тем хуже. Потому что нагрузка на отдел продаж превышает их возможности.

Что делать?

— Во-первых, сократить объём. Да-да. Начать делать меньше. Посмотреть на качество лидов: кто эти люди, приходящие из SEO? Насколько они подходят? Может, нужно не просто штамповать статьи, а пересмотреть контентную стратегию, чтобы привлекать более релевантную аудиторию.

— Во-вторых, идти к продажам и спрашивать: «Чем мы можем помочь?». Может, скрипты хромают — давайте перепишем. Может, можно подключить чат-бота, чтобы часть запросов автоматизировать и разгрузить команду.

Здесь главред выходит за рамки редакции и смотрит на всю систему целиком. Не просто «делаю хорошо свою часть», а «помогаю системе достигать цели».

И вот только тогда это можно назвать эффективностью. Не локальной, а системной.

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