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

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

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

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

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

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

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

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

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

Алекс