Техническое задание (приложение к договору об изготовлении рекламного носителя)

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

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

Без них хороший проект не сделать.

В производстве рекламы эти мерки содержит техническое задание (ТЗ). Как и в пошиве одежды, сами вы их снять не сможете, но и портной без вас не справится. Чтобы составить хорошее ТЗ, клиент и разработчик должны работать вместе.

Сегодня расскажем, как эти мерки снимать.

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

На самом деле техническое задание (ТЗ) – это юридический документ. Если подрядчик чего-то не сделал, именно этот документ в суде заставит его нести ответственность. Однако в широком смысле ТЗ включает два компонента: бриф и собственно ТЗ. В чем разница?

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

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

Часто термин «ТЗ» используется в значении «бриф» и наоборот. Просто не забывайте, что бриф — это первый этап, а ТЗ — финальный.

Кто должен составлять ТЗ

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

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

Когда заполняете бриф или начинаете составлять ТЗ, следуйте простому правилу — предлагайте задачу, а не решение.

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

Что пишет клиент

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

1. Соседство с другими вывесками и рекламными носителями. Можно просто приложить фотографию фасада, на котором планируется повесить вывеску.
2. Цветовая гамма вокруг. Аналогично, лучше приложить фото. Это важно, чтобы на бежевом фасаде не оказалось белой вывески.
3. Желаемые размеры. Не старайтесь быть предельно точными. Объясните, почему размер должен быть таким. Например, вы планируете, что вывеску будет видно с дороги издалека, а не только с тротуара вблизи.
4. Материал фасада и его состояние. Если от стены отваливается штукатурка и куски кирпича, повесить на нее тяжелую конструкцию уже не получится. Если разработчик будет знать об этом заранее, он сможет предложить более легкий аналог или посоветует другое место установки.
5. Ожидаемый бюджет. Не старайтесь назвать точную сумму, просто укажите допустимый предел. Ориентируясь на него, разработчик сможет предложить соответствующее решение.

Что пишет разработчик

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

1. Материал. Это вопрос не только эстетики. Конкретный материал зависит от погодных условий, состояния фасада, формы вывески и т.д. Если материал выбрать неправильно, вывеска может рухнуть вместе с вашей репутацией.
2. Технологии. Разработчик лучше ззнает, какие нужны светодиоды, и сколько их должно быть на вывеске.
3. Дизайн. Некоторые фантазии клиентов просто невозможно реализовать на практике. А даже если получится, провисит такая вывеска недолго.

Как показать идею

Трудно описать точную картинку того, как вы видите себе будущую рекламу. Сколько не пиши, другой человек все равно может понять иначе. Лучше показать. Сфотографируйте те вывески, которые вам нравятся, или найдите примеры в интернете. Аналогично поступите с цветовой гаммой и формой:

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

Источник — Pinterest Источник — Pinterest

Как работать с брифом и ТЗ

Бриф поможет подготовиться ко встрече вам и разработчику. Вы сформулируете, что именно хотите получить, и какие есть ограничения. Разработчик сможет предложить решение и понять, как эти ограничения преодолеть.

1. Заполните бриф своими словами. Не используйте технические термины, если плохо в них разбираетесь.
2. Отправьте бриф разработчику. Если вы находитесь в разных городах, этого хватит, но личная встреча всегда продуктивнее.
3. Разработчик проанализирует бриф и составит ТЗ. Убедитесь, что ТЗ составлено настолько подробно, что работать по нему сможет любой подрядчик.
4. После подписания ТЗ и договора, разработчик приступает к работе. Принимать результат вы будете по ТЗ.

Обычно бриф предоставляет разработчик. Если у вас его нет, скачайте наш бриф на производство вывески. Это универсальный вариант, который подходит всем.

© vizart-ptz.ru 2017 | Все права защищены. Пользовательское соглашение

Видео:ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)Скачать

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

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

Напомним, что с 11.01.2018 в правилах описания предмета госзаказа произошли изменения:

1. Законодатели исключили положение о том, что оно должно носить объективный характер.
2. Как и раньше, потребуется сопроводить товарный знак словами «или эквивалент».

