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

Обновлено: 07.01.2025

Я четыре года веду проекты по созданию сайтов, брендингу и рекламе. Раньше от слова «правочки» у меня начинал дергаться глаз.

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

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

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

Осторожно, бюрократия

Наши правила документооборота достаточно жесткие. Оправдание этой бюрократии простое: мы хотим, чтобы наши права были защищены. При этом мы делаем еще две вещи:

1. Мы дружелюбны и честны с клиентами и заранее предупреждаем о наших правилах.
2. Мы сами нарушаем собственные правила, если хотим.

У меня были ситуации, когда клиент не успевал перевести предоплату и мы стартовали без нее. Или шли верстать страницы без согласованного дизайна. Но это уже наши внутренние риски, которые менеджер и компания берут на себя.

Как делают сайты

Когда компания выходит на рынок, вырастает, меняет аудиторию или просто обнаруживает себя в 2019 году, ей становится нужен сайт.

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

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

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

Заказать разработку в агентстве. Там за клиента составят задание (описание требований к сайту), нарисуют макеты, запрограммируют. Это дороже, зато результат предсказуемый. Средний и крупный бизнес, как правило, заказывают сайты именно у агентств.

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

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

Какие есть подходы и проблемы

Есть два подхода к созданию любого веб-проекта.

Первый подход — классическая «водопадная» модель разработки. Она подразумевает, что все части проекта идут последовательно друг за другом. Это значит, что сначала мы согласовываем задание и только потом начинаем рисовать дизайн-концепцию. Концепция будет основана на задании и переданных материалах. После концепции наступит очередь макетов, а когда макеты будут готовы — начнется сборка. Наполнять сайт мы будем только предоставленным контентом. При таком подходе стоимость проекта рассчитывается заранее и не меняется в процессе работы.

Второй подход — это применение так называемых гибких методологий (эджайл, скрам, тайм-энд-матириал и другие красивые слова — отсюда). При таком подходе разработка ведется этапами и не останавливается. Как пример: сначала быстро нарисовали, запрограммировали и выпустили главную страницу сайта и каталог. Потом добавили еще пару страниц. И еще пару страниц. Такой подход подразумевает почасовую оплату работы специалистов: сколько времени потратили на итерацию, столько она и будет стоить.

Работать «по водопаду» уже не так модно, как по эджайлу, но это все еще популярный подход в разработке сайтов.

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

Наш подход

Мы работаем по первой модели — «водопадной». Чтобы избежать проблем, мы фиксируем в документах все стоящее, все полезное и все спорное. Каждый этап работы также обрастает документами.

В итоге на любом проекте у нас есть:

1. Договор.
2. Приложение № 1.
3. Приложение № 2.
4. Задание.
5. 6—10 актов выполненных работ.
6. 1—3 акта приема-передачи информационных материалов.
7. 4 счета.

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

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

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

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

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

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

Расскажу о каждом документе подробнее.

Договор

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

Во всех наших договорах мы прописываем важные для нас нюансы.

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

Сдавать результаты работ тоже можно в таск-менеджере. Если клиент пропадает, а срок сдачи макетов подошел, можно выложить результат в таск-менеджер — юридически это считается сдачей результата. Остается выставить акт и счет.

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

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

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

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

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

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

Приложение

Приложение — это соглашение об определенном наборе работ. В нем мы фиксируем этапы, сроки, стоимость, ответственность сторон на конкретном проекте. Если проект большой, мы можем сделать два приложения: первое — на дизайн, второе — на программирование. Если проект маленький, мы составляем одно приложение. Расскажу о наших принципах именно на таком примере.

В приложении всегда есть предоплата. В зависимости от договоренностей с клиентом и объема работ, она составляет от 20 до 100% стоимости контракта. Мы не работаем без предоплаты, потому что всегда есть шанс расторжения договора и прекращения сотрудничества. Будет обидно, если мы сделаем работу без предоплаты, ее не примут и потребуют расторгнуть договор. Получится, что денег нет, клиента нет, а время, которое потрачено на эту работу, не вернуть.

Работы в приложении делятся на этапы. Каждый этап закрывается актом выполненных работ и становится основой для последующих работ и этапов.

Сначала читать, потом подписывать

Разбивка по этапам выглядит примерно так:

1. Разработка задания — 10 рабочих дней.
2. Разработка дизайн-концепции — 10 рабочих дней.
3. Разработка дизайн-макетов — 20 рабочих дней.
4. Сборка (верстка, программирование, тестирование) сайта — 40 рабочих дней.
5. Наполнение сайта контентом — 10 рабочих дней.

