Завдання на проєктування: вихідні дані та кошторис

Нормативна й практична межа: вимоги замовника, а не універсальний шаблон

Закон України № 687-XIV «Про архітектурну діяльність» визначає завдання на проєктування як документ з обґрунтованими в межах законодавства вимогами замовника до планувальних, архітектурних, інженерних і технологічних рішень, властивостей об’єкта, його основних параметрів, вартості та організації будівництва. Це визначення окреслює призначення документа, але саме по собі не встановлює однакової форми для кожного об’єкта. У межах цієї статті кошторисник не призначає технічні рішення.

Чинний Порядок розроблення проєктної документації, затверджений наказом № 45, називає основними складовими вихідних даних містобудівні умови та обмеження, технічні умови й завдання на проєктування. Порядок також установлює, що завдання складають з урахуванням вимог ДБН А.2.2-3:2014; його затверджує замовник за погодженням із генпроєктувальником (проєктувальником). Завдання може створюватися як електронний документ із накладенням передбачених Порядком електронних підписів, а його примірник завантажує генпроєктувальник (проєктувальник) через електронний кабінет до Реєстру будівельної діяльності з накладенням електронних підписів відповідальних осіб, які його підписували. Ці положення описані лише для розуміння джерела й статусу документа; стаття не є інструкцією щодо реєстраційних дій.

Водночас офіційна сторінка ЄДЕССБ для ДБН А.2.2-3:2014 у редакції від 30 квітня 2026 року позначає запис як архівний, тоді як чинна редакція Порядку № 45 продовжує прямо посилатися на цей ДБН. Через цю розбіжність стаття не відтворює поля додатка як чинний шаблон і не робить висновку про застосовність норми до конкретного проєкту. Замовник і відповідальний проєктувальник мають перевірити актуальні застосовні вимоги для свого об’єкта. Тут використовуються лише процесні положення чинного Порядку № 45 та практичні рекомендації з кошторисної простежуваності.

Містобудівні умови та обмеження й технічні умови залишаються окремими складовими вихідних даних. Тут не пояснюється їхній зміст, порядок отримання або застосування. Так само поза межами сторінки залишаються дозволи, легалізація робіт, експертиза, затвердження проєкту, вибір проєктувальника та визначення вартості його послуг.

Як перевести вимоги замовника в перевірювану структуру

Кошторисна готовність починається не з максимальної деталізації, а з однозначності. Кожна вимога має бути прив’язана до зони, системи або результату, мати джерело й статус, а також передбачати документ, за яким можна буде перевірити її виконання в проєкті. Вимоги різного рівня не варто змішувати в одному реченні: функціональну потребу, технічне рішення, комерційне обмеження й організаційну умову краще фіксувати окремо.

• Мета об’єкта або зміни. Яку потребу замовника має забезпечити проєкт і який результат не входить до цієї роботи.
• Фізична межа. Будівля, черга, секція, поверх, приміщення, мережа, ділянка чи інша частина, до якої належить вимога.
• Функціональний результат. Що має бути можливим після реалізації без підміни результату конкретним непогодженим рішенням.
• Вихідний стан. Які обміри, обстеження, виконавчі матеріали або дані існуючих систем передані та ким підтверджені.
• Обмеження. Габарити, доступ, режим роботи, черговість, суміжні об’єкти й інші документовані умови, що впливають на рішення.
• Інтерфейси. Де проходить межа між розділами, постачальниками, підрядниками, існуючими та новими системами.
• Очікувані документи. Яке креслення, специфікація, відомість, розрахунок або погоджене рішення підтвердить виконання вимоги.
• Критерій перевірки. Як замовник і проєктувальник зрозуміють, що результат відповідає завданню, без вигаданих кошторисником показників.
• Пріоритет і залежності. Яка вимога є базовою, яка залежить від уточнення та що зміниться після нового рішення.
• Власник рішення. Хто надає дані, хто готує рішення, хто погоджує зміну і хто отримує запит про суперечність.

Корисний робочий запис має формат «ідентифікатор вимоги — формулювання — зона — джерело — відповідальний — очікуваний доказ — статус — пов’язані рішення». Ідентифікатор дає змогу простежити вимогу в протоколі, кресленні, специфікації й кошторисному коментарі. Це особливо важливо, коли одна вимога впливає на кілька розділів або на межу між обладнанням і будівельними роботами.

