В то время как это варьируется компанией, роль менеджера по продукции обычно охватывает три области:
• Опыт (проект). Это — бывший обращенным к пользователю аспект продукта. Это означает решать, какие функции создать для пользователей — не обязательно, какие функции будут делать деньги, но которые делают для лучшего продукта.
• Технология (разработка, управление проектами). Это включает понимание реализации продукта. По крайней мере, это означает управлять расписанием и загружать на выполнениях. В более технической роли менеджера по продукции это могло бы включить работу непосредственно с разработчиками, чтобы создать спецификацию API.
• Стратегия (бизнес). Это — часть, наиболее выровненная с бренд-менеджментом. Стратегия означает решать, какие бизнес-сферы продукт должен вырастить в и почему. Это также означает запускать тесты A/B и другие эксперименты, чтобы помочь оптимизировать производительность и доход продукта.
Типы менеджеров по продукции
Так как роль варьируется компанией и имеет три отличных части, не, каждое задание управления производством — то же. Большинство менеджеров по продукции более сильно в одной или двух областях. Их области силы часто под влиянием их областей исследований и опыта прежде, чем ввести карьеру.
Кристина Уодтк предложила платформу, в которой менеджеры по продукции идентифицированы их областями силы 14, Она предлагает, чтобы, потому что менеджеры по продукции входят от другой дисциплины, они взяли разновидность той дисциплины — быть им проект, разработка или бизнес.
Очень техническая компания может хотеть менеджеров по продукции с большим количеством технического фокуса. Компания, которая продает клиентам предприятия, могла бы предпочесть менеджеров по продукции, у которых есть больше делового фокуса. Компания это стремится найти адаптацию рынка, могла бы хотеть более фокусируемых на опыте менеджеров по продукции.
Типы менеджеров могут быть разными, у них даже инструменты разные. Но если взять за основу менеджеров разрабатывающих ПО, получим Jira, Redmine и прочие не слишком различающиеся в основе инструменты. Если говорить очень грубо, то продукт это репозиторий с кодом, плюс вспомогательные артефакты позволяющие последующие модификации.
Споры о том нужно ли заниматься микроменеджментом, который предполагает глубокие познания в предметной области, или достаточно, назовём это по аналогии, макроменеджментом. Инструменты менеджмента в области ПО никак не ограничены масштабами. Скажем макроменеджер создаёт проекты, а микроменеджер прописывает мельчайшие детали, начиная с требований и вплоть до создания частей функций.
По идее микроменеджер не обязан решать задачи, он даже не обязан их ставить, ведь это обязанности бизнес-аналитика и системного аналитика. Но записать их кто-то должен, а так же следить за ходом выполнения, проверки и завершения. Почему бы тогда не делать некоторых программистов микроменеджерами.
Наставничество от опытных инженеров
Как Хоровиц утверждал в PM101, менеджер по продукции должен быть фольгой к техническому выводу. Опытный технический вывод, вероятно, работал с великими менеджерами по продукции прежде и имеет ожидания о возможностях менеджера по продукции.
Технический вывод — один из базовых людей менеджер по программному продукту работы с. У них часто есть перекрывающиеся обязанности. Во многих компаниях, обе справки, чтобы отслеживать расписания, отказы и прогресс.
То есть менеджер это человек управляющий проектом посредством инструментов. Redmine по умолчанию сделан так, что закрывает или отказывается от задачи менеджер. Разработчик может лишь поставить статус для проверки для того же обзора кода, или указать, что задача решена.
Коллега, воспитывающая
Другая тенденция в обучении управления производством — коллега, воспитывающая. Это подобно роли конференций и встреч, но с больше один на одном опыт с другим менеджером по продукции.
Один способ найти равноправного наставника через существующую сеть. Менеджеры по продукции в Юнион-Сквер Финансируемые предприятиями компании могут примениться к ее воспитывающей коллегу программе. Другие фирмы могут запустить подобные программы.
Это техника обучения называется дублирование. Выполняя вместе одну и ту же работу один человек передаёт другому знания. По окончании он начинает действовать самостоятельно и ему можно делегировать обязанности.
В общем непонятно, почему некоторые утверждают, что микроменеджмента не должно быть, потому что это якобы мешает программистам, которые как раз и должны этим процессом заниматься. И непонятно, почему макроменеджер не может выйти из среды микроменеджмента. И тот и другой навык отнюдь не абстрактны.
У Вас или у гугла, что скорее всего, крайне забавный перевод получился -- менеджер по продукции должен быть фольгой
Оставили бы лучше английский.
V>В общем непонятно, почему некоторые утверждают, что микроменеджмента не должно быть, потому что это якобы мешает программистам, которые как раз и должны этим процессом заниматься. И непонятно, почему макроменеджер не может выйти из среды микроменеджмента. И тот и другой навык отнюдь не абстрактны.
Зачем плодить сущности без необходимости -- менеджер этого, менеджер того.
Здравствуйте, Sharov, Вы писали:
S>Зачем плодить сущности без необходимости -- менеджер этого, менеджер того.
А зачем вводить роль Product Owner просто потому, что это Scrum? В том случае который описывал я разница совсем иная.
простой проект:
разработчик
проект стал больше:
разработчик
разработчик
проект стал ещё больше:
менеджер
-тимлид
--разработчик
--разработчик
--разработчик
или
менеджер
-команда
проект снова вырос:
менеджер
-команда
менеджер
-команда
проект вошёл в новую стадию:
менеджер
-менеджер
--команда
-менеджер
--команда
-менеджер
--команда
-менеджер
--команда
-менеджер
--команда
-менеджер
--команда
То есть из менеджеров, так же как и из разработчиков может выстраиваться иерархия.
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, Sharov, Вы писали:
S>>Зачем плодить сущности без необходимости -- менеджер этого, менеджер того.
V>А зачем вводить роль Product Owner просто потому, что это Scrum? В том случае который описывал я разница совсем иная.
Здравствуйте, Sharov, Вы писали:
V>>А зачем вводить роль Product Owner просто потому, что это Scrum? В том случае который описывал я разница совсем иная. S>Просто потому, что есть еще заказчик.
Вот и получаются те самые лишние сущности. Взять хотя бы систему управления вехами (milestone) в ChiliProject.
• A – главный номер версии (major version number).
• B – вспомогательный номер версии (minor version number).
• C – номер логической итерации по работе над функционалом версии A.B (build number).
• D – номер ревизии, сквозной номер назначаемый автоматически программным обеспечением хранения версий.
К примеру, первая веха полностью законченного функционала.
0.1.1 название функционала С
Назначать D для вехи неправильно, коммиты отображаются в репозитории. A и B это полный функционал на выпуск во вне.
Добавил в ChiliProject плагин для Scrum. И оказывается, что спринт это как раз и есть веха уровня С, то есть небольшого функционала. А задачи логично планировать так, чтобы они связывались с уровнем D.
Добавился dashboard, что конечно удобно, но использует он те же самые статусы задач.
Новая Рабочая Проверка Решена Закрыта Отказ
задача
задача
задача
задача
Собственно это и есть бэклог спринта, а на самом деле веха C. А задачи для него нужно брать из бэклога проекта. И здесь вообще ничего не поменялось. Был список задач (task list) проекта, а теперь нужно это называть бэклог (backlog) проекта. Ну и так далее и тому подобное.
Здесь как раз и возникает вопрос о том, что Scrum не особо и отличается от водопада с итеративным подходом. Заказчик же это совсем другой вопрос. Конечно, людям легче общаться с одним человеком, его хотя бы можно подловить на том, что такой разговор с ним уже был. Очевидно, что такой человек при древовидной иерархии менеджмента будет находится в его корне.
Другое дело, что менеджер может попутать себя с заказчиком и вести себя соответственно. И тогда получается, что он выполняет функции связи в удобной для заказчика форме, но не выполняет функции менеджера проекта.
Здравствуйте, velkin, Вы писали:
V>Споры о том нужно ли заниматься микроменеджментом, который предполагает глубокие познания в предметной области, или достаточно, назовём это по аналогии, макроменеджментом. Инструменты менеджмента в области ПО никак не ограничены масштабами. Скажем макроменеджер создаёт проекты, а микроменеджер прописывает мельчайшие детали, начиная с требований и вплоть до создания частей функций.
Вы похоже путаете менеджера продукта с менеджером проекта. Менеджер продукта должен отлично знать предметную область, но при этом ему абсолютно наплевать на "части функций".
Здравствуйте, Kerk, Вы писали:
K>Вы похоже путаете менеджера продукта с менеджером проекта. Менеджер продукта должен отлично знать предметную область, но при этом ему абсолютно наплевать на "части функций".
А я вот читал, что хорошо знать предметную область должен специалист в предметной области. Отсюда и направление в программировании DDD.
Домен (англ. domain) — область знаний. Область знаний, к которой применяется разрабатываемое программное обеспечение.
Модель (англ. model) — описывает отдельные аспекты домена и может быть использована для решения проблемы.
Язык описания — используется для единого стиля описания домена и модели.
Это эволюция подхода, когда программисты работают со специалистами в предметной области. Причём последние не являются менеджерами ни в каком виде. Так понимаю у каждой организации должен быть процесс разработки ПО в котором чётко прописана область ответственности каждой роли.
В итоге некоторые обсуждения скатываются на то, что менеджер или должен знать всё, или не должен знать ничего. У некоторых менеджер должен продавать, у других общаться с заказчиком, у третьих, ну скажем знать предметную область, у четвёртых уметь составлять бизнес-процессы, у пятых выявлять требования, у шестых проектировать архитектуру программы и так далее.
Получается прежде нужно уточнять, какой модели пытаются следовать разработчики приписывая обязанность некой роли. Что это из популярных, RUP, XP, Scrum, Kanban или многое другое, а может быть смесь. Просто я это к тому, что читал книгу, в которой специалистами предметной области были выделенные люди со стороны заказчика, в частности речь шла об электронщиках. Ни к руководству заказчика, ни к руководству программистов они отношения не имели.
Ещё часто идёт речь о недоскрам, недоруп, когда используется не чистая их вариация, а лишь некоторые из методов, оказавшиеся полезными. Понятно, что весь RUP использовать многократно сложнее, чем тот же Scrum, причём не по тех. процессу, а по числу формальностей, которые нужно соблюдать.
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, Kerk, Вы писали:
K>>Вы похоже путаете менеджера продукта с менеджером проекта. Менеджер продукта должен отлично знать предметную область, но при этом ему абсолютно наплевать на "части функций".
V>В итоге некоторые обсуждения скатываются на то, что менеджер или должен знать всё, или не должен знать ничего. У некоторых менеджер должен продавать, у других общаться с заказчиком, у третьих, ну скажем знать предметную область, у четвёртых уметь составлять бизнес-процессы, у пятых выявлять требования, у шестых проектировать архитектуру программы и так далее.
V>Получается прежде нужно уточнять, какой модели пытаются следовать разработчики приписывая обязанность некой роли.
Вроде бы в сабже роль обозначена вполне конкретно "менеджер продукта".
Это совершенно конкретная роль с управлением разработкой ничего общего не имеющая. Упрощенно говоря, менеджер продукта выполняет роль заказчика в продуктовой разработке. В аутсорсинге или заказной разработке заказчик есть, а в продуктовой разработке заказчика нет. Поэтому нужен человек, который будет знать требования рынка и ставить задачи. Этим и занимается менеджер продукта. Эта роль куда ближе к маркетингу, чем к программированию.
Здравствуйте, Kerk, Вы писали:
K>Вроде бы в сабже роль обозначена вполне конкретно "менеджер продукта". K>Это совершенно конкретная роль с управлением разработкой ничего общего не имеющая.
Кто такой менеджер продукта обозначено у меня же в комментарии, это автоматический перевод из изначальной статьи. Так что я не путаю менеджера продукта и менеджера проекта. Так написал автор обсуждаемой статьи, если что претензии к нему.
Ещё раз кратко, менеджер продукта это:
1. Опыт (проект), 2. Технология (разработка, управление проектами), 3. Стратегия (бизнес).
По изначальной статье этой темы менеджер продукта во втором пункте является менеджером проекта. Да, это именно управление разработкой. Ещё раз повторю, то что заключено в цитату, это перевод статьи, а не мои измышления. Я же сам говорю о микроменеджере проекта и макроменеджере проекта, но ничего не говорю о менеджере продукта.
Собственно говоря вернёмся к переводу статьи. Там написано, что менеджеры продукта сильны в одной, двух областях, иначе говоря следует, что эта роль сильно размыта, и получается, что в одной, двух областях менеджер продукта слаб. Вся эта размытость заставляет брать человека на одну роль с разными должностными обязанностями. Лично мне такое нечёткое деление не нравится.
Это знаете как, вы берёте на работу менеджера продукта, но один из них менеджер проекта, другой бизнес-аналитик, а третий бренд-менеджер. Потому и говорю, что нужно более чётко приписывать обязанность конкретной роли. Если надо, обозначить на одного человека несколько ролей, но чтобы с гарантией, что они их выполняет, а не — может выполнять, потому что вроде как силён на одну или две третьих в других ролях.
