Акционерное соглашение для девелопменте: что прописать

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

В этой статье — акционерное соглашение для девелопмента с точки зрения практики: что прописать, чтобы документ работал не в момент подписания, а через три года, когда проект войдёт в кризисную стадию. В конце — один пункт, который я рекомендую включать в любое девелоперское SHA вне зависимости от структуры сделки. Большинство юристов его не предлагают.

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

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

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

Прежде чем читать дальше — вспомни, когда последний раз ты открывал SHA своего текущего проекта. Не для подписания. Просто перечитывал. Если не можешь вспомнить — это уже диагноз.

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

Пятый раз за последний год вижу одну и ту же конструкцию в девелоперских SHA: drag-along прописан, оценочная методология — нет. Партнёры думают, что защищены. На деле они создали документ, который при первом же конфликте превратится в предмет судебного спора, а не в инструмент его разрешения.

Следующий вопрос — кто и как управляет проектом на каждой стадии. Это не очевидно даже для опытных девелоперов.

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

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

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

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

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

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

Но управление — это только половина уравнения. Вторая половина — деньги.

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

Waterfall vs. pari passu. Waterfall — это каскадное распределение: сначала возврат вложенных средств, потом предпочтительный доход, потом остаток. Pari passu — пропорциональное распределение с первого рубля. В девелопменте waterfall защищает того партнёра, который вложил больше на ранней стадии — когда риски были выше. Это честно. Но waterfall нужно прописывать детально: каждый уровень каскада, порядок расчёта, что считается «вложенными средствами».

Разговаривал с коллегой — партнёром практики M&A — о том, как waterfall-структура превращается в источник конфликта. Его наблюдение точное: конфликт возникает не из-за самой структуры, а из-за того, что партнёры по-разному понимают, что входит в «возврат вложенных средств». Девелоперский fee управляющего партнёра — это вложение или операционные расходы? SHA должен отвечать на этот вопрос прямо.

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

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

Это самый конфликтогенный раздел любого девелоперского SHA. И самый часто написанный небрежно.

Drag-along в девелопменте. Классический drag-along даёт мажоритарию право продать компанию целиком, «притащив» с собой миноритария. В операционном бизнесе это работает: покупатель получает действующий бизнес. В девелопменте — нюанс. Если объект не достроен, покупатель приобретает не бизнес, а риск. Цена сделки будет другой. SHA должен прописывать: применяется ли drag-along до завершения строительства, и если да — как определяется справедливая цена для миноритария в этом случае.

Оценка доли при выходе. Это главная точка конфликта. Партнёры договариваются о drag-along и tag-along, но не договариваются о методологии оценки. Потом один хочет выйти — и выясняется, что у каждого своя цифра, расходящаяся в два раза.

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

Андрей — партнёр в региональном девелоперском проекте, жилой комплекс на 400 квартир, два акционера с долями 60/40. На стадии котлована — примерно через восемь месяцев после старта — миноритарий заявил о желании выйти. Личные обстоятельства, не связанные с проектом. SHA содержал стандартный drag-along и право выкупа, но не содержал методологии оценки доли на стадии незавершённого строительства.

Партнёры наняли двух независимых оценщиков. Один оценил долю в 47 миллионов рублей, второй — в 89 миллионов. Разница — почти вдвое. Оба оценщика действовали добросовестно, просто применяли разные методологии. Переговоры затянулись на 14 месяцев. Проект стоял.

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

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

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

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

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

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

Не прописали задержку разрешения на строительство. Разрешение на строительство может задержаться на год, два, три. Это меняет всю финансовую модель проекта. SHA должен содержать механизм пересмотра условий при существенном изменении сроков: как пересчитывается девелоперский fee, как меняются условия дополнительного финансирования, есть ли у партнёров право выйти из проекта при задержке сверх согласованного порога.

Ещё одно типичное возражение: «Мы уже работаем, поздно переписывать SHA». Это неправда. SHA можно и нужно обновлять при переходе между стадиями проекта. Подписали на старте — обновите перед началом строительства. Это нормальная практика, а не признак недоверия.

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

SHA — не документ, который подписывают один раз и забывают. В девелопменте это живой инструмент, который должен сопровождать проект на каждой стадии.

Когда подписывать. Идеальный момент — до создания SPV. На этой стадии у партнёров ещё нет активов, которые нужно делить, и нет конфликтов, которые нужно разрешать. Психологически проще договориться о правилах, когда ставки ещё невысоки. Если SPV уже создана, но SHA нет — подписывайте сейчас. Лучше поздно, чем никогда, но помните: чем дальше зашёл проект, тем сложнее договориться о некоторых пунктах.

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

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

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

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

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

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

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

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

[Скачать negotiation framework →]

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

Если нужна работа непосредственно с документом и структурой сделки — работаю с собственниками девелоперских и строительных бизнесов от 80 миллионов выручки. Беру не более 3 новых заявок в неделю. Напиши на hi@vvetrov.com: кто ты, что за проект, в чём вопрос по SHA.

P.S. Если задача не моя — скажу, к кому идти.

Апрель 2026. Автор — Виталий Ветров, стратегический советник для предпринимателей.