Андрей пришёл с вопросом, который звучал просто: «Мне нужно принять одно решение». Через двадцать минут выяснилось, что решений три. Они связаны между собой, и каждое блокирует следующее. Он знал об этом давно — просто не называл это так. Это кейс о том, как управляющий партнёр IT-компании строил фреймворк принятия решений — не в теории, а в условиях, когда цена ошибки уже была понятна.
Андрей управлял IT-компанией больше десяти лет. Не стартап, не корпорация — средний бизнес с устойчивой выручкой, командой в несколько десятков человек и репутацией в своей нише. Компания работала. Не взрывалась, не падала — работала. Именно это и стало проблемой.
Он пришёл на первую сессию с формулировкой, которую явно готовил заранее: нужно решить, что делать с одним из направлений бизнеса — развивать, сворачивать или продавать. Звучало как операционный вопрос. Я попросил рассказать подробнее.
За первые двадцать минут выяснилось следующее. Первое: у него есть партнёр, с которым они расходятся в видении будущего компании — и это расхождение не обсуждалось напрямую уже больше года. Второе: «проблемное направление» — это не отдельный бизнес-юнит, а часть общей операционной модели, и любое решение по нему тянет за собой структурные изменения. Третье: сам Андрей не был уверен, хочет ли он оставаться в роли управляющего партнёра ещё пять лет — или это уже инерция.
Три решения. Не одно.
Он это знал. Просто пришёл с одним — потому что с одним проще. Одно решение можно обсудить, взвесить, делегировать советнику. Три решения — это уже другой разговор. Это про тебя, а не про бизнес.
Я не стал делать вид, что не заметил. Именно здесь начался настоящий разговор — и именно здесь стало понятно, что фреймворк принятия решений для управляющего партнёра в IT-компании — это не таблица с критериями. Это способ думать честно.
Формальный запрос звучал так: помоги структурировать решение по одному из трёх вопросов — тому, который кажется наиболее срочным. Андрей хотел методологию. Матрицу. Набор критериев, по которым можно взвесить варианты и выбрать оптимальный.
Это стандартный запрос. И это почти никогда не настоящий запрос.
За ним, как правило, стоит другое: человек хочет снять с себя ответственность за выбор. Не в плохом смысле — просто когда решение тяжёлое, очень хочется, чтобы его принял «процесс», «фреймворк», «советник». Чтобы потом можно было сказать: «Я следовал методологии». Это нормальная психологическая защита. Но она не работает — потому что методология не несёт последствий. Их несёшь ты.
Управляющие партнёры в IT попадают в эту ловушку особенно часто. Они привыкли к аналитическому мышлению. Они умеют декомпозировать задачи, строить дорожные карты, работать с данными. Это сильная сторона — и одновременно слабое место: когда данных недостаточно или когда решение принципиально не аналитическое, они продолжают искать «правильный фреймворк» вместо того, чтобы признать, что здесь нет правильного ответа. Есть только выбор — и его последствия.
С Андреем мы провели диагностику, прежде чем двигаться к любой методологии. Три вопроса: что произойдёт, если ты не примешь ни одного из этих решений в ближайшие полгода? Что ты уже знаешь, но не хочешь признавать? Какое из трёх решений ты боишься принять больше всего — и почему именно его?
Третий вопрос дал ответ на всё остальное.
Андрей боялся разговора с партнёром. Не решения по направлению бизнеса — оно было технически несложным. Именно партнёрского разговора. И всё остальное — операционные вопросы, стратегические развилки, усталость от роли — было способом этот разговор отложить.
Это важно понять до того, как строить любой фреймворк. Потому что фреймворк, построенный поверх неназванного страха, просто воспроизводит этот страх в структурированном виде.
Когда настоящий вопрос был назван, стало возможным работать с реальной задачей. Мы прошли четыре шага — не быстро, не линейно, с возвратами.
Первый шаг — декомпозиция. Три решения были разложены на составляющие. Не «что делать с направлением», а: что именно нужно решить, кто принимает это решение, в какие сроки, какие ресурсы задействованы, кто ещё является стороной. Оказалось, что одно из трёх решений — не решение Андрея вообще. Оно требовало согласования с партнёром, и без этого согласования любой выбор был бы фиктивным. Это сократило реальную повестку с трёх пунктов до двух.
Второй шаг — разделение обратимых и необратимых решений. Это один из самых недооценённых инструментов в арсенале управляющего партнёра. Большинство решений, которые кажутся необратимыми, — обратимы. И наоборот: некоторые «мелкие» операционные шаги создают факты, которые потом очень трудно отменить. Андрей обнаружил, что решение по направлению бизнеса — обратимое. Его можно принять, проверить гипотезу, скорректировать. А вот разговор с партнёром — необратимый. После него отношения изменятся в любом случае. Это не повод его избегать. Это повод готовиться.
Третий шаг — приоритизация через точку невозврата. Не «что важнее», а «что, если не сделать сейчас, закроет другие возможности». Это другой вопрос. Он даёт другие ответы. Для Андрея точкой невозврата оказался не бизнес-вопрос — а его собственное состояние. Ещё год в режиме «откладываю разговор с партнёром» — и он уйдёт из компании не по решению, а по истощению. Это был честный ответ. Неприятный, но честный.
Четвёртый шаг — определение минимально достаточного решения. Не оптимального. Не идеального. Достаточного — чтобы двигаться дальше. Это важный сдвиг для людей с аналитическим складом: они часто ищут лучшее решение там, где нужно просто принять достаточное и начать действовать.
Андрей сопротивлялся на третьем шаге. Признавать, что бизнес-вопрос — это прокрастинация перед личным разговором, было некомфортно. Он несколько раз возвращался к операционным деталям — цифрам, сценариям, рыночным данным. Я не останавливал его. Просто каждый раз возвращал к третьему вопросу из диагностики: «Какое решение ты боишься принять больше всего?»
В какой-то момент он сказал: «Ладно. Я понял». И мы пошли дальше.
Результат этой работы — компромисс. Не победа. Это важно назвать честно.
Одно решение было принято: по направлению бизнеса. Андрей выбрал сворачивание — не потому что это был оптимальный вариант по всем критериям, а потому что это было достаточное решение, которое освобождало ресурс для более важного. Операционно это дало результат в течение квартала: команда перераспределена, нагрузка снизилась, фокус сместился.
Два других решения были отложены — осознанно. Не потому что их избегали, а потому что для них не было достаточной информации. Разговор с партнёром был запланирован — но не состоялся в рамках нашей работы. Андрей решил готовиться к нему самостоятельно. Вопрос о своей роли в компании на горизонте пяти лет он оставил открытым — и это тоже было решением, просто другого рода.
Что фреймворк дал: структуру мышления, которая позволила разделить три переплетённых вопроса и работать с каждым отдельно. Снижение тревоги — не потому что стало меньше неопределённости, а потому что неопределённость была названа и локализована. Одно конкретное действие вместо трёх заблокированных.
Что фреймворк не дал: ответа на вопрос о партнёре. Ясности насчёт личного будущего. Гарантии, что принятое решение — правильное.
Это нормально. Фреймворк принятия решений — не машина для производства правильных ответов. Это инструмент, который помогает думать честнее. Честность не всегда приятна. Но она лучше, чем иллюзия оптимального выбора, за которой прячется страх.
Это уже четвёртый раз за последние несколько месяцев, когда управляющий партнёр или CEO IT-компании приходит с «одним вопросом», за которым обнаруживается три. Структура почти идентична: операционный запрос как прокси для личного или партнёрского вопроса, который не хочется называть напрямую.
Паттерн выглядит так. Человек с аналитическим складом — а управляющие партнёры в IT почти всегда такие — умеет очень хорошо структурировать бизнес-задачи. Это создаёт иллюзию, что любую задачу можно решить через правильную структуру. Когда задача принципиально не структурная — например, «я не уверен, хочу ли я этого партнёрства» — он всё равно ищет фреймворк. Потому что фреймворк — это знакомая территория. А признание — нет.
Второй кейс, который вспоминается в этом контексте: другой управляющий партнёр, другая IT-компания, похожий запрос. Там исход был другим — разговор с партнёром состоялся быстро, и оказалось, что партнёр думал то же самое, просто тоже молчал. Они договорились за два часа о том, что откладывали два года. Это не значит, что так бывает всегда. Но это значит, что страх перед разговором часто больше самого разговора.
Разница между «не знаю, что выбрать» и «не хочу нести ответственность за выбор» — принципиальная. Первое решается фреймворком. Второе — нет. Второе решается только готовностью признать, что ты уже знаешь ответ. Просто он тебе не нравится.
Фреймворк принятия решений для управляющего партнёра в IT-компании — это не набор инструментов. Это способ добраться до вопроса, который ты уже давно не задаёшь себе вслух.
Это единичный случай или типичная ситуация для IT-компаний?
Типичная — с поправкой на масштаб. Управляющие партнёры в IT чаще других руководителей попадают в ловушку «правильного фреймворка», потому что привыкли решать задачи аналитически. Когда задача не аналитическая — инструмент не работает, но человек продолжает его применять. Это не слабость, это профессиональная деформация.
А если партнёрский конфликт уже открытый — фреймворк всё равно работает?
Работает, но иначе. Когда конфликт открытый, задача фреймворка — не диагностика (она уже есть), а структурирование переговорного процесса: что обсуждается, в каком порядке, какие решения принимаются совместно, какие — раздельно. Это другая работа, ближе к медиации, чем к коучингу.
Что делать, если я вижу у себя похожую структуру — три вопроса вместо одного?
Начать с диагностики: какое из трёх решений вы боитесь принять больше всего — и почему именно его. Ответ на этот вопрос обычно указывает на настоящую задачу. Дальше — либо самостоятельно, либо с кем-то, кто не заинтересован в конкретном исходе.
Андрей пришёл с одним вопросом. Оказалось — три. Одно решение было принято. Два — отложены осознанно. Это не победа. Но это честный результат работы с фреймворком принятия решений, который не обещает правильных ответов — только честные вопросы.
Если этот кейс читается как твоя история — не обязательно идентично, достаточно сходства по структуре — приходи на 20-минутный разбор. Работаю с управляющими партнёрами и CEO IT-компаний с оборотом от 80 миллионов. Беру до 3 заявок в неделю.
hi@vvetrov.com — кто ты, что за бизнес, в чём вопрос.
Если кажется, что у тебя принципиально иначе — возможно, так и есть. Но чаще это не так.
P.S. Андрей написал через полгода. Второе решение он принял самостоятельно. Это хороший знак.
Апрель 2026. Автор — Виталий Ветров, управляющий партнёр юридической фирмы, советник и коуч для CEO и управляющих партнёров.