Одна из самых неприятных проблем для любой формальной структуры, в том числе для структуры компании — отрыв от реальности. Как только он происходит, становится лишь вопросом времени, когда реальность эту формальную структуру догонит и крепко стукнет по голове, возможно, даже неоднократно.
Применительно к разработке софта это нередко выражается в попытках функционального разделения отделов. То есть, есть отдел разработчиков, есть отдел тестировщиков, есть отдел документаторов и так далее. Генезис такого подхода вполне понятен, кажется, что у разработчиков между собой больше общего, нежели у разработчиков и тестировщиков, ровно так же, как у водителей автобусного парка больше общего, нежели у водителей и механиков.
В крайних формах это приводит к таким понятиям как «пул разработчиков» и «пул тестировщиков», из которых, теоретически, можно дёргать людей на какие-то проекты и что-то делать. По тому же самому принципу, по которому можно взять любого механика на ремонт любого автобуса или любого водителя отправить с любым кондуктором на любой маршрут. Чтобы было интереснее, всё это может называться матричной структурой управления.
Может быть, где-то в аутсорсных компаниях, где жизнь измеряется небольшими ограниченными проектами, после которых участников можно смело разгонять (хотя даже там стараются давать проектам развитие и не менять сильно тематику), такой подход вполне имеет право на жизнь.
Но в моей практике создания долгосрочных продуктов всё оказывается несколько иначе и проектная (продуктная) связь группы людей оказывается куда сильнее функциональной, то есть, в рамках проекта у разработчика и тестировщика (с документатором вместе) оказывается гораздо больше общих забот, общего необходимого знания предметной области и общего понимания самого продукта, нежели у двух разработчиков (или тестировщиков, или…) разных проектов.
Причём, самым критичным оказывается именно глубокое внутреннее понимание как основной сути, так и каких-то небольших нюансов проекта, размазанное тонким слоем по всей команде. Поверхностное понимание проекта приобрести несложно, а вот обеспечить глубину это совсем другая история. И именно поэтому передёргивание людей между проектами, хоть и возможно теоретически (и предполагается структурой компании с функциональным разделением отделов), на практике приводит к заметным проблемам — разработчики делают что-то не так, тестировщики не видят того, что должны бы, документаторы просто пишут абы что. Причём, никакого злого умысла со стороны людей нет, просто так получается, что при имеющейся у исполнителя глубине понимания проблемы, сделать что-то иначе он не в состоянии.
Поэтому лично мне гораздо симпатичнее (а главное, гораздо работспособнее) структура, в которой команда кросс-функциональна, то есть, содержит в рамках одной структурной единицы людей с разными функциональными возможностями и обязанностями. Это же позволяет естественным образом формировать рамки ответственности команды, нет возможности для перепихивания проблем между функциональными отделами, команда делает пиджак целиком и отвечает за пиджак целиком.
Что, впрочем, не отменяет примат реальности и если реальность иная, то и структура будет иная.