КАК НАПИСАТЬ ТЗ И НЕ СОЙТИ С УМА.

Привет, друзья! В прошлом посте мы говорили о том, как сформулировать Value Propositions для вашего сервиса, т.е. высокий смысл, а сегодня поговорим о чем-то более приземленном. Если вы когда-нибудь занимались разработкой IT-сервиса, то наверняка сталкивались с техническим заданием (ТЗ).

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

💔Функциональные требования описывают, что система должна делать. Это всевозможные «хочу», «надо», «необходимо», которые касаются конкретных функций: авторизация, поиск, фильтрация, и так далее. Они отвечают на вопрос: «Что должен уметь наш сервис?»

💔Нефункциональные требования - это те, которые описывают, как система должна это делать. Это скорость работы, надежность, масштабируемость, безопасность и другие «неочевидные» аспекты. Они отвечают на вопрос: «Как наш сервис должен функционировать?»

Как описать функциональные требования?

Поговорить с заказчиком, обсудить все его «хочу» и «надо». Записывайте каждую мелочь, даже если кажется, что это и так понятно. Не бойтесь задавать уточняющие вопросы: «Как именно должна работать эта функция?», «Что должно произойти, если…?».

Шаблон описания требования:

1⃣Входной параметр
2⃣Реакция системы на него
3⃣Выходной параметр

Например, требование “Хочу чтобы была форма обратной связи” может выглядеть так:

1⃣Пользователь переходит на страницу обратной связи, вводит данные в полях таких-то и кликает на кнопку “Отправить”
2⃣Система сохраняет данное событие в таблицу со статистикой таким-то образом.
3⃣Администратор сайта получает на почту сообщение о новом запросе на сайте в таком-то формате.

Кажется, очень просто. Но тут нужно учесть очень много нюансов:

🩷Функциональные требования определяют не только конечный продукт, но и уровни авторизации. Та самая всеми “любимая” ролевая модель, которую так сложно описать.

🩷Важно учитывать бизнес-задачи, которые решает тот или иной функционал, и объем этих задач, если они повторяются. Пользователи будут оценивать ваш сервис по удобству интерфейса для выполнения конкретной задачи, тут на помощь придут и user case, и jtbd - методики. Главное - понять что даже порядок столбцов в таблице может быть разным не потому что кому-то не нравится, а потому что с такой таблицей будет неудобно работать на больших числах. Когда у вас много повторяющихся элементов (например, заказы или формы обратной связи), то уделите немного времени логике таблиц-листингов.

🩷Отчетность и внутренняя статистика - важно не забыть что события должны куда-то сохраняться и как-то использоваться впоследствии.

🩷Как и не стоит забывать о том, как вы видите процессы, происходящие внутри системы. Многие советуют отдавать право выбирать, какой будет внутренняя архитектура, подрядчикам, но на моем опыте - лучше немного погрузиться “во внутрянку” и сформулировать важные вводные самим. Так вы избежите “костылей”.

🩷Чаще всего еще на этапе формулирования ТЗ вам понадобятся прототипы. Научитесь рисовать хотя бы в фигме - это действительно очень просто и сэкономит кучу времени и нервов. Многим нужна визуализация, чтобы понять, как будет работать система.

🩷Иногда на этапе написания ТЗ потребуется привлечь … тестировщиков. Они могут помочь определить ограничения будущей системы, о которых вы даже и подумать не могли.

🩷Если в проекте есть интеграции - нужно проектировать их отдельно. И не только принцип и способ интеграции, но и сами файлы, их формат, поля, свойства значений в полях, возможное содержимое и то, как системы реагируют на то или иное содержимое файла и даже то, что будет если в ходе интеграции придут некорректные значения… В общем, тут важно учесть все.

Продолжение про нефункциональные требования - в следующем посте. Лайки автору!