редакции
Как составить ТЗ так, чтобы тебя понимали
Когда Клиент приходит к нам, он рассказывает свою идею, описывает, какое приложение хочет получить. Перед началом работы все его пожелания и требования фиксируются в техническом задании. ТЗ — важная часть создания приложения. Если оно будет недостаточно продуманным, то работа может затянуться на долгий срок, а команда застрянет в переделках, которые возникли из-за недопонимания между Заказчиком и Клиентом.
Что такое ТЗ
В техническом задании фиксируются все основные характеристики и требования — от внешнего вида до его функционала. Фактически здесь описывается представление о том, каким должен быть конечный продукт, чтобы было понятно двум сторонам: Заказчику и Исполнителю. Задача ТЗ — свести к минимуму разницу между ними.
Цели написания ТЗ
1. Упорядочить пожелания Клиента. Найти оптимальный способ реализации задачи.
2. Убедиться, что Команда и Клиент понимают задачу одинаково.
3. Дать Клиенту оценку, чтобы он мог ориентироваться по стоимости и срокам.
4. Подготовить документ, по которому будет работать Команда.
5. По ТЗ тестировщик и Клиент могут проверить, что реализация соответствует задаче.
Техническое задание — это юридический документ, и в случае споров, обе стороны могут на него опираться.
Как составить ТЗ в государственном стандарте не описано, там лишь указано, каким оно должно быть. Сейчас мы расскажем о требованиях и правилах, которые помогут писать технические задания.
Требования к техническому заданию
Чтобы ТЗ способствовало достижению описанных целей, оно должно соответствовать некоторым требованиям:
- Быть достаточным для того, чтобы понимать весь процесс работы программы. Какое действие за каким следует, откуда берутся данные, куда передаются, какой формат данных, какие условия, кто может это делать, что произойдет в случае успеха или ошибки.
- Быть однозначным. Формулировки должны быть «закрытыми». Здесь не может быть указано «админка должна быть удобной», так как удобство — это субъективный фактор, пишите конкретно то, какой вы ее хотите видеть. Не можете сформулировать — мы всегда подскажем и посоветуем. Если техническое задание написано неоднозначно — это приведет к бесконечным доработкам.
- Быть понятным всем участникам процесса. Включая Клиента! Не стоит перенасыщать ТЗ техническими терминами. Старайтесь писать так, чтобы даже новичок в IT понял, о чем идет речь.
- Быть компактным и иметь понятную структуру, чтобы в нем было легко ориентироваться. Высшее мастерство написания ТЗ — добиться максимального описания задачи при минимальном количестве слов.
На что еще обратить внимание при составлении ТЗ
Введите в курс дела
Опишите вашу компанию, будущего клиента приложения, его боли. Расскажите, какими способами вы пытались решить проблему, и почему эти попытки были успешными или неуспешными. Так Исполнителям будет проще вникнуть в суть работы.
Разберитесь в терминах и нюансах
Это необходимо для того, чтобы быть уверенными, что Заказчик и Исполнитель говорят на одном языке. Здесь нужно указать расшифровки терминов, которыми вы оперируете, уточнить, какой смысл вы вкладываете в них. Ошибочное понимание терминов может привести к большой проблеме.
Приведите пример, покажите конкурентов
Вставьте скриншоты и укажите ссылки тех работ, которые вам нравятся.
Уточните технические требования
Здесь нужно указать перечень функционала и список разделов, которые вы предполагаете. Также требования к юзабилити и производительности системы, различным характеристикам, требования к интерфейсам, структуре базы данных.
Требования к проверке
Укажите конкретно, как вы будете проверять готовую работу, не отталкивайтесь от абстрактных требований к продукту. Составьте чек-лист методов проверки, например:
- Скорость загрузки страницы;
- Корректное изображения;
- Проверяю правильность работы элементов интерфейса;
- Unit-тест для отдельных элементов;
- Проверка всего функционала Системы.
Правила для написания технического задания
Исходя из выше перечисленных требований , мы сформулировали несколько практических правил, как составить ТЗ:
Оформление
Это, пожалуй, самое важное в составлении не только ТЗ, но и любых текстовых документов. Наша команда этому пункту уделяет особое внимание. От форматирования и структуры зависит, насколько удобно читать ТЗ и в нем ориентироваться. Если читать и ориентироваться сложно, то каким бы хорошим не было само ТЗ, оно все равно будет порождать ошибки разработки. Из-за того, что люди не нашли нужное описание или не заметили какой-то текст.
Правила оформления:
1. Выберите хорошо читаемый шрифт и придерживайся его во всех документах. Мы используем Verdana или Roboto.
2. Не мельчите. Размер шрифта для GoogleDocs — 12, для Word — не меньше 9. Междустрочный интервал — 1,5.
3. Используйте одинаковый вид для одинаковых элементов по всему документу.
4. Выделяйте заголовки, подзаголовки, названия пунктов.
В GoogleDocs из заголовков собирается автоматически оглавление страницы и отображается слева сбоку — они сильно упрощают навигацию по документу.
5. Делайте пробелы между абзацами и пунктами. Разбивайте длинные абзацы.
Описание экранов и логики.
Обычно описание ТЗ идёт по экранам.
1. Описывайте экраны в порядке прохождения их пользователем (и в порядке отображения ссылок в меню).
2. Описывая экраны, напишите, какие элементы отображается на странице, требования к этим элементам. Укажите, откуда берутся данные, что происходит при взаимодействии с элементами. Обычно на экране имеется какое-то целевое действие. Покажите, каковы его успешные и неуспешные сценарии, что произойдет при возникновении ошибки.
3. Все однотипные элементы или действия должны работать одинаково.
4. Типовые элементы и действия, которые работают одинаково по всей программе, можно вынести в раздел Типовые элементы. Не нужно будет постоянно копипастить описание таких элементов, и это минимизирует вероятность ошибки.
5. Каждому экрану свой пункт в ТЗ. Если на экране могут возникать новые окна, всплывающие формы, переходы на другие страницы, не нужно их описывать тут. Просто поставьте ссылку на нужный пункт в ТЗ.
6. Не пишите лишнего. Если в описании какое-то слово/словосочетание можно убрать и не потерять при этом смысл, то нужно это сделать.
7. Если сложно описать текстом, можно использовать таблицы, графики, макеты, рисунки.
8. Если есть риск, что читающий может понять описание неверно, нужно добавить несколько подробных примеров.
Резюме
Все, о чем мы говорили в этой статье, поможет вам составить ТЗ, если вы планируете писать его самостоятельно . Однако, мы советуем передать составление технического задания команде разработчиков, а не заниматься этим самому. Так как у нас больше опыта, и разные специалисты посмотрят на задачу со своей стороны. Так мы учтем все, что нужно. А если Заказчик сам составляет ТЗ, то, скорее всего, перед стартом работ, команда все равно потратит время на уточнение деталей ТЗ, или вовсе придется составлять новое. А это отнимает время и деньги.
Практика показывает, что если в ТЗ все продумано, то работа будет выполнена быстрее, и она потребует меньше доработок. Тогда и сотрудничество с командой разработчиков будет приятнее!
