Техническое задание на подготовку документации по планировке территории

Наблюдения, которые указывают на решимость предприятия к изменениям

Раздается звонок.
— Здравствуйте, это Сергей? Меня зовут (не вникайте в название, но это плоды секундной фантазии), я директор по производству на . У меня есть ряд проблем с производственным планированием. Могли бы мы с вами встретиться?

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

Большой проект: документация

Оставим за рамками нашей темы поиск потенциального клиента. Мы его нашли. Вот он — Большой клиент. Чего мы хотим? Хотим заработать. И чтобы этот Большой клиент был у нас не один. А к нам большинство таких клиентов пришли по рекомендации, а для рекомендаций положительных нужно, чтобы Большой клиент был очень доволен сотрудничеством с нами. Но и мы хотели бы быть довольны работой с ним. Вот о том, какими документами мы этого добиваемся, я и попытаюсь рассказать.
*** Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года). Также она опубликована в журнале Инфостарта № 3

ГОСТ 19 для Технического задания

Техническое задание по ГОСТу 19 должно содержать следующие разделы:

1. введение;
2. основания для разработки;
3. назначение разработки;
4. требования к программе или программному изделию;
5. требования к программной документации;
6. технико-экономические показатели;
7. стадии и этапы разработки;
8. порядок контроля и приёмки.

В техническое задание допускается включать приложения, а также в зависимости от особенностей программы или программного изделия в ТЗ допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них.

В разделе 1 «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

В разделе 2 «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведётся разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

В разделе 3 «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

Раздел 4 «Требования к программе или программному изделию» должен содержать следующие подразделы:

• требования к функциональным характеристикам;
• требования к надёжности;
• условия эксплуатации;
• требования к составу и параметрам технических средств;
• требования к информационной и программной совместимости;
• требования к маркировке и упаковке;
• требования к транспортированию и хранению;
• специальные требования.

В подразделе 4.1 «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.

В подразделе 4.2 «Требования к надёжности» должны быть указаны требования к обеспечению надёжного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).

В подразделе 4.3 «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.

В подразделе 4.4 «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

При необходимости должна обеспечиваться защита информации и программ.

В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

В разделе 5 «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.

В разделе 6 «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.

В разделе 7 «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.

В разделе 8 «Порядок контроля и приёмки» должны быть указаны виды испытаний и общие требования к приёмке работы.

В приложениях к техническому заданию, при необходимости, приводят:

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

Что такое системы связи

Связь – это обмен определенной информацией. Для целей проектирования, строительства и эксплуатации зданий система связи предусматривает комплекс сетей и оборудования, обеспечивающих обмен информацией, т.е. внутреннюю и внешнюю коммуникацию. В зависимости от особенностей и типа объекта, система связи может включать:

• линии и оборудование сигнализации, аварийного и экстренного оповещения;
• локальную, внешнюю, проводную или беспроводную телефонную связь;
• оптико-волоконные и иные интернет-каналы;
• системы дистанционного управления оборудованием, приборами учета и иными устройствами в здании;
• каналы электро- и радиосвязи;
• технологические сети связи, обеспечивающие обработку технической и производственной информации на объекте.

В отдельных случаях монтаж систем связи может быть обязательным требованием для эксплуатации объекта. Например, для многоквартирных зданий предусматривается разработка линий пожарной сигнализации и аварийного оповещения жильцов. Следовательно, от надлежащего проектирования таких систем зависит не только надлежащая коммуникация, но и обеспечение безопасности людей, имущества, здания.

Нормативные документы в 2021 году