Делать это не обязательно:

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

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

Правила составления ТЗ основаны на комплексе норм государственных и международных стандартов (ГОСТ). При их использовании в какой-либо сфере необходимо соотнести ТЗ со спецификой конкретной области деятельности.

https://www.youtube.com/watch?v=1GRZjBsYMMA

В соответствии с 44-ФЗ, образец технического задания по ГОСТу в обязательном порядке заказчику создавать не нужно.

Но практика показывает, что на каждом из этапов закупки (при составлении сопровождающей документации, проекта контракта, приемки и контроля исполнения контракта) заказчик соприкасается с элементами техзадания.

Поэтому полезно такой образец иметь и понимать принципы разработки технического задания.

Правила составления ТЗ по 44 ФЗ

Самый простой и быстрый способ сформировать техническое задание — образец по ФЗ 44 разработать на основе официального издания Единой системы документации национальных стандартов.

Скачать

Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. Закон устанавливает, что наименование закупки указывается в соответствии с каталогом товаров, работ, услуг (ч. 4 ст. 23). Каталог утвержден постановлением правительства от 08.02.2017 № 145.

При наличии описания закупаемой продукции в КТРУ заказчик обязан:

• описывать объект закупки так, как это предусмотрено КТРУ;
• включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).

Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:

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

Что указать в техническом задании

ТЗ необходимо основывать на положениях 44-ФЗ, обязательно соблюдать нормы гражданского, бюджетного и антимонопольного законодательств и отраслевых нормативных актов.

В качестве рекомендации, как составить техническое задание по 44 ФЗ, можно предложить разбить документ на основные разделы:

• общая информация;
• информация о закупаемом объекте;
• требования к поставщикам;
• условия исполнения контракта;
• приложения (допускается по усмотрению заказчика).

Этапы составления технического задания

1. Составить список терминов, определений и сокращений, которые будут использоваться в документе.

2. Предоставить полную информацию о заказчике:

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

3. Предусмотреть в информации о закупке сведения:

4. Перечислить сведения о госзакупке:

• способ определения поставщика (ч. 1 ст. 24);
• обоснование выбранного способа определения поставщика (ч. 5 ст. 24).

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

6. Указать исходные условия: справочная, производственная, опытная информация, которые оказывают влияние при исполнении контракта. Например, обслуживать закупаемую технику только в утренние часы.

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

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

9. Привести желаемые результаты (какую проблему хочет решить заказчик).

10. Указать источник финансирования.

11. Установить для участников требование соблюдать определенную нормативно-правовую базу, в том числе относящуюся к предмету контракта, условиям исполнения, срокам, гарантийным обязательствам.

12. Определить условия нормирования госзакупки (ч. 1 ст. 19).

13. Указать наименование и обоснование объекта госзакупки.

14. Максимально точно и детально описать объект госзакупки (ст. 33).

15. Определить экологические особенности закупаемого объекта.

16. Уточнить объем закупаемых товаров, периодичность и срок поставки.

17. Определить гарантийный срок и объем предоставляемых гарантий.

18. Установить требования к упаковке, маркировке, какие условные и специальные обозначения должны быть на ней.

19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.

20. Определить расходы на эксплуатацию.

21. Определиться, нужны ли монтаж и наладка.

22. Установить порядок поставки и приемки.

23. Указать на необходимость провести испытания, обучение лиц, которые будут использовать закупаемый товар.

Образцы техзаданий для товаров, работ, услуг в 2020 году

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

Далее представлен образец технического задания на поставку товара по 44-ФЗ.

Скачать

Образец техзадания на выполнение работ по ФЗ-44 вы можете найти в материале о техзадании на проектирование и обслуживание пожарной сигнализации или системы видеонаблюдения.

https://www.youtube.com/watch?v=BZXwh1oHkhg

А если вы закупаете техобслуживание машины, то образец технического задания на ремонт автомобиля по 44 ФЗ и пошаговую инструкцию по проведению этого вида закупок вы сможете найти в статье «Как закупить автомобили или техобслуживание: пошаговая инструкция».

