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

Почему важно зафиксировать весь процесс работы в виде технической документации?

1. В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.
2. Это сэкономит время на коммуникациях: зафиксированные технические решения избавят от многочисленных пересказов, подтверждений, путаницы в показаниях.
3. Документ позволит четко разделить зоны ответственности между сторонами проекта.
4. ТЗ дает возможность проанализировать будущий проект и выявить проблемы на стадии планирования.
5. Правильно составленное задание сделает поведение всех участников работы предсказуемым и избавит от возникновения многочисленных недоразумений.
6. С юридической точки зрения, наличие этого документа облегчит сторонам разрешение спорных моментов.
7. Техзадание делает возможным финансовое планирование, что является залогом успешного бизнеса. Заказчику будет заранее видно, на что расходуются его средства.

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

Если одна из сторон хочет сотрудничать без техзадания

Это может означать следующее:

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

Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.

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

Участники проекта

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

• Product Manager
• Руководитель проекта
• Спонсор проекта
• Тестировщики
• Технические писатели
• Кураторы
• Пользователи/потребители (например, для финального тестирования)
• И др.

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

Что дает сторонам каждый раздел ТЗ:

Раздел ТЗ	+ Для Заказчика	+ Для Разработчика
Определение цели	Осознание задач, которые решает проект или его доработка	Понимание сути задачи
Описание продукта	Представление о том, каким будет готовый продукт	Уверенность в правильном понимании конечного результата
Сроки выполнения	Ориентирование в сроках работ и получения планируемых результатов	Оценка трудозатрат и потребности в ресурсах
Бюджет проекта	Определение более-менее точной суммы затрат и планирование бюджета	Согласованный учет всех работ проекта
Перечень работ	Подробное описание работ и каждого этапа реализации проекта	Ведение работ по установленной технологии. Возможность отказаться от работ, не предусмотренных заданием, либо включить их в ТЗ за доплату
Оценка результата работ	Проверка работы проекта по программе тестирования на соответствие требованиям задания	Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ
Обслуживание проекта	Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта	Выполнение работ с учетом обслуживания проекта в перспективе
Выявление проблем	Планируемые доработки проекта	Доработка в соответствии с новыми потребностями

Последствия составления некачественного задания

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

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

Обычно разработке качественного ТЗ мешают следующие моменты:

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

Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.

Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.

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

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

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

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

Техзадание должно отвечать на вопросы:

1. Что? (какие работы, содержание элементов)
2. Где? (расположение элементов)
3. Когда? (последовательность выполнения и установленные сроки работ)
4. Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
5. Откуда? / Куда? (при переносе и т. п.)
6. Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
7. Особенности.

1. Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
2. Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
3. Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, - неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
4. Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
5. Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
6. ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.

7 типовых ошибок

1. Нечеткие цели и задачи.
2. Мало деталей в технической информации.
3. Размытые или неустановленные сроки.
4. Нет согласованности по всем вопросам между сторонами.
5. Нет регламента взаимодействия.
6. Нет ответственных лиц.
7. Нет критериев оценки результата.

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

Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.

Описание :

1. ГДЕ? Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».
2. КУДА? URL новой страницы сделать: /vash_konsultant.htm
3. КАК? Макет новой страницы взять со страницы “Наши врачи”. Только вместо врачей будут консультанты.
4. ЧТО? Структура страницы следующая:
   • заголовок: Ваш консультант - по центру (в стиле других заголовков страниц сайта);
   • 3 блока в ряд, имеющие поля:
     • с фотографиями продавцов размером 400*600 (выравнивание по центру);
     • Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки);
     • телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);
     • электронный адрес под телефоном (e-mail: site 2@ mail . ru );
     • кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url: /katalog.ru).
5. ОТКУДА? Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.

Если работы выполняются для целей SEO - не забывайте закладывать все необходимые элементы на странице.

Также внизу разместить форму заказа.

1. ГДЕ? Под списком консультантов, над футером.
2. ЧТО? Три поля:
   • Имя
   • Номер телефона
   • Содержание заявки
3. КАК? Обязательные для заполнения поля: Имя и Номер телефона. Оформление сделать по образцу формы обратной связи. Если обязательное поле не заполнено, то должно выводиться сообщение, как в форме обратной связи.
4. КУДА? Заявку отправлять на email заказчика: info @ common . com
5. КАК? Оформление письма в свободной форме.
6. ОСОБЕННОСТИ Защиту от ботов поставить, как на форме обратной связи.
   При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие “Отправка заявки”.
7. НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ
   Проверить:
   • На странице не должно быть незакрытых HTML-тегов.
   • Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280 x 1024.
   • Проверить работу в браузерах Safari, Chrome, Mozilla.

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

Павел Молянов

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.

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

Статья будет полезна:

• Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
• Менеджерам проектов.
• Руководителям диджитал-студий.
• Предпринимателям, которые планируют заказать разработку сайта.

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

Что такое техзадание и зачем оно нужно

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

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

Пользы от технического задания много. Для каждой стороны она своя.

Польза для клиента:

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

Польза для исполнителя:

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

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

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

Техзадание составляет исполнитель

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

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

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

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

Пишите однозначно и точно

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

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

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

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

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

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

Поясните сложные термины

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

Опишите инструменты и требования к хостингу

Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

Перечислите требования к работе сайта

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

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

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

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

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

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

Объясните, что будет на каждой странице

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

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

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

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

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

• Действие пользователя.
• Ответное действие сайта.
• Результат.

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

Подробнее о сценариях использования читайте в «Википедии ».

Определите, кто отвечает за контент

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

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

Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.

Опишите дизайн (если сможете)

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

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

Вместо вывода: структура техзадания

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

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

• Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
• Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

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

Комментарии разработчиков

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

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

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

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

• Информацию о компании и цель сайта.
• Требования к дизайну, цветовую гамму.
• Используемые технологии и CMS.
• Кто занимается контентом - мы или клиент.
• Структуру сайта вплоть до каждой страницы.
• Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.

Последние 2 раздела - самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.

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

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

Кто должен писать ТЗ?

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

Для чего необходимо техзадание?

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

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

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



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

1. Цель/Задача. Сформулировать то, что должно быть реализовано в конечном итоге.

2. Описание. Вкратце изложить содержание планируемых доработок.

3. Способ реализации. Детально описать методы, с помощью которых должна быть достигнута цель. Следует прописать все особенности задачи на языке программиста: регистры, справочники (создать их или отредактировать); дизайн интерфейса и т.д. Для тех, кто не знаком и лишь что-то такое слышал про специфический язык программиста, советуем не делать ненужных попыток «заговорить» на техническом языке. Т.к. описание в идеале - это сухая констатация, исключающая неоднозначность и возможность возникновения лишних вопросов. Кроме этого этот пункт может включать в себя пример, как подобное программирование было уже исполнено где-то.

4. Оценка работы. Данный пункт очень важен - в нем нужно описать трудозатраты.

Еще два важных момента: есть утвержденные стандарты к написанию ТЗ - ГОСТы. Сейчас они редко используются, но некоторые клиенты могут по старинке просить использовать и их.

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

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

Пример ТЗ для программиста

Техническое задание 1С на доработку внешней обработки


Цель
Необходимо настроить выгрузку данных из 1С в АРМ банка.


Описание

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

Выгрузка данных должна основываться на документах «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и «ВедомостьНаВыплатуЗарплатыВБанк».


Исходные данные

Имеющаяся обработка к конфигурации 1С «Зарплата бюджетного учреждения», осуществляющая выгрузку данных из документа «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и других справочников и регистров в файл DBF обмена данными с АРМ банка установленного образца.

Обработка выгружает данные в поля TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN соответствующую информацию из конфигурации 1С, предварительно занесённую в указанный документ и другие учётные таблицы. Выгружаются табельный номер, ФИО сотрудника, его паспортные и адресные данные, день рождения и гражданство.


Способ реализации

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


Оценка работы

Потребуется 5 рабочих дней работы программиста.

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

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

Гурам Сипки, основатель диджитал-студии Udix Media

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

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

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

Пример технического задания на доработку сайта

Общие сведения

Наименование автоматизированной системы

«АС СБЫТ»

Заказчик

Исполнитель

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

Плановые сроки начала и окончания работ по созданию системы

Начало работ: 01.09.2010

Окончание работ: 31.12.2010

Назначение и цели создания системы

Назначение системы

Разрабатываемая автоматизированная система предназначена для автоматизации процессов сбыта предприятия..

Цели создания системы

Цели создания автоматизированной системы

Целями разработки «АС СБЫТ»являются:

1. 3. Характеристика объекта автоматизации

3.1 Бизнес процессы предприятия

3.1. 1 Бизнес процесс «Заключение договора»

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

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

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

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

Всё, что не прописано в ТЗ разработчик делает на своё усмотрение.

· Руководство администратора;

· Руководство контент-менеджера;

· Руководство по инсталляции;

· Руководство программиста.