Проектная документация на строительство, реконструкцию и капремонт зданий осуществляется в соответствии с Постановлением № 87, строительными нормами и правилами, НПБ, СНиП, иными нормативными актами. Как указывалось выше, Постановлением № 87 раздел “Системы связи” (подробнее про изменения на сайта https://www.mos.ru/authority/documents/doc/38266220/) и порядок его заполнения указан как обязательная часть проекта. Также при разработке документации будут использоваться:

• СП 118.13330.2012 на общественные здания (скачать СП 118 Общественные здания);
• СП 54.13330.2016 на многоквартирные дома (скачать СП 54.13330.2016 на многоквартирные дома);
• СП 56.13330.2011 на производственные здания (скачать СП 56.13330.2011 на производственные здания);
• СП 133.13330.2012 на сети проводного радиовещания и оповещения в зданиях (скачать СП 133.13330.2012);
• СП 134.13330.2012 на системы электросвязи (скачать СП 134.13330.2012);
• НПБ 110-03 на системы защиты зданий автоматическими установками пожаротушения и аварийной сигнализацией (скачать НПБ 110 03).

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

Простым языком

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

Современные многоквартирные дома обязательно проектируется с учетом монтажа:

• систем аварийной и пожарной сигнализации;
• мест для прокладки оптико-волоконных сетей;
• средств связи с диспетчерскими службами;
• оборудованием для удаленного доступа, домофонами, иными средствами коммуникации.

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

Образец проекта систем связи – Образец проекта СС

Обследование перед проектированием систем связи перед реконструкцией

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

Кто выполняет обследование систем связи

Перед реконструкцией обследование проводится по инициативе собственника здания, т.е. он должен обеспечить экспертов документацией, предоставить доступ для визуального и инструментального изучения объекта. Состав комиссии зависит от направлений проверки и вида предстоящих работ. Это могут быть представители проектной и подрядной организации, архитекторы, инженеры, техники.

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

Что обследуется в системе связи зданий

Для проектирования реконструкции обследования и изыскания проводятся в здании, его помещениях, на несущих конструкциях, на территории участка. В перечень проверок входит:

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

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

Обследование систем связи

Основные способы и инструменты для обследования систем связи

Помимо изучения документов, обследование систем и оборудования связи может предусматривать:

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

При выявлении дефектов, недостатков и проблем будут составлены акты, дефектные ведомости. Также будет проверено соответствие средств связи требованиям законодательства по разрешенным частотам, на наличие сертификатов и лицензий. Морально устаревшее оборудование будет рекомендовано к полной или частичной замене.

Итоговый документ по результату

Итогом обследований должен стать вывод о возможности проведения реконструкции без угрозы устойчивости и прочности здания. Этот вывод будет указан в отчетах и заключениях экспертов. Также в экспертном заключении будут содержаться рекомендации о возможных усилениях конструкций, о разрешенных местах присоединения новых линий связи и оборудования. По экспертному заключению, отчетам, актам и дефектным ведомостям проектировщик будет заполнять соответствующие разделы документации.

2.1 Стандарты ТЗ

Форма и содержание ТЗ создается на основании установленных шаблонов. Это сокращает затраты, время и систематизирует работу. Как правило, для создания ТЗ используются следующие виды стандартов:

1) Международные стандарты

2) Государственные стандарты

3) Корпоративные стандарты

Кратко опишу стандарты, используемых для написания ТЗ:

Международные стандарты.

Наиболее известным международным стандартом является стандарт IEEE Std 830. Стандарт IEEE Std 830 предполагает, что детальные требования могут быть обширными и не существует оптимальной структуры для всех систем. Стандарт рекомендует структурировать детальные требования таким образом, чтобы структура каждого раздела требований была наиболее оптимальной для понимания. Стандарт предлагает различные способы структурирования детальных требований для различных классов систем.

Государственные стандарты.

Основным стандартом для написания ТЗ по информационным системам является ГОСТ 34.602-89. Для крупных проектов, выполняемых в крупных компаниях, данный стандарт подойдет лучше всего. Иногда этот стандарт у ряда заказчиков является обязательным для применения на проектах внедрения автоматизированных систем управления (АС). Данный стандарт имеет более жесткую структуру, чем стандарт IEEE Std 830, что одновременно является его преимуществом и недостатком.

В большинстве проектов внедрения 1С:Предприятия данный стандарт является избыточным и сложным для понимания даже для разработчиков АС. Однако, когда разработка ТЗ всё-таки ведется по данному ГОСТу предлагается полностью сохранять структуру документа в соответствии с установленным стандартом. При этом по «пустым» разделам просто вносить комментарии типа: «По данному разделу требования отсутствуют».

Корпоративные стандарты.

