Все статьи Кучугурин.
Статья

Лес вырублен - цели выполнены - реальность потеряна

Как компания начинает управлять красиво упакованной версией себя - и где это видно раньше всего

20 мая 2026 · 24 мин чтения · Константин Кучугурин

В 2002 году Дэвид Коте возглавил Honeywell. Промышленный гигант на тот момент находился в крутом пике. Четыре с половиной месяца совет директоров и уходящий CEO не давали ему доступа к финансовому блоку и отчётности. Когда Коте наконец получил данные, прогноз по прибыли обрушился в течение нескольких недель.

Он вызвал руководителей ключевых подразделений. Цели, которые им спускали, были оторваны от операционной реальности. Финансовый блок просто транслировал их вниз: сделайте что угодно, чтобы закрыть квартал [1].

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

Самое сильное впечатление произвёл случай на химическом заводе в Луизиане. Управляющий завода, чтобы закрыть квартал, распорядился вырубить лес, прилегавший к заводу, и продал его как пиломатериалы. Получил бонус за исполнение и креатив. Это была часть системы: до 20% объявленной прибыли Honeywell приходило от подобных разовых операций, которые внутри называли "specials" (по сути, схемы).

Коте сделал из этого простой вывод. Раз в месяц он стал резервировать два-три дня без встреч в штаб-квартире, и использовал их на внезапные визиты на заводы. Он называл их "X-days". Один из таких визитов был после гибели рабочего на одном из химических заводов в Луизиане. Коте не поверил, что вопросы безопасности на самом деле решены, и поехал сам, без предупреждения штаба, чтобы увидеть людей и площадку как есть, без подготовленных историй и "свежеокрашенных" стен к его приезду.

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

История одного завода в Луизиане - не история одного Honeywell. Это анатомия, у которой есть разные формы.

Говард Ю, профессор IMD, разбирает в эссе "How Organizations Lose Their Minds" историю Circuit City [2]. К концу девяностых компания запустила собственный "карманный" банк, обслуживавший её же кредитные карты, и очень быстро это решение стало прибыльным. А дальше прибыль банка не выделили в отдельную строку отчётности, её влили в общие операционные результаты магазинов. В итоге они стали выглядеть значительно прибыльнее, чем это было на самом деле. Среднее звено смотрело на цифры и считало, что Circuit City работает эффективнее Best Buy. На деле, без банка, магазины не были эффективнее. Они проигрывали. Бывший CEO Алан Вурцель, оглядываясь назад, сформулировал это в одну фразу:

"Компания обманывала сама себя"

В Луизиане лес продали физически. В Ричмонде правду продали за строчку в отчёте. Результат один: система перестала отличать выполненную цель от реального состояния бизнеса, а дальше работает простое правило: то, чего нет в отчётности, для руководства не существует.

В одной из компаний мне досталась "в наследство" команда DS/DE, которую до моего прихода всерьёз обсуждали полностью убрать, поскольку совершенно не понимали, чем она занимается. Её создал под личные проекты предыдущий руководитель функции. Команда осталась без якоря в управленческой рамке. Инфраструктура и модели работали, но как это превращается в деньги, для борда было не очевидно, а стоимость команды при этом была немаленькой.

Команду не "порезали". Я смог её сохранить и переориентировать на прикладные задачи с измеримым эффектом. Один из примеров: автоматизация клиентской поддержки на базе языковых моделей. Расчётная стоимость обработки одного обращения снизилась примерно в шесть раз, потенциал автоматизации до 40% обращений без роста численности команды.

По сути - такой же механизм, что в Honeywell и Circuit City. Только вместо леса и банка резали способность компаний работать с данными. Эту способность компании теряют не разом. Это не катастрофа и не чей-то злой умысел. Каждый управленческий слой постепенно адаптирует реальность под ожидания наверху.

Как это начинается

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

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

Дальше "удобная" модель закрепляется в поведении.

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

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

Такой руководитель постепенно превращается в "прослойку" между реальностью и теми, кто должен принимать решения на её основе. Любая неудобная информация проходит через него с потерями:

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

У акционера в какой-то момент возникает закономерный вопрос - "а ты что делаешь?". И "прослойка" снова отрабатывает: переадресовывает, объясняет, разруливает, показывает "движение". Поэтому такая "прослойка" часто живёт долго. Она удобна системе, потому что снижает прямой контакт с неудобной реальностью и позволяет сохранять управляемую картину.

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

На следующем уровне искажение доходит до цифр.

