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

G>Эта схема дает больше прозрачности, что по канонам темных исскуств как раз вредно — интригу замутить меньше возмжностей. А что до того, что на кого свалить — так это вопрос желания и техники.

G>Вообще — если говорить с позиции светлых исскуств — а именно, командообазующих факторов, — доверие — необходимый элемент команды. Если участники сразу подходят друг к другу с недоверием — и думают, как на них кто-то что-то начнет валить — то это уже нехорошая, "темная" установка. Не есть правильно, на мой взгляд.

Кстати, а ведь отличная идея. Действительно, тьма не может существовать без света, а зло — без добра. Как можно называть исскуства "темными" — не имея их противоположности?

Так вот, теперь у меня в голове все встало на свои места. Все просто. Исскуство командной работы и все вокруг этого, когда на первый план выходит "мы", — это "светлые" исскуства. Исскуство индивидуализма и личной выгоды — "темные" исскуства.

На самом деле тут есть казус — "темные" исскуства вполне может быть команднй игрой . Но это не важно — это как инь и янь, плавно перетекает одно в другое и взаимно проникает. Диалектика. На самом деле — грамотный руководитель должен в равной степени владеть обоими исскуствами, чтобы суметь и создать команду, и отстоять ее интересы, и, что немаловажно, сохранить команду. "Темное" и "светлое" — это условности, две половинки одного и того же. Одно людей разобщает и обманывает — другое — объединяет и укрепляет доверие. Вот.

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

M_E>Мне так кажется, что в проекте много также других важных стратегических ролей (например, менеджер по качеству), но ведь они подчиняются руководителю проекта? Точно также и системный аналитик.

Если под руководителем проекта подразумевается Product Manager — то да, но никак не Project Manager. Не дай бог если QA подчиняется Project Manager. Тогда никто и никогда толком качество проверять не будет.

M_E>У меня создалось впечатление, что у вас под руководителем проекта понимается ведущей разработчик (возможно у вас он же и архитектор), что неверн

Product Manager — это перец что думает в терминах продукта целиком (как он позицируется на рынок, какие бизнес требования и т.д.). Он вообще вполне может быть не техническим спецом. Project Manager — вот он уже даски на разработку выдает и за прогрессом следит именно разработки, есть еще аналитики и QA сбоку.

Грубо говоря, Product Manager задает направление куда идти, аналитики прокладывают маршрут по карте, программисты во главе с Project Manager тащят груз в указанныю точку, а QA проверяет дошли или нет



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

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

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

Не размыванию, а распределению. При данной схеме аналитики ставят ТЗ, исследуя бизнес-процессы. Их роль, кстати, можно совместить с поддержкой пользователей. Они отвечают за адекватное отражение бизнес-потребностей. Их же при желании сократить команду можно совместить с тестерами и поддержкой пользователей.

Проджект лиды выполняют проект в соответствии с ТЗ — естественно, они могут спорить с аналитиками по поводу ТЗ — но прогнуть они аналитиков не могут — так же, как и аналитики их. Они должны прийти к согласию. Нормальная схема, посмотрите как сделано в Майкрософте — там в параллели находятся program manager, руководитель программеров и руководитель тестеров.

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

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

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

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

Здравствуйте, Спильный Андрей, Вы писали:

V>>Да и вообще, часто заказчик нифига не знает точно что ему надо
СА>практически всегда заказчик знает, что он хочет, но не знает как это должно выглядеть или не может внятно сформулировать проблему
СА>суждения, подобные вашему, как раз и появляются из-за постоянного смешивания что (проблема) и как (один или несколько вариантов решения) на стороне заказчика...впрочем, многие аналитики также подвержены этому

В чистом аутсоргинге — наверное так и есть. Только при внутренней разработке когда заказчик это маркетинг или еще кто, может быть что угодно, и совсем необязательно что они знают что им надо. Ну т.е. знают конечно, но вообще, типа "надо денег срубить на новых фичах", вот остается только их придумать и сделать


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

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

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

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

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

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

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

ZD>а по мне, как раз, неправильно. Во-первых, непонятно, почему "если он будет подчиняться проджектлиду, то проджектлид будет на него влиять в своих интересах, и дело делаться не будет". Пиэм не заинтересован в прогрессе проекта?

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

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

