Можно выделить два основных формата организационных структур - функциональную и проектную (матричную). Развитие матричных структур можно проводить в разных направлениях. Например, выбрать направление максимальной универсализации или сориентироваться на удовлетворение потребностей клиента.
В статье я описал свои размышления о том, в каком направлении потенциально может развиваться эволюция матрицы и в какую точку она может прийти.
![](https://habrastorage.org/getpro/habr/upload_files/772/de0/6aa/772de06aacb1d393b022d3b60f85c1ce.png)
Пример ситуации
ИТ компания находится на эволюционном распутье развития матричной организационной структуры.
Проекты объединены в портфель аккаунт менеджера. В один портфель могут входить проекты разных функциональных областей и разных заказчиков. Иных правил группировки нет, кроме принадлежности к аккаунту.
Организационная структура матричная. Руководители проектов и аналитики включаются в команду проекта по принципу доступности, желательно, с наличием опыта в функциональной области. Разработчиков включают в команду проекта на основании технологического стека разработки.
Сотрудники административно разделены на подразделения и подчинены руководителю подразделения. Руководитель подразделения отвечает за обеспечения проектов сотрудниками из числа имеющихся специалистов, развитие компетенций, подбор и мотивацию персонала. Сам, непосредственно в проектной деятельности, не участвует.
Основной посыл - снижение потенциальных простоев сотрудников.
![](https://habrastorage.org/getpro/habr/upload_files/abf/bfc/47e/abfbfc47e4aabae40da58ddff8abd723.png)
Эволюция "DOWN" - стремление к универсализации
Почему возникает стремление универсализации матрицы? Формулируется цель – свести простои к нулю. Для достижения вырабатывается ряд гипотез. Пример гипотезы: специалист, включенный в команду проекта, может достаточно быстро освоить технологии и знания, необходимые для реализации проекта, поэтому считаем, нам нужны «универсальные солдаты». Столкнувшись на практике с реальностью, быстрого освоения не получается достичь. Ожидаемый заказчиком уровень компетенций исполнителя высок, как следствие, цели проекта не достигаются. Вырабатывается корректирующее действие - развивать специалистов в рамках проекта. За чей счет? Придерживаясь стратегии «универсальных солдат» находим ответ - за счет заказчика.
В результате:
Резко возрастает себестоимость работ
Заказчик получает не качественный результат
Специалисты, перекидываемые с одного направления на другое, вынуждены начинать «с нуля», что приводит к недостижению экспертного уровня в конкретном направлении. Развиваясь как аналитик в решении задач регламентированного учета он достиг уровня middle+, и понимает, что до senior остается один маленький шаг, но узнает, что завтра он работает в проекте и будет решать задачи блока CRM, про которые он ничего не знает, т.е. его уровень вновь junior. Предположим, что работодатель сохранит уровень мотивации, но кто от этого выигрывает? Сохраниться ли интерес у сотрудника к решению простых задач и сможем ли мы продать услуги уровня junior по цене senior?
В текущей ситуации универсальность не распространяется на разработчиков, но предположим, что тренд универсальности затронет всех
В фантастической комедии «Эволюция», в итоге эволюционного процесса всё разнообразие организмов, закончилось одним универсальным. Пофантазирую на эту тему.
Итогом следующего шага будет являться реализация гипотезы универсальности разработчиков, не зависимо от технологического стека.
![](https://habrastorage.org/getpro/habr/upload_files/294/e19/80e/294e1980e90bf10a9bc47cb5711c3fd5.png)
Далее трансформируем специализацию до ИТ-специалиста, который будет «и швец, и жнец, и на дуде игрец». Существенно упростим процессы комплектации команд проектов. А получим ли результат по проекту? Вопрос риторический.
![](https://habrastorage.org/getpro/habr/upload_files/43a/db2/3e9/43adb23e9590ec3b387e5a3bca9984ae.png)
Описанный сценарий, вероятно, никогда и нигде не произойдет. Поэтому, рассмотрю вариант эволюции матрицы, который позволит достичь удовлетворенности заказчика эффективным способом, снижая возможные риски
Эволюция "UP" - ориентация на клиента
Основным вектором эволюции «UP» является ориентация на заказчика. Важно понимание - кто наш заказчик, какие потребности у него и как эти потребности удовлетворить за счёт решений, создаваемых по итогам реализации проектов.
Этот вектор ложится в основу формирования организационной структуры, ролей и процессов управления проектами. Потребности заказчика классифицируются по решаемым в проектах функциональным задачам, формируя в нашей структуре набор функциональных компетенций. Компетенция – это бизнес функция заказчика, например, регламентированный учет, CRM, управление дистрибьюцией и т.п.
Портфель проектов по компетенции
Объединяющим понятием проектов является компетенция портфеля проектов. Руководитель портфеля является предметно прогруженным в компетенцию. Отвечает за развитие функциональных знаний аналитиков проектов портфеля, их найм и мотивацию, объем и финансовые показатели реализуемых проектов портфеля. Несет комплексную ответственность за направление в целом.
Организационная структура портфеля проектов
В портфель проектов входят все проекты по компетенции. Руководители проектов и аналитики административно подчинены руководителю портфеля проектов. Распределение специалистов по проектам производится в рамках частной проектной матрицы конкретного портфеля. Остальные члены проектных команд административно являются сотрудниками, не входящих в портфель проектов структур, например, отделов или департаментов разработки, тестирования, информационной безопасности. Включение указанных специалистов в команды проектов также происходит по матричному принципу, но уже в рамках общей для всех проектов организации матрицы. Таким образом, организационная структура организации — это матрицы в матрице.
![](https://habrastorage.org/getpro/habr/upload_files/f6c/894/758/f6c894758a22a8c40d14203d986aec1c.png)
Административно подчиняться руководителю портфеля проектов и входить в частную матрицу могут разные специалисты. Например, если технологический стек 1С используется только в одном портфеле проектов, то разработчики могут входить в организационную структуру портфеля проектов по компетенции
Проектная методология и проект
В организации создается проектный офис. В его функции входят - разработка базовых правил процессов проектной деятельности и проектной методологии. Часть методологии, которая является специфичной для портфеля проектов по компетенции, может быть разработана в рамках портфеля и применяться только для него. Примером может являться общий для всех проектов процесс формирования бюджета, а процесс проведения защиты архитектуры может быть разным. Иерархия проектной методологии позволит уменьшить трудозатраты для выработки процессов по схожим задачам и, в то же время, не запихивать в «прокурстово ложе» проекты разной специфики.
Проектный офис также ответственный за проведение проектных комитетов, на которых рассматриваться ключевые точки проекта.
Проектный офис разрабатывает и контролирует исполнение процесса инициации проекта, определяет состав материалов, необходимых для инициации. Подготовку проекта к инициации производит аккаунт менеджер совместно с командой портфеля проектов по наиболее близкой компетенции на основании запроса на проект. Желательно сохранить преемственность всего проектного цикла - от момента возникновения запроса на проект до его завершения. После подготовки необходимых материалов, проектный офис производит инициацию проекта.
Институт главных специалистов
Рассматриваемая структура предусматривает множество портфелей проектов, объединенных по компетенциям. В каждом из них существуют свои схожие по профессии группы - категории специалистов - аналитики, руководители проектов, разработчики и т.д. Для категории в целом возникает необходимость развития soft skills или профессиональных навыков, например, описание бизнес процессов в определенной нотации. К тому же пользу принесут институты обмена опытом и знаниями внутри категории. Это деятельность требует координации, планирования, обеспечения исполнения.
В бытность работы на промышленном предприятии я столкнулся с таким специалистом как главный металлург. Цитата из должностной инструкции: «Организует разработку и внедрение в производство прогрессивных, экономически и экологически обоснованных технологических процессов, обеспечивающих высокий уровень технологической подготовки производства, производительности труда и качества выпускаемой продукции на уровне лучших отечественных и зарубежных образцов».
Предлагается ввести аналогичные роли и в нашей структуре. Главный аналитик или разработчик, сможет решать задачи, являющиеся общими для категории специалистов.
Менеджер по продукту
Продукт — это осязаемый результат, у его жизненного цикла нет жёстких временных рамок, а для его создания и функционирования чаще всего необходимо несколько проектов. Проект — это процесс, он ограничен в рамках времени и бюджета. Итогом реализации проекта может являться продукт.
Менеджер по продукту ведет продукт и отвечает за его успех. Этот специалист определяет потребности клиента и его бизнес цели. Менеджер по продукту обеспечивает соответствие целевого результата проекта потребностям клиента.
Целесообразно ввести в структуру роль менеджера по продукту, не привязывая его жестко к конкретному проекту, лучше - вывести на отдельный элемент матрицы. Задачи могут повторяться у разных клиентов и задачи могут иметь подзадачи на стыке компетенций. При завершении одного проекта и инициации последующих проектов, менеджер по продукту обеспечит целостность продукта и восприятие клиентом неразрывности решения потребностей. Подобное объединение продуктов проектов позволит менеджеру по продукту стать носителем знаний о потребностях группы клиентов и применимых решениях, что позволит переиспользовать решения на основе лучших проектных практик, и, в будущем, перейти к проактивному предложению решений для клиентов.
Аккаунт менеджер
Аккаунт менеджер прикрепляется к клиенту и не зависит от принадлежности проекта к портфелю. Основной функцией является обеспечение коммуникаций клиента и проектных команд, сохранение и развитие взаимоотношений, общая координация работ с клиентом. В случае отсутствие отдельного ответственного за продажу, аккаунт менеджер может выполнять и эту роль.
Супервизор
В психологии есть такая роль - супервизор. Это наставник, который помогает менее опытным специалистам, это не тот, кто все знает и умеет, а тот, кто может свежим и опытным взглядом разобрать проблему, рассмотреть её с другой стороны.
Введении подобных ролей в организации повысит производительность и вовлеченность сотрудников, снизит риски выгорания.
Желательно, чтобы супервизор не являлся руководителем сотрудника. Это нужно, чтобы взаимодействие строилось на доверительных отношениях, не обременённых формальными механизмами.
Деятельность супервизора поддерживается и поощряется руководством организации. Супервизором должно быть престижно.
Итог эволюции "UP"
В итоге получается структура организации, обеспечивающая ориентацию на удовлетворение потребностей клиента эффективным способом. Структура учитывает специфику проектов, являясь гибкой и масштабируемой.
![](https://habrastorage.org/getpro/habr/upload_files/96a/476/e94/96a476e94f0fa1ab1ab3f240965cf462.png)
Заключение
Я рассмотрел два варианта эволюции. В реальной жизни их может быть гораздо больше. В статье описаны роли. Исполнение ролей может совмещаться или разделяться, а их количество не обязательно равно количеству специалистов, всё зависит от конкретного проекта.
Примечание
В статье есть ряд допущений. Выделены только часть специализаций и ролей с целью не утяжелять повествование и схемы
Рассматриваемые ситуации являются интегрированным пониманием автора и, отчасти, художественным вымыслом. Все совпадение случайны.