Фраза «передбачити все необхідне» приховує ризик. Замість неї варто описати очікуваний результат і перелік відомих інтерфейсів, а невідомі питання винести в реєстр уточнень. Кошторис не повинен створювати удавану повноту через загальний резерв, якщо склад робіт ще не визначений відповідальним учасником.

Вихідні дані: як відрізнити наявність файла від готовності до розрахунку

Назва файла в переліку ще не доводить його придатність. Для кожного джерела потрібні автор, дата, ревізія, статус, охоплена зона та зв’язок з іншими документами. Попередня схема, робочий обмір і затверджена вихідна інформація мають різну вагу. Якщо два джерела суперечать одне одному, кошторисник не вибирає зручніше, а фіксує розбіжність.

• Реєстр вихідних даних. Містить назву, шифр, дату, ревізію, статус, автора, одержувача й зону застосування кожного документа.
• Дані про існуючий стан. Обміри, обстеження, виконавчі схеми, технічні звіти та фото мають відомого укладача й межу достовірності.
• Вихідні вимоги замовника. Зафіксовано, які вимоги погоджені, які уточнюються, а які замінено новою редакцією.
• Суміжні умови. Відомі точки підключення, межі відповідальності, обмеження експлуатації та залежності від інших рішень.
• Базові кількісні дані. Площі, довжини, потужності, кількість приміщень або обладнання мають конкретне джерело, одиницю й ревізію.
• Перелік невідомого. Для кожної прогалини визначено, хто й коли має надати відповідь та які рішення або суми від неї залежать.
• Протоколи рішень. Усні домовленості перенесено в датований запис із відповідальними та переліком змінених документів.
• Комерційна межа. Позначено, що надає замовник, що входить до проєктних робіт і які дані очікуються від виробника чи підрядника.

Для ранньої оцінки можна підготувати сценарний розрахунок, але його не можна видавати за остаточний кошторис. У сценарії окремо показують підтверджені величини, припущення, діапазони, виключені роботи й тригери перерахунку. Коли надходить новий документ, змінюють лише залежні позиції та зберігають історію, чому змінилася сума.

Технічна повнота й кошторисна готовність не тотожні. Проєктувальник визначає достатність даних для своїх рішень; кошторисник перевіряє, чи можна простежити номенклатуру, обсяг, одиницю, межу робіт і цінову базу. UkrSmeta не підтверджує технічну придатність вихідних даних, а показує, де їхня невизначеність впливає на розрахунок.

Вісім кроків контролю версій і змін до завдання

Завдання розвивається разом з уточненням об’єкта, але кожна зміна повинна мати контрольований наслідок. Послідовність нижче є практикою керування кошторисними залежностями, а не нормативною процедурою затвердження документа.

1. Зафіксувати базову редакцію. Записати номер, дату, статус, підписантів і перелік додатків, на яких побудовано поточний розрахунок.
2. Ідентифікувати зміну. Описати, яка вимога додана, вилучена, уточнена або перенесена до іншої межі.
3. Визначити причину. Послатися на нові вихідні дані, рішення замовника, координаційну відповідь або інший датований документ.
4. Побудувати карту впливу. Позначити розділи, креслення, специфікації, обсяги, пропозиції й кошторисні рядки, які потребують перевірки.
5. Призначити відповідальних. Відокремити автора технічного рішення від особи, яка оновлює кількість, ціну або договірну межу.
6. Оновити пов’язані документи. Не змішувати нове завдання зі старою специфікацією або нове креслення зі старою відомістю обсягів.
7. Перерахувати тільки залежне. Зберегти базу порівняння, пояснення зміни кількості та дату цінових джерел.
8. Закрити або перенести питання. Зафіксувати рішення, залишкову невизначеність і умову наступного перегляду перед випуском кошторису.

Особливо небезпечні зміни без номера редакції: лист, позначка на PDF, повідомлення в месенджері або усне уточнення можуть змінити одну систему, але не потрапити до суміжних розділів. Реєстр змін повинен показувати не лише текст правки, а й документи, які вже приведені у відповідність.

Замороження версії для розрахунку не означає, що проєкт більше не змінюється. Воно означає, що підсумок має чітку дату й основу. Наступна редакція оформлюється як контрольоване порівняння, а не як непомітна заміна чисел у старому файлі.

Від завдання до специфікацій і обсягів: що має залишатися простежуваним