Мимо ПМ влиять они конечно не должны, от них к нему сформулированные требования приходить и должны. А его работа вставлять их в план и оценивать. ИМНО ПМ и не должен чувствовать себя ответственным единолично за весь проект.


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

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


K>Нет, проджект-менеджеры тоже подчиняются ИТ-директору, как и системные аналитики...

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

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

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

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

Посмотрите здесь: http://old.e-xecutive.ru/publications/aspects/project/article_921/
Рассматриваются различные подходы к организации управления проектами на предприятии.

ИТ-директор хочет выделить отдельный функциональный отдел.
Нагрузка на аналитика в проектах может быть не постоянной и перемещение аналитика от проекта к проекту может производиться в соответствии с загрузкой и приоритетами проектов.
Загрузка аналитика в рамках проекта уже лежит на ПМ.
Возможно у ИТ-директора есть работа для функционального отдела, которая не связана с текущими проектами или является общей для всех проектов. Т.е. рассматривать полное подчинение аналитика ПМ в таком случае не может быть и речи.

Здравствуйте, <Аноним>, Вы писали:

А>2. Не понимаю опасений по поводу зависимости аналитика от проджектлида и что первый "будет использован проджект-лидом"? Требования которые готовятся аналитиком должны проходить ревью у заказчика. Именно заказчик должен лучше всех (в том числе и ИТ-директора) знать что нужно в итоге получить. И если проджектлид и попытается выкинуть что-то из требований или как-то изменить приоритеты — то это будет обнаружено заказчиком.

Не совсем, требования никто выкидывать не будет, просто ПМ может сильно влиять на нужную ему (а не заказчику) приоритизацию. Да и вообще, часто заказчик нифига не знает точно что ему надо

А>4. Насчет структуры управления: по идее аналитики — это группа разработки требований и обычно она входит в команду проекта и подчиняется проджектлиду.

Давайте тогда определимся с терминологией, для меня ПМ (проджектлид) что все здесь писали — это менеджер проекта, его задача оперативное управление проектом, чтобы дедлайны соблюдались, и т.д. Есть еще Продукт менеджер, вот он уже выступает больше как customer advocate (не могу точно на русском подобрать). Дак вот аналитики должны подчиняться ему.

А>Но так вот что бы аналитики подчинялись через голову проджектлида напрямую программменеджеру (ИТ директору в данном случае) — это как-то экзотично.

Ага, например такая экзотика в MSF


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

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

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

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

K>Спасибо!

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

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

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

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

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

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

Спасибо!

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

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

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

K>Спасибо!

аналитики должны подчиняться своим проджектлидам

Здравствуйте, Аноним, Вы писали:

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

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

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

K>>Спасибо!

А>аналитики должны подчиняться своим проджектлидам

Вот и я так чувствую. И точно так же я (проджектлид) говорю своему IT-директору. Но почему так будет лучше? Лично я не могу ему достаточно внятно обьяснить.

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

Что в нашей компании имеется в виду под сис.аналитиком? Это человек, который собирает у заказчика бизнес-требования, и преобразует их в технические требования разработчикам (задание на уровне интерфейса пользователей и интерфейса компонент)

Вобщем, обьясните, пожалуйста, почему сис. аналитик должен подчиняться проджектлиду непосредственно?

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

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

На мой взгляд, ваш директор все делает правильно. Я бы сделал так же. Аргумент вашего директора №2 — если он его еще не сказал — аналитик один, менеджеров много. Он один всем сразу подчиняться не может — будет конфликт ресурсов. Аргумент №3 — только так ваш директор получит полный контроль над приоритетами работ — а он этого, судя по всему, хочет. Все правильно, короче.

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

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

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

G>На мой взгляд, ваш директор все делает правильно. Я бы сделал так же. Аргумент вашего директора №2 — если он его еще не сказал — аналитик один, менеджеров много. Он один всем сразу подчиняться не может — будет конфликт ресурсов. Аргумент №3 — только так ваш директор получит полный контроль над приоритетами работ — а он этого, судя по всему, хочет. Все правильно, короче.