2.20. Организация и проведение обучения специалистов Следственного комитета при прокуратуре Российской Федерации

Предъявляются следующие требования к обучению:

· Исполнитель должен провести обучение сотрудников Следственного комитета при прокуратуре Российской Федерации в составе не более 10 чел.

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

· Помещение для обучения предоставляется Заказчиком.

· Место и время обучения должно быть согласовано с Заказчиком.

Обучение должно проводиться по всей функциональности Системы.

В рамках обучения необходимо осуществить информационное наполнение одного пилотного сайта Кольца сайтов Следственного комитета при прокуратуре Российской Федерации.

3.

Образец технического задания на доработку сайта

Важно

В процессе внедрения Исполнитель должен оказывать помощь Заказчику в рамках Графика внедрения.

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

6.2.Порядок дальнейшего сопровождения задач АС «СБЫТ».

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

В ТЗ должна быть указана трудоемкость и стоимость работ по реализации дополнительных требований.

6.2.2. Исполнитель обязуется поддерживать телефонную «горячую линию» по сопровождению программного обеспечения.

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

Это ключевая информация для разработчика (вендора), однако именно на этапе сбора требований возникает самое большое число коллизий, ошибок, излишних запросов и проч.

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

Сюда можно отнести требования к различного рода сортировкам, интеграциям с чатом, возможностям телефонии.

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

Внимание

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

Уровень технологии - последний в списке, но по важности и сложности опережающий остальные.

Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS.

Microsoft World или Microsoft Excel.

Лично мы при разработке landing page используем специальные программные продукты.

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

По теме: Прототипирование сайта: создание, инструменты и программы.

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

ЛАЙФХАКИ ПО СОСТАВЛЕНИЮ ТЗ

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

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

1.

Убедиться, что клиент и исполнитель правильно поняли друг друга».

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите.

Решили заказать сайт (он же лендинг)? Как показывает практика, это не так просто. Сотни заказчиков, увидев свой готовый сайт, обнаруживают, что он им не подходит: дизайн не тот, расположение хромает, тексты мимо, прикрутили кучу ненужных функций.

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

ОНО МНЕ НАДО?!

Неважно, кто будет исполнителем сайта – Вы сами, Ваш родственник, фрилансеры за скромную оплату, специализированная компания за огромную сумму денег…

Техническое задание на сайт должно быть.

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

Анатомия технического задания

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

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

Что касается реалистичности, то избежать просьб допилить CRM до уровня системы управления коллайдером просто: следует включать в требования то, что действительно нужно на данный момент и в обозримом будущем.

Например, RegionSoft CRM - десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании.

Полное и краткое наименования информационной Системы

Полное наименование системы – официальный интернет-сайт Следственного комитета при прокуратуре Российской Федерации.

Краткое наименование системы – «Сайт СКП», «Система», «Сайт».

1.2. Наименование заказчика системы и его реквизиты

Наименование: Следственный комитет при прокуратуре Российской Федерации

Место нахождения: г.

Инфо

Москва, Технический переулок, дом 2

Фактический адрес: А

Контактное лицо Заказчика:

Телефон: (4, (4;

Адрес электронной почты

1.3. Перечень документов, на основе которых создается Система

Государственный контракт №________________ от ___ ___________ 2010 г.

1.4.

Плановые сроки начала и окончания работ по созданию Системы

Определяются в соответствии с Договором.

2. Требования к системе

2.1.

Дата платежа

НомерПлатежа

Номер платежа в платежной системе

Сумма платежа

1. Выбрать строки файла передачи данных
2. Начать цикл по строкам файла передачи данных
3. Прочитать строку файла передачи данных
4. Получить из строки файла передачи данных код договора
5. Найти по коду соответствующий элемент в справочнике «Договоры контрагентов», если элемент не найден, то выдать сообщение « Не найден договор с кодом …»
6. Если элемент найден, то добавить строку в таблицу значений, где: «Договор» — найденный элемент, «Дата» — «Data_plat», «НомерПлатежа» — «Nomer_plat», «Сумма» — «Summa_plat»
7. После получения последний строки файла передачи данных окончить цикл
8. Для каждой строки таблицы значения создать документ «Платежное ордер поступление денежных средств».

Заполняя бриф или составляя тз на дизайн сайта, не оставляйте в нём пробелов.

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

И конечно, так происходит не всегда.

Если Вам попался грамотный специалист, то можно не волноваться за результат.

Но тут возникает другая проблема, он может сделать реально как надо, а Вам не понравится чисто субъективно. И всё будет как в известном для многих разработчиков анекдоте:

КОРОТКО О ГЛАВНОМ

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

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

При нажатии на тот или иной округ должно переходить на страницу с текстовым описанием данного округа.

· Блок «Блог Председателя» — должен представлять собой список из трех последних тем, созданных в блоге в виде названия темы и даты ее публикации. Название темы будет являться ссылкой, при нажатии которой должно перевести на страницу блога с описанием данной темы. Также в данном блоке должно размещаться видео, которое можно воспроизвести, не покидая главную страницу. У видео должна быть ссылка «Комментарии», представляющая собой количество комментариев к данному видеоизображению. Ссылка «Комментарии» должна вести на страницу блога с комментариями к представленному видео.

Нижний колонтитул должен содержать поле для поиска, информацию об авторских правах и т. д.

2.3.

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

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

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

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

Либо в графе “Дополнительная информация” обязательно укажите все Ваши пожелания, не вошедшие в ответы на вопросы.

Если эта графа отсутствует, просто допишите их в конце брифа.

VK, Google, Facebook.

3.2.2 В личном кабинете в разделе заказы добавить поле для добавления промо-кода.

3.2.3 Вместо страницы, которая приходит пользователю после запроса на восстановление пароля (вида name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=) сделать страницу (вида name.com/login/forgot/сhange_password=yes&lang=ru&USER_CHECKWORD=), которая будет отображать контент сайта, будет иметь поле «Email при регистрации», контрольная строка, новый пароль, подтверждение пароля, кнопка отправить данные.

3.2.4 При добавлении товаров в корзину должно выводиться сообщение о том, что товар добавлен в корзину.

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

Автоматизированная система «СБЫТ». Техническое задание На листахДействует с «__» ____________ 2010 г.

» _» ______________ 2010 г.

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

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

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

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

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

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

Имеется root-доступ, собственные IP-адреса, порты, правила фильтрования и таблицы маршрутизации.

Google PageSpeed Insights - это бесплатный сервис рекомендаций для веб-сайтов по ускорению отображения страницы в браузере пользователя (https://developers.google.com/speed/pagespeed/insights/).

Поисковая оптимизация (или SEO) - комплекс мер по внутренней и внешней оптимизации для поднятия позиций сайта в результатах выдачи поисковых систем по определённым запросам пользователей.

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

Внутренняя оптимизация сайта - это оптимизация текста, URL-адресов, редактирование структуры сайта, перелинковка, проверка ответов сервера.

Имеющиеся материалы Ссылки на понравившиеся сайты, а также буклеты, журналы, фотографии – что угодно, а может быть у Вас есть готовый бренд-бук. Прилагается отдельным архивом. Минимальное разрешение и устройства отображения В этом пункте укажите, с каких устройств предполагается просматривать сайт – ПК, ноутбуков, смартфонов… Мониторы ПК от 19 до 27 дюймов; Ноутбуки от 15,6 до 17,3 дюйма; Смартфоны от 3,5 до 6 дюймов; Планшеты от 7 до 12 дюймов Нужна ли мобильная версия? Да ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ Примерный набор модулей (для пользователей) В этом разделе нужно перечислить все функциональные возможности, которые Вы хотите видеть на сайте.

Это может быть корзина, фильтры каталога по разным параметрам, возможность сделать онлайн-заказ, оставить заявку на обратный звонок, подписаться на рассылку и любые другие опции Фильтры каталога по цене, по алфавиту, по производителю.
CRUпtCj9B:s»XVжб╟▌╤└u╟J_■Е╘Dj»J■╛EХHJя(гTT┬Пб╟▌╤└u╟╛#╜┘al+Кa Кqяk3┴i≈²&F╒#┐╜╙┐█ц╜IWA▓BOЬ└vOЗб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜│ц&V█7┬м3aqNYJy╕°Vжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╒▀┬y╥XuF≈≈K&ОQТё╦▒’%[н╓≥Lк"[Ц{б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚б╖~у╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚бD’═\┘*NлkZ⌡┐©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈Д7и$╔≥ Ы∙?ЬjЛ?Ч╜∙╤SQ≥╒°еHФх═с┬├6ыCЫиЪ╖Bl╢╡LэOь/РЯE∙rrмVC╪┬7┴+iSo(╦°rБ╒┴■Е4СЦг┬╨ з╖ ┘╤m°с÷Уm╦Wыmdр’%R^&╔gt╖yхDА]zт╪L╝i▌▀s_2╫J)Э+Ч©OлM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.