В компаниях с матричной структурой организации между руководителями проектов и отделов периодически возникают конфликты. Борьба за человеческие ресурсы (далее ресурсы), сроки выполнения задач и их приоритет, споры об ответственности и принятии решений и так далее. Если в вашей компании такого нет, то вы — счастливое исключение, подтверждающее правило.
Некоторые руководители считают, что конфликты, возникающие в матричной структуре, способствуют поиску наиболее оптимальных решений, так как рассматриваются интересы обеих сторон. Но в то же время конфликты, порождаемые матрицей, являются причиной срыва сроков выполнения задач и падения производительности и эффективности.
Есть веские причины, не позволяющие упразднить отделы, чтобы все ресурсы могли находиться в проектах. Во-первых, не все специалисты нужны на все время жизни проекта, и нужно решать, что делать с ними, когда задачи заканчиваются. Во-вторых, руководитель проекта может быть недостаточно компетентен, чтобы не только нанимать нужных специалистов, но и впоследствии заниматься развитием их потенциала в компании. В-третьих, руководитель может быть недостаточно компетентен, чтобы оценить правильность решения задач.
Ключ к решению проблемы — в выстраивании правильного взаимодействии между проектами и отделами. К ней есть грамотный подход, к которому я пришел за последнее десятилетие работы в ИТ.
Каково назначение компании, если вы не Стив Джобс и “изменить мир” не является вашей главной целью? Большинство скажет, что зарабатывать деньги. Об этом написано в любой книге о бизнесе. Именно этот факт часто упускается при разделении полномочий и ответственности между отделами и проектами.
Как раз проект является той движущей силой, которая создает продукт/сервис и приносит прибыль компании. Проект — это конвейер, который использует различные ресурсы для изготовления продукта. Следовательно, распределение полномочий и ответственности должно быть направлено, в первую очередь, на поддержку проекта. Ресурсы должны полностью выделяться на проект, а не распыляться на выполнение задач в отделах. Почему? Вот аргументы.
Задача проходит через отдел
Когда задача ставится отделу, она попадает вниз бэклога задач. Менеджер проекта должен приложить массу усилий, чтобы обосновать руководителю отдела, почему его задача наболее приоритетна.
Получается, что проект начинает зависеть от личной расстановки приоритетов руководителем отдела. Это приводит к неопределенности со сроками решения задач, ведь другой проект может поставить задачу, которую сочтут более важной. Такой подход приводит к тому, что общее время решения задачи может значительно превышать фактически потраченное на нее время. Для руководителя проекта это сущий ад — координировать задачи между отделами и учитывать их зависимости. Как можно составить точный план проекта в таких условиях?!
Частичное выделение рабочего ресурса на проект
Для меня самая нелепая ситуация — выделение ресурса на проект на определенный процент времени. Например, руководителю проекта говорят, что “только 70% ресурса выделяется на ваш проект, а другие 30% идут на другой”. Обосновывая это тем, что “не только у вашего проекта есть задачи”. Такой подход приводит к тому, что вместо одного “недовольного” проекта мы получаем два, так как их задачи влияют на обоюдные сроки.
Почему мой проект должен зависеть от другого? Что лучше: один проект, сделанный вовремя, или два проекта, сдвинутые по срокам? Если возникает нехватка ресурсов, не нужно пытаться успеть везде, но понемногу. Нужно полностью закрыть потребности одного проекта и искать ресурсы для другого.
Стоимость передачи информации
Составляя бюджет и план проекта, менеджер определяет необходимые ресурсы и срок, на который они нужны. При этом нужно не забыть про внешние зависимости, стоимость закупки оборудования, ПО и услуг. Но практически никто не учитывают важную статью расходов, которая сильно влияет на проект.
Очевидно, что проект, имеющий выделенные ресурсы, находящиеся в одном помещении, будет выполнен быстрее и при меньших застратах, чем проект, в котором задачи передаются в отделы. Почему так? Еще Алистер Коберн описал, как расположение членов команды и их погруженность в проект влияет на стоимость передачи единицы информации. Если ресурс выделен на проект и обладает достаточным контекстом, то для описания задачи ему нужно передать меньший объем информации, чем ресурсу, находящемуся внутри отдела. Передаваемый объем информации напрямую влияет на срок проекта, а, следовательно, на бюджет.
Попробуйте сами посчитать сколько времени вы тратите на передачу информации.И как будет лучше.
Увлеченность проектом
Судя по стартапам, в которых все работают в едином порыве творческого энтузиазма, увлеченность членов команды напрямую влияет на успех проекта. С подобным драйвом могут быть проблемы, если вы сотрудник отдела и вам сегодня дают задачу из одного проекта, а завтра из другого. Не успевая погрузиться в проект, вы становитесь машиной по реализации фич, а не человеком, двигающим его вперед.
Если менеджер проекта хочет, чтобы у участников проекта были желание жить этой работой и драйв, их нужно привлекать в проект на длительный срок. Так они почувствуют связь между своей работой и успехом проекта. Их личный успех будет равноценен успеху проекта, и наоборот.
Agile
Для проекта, работающего по Agile, передача задач в отделы убивает саму суть этой методологии, т.к. исполнитель заранее неизвестен и невозможно создать команду. Есть одно исключение, это когда вся команда находится в отделе и хотя бы в рамках отдела выделена на проект.
Идеальный проект
Чтобы получить идеальный проект с максимальной эффективностью и высокой производительностью, нужно создать конвейер на котором задачи беспрепятственно перетекают из “To Do” в “Done”. А для этого проект нужно снабдить всеми необходимыми ресурсами. Традиционный подход передачи задач в отделы мешает созданию конвейера, а, следовательно, эффективности и производительности.
Идеальный отдел
У идеального отдела должны быть три главных задачи:
— нанимать лучших
— обеспечивать постоянное развитие сотрудников
— обеспечивать наилучший уровень решения задач на проекте
Автор: dmitry_ov