а по мне, как раз, неправильно. Во-первых, непонятно, почему "если он будет подчиняться проджектлиду, то проджектлид будет на него влиять в своих интересах, и дело делаться не будет". Пиэм не заинтересован в прогрессе проекта? Такого пиэма надо менять, кмк. Во-вторых, далеко не очевидно, что аналитик один, в исходном посте промелькнуло что их несколько.
Далее, если сделать как хочет ит-дир, то произойдет размывание отвественности. Пиэм уже не будет чуствовать себя полностью ответсвенным за проект, поскольку у директора всегда будет возможность давать указания аналитикам, которые потом повлияют на разрабоку, мимо пиэма (теоретически, конечно же, она есть всегда, но при формальном подкреплении она будет использоваться на всю катушку).

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

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

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

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

Во первых, должен выполняться принцип единоначалия. Соответсвенно, если аналитики формально находятся в IT службе, то кроме как своему непосредственному руководству никому они подчиняться не должны. Проджект менеджеры — они к каким службам относятся? к IT или к каким-то другим? Я так понимаю что они из других служб, иначе бы вопроса не было. В таком случае возможны 2 варианта — аналитики подчиняются IT директору, а проджект менеджеры взаимодействуют с IT директором. Если аналитик загружен данным менеджером полностью, то такая структура может быть неоптимальной (менеджер вынужден взаимодействовать с аналитиком через IT директора, так как аналитик будет иметь полное право не выполнять его работу до непосредственно приказа начальства. В случае конфронтации аналитика и менеджера работа встанет). Чтобы этого избежать, можно построить организационную структуру, когда аналитики на время проекта начинают подчиняться менеджерам — но это совсем другой принцип организации получается. ИМХО первый вариант все-таки лучше.

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

S>Во первых, должен выполняться принцип единоначалия. Соответсвенно, если аналитики формально находятся в IT службе, то кроме как своему непосредственному руководству никому они подчиняться не должны. Проджект менеджеры — они к каким службам относятся? к IT или к каким-то другим? Я так понимаю что они из других служб, иначе бы вопроса не было. В таком случае возможны 2 варианта — аналитики подчиняются IT директору, а проджект менеджеры взаимодействуют с IT директором. Если аналитик загружен данным менеджером полностью, то такая структура может быть неоптимальной (менеджер вынужден взаимодействовать с аналитиком через IT директора, так как аналитик будет иметь полное право не выполнять его работу до непосредственно приказа начальства. В случае конфронтации аналитика и менеджера работа встанет). Чтобы этого избежать, можно построить организационную структуру, когда аналитики на время проекта начинают подчиняться менеджерам — но это совсем другой принцип организации получается. ИМХО первый вариант все-таки лучше.

Нет, проджект-менеджеры тоже подчиняются ИТ-директору, как и системные аналитики...

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

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

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

G>На мой взгляд, ваш директор все делает правильно. Я бы сделал так же. Аргумент вашего директора №2 — если он его еще не сказал — аналитик один, менеджеров много. Он один всем сразу подчиняться не может — будет конфликт ресурсов. Аргумент №3 — только так ваш директор получит полный контроль над приоритетами работ — а он этого, судя по всему, хочет. Все правильно, короче.

Я не говорил, что аналитик один. Я, похоже, невнятно написал. Под каждый проект буду набираться свои системные аналитики. Три проекта — три аналитика. Кому они должны подчиняться — каждый своему проджект-менеджеру, или все три ИТ-директору? Вот в чем был вопрос!

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

G>Не размыванию, а распределению. При данной схеме аналитики ставят ТЗ, исследуя бизнес-процессы. Их роль, кстати, можно совместить с поддержкой пользователей. Они отвечают за адекватное отражение бизнес-потребностей. Их же при желании сократить команду можно совместить с тестерами и поддержкой пользователей.
А если они будут подчиняться менеджеру, они не будут ставить ТЗ? Кмк, базовые функции аналитиков не меняются от того, что их кому-то переподчиняют. А конкретно в этом случае директор не доверяет (либо не уверен в возможностях) менеджеру (менеджерам), из-за чего хочет переложить чать работы менеджера на аналитика ("... будет независимым он проджектлида, будет ставить задания проджектлидам, контролировать сроки и функционал"). Не зная нюансов конкретной ситуации сложно сказать, кто из них прав.