Каждая функция живёт в своей системе координат. Продажи - в воронке и LTV. Маркетинг - в CAC и retention. Операционный контур - в своих метриках. ИТ - в доступности, скорости вывода изменений, амортизации НМА, стоимости владения и масштабируемости технологической функции: растёт ли бизнес быстрее, чем расходы на ИТ, сохраняется ли операционная эффективность при том же бюджете, можно ли снижать затраты без потери устойчивости.

Эти метрики классические. Проблема в том, как они доезжают наверх. На уровне функции цифра ещё может быть честной. Но по пути в управленческий отчёт она получает объяснение, контекст, смягчение и удобную причину. Просадка доступности становится "единичным инцидентом". Рост стоимости изменений - "усложнением бизнеса". Падение скорости поставки - "высокой загрузкой команды". Снижение конверсии - "внешним рынком".

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

Но этого мало. Каждый в своих цифрах - это набор функциональных островков. CEO и CFO собирают их в общую экономическую рамку. Чаще всего это EBITDA. Без такой склейки итоговая EBITDA видна, но не видно причин: какое решение реально двигает маржу, какое просто красиво выглядит внутри функции, а какое переносит проблему в соседний контур.

Именно здесь дисфункция раньше всего становится видимой в ИТ.

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

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

В презентации всё может выглядеть "вкусно": цифры, сроки, ожидаемые эффекты. Но в работе быстро становится видно, на чём на самом деле стоит инициатива:

И вот здесь часто выясняется, что перед тобой упаковка под "движение".

С BO (business-owner / бизнес-владелец) спрашивают цифры по плану: выручку, промо-, прямую маржу. Если появляется разрыв план / фактом, бизнесу нужно дать управляемое действие. В современной компании таким действием часто становится новая инициатива: с названием, бюджетом, сроком, владельцем и ожидаемым эффектом.

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

До ИТ такая инициатива доезжает уже решением, прошедшим портфельный или инвестиционный контур.

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

CIO не решает за CPO, IT BP или BO, нужен ли продукт рынку. Но он не должен принимать в технологический контур инициативу, у которой неясны четыре вещи:

Без такого фильтра ИТ превращается в конвейер по производству "дров". Только рубят уже не лес, а ёмкость команд разработки, скорость вывода продуктов и устойчивость архитектуры на горизонте года или двух.

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

Три слоя искажения

Этот конвейер по производству "дров" не возникает сам по себе. Обычно под ним лежат три слоя искажения. Я видел их в разных индустриях и в компаниях разного размера и зрелости.

Первый слой. За что на самом деле спрашивают

Если KPI или OKR устроены так, что цель можно закрыть без реального эффекта для бизнеса, система будет защищать выполнение цели, а не результат. Это не вопрос "плохих" людей. Это вопрос того, какую модель поведения компания фактически вознаграждает.

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

Второй слой. Что доходит до верха

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

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

Третий слой. Что происходит за плохие новости

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

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

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

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

И здесь появляется вопрос: кто внутри системы видит расхождение между фактом и управленческой версией раньше, чем оно становится красивым слайдом?

Где в этом CIO

CIO "стоит" на пересечении нескольких потоков: данные, деньги, процессы, люди, технологии, риски. Это одна из немногих ролей, где процессы через данные видно насквозь: где реальность расходится с отчётом, где управленческая версия не совпадает с тем, что происходит в системах, интеграциях, клиентском пути, операционных потерях, стоимости изменений, качестве решений. Этот список можно продолжать, но смысл один: CIO видит расхождение раньше, чем оно становится красивым слайдом.

Но видеть расхождение - не значит иметь право его исправить.

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

Я сам строил такую систему ещё до того, как стал CIO по роли.

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

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

Со временем этот контур стал давать компании измеримый коммерческий результат. Как полноценный бизнес-контур: продажи, обслуживание клиентов, работа с партнёрами, быстрый запуск изменений.

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

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

Это не история про конкретных людей. Это история про то, как "правильная" управленческая модель может разрезать работающую систему, если не видит, на чём на самом деле держался результат.

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

Поэтому за мандатом CIO идёт на правление не один. Ему нужен союзник, которому прозрачность выгоднее непрозрачности:

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

Юбер Жоли, возглавивший Best Buy в 2012 году, действовал так же. В первый день в роли CEO он поехал в магазин: надел синюю рубашку с биркой "CEO на стажировке" и три дня работал в зале [3]. За это время он увидел то, чего не показывала отчётность:

Для CIO это та же логика, только в другой форме. У каждой индустрии свои источники факта: кассы и эквайринг в рознице, WMS и RFID на складе, SCADA и PLC на производстве, торговые шлюзы и процессинг в финансах, телематика и системы урегулирования убытков в страховании. Но принцип один: реальность нельзя видеть только через отчёты руководителей направлений.

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

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