Примеры для других госзакупок

Также в наших подробных инструкциях вы можете найти образец техзадания и узнать, как грамотно провести закупку на:

Видео:Как составить техническое задание на разработку программного обеспечения? 4 основных правила ТЗ!Скачать

Как составить ТЗ: подробная инструкция по созданию технического задания

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

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

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

Поэтому для расширения кругозора и для пользы представителей не-цифровых отраслей, стоит приводить отсылки и к оффлайн-проектам.

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

Узнать подробнее

Для чего нужно техническое задание?

Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.

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

Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.

Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно.

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

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

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

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

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

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

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

ГОСТ

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

https://www.youtube.com/watch?v=up8xKOWtt7w

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

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

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

Более новый стандарт — ГОСТ 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, содержит требования к конечному программному продукту.

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

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

Порядок документирования требований

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

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

Бриф

В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.

https://www.youtube.com/watch?v=5txmsG1EcYI

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

• Цель и назначение продукта;
• Предполагаемый бюджет;
• Целевая аудитория.

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

Такой опрос удобно разместить на сайте, если он не сложный. Его можно запрограммировать или дать ссылку на Google формы. Либо просто разместите кнопку обратного звонка, чтобы задать вопросы и проконсультировать клиента прямо в режиме реального времени по телефону.

50 минут в подарок новым клиентам

• Повысьте конверсию сайта на 30%.
• Экономьте на тарифах: от 5 рублей в минуту.
• Настраивайте под ваш сайт. Адаптируйте под все устройства. Тестируйте разные виджеты.
• Используйте гибкие настройки показа.
• Стройте отчеты по звонкам: от показа виджета до ключевого слова.

Узнать подробнее

Технико-коммерческое предложение

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

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

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

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

Технические требования

Если в ТКП требования приводятся самые основные, для ознакомления, то при заинтересованности заказчика с ним составляются уже более детализированные перечни требований.

Техническое задание

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

Технический проект

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

В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).

Эксплуатация

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

Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.

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

Ведите историю правок

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

Составляйте список терминов и сокращений

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

Прописывайте каждую деталь

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

https://www.youtube.com/watch?v=qkZLEq3C-FI

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

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

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

Узнать подробнее

Видео:Техническое Задание (Бриф) на создание видеоролика и инфографики - что это и зачем его заполнять?Скачать

Договор на разработку технического задания

ДОГОВОР

НА РАЗРАБОТКУ ТЕХНИЧЕСКОГО ЗАДАНИЯ

№ 1

Общество с ограниченной ответственностью «Компания 1» (сокращенное наименование ООО«Компания 1»), именуемое в дальнейшем Заказчик, в лице генерального директора Братчикова Станислава Вячеславович, действующего на основании Устава, с одной стороны, и Общество с ограниченной ответственностью «Компания 2» (сокращенное наименование ООО «Компания 2»), именуемый в дальнейшем Исполнитель, в лице генерального директора Иванова Ивана Ивановича, действующего на основании Устава, с другой стороны (далее по тексту договора по отдельности именуемые – «Сторона», а совместно – «Стороны»), заключили настоящий Договор (далее по тексту – «Договор») о нижеследующем:

1.              ПРЕДМЕТ ДОГОВОРА

1.1.

         Заказчик поручает и оплачивает, а Исполнитель обязуетсясогласно требованиям Заказчика разработать Техническое задание на разработку системы X (далее СX) согласно серверной архитектуре указанной в Приложении №1, включающее: web-сайт системы, программный комплекс системы мониторинга, взаимодействие модулей системы, интеграция с внешними системами, мобильные приложения под Android, iOS.

1.2.         Перечень и стоимость работ представлены в Приложении № 3 к настоящему Договору.

2.              ПОРЯДОК ВЫПОЛНЕНИЯ РАБОТ

2.1.         Исполнитель приступает к выполнению работ после подписания Заказчиком настоящего Договора.

2.2.         Исполнитель разрабатывает Техническое задание системы в срок определённый в Приложениях 3,4 к настоящему Договору, и предоставляет на утверждение Заказчику.