G>Проджект лиды выполняют проект в соответствии с ТЗ — естественно, они могут спорить с аналитиками по поводу ТЗ — но прогнуть они аналитиков не могут — так же, как и аналитики их. Они должны прийти к согласию.
Зависит от конкретных личностей. Иногда прямого подчиненного не удается прогнуть, а иногда чужим крутят как хотят

G> Нормальная схема, посмотрите как сделано в Майкрософте — там в параллели находятся program manager, руководитель программеров и руководитель тестеров.
Куда посмотреть? Думаю, там коробочный продукт, а в рассматриваемом случае — внутренняя автоматизация.

G>Директор при данной схеме определяет приоритеты работ, контроллирует порядок реализации функциональности, рисует роадмап по внедрению технологий, инфраструктуры, и новой функциональности, управляет релизами, и разруливает конфликты. Вполне нормальная схема для маленького отдела.
Т.е. директор по сути становится менеджером на трех проектах. В принципе, тоже вариант, почему нет.
Кстати, про маленький отдел в условиях сказано не было Может, у них там по 10 программистов на проект хотят выделить.

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

G>Эта схема дает больше прозрачности, что по канонам темных исскуств как раз вредно — интригу замутить меньше возмжностей.
Не понял. Почему (и, главное, кому) больше прозрачности? Директору может и больше, но мы-то вроде пытаемся помочь менеджеру А ему, как раз, прозрачности будет сильно меньше.

G> А что до того, что на кого свалить — так это вопрос желания и техники.
G>Вообще — если говорить с позиции светлых исскуств — а именно, командообазующих факторов, — доверие — необходимый элемент команды. Если участники сразу подходят друг к другу с недоверием — и думают, как на них кто-то что-то начнет валить — то это уже нехорошая, "темная" установка. Не есть правильно, на мой взгляд.

Пока всё хорошо — все белые и пушистые. Мы команда, друзья, тра-ля-ля... Но когда возникают проблемы (пример: пришел срок сдачи, а ничего не готово), очень часто начинают искать виноватого. И тут виноватым окажется тот, кто хуже подготовился.
А правильно это или нет... нельзя на "темном" строить повседневную работу, но готовым менеджеру надо быть.

Алекс

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

G>Так вот, теперь у меня в голове все встало на свои места.

Шо-то тебя колбасит на эту тему в последнее время
Я в хорошем смысле

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

K>Как Вы считаете, кому они должны подчиняться — непосредственно IT-директору, или проджект-менеджеру в каждой команде? Как будет лучше? И почему?

Для начала нужно определиться какую роль будут выполнять аналитики. Как минимум есть два полярных варианта:

1. А ну-ка, милок, сгоняй к бабе Мане и спроси откуда она эту цифру взяла.
2. Аналитик как представитель заказчика (на больших проектах эту роль выполняет Product Manager, у которого в подчинении может быть несколько аналитиков).

Я видел обе схемы. Какую из них выбрать зависит от размеров проекта, удалённости разработчиков от заказчика и предпочтений руководства проекта. На больших проектах и/или удалённости разработчиков рулит второй вариант. На небольших и/или внутренних соответственно первый.

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

G>>На мой взгляд, ваш директор все делает правильно. Я бы сделал так же. Аргумент вашего директора №2 — если он его еще не сказал — аналитик один, менеджеров много. Он один всем сразу подчиняться не может — будет конфликт ресурсов. Аргумент №3 — только так ваш директор получит полный контроль над приоритетами работ — а он этого, судя по всему, хочет. Все правильно, короче.

K>Я не говорил, что аналитик один. Я, похоже, невнятно написал. Под каждый проект буду набираться свои системные аналитики. Три проекта — три аналитика. Кому они должны подчиняться — каждый своему проджект-менеджеру, или все три ИТ-директору? Вот в чем был вопрос!

Что конкретно вменяется в функции аналитику, чем он занят на разных этапах проекта? От этого зависит ответ на вопрос, стоит их выделять в отдельную группу, или нет.

ZD>контролировать сроки и функционал"). Не зная нюансов конкретной ситуации сложно сказать, кто из них прав.

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

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

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

G>>Так вот, теперь у меня в голове все встало на свои места.

