В этой статье я хочу рассмотреть необходимость наличия графических прототипов в техническом задании, даже если вы, в вашем проекте, обходитесь без отдельного дизайна, а собираете интерфейс из шаблона.
Статья пригодится тем, кто часто пишет ТЗ в сервисных (работающих с внешними клиентами) и продуктовых (работающих с внутренними клиентами, в виде начальников) компаниях.
Менеджеры проектов иногда сталкиваются с недопониманием со стороны как клиентов, так и разработчиков по поводу внешнего вида интерфейса. Такое происходит, когда в качестве ТЗ существует только текстовое описание продукта, его функций, разделов, меню.
Вариант 1. Заказчик заказал индивидуальный дизайн для своего B2C проекта.
В этом случае вы проходите стандартную схему, где существуют этапы проектирования интерфейса, дизайна, верстки (фронт-енд разработки). Так как визуальное оформление сервиса здесь проходит отдельным этапом, то соответственно и согласуется уже по мере выполнения работ.
И у клиентов, и у разработчиков не возникает вопросов, где же будет стоять эта красивая красная кнопка. Все согласуется поэтапно.
Вариант 2. Заказчик использует шаблон для своего интранет проекта.
Особенности такого проекта:
Допустим это автоматизация части бизнеса, внутри компании
Доступ к кабинетам имеют только сотрудники компании
Нет необходимости отдельно рисовать пользовательский интерфейс и делать его графически уникальным, в корпоративном стиле.
В этом случае, более чем обоснованно использование шаблона, из которого собирается интерфейс, экономя время и деньги.
Заказчику важно понимать, как будет выглядеть продукт при условии разработки на шаблоне, не все обладают визуальным воображением и не могу предположить, как будет выглядеть их веб-сервис.
Кроме того, если дать команде разработки задачу – «поставить заданные функции в интерфейс», справятся с этим далеко не все, а на визуальные правки может уйти куча времени при сдаче этапа проекта.
Из моей практики, неподготовленный к такой задаче разработчик собирает интерфейс очень плохо, приходится много раз его корректировать, чтобы получить вменяемый вариант. Конечно, со временем люди учатся, и через 2-3 года интерфейс собирают почти идеальный, но не стоит всегда на это рассчитывать.
Решение проблемы
Решение лежит на поверхности и заключается в том, что в рамках написания технического задания, надо рисовать простые прототипы, в которых можно показать расположение элементов, занимаемые области на вывод контента и прочее.
Почему это часто не делается – я думаю, виной этому банальная лень, ведь на прототипы уйдет прилично времени. И тут многие менеджеры проекта не понимают – имея готовые прототипы к ним будет гораздо меньше вопросов по реализации интерфейса, а на объяснения они потратят не только свое время, но и время команды разработки, а потери компании в деньгах совокупно будут еще больше.
Почему это необходимо делать даже на маленьких проектах и взять за правило
Упростит презентацию проекта клиенту перед разработкой
Поможет поймать упущенные моменты в самом ТЗ
Поможет объяснить разработчикам расположение элементов
Ускорит процесс производства
И в итоге – увеличит доходность, пусть не на 20%, но и 2-3% тоже деньги.
На этом все, если есть мысли по оптимизации производства программных продуктов, пишите в комментариях, обсудим.