2.3.         Обязательства Исполнителя по Договору считаются выполненными после подписания Сторонами Акта сдачи-приемки работ.

Заказчик в течении 5 (пяти) рабочих дней со дня получения Акта сдачи-приемки работ по настоящему Договору обязан направить Исполнителю подписанный Акт сдачи-приемки работ или мотивированный отказ от приемки работ.

В случае мотивированного отказа Заказчиком от приемки работ, Сторонами в пятидневный срок составляется двухсторонний Акт с перечнем необходимых доработок, сроков их исполнения.

2.4.         Принятое Заказчиком Техническое задание подтверждается письмом в адрес Исполнителя и, в случае необходимости, дорабатывается окончательно на основании замечаний Заказчика, после чего Стороны подписывают Акт сдачи-приёмки работ.

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

2.6.         Договор считается выполненным после подписания Актов сдачи-приёмки работ.

2.7.         Акт сдачи-приёмки работ предоставляется Заказчику в течение 5 (Пяти) рабочих дней с момента предоставления Исполнителем результатов работ.

2.8.         Если в течение 5 (пяти) рабочих дней с момента получения Акта сдачи-приёма, данный Акт не будет подписан Заказчиком, и не будут отправлены в адрес Исполнителя мотивированные возражения, работы считаются выполненными надлежащим образом и принятыми.

2.9.         Право собственности на результат работ, выполненных Исполнителем, становится собственностью Заказчика, в момент подписания Сторонами Акта сдачи-приемки работ.

2.10.      Вместе с подписанным Сторонами Актом сдачи-приемки работ, Заказчик получает от Исполнителя все необходимые материалы, которые являются результатом проведения работ Исполнителем.

3.              Стоимость работ и порядок оплаты

3.1           Сумма настоящего Договора соответствует Перечню и стоимости работ, указанных в Приложениях № 2,3, и включает в себя сумму НДС 18%.

3.2           Оплата работ по Договору производится на условиях 100% постоплаты в течение не более 5 рабочих дней со дня подписания Заказчиком Акта сдачи-приемки работ.

3.3           В платёжных документах сумма НДС (18%) выделяется отдельной строкой.

3.4           В случае просрочки оплаты счета Заказчиком, срок исполнения работ по настоящему Договору увеличивается на соответствующее число дней просрочки.

3.5           В случае отказа Заказчика от услуг Исполнителя, добросовестно выполняющего свои обязательства, оплаченная сумма не возвращается Заказчику.

4.              СРОК ДЕЙСТВИЯ ДОГОВОРА

4.1.         Настоящий Договор вступает в силу с момента подписания и действует до исполнения Сторонами принятых на себя обязательств.

5.              ОТВЕТСТВЕННОСТЬ СТОРОН

5.1.         В случаях неисполнения или ненадлежащего исполнения своих обязательств по Договору Стороны несут ответственность в соответствии с условиями настоящего Договора и в соответствии с действующим законодательством Российской Федерации.

5.2.         За просрочку оплаты Исполнитель вправе потребовать от Заказчика уплатить неустойку в размере 0,1% от неуплаченной суммы за каждый день просрочки, но не более 10% от размера неуплаченной суммы.

5.3.         За неисполнение работ в срок Заказчик вправе потребовать от Исполнителя неустойку в размере 0,1% от стоимости настоящего Договора за каждый день просрочки, но не более 10% от стоимости настоящего Договора.

5.4.         Оплата неустойки осуществляется на основании письменного требования пострадавшей Стороны и ее признания виновной Стороной с даты, указанной в требовании.

5.5.         Оплата неустойки не освобождает Сторону от исполнения обязательств по настоящему Договору.

6.              КОНФИДЕНЦИАЛЬНОСТЬ

6.1.

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

6.2.         Обязательства конфиденциальности продолжают действовать в течение 1 (Одного) года после истечения срока данного Договора на предоставление услуг.

7.              ФОРС-МАЖОР

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