IT>Шо-то тебя колбасит на эту тему в последнее время
IT>Я в хорошем смысле

Дык у меня последние два года радикально другая работа, на которой я не только пассивный наблюдатель этих "исскуств", но поневоле и активный участник. Причем, у нас интриг не просто много — их дохрена, так что данные умения это вопрос выживания на уровне среднего менеджмента. Не скажу, что мне это нравится — ровно наоборот. Но в эти игры играть чутка научился, и полученные знания и навыки у меня в голове как то сами постепенно укладываются в систему, постепенно вылезают интересные обобщения и противопоставления. Как улягутся — тема меня интересовать перестанет.

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

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

А>>аналитики должны подчиняться своим проджектлидам

K>Вот и я так чувствую. И точно так же я (проджектлид) говорю своему IT-директору. Но почему так будет лучше? Лично я не могу ему достаточно внятно обьяснить.

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

K>Что в нашей компании имеется в виду под сис.аналитиком? Это человек, который собирает у заказчика бизнес-требования, и преобразует их в технические требования разработчикам (задание на уровне интерфейса пользователей и интерфейса компонент)

K>Вобщем, обьясните, пожалуйста, почему сис. аналитик должен подчиняться проджектлиду непосредственно?

------------

1. Аналитик не должен конролировать функционал и сроки. Функционал и сроки контролирует проджектлид. Аналитик "пытает" заказчика и документирует его требования к фунционалу, срокам и его приоритеты. Далее команда проекта (в лице проджектлида) договаривается с заказчиком что они готовы сделать то-то и то-то в такие-то сроки. Заказчик подтверждает, что его поняли верно и это именно то, что он хочет. Эти договоренности надо документировать.

2. Не понимаю опасений по поводу зависимости аналитика от проджектлида и что первый "будет использован проджект-лидом"? Требования которые готовятся аналитиком должны проходить ревью у заказчика. Именно заказчик должен лучше всех (в том числе и ИТ-директора) знать что нужно в итоге получить. И если проджектлид и попытается выкинуть что-то из требований или как-то изменить приоритеты — то это будет обнаружено заказчиком.

3. Насчет функций ваших аналитиков "задание на уровне интерфейса пользователей и интерфейса компонент". Может быть вы что-то другое имеете ввиду, но по идее "интерфейсы компонент" — если речь идет о внутренней структуре системы и APIs компонент, то это уже относится к дизайну, который должен делаться разработчиками (архитектором, если есть такая роль)

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

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

Если речь идет именно о такой ситуации совмещения 2х ролей в лице одного ИТ-директора — с одной стороны он ваш начальник, а с другой стороны представитель заказчика — вот это не есть хорошо. У него появится большой соблазн запихать как можно больше функционала в каждый этап (как заказчик), а с другой стороны продавить вас по срокам (как ваш начальник) — т.е. навязать вам нереальные графики работ. Тут вам надо будет иметь смелость аргументировано отстаивать свои оценки трудоемкости и сроков. Либо аккуратно передвинуть ответственность на ИТ директора.

Вообще попытка все делать самому и чрезмерная концентрация контроля на себе — как мне кажется это от недостатка опыта управления. Кажется что никто кроме тебя лучше не сделает. Это надо в себе подавлять. Задача управленца заключается в том чтобы делать работу чужими руками. И делать хорошо

С уважением,
Олег З.

А что нужно-то? Что бы задачи решались или бюджет поднять?

Здравствуйте, Аноним, Вы писали:

А> ...

А>Вообще попытка все делать самому и чрезмерная концентрация контроля на себе — как мне кажется это от недостатка опыта управления. Кажется что никто кроме тебя лучше не сделает. Это надо в себе подавлять. Задача управленца заключается в том чтобы делать работу чужими руками. И делать хорошо

А>С уважением,
А>Олег З.

Спасибо! У Вас каждое слово — на вес золота!

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

G>А что нужно-то? Что бы задачи решались или бюджет поднять?

Чтобы задачи решались.

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

G>Что конкретно вменяется в функции аналитику, чем он занят на разных этапах проекта? От этого зависит ответ на вопрос, стоит их выделять в отдельную группу, или нет.