Корпоративный стандарт существует на отдельном предприятии или в холдинге. Обычно корпоративный стандарт берет за основу любой из двух предыдущих стандартов и дорабатывается с учетом особенностей данного предприятия и его бизнес-процессов. В проектах внедрения 1С чаще всего используется корпоративный стандарт в виде упрощенного варианта ГОСТа34.

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

Выполнил для компании, которая занимается маркетингом и продвижением продуктов, проектирование и модификацию конфигурации КА 2.4 и справочника «Проекты». Теперь в конфигурации «Проекты» имеют особенную роль и на основании выполненной доработки руководство компании принимает решения по продолжению, закрытию или продвижению проекта/ов, поиск путей решения возникающих вопросов. При необходимости доработку можно реализовать под ERP конфигурацию. Архитектура решения выполнена «рядом» с основной конфигурацией. В настоящее время конфигурация поддерживается, модификация ведется в актуальной версии КА 2.4.10 на платформе 8.3.14.1630.

Жизнь без технического задания

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

Технические условия

Если очень упростить определение, то технические условия объясняют, что можно сделать. Выдают техусловия на проектирование электрики в энергоснабжающем предприятии. Для этого нужен следующий пакет документов:

1. Схема расположения электроустановок. Поскольку техусловия выдаются для здания или предприятия целиком, то нет необходимости выполнять полную детализацию, вплоть до каждой лампочки и розетки.
2. Однолинейная схема электроснабжения. Требуется для потребителей, использующих напряжение свыше 35 кВ.
3. Список подключаемых электроустановок. Необходимо указать мощность этих установок
4. Копии документов, доказывающие право собственности на подключаемый объект. Юридические лица должны получить выписку из ЕГРЮЛ.
5. Физические лица, подающие заявку на подключение электроэнергии к объекту, мощностью до 15 кВт, для личных нужд должны подать паспорт или другой документ, подтверждающий личность и место жительства. Кроме этого, нужен список электроприборов с указанием максимальной одновременной мощности.

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

Если в заявке будет указана очень большая мощность, то в прошении будет отказано.

Задание и проект

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

Здесь важно запомнить, что нужно избегать каких-либо привязок к особенностям технической реализации, то есть в процессе разработки ТЗ, в принципе, не имеет никакого значения то, на какой конкретной платформе будет осуществляться реализация всех этих требований. Конечно, есть определенные исключения, но это частные случаи

Выяснением и дальнейшей формулировкой различных требований, а также окончательной разработкой ТЗ уже должен заниматься специализированный бизнес-аналитик, а никак не исполнитель (если он, конечно, не совмещает в себе эти роли, что периодически случается). Другими словами, специалист должен общаться с заказчиком на языке бизнеса, который тот ведет.

Типичные нарушения заказчика при составлении технического задания

Нарушение 1: неясные формулировки, значения

Из описания объекта закупки должно быть однозначно понятно, что заказчик собирается закупить. Требования к показателям характеристик (min, max или точные значения) следует указывать недвусмысленно, предельно понятно и доступно. Согласно ч. 1 и ч. 2 ст. 33 документация должна содержать требования, которые позволяют установить подходят ли предлагаемые товары, (работы или услуги) заказчику. Не следует использовать термины наподобие «не хуже», «не слабее» и тому подобные, это не объективное описание. Что для заказчика лучше, а что хуже, поставщик не обязан знать или угадывать.

Характеристики объекта закупки, например, могут выглядеть так:

«Требования к товару. Товар (далее — мебель) должен соответствовать ГОСТ 16371-2014 «Мебель. Общие технические условия» (введен в действие Приказом Росстандарта от 15.06.2015 № 683-ст), ГОСТ 26800.1-86 «Мебель для административных помещений. Функциональные размеры столов». Наименование товара — стол эргономичный. Размер, Ш x Г x В (ширина, глубина, высота): — минимальные значения — 100 x 100 x 71,5 см; — максимальные значения — 165 x 110 x 71,5 см. При этом высота не подлежит изменению. Цвет: коричневый. Требования к столешнице: Материал — высококачественная МДФ, толщина: минимальное значение — 12 мм, максимальное значение — 35 мм. Облицовка — ПВХ-пленка. Столешница должна быть эргономичной и иметь плавные края. В столешнице должно быть предусмотрено отверстие для проводов с заглушкой.»

