Comments 7
Схема 2 более жизнеспособна на небольших программных продуктах, 1 - больше применима к тяжеловесным монолитам. Тут, наверно, нужно отталкиваться от того, что нужно бизнесу: если качество - то схема 1, если скорость добавления ценности, то схема 2.
Интересно было бы посмотреть на комбинированную схему, где один и тот же специалист подчиняется нескольким руководителям.
Зачем же Вы своровали уже готовую статью https://habr.com/ru/articles/830832/ ?
Понятие "лучше" не существует в отрыве от задач и исполнителей. Поэтому так часто проваливается попытка внедрения "лучших практик". Плюс важным фактором является представление о прекрасном высшего руководства, как оно считает "правильным", да и банально характеры сотрудников. Поэтому я бы ответил, что правильным является использование комбинированной структуры - но загвоздка в том, что как она должна выглядеть ответа нет. В качестве не часто упоминаемых, но на мой взгляд важнейших факторов, хотел бы отметить наличие персональной, а не коллективной ответственности за результат.
Мне кажется, что рациональная схема гибрида - это когда на базе функциональной структуры, с единой точкой входа задач в отдел, формируется проектная структура на уровне не рядовых сотрудников, а руководства подразделения. Т.е. все руководители отделов (или их замы, не суть), видят не отдельные сыплющиеся им на вход задачи, а весь жизненный цикл ведущихся проектов, имеют понимание об их объёмах и приоритетах, и уже в зависимости от этой картины приоритизируют задачи внутри отдела. А каждому проекту назначается проджект, который является фактически администратором.
В общем, тут можно теоретизировать до бесконечности, а потом выясняется что у тебя в "кросс-функциональной команде" то одни энергичные джуны, то мидлы работающие строго с 10 до 6, то сплошные сеньоры тянущие одеяло на себя :)
Соглашусь. Мне всегда казалось, что роль личности в разработке несколько недооценивают.
И ещё часто пишут о слишком больших издержках на кросс-коммуникацию между всеми участниками проекта, но почему-то одновременно поощряют их в "эджайл-стиле", называя это вовлечённостью в проект. Я считаю что сотрудники должны быть хоть и не изолированы от внешнего мира, но огорожены от внешних воздействий и непрерывной коммуникации со всеми подряд. (Особенно это пагубно, когда интроверты-разработчики сталкиваются с экстравертами-менеджерами). Это мало того что выбивает из рабочего ритма, так ещё и путает приоритеты исполнения. В таком случае руководитель не может нести ответственность за своевременное выполнение задач, и получается что "никто не виноват", только работа недоделана.
Способы организации команд разработки