При чем тут отдельная группа? Речь о том, кому должен подчиняться аналитик, который занимается конкретным проектом — проджектменеджеру или ИТ-директору. Вот и весь вопрос. Каждый аналитик занимается своим проектом. Зачем вообще может возникнуть необходимость выделять их в отдельную группу??

В функции аналитика вменяется сбор требований от заказчика и формулирование их техническим языком

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

А>3. Насчет функций ваших аналитиков "задание на уровне интерфейса пользователей и интерфейса компонент". Может быть вы что-то другое имеете ввиду, но по идее "интерфейсы компонент" — если речь идет о внутренней структуре системы и APIs компонент, то это уже относится к дизайну, который должен делаться разработчиками (архитектором, если есть такая роль)

Мы пишем большой веб-сайт. Под интерфейсом компонент я имел в виду требования к веб-компонентам и их конфигурированию. Например, веб-компонент "список новостей" имеет параметры: показывать дату/время или нет, сколько новостей показывать и т.д. Я имел в виду под интерфейсом, в частности, что и как конфигурируется в веб-компоненте.

Извините, неправильно выразился...

> Чтобы задачи решались.

Честно-честно? Тогда ПМ-а нужно подчинить аналитику Вот только что с предприятия, где ПМ-ы рулят. Нагнали народу, работа кипит, народ гудит, технологии рулят... А что-то как-то всё на средненьком уровне, степень удовлетворенности никакая. Чем больше технологий, тем дольше всё считается.

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

S>Во первых, должен выполняться принцип единоначалия.

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


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

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

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

S>>Во первых, должен выполняться принцип единоначалия.

V>Ничего он не должен выполняться, есть миллион причин когда в компаниях человек подпиняется разным начальникам по разным нарпавлениям.

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

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

S>Например? В какой ситуации множественное подчинение будет не косяком в организационной структуре, а необходимым и обоснованным условием нормальной работы?

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

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

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

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

G>>Что конкретно вменяется в функции аналитику, чем он занят на разных этапах проекта? От этого зависит ответ на вопрос, стоит их выделять в отдельную группу, или нет.

K>При чем тут отдельная группа? Речь о том, кому должен подчиняться аналитик, который занимается конкретным проектом — проджектменеджеру или ИТ-директору. Вот и весь вопрос. Каждый аналитик занимается своим проектом. Зачем вообще может возникнуть необходимость выделять их в отдельную группу??

1. Фактическое выделение аналитиков в отдельную группу все равно произойдет при подчинении их директору, просто он станет и.о. руководителя этой группы, совмещая эту роль со своей, вот и все. Поэтому, вопрос на мой взгляд проще решать именно в постановке выделения аналитиков в отдельную группу. Иначе он вообше лишен смысла. Ваш директор может думать, что это не так — но это сути дела не меняет. Группа его обязанностей по руководству аналитиками, если он возьмется ими руководить — это отдельная роль, которая предполагает работу с текучкой, и которую он берет на себя в довесок к своим основным обязанностям.

2. На этот вопрос нельзя ответить, не зная (или не додумывания) деталей, при кажущейся его простоте.

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

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

Мне так кажется, что в проекте много также других важных стратегических ролей (например, менеджер по качеству), но ведь они подчиняются руководителю проекта? Точно также и системный аналитик.
Кроме того, если требуется работа системного аналитика — например, разработка документа Концепция, в которой он должен описать варианты использования, то она должна выполняться по заданию руководителя проекта, так как именно руководитель проекта отвечает за распределение работ, их очередность и приоритет. А у вас получается наоборот, что руководитель проекта подчиняется системному аналитику. Тогда уж можно сделать, чтобы он подчинялся архитектору, ведущему разработчику, ведущему тестировщику и т.п.

У меня создалось впечатление, что у вас под руководителем проекта понимается ведущей разработчик (возможно у вас он же и архитектор), что неверно.

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

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

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

А вот по поводу Product Manager согласен — он, конечно, вне зоны ответственности Project Manager'а.

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

V>Product Manager — это перец что думает в терминах продукта целиком (как он позицируется на рынок, какие бизнес требования и т.д.). Он вообще вполне может быть не техническим спецом. Project Manager — вот он уже даски на разработку выдает и за прогрессом следит именно разработки, есть еще аналитики и QA сбоку.

