Заказчик и аутсорс — как перестать контролировать мониторы и начать эффективно работать

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

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

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

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

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

    Не надо так: — Дизайнер, поиграй со шрифтами.

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


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


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

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

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

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


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

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

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


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

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


    Важно: Если в ТЗ нет какой-то информации, то нет требования, а значит — разработчики будут принимать решение в свою пользу. Заказчики, лучше потратьте 3 дня, чтобы вникнуть в документ и задать все уточняющие вопросы. Скорость согласования ТЗ должна быть высокой. Не растягивайте обсуждение ТЗ на недели — это снизит качество проекта. Автор ТЗ должен помнить всё и держать в голове все версии проекта, чтобы быстро отвечать на вопросы клиента.

    После работы над ТЗ проект должен стать заказчику еще яснее, а разработка казаться все проще и проще. Имея 20–40 страниц А4 согласованными можно переходить к разработке.

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

    Кирилл Гришанин

    Кирилл Гришанин

    Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков.

    🇮🇱 Israel http://wbtech.ru/