Можно выделить два основных формата организационных структур - функциональную и проектную (матричную). Развитие матричных структур можно проводить в разных направлениях. Например, выбрать направление максимальной универсализации или сориентироваться на удовлетворение потребностей клиента.
В статье я описал свои размышления о том, в каком направлении потенциально может развиваться эволюция матрицы и в какую точку она может прийти.
Пример ситуации
ИТ компания находится на эволюционном распутье развития матричной организационной структуры.
Проекты объединены в портфель аккаунт менеджера. В один портфель могут входить проекты разных функциональных областей и разных заказчиков. Иных правил группировки нет, кроме принадлежности к аккаунту.
Организационная структура матричная. Руководители проектов и аналитики включаются в команду проекта по принципу доступности, желательно, с наличием опыта в функциональной области. Разработчиков включают в команду проекта на основании технологического стека разработки.
Сотрудники административно разделены на подразделения и подчинены руководителю подразделения. Руководитель подразделения отвечает за обеспечения проектов сотрудниками из числа имеющихся специалистов, развитие компетенций, подбор и мотивацию персонала. Сам, непосредственно в проектной деятельности, не участвует.
Основной посыл - снижение потенциальных простоев сотрудников.
Эволюция "DOWN" - стремление к универсализации
Почему возникает стремление универсализации матрицы? Формулируется цель – свести простои к нулю. Для достижения вырабатывается ряд гипотез. Пример гипотезы: специалист, включенный в команду проекта, может достаточно быстро освоить технологии и знания, необходимые для реализации проекта, поэтому считаем, нам нужны «универсальные солдаты». Столкнувшись на практике с реальностью, быстрого освоения не получается достичь. Ожидаемый заказчиком уровень компетенций исполнителя высок, как следствие, цели проекта не достигаются. Вырабатывается корректирующее действие - развивать специалистов в рамках проекта. За чей счет? Придерживаясь стратегии «универсальных солдат» находим ответ - за счет заказчика.
В результате:
Резко возрастает себестоимость работ
Заказчик получает не качественный результат
Специалисты, перекидываемые с одного направления на другое, вынуждены начинать «с нуля», что приводит к недостижению экспертного уровня в конкретном направлении. Развиваясь как аналитик в решении задач регламентированного учета он достиг уровня middle+, и понимает, что до senior остается один маленький шаг, но узнает, что завтра он работает в проекте и будет решать задачи блока CRM, про которые он ничего не знает, т.е. его уровень вновь junior. Предположим, что работодатель сохранит уровень мотивации, но кто от этого выигрывает? Сохраниться ли интерес у сотрудника к решению простых задач и сможем ли мы продать услуги уровня junior по цене senior?
В текущей ситуации универсальность не распространяется на разработчиков, но предположим, что тренд универсальности затронет всех
В фантастической комедии «Эволюция», в итоге эволюционного процесса всё разнообразие организмов, закончилось одним универсальным. Пофантазирую на эту тему.
Итогом следующего шага будет являться реализация гипотезы универсальности разработчиков, не зависимо от технологического стека.
Далее трансформируем специализацию до ИТ-специалиста, который будет «и швец, и жнец, и на дуде игрец». Существенно упростим процессы комплектации команд проектов. А получим ли результат по проекту? Вопрос риторический.
Описанный сценарий, вероятно, никогда и нигде не произойдет. Поэтому, рассмотрю вариант эволюции матрицы, который позволит достичь удовлетворенности заказчика эффективным способом, снижая возможные риски
Эволюция "UP" - ориентация на клиента
Основным вектором эволюции «UP» является ориентация на заказчика. Важно понимание - кто наш заказчик, какие потребности у него и как эти потребности удовлетворить за счёт решений, создаваемых по итогам реализации проектов.
Этот вектор ложится в основу формирования организационной структуры, ролей и процессов управления проектами. Потребности заказчика классифицируются по решаемым в проектах функциональным задачам, формируя в нашей структуре набор функциональных компетенций. Компетенция – это бизнес функция заказчика, например, регламентированный учет, CRM, управление дистрибьюцией и т.п.
Портфель проектов по компетенции
Объединяющим понятием проектов является компетенция портфеля проектов. Руководитель портфеля является предметно прогруженным в компетенцию. Отвечает за развитие функциональных знаний аналитиков проектов портфеля, их найм и мотивацию, объем и финансовые показатели реализуемых проектов портфеля. Несет комплексную ответственность за направление в целом.
Организационная структура портфеля проектов
В портфель проектов входят все проекты по компетенции. Руководители проектов и аналитики административно подчинены руководителю портфеля проектов. Распределение специалистов по проектам производится в рамках частной проектной матрицы конкретного портфеля. Остальные члены проектных команд административно являются сотрудниками, не входящих в портфель проектов структур, например, отделов или департаментов разработки, тестирования, информационной безопасности. Включение указанных специалистов в команды проектов также происходит по матричному принципу, но уже в рамках общей для всех проектов организации матрицы. Таким образом, организационная структура организации — это матрицы в матрице.
Административно подчиняться руководителю портфеля проектов и входить в частную матрицу могут разные специалисты. Например, если технологический стек 1С используется только в одном портфеле проектов, то разработчики могут входить в организационную структуру портфеля проектов по компетенции
Проектная методология и проект
В организации создается проектный офис. В его функции входят - разработка базовых правил процессов проектной деятельности и проектной методологии. Часть методологии, которая является специфичной для портфеля проектов по компетенции, может быть разработана в рамках портфеля и применяться только для него. Примером может являться общий для всех проектов процесс формирования бюджета, а процесс проведения защиты архитектуры может быть разным. Иерархия проектной методологии позволит уменьшить трудозатраты для выработки процессов по схожим задачам и, в то же время, не запихивать в «прокурстово ложе» проекты разной специфики.
Проектный офис также ответственный за проведение проектных комитетов, на которых рассматриваться ключевые точки проекта.
Проектный офис разрабатывает и контролирует исполнение процесса инициации проекта, определяет состав материалов, необходимых для инициации. Подготовку проекта к инициации производит аккаунт менеджер совместно с командой портфеля проектов по наиболее близкой компетенции на основании запроса на проект. Желательно сохранить преемственность всего проектного цикла - от момента возникновения запроса на проект до его завершения. После подготовки необходимых материалов, проектный офис производит инициацию проекта.
Институт главных специалистов
Рассматриваемая структура предусматривает множество портфелей проектов, объединенных по компетенциям. В каждом из них существуют свои схожие по профессии группы - категории специалистов - аналитики, руководители проектов, разработчики и т.д. Для категории в целом возникает необходимость развития soft skills или профессиональных навыков, например, описание бизнес процессов в определенной нотации. К тому же пользу принесут институты обмена опытом и знаниями внутри категории. Это деятельность требует координации, планирования, обеспечения исполнения.
В бытность работы на промышленном предприятии я столкнулся с таким специалистом как главный металлург. Цитата из должностной инструкции: «Организует разработку и внедрение в производство прогрессивных, экономически и экологически обоснованных технологических процессов, обеспечивающих высокий уровень технологической подготовки производства, производительности труда и качества выпускаемой продукции на уровне лучших отечественных и зарубежных образцов».
Предлагается ввести аналогичные роли и в нашей структуре. Главный аналитик или разработчик, сможет решать задачи, являющиеся общими для категории специалистов.
Менеджер по продукту
Продукт — это осязаемый результат, у его жизненного цикла нет жёстких временных рамок, а для его создания и функционирования чаще всего необходимо несколько проектов. Проект — это процесс, он ограничен в рамках времени и бюджета. Итогом реализации проекта может являться продукт.
Менеджер по продукту ведет продукт и отвечает за его успех. Этот специалист определяет потребности клиента и его бизнес цели. Менеджер по продукту обеспечивает соответствие целевого результата проекта потребностям клиента.
Целесообразно ввести в структуру роль менеджера по продукту, не привязывая его жестко к конкретному проекту, лучше - вывести на отдельный элемент матрицы. Задачи могут повторяться у разных клиентов и задачи могут иметь подзадачи на стыке компетенций. При завершении одного проекта и инициации последующих проектов, менеджер по продукту обеспечит целостность продукта и восприятие клиентом неразрывности решения потребностей. Подобное объединение продуктов проектов позволит менеджеру по продукту стать носителем знаний о потребностях группы клиентов и применимых решениях, что позволит переиспользовать решения на основе лучших проектных практик, и, в будущем, перейти к проактивному предложению решений для клиентов.
Аккаунт менеджер
Аккаунт менеджер прикрепляется к клиенту и не зависит от принадлежности проекта к портфелю. Основной функцией является обеспечение коммуникаций клиента и проектных команд, сохранение и развитие взаимоотношений, общая координация работ с клиентом. В случае отсутствие отдельного ответственного за продажу, аккаунт менеджер может выполнять и эту роль.
Супервизор
В психологии есть такая роль - супервизор. Это наставник, который помогает менее опытным специалистам, это не тот, кто все знает и умеет, а тот, кто может свежим и опытным взглядом разобрать проблему, рассмотреть её с другой стороны.
Введении подобных ролей в организации повысит производительность и вовлеченность сотрудников, снизит риски выгорания.
Желательно, чтобы супервизор не являлся руководителем сотрудника. Это нужно, чтобы взаимодействие строилось на доверительных отношениях, не обременённых формальными механизмами.
Деятельность супервизора поддерживается и поощряется руководством организации. Супервизором должно быть престижно.
Итог эволюции "UP"
В итоге получается структура организации, обеспечивающая ориентацию на удовлетворение потребностей клиента эффективным способом. Структура учитывает специфику проектов, являясь гибкой и масштабируемой.
Заключение
Я рассмотрел два варианта эволюции. В реальной жизни их может быть гораздо больше. В статье описаны роли. Исполнение ролей может совмещаться или разделяться, а их количество не обязательно равно количеству специалистов, всё зависит от конкретного проекта.
Примечание
В статье есть ряд допущений. Выделены только часть специализаций и ролей с целью не утяжелять повествование и схемы
Рассматриваемые ситуации являются интегрированным пониманием автора и, отчасти, художественным вымыслом. Все совпадение случайны.