Как написать ТЗ за час

Что такое ТЗ?

Документ, по которому исполнитель, сделав продукт попадет в ожидания заказчика. Но все не так просто. Попасть в ожидания невозможно без подробного описания результата, если, конечно, разработчик не экстрасенс или если у заказчика нет ожиданий.

Например, возьмем требование «При фотографировании должна вылетать птичка». Вытекающие вопросы: Какая птичка? Какого цвета? Где ее взять? В какую сторону должна вылетать? Откуда она должна вылетать? Какого размера эта птичка? Это одна и та же птичка или каждый раз новая? Почему не выбегать? Должна ли птичка чирикать? Если да, то что именно она должна чирикать?

Т.е., казалось бы, простое требование может вызвать кучу вопросов на ровном месте. Поэтому хорошее ТЗ должно максимально подробно описывать продукт, чтобы все участники однозначно понимали каким будет результат. Вот несколько критериев качества технического задания: однозначность, непротиворечивость, полнота, актуальность, читаемость.

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

Итак, мы выяснили что за час приемлемое ТЗ не написать, но за это время можно составить описание продукта, которое поможет гораздо точнее оценить стоимость разработки и вероятно самому лучше разобраться в вопросе, о чем на самом деле будет проект. А как известно, правильно поставленный вопрос — это уже половина решения.

У вас есть идея и, возможно, даже представление о монетизации. Осталось найти команду, донести до них вашу идею, определить вилку по времени и стоимости разработки. Чем лучше вы опишите проект, тем точнее будет оценка и выше шансы на успех.

Как же описать проект, чтобы вас понял разработчик? Используйте следующую структуру документа:

1. Введение. О чем продукт, его цели и ключевая идея, кто будет им пользоваться, какие проблемы пользователей решает, как эти проблемы решаются сейчас без вашего сервиса. По объему это один -два абзаца в паре-тройке предложений.
2. Бизнес процесс / процессы. Кратко своими словами, простым текстом опишите, как вы видите работу сервиса. Кто и как инициирует процесс, какую роль в нем выполняет система. Кто еще может использовать систему. Если есть сторонние сервисы, с которыми взаимодействует ваш будущий продукт, их тоже стоит указать. По объему это может занимать от половины листа А4 до 2-х листов, в редком случае больше.
3. Функции системы. В каком-то смысле это п.2 только в профиль, он позволяет посмотреть на систему глубже. Тезисно опишите функции системы относительно пользователей и сторонних сервисов, которые будут с ней работать. Возьмем для примера интернет магазин.

   Роль «Пользователь»

   • Выбирает товар в каталоге и его количество, откладывает его в корзину,
   • Оформляет заказ из корзины, указав адрес доставки,
   • Оплачивает товар через платежные системы,
   • Пишет отзывы на товар, может проставить оценку,
   • Пишет в службу поддержки,
   • Просматривает список своих заказов и статусы.

   Роль «Администратор»

   • Просматривает и отвечает на сообщения пользователей сайта,
   • Просматривает список и статусы заказов пользователей.

   Система складского учета

   • Получает из системы заявки на покупку, резервирует товар на складе,
   • Передает в систему статус заказа и количество остатков на складе.

   Платежный сервис

   • Принимает оплату от пользователя сайта,
   • Передает в систему информацию об оплате заказа
4. Позиционирование и конкуренты. Велика вероятность, что что-то подобное уже есть. Если нет, то пересмотрите Симпсонов. В этом пункте можно указать ваши сильные стороны, чем вы отличаетесь от конкурентов, почему ваш сервис лучше. Также полеsзно привести список аналогичных или близких сервисов, указав для каждого какие моменты вам в них нравятся, а какие нет.
5. Критерии успеха. Как вы будете оценивать качество продукта, какие критерии вы считаете ключевыми, какой результат от продукта ожидаете получить.
6. Общие требования. В свободной форме опишите моменты, о которых бы хотели сообщить, но им не нашлось места в предыдущих пунктах. Например, сколько пользователей будет у вашей системы сейчас и через полгода-год после релиза. Какие возможные фичи могут быть прикручены в будущем. Ожидаемые сроки. На какие языки должен быть переведен сервис и прочее.

ТОП- 5 ошибок или что делать не следует

1. Писать ТЗ самостоятельно. Не пытайтесь описать все.
   1. Это долго;
   2. Это объемно и велик шанс допустить неточности — чем больше документ, тем сложнее его читать, и легче в нем запутаться;
   3. ТЗ должны разрабатывать профессионалы. Да, именно разрабатывать, а не писать, потому что параллельно прорабатывается и проектируется функциональная логика вашего продукта и структура данных;
   4. Всеобъемлющее ТЗ может и не понадобиться на проекте. Существуют методологии, где ТЗ пишется в процессе разработки или даже после нее;
   5. Если вы упустите что-то существенное, грамотный разработчик сам уточнит у вас ключевые неоднозначные моменты.
2. Ограничивать стек технологий если для вас это не принципиально или вы не специалист. Возможно вы где-то читали, что похожие проекты реализуются на PHP, а СУБД MySQL- самая лучшая во всех отношениях. Но на самом деле, решить практически любую задачу можно несколькими способами, и выбор способа решения лучше доверить профессионалам, доверяя их опыту. О том, как выбрать команду разработки — тема отдельной статьи.
3. Сыпать терминами. Если вы пишите технический термин и не уверены в его корректности замените на что-то более обывательское. Также постарайтесь не использовать профессиональный сленг своей предметной области, для вас он будет очевидными, но не обязательно также однозначно понятен исполнителю.
4. Давать готовое решение если вы не уверены в нем. Например, вам кажется что будет круто, если модальные окна появляются по раскручивающейся спирали. Разработчики ребята простые — что написано в документе, то и сделают, т.к. как правило буквально понимают задание и не всегда подвергают сомнению написанное, ведь у них другая задача. Поэтому постарайтесь воздержаться от готовых ответов, наверняка совместно можно найти более лаконичное и простое решение. Предлагать свои варианты не запрещается, но укажите, что это всего лишь варианты и вы не против рассмотреть альтернативу.
5. Вместить все в MVP. Зачастую бюджеты и сроки проекта не резиновые. Поэтому тщательно продумайте без чего ваш продукт может существовать и выполнять ключевую функцию какое-то время, укажите в документе какие функции вы считаете наиболее важными, а какие можно оставить до следующих поставок. Тем самым, у вас будет время притереться к команде, быстро реализовать продукт и проверить его на реальном мире, при этом не потратив много времени.

Конечно, этот документ не заменит техническое задание. Однако, вы уже сможете грамотно передать идею вашего продукта команде разработки для определения объема работ, не затратив при этом много времени. Следующим этапом будет доработка вашей концепции и уточнение требований аналитиком или продуктовым менеджером, после чего можно будет пересмотреть оценку, и она станет еще точнее. А дальше, все будет зависеть от того, по какому пути реализации вы пойдете — гибкая модель разработки или каскадная, но это уже совсем другая история.