Часто проблемы в проекте возникают из-за несогласованности действий и из-за нежелания дизайнеров и разработчиков общаться друг с другом. Руководитель Яндекс.Карт Юрий Подорожный дал три практических совета, которые помогут объединить команду общими знаниями и общими целями, а также избежать путаницы и лишней траты времени.

Создайте хранилище данных

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

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

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

Называйте макеты понятно

У нас в команде Яндекс.Карт есть общая папка с макетами на Яндекс.Диске. Там макеты разделяются сначала по операционным системам: iOS (iPhone, iPad, Watch), Android (телефон и планшет), Windows. Дальше идет разделение по разным версиям приложения. И отдельно лежат гайды. И всё это чётко обозначено в структуре и названиях папок, то же должно быть и с самими макетами. Это вы сейчас понимаете, что вы имели в виду, когда назвали файл untitled 13, но очень скоро забудете.

Нужно выработать общую систему названий, общую мнемонику, чтобы вся команда могла понять, что находится в этом файле. У нас названия строятся по такому принципу: название платформы-название элемента-действие. Например, ios-start-navigation-update. Если вам удобно, действуйте по нашему принципу, или придумайте свой. Пока мы не создали такую систему, вопрос «а где актуальные макеты?» задавали дизайнерам очень часто.

Вовлеките команду в процесс

Есть много инструментов, с помощью которых можно отслеживать аналитику и текущее состояние сервиса. Например, Fabric. Это готовая система аналитики от Twitter, с помощью которой можно следить за метриками продукта. Здесь можно посмотреть, сколько человек пользуются вашим приложением прямо сейчас, в режиме реального времени, дневную аудиторию, месячную аудиторию, процент сессий, которые завершились без падения приложения. Все это отображается в красивых понятных графиках. Доступ к аналитике должен быть у всех участников команды: и у разработчиков, и у дизайнеров, и у всех остальных. Очень здорово работает соревновательный эффект. График, доступный всем, на котором отображаются показатели работы разных команд, приводит к социалистическому соревнованию участников команды — кто быстрее победит. Это здорово работает.

Очень полезно настроить для ваших коллег рассылку ключевых показателей, чтобы каждый член команды каждый день получал в мессенджер или на почту некий отчёт о том, как чувствует себя продукт. У Fabric такая функция встроена.

Настройте рассылку отзывов из магазина приложений. Здорово было бы, если бы все члены команды, особенно разработчики, каждый день читали отзывы, опубликованные на Google Play и App Store.