Под обстоятельствами непреодолимой силы стороны понимают стихийные бедствия (наводнения, землетрясение, ураган, эпидемия, военные действия или аналогичные войне события).

Также Исполнитель не несет ответственности за работоспособность средств связи Заказчика.

8.              ПРОЧИЕ УСЛОВИЯ

8.1.         В случае возникновения разногласий между Сторонами по вопросам, предусмотренным настоящим Договором или возникшим в связи с его исполнением, Стороны принимают меры к их разрешению путем переговоров.

Оставшиеся неурегулированными разногласия передаются на рассмотрение Арбитражного суда Санкт-Петербурга и Ленинградской области на основании ГПК РФ или АПК РФ на русском языке и на основании настоящего Договора.

8.2.         Недействительность какого-либо из условий Договора не влечет за собой недействительности всего Договора в целом.

9.        РЕКВИЗИТЫ СТОРОН

Приложение N1 к Договору

№ 1 от «31»декабря 2014 года

Архитектура системы X

Описание…

Исполнитель                                                                                                                                         Заказчик

________________/ Петров П.П.                                 ______________/ Иванов И.И.

М.П.                                                                                             М.П.    

Приложение N2 к Договору

№ 1 от «31»декабря 2014 года

Описание компонентов архитектуры системы указанной в Приложении №1

1. База данных – в качестве СУБД используется MySQL.
2. Модуль безопасности – данный компонент обеспечивает авторизацию и аутентификацию пользователей в системе. В модуль входит такие сущности как «Роли», «Пользователь», «Права». Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
3. Модуль оповещения – данный компонент обеспечивает посылку сообщений пользователям, платежным системам и т.д. Поддерживает протоколы E-mail, SMPP, SMTP, HTTP. Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
4. Аналитика и отчеты – компонент обеспечивает подготовку и демонстрацию отчетов. Анализ данных, поиск зависимостей, поиск аномалий и т.д. Оповещение администрации об аномалиях. Модуль имеет только локальный API, для обеспечения доступа к нему только локальным подсистемам.
5. Web приложение – компонент обеспечивающий связь пользователя и функциональными компонентами. Получает запросы по протоколу HTTP, обрабатывает их, при необходимости обращается к функциональным компонентам, формирует ответ и отправляет его по HTTP. Состоит из разделов, которые соответствуют функциональным компонентам.
6. Интеграция – компонент обеспечивает передачу финансовой информации в 1С-Бухгалтерию на уровне проводок.
7. Сервер приложений – .
8. Web сервер-1 – Apache
9. Web сервер-2 – Apache
10. CMS – сайт компании, включает в себя новости, блог и т.д. Используется язык PHP, framework yii.
11. CMS DB – Maria DB

Related Posts via Categories

Видео:Как создать техническое задание на сайт. Разработка ТЗ для IT проекта #tz #it #product #pmСкачать

Техническое задание на разработку приложения

Написать хорошее ТЗ сложно, это не дело пяти минут. Но есть отличная новость! Эта ответственная задача ложится не только на ваши плечи, но и на плечи мобильного разработчика. Он тоже заинтересован в успехе вашего сотрудничества.

1 шаг. Идея разработки мобильного приложения

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

Не пытайтесь втиснуть в одно приложение все сразу — ведь в блюдах мы не мешаем все, что находим в холодильнике.

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

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

https://www.youtube.com/watch?v=YErxcMh3wXU

Если же вы делаете приложение под свои бизнес-задачи, то вам будет полезно посмотреть, какие приложения есть у ваших конкурентов. Возможно, что-то вы сможете сделать сильно лучше, и как итог — переманить клиентов у конкурентов.

2 шаг. Вопросы, с которых начинается ТЗ

Чтобы составить ТЗ, для начала нужно ответить на несколько вопросов:

