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

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

А> ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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



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

Вполне возможно.
Однако если судить по моему опыту — а у меня в подчинении и 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) не подчиняется руководителю проекта — он входит в соответствущий отдел обеспечения качества. А отдел замыкается на руководство компании. Считается, что за счет такой независимости, можно получить более четкое представление о "технологичности" процесса на проекте, т.е. насколько он соответствует принятым в компании стандартам и правилам. Все это базируется на старой идее о том что "хорошие процессы дают хорошие продукты".

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