Техническое задание на административно-бытовой комплекс должно описывать не абстрактное здание, а рабочий день людей. Кто приходит первым, сколько групп одновременно пользуется помещениями, где сотрудники переодеваются, отдыхают и решают административные задачи, что происходит между сменами и какие ограничения есть у площадки — эти сведения полезнее фразы «нужен АБК такой-то площади».
Для северной или удалённой площадки особенно важно не заменять исходные данные словом «северный». Адрес, режим эксплуатации, доступные сети, сезон доставки и порядок обслуживания превращают пожелание в задачу для проектировщика. Конкретные климатические параметры, конструкции и оборудование определяют применительно к объекту; статья не назначает их вместо проекта.
Если у вас уже есть схема, ведомость помещений или описание смен, их можно приложить к заявке на расчёт. Коммерческое направление и состав работ ModulForma описаны на странице модульных АБК и штабов строительства.
1. Сначала опишите работу АБК, а не перечень комнат
Начните с короткого эксплуатационного сценария. Укажите назначение комплекса, кто им пользуется, когда начинается и заканчивается смена, какие действия происходят одновременно и какие функции нельзя смешивать. Такой сценарий помогает понять логику планировки ещё до обсуждения площади.
Например, заказчику полезно описать путь сотрудника: вход на территорию, контроль доступа, переодевание, хранение личной и рабочей одежды, рабочее или административное помещение, перерыв, санитарные зоны, выход после смены. Для посетителя, ИТР, обслуживающего персонала или водителя маршрут может отличаться. В ТЗ фиксируют сам факт различий, а проектировщик предлагает планировочное решение.
Не нужно заранее угадывать каждую площадь. Достаточно отметить, какие функции обязательны, какие желательны и какие можно объединять только после проверки. Это оставляет пространство для проектирования, но не позволяет потерять важный процесс.
2. Зафиксируйте пользователей, смены и пиковые моменты
Численность «всего персонала» часто не показывает реальную нагрузку на АБК. Для первого расчёта важнее максимальное одновременное присутствие и моменты, когда несколько групп пользуются одними зонами.
| Что сообщить | Зачем это нужно | Если данных пока нет |
|---|---|---|
| Категории пользователей | Разделить административные, бытовые и гостевые функции | Перечислить известные группы без чисел |
| Максимальная смена | Понять пиковую загрузку помещений | Дать диапазон и пометить его как предварительный |
| График прихода и ухода | Увидеть одновременные потоки | Описать обычный и наиболее напряжённый сценарий |
| Работа между сменами | Учесть уборку, обслуживание и закрытые зоны | Назначить вопрос ответственному заказчика |
| Посетители и подрядчики | Предусмотреть контролируемый маршрут | Указать, допускаются ли они внутрь основных зон |
Если численность меняется по этапам проекта, покажите этапы отдельно. Не выбирайте одно удобное значение, которое скрывает будущий пик. При этом предварительный диапазон допустим, если он честно обозначен и есть дата его уточнения.
3. Соберите связи помещений без выдуманных площадей
Ведомость помещений становится полезнее, если рядом с названием указана функция и желаемое соседство. Кабинет, раздевалка, сушильная, комната приёма пищи, санитарная или техническая зона требуют разных связей с входами, коридорами и местами обслуживания.
Для каждого помещения или группы помещений запишите:
- кто пользуется зоной и в какое время;
- что должно находиться рядом;
- от каких потоков её нужно отделить;
- нужен ли контролируемый доступ;
- какое оборудование заказчик уже выбрал;
- что должен предложить проектировщик;
- какие входные данные ещё отсутствуют.
Так появляется схема связей, а не случайный список комнат. Она помогает проверить, не пересекаются ли несовместимые маршруты и можно ли обслуживать бытовые и технические зоны без прохода через рабочие кабинеты. Вопросы эвакуации и обязательные требования проверяют профильные специалисты по проекту; отдельный материал объясняет, как проверять маршруты на плане, но не заменяет проектную проверку.
4. Опишите зимние и межсменные режимы как сценарии
Для удалённой площадки одного рабочего режима может быть недостаточно. В ТЗ стоит описать, что происходит во время обычной смены, ночью, в выходной, при плановой паузе и перед повторным запуском. Это не расчёт инженерных систем, а перечень ситуаций, которые проектировщик должен учесть.
Полезные вопросы:
- В каких помещениях люди находятся постоянно, а какие используются кратковременно?
- Какие зоны должны оставаться доступными между сменами?
- Что продолжает работать при отсутствии персонала?
- Кто контролирует состояние здания во время длительной паузы?
- Как заказчик сообщает об аварийном отключении доступных сетей?
- Какие помещения и оборудование требуют отдельного порядка запуска после простоя?
Точные температуры, резервирование, мощности и алгоритмы автоматики нельзя переносить из универсального чек-листа. Их определяют исходные данные площадки, расчёты, проект и согласованный состав поставки. В ТЗ заказчик описывает требуемый результат и известные условия, а не придумывает техническое решение за исполнителя.
5. Разделите доступные вводы и требуемые системы
Фраза «вся инженерия включена» не объясняет, что доступно на площадке и где заканчивается ответственность поставщика здания. Сначала соберите подтверждённые сведения о внешних ресурсах, затем отдельно перечислите функции внутренних систем.
| Блок | Что фиксирует заказчик | Что ожидается в ответе подрядчика |
|---|---|---|
| Электроснабжение | Точка подключения, подтверждённая доступность, ограничения площадки | Принятые исходные данные и вопросы для расчёта |
| Теплоснабжение/отопление | Доступный источник либо отсутствие решения | Предлагаемая граница и данные, которых не хватает |
| Вода и канализация | Точки подключения, режим доступности, ответственная сторона | Схема интерфейсов и перечень уточнений |
| Вентиляция и специальные зоны | Назначение помещений и процессы | Решения после проверки режимов и требований |
| Связь и контроль доступа | Пользовательские сценарии и внешние интерфейсы | Состав системы в пределах предложения |
Если технические условия ещё готовятся, не подменяйте их предположением. Отметьте статус UNKNOWN, укажите владельца вопроса и попросите два варианта ответа: что можно оценить сейчас и что изменится после получения подтверждённых данных.
6. Пометьте каждое исходное данное статусом
Проблема ТЗ часто не в отсутствии сведений, а в том, что пожелание выглядит как утверждённое решение. Простая маркировка делает документ понятнее без сложной системы управления проектом.
Используйте четыре статуса:
- подтверждено заказчиком — факт или принятое требование с ответственным;
- предварительно — рабочее значение, которое нельзя использовать как окончательное без проверки;
- предложить подрядчику — ожидается вариант решения и объяснение его границ;
- неизвестно — параметр пока отсутствует, указан владелец и срок уточнения.
Статус ставят рядом с численностью, версией планировки, составом помещений, доступностью сетей и условиями площадки. Если документ меняется, новая версия должна явно заменять прежнюю. Подробный договорный комплект рассматривается отдельно в материале о документах; здесь достаточно не смешивать утверждённые исходные данные с черновиком.
7. Передайте площадку и логистику как ограничения
Для предварительной проработки АБК приложите схему размещения, известные подъезды, место разгрузки, ограничения пропускного режима и сведения о готовности основания. Если часть информации будет подтверждена позже, укажите это прямо.
Не превращайте статью об АБК в инструкцию по организации монтажа. Для подготовки рабочих зон есть отдельный чек-лист монтажной площадки, а порядок прибытия и установки модулей раскрыт в материале о последовательности монтажа. В ТЗ на АБК достаточно показать ограничения, которые могут повлиять на компоновку, способ поставки и состав предложения.
Для северной или удалённой площадки отдельно сообщите сезон предполагаемой доставки, известные ограничения маршрута, правила допуска и доступность принимающей стороны. Фактическую транспортную и монтажную схему формируют после проверки адреса и проекта.
8. Задайте формат ответа подрядчика именно по АБК
Хорошее ТЗ не только передаёт исходные данные, но и задаёт структуру ответа. Тогда заказчик получает не рекламное описание, а материал, который можно проверить и согласовать.
Попросите подрядчика вернуть:
- перечень принятых исходных данных и явных допущений;
- предварительную компоновку с пояснением маршрутов пользователей;
- ведомость помещений и функций без неподтверждённых «норм от поставщика»;
- состав отделки и инженерных систем в пределах предложения;
- список вопросов, без которых решение остаётся предварительным;
- границы поставки здания и интерфейсы с площадкой;
- исключения, альтернативы и последствия изменений;
- перечень результатов, которые будут переданы для согласования и приёмки.
Цены, сроки и комплектация становятся сопоставимыми только после выравнивания исходных данных. Их нельзя обещать по статье: они фиксируются в коммерческом предложении и договоре применительно к задаче.
9. Определите проверяемый результат до согласования планировки
Приёмку полезно начинать не с финального осмотра, а с вопроса: какой результат должен получить заказчик на каждом шаге. Для ТЗ это может быть согласованная программа помещений; для компоновки — одна актуальная версия с отмеченными потоками; для инженерных разделов — понятные точки подключения и список исходных данных; для поставки — согласованный состав и исключения.
Составьте короткую таблицу контроля:
| Результат | Кто проверяет | Чем подтверждается | Что делать при расхождении |
|---|---|---|---|
| Программа помещений | Представитель заказчика и проектная сторона | Утверждённая ведомость | Вернуть перечень замечаний к одной версии |
| Маршруты пользователей | Ответственный за эксплуатацию | Схема потоков и пояснение | Уточнить конфликтующие сценарии |
| Инженерные интерфейсы | Технические ответственные сторон | Схема точек и границ | Зафиксировать неизвестные данные и владельца |
| Состав предложения | Снабжение и руководитель проекта | Построчная комплектация и исключения | Сопоставить с ТЗ до решения по договору |
Критерии не заменяют строительный контроль или нормативную приёмку. Они помогают не потерять пользовательскую задачу АБК между ТЗ, проектированием и коммерческим предложением.
10. Соберите пакет для первого расчёта
Для старта не обязательно иметь полностью разработанный проект. Полезный пакет может состоять из короткой записки и приложений, если у каждого файла понятны версия и статус.
Перед отправкой проверьте наличие:
- назначения АБК и описания обычного рабочего дня;
- групп пользователей, сменности и максимального одновременного присутствия;
- перечня функций и желаемых связей помещений;
- схемы площадки или честной отметки, что она готовится;
- доступных сведений по внешним сетям;
- зимних, межсменных и аварийных эксплуатационных сценариев;
- ограничений доставки, допуска и разгрузки;
- списка подтверждённых, предварительных и неизвестных параметров;
- контактных лиц по эксплуатации, площадке и техническим вопросам;
- желаемого формата ответа и критериев согласования.
Неизвестные данные не делают заявку бесполезной, если они явно выделены. По ним можно составить перечень уточнений и понять, что требуется от заказчика, проектировщика и поставщика до предметного расчёта.
Отправить исходные данные на проверку
Перейдите на страницу модульных АБК и штабов строительства или откройте форму расчёта и приложите файлы. Передайте назначение комплекса, сценарий смены, известную площадку и текущие версии материалов. Неизвестные параметры можно оставить отдельным списком: они должны стать вопросами для проверки, а не выдуманными характеристиками.
Стоимость, срок, проектные решения и комплектация определяются после проверки исходных данных и закрепляются в предложении и договоре.