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