×Закрыть

Чи є насправді різниця між Project Manager, Product Owner та Product Manager

Незважаючи на зростання популярності і розуміння методологій управління проектами, включаючи Agile, багато людей часто плутаються у визначенні ким він хоче стати або кого шукає компанія собі в штат. У разі Project Manager, Product Owner та Product Manager ви, напевно, стикалися з плутаниною в розумінні ролей і обов’язків співробітників.

Отже, спробуємо розібратися в чому різниця і чи є вона між Project Manager, Product Owner та Product Manager?

Давайте для початку з’ясуємо, що таке «проект» і «продукт».

Проект — тимчасова активність, спрямована на створення унікального продукту або послуги.

У проекту є критерії успіху, по досягненню яких проект вважається завершеним, або коли проект припиняється у зв’язку з тим, що його цілі не будуть або не можуть бути досягнуті.

Продукт — товар або послуга, яку можна запропонувати для ринку, і яка буде задовольняти потреби користувачів.

Продукт можна покращувати і за рахунок запуску і виконання нових проектів.

В рамках одного продукту може існувати безліч підпродуктов та підпроектів.

Щоб зрозуміти роль чіткіше і мати можливість розрізняти Project Manager, Product Owner та Product Manager, давайте заглибимося в їх обов’язки, які фактично втілює кожна роль.

Project Manager

Роль Project Manager з’явилася найпершою бо була необхідність мати відповідального координатора за реалізований проект. Спочатку всі проекти слідували методології Waterfall, координуючі дії команди проекту.

Project Manager бере на себе управління певною фазою продукту або послуги, наприклад, випуском нового продукту, а також відповідає за задоволення потреб: потреб у виконанні завдань, потреби проектів та індивідуальних потреб членів команди. Але його відповідальність може бути розширена на основі додаткових обов’язків або бізнес процесів в компанії.

Основні обов’язки Project Manager’a:

  • Збір інформації
  • Організація ресурсів для проекту
  • Розуміти процеси (відповідати на питання «як?»)
  • Оновлення та статуси
  • Контроль бюджету, часу і змісту проекту (відповідати на питання «куди?» І «скільки?»)
  • командне співпрацю
  • Завершення і передача проекту замовнику

Product Owner

Роль Product Owner виникла після появи на світ методології управління проектами — Agile Project Management. Обов’язки Product Owner схожі на роль Project Manager, але Product Owner працює у відносно кращій координації з усією командою Agile. Який тип лідера буде найбільш ефективним, залежить від того, на який філософії побудований проект.

Project Manager вступає в гру, коли проект використовує більш традиційний підхід Waterfall, тоді як проект, розроблений з урахуванням гнучкого підходу Agile, буде очолюватися Product Owner. Project Manager віддають перевагу діаграмі Ганта (Gantt chart), а Product Owner віддають перевагу Agile-інструментам.

Спосіб, яким Project Manager або Product Owner вирішує завдання, повинен бути гнучким, але завжди будуть існувати деякі конкретні відмінності в підході. Ідеї, що лежать в основі ролі Product Owner і філософії управління Agile, виросли і розвинулися на основі ідей, розроблених в методі Waterfall.

Product Manager

На відміну від проекту, який може мати тимчасові рамки, сам продукт є чимось більш довгостроковим. По суті, управління продуктом обертається навколо продукту або послуги, тобто все, що може бути запропоновано ринку для вирішення проблеми або задоволення потреби.

Product Manager відповідає за успіх продукту протягом усього життєвого циклу продукту. Він зосереджує увагу більше на питанні «що?», ніж на «як?». Product Manager відповідає за довгострокове планування і відповідає за розвиток продукту.

Основні обов’язки Product Manager:

— Поверхневе знання всього того що знає Project Manager

— Глобальна стратегія продукту і створення дорожньої карти

— Знаходити болю користувачів і визначати вимоги

— UX / CustDev

— Дослідження ринку, аналітика і метрики

— Маркетинг

— Бізнес процеси та економіка продукту

У підсумку

Ролі Project Manager, Product Owner та Product Manager мають різні обов’язки і набір необхідних знань.

Основна відмінність між Project Manager та Product Owner можна знайти в напрямку проекту, яким необхідно управляти. Якщо це тип проекту, який повинен бути побудований з надійного плану, в якому викладені всі кроки в тому порядку, в якому вони повинні бути завершені до початку наступного кроку, Project Manager допоможе вам туди дістатися.

З іншого боку, проект, маючи на увазі продукт, який потребує гнучкої розробки функціоналу, то для такого проекту Product Owner буде кращим рішенням.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Це деякі компанії людям ставлять в план по розвитку одним з пунктів ’написати статтю на ДОУ’?

Бракує прикладів

Спочатку всі проекти слідували методології Waterfall, координуючі дії команди проекту.

Можно подробнее, что это за методология такая? И как она обрела такое распостронение, что ей прямо все проекты следовали.

И вот тут я очередной раз упал со стула, читая доу чан.

Я так думаю це або питання з підтекстом і суть в тому що не абсолютно всі проекти були по ватерфолу або, або я хз

Не все. В зависимости от проекта, были и итерационные подходы — названий модных не было.

ну от і я про це. Можливо Pavel хотів своїм питанням виразити своє обурення щодо «всі» проекти. Іншого виправдання я не знаходжу.
Хоча типання відповідає якості статті, вона написана ніби копірайтером по старих методичках

Ох, блин. Поищите шутки ради описание этой самой методологии. Ведь если это методология и проекты ей следовали — то должен быть гайдбук, свод правил, авторы, вот это все.

