Прожект и продакт менеджер, архитектор, тим лидер, рук.проекта, аналитик.Кто это такие???

[vbhm]

Здравствуйте!

Что-то я немного отстал от современных терминов. Я являюсь
руководителем разработчиков в одной из компаний. В оффисе у нас в во-
всю ходят термины: прожект менеджер, продакт менеджер, тим лидер,
руководитель проекта, аналитик, архитектор и т.п. А меня вроде-бы как
ждет роль то ли продакт-менеджера, то ли архитектора, то ли
руководителя проекта.

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

Поэтому вопроса два:

1) Мог бы кто-нибудь мне разьяснить, в чем состоят функциональные
обязанности вышеперечисленных ролей? Чем они отличаются? Может, есть
где-то документ, регламентирующий обязанности этих ролей?

2) Интересует, какая должность более прибыльная (в одной и той же
компании): продакт-менеджер, или архитектор?

Всем спасибо!

[Andrew Gomilko]

То что я мог наблюдать, т.е. ИМХО:
Все эти должности очень разные, а именно:

1. Product manager - формализирует требования к продукту или его части поступающие от заказчика, например в виде Use Cases. Все описывается на достаточно общем уровне, понятными для всех словами, снабжается иллюстрациями, таблицами, и т.п. На эти требования потом все опираются, и девелопмент и тестеры и сами продакты. Должен обладать отличными коммуникативными качествами, понять заказчика, понять и сформировать требования и объяснить это все девелопменту. Также должен следить за тем что б эти требования все-таки реализовывались в продукте, а не оставались на бумаге.

2. Architect -  чисто технический специалист, придумывает и прототипирует  core вещи в системе.  Должен обладать очень широким кругозором, приличным опытом разработки, иметь нюх/интуицию на "правильную" архитектуру, ну и постоянно поддерживать свой уровень технический уровень. Т.е. например знать, что может дать хорошего или плохого следующая версия какого нибудь Hibernate для разрабатываемого продукта. Ну так как архитекторов обычно меньше чем продактов должен обладать харизмой и добродушием :)

Т.е. я бы сказал что эти 2 должности очень отличаются между собой, примерно как студент исторического и радиофизического факультетов :)

[Tymur Porkuian]

> 1) Мог бы кто-нибудь мне разьяснить, в чем состоят функциональные
> обязанности вышеперечисленных ролей? Чем они отличаются? Может, есть
> где-то документ, регламентирующий обязанности этих ролей?
>
> 2) Интересует, какая должность более прибыльная (в одной и той же
> компании): продакт-менеджер, или архитектор?

Вот тут вот очень хорошо расписано:
http://www.developer.com/java/other/article.php/3490871

К сожалению, это не стандарт, и компании называют роли как хотят :)
Особенно часто переставляют девелопмент и проджект менеджера.

[vbhm]

Тогда такой вопрос:кто должен руководить проектной командой
(разработчики, дизайнеры, тестировщики и т.д.): продакт менеджер или
архитектор?

On 16 фев, 23:48, "Andrew Gomilko" <andrew.gomi...@gmail.com> wrote:
> То что я мог наблюдать, т.е. ИМХО:
> Все эти должности очень разные, а именно:
>
> 1. Product manager - формализирует требования к продукту или его части
> поступающие от заказчика, например в виде Use Cases. Все описывается на
> достаточно общем уровне, понятными для всех словами, снабжается
> иллюстрациями, таблицами, и т.п. На эти требования потом все опираются, и
> девелопмент и тестеры и сами продакты. Должен обладать отличными
> коммуникативными качествами, понять заказчика, понять и сформировать
> требования и объяснить это все девелопменту. Также должен следить за тем что
> б эти требования все-таки реализовывались в продукте, а не оставались на
> бумаге.
>
> 2. Architect - чисто технический специалист, придумывает и прототипирует
> core вещи в системе. Должен обладать очень широким кругозором, приличным
> опытом разработки, иметь нюх/интуицию на "правильную" архитектуру, ну и
> постоянно поддерживать свой уровень технический уровень. Т.е. например
> знать, что может дать хорошего или плохого следующая версия какого нибудь
> Hibernate для разрабатываемого продукта. Ну так как архитекторов обычно
> меньше чем продактов должен обладать харизмой и добродушием :)
>
> Т.е. я бы сказал что эти 2 должности очень отличаются между собой, примерно
> как студент исторического и радиофизического факультетов :)
>