Чтобы видеть реальность, нужны инструменты. У Коте в 2002 году одним из главных инструментов были очные встречи с людьми. Сегодня инструментов больше: данные текут потоком, мониторинг стал точнее, процессы видны в реальном времени. Но встречи с людьми не исчезли: данные показывают, что происходит - человек объясняет почему.

Сегодня контур, через который компания "видит себя", строится через несколько ролей:

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

Узкое место чаще в бизнес-определениях. Договорились о ролях, но не договорились, что считаем одинаково. "Выручка" в системах-источниках, витринах данных и управленческой отчётности может означать разное. Под одним словом - три разные цифры. Борд получает три версии реальности и ни одной полной.

С приходом ИИ цена этой несогласованности выросла. Модель, обученная на данных, где "выручка" означает три разные вещи, не лечит архитектуру. Она масштабирует её дефекты. По данным Modern Data Report 2026 (540+ респондентов, 64 страны, 29 отраслей), 80% участников ставят семантический слой со стандартизованными определениями на первое место среди условий, без которых ИИ не работает [4].

Несогласованная архитектура из теоретической проблемы становится операционной.

Что с этим делать

Лозунг "говорите правду" не работает.

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

Первое. Красный статус не перекрашивается в зелёный.

Красный - это превышение измеримого порога: вехи, бюджет, допустимое отклонение (например +10%). Не мнение, не настроение. Если по факту проблема - она и в отчёте для акционера обозначена как проблема. Без переупаковки в зелёный.

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

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

Второе. Источник данных не подчиняется владельцу результата.

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

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

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

Третье. За плохие новости не наказывают. За их сокрытие - да.

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

Это не отменяет ответственности. Она просто смещается с поиска виноватого на разбор причины и системную правку. Иначе система не учится. Это не теория: исследования Эми Эдмондсон и Project Aristotle в Google показывают, что психологическая безопасность - один из ключевых факторов результативности команд [5].

В технологическом контуре это blameless postmortem и RCA. В финансах - внутренний аудит. В операциях - структурированные разборы. Реализация разная, граница одна: за принесённую плохую новость не наказывают, за сокрытую - наказывают всегда.

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

Сильнее всего обычно бьёт правило про независимый источник данных. Когда руководитель функции теряет монополию на интерпретацию своих показателей, он теряет возможность переупаковать их перед бордом. Это ровно те же действия, что перед Коте показали управленцы на первом совещании в Honeywell: продать бизнес ради разового дохода, перетянуть выручку из будущего, сменить метод учёта. Когда источник данных независим, такая упаковка становится намного сложнее.

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

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

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

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

Но чтобы проводить эти правила как защиту, самому нужен мандат от борда. Мандат - это не декларация, что "ИТ важно". Это архитектура прав на решения, "decision rights", без которой все три правила превращаются в пожелания. По данным Gartner (опрос 2024 года) цифровые инициативы достигают целей в 63% случаев, когда CIO работает во франшизной модели - держит общую рамку, а инициативы ведут функции, - и в 43%, когда остаётся оператором внутри своей функции [6]. Разрыв в 20 процентных пунктов - не разрыв в компетенциях, это разрыв в правах на решения.

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

Без мандата CIO продаёт эти правила руководителям функций в одиночку, и его переговорная сила зависит от личного веса в компании. С мандатом - за ним стоит CEO или акционер, и у сопротивления появляется верхний потолок.

Если этих трёх правил нет, всё остальное в управлении ИТ - декорация.

Основной вывод

Компании убивают не конкуренты и не технологии - они начинают умирать, когда решения принимаются на основе красиво упакованной версии реальности.

Внизу знают, что происходит, но наверх уходит безопасная версия: по статусу, бюджету, репутации, квартальному результату. Дальше компания управляет тем, что успели красиво упаковать.

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

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

Для этого у CIO должно быть две опоры:

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

влиять на архитектуру управленческой реальности: единые формулы, единые определения, независимые источники проверки, согласованный поток данных между CIO, CDO и CFO.

Без первого CIO исполняет чужие решения, даже когда видит, что они построены на иллюзии. Без второго CIO, CDO и CFO могут работать с разными версиями одной и той же реальности. Каждый видит свою картину, а компания теряет общий контур управления. Именно поэтому три правила из этой статьи не работают как лозунги. Они работают только как часть управленческой конструкции:

Последний вопрос я оставляю без ответа.

Если завтра вы предложите эти три правила в компании - найдутся ли на борде хотя бы двое, кто встанет рядом с вами в открытую?

Источники

Похожая задача у вас?

Первый разговор - 45 минут. Только вопросы, никаких решений с ходу. К концу я скажу, моя это ситуация или нет.

Обсудить