V>Грубо говоря, Product Manager задает направление куда идти, аналитики прокладывают маршрут по карте, программисты во главе с Project Manager тащят груз в указанныю точку, а QA проверяет дошли или нет

Я думал, что скорее:

Product Manager (в вашем понимании) = Project Manager (в моём)
Project Manager (в вашем понимании) = Team Leader (в моём)

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

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

V>Здравствуйте, <Аноним>, Вы писали:

А>>2. Не понимаю опасений по поводу зависимости аналитика от проджектлида и что первый "будет использован проджект-лидом"? Требования которые готовятся аналитиком должны проходить ревью у заказчика. Именно заказчик должен лучше всех (в том числе и ИТ-директора) знать что нужно в итоге получить. И если проджектлид и попытается выкинуть что-то из требований или как-то изменить приоритеты — то это будет обнаружено заказчиком.

V>Не совсем, требования никто выкидывать не будет, просто ПМ может сильно влиять на нужную ему (а не заказчику) приоритизацию. Да и вообще, часто заказчик нифига не знает точно что ему надо

Понятно, что в жизни может быть все что угодно: заказчик (например руководитель отдела снабжения) может быть назначен формально и не будет замотивирован на успех проекта, проект может быть "надуманный" — т.е. когда нет реальной потребности и организация "не созрела", но кто-то решил заработать и "продал" этот проект и многие другие ситуации. Но в таких случаях как не извращайся с подчинением аналитиков ничего в итоге хорошего не получится — реально ваша система работать либо не будет, либо будет работать с крайне низким КПД. В лучшем случае формально вам "закроют" работу и подпишут документы, в плохом — будут скандалы и все такое... Типа "насильно автоматизировать можно, только удовольствия не получится"

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

Еще мне не понятно, почему считается что "заказчик нифига не знает точно что ему надо", но при этом есть уверенность что это самое "то что нужно заказчику" точно знает кто-то со стороны команды проекта (ИТ-директор, например)? Я понимаю что есть ИТ-специалисты которые очень хорошо рубят в предметной области и имеют в ней серьезный опыт, но все равно надо быть очень осторожным чтобы не подавлять заказчика и не решать за него. Советовать да, но аккуратно. Финальное слово должно быть за заказчиком. А то в конце проекта вы с удвилением обнаружите что система полностью удовлетворяет вас, но не заказчика...


А>>4. Насчет структуры управления: по идее аналитики — это группа разработки требований и обычно она входит в команду проекта и подчиняется проджектлиду.

V>Давайте тогда определимся с терминологией, для меня ПМ (проджектлид) что все здесь писали — это менеджер проекта, его задача оперативное управление проектом, чтобы дедлайны соблюдались, и т.д.

согласен. Его цель — достичь поставленных перед проектом целей, с учетом установленных ограничений по времени/бюджету/качеству.
http://en.wikipedia.org/wiki/Project_manager

V> Есть еще Продукт менеджер, вот он уже выступает больше как customer advocate (не могу точно на русском подобрать). Дак вот аналитики должны
V> подчиняться ему.

http://en.wikipedia.org/wiki/Product_Manager — тут какое-то слишком общее определение на мой взгляд
да, действительно есть такая роль в ряде процессов (в том же MSF). И действительно одна из его задач быть адвокатом заказчика (по MSF). Но вот про то, что аналитики должны подчиняться ему я в MSF Team Model v. 3.1 не нашел. На сайте MS что-то не нашел более свежей версии — может там и по-другому...

Но вообще мне думается, что это неверно, потому как если подчинить аналитиков Product Manager-у то может быть следующий конфликт:
Как известно, основными пользователями требований, которые создаются аналитиками, являются разработчики и тестеры. И когда все они работают в одной команде под руководстом проджектлида/проджектменеджера, то все получается довольно гладко — всегда можно в рабочем порядке решить как и в каком виде документировать требования, на каком уровне детализации остановиться, где надо что-то отдельно проработать, и т.д. Так же в рабочем порядке аналитики приглашают разработчиков и тестеров на ревью требований, принимают их замечания и улучшают требования.
Если же вывести аналитиков из подчинения проджект-лида, и перевести в подчинение Product Manager, то может получиться что 1) требования будут разрабатываться в том виде который захочет Product Manager, 2) уровень детализации может быть установлен Product Manager по его усмотрению и все такое в том же духе 3) люди не будут чувствовать себя одной командой и это будет мешать проекту. Нужны будут дополнительные терки и согласования чтобы все это преодолеть. Это все усложнит работу.
Никто не мешает Product Manager-у защищать интересы заказчика, но без управления командой аналитиков.