1. Для кого это приложение? Для ваших клиентов, будущих или потенциальных, или для всех сразу? Или для ваших сотрудников?
2. Какие задачи решает приложение? Если оно для клиентов, то что клиенты смогут делать с помощью вашего приложения – заказывать товары, услуги, бронировать, записываться онлайн, узнавать об акциях и т.д.? Если оно для сотрудников, то какие функции в приложении помогут им работать эффективнее?
3. На каком устройстве вы хотите видеть ваше приложение? Смартфон, планшет или десктоп?
4. В устройствах каких марок вы планируете поселить ваше приложение? От этого зависит, какую платформу для приложения вы выберите — iOS, Android, Windows.
5. Когда вы хотите получить готовое приложение? То есть сроки.
6. Какой у вас бюджет? Уникальное приложение стоит не дешево, однако стоит учитывать те бонусы, которые вы за счет него получите — прибыль от увеличения заказов или оптимизации бизнеса.

Ответив на эти вопросы, можете смело заполнять бриф. А это первый шаг к тому, чтобы составить правильное ТЗ, а потом и к разработке успешного мобильного приложения.

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

3 шаг. Настало время ТЗ!

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

За некоторыми исключениями, ТЗ состоит из вот таких разделов:

1. Терминология. Очень важно договориться о терминах заранее, ведь одно и то же слово вы и разработчик можете понимать по-разному.
2. Цель создания системы, то есть приложения. Здесь вы подробно описываете, что пользователь сможет делать в приложении, какие действия и какой результат он получает. В общем, для чего ваше приложение будут скачивать люди в свои смартфоны. Если у вас приложение для магазина, то вы должны решить, к примеру —пользователь будет просто просматривать каталоги, узнавать о наличии товаров в магазинах или сразу покупать и заказывать доставку?
3. Требования к приложению. Самая сложная часть техзадания, где технические термины льются как из рога изобилия. Написать это самому нереально. Но важно понимать, что каждый шаг будущего пользователя должен быть продуман до технических мелочей. К примеру, из тз должно быть четко ясно, что случится, если нажать на вот эту красную кнопочку?
4. Сценарии использования. Что происходит, когда человек впервые заходит в приложение? Нужно ли регистрироваться? А что произойдет, когда он зайдет повторно? Все эти пути важно описать в тз, ведь это поможет выявить, какие функции нужны приложению и что именно должно в нем происходить.
5. Описание экранов. Некоторые тз содержат прототипы экранов, если они уже готовы. В некоторых есть даже первичный дизайн. В любом случае описать экраны хотя бы словами просто необходимо. Ведь для многих пользователей приложение – это и есть экран. Именно с ним он имеет дело, и что толку от функции регистрации, к примеру, если ни на одном экране нет такой кнопки?6.Требования к платформе, CMS, архитектура системы… и еще много страшных слов, если вы не разработчик или технический писатель.

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

Начните прямо сейчас!

На самом деле, написать хорошее ТЗ — просто, если подойти к этому делу с умом. И не возлагать на себя одного это нелегкое дело. Ведь ТЗ нужно для результативного взаимодействия. А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности разработчик берет на себя!

Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта. Поэтому начинайте прямо сейчас — напишите бриф. Этого хватит, чтоб увидеть проект в общих чертах, а значит, дело останется за деталями!

Статья подготовлена компанией PunicApp — punicapp.com

В избр. Сохранено

1 шаг. Идея разработки мобильного приложения

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

Мы выбираем что-то главное и добавляем к нему несколько менее важных ингредиентов, для того чтоб вкус получился уникальным.Посмотрите, нет ли аналогов приложения? Если нет, то вам крупно повезло. Обычно же аналоги находятся и в крупных размерах — ваша задача придумать, чем ваше приложение будет отличаться, причем в лучшую сторону.

И если вам удастся найти эту прореху в нише, заполняйте ее смело и не теряйте драгоценных секунд — конкуренты не дремлют.

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

Возможно, что-то вы сможете сделать сильно лучше, и как итог — переманить клиентов у конкурентов.

2 шаг. Вопросы, с которых начинается ТЗ

Чтобы составить ТЗ, для начала нужно ответить на несколько вопросов:1. Для кого это приложение? Для ваших клиентов, будущих или потенциальных, или для всех сразу? Или для ваших сотрудников?2.