> On 2/16/07, vbhm <v...@yandex.ru> wrote:
>
>
>
>
>
> > Здравствуйте!
>
> > Что-то я немного отстал от современных терминов. Я являюсь
> > руководителем разработчиков в одной из компаний. В оффисе у нас в во-
> > всю ходят термины: прожект менеджер, продакт менеджер, тим лидер,
> > руководитель проекта, аналитик, архитектор и т.п. А меня вроде-бы как
> > ждет роль то ли продакт-менеджера, то ли архитектора, то ли
> > руководителя проекта.
>
> > Мне стыдно признаться, но у меня нет четкого понимания, что это за
> > роли, и каковы их ответственности. Есть только приблизительное
> > понимание. Искал через гугл, через яндекс, так и не смог найти такой
> > информации.
>
> > Поэтому вопроса два:
>
> > 1) Мог бы кто-нибудь мне разьяснить, в чем состоят функциональные
> > обязанности вышеперечисленных ролей? Чем они отличаются? Может, есть
> > где-то документ, регламентирующий обязанности этих ролей?
>
> > 2) Интересует, какая должность более прибыльная (в одной и той же
> > компании): продакт-менеджер, или архитектор?
>

> > Всем спасибо!- Скрыть цитируемый текст -
>
> - Показать цитируемый текст -

[Alexander Ogol]

В зависимости от процесса, который Вы применяете.
Например, в MSF на разных фазах разработки ответственными являются разные
роли.

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

[Andrew Gomilko]

Тут опять пропущена роль Project Manager, он то и руководит проектной командой (ну опять, же то что я мог наблюдать). Архитектор, это не роль управленца, это инженерная роль.

[Max Ischenko]

Привет,

On 2/16/07, vbhm <vb...@yandex.ru> wrote:

Здравствуйте!

Что-то я немного отстал от современных терминов. Я являюсь
руководителем разработчиков в одной из компаний. В оффисе у нас в во-
всю ходят термины: прожект менеджер, продакт менеджер, тим лидер,
руководитель проекта, аналитик, архитектор и т.п. А меня вроде-бы как
ждет роль то ли продакт-менеджера, то ли архитектора, то ли
руководителя проекта.

1) Мог бы кто-нибудь мне разьяснить, в чем состоят функциональные
обязанности вышеперечисленных ролей? Чем они отличаются? Может, есть
где-то документ, регламентирующий обязанности этих ролей?

Роль "продакт менеджер" ввели в жизнь майкрософтовцы по-моему. Этот человек общается с конечным потребителем (или его прокси в виде сейлзов/маркетинг) и "синхронизирует" его с разработчиками. Он же отвечает, по идее, за релиз продукта/линейки продуктов и координирует работу проектных групп.

Если "прожект" == "продукт", то прожект менеджер играет и роль продакт менеджера.

Сугубо мое личное мнение, в интернете какой-то приличной классификации не нашел.

Разве что RUP: http://www-128.ibm.com/developerworks/rational/library/apr05/crain/index.html

2) Интересует, какая должность более прибыльная (в одной и той же
компании): продакт-менеджер, или архитектор?

Я думаю это можно узнать только в вашей компании. Фраза "я хочу больше зарабатывать" может быть хорошим началом разговора.       ;)

[Art...@gmail.com]

в MSF: http://www.microsoft.com/rus/docs/msdn/msf/MSF_team_model_rus.doc
Советую изучить понятия "позиция", "должность", "роль" и
"деятельность". Модели процессов разработки ПО обычно оперируют
ролями.

Более прибыльной является та должность, за которую руководство Вашей
компании больше платит ;) А какие у этого руководства критерии - Вы
скорее всего знаете лучше, чем сторонний человек.

[vbhm]

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

On 17 фев, 16:15, "Andrew Gomilko" <andrew.gomi...@gmail.com> wrote:
> Тут опять пропущена роль Project Manager, он то и руководит проектной
> командой (ну опять, же то что я мог наблюдать). Архитектор, это не роль
> управленца, это инженерная роль.
>

