Здравствуйте, vpedak, Вы писали:

V>Например удаленный офис компании, где сотрудники подчиняются директору, который обеспечивает возможность работы (офис, легальное и юридическое обеспечение и т.д.), но при этом он ничего не понимает в том тем занимается сама компания (например разработкой софта), и есть еще конкретные менеджеры проектов и продуктов которые по работе подчиняются вышестоящим менеджерам из головного офиса. В итоге, если по работе — подчинение из головного офиса, если по офису — местный директор (эта схема ИМНО удачна и часто встречается).

Но директор в данном случае выполняет функции надсмотрщика и крыши, в процесс разработки он не вмешивается. Он собственно и не директор вообще, тем более не IT-директор. Так что все нормально.

Здравствуйте, Sshur, Вы писали:

V>>Например удаленный офис компании, где сотрудники подчиняются директору, который обеспечивает возможность работы (офис, легальное и юридическое обеспечение и т.д.), но при этом он ничего не понимает в том тем занимается сама компания (например разработкой софта), и есть еще конкретные менеджеры проектов и продуктов которые по работе подчиняются вышестоящим менеджерам из головного офиса. В итоге, если по работе — подчинение из головного офиса, если по офису — местный директор (эта схема ИМНО удачна и часто встречается).

S>Но директор в данном случае выполняет функции надсмотрщика и крыши, в процесс разработки он не вмешивается. Он собственно и не директор вообще, тем более не IT-директор. Так что все нормально.

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

Здравствуйте, Gaperton, Вы писали:


G>Он безусловно директор, а конкретнее — директор офиса. Его обязанности — управление бюджетом офиса, обеспечение всех аспектов его функционирования, включая найм специалистов и управление ресурсами. По сути, это вариант известной матричной схемы, где у сотрудников двойное подчинение по разным аспектам работы.

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

Здравствуйте, Michael_E_Smrinov, Вы писали:

M_E>Однако если судить по моему опыту — а у меня в подчинении и QA с тестерами, и архитектор, и разработчики, и тех. поддержка — по моему тащим грузы вполне нормально и за качеством следим.

Ну, может вы просто хороший человек и любите совю работу Не всегда так бывает

Вячеслав Педак

Здравствуйте, Curufinwe, Вы писали:

C>Или в вашей терминологии Team Leader играет другую роль?

ИМНО Если в проекте более чем 7-9 человек, то Project Manager вынуждет разбивать его на подгрупы и наботать не напрямую с каждым, а через руководителя группы (Team Leader). Он еще и код может писать, а вот ПМ уже не успевает это делать (да и не его это дело).

Вячеслав Педак

V>Ну, может вы просто хороший человек и любите совю работу Не всегда так бывает

Эх, спасибо Я польщен

Здравствуйте, karbon76, Вы писали:

K>Доброго времени суток!

K>У нас в компании (не IT, продукты пишем для себя), есть три проекта и, соответственно, три проджект-менеджера. Над ними стоит IT-директор. Заказчики по всем продуктам находятся внутри компании. Все пока только формируется. Вопрос в системных аналитиках по каждому проекту. Как Вы считаете, кому они должны подчиняться — непосредственно IT-директору, или проджект-менеджеру в каждой команде? Как будет лучше? И почему?

K>Спасибо!

В моей практике — аналитик не должен подчиняться PM, но такой вариант возможен в вашем случае.

Обоснование:

интересы аналитика — сделать ТЗ как можно ближе к пожеланиям заказчика, то есть как можно больше
интересы PM — сделать все как можно быстрее, чтобы рисков поменьше выплыло
интересы разработчиков — сделать всего как можно меньше, как можно меньше сложной бизнес-логики, как можно меньше сложных GUI и в таком духе.

Можно долго рассуждать что на самом деле разработчики хотят работать побольше, а PM хочет затягивать проект, но лично я спорить на эту тему не хочу, сорри. Из этой раскладки очевидно что интересы аналитика и разработки (PM и собственно девелоперы) радикально отличаются и если аналитика подчинить PM, то либо они будут непрерывно в состоянии битвы, либо интересы разработки будут превалировать над интересами аналитика (а следовательно и заказчика), второе конечно вероятнее. Особенно это заметно в случае написания "под заказ", в вашем случае возможно не будет так все грустно.