Какие задачи решает приложение? Если оно для клиентов, то что клиенты смогут делать с помощью вашего приложения – заказывать товары, услуги, бронировать, записываться онлайн, узнавать об акциях и т.д.? Если оно для сотрудников, то какие функции в приложении помогут им работать эффективнее?3. На каком устройстве вы хотите видеть ваше приложение? Смартфон, планшет или десктоп?4.

В устройствах каких марок вы планируете поселить ваше приложение? От этого зависит, какую платформу для приложения вы выберите — iOS, Android, Windows.5. Когда вы хотите получить готовое приложение? То есть сроки.6.

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

Ответив на эти вопросы, можете смело заполнять бриф. А это первый шаг к тому, чтобы составить правильное ТЗ, а потом и к разработке успешного мобильного приложения.

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

3 шаг. Настало время ТЗ!

ТЗ – индивидуальный документ, и каждый раз составляется заново под каждый проект. Это также зависит и от разработчика, к которому вы обратились.

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

1. Терминология.

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

2. Цель создания системы, то есть приложения. Здесь вы подробно описываете, что пользователь сможет делать в приложении, какие действия и какой результат он получает. В общем, для чего ваше приложение будут скачивать люди в свои смартфоны. Если у вас приложение для магазина, то вы должны решить, к примеру —пользователь будет просто просматривать каталоги, узнавать о наличии товаров в магазинах или сразу покупать и заказывать доставку?
3. Требования к приложению. Самая сложная часть техзадания, где технические термины льются как из рога изобилия. Написать это самому нереально. Но важно понимать, что каждый шаг будущего пользователя должен быть продуман до технических мелочей. К примеру, из тз должно быть четко ясно, что случится, если нажать на вот эту красную кнопочку.
4. Сценарии использования. Что происходит, когда человек впервые заходит в приложение? Нужно ли регистрироваться? А что произойдет, когда он зайдет повторно? Все эти пути важно описать в тз, ведь это поможет выявить, какие функции нужны приложению и что именно должно в нем происходить.
5. Описание экранов. Некоторые тз содержат прототипы экранов, если они уже готовы. В некоторых есть даже первичный дизайн. В любом случае описать экраны хотя бы словами просто необходимо. Ведь для многих пользователей приложение – это и есть экран. Именно с ним он имеет дело, и что толку от функции регистрации, к примеру, если ни на одном экране нет такой кнопки?
6. Требования к платформе, CMS, архитектура системы… и еще много страшных слов, если вы не разработчик или технический писатель.
Ваше ТЗ может не содержать тех или иных разделов только в том случае, если это не существенно именно для вашего проекта. Но узнать, что именно существенно, а что нет, вы сможете только от разработчика.

Начните прямо сейчас!

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

А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности мы берем на себя!
Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта.

Поэтому начинайте прямо сейчас — заполните бриф. Этого хватит, чтоб увидеть проект в общих чертах, а значит, дело останется за деталями!

📸 Видео

Техническое задание. Что такое и зачем нужно?Скачать

Задание на проектирование, Техническое задание, URS – в чем различие? Структура Технического заданияСкачать

Техническое заданиеСкачать

Как составить техническое задание (ТЗ)?Скачать

Документальное сопровождение разработки и производства ЭКБ (Техническое задание на ОКР)Скачать

Этап проектирования и техническое задание (ТЗ) в проектах по автоматизацииСкачать

Как составить техзадание на сайт / лендинг - Пример ТЗСкачать

Разработка технического задания для мобильного приложения iOS или Android (Technical Requiriments)Скачать

Как написать ТЕХНИЧЕСКОЕ ЗАДАНИЕ?Скачать

Разработка веб-сервисов. Техническое заданиеСкачать

Мастер-класс «Как НКО составить техническое задание на разработку сайта»Скачать

09 Пример составления технического заданияСкачать

Техническое задание - Как составить #ТЗ для интернет магазина | 4 этапаСкачать

Притча про Техническое ЗаданиеСкачать

Как составить ТЗ для фабрики по пошиву одежды?Скачать

Мастер класс по анкете и техническому заданию (бриф на дизайн-проект)Скачать