Давайте теперь рассмотрим, как создается техническое задание по шагам.

Структура приложения

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

Создание макетов

Обычно макеты делаются в специальной программе (например, Axure RP).

Макет – это то, как упрощенно выглядит интерфейс программы + описание как это должно работать.

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

Макеты можно делать простыми статичными или более сложными – динамическими. Можно сделать выгрузку в HTML и показывать клиенту не просто документ, а полифункциональный прототип сайта.

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

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

Системные требования проекта

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

  1. Браузеры. Какие браузеры надо поддерживать? Какие версии? Будут ли учитываться мобильники и планшеты?
  2. Скорость отклика и производительность. Есть ли специальные требования по производительности приложения?
  3. ПО для работы. Какую платформу и язык разработки необходимо использовать? Есть ли какие-либо ограничения по технологиям?
  4. Интеграция с внешними системами. К чему будет подключена разрабатываемая система? В каком объеме будет происходить интеграция? Какими средствами (XML, веб сервис)?
  5. Дополнительные услуги (создание бекапов, настройка назначенных заданий на сервере, проработка предметной области, поиск решений для нетипичных задач, например, парсинг).

Проработка узких мест и проектирование решений

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

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

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

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

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

Следующий блок о процессе разработки.