Техническое задание на создание сайта. Нюансы, которые лучше учесть сразу

В этой статье рассмотрим отдельные моменты, которые лучше учесть в самом начале проекта. Это уменьшит возможные риски проекта, а также возможно поможет избежать переработок функционала в будущем.

Оглавление

Введение

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

Нюанс 1. Метрики проекта

Проект развивается или стагнирует? Мы добиваемся своих целей на проекте или нет?
На ранней стадии эти вопросы не учитываются, и фокус внимания идет просто на создание функционала системы.

Можно заранее подумать, какие метрики будут определять здоровье проекта.

Также можно детализировать эти метрики на составляющие, чтобы понимать, как мы можем влиять на эти метрики.
Самый удобный вариант - это таблица по периодам (неделям, месяца, кварталам, годам) с возможностью проваливаться в подтаблицу по показателю. Это позволит понять, из чего сложился такой показатель за период (например, распределение по менеджерам).

В нашей платформе подобные отчеты можно сделать по этой документации.

Нюанс 2. Это нужно кому-то?

Это скорее экзистенциальный вопрос - а нужен ли вообще сервис, или отдельная его часть? Можно ли без этого обойтись?
Если острой потребности нет, то вероятно проект не выстрелит. Не так просто заставить пользователя действовать на новый лад. У него должны быть серьезная потребность или стимул в новом сервисе.

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

Нюанс 3. Нештатные ситуации

Меньше всего нам хочется думать на этапе создания системы, что пойдет что-то не так. В реальной жизни постоянно возникают ситуации, которые ранее никто не предусмотрел.
Невозможно все предусмотреть, но базовые сценарии надо попробовать проработать и заложить некоторые ручные возможности для решения проблем - это некие нетиповые операции, которые может использовать админ.

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

Нюанс 4. Логирование операций

Логи - это хорошо.
Это позволяет понять, что там произошло. Причем ситуации могут быть разные, и необходимо иметь возможность доподлинно знать последовательность событий в системе.

Также логирование позволяет в будущем строить метрики, которые мы пока не придумали.
Если этого логирования нет, то какие-то метрики в будущем мы не сможем построить (т.к. не будет в базе информации по прошедшим процессам).
Обратная сторона - это рост базы. Если слишком много логировать, то база будет быстро расти, и надо сразу подумать о том, как это лог будет очищаться по необходимости.

Нюанс 5. Дизайн

О дизайне наоборот говорят много, но по факту это не функциональное требование. Важно, чтобы дизайн помогал решать задачи пользователя. Это ключевая функция дизайна.
Не стилистика, не красивые картинки.

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

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

К примеру, мы всегда в проектах стараемся все сделать на Bootstrap 4 и без использования каких-то JS фреймворков.
Ничто не мешает добавить различные технологии на разные страницы, но поддерживать это будет сущий ад:

это будет конфликтовать где-то с ядром платформы (накладываться стили),
если технология редкая, то и поддерживать это сможет не каждый.

Мы исходим из того, что дизайн будет сделан типовыми средствами платформы - Bootstrap 4 с минимумом CSS.

Нюанс 6. API и интеграция с другими системами

Если планируются интеграции с внешними системами, то лучше сразу закладывать некое время на создание прототипа - это голый функционал подключения к методам API внешней системы.
Это необходимо, чтобы понять возможна ли интеграция в принципе, все ли работает, как заявлено в документации и это позволяет оценить внедрение самого АПИ.

В плане АПИ важно описать, какие методы будут на какой стороне и сигнатуры методов - передаваемые параметры и возвращаемый результат.

Большая ошибка в плане АПИ - неконкретность. Нельзя просто написать в ТЗ: необходимо интегрироваться с такой-то системой. Это повод для будущих конфликтов.
Необходимо обозначать более детальные границы, что куда мы будем передавать (какие объекты или команды, в какую сторону).

Нюанс 7. Учет будущей оценки ТЗ

Необходимо писать ТЗ таким образом, чтобы его было потом легко оценивать + возможно выкидывать часть требований.
Может быть ситуация, когда оценка по ТЗ сделана и заказчик решает уменьшить бюджет за счет объема. В этом случае какие-то пункты уйдут из ТЗ и оценки. Важно, чтобы это было легко сделать без долгой переработки ТЗ.

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

Нюанс 8. Неопределенные моменты

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

В целом, есть принцип построения систем, который можно взять на вооружение - если какое-то важное решение можно отложить, то его следует отложить.

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

Второй довод в пользу этого: в будущем будет больше информации, и спорное решение будет проще принять на основе нового опыта.

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

Заключение

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

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