Заказчик и аутсорс — проблемы дизайна и ТЗ на разработку

March 23 2023

На основании результата предыдущего этапа понимания проекта, аутсорсеры приступают к разработке макетов. По-прежнему правило для заказчика «мне становится все яснее и яснее» — основная метрика успешного хода проекта и контроля за разработчиками. Результат на этапе разработки макетов должен быть каждую неделю.

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

Что делать, если заказчику «не нравится»
Разумнее идти от смысла дизайна
Техническое задание на разработку

Что делать, если заказчику «не нравится»

О проблеме «мне не нравится, не знаю почему» можно написать отдельную книгу. Поделюсь советами, как постараться избежать этой проблемы:

  1. Поинтересуйтесь у заказчика, какие именно из ваших выполненных проектов ему понравились. Если это проекты одного и того же дизайнера и аналитика — берите на проект именно их. Почему? Потому что это повысит вероятность успешного выпуска проекта.
  2. В ходе обсуждений отличайте вкусовые предпочтения от смысловых, оперируйте только объективными критериями. Желательно теми, которые вы согласовали на предыдущем этапе.
  3. Заказчик со своей стороны должен задать столько ограничений дизайнеру, чтобы вариантов решений было немного — тогда и спорить будет не о чем.
  4. Мотивируйте заказчика вести диалог, если ему «не нравится». Пусть он рассказывает о мотивах, которые вынуждают его обсуждать предложенное дизайнером решение.

Не надо так:

Дизайнер, поиграй со шрифтами.

Разумнее идти от смысла дизайна

«Дизайнер, на этапе аналитики мы решили, что наша ЦА — слабовидящие старушки. Не думаю, что светло-серая Helvetica 12 размера на белом фоне будет уместна в нашем проекте. Почему ты решил использовать именно ее?»

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

Не задерживайте проект, стараясь продумать каждое состояние экрана — вы все равно что-то забудете, и что-то придется согласовывать по ходу разработки — это обычная ситуация. При работе на среднем проекте мы делаем около 100 экранов в Zeplin с различными состояниями. Имея этот результат на столе, можно переходить к разработке.

Техническое задание на разработку

Разработка начинается с технического задания, которое фиксирует все договоренности между аутсорсом и заказчиком на техническом языке.

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

В ТЗ заказчик должен видеть минимум три раздела:

  1. Модель данных — описывает все сущности, что есть в системе, и типы данных.
  2. Бизнес-логика — описывает, какие данные, где и как вводятся, обрабатываются, и какой результат получается на выходе.
  3. Взаимодействие со сторонними системами.

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

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

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

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

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

Читайте далее: Эпизод III — результат разработки.

Автор статьи
Кирилл Гришанин
Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков

Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей

    Последние статьи

    Миграция внутренних пользователей Jira в новую директорию с сохранением данных об активности

    Рассказали, как осуществили перенос пользовательских данных из Jira (Internal Directory) в директорию Microsoft Active Directory.

    Как эффективно хранить и актуализировать корпоративные данные средствами low/no-code

    Рассказали, как организовали поток HR-данных, чтобы оргструктура и бонусно-бухгалтерские расчеты всегда были актуальны.

    Мало кода, больше результативности: платформы low-code и no-code

    О low-code и no-code платформах, примерах использования и разбор нужно ли быть программистом.

    ИП Гришанин Кирилл Олегович
    ИНН 774313842609

    Коворкинг Starthub

    Б. Новодмитровская ул., 36, стр. 12, вход 6,
    Москва, Россия, 127015

    Коворкинг Wework

    Ahad Ha'am 54,Tel Aviv-Yafo,Израиль

    © 2023 WB—Tech. Мы разрабатываем уникальные решения для компаний из России, США и Европы.