Фреймворк принятия решений для сооснователь в IT-компании: для собственника

Михаил пришёл с одним вопросом.

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

Пауза. Потом добавил: «Я уже не понимаю — это проблема нашего бизнеса или проблема нас двоих».

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

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

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

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

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

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

Но до этого понимания нужно было ещё добраться.

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

Я не стал начинать с медиации.

Первый вопрос, который я задал Михаилу на нашей первой встрече: «Когда вы последний раз принимали решение вместе — и оба остались довольны процессом, не только результатом?»

Он думал долго. Потом назвал случай трёхлетней давности. Детали не важны — важно, что с тех пор что-то изменилось. Не в отношениях — в структуре компании. Она выросла. Появились люди, процессы, зависимости. Решения перестали быть простыми. А процесс их принятия остался прежним — интуитивным, неформальным, основанным на доверии и на том, что «мы всегда как-то договаривались».

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

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

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

Вот с чего нужно было начинать.

Фреймворк принятия решений для сооснователя IT-компании — это не таблица и не алгоритм. Это набор договорённостей с самим собой и с партнёром о том, как устроен процесс. Мы строили его в три шага.

Шаг первый: разделение вопросов по горизонту.

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

Мы разделили все вопросы на три горизонта:

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

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

— Экзистенциальный — решения, которые меняют саму природу компании или партнёрства. Продать бизнес. Взять инвестора. Разойтись. Эти требуют отдельного протокола — и отдельного времени.

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

Шаг второй: тест на обратимость.

Для стратегических решений мы ввели один обязательный вопрос перед любым обсуждением: «Это решение обратимо?»

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

Это простой тест. Но он меняет разговор. Вместо «ты хочешь рисковать» и «ты хочешь остановиться» появляется конкретный вопрос: «Если мы ошибёмся — что именно мы потеряем и можем ли мы это восстановить?»

Шаг третий: протокол «стол переговоров с самим собой».

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

Перед каждой совместной сессией с партнёром он проводил 20-минутную сессию с самим собой по фиксированной структуре:

1. Что я хочу от этого решения — для бизнеса? 2. Что я хочу от этого решения — для себя лично? 3. Где эти два ответа совпадают, а где расходятся? 4. Что я готов уступить — и что для меня неприемлемо? 5. Какой результат я назову «достаточно хорошим», если идеального не будет?

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

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

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

Через несколько месяцев работы Михаил описал изменения так: «Мы не стали соглашаться чаще. Мы стали спорить о другом».

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

Что конкретно изменилось:

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

— Стратегические обсуждения стали короче и конкретнее. Не потому что они стали менее сложными — а потому что появился общий язык.

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

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

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

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

Причина почти всегда одна: у них нет фреймворка. Не в смысле «таблицы в Notion» — а в смысле договорённостей о том, как устроен процесс. Кто принимает что. Как оцениваются варианты. Что считается «достаточно хорошим решением».

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

Второй паттерн: сооснователи в IT часто путают «мы не договорились» с «один из нас не прав». Это делает каждое несогласие личным. Фреймворк принятия решений переводит разговор из личного в процессный — и это меняет всё.

Параллельный случай, для масштаба. Другой сооснователь — тоже IT, тоже средний бизнес, тоже партнёрский конфликт — пришёл с похожим запросом, но на полгода позже, чем стоило. За эти полгода один из основателей начал переговоры о выходе. Фреймворк помог — но уже не полностью. Часть опций была закрыта. Это кейс о том, что инструмент работает лучше, когда его применяют до того, как ситуация стала необратимой.

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

Это работает только для IT или для любого бизнеса с двумя основателями?

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

А если партнёр не готов работать с каким-то фреймворком — считает это лишней формализацией?

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

Что делать, если я вижу у себя похожую ситуацию — несколько месяцев не можем принять одно ключевое решение?

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

Михаил в начале нашей работы спросил: «Это проблема нашего бизнеса или проблема нас двоих?»

Ответ оказался третьим: это проблема отсутствия инструмента. Бизнес был в порядке. Отношения — тоже. Не было только договорённости о том, как принимать решения вместе, когда ставки высоки.

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

Работаю с сооснователями и CEO компаний от 80 млн выручки. Беру до 3 новых запросов в месяц.

Напиши на hi@vvetrov.com — кто ты, что за бизнес, в чём вопрос.

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

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