При желании можно разбить проект на большее количество этапов: отдельно показать прототип, адаптацию макетов, верстку, тестирование и что-нибудь еще. Все зависит от проекта.

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

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

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

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

Для каждого этапа мы указываем, в какой форме сдаем результат. И именно результат по этой форме клиент может принять или не принять. Объясняю на примере.

С юридической точки зрения дизайн-концепция — это две картинки

Вот что мы делаем для разработки концепции:

1. Выясняем пожелания клиента.
2. Изучаем и предлагаем референсы.
3. Понимаем ограничения и пожелания по концепции.
4. Определяем цветовую палитру и шрифты.
5. Готовим презентацию на пару десятков слайдов.
6. Делаем видеоролик.
7. Собираем анимированный прототип.

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

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

1. Материалы, которые передает клиент и на которые у него должны быть права. Обычно это логотип, фотографии сотрудников, продуктов и процессов клиента и тому подобный визуальный контент.
2. Рекомендуемые элементы — шрифты, стоковые изображения и прочие вещи, которые нам не принадлежат, поэтому отдавать права на них мы не можем. Поэтому мы их именно рекомендуем к использованию.
3. Лицензии на программное обеспечение — на « 1С-битрикс », например. Права на лицензию нельзя передать, так что мы не можем купить ее, попользоваться и потом отдать клиенту. А значит, клиент сам должен об этом позаботиться и предоставить нам разрешение на использование лицензии.

Все нюансы работы с интеллектуальными правами прописаны в приложении. Пункт 4.6 фиксирует, что права на все результаты работ переходят к клиенту только после завершения проекта, не раньше. Пункт 4.7 разрешает нам анонсировать наши работы на фестивалях, конкурсах, в СМИ. Это приносит нам примерно половину новых клиентов

Задание

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

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

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

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

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

Зачем делают и какие бывают

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

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

1. Поставки: спецификация, тарифы, заявка на поставку, график поставки, порядок взаиморасчетов.
2. Подряда: проектно-сметная документация, техническое задание, график производства работ, акты выполненных работ, справка о стоимости.
3. Оказания услуг: перечень услуг, график, порядок оплаты.
4. Купли-продажи: перечень продукции, подробное описание (при необходимости), акт сдачи-приемки.
5. Трудовой: условия труда, график работы, размер зарплаты.

Особые правила действуют для подрядных контрактов. В ст. 432 ГК РФ не указано, что такое приложение к договору, но в ч. 1 ст. 432 закреплены существенные условия, т. е. условия, обязательные для исполнения конкретного вида соглашения. В подрядном контракте это виды и объем работ, которые указывают в локальном сметном расчете. Смета является обязательной и неотъемлемой частью любого подрядного соглашения.

Чем отличается от дополнительного соглашения

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

Отличия допсоглашения от приложений:

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

Допсоглашения составляют, если сторонам требуется урегулировать изменения. А вот как прописать приложения к договору в договоре поставки, подряда или услуг:

1. Добавить отдельный пункт в содержание.
2. Перечислить перечень дополнений.
3. Указать, что они неотъемлемая часть контракта.

Как составить

Унифицированный бланк в законодательстве не предусмотрен, поэтому используется свободная форма приложения к договору поставки, подряда, купли-продажи и др. Дополнения составляют в том же виде, что и основное соглашение. Если стороны заключили сделку в письменной форме, то и все документы к нему составляют письменно (ст. 434 ГК РФ).

Краткая инструкция, как оформляется приложение к договору в письменном виде:

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

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

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

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

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

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

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

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

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

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

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

Заказчик

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

Исполнитель

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

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

Совместно

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

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

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

