Как технологическая команда может быть вовлечена в управление продуктом
Перевод статьи из блога Ask Good Product Manager.
Ссылка на статью: http://ask.goodproductmanager.com/2008/08/10/how-can-it-be-involved-in-product-management/
——перевод——↓
Вопрос: как разделять владение продуктом (product ownership) с компанией-разработчиком?
Я управляю продуктами портала по поиску работы и мой вопрос связан с владением продуктом.
Я нахожусь в компании, занимающейся управлением продуктами, и у нас есть компания-разработчик, которая ответственна за разработку в том направлении, которое было установлено менеджером продуктов. Сотрудники компании-разработчика по большей части молодые и креативные, и мы, конечно, хотим, чтобы они содействовали развитию продукта и проявляли инициативу для улучшения продукта.
Но как нам определить владение продуктом между продуктовой командой и командой разработчиков? Какие существуют лучшие практики для случая, когда менеджеры продукта и руководители разработки подчиняются разным руководителям?
Ответ Saeed Khan (On Product Management): Ключевой момент здесь – как наилучшим образом использовать креатвные таланты команды разработчиков в процессе разработки.
Сам факт того, что менеджеры продукта и команда разработчиков подчиняются разным руководителям – это не проблема, и на самом деле является более чем обычным делом в софтверной индустрии. Менеджер продукта, по существу, ответственен за определение того, что должно быть сделано и когда (т.е. расставлять приоритеты), а разработчик (в вашем случае – технологическая команда) ответственен за то, каким образом эти приоритеты могут быть реализованы с учетом заданных временных и ресурсных ограничений. Вы должны это хорошо понимать, иначе будут возникать разногласия.
Для того, чтобы максимально использовать креативные таланты команды разработчиков, вовлекайте их на стадии определения требований. Посмотрите, какие у них есть идеи, которые соответствуют поставленным бизнес-задачами, и решите, имеет ли смысл их приоритезировать.
Я предполагаю, что креативные идеи крутятся вокруг пользовательского интерфейса и дизайна? Или они затрагивают средний уровень или back end портала?
В одной компании, в которой мне приходилось работать, у нас стояла главная задача – улучшать производительность серверной части нашего продукта на 25% каждый старший (major) релиз. Решение этой задачи включало, как правило, архитектурные или внутренние изменения. Как именно это достигалось, не было определено менеджментом продукта, но мы поставили задачу архитекторам давать предложения по улучшению производительности и обсуждали совместно с архитекторами, что наиболее важно для конкретного релиза.
Это дало нам некоторые преимущества помимо самого улучшения производительности. Это вовлекло команду разработчиков в процесс работы с требованиями и гарантировало нам то, что существовали полезные, но технически сложные проекты, на которых команда разработчиков могла сфокусироваться при разработке определенного релиза.
Я не хочу сказать, что вам необходимо ставить вашей команде задачи по улучшению производительности, но вы должны просто определять некоторые высокоуровневые цели, над которыми ваша технологическая команда может немного подумать и представить варианты решения.
Один из подходов состоит в том, чтобы наладить хорошие отношения с руководителем технологической группы и совместно с ним идентифицировать нескольких ключевых людей, которые могут работать с вами более тесно и генерировать идеи по улучшению. Убедитесь, что улучшения соответствуют вашим бизнес-целям и обеспечьте понятные преимущества при работе.
В конечном счете, успех зависит от того, насколько технологическая команда будет включена в процесс, который вы осуществляете. Если они будут чувствовать, что являются частью процесса и что вы слушаете их мнение и учитываете его, где возможно, в своих планах, вы сможете получить преимущества от их креативных талантов.
