close
29 августа 2019

Как грамотно составить техническое задание программисту

Что такое техническое задание (ТЗ)?

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

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

  1. В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.

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

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

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

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

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

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

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

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

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

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

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

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

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

Заказчик

Менеджер проекта

Разработчики

  • Ставит задачу

  • Согласовывает ТЗ

  • Принимает работу

  • Ставит задачу разработчикам

  • Контролирует ход работы и расставляет приоритеты

  • Осуществляет взаимодействие с заказчиком и разработчиком

  • Тестирует выполненную работу (если нет тестировщиков)

  • Выполняют задание в соответствии с ТЗ

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

  • 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 новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.

Описание:

(ГДЕ?)

Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».

(КУДА?)

URL новой страницы сделать: /vash_konsultant.htm

(КАК?)

Макет новой страницы взять со страницы “Наши врачи”. Только вместо врачей будут консультанты.

(ЧТО?)

Структура страницы следующая:

  • заголовок: Ваш консультант - по центру (в стиле других заголовков страниц сайта);

  • 3 блока в ряд, имеющие поля:

1) с фотографиями продавцов размером 400*600 (выравнивание по центру);

2) Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки); 3) телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);

4) электронный адрес под телефоном (e-mail: site2@mail.ru);

5) кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url: /katalog.ru).

(ОТКУДА?)

Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.

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

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

(ГДЕ?)

Под списком консультантов, над футером.

(ЧТО?)

Три поля:

  1. Имя

  2. Номер телефона

  3. Содержание заявки

(КАК?)

Обязательные для заполнения поля: Имя и Номер телефона.

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

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

(КУДА?)

Заявку отправлять на email заказчика: info@common.com

(КАК?)

Оформление письма в свободной форме.

(ОСОБЕННОСТИ)

Защиту от ботов поставить, как на форме обратной связи.

При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие “Отправка заявки”.

(НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ)

Проверить:

  • На странице не должно быть незакрытых HTML-тегов.

  • Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280 x 1024.

  • Проверить работу в браузерах Safari, Chrome, Mozilla.

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

Онлайн SEO-сервис Labrika

Получите рекомендации для продвижения сайта на основе 178 требований поисковых систем