Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас)

25 сентября 2025 года

#туча #диаграмма_разрешения_конфликта #конфликт_интересов #причины_брака #win-win-решение #компромисс

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

Конфликт: борьба или поиск?

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

WIN-WIN есть всегда. Выгодно верить

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

Несколько реальных историй

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

История №1. Самый умный разработчик

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

История №2. Ленивый разработчик

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

История №3. Жадный собственник

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

История №4. Глупый начальник

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

Туча или графическое представление конфликта

Все ситуации в духе «Мы д’Артаньяны, а они проклятые гвардейцы» выглядят примерно одинаково: наше доблестное подразделение страдает, пока этот бессмысленный отдел делает ерунду. У нас есть гениальная гипотеза, но они почему-то упёрлись в свою сырую идею. А наших недооценённых сотрудников нагоняет руководство, хотя эти бракоделы спокойно выполняют свои KPI. Причём KPI у них какие-то безумные, в отличие от наших нормальных и грамотных OKR.
Если изобразить подобные конфликты в виде схемы, то все они выглядят примерно так: я хочу «Внедрить своё изменение». Почему? Потому что я верю: есть важная потребность системы, которая находится под угрозой. Я хочу «Спасти эту потребность» или «Получить улучшение». И делаю это не только для себя — а для компании, для всей системы!
Но при этом моё очевидно эффективное решение может поставить под угрозу какую-то другую важную потребность системы. Иногда личную, но чаще — потребность всей системы.
И здесь есть важный момент: нам нужна общая цель. И легко сказать: «У меня с начальником нет общей цели». Но если вы работаете в одной компании, очень высока вероятность, что для вашей компании важны обе потребности, а значит, общая цель всё-таки есть.
Поэтому если мы хотим разрешить конфликт и приблизиться к цели системы, то мы должны сделать, по крайней мере, две вещи.
1. Нужно убедиться, что то, что мы пытаемся сделать, действительно важно не только в нашей локальной ситуации, но в рамках полной картины: в масштабах отдела или компании.

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

Компромисс — худшее из решений

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

«Люди хорошие». И в это тоже выгоднее верить

Допустим, мы сошлись на том, что есть смысл в том, что наше «очевидно классное» решение может ставить важную потребность системы под угрозу. Но чтобы увеличить шанс увидеть это и найти WIN–WIN-решение, нам нужно допустить одну сложную мысль, которая, возможно, вам не понравится:
Люди хорошие.
Эту мысль оставил нам Голдратт. Он настолько в неё верил, что даже написал её на своём надгробии: «…One, people are good…»
Но это не про розовые облака и пони. И не про наивность. Голдратт был израильтянином. Он родился на территории Израиля за год до того, как появилась такая страна, и жил буквально на пороховой бочке. И предположить, что он не сталкивался с конфликтами, жестокостью и сложностями? Конечно, он со всем этим сталкивался. И тем не менее, первым пунктом он написал: «Люди хорошие».
Это не романтизм, а очень прагматичная мысль. Он имел в виду, что у людей, зачастую, нет цели сделать плохо.
Возьмём пример с браком. Ошибки бывают в любой сфере. И самый популярный способ бороться с браком — это штрафы:
Почему люди делают брак? Потому что они плохо стараются. А если плохо стараются, давайте их штрафовать! Тогда у них появится мотивация стараться лучше — и брак исчезнет.
За много лет я смогла выделить всего три причины появления брака.
Первая: мы не договорились, что именно считать браком. Если нет общего понимания, что мы считаем браком, то я могу производить брак, даже не подозревая этого. Помогут ли штрафы? Нет. А если штрафуют ещё и моего начальника, то он начнёт этот брак ещё и прятать. Поможет только если в момент оглашения прайс-листа вы наконец смогли объяснить мне, что считается браком.

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

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

Бывает всякое (и мудаки тоже)

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

Настрой важен

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

Я почти всё

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

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

  • Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас) [посмотреть]
  • Это — не проблема… Настоящая проблема — это… [посмотреть]
  • Про диаграмму разрешения конфликтов (Туча) [посмотреть]
  • Вижу «Штраф за курение 5000» — читаю «Покурить — 5000» [почитать]
  • Почему «KPI+деньги» не работает [почитать] [почитать] [посмотреть]
Мой телеграм-канал, где я оповещаю о новых заметках и делюсь короткими инсайтами и мыслями, которые не попадают сюда. Ещё там можно обсуждать идеи и смотреть на ТОС с разных сторон вместе с другими