Diagnosis ex juvantibus
Несколько лет назад я увидел рекламу универсального зарядного кабеля inCharge 3. Чтобы вы понимали, как он выглядит, вот:
В рекламе говорилось, что он:
- Чертовски прочен. По нему может проехать легковой автомобиль и он не сломается.
- Заменяет все остальные кабели (USB-C, USB-A, Lighting, Micro-USB), при этом компактен.
- Нормально так стоит. Мне он обошёлся в 1980 ₽
После того, как я его купил, оказалось, что:
- Он не поддерживает быструю зарядку. Как в 2020 году можно выпустить кабель без поддержки быстрой зарядки?
- Передача файлов через него происходит только в одном положении. Если вы вставите кабель не той стороной, он не будет работать.
Это называется обманутыми ожиданиями. Криворукие создатели этого кабеля решили сэкономить на распайке в надежде на то, что пользователи смирятся с недостатками гаджета. На деле они получили огромное количество требований возврата и несмываемое пятно на репутации, хотя задумка была отличная.
Работаете вы в аутсорсе или над внутренним продуктом, в управлении этими проектами управление ожиданиями очень важно. Всегда есть заказчик, у которого есть некий набор галлюцинаций о будущем продукте и если вы выдадите нечто, сильно от этих галлюцинаций отличающееся, у вас будут проблемы.
В продуктовой разработке вместо ожиданий заказчика, ожидания клиентов. Однажды мне довелось делать мобильное приложение, личный кабинет абонентов одного кабельного телеоператора. Заказчику очень понравилась программа телевещания из приложения Beeline TV и он хотел сделать это центральной фичей приложения:
У Билайна простые серые кирпичи с названиями телепередач, в нашем же приложении должны были быть картинки. На реализацию и оптимизацию этой фичи ушло огромное количество времени, всё это нещадно тормозило и глючило.
Помимо программы, в приложении были всякие сервисные функции — просмотр баланса, вызов мастера, чат с техподдержкой.
После релиза же выяснилось, что реальные клиенты хотят от такого приложения совершенно другого — просмотра эфира разных телеканалов онлайн. А программа телепередач, на которую мы убили столько времени, им не особо интересна. Единица в гугл плей, потерянные деньги и репутация.
Работа с галлюцинациями
Работа с галлюцинациями начинается с подбора правильного языка. Заказчика, скорее всего, не интересуют методы работы с кэшем, он в этом ничего не понимает, ему нужно, чтобы странички сайта грузились быстро → пользователи были довольны → товары продавались.
Кроме того, проблема может возникнуть, если вы будете называть понятные для заказчика вещи новыми, непонятными для него словами. Проблема достаточно частая, я с ней сталкиваюсь, например, в ходе собеседования. Интервьюер говорит какую-нибудь аббревиатуру и спрашивает, работал ли я с ней. Чаще всего, после объяснения термина более привычными словами оказывается, что работал, но называл иначе.
Снятие и фиксация ожиданий
В основе управления ожиданиями корректное снятие требований. Очень важно проговаривать с заказчиком цели проекта и то, как предлагаемое техническое решение с ними согласовано.
Однако не менее важно проговаривать и границы проекта, что именно в рамках проекта или итерации вы не планируете делать.
И уж совершенно точно, очень важно проговаривать ключевые риски, определять стратегии по работе с ними, согласовывать, обработка каких рисков на стороне разработчика, а за какие будет отвечать заказчик.
При обсуждении этих вещей стоит избегать слишком размытых и неформализованных формулировок, вроде «приложение должно быть достаточно быстрым» или «безопасность хранения пользовательских данных для нас наиважнейший приоритет».
Не будет лишним прочесть мою заметку о том, как не превратить сбор требований в соревнование.
Неверные ожидания обязательно нужно корректировать. В разработке клиент прав далеко не всегда.
Ну и документируйте, документируйте, документируйте. Совершенно необязательно в виде трёхсотстраничных ТЗ, можно и в виде каких-то более легковесных вещей, но все ожидания должны быть зафиксированы и утверждены. Более того, управление этой самой документацией — непрерывный процесс, он не заканчивается на этапе планирования, нужно грамотно организовать работу с изменениями.
Работа с ожиданиями команды
Каждый член команды должен чётко понимать, что именно от него требуется. Профессионалы работают вдолгую, нужно не просто сделать проект, выгореть и разбежаться, а выдавать результаты постоянно и предсказуемо.
Ваша задача как пиэма — разъяснить каждому члену команды его границы ответственности. До какой глубины должен детализировать требования аналитик, какие методы тестирования совершенно точно потребуются от QA, должен ли разработчик покрывать код модульными тестами, ну и так далее.
И всегда проговаривайте сроки, помните о SMART.
Если в рамках проекта взаимодействуют несколько отделов, вам поможет матрица взаимных ожиданий.
Прозрачность
Если не рассказывать заказчику о ходе работ, он начинает нервничать. Во времена, когда Jira ещё работала в РФ, мы использовали плагин Big Picture, чтобы сформировать диаграмму Ганта на основании существующих задач и поделиться ссылкой на неё с заказчиком. Таким образом, он постоянно, в режиме реального времени видел прогресс по задачам. Но если таких возможностей нет, можно ограничиться краткими меморандумами, раз в одну или две недели.
Также нужно проводить промежуточные демо, чтобы собрать обратную связь. Такие вещи встроены, к примеру, в сами основы скрама.
Вопросы
Для того, чтобы лучше управлять ожиданиями, пользуйтесь следующими вопросами:
- Чего ожидает заказчик и его бизнес?
- Чего хотят получить пользователи продукта?
- Что ждет заказчик от каждого специалиста и команды в целом?
- Является ли план работ актуальным и верным?
- Вы все еще движетесь к цели или стоит внести корректировки в цель / план?
В целом, это всё, что вам нужно знать об управлении ожиданиями.