Завдання формулює потребу й обмеження, а проєктувальник перетворює їх на рішення. Для кошторису важливо не перестрибнути цей етап. Номенклатура та кількість мають походити з погоджених креслень, специфікацій, відомостей або розрахунків, а не безпосередньо з загальної фрази замовника.

• Система й зона. Кожна позиція має бути віднесена до конкретного розділу, приміщення, ділянки, черги або вузла.
• Ідентифікатор вимоги. За можливості показує, яку потребу замовника реалізує рішення та чому позиція входить до межі.
• Марка або опис. Використовується рівень визначеності, який реально містить чинний документ, без вигаданого виробника чи моделі.
• Кількість і одиниця. Відповідають кресленню або відомості, мають правило округлення та не змішують чистий обсяг із замовним.
• Комплектність. Основний ресурс, комплектуючі, кріплення, керування, пускові елементи й документація розмежовані без дублювання.
• Будівельні інтерфейси. Отвори, основи, підведення, оздоблення, тимчасові роботи й відновлення мають визначеного виконавця.
• Монтаж і випробування. Враховуються лише за погодженим складом робіт, документами та договірною межею, без універсальної технології.
• Невирішені аналоги. Альтернативний ресурс залишається позначеним як аналог до документованого рішення відповідального учасника.

Для кожної нетипової позиції корисно зберігати маршрут «вимога — рішення — документ — кількість — ресурс — робота — ціна». Якщо змінюється вимога, карта показує залежні рядки. Якщо змінюється лише постачальник, технічну відповідність і комплектність перевіряють окремо, не переписуючи вихідну вимогу під дешевшу пропозицію.

Відсоток «на невраховані роботи» не лікує невизначені межі. Краще створити окремий реєстр питань із потенційно залежними ресурсами та сценаріями. Це не робить суму остаточною, але дає замовнику зрозуміти, що вже підтверджено, що оцінено умовно і яке рішення змінить бюджет.

Дванадцять контрольних рядків кошторисної готовності завдання

Таблиця є робочою картою, а не нормативним додатком і не універсальним обов’язковим переліком. Для конкретного об’єкта рядки деталізують, об’єднують або не застосовують за рішенням відповідальних учасників. Її мета — показати, чи має кожна вартісна група простежуване джерело.

Під час складання кошторису на будівництво ця карта допомагає відокремити підтверджені обсяги від попередніх, а прямі ресурси — від інтерфейсів та організації робіт. Для кожного рядка зберігають код джерела й коментар до межі. Після нової редакції завдання можна перевірити, які суми справді потребують оновлення.

Якщо кошторис складається ще до завершення проєктних рішень, підсумок подають за сценаріями або з реєстром припущень. Дата цін, рівень визначеності та невраховані групи мають бути видимими. Формулювання завдання не є самостійним доказом кількості, якщо її повинен визначити подальший проєктний документ.

Вартісні межі: бюджет об’єкта не дорівнює ціні проєктних послуг

Вимога до вартості в завданні може задавати бюджетний орієнтир, обмеження або порядок порівняння варіантів. Вона не створює автоматично підтверджену вартість будівництва й не замінює кошторис. Так само ця сторінка не розраховує ціну проєктних робіт і не пояснює склад відповідної договірної ціни.

• База бюджету. Дата, валюта, податки, рівень цін і перелік включених частин об’єкта мають бути названі.
• Межа витрат. Проєктування, будівельні роботи, обладнання, доставка, пуск, резерви й інші групи не змішують без пояснення.
• Рівень визначеності. Концептуальна оцінка, сценарний бюджет і кошторис за робочими документами мають різну доказовість.
• Варіанти. Порівнюють однаковий функціональний результат, комплектність, строк даних і договірну межу.
• Цінові джерела. Фіксують постачальника, дату, регіон, одиницю, валюту, ПДВ, доставку, монтаж і строк дії.
• Аналоги. Технічну альтернативу не визнають погодженою лише через нижчу ціну; потрібне рішення уповноваженого учасника.
• Зміни бюджету. Показують зв’язок із новою вимогою, обсягом, специфікацією, ціною або межею, а не лише різницю підсумків.

Чинна Настанова з визначення вартості проєктних, науково-проєктних, вишукувальних робіт та експертизи проєктної документації на будівництво, затверджена наказом № 281, застосовується для визначення вартості відповідних робіт у межах своєї сфери. Вона не дає універсальної ціни складання завдання, не встановлює готовий відсоток для будь-якого об’єкта й не підмінює договірне визначення фактичної послуги. У цій статті джерело згадується лише для чіткого відмежування ціни проєктних робіт від кошторисної готовності вимог.

