Что нужно знать до начала
Это редакционный материал по формату работы, а не юридическая консультация. Места про 152-ФЗ, локализацию персональных данных и автоматизированные решения — практические ориентиры, конкретику сверяйте с действующей редакцией законодательства и квалифицированным юристом.
Цифры из исследований (Standish CHAOS, McKinsey/Oxford) даны как порядок величины и опубликованный консенсус, не как точная статистика конкретного проекта или подрядчика. Иллюстративные суммы — иллюстративные.
Когда проект идёт не так, в разборе полётов обычно винят код. Настоящая причина лежит раньше и тише: команда начала писать код до того, как кто-либо точно определил — что строим, как части соединяются и что не должно сломаться никогда. Этот разрыв — отсутствие осознанно зафиксированного scope и архитектуры до кода — самая дорогая ошибка в разработке. Архитектурный спринт за 5 дней существует, чтобы её предотвратить. Ниже — что это за формат, как устроены пять дней, что вы получаете на выходе и, не менее важно, когда его делать не нужно.
01 · Почему проекты чаще проваливаются на scope, а не на коде
Статистика отрезвляющая и на удивление устойчивая. Широко цитируемое (и, справедливости ради, местами критикуемое) исследование Standish Group CHAOS из года в год показывает: полностью успешны примерно треть проектов (около 31% в данных 2020 года), около половины — «проблемны» (срыв сроков, бюджета или урезанный объём), остальные провалены. Вывод о причинах успеха повторяется неизменно и называет три фактора: вовлечённость пользователей, поддержка руководства и чёткая формулировка требований. Требования и scope, а не технологии, стоят на вершине списка. Project Management Institute отдельно указывает на размытый изначальный scope как на источник «расползания требований» (scope creep), который и пускает проекты под откос.
Размер — второй мощный предиктор: маленькие, чётко ограниченные проекты успешны примерно в 90% случаев, крупные — менее чем в 10% (те же данные CHAOS). А цена ошибки на крупных проектах беспощадна: исследование McKinsey совместно с Оксфордским университетом показало, что большие ИТ-проекты в среднем превышают бюджет на ~45% и при этом приносят на ~56% меньше ценности, чем планировалось, а каждый дополнительный год добавляет около 15% к перерасходу. Standish даже измерил цену нерешительности: команды с высокой «задержкой решений» успешны лишь в ~18% случаев против 63% у тех, кто решает быстро.
Сложите это вместе — и вывод один: технические проблемы обычно симптом; болезнь — это scope и поздно принятые решения. Дорогие ошибки — это не плохие функции, а неверно выбранная модель мультитенантности по умолчанию, схема авторизации, которую приходится переделывать на пятидесятом клиенте, структура данных, из-за которой удаление по 152-ФЗ превращается в переписывание. Это не «баги». Это решения, которые никто не принимал осознанно, и переделка любого из них после запуска легко обходится в миллионы рублей — между временем разработчиков, потерянным темпом и сорванными сделками. Сумма иллюстративна, принцип — нет: чем позже исправляется структурное решение, тем дороже это стоит.
02 · Что такое архитектурный спринт
Архитектурный спринт — это неделя с фиксированным объёмом и фиксированной ценой, на выходе которой — решения и план, а не продакшен-код. Если Design Sprint от Google Ventures — это пятидневный метод проверки продуктовой идеи до того, как её строить, то архитектурный спринт — его инженерный аналог: scope до кода, отвечающий на вопрос «можно ли это построить хорошо и как именно» прежде, чем разработка вас к чему-либо привяжет. Это проектирование SaaS до разработки, которое выносит вперёд решения, дешёвые сейчас и разорительные потом.
Это не «большой дизайн заранее» и не 200-страничное ТЗ. Это ровно столько архитектуры, чтобы следующие три–шесть месяцев разработки шли безопасно и быстро: чёткие границы, проверенный стек, размеченные процессы, честный реестр рисков и приоритизированный roadmap. Пять дней, фиксированная цена и небольшой набор артефактов, которые принадлежат вам и которые можно отдать любой команде.
03 · Структура: что делаем каждый день
День 1 — контекст, ограничения и реальная цель. До любых схем мы фиксируем ограничения, которые на самом деле формируют архитектуру: кто пользователи, что бизнес должен делать ежедневно, регуляторная среда (для РФ — 152-ФЗ и локализация данных, см. ниже), рынок найма, обязательные интеграции, бюджет и сроки. Большинство архитектурных ошибок — на самом деле ошибки в ограничениях: «лучшая практика», применённая в неверном контексте.
День 2 — разметка процессов и ролей. Здесь продукт превращается в систему на бумаге: моделируем ключевые процессы сквозь, чтобы найти естественные границы между компонентами. Подробнее ниже.
День 3 — выбор стека и ключевые решения по данным. Когда процессы размечены, осознанно принимаются структурные решения: модель мультитенантности, модель данных, границы API и сам стек — проверенные по критериям, а не выбранные по привычке.
День 4 — анализ рисков. Структурированный поиск того, что может пойти не так, до того как пошло: масштабирование, безопасность, соответствие 152-ФЗ, зависимость от поставщика и от конкретных людей. Это день, который тише всего предотвращает дорогой сюрприз.
День 5 — синтез. Всё превращается в результаты: приоритизированный roadmap, Architecture Decision Records (ADR), фиксирующие каждое значимое решение и почему, и технические оценки (смета), под которые команда может планировать и закладывать бюджет.
Неделя намеренно короткая: как подсказывают данные Standish про «задержку решений», быстрые и обоснованные решения побеждают медленные и идеальные, а жёсткий тайм-бокс заставляет разговор сойтись к решениям, которые действительно важны.
04 · Разметка процессов и ролей
Разметка на втором дне опирается на две устоявшиеся техники. Event storming — моделирование системы как последовательности доменных событий («заказ создан», «арендатор подключён», «счёт выставлен»), а не экранов или таблиц — вскрывает реальный бизнес-процесс и, что важнее, места, где одна часть системы заканчивается и начинается другая. Story mapping (метод Джеффа Паттона) удерживает в фокусе путь пользователя, чтобы архитектура обслуживала реальный процесс, а не абстрактную модель данных.
Результат — не красивая схема ради схемы, а выделение ограниченных контекстов (bounded contexts): швов, по которым систему можно разделить на части, меняющиеся независимо. Именно эти швы потом позволяют добавлять функции, не задевая всё подряд, — разница между системой, которая остаётся быстрой, и той, что костенеет.
05 · Выбор стека с обоснованием
Решение по стеку на третьем дне — место, где команды чаще всего скатываются к моде, и где спринт настаивает на соответствии. Критерии намеренно скучные:
- Рынок найма — можно ли реально нанять под этот стек? Технически изящный выбор, под который некого нанять, — это скрытый риск «ключевого человека» в момент, когда первый разработчик уходит.
- Интеграции — чисто ли он соединяется с системами, которые уже используют ваши клиенты (1С, эквайринг, госсистемы)?
- Профиль нагрузки — соответствует ли реальной форме нагрузки (интерактивная продуктовая аналитика ведёт себя совсем не как пакетная отчётность)?
- Соответствие требованиям — можно ли его эксплуатировать так, чтобы выполнять 152-ФЗ, локализацию данных и требования к аудиту?
- Эксплуатационная ответственность — кто будет запускать, мониторить и защищать это, и реально ли это для команды такого размера?
«Лучший» стек — тот, что хорошо проходит по вашим ограничениям, а не тот, что в тренде в этом квартале.
06 · Анализ рисков
Четвёртый день — это что-то близкое к pre-mortem (представьте, что проект провалился — почему?) в сочетании со структурированным разбором рисков по фиксированным категориям. Для российского SaaS они надёжно включают:
- Масштабирование и отказоустойчивость — где это ломается под нагрузкой и что должно деградировать плавно, а не падать целиком?
- Безопасность — управление секретами, контроль доступа, изоляция арендаторов с первого дня.
- Персональные данные и 152-ФЗ — и здесь для РФ архитектура и есть позиция по комплаенсу. Закон «О персональных данных» (152-ФЗ) и требование локализации (242-ФЗ) означают, что персональные данные российских пользователей нужно собирать, хранить и обрабатывать на серверах в России — и это решение принимается сейчас, на этапе архитектуры, а не дорабатывается потом. Ставки заметно выросли: с 30 мая 2025 года штрафы ужесточены — за обработку без согласия до 300 тыс./1,5 млн ₽, за утечку — до 15 млн ₽, за повторные серьёзные утечки введены оборотные штрафы до 3% годовой выручки или до 500 млн ₽, за неуведомление Роскомнадзора — 1–3 млн ₽, плюс добавлена уголовная ответственность (421-ФЗ). Отдельный архитектурный нюанс: автоматизированные решения со значимыми последствиями для человека (скоринг, отбор, одобрение заявок) требуют уведомления субъекта и возможности оспорить — это закладывается в дизайн, а не прикручивается позже. Это практический разбор, не юридическая консультация; конкретику сверяйте с действующей редакцией и юристом.
- Зависимость от поставщика и ключевых людей — lock-in на одном вендоре в ядре и поведение, держащееся на недокументированном знании одного человека.
Назвать эти риски на первой неделе, пока они дёшевы в обходе, — и есть весь экономический смысл спринта.
07 · Что на выходе: документ + roadmap + смета
Вы уходите с тремя артефактами, которые принадлежат вам:
- Приоритизированный roadmap — что строить и в каком порядке, с явными зависимостями и решениями, которые гейтируют каждый этап.
- Architecture Decision Records (ADR) — короткие живучие документы (формат, который ввёл Майкл Найгард), фиксирующие каждое значимое решение, рассмотренные варианты и почему выбран один. ADR — это то, что позволяет новому разработчику (или команде due diligence при сделке) через год понять логику системы без «археологии».
- Технические оценки (смета) — достаточно обоснованные, чтобы планировать и закладывать бюджет, с заранее учтёнными рисками, а не обнаруженными в середине разработки.
Ни один из этих артефактов не привязывает вас к разработке именно с нами. Они намеренно нейтральны к стеку и к команде — смысл в обоснованном плане, а не в зависимости.
08 · Пример: трёхролевой маркетплейс
Возьмём частый случай: основатель с идеей маркетплейса, связывающего три роли — скажем, покупателей, поставщиков и внутреннюю операционную команду — у каждой свои права, видимость данных и процессы.
На входе «очевидное» решение — одно приложение с флагами ролей. Разметка процессов на втором дне быстро показывает, что у трёх ролей по-настоящему разные жизненные циклы и правила доступа, и это вскрывает реальные архитектурные вопросы: как изолируются три роли, где живёт модель прав, как данные поставщика остаются невидимыми для покупателя.
Выбор стека взвешивает модель тенантности и авторизации против реальности найма и требования локализации данных по 152-ФЗ. Анализ рисков подсвечивает экспозицию персональных данных при кросс-ролевом доступе и вопрос уведомлений, если операционная роль ведёт мониторинг.
К пятнице у основателя есть roadmap, который строит модель прав и изоляции первой (потому что её ретрофит — это та самая переделка на миллионы), ADR с объяснением решений по тенантности и авторизации, и смета, по которой может работать разработчик или студия — вместо того чтобы обнаружить проблему изоляции после запуска, перед первым корпоративным клиентом.
09 · Стоимость
Архитектурный спринт стоит от 150 000 ₽ — намеренно фиксированный объём и цена, потому что вся философия в том, что определённый scope побеждает открытую неопределённость. На фоне исследований выше (крупные проекты с перерасходом ~45% и недополученной ценностью ~56%) фиксированная неделя, снимающая риск с разработки, — одна из самых дешёвых страховок, которую может купить ИТ-проект. Это и причина, по которой спринт работает как самостоятельный первый шаг: вы получаете план и артефакты вне зависимости от того, продолжите ли разработку с нами.
10 · Когда спринт НЕ нужен
Честность здесь — часть метода. Архитектурный спринт — неверный инструмент в нескольких реальных ситуациях:
- Вы строите настоящий одноразовый прототип. Если цель — проверить гипотезу, которую вы заведомо выбросите, осознанная архитектура — это переинвестирование. Сделайте спайк, поучитесь, потом фиксируйте scope.
- Ваша проблема — продуктовая, а не архитектурная. Если вы ещё не знаете, что строить и нужно ли это кому-то, вам нужен продуктовый Design Sprint или customer discovery; архитектура отвечает на «как построить хорошо», а не «должно ли это существовать».
- Требования всё ещё сильно нестабильны. Если ядро идеи меняется каждую неделю, фиксировать архитектуру преждевременно — сначала стабилизируйте концепцию.
- У вас уже есть сильный архитектор и ясный план. Если решения действительно приняты и задокументированы, незачем принимать их заново.
Если что-то из этого про вас — спринт будет полировкой не того. И сказать об этом — часть честного подхода к scope.
Коротко
Проекты проваливаются не потому, что кто-то плохо написал код. Они проваливаются потому, что дорогие решения приняты по умолчанию, поздно и незаметно. Архитектурный спринт за 5 дней выносит эти решения вперёд, где они дёшевы, — превращая «scope до кода» из лозунга в определённую неделю с roadmap, ADR и сметой на выходе. Если вы вот-вот вложите месяцы разработки в идею, неделя осознанного проектирования — самое высокорычажное время, которое можно потратить.
Частые вопросы
Чем это отличается от обычного ТЗ? ТЗ перечисляет функции; архитектурный спринт принимает и документирует решения — модель тенантности, границы данных, соответствие стека, меры против рисков — и объясняет почему. На выходе обоснованный план с ADR, а не список фич, и он заземлён на реальные ограничения (152-ФЗ, найм, интеграции).
Спринт привязывает меня к разработке у вас? Нет. Результаты нейтральны к стеку и команде — roadmap, ADR и смета принадлежат вам и могут быть переданы любому разработчику или студии. Смысл — снять риск с вашей разработки, а не создать зависимость.
Почему scope предотвращает дорогие ошибки? Потому что структурные решения дорожают экспоненциально после старта разработки. Исследования (Standish, McKinsey/Oxford) устойчиво показывают: причина провалов и перерасходов — scope и требования, а не код. Поймать неверную модель тенантности или авторизации в неделю планирования, а не после запуска, — это разница между разговором и переписыванием.
Подходит ли спринт для проектов с персональными данными по 152-ФЗ? Да, он на это и рассчитан. Соответствие проектируется как архитектура: локализация данных, модель согласий и уведомлений, обработка автоматизированных решений. Это практический разбор, а не юридическая консультация, и он хорошо работает в связке с юристом.
Это редакционный материал по формату работы, а не юридическая консультация. Вопросы по 152-ФЗ, локализации и автоматизированным решениям сверяйте с действующей редакцией закона и квалифицированным юристом.