В вакансиях на должность системного аналитика или технического писателя можно встретить требование: знание ГОСТ 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, содержит требования к конечному программному продукту.

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

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

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

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

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

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

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

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

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

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

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

  Виджет обратного звонка для сайта

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

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

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

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

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

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

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

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

  
  

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

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

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

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

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

  23 действующих способа сделать свой маркетинг круче, быстрее, эффективнее, чем сейчас

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

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

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

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

  Рекомендации по составлению ТЗ

  Правильное ТЗ составляют по универсальному шаблону. Он формируется из следующих элементов.

  Дайте подрядчику общую информацию

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

  Покажите конкурентов

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

  Распишите сценарии использования продукта

  Сценарий нужен для понимания принципа работы продукта. Например, если область работы касается IT, сценарий отвечает на вопрос «Как будет вести себя пользователь?» и дает понимание главных функций сайта.

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

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

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

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

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

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

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

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

  
  

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

  Опишите требования к проверке проекта

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

  Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch. Он формирует отчет о результатах рекламных кампаний: сколько было звонков и заявок, и сколько из них привели к оформлению заказа. Вам не придется высчитывать KPI — итоги работы наглядно отражены в личном кабинете.

  Сквозная аналитика

  • Автоматически соберет данные с рекламных площадок, сервисов и CRM в 1 окне
  • Бесплатные интеграции c CRM и другими сервисами: более 50 готовых решений
  • Анализируйте воронку продаж от показов до кассы
  • Оптимизируйте свой маркетинг с помощью подробных отчетов: дашборды, графики, диаграммы
  • Кастомизируйте таблицы, добавляйте свои метрики. Стройте отчеты моментально за любые периоды

  Когда ТЗ не нужно

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

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

  Выводы

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

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

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

  Открыть документ в вашей системе КонсультантПлюс:
  Форма: Техническое задание (приложение к договору оказания маркетинговых услуг)
  (Подготовлен для системы КонсультантПлюс, 2021)

  Открыть документ в вашей системе КонсультантПлюс:
  Форма: Техническое задание (приложение к договору оказания услуг по негосударственной экспертизе предпроектной документации)
  (Подготовлен для системы КонсультантПлюс, 2021)

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

  Открыть документ в вашей системе КонсультантПлюс:
  Подборка судебных решений за 2018 год: Статья 117 "Восстановление процессуальных сроков" АПК РФ
  (ООО юридическая фирма "ЮРИНФОРМ ВМ") Руководствуясь статьей 117 АПК РФ и отказывая в восстановлении пропущенного процессуального срока подачи заявления на возмещение судебных расходов, понесенных при рассмотрении настоящего дела, арбитражные суды обоснованно исходили из того, что истцом не приведены доводы, свидетельствующие о наличии объективно уважительных причин пропуска такого срока, так как в настоящем случае, с учетом условий технического задания к договору оказания юридических услуг, самостоятельное определение заказчиком и исполнителем сроков оплаты юридических услуг не может влиять на течение установленного процессуального срока.

  Открыть документ в вашей системе КонсультантПлюс:
  Подборка судебных решений за 2020 год: Статья 172 "Порядок применения налоговых вычетов" главы 21 "Налог на добавленную стоимость" НК РФ
  (АО "Центр экономических экспертиз "Налоги и финансовое право") Как указал суд, признавая позицию ИФНС правомерной, основным видом деятельности налогоплательщика является уборка и содержание производственных помещений, оказание услуг по организации технологического процесса работы объектов теплоснабжения. Им со спорными контрагентами был заключен ряд контрактов на оказание услуг по обслуживанию и ежедневной комплексной уборке, по организации технологического процесса объектов теплоснабжения. В подтверждение финансово-хозяйственных отношений представлены соответствующие контракты, договоры, технические задания, счета-фактуры, акты на оказанные услуги.

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

  Путеводитель по судебной практике. Подряд. Общие положения ". Как установлено судами и следует из материалов дела, по результатам проведения закупочной процедуры между ОАО "Молокозавод Петропавловский" (заказчик) и ООО "СтройКом" (исполнитель) 01.09.2017 заключен договор N 31705476652-2017, по условиям которого исполнитель обязался по техническому заданию заказчику (приложение N 1 к договору) оказать услуги по разработке проектно-сметной документации, включая изыскательские работы на строительство локальных очистных сооружений и передать результат оказанных услуг в полном объеме и в установленный договором срок, а заказчик обязался принять его и оплатить.

  Открыть документ в вашей системе КонсультантПлюс:
  Вопрос: Подскажите, имеем ли мы право в техническом задании на оказание услуг по уборке зданий указать, что исполнитель должен предоставить заказчику копии трудовых договоров тех сотрудников, которые будут оказывать услуги?
  ("Прогосзаказ.рф", 2019, N 2) Вопрос: Подскажите, имеем ли мы право в техническом задании на оказание услуг по уборке зданий указать, что исполнитель должен предоставить заказчику копии трудовых договоров тех сотрудников, которые будут оказывать услуги?

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

  Открыть документ в вашей системе КонсультантПлюс:
  "Порядок заключения и сопровождения договоров в ходе конкурсного производства (ликвидации) в отношении финансовых организаций"
  (утв. решением Правления ГК "Агентство по страхованию вкладов" от 04.12.2017, протокол N 138)
  (ред. от 04.03.2019) Приложение 1

  Читайте также:

    
  • Как пройти обучение в тинькофф инвестиции приложение и получить акции
    
  • Веб приложения на андроид что это
    
  • Как обновить приложение ютуб на телевизоре самсунг смарт тв
    
  • Как добавить приложение в автозагрузку c
    
  • Как заставить пользователя обновить приложение