Ох, а можно мне ссылочку?

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

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3][4] although Royce did not use the term waterfall in that article. Royce presented this model as an example of a flawed, non-working model.

Т.е. вся эта «методология» — просто бабайка. Заведомо нерабочая модель, именно так изначально и описанная. Модель! Не методология. Просто сферический конь в вакууме, неприменимый на практике.

И в тему моего начального комментария: stratoplan.ru/...​blog/project-methodology (заметьте, количество людей, думающих, что они работают по «водопаду», растет с распостранением Agile).

Тобто якщо розробити продукт по системі: Вимоги, Планування, Реалізація то це буде продукт з непрацюючою моделлю і без методології розробки?
Я, звичайно ж, вдячний за роз’яснення суті але це більше схоже на «кораблі не плавають, кораблі ходять»

То что вы описали — это не система. Это перечень из трех слов

Не просто просто слова, це заголовки. Розписати можна хоч по 10 пунктів то кожній позиції, думав в цьому нема необхідності

А какой по вашему мнению методологией пользовались зодчие при постройке зданий?

ох, и правда какой?
Только вы это, поосторожнее с аналогиями, а то договоримся, что «аджайл» изобрели в 3-ем тысячелетии до н.э. ru.wikipedia.org/wiki/Ломаная_пирамида

А уж как в Киеве дома строятся — так это чистая итеративная разработка: сначала получаем документы на офисное здание, начинаем строить, в процессе перекидываем назначение земли, получаем доки на жилое малоэтажное здание, потом доращиваем этажи и пытаемся узаконить.

P.S. шутки-шутками, но мешать «производство» и «разработку» — это уже за гранью

Хорошо, тогда вот человек описывает 7 основных методологий к разработке: habr.com/...​mpany/edison/blog/269789 — и пишет, что все они рабочие

Также есть много книг, которые описывают работу данного подхода, например: bit.ly/3ovzzSp

Я согласен с тем что у людей есть путаница в дефинициях: методология, метод, методика, модель разработки (вот тут автор уже все эти подходы на зывает не методолигей, а моделью: bit.ly/3ovBtT3) и с тем, что каскадная модель не самая лучшая для разработки продукта (сама Википедия на это намекает: en.wikipedia.org/wiki/Waterfall_model), НО! это не сферический конь в вакууме и ею пользуются в реальной жизни (ваш линк на статистику это подтверждает)

Смотрите. Вот как выглядит методология: en.wikipedia.org/...​agement_Body_of_Knowledge (~600 страниц)

Методология — это не «у нас изначально было толковое ТЗ и поэтому мы не пытались из носорога сделать аиста». Методология — это довольно детальное описание процессов, практик, артефактов, исполнение которых позволяет значительно повысить ваши шансы на успех.

Ничего подобного для «водопада» нет. Ну потому, что это не методология. Это была просто модель, которую придумали, чтоб показать, что так оно не работает.

Самое главное. Вы можете утверждать, что работаете по какой-либо методологии, только если вы тщательно изучили эту самую методологию и сознательно применяете ее на практике. А если вы просто делаете как получится, а потом пытаетесь натянуть сову на глобус (было ТЗ — значит водопад, не было — значит аджайл) — то это какой-то раздел специальной олимпиады

А еще бывают конструкторы для методологий, чтобы не натягивать сову на глобус, а слепить себе то, что лучше совы натягивается.

Можете расшифровать чуть больше? А то вашу фразу можно истолковать и как
«Можно менять время итерации», и как «Вот дейли митинг мы взяли, остальное — нет, но у нас все равно скрам»

Ох блин, а зачем вы слово «методология» туда притащили?
Design Patterns: Elements of Reusable Object-Oriented Software — это методология разработки, получается? Или конструктор методологий? :)

Design Patterns: Elements of Reusable Object-Oriented Software — это методология разработки, получается? Или конструктор методологий? :)

Вас глючит. По линку Organizational Patterns of Agile Software Development (Coplien)

Меня радует ваш уровень общения :).
Я смотрел ваш линк, и меня удивило, что вы решили что это «книжка с паттернами методологий». Забавно, что в самой «книжке с паттернами методологий» слово «методология» (methodology) встречается 13 раз (в контексте отсылок к методологиям, откуда взяты паттерны).

Для сравнения, слово «шаблон» (pattern) встречается в тексте порядка 1500+ раз. Что не удивительно — книжка то про шаблоны, а не про методологию.

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

Вы используете методологии, которые не являются шаблонами?

Это очень странный вопрос.
en.wikipedia.org/wiki/Methodology
Грубо говоря, методология — это теоритическая база, которая позволяет выбрать необходимый метод решения.

Вот к примеру тот же дейли. Шаблон — это собраться в одном месте и быстренько ответить на три вопроса, передавая друг-другу маркер.

Методология же говорит о том, что у нас есть задача организации потоков информации внутри команды. А уже как эти потоки организовывать (и организовывать ли вообще) — зависит от большого количества факторов.

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

Что из этого не подходит, например, к СКРАМу? Он не является переиспользуемым решением к часто встречающимся проблемам? Не подходит для различных ситуаций?

Нет, скрам это что-то типа «Основы построения баз данных». А уже какие паттерны вы будете использовать в ходе реализации конкретной базы данных — это уже будут design patterns. Хотя как раз скрам очень жестко ограничивает набор возможных методов.

Короче — другой уровень абстракции.

То есть, в скраме дейли и ретроспективу можно заменить чем-то?

В скраме — нет. Впрочем, тут моя ошибка, — скрам это и не методология разработки.

А что это тогда? Фреймворк?
MVC тоже, вроде, начинал как фреймворк, пока не начали подобные писать на других языках.

Подписаться на комментарии