D_>интересы аналитика — сделать ТЗ как можно ближе к пожеланиям заказчика, то есть как можно больше

Не согласен. В интересах аналитика сделать ТЗ к тому же ещё и реализуемым.
Интересы PM наоборот часто раздувают проект, если в PM получает премию в зависимости от объёма выполняемого заказа. А под этот заказ он ещё может и людей выбить, а значит определённо номенклатурно вырасти (и запись в резюме: "командовал 100 людями")

Здравствуйте, D_, Вы писали:

D_>Можно долго рассуждать что на самом деле разработчики хотят работать побольше, а PM хочет затягивать проект, но лично я спорить на эту тему не хочу, сорри. Из этой раскладки очевидно что интересы аналитика и разработки (PM и собственно девелоперы) радикально отличаются и если аналитика подчинить PM, то либо они будут непрерывно в состоянии битвы, либо интересы разработки будут превалировать над интересами аналитика (а следовательно и заказчика), второе конечно вероятнее. Особенно это заметно в случае написания "под заказ", в вашем случае возможно не будет так все грустно.

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

У ПМ, если он произошел из разработчика, может сохраниться желание сделать более общо. И/или — зарезать функционал, чтобы уложиться в сроки. А у аналитика/product manager интерес — удовлеворить нужды потребителя наиболее полным образом.

Таким образом, намерения у product и project менеджеров конфликтуют. Дело не в том, что они будут находиться в состоянии войны. Дело в том, что человек по своему устройству не может оптимально и быстро решать задачу в условиях, когда намерения конфликтуют — ему тяжело как следует проработать одновременно "за" и "против", особенно в условиях ограниченного времени. Именно поэтому в юриспруденции и принято разделение на адвокатов и обвинителей. Ничего лучше человечество не придумало. Поэтому, роли правильнее разделять.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, D_, Вы писали:

D_>>Можно долго рассуждать что на самом деле разработчики хотят работать побольше, а PM хочет затягивать проект, но лично я спорить на эту тему не хочу, сорри. Из этой раскладки очевидно что интересы аналитика и разработки (PM и собственно девелоперы) радикально отличаются и если аналитика подчинить PM, то либо они будут непрерывно в состоянии битвы, либо интересы разработки будут превалировать над интересами аналитика (а следовательно и заказчика), второе конечно вероятнее. Особенно это заметно в случае написания "под заказ", в вашем случае возможно не будет так все грустно.

G>Верно и для продуктовой разработки. Причем, так: у разработчиков часто есть желание сделать более общо, и раздуть функционал. С другой стороны, они имеют склонность пренебрегать неприятными задачами, оставляя их на потом, и понижая приоритет.

G>У ПМ, если он произошел из разработчика, может сохраниться желание сделать более общо. И/или — зарезать функционал, чтобы уложиться в сроки. А у аналитика/product manager интерес — удовлеворить нужды потребителя наиболее полным образом.

G>Таким образом, намерения у product и project менеджеров конфликтуют. Дело не в том, что они будут находиться в состоянии войны. Дело в том, что человек по своему устройству не может оптимально и быстро решать задачу в условиях, когда намерения конфликтуют — ему тяжело как следует проработать одновременно "за" и "против", особенно в условиях ограниченного времени. Именно поэтому в юриспруденции и принято разделение на адвокатов и обвинителей. Ничего лучше человечество не придумало. Поэтому, роли правильнее разделять.

Роли и так разделены, речь идет о том подчинять ли аналитика PM или вышестоящему. Я за то чтобы подчинить вышестоящему.

И респект по поводу детализации мотиваций разработчиков и ПМ-а происшедшего из разработчиков — именно так все и происходит на практике.

Здравствуйте, D_, Вы писали:

D_>Роли и так разделены, речь идет о том подчинять ли аналитика PM или вышестоящему. Я за то чтобы подчинить вышестоящему.

Я — тоже. Просто решил для полноты дать пояснение — почему роли разделяются, из которого следует ответ на вопрос, почему конфликтующие роли не стоит подчиняють друг другу.