Лучший в своём классе продакт-менеджер. Часть 1: Столп «Политика»

В своей недавней серии статей я сформулировал 42 вопроса, на которые продакт-менеджер должен обеспечить ответы в рамках следующих фаз жизненного цикла разработки ПО (SDLC):

  • Product Strategy – зачем существует продукт и какие цели он преследует
  • Product Roadmapping – укрупнённый график вывода будущих возможностей продукта
  • Initiative Planning – определение проекта для реализации функциональности в рамках бюджета и сроков
  • Solution Design – проектирование людей, процессов, систем и политик, необходимых для реализации функциональности
  • Solution Development – разработка решений (люди, процессы, системы, политики), готовых к тестированию, обучению и подготовке к внедрению
  • Solution Readiness – подтверждение готовности всех аспектов решения к запуску

Основа этих 42 вопросов — роль продакт-менеджера как стeward бизнес-системы (попечителя бизнес-системы). В её основе лежат четыре ключевых столпа:

  • Policy (Политика) – корпоративные и регуляторные правила, которым должна соответствовать бизнес-система
  • People (Люди) – навыки и знания, необходимые для функционирования системы
  • Process (Процессы) – человеческие действия с технологиями и без них
  • Technology (Технологии) – автоматизация, поддерживающая систему

По моему опыту, продакт-менеджер высшего уровня обеспечивает фокус на всех четырёх столпах на протяжении всего SDLC и добивается того, чтобы итоговая бизнес-система отражала согласование, а иногда и осознанные компромиссы между ними.

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

Что такое «политика»?

Dictionary.com даёт следующие определения:

  • Чёткий курс действий, принятый ради целесообразности
  • Курс действий, принятый и реализуемый правительством или организацией
  • Действия, соответствующие принципам благоразумия или целесообразности
  • Благоразумие, предусмотрительность

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

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

При этом я разделяю политики на три категории:

  1. Организационные политики

Применяются ко всем функциям организации.

  1. Политики подразделений

Применяются к одному или нескольким подразделениям, но не ко всей организации.

  1. Регуляторные политики

Устанавливаются государственными органами и обязательны к исполнению.

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

Что делает продакт-менеджер высшего уровня в части политики?

Вот несколько ключевых принципов:

  1. Политики находятся «под рукой»

Простой вопрос: знаете ли вы, где найти политики вашей организации и можете ли быстро получить к ним доступ?
По моему опыту, большинство продакт-менеджеров вынуждены искать их в последний момент.

  1. Изменения политик проходят оценку влияния

Продакт-менеджер должен отслеживать изменения политик и понимать, как они влияют на:

  • уже работающие системы
  • системы в разработке
  1. Новые системы проверяются на соответствие всем политикам

При проектировании необходимо пройтись по каждой политике и убедиться, что требования учтены.

Я предпочитаю принцип «лучше проверить лишний раз», чем предположить, что политика не влияет на систему. Лучше потратить время на раннем этапе, чем исправлять ситуацию позже.

  1. Изменения политик рассматриваются как элементы разработки

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

  1. Чётко определены лица, принимающие решения по политике

Продакт-менеджер должен понимать:

  • кто принимает решение об изменении политики
  • кто затрагивается этим изменением
  • кто принимает решение, а кто просто информируется

Я видел ситуации, когда руководитель считал себя лицом, принимающим решение, хотя фактически был лишь информируемой стороной. Раннее прояснение ролей экономит массу проблем в будущем.

  1. Политики включены в тестирование и обучение

Даже если политика не менялась, но входит в зону внедрения, её необходимо включить в пользовательское тестирование и обучение.

Пользователи должны видеть реальность своей будущей работы — а политика является её неотъемлемой частью.

Заключение

Вы можете не соглашаться с моей трактовкой или классификацией политик — это нормально.

Но основной вывод остаётся неизменным:

Продакт-менеджер обязан понимать политики и обеспечивать их отражение в решении бизнес-системы.

Игнорирование политик может привести к созданию системы, которая окажется несогласованной или даже конфликтующей с правилами, которые её регулируют.