Как правило, четких критериев построения ТЗ нет, оно может быть как достаточно кратким, так и весьма детализированным. Все обсуждается с подрядчиком в индивидуальном порядке.
• Краткий вариант содержит только основную информацию — ключевые и типовые экраны, страницы и их элементы, навигацию и варианты поведения данных элементов на каждом конкретно взятом экране;
• Средний представляет собой алгоритм постраничного просмотра экранов данного интерфейса, показывает связи между экранами и объясняет выбор принципа построения интерфейса в целом.
• И, наконец, «Ол инклюзив», в котом собрана вся известная информация о конкретно взятом интерфейсе.
Это на деле самый редко читаемый документ (ибо представляет неудобоваримый среднестатистическим человеческим мозгом талмуд).
Техническое задание помогает нам понять:
А) как сделан интерфейс?
Б) каким образом его применять при разработке и можно ли это сделать вообще? Вот тут-то и проявляется «Я» опытного разработчика. Как правило, его глаз уже наметан, он изначально видит, как реализовать процесс и адекватно выстроить систему. И он совсем не желает читать ТЗ, «изобретать велосипед» и работать по чьей-то схеме.
Техническое задание — это, по сути, отражение идеального интерфейса. И его нужно обсуждать: какие шаги возможны, какие отступления нежелательны, почему именно так, а не иначе.
В ТЗ прописана схема интерфейса, удобного для пользователя в данной конкретной ситуации. Обсуждение технического задания в идеале нужно начинать на этапе создания самой концепции интерфейса. Чтобы избежать дальнейшего недопонимания , желательно обсудить в первую очередь бюджет и ресурсы программы, а также технические ограничения.
Если не установить подобные рамки, фантазия может довести вас до серьезных непредвиденных затрат. Далее необходимо определить желания и потребности пользователей, которые возникнут во время работы с разрабатываемой программой, понять, с какими возможными трудностями столкнутся ваши настоящие и потенциальные клиенты.
Будут ли они пользоваться программой согласно с описанной концепцией? Возникают ли какие-либо ограничения во время работы? Существует ли возможность внедрения вообще? Если заранее, еще на стадии создания концепции, применить опыт разработчиков и прислушаться к их практическим советам, можно избежать многих не стыковок, с которыми вы столкнетесь уже после передачи ТЗ. Профит — более плотное вовлечение и мотивация разработчика. Задача упрощается, ведь он вовремя предупреждает исполнителей о нюансах работы нового или модифицированного интерфейса.
Вернемся к ранее заданному вопросу: КАК сделан интерфейс? Все ли в нем устроено так, как нужно? Нужно это, в первую очередь, пользователю (ориентируемся на него), и уже затем — требованиям разработки, бизнеса и т.п. Оба требования необходимо обсуждать и фиксировать на стартовом этапе работы, но особое внимание нужно уделить именно разработке. Технические возможности и ограничения контролируйте постоянно — с самого начала и в ходе текущих итераций. Будет проще, если вы будете заниматься этим вопросом и во время разработки концепта, и на этапе сдачи драфта. Пользовательские требования определяйте постоянно: и на начальном этапе, и во время разработки концепта. В первом случае это интервью с юзерами, а впоследствии — описание страниц интерфейса, структура навигации, профили, сценарии. В идеале интерфейс должен соответствовать поставленным требованиям и задачам, а само техническое задание — давать объяснения, каким образом и почему эти требования были учтены.
Для наглядности в ТЗ можно включить результаты пробной работы пользователей в спроектированном интерфейсе. Также мы ранее задали вопрос: можно ли (и каким образом?) применить созданный интерфейс для разработки. Это должен быть пример реального поведения интерфейса во время работы пользователя. Каким образом и почему он работает так, а не иначе, должно быть указано в ТЗ. При его написании специалист должен обратить внимание на нюансы, не очевидные в контексте прототипа в целом, и объяснить причины такого поведения. Обязательно нужно остановиться на ключевых и типовых экранах. В первом случае описать приоритетные и частные страницы интерфейса, с которыми столкнется пользователь, во втором — донести информацию об экранах с похожими функциями и назначением.
Для облегчения взаимодействия в рабочую группу необходимо (или хотя бы очень желательно) включать разработчиков, и особенно важно быть в курсе итераций при проектировании. В случае если спроектированный интерфейс работает не так, как первоначально предполагала разработка, если какие-либо команды невозможно применить так, как было задумано изначально, — здесь возможны 2 варианта ответа на вопрос, почему так происходит.
Во-первых, возможно, так удобнее пользователю, а во-вторых, вероятно, это просчет при взаимодействии с разработчиками. Технические ограничения необходимо обсуждать заранее. Бывает, конечно, пользователи просят изменить определенные элементы интерфейса, но, как показывает практика, чаще всего они привыкают к неудобствам программы или даже не предполагают, что изменения возможны. В таких случаях юзеры сами подстраиваются под особенности интерфейса. Но бывает и наоборот. Пользователь просит что-то поменять, а это технически невыполнимо. Либо заказчик требует, чтобы реклама всплывала «именно в этом самом месте, и ни в каком другом», иначе все пропало! А значит разбейся, но добейся — реклама должна быть там, где просят. Отклонения от выбранного реального «маршрута» всплывают в течение всего времени работы, особенно если их не обсудить заранее. Лучше всего предусмотреть это во время передачи спроектированного интерфейса и описать в ТЗ с возможностью корректировки. В противном случае отклонения обнаружатся на этапе разработки, и придется вносить изменения уже в процессе реализации.
Это также можно прописать в техническом задании, включив в него схему создания концепции интерфейса. Если в дальнейшем пользователи просят внести дополнительные изменения, просто обновите концепцию:
• Если на данном этапе появились новые пользователи программы — представьте их и опишите цели, которых они желают достичь;
• Зафиксируйте новые требования пользователей, бизнес-требования, а также возникающие технические ограничения;
• Добавьте необходимые пользовательские сценарии или внесите изменения в существующие;
• Проапдейте меню и структуру навигации интерфейса, а также список ключевых и типовых страниц;
• Внесите изменения в спроектированный интерфейс и, соответственно, в само техническое задание.
Теперь у вас есть возможность проверить, насколько разработанный продукт соответствует поставленным требованиям. Ну и все же, почему стоит читать ТЗ (а еще не только читать, но и активно действовать в соответствии с ним)?
1. На первом месте у нас всегда довольные пользователи (клиенты, которым удобно работать «именно так», сэкономленное время или дополнительно вырученные деньги). Ваш огромный опыт разработки — это отлично, но в данном случае пользователь важнее.
2. Опыт клиента поможет вам правильно создать интерфейс, чтобы не столкнуться с непредвиденным взаимодействием пользователя и программы.
3. ТЗ — это, по сути, тест, который отражает адекватное взаимодействие пользователя и разработанного продукта.
4. В ТЗ содержится информация, каким образом можно изменить интерфейс с максимальной выгодой для всех участвующих в процессе сторон.
