Давайте теперь рассмотрим, как создается техническое задание по шагам.
Структура приложения
Все начинается с того, что мы создаем структуру приложения, т.е. мы по сути выделяем роли (личные кабинеты) в системе, для каждого кабинета пишем какие функции должны быть представлены. Затем на основании этого мы определяем список страниц для каждого кабинета.
Создание макетов
Обычно макеты делаются в специальной программе (например, Axure RP).
Макет – это то, как упрощенно выглядит интерфейс программы + описание как это должно работать.
Здесь мы просто описываем то, что хочет видеть клиент + параллельно прорабатываем юзабилити. Макеты удобны тем, что клиент сразу может посмотреть примерный результат и внести коррективы по необходимости.
Макеты можно делать простыми статичными или более сложными – динамическими. Можно сделать выгрузку в HTML и показывать клиенту не просто документ, а полифункциональный прототип сайта.
Макеты имеет смысл делать только на те механизмы, которые подразумевают разработку на заказ.
Часть страниц типична для большинства проектов, и их не обязательно детально прорисовывать. Сюда относятся страница входа, смена пароль, редактирование профиля и т.д. Каждый макет должен сопровождаться пояснительным текст. Этот текст должен раскрывать суть взаимодействия пользователя с интерфейсом. Т.е. что конкретно будет происходить при нажатии кнопки или загрузки страницы и т.д.
Системные требования проекта
После того как все макеты сделаны, необходимо прописать системные требования проекта. Можно выделить следующие типы требований:
- Браузеры. Какие браузеры надо поддерживать? Какие версии? Будут ли учитываться мобильники и планшеты?
- Скорость отклика и производительность. Есть ли специальные требования по производительности приложения?
- ПО для работы. Какую платформу и язык разработки необходимо использовать? Есть ли какие-либо ограничения по технологиям?
- Интеграция с внешними системами. К чему будет подключена разрабатываемая система? В каком объеме будет происходить интеграция? Какими средствами (XML, веб сервис)?
- Дополнительные услуги (создание бекапов, настройка назначенных заданий на сервере, проработка предметной области, поиск решений для нетипичных задач, например, парсинг).
Проработка узких мест и проектирование решений
Отдельный момент ТЗ – это проработка узких мест и проектирование решений.
Первое что нужно сделать – это выявить такие места. Выявить их лучше на этапе ТЗ, т.к. в дальнейшем их проработка при уже существующей архитектуре системы может быть проблемной. После выявления узких мест вы прорабатываете решение по ним и фиксируете свой вариант решения.
Укажите в ТЗ структуру базы и распишите, как это будет работать изнутри, т.е. с точки зрения разработчика. Возможно для проработки узких мест следует привлекать самих разработчиков. Это позволит избежать проблем при реализации этих решений уже на этапе разработки.
В противоположность отсутствию ТЗ бывает так, что ТЗ пишется бесконечно, т.е. по сути проект так и не начинается. Конечно это лучше, чем не продумав начать проект. Но при этом появляются другие риски, связанные с тем, что клиент по сути не знает, что он хочет и велика вероятность, что при запуске проекта в разработку требования опять поменяются и вам надо будет их как-то увязывать с очень распухшим ТЗ.
Пишите ТЗ таким, чтобы его можно было прочитать за 1 раз. В противном случае появляются сложности с управлением документацией.
Следующий блок о процессе разработки.