{"id":13655,"url":"\/distributions\/13655\/click?bit=1&hash=17a0e55a63bd0960d466baff29be5a6a830a9ecab9cb1a490f31f5267724efbf","title":"\u041a\u0430\u043a \u043e\u0442\u043b\u0438\u0447\u0438\u0442\u044c \u0444\u0435\u0440\u043c\u0435\u0440\u0441\u043a\u0438\u0435 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u044b \u043e\u0442 \u00ab\u043f\u0441\u0435\u0432\u0434\u043e\u0444\u0435\u0440\u043c\u0435\u0440\u0441\u043a\u0438\u0445\u00bb?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"43a94a7a-c975-5627-8453-c0ce96e38181","isPaidAndBannersEnabled":false}
Александр Антипин

Для чего нужны прототипы интерфейсов в Техническом Задании

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

Статья пригодится тем, кто часто пишет ТЗ в сервисных (работающих с внешними клиентами) и продуктовых (работающих с внутренними клиентами, в виде начальников) компаниях.

Orana Velarde

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

Вариант 1. Заказчик заказал индивидуальный дизайн для своего B2C проекта.

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

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

Вариант 2. Заказчик использует шаблон для своего интранет проекта.

Особенности такого проекта:

  • Допустим это автоматизация части бизнеса, внутри компании

  • Доступ к кабинетам имеют только сотрудники компании

  • Нет необходимости отдельно рисовать пользовательский интерфейс и делать его графически уникальным, в корпоративном стиле.

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

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

Кроме того, если дать команде разработки задачу – «поставить заданные функции в интерфейс», справятся с этим далеко не все, а на визуальные правки может уйти куча времени при сдаче этапа проекта.

Tyler Wayner

Из моей практики, неподготовленный к такой задаче разработчик собирает интерфейс очень плохо, приходится много раз его корректировать, чтобы получить вменяемый вариант. Конечно, со временем люди учатся, и через 2-3 года интерфейс собирают почти идеальный, но не стоит всегда на это рассчитывать.

Решение проблемы

Решение лежит на поверхности и заключается в том, что в рамках написания технического задания, надо рисовать простые прототипы, в которых можно показать расположение элементов, занимаемые области на вывод контента и прочее.

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

Почему это необходимо делать даже на маленьких проектах и взять за правило

  • Упростит презентацию проекта клиенту перед разработкой

  • Поможет поймать упущенные моменты в самом ТЗ

  • Поможет объяснить разработчикам расположение элементов

  • Ускорит процесс производства

  • И в итоге – увеличит доходность, пусть не на 20%, но и 2-3% тоже деньги.

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

0
Комментарии
Читать все 0 комментариев
null