5 неочевидных болей заказчика при разработке цифрового продукта
В заказной разработке связь между бизнесом и подрядчиком поддерживает менеджер проекта (он же проджект-менеджер, он же проджект, он же PM). Этот специалист ежедневно балансирует между требованиями заказчика, руководства и команды. Вместе с тем приоритеты могут быть таковы, что некоторым задачам уделяют меньше времени. Нередко в критичные для проекта моменты работа проджекта ограничивается тем, чтобы отправить клиенту список требований к контенту или запросить токен для нового сервиса, а дальше задача становится болью заказчика.
Проджекта можно понять — команде действительно нужен токен. Но что происходит на другом конце провода? Там трудится представитель бизнеса, который ещё вчера не знал о существовании этих забот, а теперь они стали его задачами. Да ещё и с жёстким дедлайном, поскольку от проджекта уже прилетело письмо счастья: «Без токена к пятнице мы сдвигаем сроки разработки». Ты можешь быть бесконечно прав, но какой в том толк, если заказчик твой плачет? В статье разберём проблемные ситуации, с которыми может столкнуться бизнес, и самое главное — как грамотный PM может их предотвратить.
Ситуация 1. Один на один со списком требований от менеджера проекта
Разрабатывая сложный цифровой продукт, команда готовит для заказчика инструкцию по работе с системой. Иногда это могут быть видеоуроки или полноценное обучение профильных сотрудников. Но, например, составляя список интеграций, PM решает, что заказчик магическим образом поймёт по названию, какие данные и куда добавить, а самое главное — где их взять и как проверить, что они правильные.
Пример запроса от команды, который может прилететь представителю бизнеса
1) Доступы в google play console для bestpm@sitename.ru. Роль «менеджер приложения / App Manager»
2) Доступы в appstore connect для bestpm@sitename.ru
3) Доступы в FIrebase для bestpm@sitename.ru
4) Изображения продукции для главной страницы сайта. 5 шт в пропорциях как на макете “prod”
5) Токен для бота в telegram
6) Ключи и доступ к сервису смс-рассылок
Список с виду понятный, но заказчику придётся прорабатывать каждый пункт: уточнять у проджекта, гуглить самому или делегировать сотрудникам внутри компании, рискуя потерять контекст задачи.
В итоге клиент что-то подготовит, а PM это завернёт, поскольку изображения не в тех пропорциях. Например, на главной предусмотрены прямоугольные картинки, а заказчик прислал квадратные. Кто же знал, что нужно было смотреть в макеты “prod 1.01”, а не “prod”.
Что сделает суперпроджект: подготовит таблицу с комментариями, а ещё лучше — созвонится с заказчиком и разберёт её голосом.
Рассмотрим, что PM может указать в таблице, когда запрашивает контент:
- прямую ссылку на макет или референсы изображений, а также их точные пропорции;
- комментарии от дизайнера с требованиями к материалам;
- ссылку на тестовый контент, чтобы наглядно показать, как он должен выглядеть;
- требования к объёму текста, например, заголовок может содержать до 32 символов, чтобы не сломать компоновку.
Таблицу можно адаптировать под любой проект. Ключевое правило — представить, в каком виде вы бы сами хотели получить подобную задачу.
Плюсы такого подхода:
- Понятно, к кому внутри компании обратиться и по какому вопросу.
- Заказчик чувствует уверенность в результате, так как сразу видит, как будет отображаться контент.
- Клиент не волнуется, что быстро не найдёт какую-то информацию самостоятельно.
- Обе стороны могут отследить, что уже готово, а чего не хватает, и это не теряется в переписках.
- И менеджер проекта, и заказчик быстро закрывают задачу — чем не повод получить похвалу от начальства.
- Совесть проджекта не просто чиста, она сияет: ведь он действительно постарался продвинуть проект ближе к завершению и снизил риски блокеров со стороны заказчика.
Ситуация 2. Новые задачи, которые не приходилось выполнять раньше
Для примера возьмём второй пункт из таблицы выше — создать аккаунт для разработчика в магазине приложений. Эта задача актуальна для любого бизнеса, который создаёт мобильное приложение.
В таком виде заказчик может получить задачу
Доступы в App Store для bestpm@sitename.ru. Роль «менеджер приложения»
Скорее всего, клиент погуглит, как это сделать. Откроет самую популярную, но уже не актуальную статью, и перейдя App Store, столкнётся с кучей проблем. Узнает, что магазин приложений потребует документы, которых в компании в принципе нет, а ещё какой-то D-U-N-S number нужен.
Рано или поздно заказчик героически решит все задачи, но было ли это просто и быстро?
В итоге аккаунт не регистрируется в срок, дедлайн релиза сдвигается, стресс заказчика растёт. Казалось бы, команда сделала всё, что от неё зависит, и проблема на стороне заказчика. Но мы так не считаем.
Что сделает суперпроджект: подготовит пошаговую инструкцию и добавит на неё ссылку в ту самую таблицу.
Стоит предупредить заказчика обо всём, с чем ему придётся столкнуться: что потребуются документы и время на ожидание, что создание аккаунта в App Store стоит денег и платить их нужно не разработчикам, а Apple. Сообщить о комиссии с доходов от продаж подписок и о возможности её снизить. Рассказать, что магазин раз в год будет просить согласиться с новой политикой конфиденциальности, и это нормальный порядок вещей.
Важно помнить про формирование ожиданий, ведь всё, что не понравится модерации App Store, — для заказчика это тоже будет результатом работы команды.
Плюсы такого подхода:
- Страшный и непонятный App Store уже не такой непонятный, а потому и не такой страшный. Уровень стресса заказчика снижен.
- В инструкции заранее подсветили моменты, которые потребуют времени. Заказчик понимает, что за документами можно сразу обратиться к юристам, а за одобрением расходов на аккаунт Apple — в финансовый отдел.
- Команда разработки быстро получила доступы, и приложение прошло модерацию в срок.
Ситуация 3. Идея хорошая, но как её продать?
В ходе разработки появилась идея, как улучшить текущее решение, и представитель бизнеса от неё в восторге. Сложность только в том, что ему нужно согласовать бюджет на доработку с вышестоящим руководством.
Заказчик опишет идею в красках, но всё будет зависеть от его красноречия и «веса» в компании. Согласование может пройти успешно или провально, быстро или медленно. Для менеджера проекта это важный момент, но может ли он повлиять на исход?
Что сделает суперпроджект: поможет заказчику продвинуть идею. Вот как это можно провернуть:
- Спросить заказчика, почему он сам считает, что эта идея полезна для проекта, и зафиксировать ответ тезисно.
- Вместе собрать информацию, которая может прямо или косвенно доказать, что идея рабочая. Например, данные по рынку, исследования и отзывы о продуктах конкурентов, где пользователи просят реализовать похожую фичу.
- Вооружить заказчика: положить все подготовленные материалы в облако. Ссылки на прототипы, выгрузки запросов техподдержки, референсы и всё, что может быть полезно.
- Предложить свою помощь в проведении презентации.
- Высший пилотаж — когда PM сам же готовит презентацию.
Плюсы такого подхода:
- Хорошие идеи с высокой вероятностью будут согласованы, а значит, продукт станет лучше и полезнее для пользователей.
- Развитие проекта аргументировано, а значит, более вероятно.
- На практике скорость принятия решений становится быстрее.
Ситуация 4. Непонятно, как посмотреть фичу до релиза
Допустим, команда разработала крутую анимацию переходов в приложении для Android и iOS и презентовала её на демо с помощью демонстрации экрана. Заказчику всё понравилось, и он запросил материалы, чтобы «пощупать» анимацию самому и показать руководству. Чуть позже он открывает письмо от проджекта и видит: «Выслал вам приглашение в TF, вот ссылка на apk сборку приложения и на прототипы в Figma».
Тем временем мысли в голове заказчика:
- У меня нет телефона на Android, пойду спрашивать у коллег или ещё кого-то.
- На демо показывали классные анимации, но как их теперь посмотреть. Спрошу у кого-нибудь из маркетинга, они должны знать.
- Что такое TF, я вообще не знаю. Но Apple прислали письмо про test flight. Наверное, оно.
Что сделает суперпроджект:
- Расскажет, как оставлять комментарии к макетам и смотреть прототипы с анимацией в Figma. А лучше запишет видео, чтобы легко продемонстрировать функциональность при согласовании.
- Подготовит инструкцию, как устанавливать тестовые сборки приложения из TestFlight.
- Сделает скринкаст, чтобы показать, как работает Android-сборка, если у заказчика IOS-устройство. Стоит понимать, что не у всех в офисе есть два шкафа устройств для проверки разных сборок.
- Подскажет, как смотреть аналитику в AppMetrica и App Store — хотя бы самые важные показатели.
А ещё:
- Создаст для заказчика таблицу пожеланий, чтобы он мог пополнять бэклог в любой момент, а не только на специальных сессиях.
- Создаст ещё одну таблицу с багами (да, мы любим таблицы), чтобы заказчик добавлял в неё ошибки, которые сам находит. Так у него появится шаблон заполнения, и не нужно будет играть в игру «На каком устройстве воспроизводится проблема? А какая версия ОС?».
Плюсы такого подхода:
- Клиент испытывает меньше стресса, ведь доля неизвестного в его задачах снизилась.
- Все необходимые артефакты проекта точно будут увидены, услышаны и «потроганы» бизнесом. Проджект может исключить из своего будущего кейс «Анимацию согласовали, но на самом деле даже не смотрели».
- Заказчик больше погружен в свой проект.
Ситуация 5. Нужно согласовать решение сейчас, но подойдёт ли оно нам через год?
В жизни каждого проджекта бывают моменты, когда закладывается архитектура проекта и появляются технические вопросы, на которые у заказчика пока нет ответов. А решать нужно уже сейчас. Какой сервер необходим? Как будет работать рекомендательная система? Нужно ли Х, будет ли Y?
Обычно в такой ситуации заказчик оттягивает решение вопроса, так как риски высоки. Он подключает к обсуждению третьи лица, чтобы разделить ответственность за результат.
Что сделает суперпроджект: это действительно сложная задача, поскольку такие решения в любом случае должны быть за заказчиком. Однако проджект может попробовать переформулировать техническую проблему во что-то более понятное.
Как это сделать:
- Вместе с командой создать документ с разными вариантами решений, расписать их плюсы, минусы и ограничения. Рассказать о прошлом опыте и от чего должен зависеть выбор. А также предупредить, какие могут быть последствия неверного решения и как к ним подготовиться.
- Использовать контекст бизнеса заказчика и задавать ему открытые вопросы. Например, если ожидается наплыв пользователей из-за маркетинговых активностей, потребуется более мощный север. В таком случае стоит уточнить: какое количество пользователей ожидаем на старте акции, какие рекламные каналы будут подключены в этот период, как скоро в будущем планируем увеличить количество параметров системы рекомендаций, как скоро планируем подключать новые роли для пользователей.
Плюсы такого подхода:
- Даже если у заказчика нет ответов прямо сейчас, ему понятно, какую информацию нужно собрать и от чего отталкиваться при выборе решения.
- Получив ответы и обращаясь к документу от команды, заказчик сможет самостоятельно выбрать подходящий вариант на основе рекомендаций команды.
- Сроки принятия решения стали прозрачнее.
- Вероятность выбора решения, более подходящего бизнесу, стала выше.
Обратная сторона заботы
Мы много говорили о плюсах, но, как и у любого другого подхода, у предложенного нами тоже есть свои минусы:
- В смету проекта обычно не заложено время на такую поддержку.
- Шаблонов на все случаи жизни не подготовишь.
- Заказчик привыкает к заботе и начинает считать её новой нормой. Если в какой-то момент у проджекта не найдётся времени подготовить какую-то презентацию, то это может быть расценено как халтура.
- Как бы ни был хорош шаблон или инструкция, в любой момент бизнес может сказать: «Фотки будут квадратными, потому что так их сделали ещё при царе Горохе». И к этому тоже нужно быть готовым.
Как нивелировать эти минусы на своём проекте, каждый проджект-менеджер решает сам. Но сделать это точно можно — мы убедились на своём опыте.
Заключение
Проектная работа — совместный труд представителей бизнеса и разработки. Лучшей практикой считается, когда каждый привносит в проект то, в чём силён. Заказчик лучше других знает свой бизнес и цели, а исполнитель — как достичь их с помощью продуманного цифрового продукта. Работа проджекта не должна заканчиваться на получении требований и согласовании скоупа. Помочь заказчику справиться с вызовами при разработке сайта или приложения — тоже часть работы, которая двигает проект вперёд.
Если вы сталкивались со сложностями при разработке цифровых продуктов, опишите свои кейсы в комментариях, и я постараюсь разобрать их в следующих статьях.