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