Не знаю, как вы, но я постоянно сталкиваюсь с тем, что наши внутренние клиенты (отдел маркетинга и отдел продаж) хотят внести свой посильный (правда, не всегда разумный) вклад в развитие продуктов. Stakeholder, который принимает активное участие в судьбе продукта, – подарок судьбы, но только если он разумный.

Ниже я описываю определённую часть своего опыта управления линейкой из 17 продуктов.

У нас (а также практически во всех компаниях, с которыми я сталкиваюсь) зачастую возникают интересные перегибы:

• Клиенты шлют предложения в виде функций продуктов, а не в виде требований к функциональности продуктов. Другими словами, клиент говорит тебе, что в каком-то определённом месте нужно поставить кнопку с определённой функциональностью, – но мои ребята просят не предлагаемое решение проблемы, а постановку задачи, которую нужно решить. Какую задачу решает предлагаемая кнопка? Почему кнопка, а не ссылка? А почему нельзя интегрировать эту функциональность с какой-то другой?
• Клиенты шлют письма в следующем формате: “а вот неплохо было бы сделать так, что ….” Вот сиди и гадай: то ли клиент спрашивает твоего мнения, то ли разговаривает вслух, то ли просит тебя быстро что-то сделать. Решение? Связаться с клиентом, выяснить, является ли письмо просьбой что-то реализовать, определить приоритет, а потом смотреть, когда можно внести изменение в продукт.
• Волшебным образом появляются требования, о которых никто никогда не знал, но которые, по уверению клиента, могут поднять и развить бизнес компании. Увеличение объёма работы за счёт добавления новых требований – это бич нашей профессии. Решение? Установить change control для требований к продукту. Каждый запрос должен фиксироваться, оцениваться с точки зрения влияния на продукт(ы), и последствия реализации запроса должны объясняться заказчику. Не бывает бесплатных запросов, как не бывает “быстрого тестирования” (т.е. когда происходит разработка, а потом заказчик говорит, что команда разработчиков качественная, и что они не делают серьёзных ошибок). Заказчику необходимо объяснить, что любой полученный запрос влияет на срок доставки полной версии продукта, поэтому альтернативой является приоритизация запроса.

Хуже всего обстоят дела с заказчиком, находящимся далеко. Я не говорю про аутсорсинг. Даже наш простой пример:  вся наша разработка находится в Сиднее, маркетинг и продажи находятся в Лос Анджелесе, а управление компанией осуществляется из Лас Вегаса. Ну и плюс несколько региональных офисов, которые картину не меняют. Какие дополнительные проблемы доставляет удалённый заказчик?

• Общение по поводу всех требований затруднено, т.к. отсутствует компонент личного общения. Каждый день я провожу пару часов на телефоне и час на видеоконференции, чтобы получить отклик от пользователей (которым, теоретически, продукт и нужен) – но эффективность этого невысока по сравнению с моими поездками в Лос Анджелес и Лас Вегас, когда за неделю я делаю больше, чем за месяц в Сиднее. Необходимо помнить, что это не только проблема продуктовода, но и проблема умного заказчика: заказчик должен понимать, что если он не полностью рассказал о проблеме, рассчитывать на её решение лучше не стоит.
• Отсутствует обмен информацией. В общении с удалённым заказчиком возникает замыленность взгляда – между прочим, с обеих сторон. Это выражается в том, что маркетинг считает, что продуктоводы знают все аспекты бизнеса, а продуктоводы считают, что маркетинг совершенно не знает, что на самом деле разрабатывает компания.
• Требования сообщаются в более свободной форме (хотя должно быть абсолютно наоборот). На самом деле, чем более детально объясняются требования заказчиком, тем быстрее пишутся спецификации, и тем быстрее фичи попадают в продукт.

Ну и мои любимые примеры:

• Если в компании ключевые люди не понимают разницы между корпоративным маркетингом (общением с прессой, обелением компании и т.п.) и продуктовым маркетингом (раскруткой продукта), то есть только два выхода:
  • покинуть компанию в поисках более подходящего места работы
  • попытаться минимизировать ущерб и сделать всё возможное для изменения ситуации в лучшую сторону. Правда, это не сработает, если начальник отдела корпоративного маркетинга пытается заведовать продуктовым маркетингом.
• Если с человека, ответственного за разработку, топ-менеджмент требует P&L ответственности (т.е. ответственности за финансовый успех продукта – какие деньги он приносит и сколько он стоит в плане разработки и эксплуатации), нужно что-то менять. По моим меркам, это абсолютное хамство со стороны менеджмента, т.к. подобная ответственность должна сопровождаться серьёзной финансовой компенсацией и уровнем влияния на собственно разработчиков, маркетинг и продажи.

Есть ещё ряд примеров, специфичных именно для Mobile Messenger-а, но они являются конфиденциальными. Да и не слишком часто они встречаются в обычной жизни.

А как вас бесит внутренний заказчик?