Иллюзия контроля собственник в девелопменте: кейс: для собственника

Михаил показал мне таблицу. Восемнадцать вкладок, цветовая кодировка, автоматические формулы — красный, жёлтый, зелёный по каждому объекту. «Я вижу всё, что происходит», — сказал он без тени сомнения.

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

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

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

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

Система выглядела зрелой. На бумаге она работала.

Первые сигналы появились незаметно. Один проект начал отставать от графика — объяснение нашлось быстро: поставщик подвёл со сроками. Второй проект вышел за бюджет по одной из статей — тоже объяснимо, подорожали материалы. Третий шёл ровно, но Михаил всё реже получал от него обновления — руководитель проекта был «опытным», «не нужно дёргать».

Каждый сигнал в отдельности казался рабочим моментом. Вместе они складывались в картину, которую Михаил не видел — потому что смотрел на таблицу, а не на объекты.

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

Формальный запрос звучал так: «Хочу масштабироваться. Думаю о четвёртом проекте. Нужна стратегия роста».

Это стандартная формулировка для собственника, который чувствует, что что-то не так, но не может назвать это точнее. «Стратегия роста» — безопасный запрос. Он не требует признавать проблему, он звучит как амбиция.

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

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

Михаил знал каждый из этих фактов по отдельности. Он не знал их вместе.

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

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

Реальный вопрос оказался не «как масштабироваться», а «что происходит с тем, что уже есть».

Работа с Михаилом шла несколько месяцев. За это время было три момента, где он мог пойти в разные стороны — и каждый раз выбор давался с сопротивлением.

Первая развилка: признать, что данные устарели.

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

Михаил несколько раз возвращался к защите таблицы: «Данные вносятся регулярно», «Руководители проектов несут ответственность за точность». Это было правдой — формально. Неправдой было то, что «регулярно» и «точно» не означало «полно» и «своевременно».

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

После этого звонка разговор изменился.

Вторая развилка: разговоры с людьми, а не с отчётами.

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

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

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

Третья развилка: заморозить один из трёх проектов.

Это была самая болезненная точка.

Третий объект — тот, где зависло согласование — требовал либо немедленного включения Михаила лично, либо честного признания, что ресурса на три проекта одновременно нет. Михаил несколько недель откладывал решение, пробуя найти промежуточный вариант: делегировать больше, нанять ещё одного координатора, «поднажать».

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

Михаил принял это решение. Но принял его как поражение, а не как управленческий выбор. Это различие важно — и к нему я вернусь в финале.

Через несколько месяцев работы картина выглядела так.

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

Второй объект закрыл перерасход частично. Часть статей удалось оптимизировать, часть пришлось принять как потери. Финансовый итог — не катастрофа, но и не то, что планировалось. Михаил получил опыт, который стоил денег.

Третий объект остался заморожен. Возможно, он будет разморожен позже — когда высвободится ресурс. Возможно, нет.

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

Главный результат был не финансовым. Михаил изменил модель управления — не радикально, но существенно. Он стал чаще бывать на объектах. Ввёл практику прямых разговоров без посредников. Начал задавать вопросы иначе: не «как идут дела», а «что тебя сейчас беспокоит».

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

Компромисс — это не победа и не поражение. Это точка, где реальность и намерения нашли друг друга.

Четвёртый раз за последний год я вижу одну и ту же структуру у собственников в девелопменте и смежных отраслях с физическими объектами — строительство, производство, логистика с собственной инфраструктурой.

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

Чем сложнее система отчётности — тем больше иллюзия полноты картины. Восемнадцать вкладок создают ощущение, что ты видишь всё. Именно это ощущение и опасно.

Три признака, по которым иллюзию контроля можно опознать у себя:

Первый. Ты давно не получал по-настоящему плохих новостей. Не потому что всё хорошо — а потому что система не пропускает их наверх в полный голос. Если последние несколько месяцев все проблемы «решались сами» или «были небольшими» — это сигнал.

Второй. Ты знаешь цифры, но не знаешь людей. Ты можешь назвать процент выполнения плана по каждому объекту, но не можешь сказать, что сейчас беспокоит прораба на первом объекте. Данные и понимание — разные вещи.

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

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

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

Здесь обычно возникает возражение: «Это специфика девелопмента, у меня другое». Возможно. Но иллюзия контроля как когнитивное искажение не привязана к отрасли — она привязана к структуре: собственник, делегирование, система отчётности, физическая или операционная дистанция от реальности. Если эта структура есть — искажение возможно. О том, как оно проявляется в других контекстах, я писал в кейсе про управляющего партнёра в B2B-услугах и в разборе про confirmation bias у CEO. Структура та же, детали разные.

Подробнее о том, как иллюзия контроля соотносится с другими когнитивными ловушками предпринимателя — в обзорном материале по теме.

Это единичный случай или типичная история для девелопмента?

Типичная — с вариациями. Физическая дистанция между собственником и объектом создаёт структурные условия для иллюзии контроля. Чем больше объектов и чем сложнее система отчётности — тем выше риск. Я видел эту структуру у собственников с одним объектом и с десятью. Масштаб меняет цену ошибки, не её природу.

А если у меня хорошая команда и я им доверяю — это меняет картину?

Доверие к команде и иллюзия контроля — не противоположности. Михаил доверял своим руководителям проектов. Проблема была не в людях — в системе, которая не требовала от них говорить неудобную правду в полный голос. Хорошие люди в плохо настроенной системе дают предсказуемый результат.

Что делать, если я узнаю у себя эти признаки?

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

Не обязательно в деталях. Достаточно в структуре: ты выстроил систему управления, она работает — но ты давно не получал по-настоящему неудобных новостей, и это тебя не беспокоит.

Работаю с собственниками бизнесов от 80 миллионов выручки. Беру не больше двух advisory-запросов в месяц — это не маркетинговый приём, это реальное ограничение формата.

Если хочешь разобраться, что происходит на самом деле: hi@vvetrov.com — кто ты, что за бизнес, в чём вопрос. Одним абзацем.

P.S. Михаил до сих пор пользуется таблицей с восемнадцатью вкладками. Но теперь он знает, что это инструмент — а не окно в реальность.

Апрель 2026. Автор — Виталий Ветров, стратегический советник и практикующий юрист.