Бывает, что заказчики ошибаются при указании требований диапазонными значениями. Например, «ширина более 360 мм и менее 214 мм». Иногда при описании объекта закупки не учитываются собственные инструкции по подготовке заявок: «В случае, если присутствует слово «диапазон», «в пределах», то поставщику необходимо предоставить диапазон значений ниже установленного заказчиком». Каким образом это понимать в случае температурного диапазона непонятно.

Достаточно часто заказчики переписывают с государственных стандартов все подряд характеристики, при этом товар не может обладать всеми требуемыми характеристиками одновременно. Например, что касается подвижности и жесткости бетона ГОСТ 7473-2010. Бетон может быть либо жестким (Ж), либо подвижным (П). Это взаимоисключающие характеристики. Однако, заказчики умудряются вписать в техзадание и то и другое: жесткость Ж1-Ж4; подвижность П1-П4. Материала с такими характеристиками не может быть. И это является нарушением ч. 2 ст. 33 44-ФЗ.

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

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

Нарушение 2: ссылка на ГОСТ без какого-либо описания

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

Нарушение 3: отсутствие фразы «или эквивалент»

Распространённой ошибкой также является указание в описании объекта закупки требования к товарному знаку без ссылки на возможность применения эквивалента, что может привести к ограничению конкуренции. Узнайте подробнее об этом требовании закона в видео на сайте Школы электронных торгов «Правила составления технических заданий в рамках закона 44-ФЗ и требования к их содержанию»

Как составить техническое задание

В первом приближении главные требования к техническому заданию — это продуманность и полнота. Но, так как не во всех случаях составители способны соблюсти данные условия, были разработаны общепринятые стандарты разработки ТЗ.

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?

Из названия легко понять, что данные стандарты приняты на общегосударственном уровне и являются рекомендуемым образцом разработки технических заданий на территории России.

Вместе с тем, надо помнить, что эти два ГОСТа имеют отношение именно к программным комплексам. То есть, в современном понимании — к сайтам, приложениям, системам автоматизации. ТЗ на размещение предприятия общественного питания в бюджетном учреждении придётся писать по другим правилам.

ГОСТ

Не пугайтесь, но ГОСТ 19 введён в 1980 году. Учитывая, что основа и парадигма программного обеспечения на протяжении долгого времени примерно та же, он пока не утратил своей актуальности. Это можно сравнить со строительством зданий. Конечно, меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.

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

Само техническое задание должно содержать следующие пункты:

• Введение;
• Основания для разработки;
• Назначение разработки;
• Требования к программе или программному изделию;
• Требования к программной документации;
• Технико-экономические показатели;
• Стадии и этапы разработки;
• Порядок контроля и приемки;
• Приложения.

Более новый стандарт — ГОСТ 34, но и здесь присутствует нюанс. Новее он только на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

Текст технического задания строится по структуре:

• Общие сведения;
• Назначение и цели создания (развития) системы;
• Характеристика объектов автоматизации;
• Требования к системе;
• Состав и содержание работ по созданию системы;
• Порядок контроля и приемки системы;
• Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
• Требования к документированию;
• Источники разработки.

Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.

ISO/IEC/IEEE 29148

Разработанный Международной организацией по стандартизации ISO, данный современный стандарт пригоден для использования помимо всего прочего в международных проектах.

Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

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

Из чего состоит техническое задание

Все будет зависеть от шаблона, который вы выберете (чуть дальше я дам несколько ссылок на шаблоны/примеры), но есть базовые блоки, которые входят в техническое задание:

1. Описание проекта/задачи. Кратко пишем, что за проект или задача, которую нужно выполнить.
2. Назначение и цели. Какие цели стоят перед проектом.
3. Требования. Дизайн, функции, технологии, которые необходимы.
4. Описание работ. Что, когда и как будет выполнено.
5. Порядок контроля и приемки. Как будут приниматься работы, что можно считать выполненным.
6. Приложения. Эскизы, наброски, прототипы.

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

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–