> > > - Показать цитируемый текст -- Скрыть цитируемый текст -

[Andrew Gomilko]

Наверное тот человек у которого меньше работы окажется и больше свободного времени на это :)
Но мне кажется что тяжело совмещать product менеджмент и project. Продакты обычно отображают
желания заказчика и хотят что б в разрабатываемой системе было больше изменений, больше
новых возможностей. А проджекту нужно правильно распределить ресурсы между командами
и распланировать все события (когда и кто к чему приступает, когда планируется завершение).
Получается что эти люди концентрируются на разные стороны, к заказчику и к команде разработчиков,
и преследуют несколько противоположные цели - успеть побольше (product manager), и успеть в срок
и с наличными ресурсами (project manager).

Т.е. я бы в этом случае сделал бы две отдельные должности - product и project менеджеры, а архитектуру
отдал бы какому нибудь тим-лиду или project manager-у.

Хотя, я думаю что если недостаточно ресурсов сделать все отдельными должностями, то нужно просто
прикинуть какие роли нужнее всего, а какие можно опустить или совместить.

> > > Т.е . я бы сказал что эти 2 должности очень отличаются между собой,

[Vladimir Vinnitsky]

день добрый.

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

 

плюс несколько слов вообще по теме.

роли не могут рассматриваться вне процесса разработки: когда говорят роль, то это значит что она должна выполнять или принимать участие в выполнении активностей в рамках процесса, а значит у нее есть функцональные обязанности, есть цель, есть набор артефактов, которые должна производить и т.д.. все это в той или иной степени и есть процесс разработки. устраиваясь на новое место работы, как правило, первое что я српашиваю на собеседовании как понимает сам работодатель ту роль на которую открыта данная позиция. мое знание обязанностей роли в процессах MSF или RUP, не помогает, потому что работодатель редко различает эти процессы вообще :-) он называет тот набор функциональных обязанностей, которые по его мнению ему же и нужны той ролью, какая, по его мнению, этому лучше всего соответствует - т.е. получается такая себе галюцинация на налюцинацию :-) при этом не сильно утруждая себя пониманием рекомендуемых процессов разработки вообще и тех ролями из которых он называет открытую ним позицию. по этому, в качестве совета, просто выясняйте у роботодателя, что он подразумевает под той или иной ролью.

 

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

 

что качается второго вопроста, то здесь все значительно сложнее... но я попытаюсь дать универсальный, с моей точки зрения, ответ на сколько это возможно: прибыльней может быть та роль ошибка которой будет стоить компании дороже... суть ответа в том что чем более дорогостоящие решения вы упономочены принимать, или скорее влиять, потому как обычно используется механизм коллегиального принятия решения, для защиты от ощибки одного человека, тем компетентней компания ищет сотрдника, тем дороже бужет его заработкая плата.  примеры с деталями могу написать отдельно, если будет интересно, дабы не спамить и так много написал :-)

так же смотрите или роль разделяемая или нет, потому как если разделяемая то могут кидать с проекта на проект, а это чревато переключением контекстов :-)
 

On 2/16/07, vbhm <vb...@yandex.ru> wrote:

Здравствуйте!

Что-то я немного отстал от современных терминов. Я являюсь
руководителем разработчиков в одной из компаний. В оффисе у нас в во-
всю ходят термины:

 

 

 

прожект менеджер,

RUP:

MSF:

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

 

продакт менеджер,

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

подчиняется IT директору

 

тим лидер,

это можно сказать придумка HRов :-)

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

подчиняется IT менеджеру проекта

 

руководитель проекта,

то же что и прожект менеджер только на русском :-)

 

аналитик,

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

подчиняется менеджеру проекта, но является разделяемым ресурсом.

 

архитектор

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

в зависимости от роли архитектора

или

подчиняется IT директору, является разделяемым ресурсом

или

подчиняется менеджеру проекта, но является разделяемым ресурсом.

 

т.п. А меня вроде-бы как
ждет роль то ли продакт-менеджера, то ли архитектора, то ли
руководителя проекта.

 

если компания маленькая то могут все вмести роли ждать :-) а деньги будут платить как за одну.. :-) а если серьезно, то между ролями должен соблюдаться конфликт интересов.