Для перевірки будівельного кошторису пропозиції приводять до єдиної технічної й комерційної бази. Якщо різниця виникає через різну комплектність або відсутню роботу, це може означати іншу межу порівняння, а не підтверджену економію. Невідомі характеристики й непогоджені аналоги залишають видимими.

Типові ризики та межі перевірки UkrSmeta

• Побажання видано за вимогу. Немає зони, критерію, джерела, відповідального й очікуваного проєктного доказу.
• Рішення записано передчасно. Завдання фіксує модель або технологію без належного проєктного обґрунтування та погодження.
• Змішані редакції. Завдання оновлено, але креслення, специфікації, обсяги й кошторис належать до різних версій.
• Не визначені інтерфейси. Постачання, монтаж, підключення, отвори, оздоблення або пуск не мають одного відповідального.
• Кількість взято з текстової вимоги. Відсутній маршрут через погоджене рішення, креслення чи відомість.
• Комплектність прихована в ціні. Основний ресурс, комплектуючі, доставка, монтаж і документація не розмежовані.
• Умовний бюджет названо остаточним. Припущення, прогалини, дата цін і тригери перерахунку не показані.
• Кошторисник підмінив відповідального учасника. Самостійно визначив технічний параметр, нормативну застосовність або дозвільний порядок.

На кошторисну готовність найбільше впливають якість реєстру вихідних даних, однозначність меж, зрілість проєктних рішень, синхронність креслень і специфікацій, наявність інтерфейсної матриці, контроль версій, прозорість припущень та порівнюваність цін. Жоден з цих факторів не перетворюється на універсальний відсоток готовності або гарантовану точність суми.

UkrSmeta може виконати перевірку кошторису: зіставити вимоги з переданими документами, простежити джерела кількостей, знайти пропущені межі, дублювання, різні редакції, непорівнювані пропозиції та приховані припущення. Ми не погоджуємо завдання, не визначаємо достатність проєктних рішень, не виконуємо обміри чи обстеження, не призначаємо характеристики, не розробляємо проєкт і не підтверджуємо юридичну або нормативну відповідність об’єкта.

Якщо джерела суперечать одне одному, результатом перевірки є локалізована розбіжність, перелік залежних кошторисних позицій і запит відповідальному учаснику. До документованої відповіді варіанти не змішують у одну удавано точну суму.

Поширені запитання про завдання на проєктування й кошторис

Чи є наведена структура обов’язковою формою завдання?

Ні. Це практична матриця кошторисної готовності, а не універсальний нормативний шаблон. Форму, склад, деталізацію й порядок погодження визначають для конкретного об’єкта відповідно до застосовних вимог, договору та рішень, узгоджених замовником із проєктувальником.

Чи можна скласти кошторис лише за завданням на проєктування?

Завдання може дати межу й бюджетні орієнтири, але точні номенклатура та обсяги зазвичай потребують погоджених рішень, креслень, специфікацій, відомостей і даних про існуючий стан. До їх отримання можливий сценарний розрахунок із чіткими припущеннями.

Хто визначає відсутній технічний параметр?

Відповідальний проєктувальник або інший уповноважений технічний учасник у межах своєї компетенції та договору. Кошторисник може показати, які позиції й суми залежать від параметра, але не має призначати його самостійно.

Як контролювати зміну вимог без повного перерахунку?

Надати вимогам ідентифікатори, вести реєстр редакцій і карту зв’язків із рішеннями, кресленнями, специфікаціями та кошторисними рядками. Тоді після зміни перевіряють лише залежні частини й зберігають пояснення різниці.

Чи встановлює завдання остаточну вартість будівництва?

Ні. Воно може містити вимоги до вартості або бюджетний орієнтир, але підсумок залежить від розроблених рішень, підтверджених кількостей, меж робіт, цінової бази та умов договору. Рівень визначеності слід показувати разом із сумою.

Що передати для перевірки кошторисної готовності?

Передайте чинну редакцію завдання з додатками, реєстр вихідних даних, протоколи рішень і змін, креслення, специфікації, відомості обсягів, матрицю інтерфейсів, комерційні пропозиції, сценарні оцінки та наявний кошторис із поясненням його бази.