Далее, в той компании о которой идет речь (начальный пост от karbon76), нет такой роли "Product manager", насколько я понял. Да, ее можно ввести, но сильно не уверен, что совмещать роль ИТ-директора (а по сути это Program Manager — тот кто курирует несколько проектов, в том числе может баланисировать ресурсы между проектами, назначить руководителей и т.п. http://en.wikipedia.org/wiki/Program_(management)) с ролью Product Manager есть хорошая идея. В том же MSF — это разные роли.

Вообще мне кажется что ценность роли Product Manager сильно зависит от типа бизнеса/проекта:
1. Если компания делает продукты для массовой продажи — типа как Microsoft — то там роль Product Manager действительно востребована и важна. Он как бы и представляет заказчика ввиду того что конкретного заказчика нет, а есть некое обобщенное представление что нужно среднему пользователю разрабатываемого продукта.
2. Для внутренних проектов (например когда пишется система для автоматизации отдела кадров) либо когда идет "заказная разработка" под конркетного внешнего заказчика, то, как мне представляется, необходимость в Product Manager-е гораздо менее выражена.

А>>Но так вот что бы аналитики подчинялись через голову проджектлида напрямую программменеджеру (ИТ директору в данном случае) — это как-то экзотично.

V>Ага, например такая экзотика в MSF

В моем понимании Program Manager — это то что написано в wikipedia — это человек который курирует несколько проектов, он за них отвечает (и это в данном случае и есть ИТ-директор этой компании), а рулить аналитиками это не его задачи и уровень.

Олег З.

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

M_E>Мне так кажется, что в проекте много также других важных стратегических ролей (например, менеджер по качеству), но ведь они подчиняются руководителю проекта? Точно также и системный аналитик.

это конечно оффтопик, но позволю себе небольшое замечание насчет менеджера по качеству. Знаю, что во многих компаниях под "менеджером по качеству" понимается "инженер по тестированию", но бывают варианты когда есть "инженер по тестированию" (Test engineer) — он разрабатывает и прогоняет тесты. А есть "менеджер по качеству" (он же "SQA-инженер" (Software Quality Assurance engineer)) — он следит за соответствием следования проекта установленному процессу (технологии).
И этот SQA-инженер (в отличие от test engineer) не подчиняется руководителю проекта — он входит в соответствущий отдел обеспечения качества. А отдел замыкается на руководство компании. Считается, что за счет такой независимости, можно получить более четкое представление о "технологичности" процесса на проекте, т.е. насколько он соответствует принятым в компании стандартам и правилам. Все это базируется на старой идее о том что "хорошие процессы дают хорошие продукты".

С уважением,
Олег З.

А>это конечно оффтопик, но позволю себе небольшое замечание насчет менеджера по качеству. Знаю, что во многих компаниях под "менеджером по качеству" понимается "инженер по тестированию", но бывают варианты когда есть "инженер по тестированию" (Test engineer) — он разрабатывает и прогоняет тесты. А есть "менеджер по качеству" (он же "SQA-инженер" (Software Quality Assurance engineer)) — он следит за соответствием следования проекта установленному процессу (технологии).
А>И этот SQA-инженер (в отличие от test engineer) не подчиняется руководителю проекта — он входит в соответствущий отдел обеспечения качества. А отдел замыкается на руководство компании. Считается, что за счет такой независимости, можно получить более четкое представление о "технологичности" процесса на проекте, т.е. насколько он соответствует принятым в компании стандартам и правилам. Все это базируется на старой идее о том что "хорошие процессы дают хорошие продукты".

Да, я с вами согласен.

Здравствуйте, 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>Ну, может вы просто хороший человек и любите совю работу Не всегда так бывает

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

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

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

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

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

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

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

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

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

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

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

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

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

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