Мотивация проектной команды

Роль мотивации в успехе проекта

Все проекты в области IT в качестве основного ресурса используют человеческие ресурсы. Говоря проще, всю работу делают люди, участники проекта, все основные затраты идут на них, и успех проекта тоже на 90% зависит от людей. Учитывая это, трудно переоценить роль участников проекта со стороны подрядчика – консультантов и проектных менеджеров. От их квалификации и отдачи зависит много, если не все. И если найти квалифицированных консультантов сейчас можно, то мотивировать их на эффективную работу в проекте гораздо сложнее. Ведь это командная работа, и помимо индивидуальной мотивации членов проектной команды, должна быть «коллективная мотивация», то есть нацеленность не только на индивидуальные достижения, но и на достижение результата по проекту в целом, настрой на продуктивное внутрикомандное сотрудничество, на позитивные отношения с представителями заказчика и так далее. Достичь такого состояния команды непросто. Ведь команда состоит из личностей, да к тому же часто личностей непростых, людей с хорошим образованием, хорошо зарабатывающих, имеющих высокую самооценку. Простое администрирование здесь не проходит. Поэтому одна из главных задач руководителя проекта – выстроить правильную мотивационную политику внутри проектной команды, для того чтобы добиться максимальной синергии, высокой эффективности общей работы, что, в свою очередь, приведет к успешному завершению всего проекта.

Виды мотивации

Виды мотивации, которые рассматриваются в этой статье, в общем, соответствуют пирамиде Маслоу. Вот они:

  • Мотивация вознаграждением
  • Премирование (бонусы за результат)
  • Гарантия занятости
  • Повышение статуса
  • Профессиональный рост, получение проектного опыта
  • Чувство ответственности за результат
  • Чувство значимости личного вклада в общий успех
  • Удовлетворение от результата.

Можно добавить к этому списку командные мотивирующие факторы:

  • Чувство надежности в команде
  • Товарищество.

Теперь можно перейти к более подробному описанию этих факторов.

Мотивация вознаграждением – это стартовый мотивирующий фактор. Конечно, если мало платить, то никто за работу не возьмется. Причем мало – относительно среднерыночных показателей. Но после того, как сотрудник втянулся в проект, мотивирующее влияние денежного вознаграждения резко ослабевает. Сотрудник серьезно реагирует на резкие (минимум на 25%) изменения. Но реакция эта кратковременна. Так, если повысить оклад консультанту, ну, допустим, в 1,5 раза, то максимум первый месяц он будет работать интенсивнее, а затем вернется к обычному ритму. То есть сработает эффект привыкания. Постоянно же повышать зарплату невозможно, так как финансовые ресурсы всегда ограничены, тем более в проектах с ограниченным бюджетом.

Нужно еще учесть тот факт, что сотрудники реагируют на относительное увеличение вознаграждения, а не на абсолютное. Поэтому чем выше стартовые условия по зарплате, тем тяжелее для спонсора проекта мотивировать сотрудников ее увеличением. Понятно, если зарплата 1000, то увеличение до 1500 серьезно мотивирует, хотя и однократно. А если зарплата 5000, то увеличение до 5500 практически не мотивирует сотрудника. При этом ежемесячные затраты спонсора увеличиваются в обоих случаях на 500.

Вывод: вознаграждение (или заработная плата) достаточной величины обеспечивает привлечение необходимых квалифицированных ресурсов на проект. Но этот фактор оказывает небольшое влияние на увеличение эффективности работы сотрудников. Поэтому его нельзя относить к эффективным инструментам мотивации персонала.

Мотивация премированием (бонусы за результат) – почти то же, что и мотивация вознаграждением. Но это более действенный механизм мотивации персонала в проектной работе. При этом обязательно должны соблюдаться следующие условия:

  • Размер премии (бонуса) должен быть существенным по отношению к заработной плате (не менее 50% от месячного вознаграждения);
  • Размер премии (бонуса) должен быть заранее известен сотруднику;
  • Условия получения премии (бонуса) должны быть заранее известны сотруднику, лучше всего будет, если эти условия будут изложены в специальном документе (например, в бонусном письме);
  • Условия получения премии (бонуса) должны быть понятными и достижимыми;
  • Условия получения индивидуальной премии (бонуса) должны быть зависимыми от индивидуальных усилий сотрудника;
  • Условия получения командной премии (бонуса) должны быть зависимыми от командных усилий;
  • Такая премия должна выплачиваться не реже, чем раз в полгода (иначе повышение производительности труда произойдет только за пару месяцев до плановой даты получения премии);
  • При выполнении всех условий получение премии (бонуса) должно быть гарантированным.

То есть в компании, которая ведет проект, система проектного премирования должна быть хорошо развита.

Еще один момент – в некотором роде «соответствие цены и качества»: усилия, затраченные на получение премии, должны быть адекватны самой премии. Не стоит ждать от сотрудников, что они будут сидеть по ночам, если премия не поможет, как минимум, организовать хороший отдых, оплатить мероприятия по восстановлению здоровья.

Вывод: мотивирующее влияние премирования не стоит переоценивать. К тому же, здесь действуют все те ограничения, что и на заработную плату, – бюджет проекта всегда ограничен. Но при четкой системе премирования этот механизм мотивирования эффективен.

Мотивирование гарантией занятости – в период экономического подъема очень слабо мотивирует людей, так как всегда есть куда уйти. В период спада, кризиса – мотивирует гораздо сильнее. Но при этом сотрудник должен четко понимать, что улучшение качества выполнения проектных задач убережет его от увольнения, и наоборот. К сожалению, в кризисное время не все зависит от усилий сотрудников. А если люди чувствуют, что от их усилий мало что зависит, то угроза потерять работу их демотивирует. В этом случае действует тот же эффект привыкания, но теперь уже к «плохому».

Вывод: такой метод мотивации угрозой приводит к ухудшению морального духа в проекте. Не стоит этот способ мотивации делать основным. Но совсем отказываться от этого нельзя. Кроме возможностей, сотрудники должны ощущать угрозы.

Мотивирование повышением статуса – достаточно важный фактор. Конечно, действует на сотрудников по-разному, ибо есть люди с четко выраженными карьерными (в хорошем смысле слова) стремлениями, а есть люди, несколько равнодушные к этому. В современных российских компаниях этот механизм продекларирован, но задействован слабо. Может быть, мне просто не везло, но ни в одной компании лично я не получил четкий план моего карьерного роста. К сожалению, единственный серьезный способ карьерного роста – переход в другую компанию. Но это не тема данной статьи.

Я считаю, что этот мотивирующий фактор нужно активно использовать в проектах, но обязательно нужно учитывать следующие ограничения и требования:

  • Увеличение статуса (грейда, должности и тому подобного) часто ведет к увеличению стоимости этого ресурса. А плановый бюджет проекта при этом не меняется. Поэтому менеджеру проекта необходимо либо обещать такие изменения в конце проекта, либо брать на проект недооцененных перспективных сотрудников и потом в ходе проекта повышать их статус до запланированного в стартовом бюджете проекта.
  • Условия повышения своего статуса должны быть для сотрудника понятными и достижимыми.
  • Условия повышения статуса сотрудника должны быть известными и понятными для менеджера проекта.
  • Увеличение статуса (особенно назначение на вышестоящую должность) может вывести ценного сотрудника из проекта. Это характерно для матричных структур управления компаниями.

Вывод: это действенный фактор, который необходимо использовать в проекте, помня правило «не навреди».

Мотивирование профессиональным ростом, получением проектного опыта – очень действенный мотиватор, при условии, что проект действительно обеспечивает сотруднику профессиональный рост и получение необходимого проектного опыта. Хорошо действует на начинающих и специалистов среднего уровня. Для них все новое и незнакомое. Каждый день на проекте дает этим сотрудниками новые знания. С опытными и высококвалифицированными сотрудниками тяжелее – проект действительно должен быть новаторским либо должен очень четко, образцово управляться и тому подобное. Если высококвалифицированный сотрудник не найдет в проекте для себя ничего нового, то это будет его демотивировать.

В одном их моих проектов пришедший в него опытный консультант сразу заявил, что проект очень ординарный, но он ждет хорошего уровня управления проектом, ибо до этого участвовал в проектах с посредственным менеджментом. Это пример обратной связи (консультант стимулировал менеджера проекта, менеджер проекта – сможет стимулировать консультанта).

Вывод: это действенный фактор, который необходимо использовать в проекте, четко дифференцируя его по уровню каждого сотрудника. При этом менеджер проекта должен приложить все усилия, чтобы проект был хорошо управляем, использовать новаторские технологии и так далее. Ну, и желательно, чтобы проект имел хорошие шансы успешного завершения.

Мотивирование ответственностью за результат – в некотором роде «отрицательный» мотиватор. Но если использовать этот механизм конструктивно, то он может очень сильно стимулировать сотрудников. Если сотрудник не просто будет подвергаться регулярным проверкам результатов своей работы со стороны менеджера, а будет ощущать необходимость своей работы, чувствовать, что результаты его работы нужны для проекта, что их ждут его коллеги, что «если не он, то никто», – сотрудник будет вынужден (если он не неисправимый саботажник) прикладывать дополнительные усилия для достижения необходимых целей. Тут почти все зависит от менеджера проекта, от созданной им системы управления, от внутренней атмосферы проекта.

Вывод: это необходимый мотиватор, стержень всей системы проектной мотивации. Без этого способа все остальное теряет смысл. Правильное применение этого механизма – обязанность менеджера проекта. Здесь все зависит от его профессионализма.

Мотивирование чувством значимости личного вклада в общий успех – развитие предыдущего механизма. Каждый сотрудник должен знать, что его работа не осталась незамеченной, что она внесла вклад в общий результат, что его усилия привели к общему успеху. Менеджер проекта должен подчеркивать это, упоминать достижения каждого сотрудника. И тогда сладкий вкус причастности к победе запомнится сотруднику надолго, и он будет и в следующий раз работать с максимальной отдачей.

Вывод: менеджер не должен забывать отмечать вклад каждого сотрудника, входящего в проектную команду. И в дальнейшем это принесет свои плоды. Вообще, менеджерам нужно как можно чаще общаться с командой, со всеми вместе и индивидуально, поощрять сотрудников, хвалить их и тому подобное. Естественно, соблюдая правильные пропорции.

Мотивирование удовлетворением от результата – опирается на творческое начало человека. Главное, чтобы это было заметно не только самому сотруднику, но и его коллегам. Нужно отбросить скептическое отношение к новаторским предложениям и поощрять сотрудников к творчеству. В IT-проектах без этого нельзя. Опять же, не забывая про главную задачу проекта – достижение результата.

Вывод: механизм нужно активно применять на проектах, но четко отслеживать, чтобы творческий процесс не свалился в «автогенерацию», то есть в генерирование идей, не ведущих к результату. Тут все в руках менеджера.

Демотивирующие факторы (внутренние и внешние)

Демотивирующие факторы можно разделить на внутренние факторы (управляемые) и внешние (большей частью неуправляемые). Соответственно, в каждом случае необходимо предусмотреть механизм управления факторами либо смягчения их воздействия на сотрудников.

Перейдем к внутренним факторам. Тут практически зеркальное отражение линейки мотивирующих факторов:

  • Низкое вознаграждение
  • Плохая система премирования
  • Отсутствие перспективы
  • Плохая управляемость проекта, отсутствие мониторинга результатов
  • Рутинный труд, невозможность получить новые знания и навыки
  • Невнимание к сотрудникам.

Рассмотрим каждый отдельно и механизм управления этими факторами.

Низкое вознаграждение – если заработная плата сотрудника «ниже рынка», если он чувствует в этом смысле себя недооцененным – заставить работать его трудно. «Голодное брюхо» ко всему глухо. К сожалению, обычно менеджер проекта имеет слабое влияние на уровень вознаграждения. Однако линейные руководители, которые обычно и определяют уровень заработной платы, должны четко понимать: маленькая зарплата приведет к тому, что на проекте останутся сотрудники, соответствующие этому низкому уровню, и результат проекта будет недостижим. Менеджеру проекта нужно чувствовать такие моменты и немедленно сигнализировать соответствующему линейному руководителю. То есть заработная плата не должна быть низкой, она не должна быть высокой, она должна быть достаточной для привлечения на проект необходимых сотрудников.

Вывод: менеджер проекта должен по возможности мониторить уровень вознаграждения сотрудников и при первых признаках недовольства сотрудниками своей низкой зарплатой сигнализировать об этой ситуации линейному руководителю.

Плохая система премирования – невнятная система премирования, без четких правил и сумм удручающе действует на сотрудников. Сотрудники начинают понимать, что премию получить будет так же сложно, как и выиграть лотерею. В лучшем случае производительность труда останется на прежнем уровне, а скорее всего – снизится. Тут менеджеру проекта также нужно чувствовать такие моменты и немедленно сигнализировать соответствующему линейному руководителю. Правда, к сожалению, менеджер проекта может не знать ничего о премировании сотрудников своей команды, влияя на начисление премии только косвенно. Задача линейных руководителей, компании в целом – разработать и применять четкую систему премирования. Требования к ней приведены в описании мотивирования премированием.

Вывод: если есть возможность повлиять на систему премирования сотрудников – менеджер проекта должен это делать.

Отсутствие перспективы – если сотрудник не знает, что с ним будет после проекта, он не будет стремиться завершить его в срок. Если сотрудник не будет понимать, как успех проекта повлияет на его продвижение, – он не будет стремиться работать эффективно. Если проект ничего не дает сотруднику в профессиональном плане, если непонятно его влияние на рост заработной платы – хорошей работы на проекте от этого сотрудника никто не дождется.

Вывод: менеджер проекта должен уточнять с линейными руководителями все правила и сообщать их сотрудникам своей команды, для того чтобы они четко представляли свои перспективы. Команду желательно подбирать так, чтобы обеспечивать каждому сотруднику возможности роста в ходе проекта.

Плохая управляемость проектом, отсутствие мониторинга результатов. Плохая управляемость проекта, а особенно отсутствие мониторинга результатов работы каждого сотрудника проектной команды, приведет к тому, что сотрудники перестанут прикладывать усилия для достижения результата. У них сложится четкое ощущение, что от них ничего не зависит, их работа не особенно нужна на проекте, вместо них работу сможет сделать кто-то другой. В результате через некоторое время менеджер с огорчением отметит катастрофическое отставание по срокам, при этом сотрудники большую часть рабочего времени будут сидеть в интернете.

Вывод: все в руках менеджера проекта. Создав четкую систему управления проектом, работая по циклу Plan-Do-Check-Act, правильно ведя проектную документацию, менеджер сможет перевернуть ситуацию.

Рутинный труд, невозможность получить новые знания и навыки. Как уже указано выше, консультантам нужны новые задачи, новые горизонты для своего профессионального роста. Конечно, без рутины на проекте не обойтись, но необходимо такую работу правильно перераспределять между сотрудниками, входящими в команду, учитывая их квалификацию, склонности и особенности характера.

Вывод: менеджер проекта должен правильно распределять задачи между сотрудниками проектной команды.

Невнимание к сотрудникам. Нужно помнить, что вокруг работают люди и они ценят, когда на них обращают внимание. Если общаться с консультантами сухо, не хвалить их, не поощрять, то моральный дух команды будет падать. Нужно сочетать ежедневное подбадривание и периодическое публичное признание достижений сотрудников. При этом нужно обязательно учитывать особенности каждого сотрудника команды.

Вывод: менеджер проекта должен знать своих людей и уделять им необходимое внимание.

Рассмотрим внешние демотивирующие факторы. Они связаны или с общим состоянием экономики либо с экономическим состоянием компании заказчика и/или компании подрядчика. Форс-мажорные ситуации рассматривать не будем.

Вот эти факторы:

  • Спад в экономике
  • Ухудшение финансовой ситуации у заказчика
  • Ухудшение финансовой ситуации у подрядчика.

Управлять этими факторами менеджеру проекта невозможно. Конечно, было бы неплохо иметь какую-то «подушку безопасности», но в современных IT-проектах такую роскошь может себе позволить редкий заказчик. В любом случае менеджер проекта должен до последней возможности пытаться удержать проект и команду. Люди это оценят и будут в целом работать лучше. Ну, а если ситуация станет критической – нужно вовремя и честно предупредить людей.

Мотивационная политика руководителя проекта

Существует целое многообразие стилей управления проектом. Между следующими крайностями – жесткое управление, мягкое управление, централизация, децентрализация, абсолютно формализованное управление, неформально-креативное управление и тому подобное – каждый менеджер проекта выбирает свою золотую середину, в зависимости от личных качеств менеджера, культуры компании, в которой он работает, требований вышестоящего руководства и так далее.

Таким же образом менеджер проекта выбирает мотивационную политику, отбирая в свой мотивационный пакет необходимые «инструменты». «Золотого рецепта» для этого нет и не может быть. Необходимо просто помнить, что главные ресурсы в проектах – это люди, со всеми своими сложностями. Поэтому нужно использовать несколько способов мотивирования сотрудников проектной команды, гибко применяя их в зависимости от ситуации и личных качеств конкретного сотрудника.

Для успешного мотивирования главное, на мой взгляд, – это коммуникации с сотрудниками проектной команды. Менеджеру проекта необходимо общаться со своей командой как можно чаще, индивидуально и коллективно, используя формальные способы (переписка, совещания, семинары, конференции и тому подобное) и неформальные способы (беседы, совместные обеды, командные мероприятия и тому подобное). Необходимо дать понять сотрудникам команды, что они не подчиненные, а коллеги, поощрять их активность и самостоятельность. Ну, и нельзя забывать о базовых способах мотивирования, то есть о материальной стороне дела.

Вообще, на мой взгляд, каждому менеджеру проекта необходимо определить свою мотивационную политику на проекте, лучше всего записать ее и стараться ей следовать в ходе выполнения проектных работ. При этом опубликовывать эту мотивационную политику не обязательно.

Team building в правильном смысле этого термина

Почему-то термин team building в обиходе свелся к отождествлению с командными мероприятиями развлекательного характера. На самом деле, это очень сложный процесс, который целиком ложится на плечи менеджера проекта. Необходимо в достаточно сжатые сроки из разнородной группы назначенных на проект сотрудников создать жизнеспособный проектный организм, превратить просто людей в команду, способную решать совместно сложные задачи. Задача очень непростая, и в этой статье я только слегка коснусь ее с точки зрения мотивации.

Выстраивание команды должно идти в проекте постоянно. Огромную роль играет при этом личное общение. Необходимо регулярно проводить общие совещания, применять для решения сложных задач мозговые штурмы. Нужно заставлять, если это возможно, проблемные вопросы обсуждать на личной встрече, а не вступать в бесконечную «спамообразную» переписку по электронной почте. Тогда люди почувствуют друг друга, поймут полезность и эффективность совместной работы в команде. А совместная деятельность, прозрачная и понятная, будет мотивировать их работать лучше.

Что касается командных мероприятий развлекательного характера – они необходимы. Но эти мероприятия должны быть строго дозированы и привязаны к определенным событиям (начало проекта, закрытие большого этапа проекта, успешное завершение всего проекта и тому подобное). В этом случае сотрудники воспримут это мероприятие как вознаграждение, как внимание к себе со стороны руководства, как оценку своих заслуг. И тогда будут стремиться в следующий раз отработать так, чтобы заслужить такое мероприятие.

Накопление опыта

Как вся проектная деятельность, мотивирование участников проекта – сложный и многовариантный процесс. Инструментов много, применять их можно по-разному, в каждом случае возникают свои нюансы. Менеджер проекта должен накапливать этот опыт, анализировать свои удачи и неудачи, корректировать свою мотивационную политику. И тогда на последующих проектах мотивирование сотрудников будет более и более удачным.

Послесловие

В этой статье я не пытался чему-то учить. Просто это мой опыт, это результат общения с коллегами. На мой взгляд, работа с участниками проекта очень важна для его успеха. Недооценивать ее – значит увеличивать риск неудачного завершения проекта.

Скорее всего, я перечислил малую часть мотивационных инструментов. Но эти способы мною опробованы, и я могу дать им оценку.

Если в своих отзывах на эту статью вы сообщите о своем опыте мотивирования проектной команды, я буду вам крайне признателен.

Фото: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Профессор, Москва
По поводу оценки 360:
Максим Артамохин пишет: Просто хотел высказаться по этому поводу. Встречал восторженные отзывы по поводу этой методики, включая ''за то мы знаем такие технологии, которые решат все вопросы''. В основе этой методики лежит банальное непонимание восприятия человека и его основной составляющей потребности быть частью социума. Вот понятно, что телешоу вроде ''Дом-2'' и тому подобные червяков в мозги насажали, но тем не менее, в части проектной работы, думаю, один из вариантов ''вредных советов''.
Максим, а в чём банальное непонимание? И ''Дом-2'' причём? :-! Как раз ''формально'' система отражает стремление человека быть частью социума. Чего социум (команда) порешал, то и получили. Но если вы внимательно читали мой пост, то я написал, что ПРОФЕССИОНАЛЬНАЯ составляющая деятельности участника команды ТАК оцениваться не может. Речь идёт об оценке члена команды как ЧЛЕНА КОМАНДЫ. Кстати, в отличие от вас, я ВОСТОРЖЕННЫХ отзывов не встречал. Как-то вот люди вокруг меня - народ сдержанный. Я бы на эту тему высказался так: ''ЕСТЬ МНЕНИЕ, что в определённых условиях (учитываем национальный менталитет, корпоративную культуру и т.д.) применение оценки 360 при распределении командного бонуса может дать положительный эффект''. С наилучшими пожеланиями, Станислав.
Руководитель управления, Украина
Максим Беспалов пишет: И все эти доминанты Вы взяли из длительных личных бесед с господами М+П, прогуливаясь по чудесному рублевскому бору, я надеюсь? Или кремль.ру уже публикует такие данные по всему составу чиновников? Извините, но уже сильно хочется съязвить.
Другой бы спорил: http://denisencov.h17.ru/tipologiya%20yunga.html может эта статья Вам будет полезна.
Менеджер интернет-проекта, Москва
Если вернуться опять к управлению проектами: 1. Как мотивировать команду проекта в организации со слабой матричной структурой, то есть когда работы по проекту ведутся ночью, после выполнения ''основных должностных обязанностей''. :) Работа в таких структурах движется гораздо медленнее, естественно, чем при выделении людей исключительно на проект. Но чтобы она вообще двигалась - нужно соблюдение нескольких условий. Во-первых - каждый член проектной команды осознает исключительную важность проекта и своей роли в нем (''если не я, то кто?'', ''если я это не сделаю, то все рухнет/придут другие и все испортят'' и т.п.). Во-вторых - каждый член команды буквально физически ощущает, как он развивается и учится в ходе работы над проектом (PM так планирует распределение работ, чтобы каждый осваивал какую-то новую компетенцию, при этом задействуя и свои сильные стороны, чтобы польза была не только члену команды от развития, но и проекту). В-третьих - банально по завершении ключевого этапа проекта выплачивается премия каждому, с учетом вклада в проект. Тогда оставшиеся этапы пролетают на душевном подъеме. А по итогам проекта - опять премия. 2. ''Что делать Наташе, чтобы завоевать доверие команды и стать реальным (а не назначенным) лидером''.
Олег Кашуба пишет: а) доказать свою компетентность; б) наладить внутренние коммуникации; в) уметь брать ответственность на себя; г) взять на себя необходимые внутренние коммуникации; д) контролировать работы; е) помогать коллегам и т.д.
Ровно это. :)
Профессор, Москва
Светлана Шишкова пишет: В-третьих - банально по завершении ключевого этапа проекта выплачивается премия каждому, с учетом вклада в проект.
Так как этот вклад определять? Светлана! Конкретный вопрос - можно ли для определения вклада участников использовать оценку 360 (см. дискуссию выше). Я понимаю и сильные и слабые стороны этой идеи. Каково Ваше мнение? С уважением, Станислав.
Менеджер интернет-проекта, Москва
Станислав Фурта, мое мнение: оценка 360 - прекрасный инструмент, очень полезный, хотя формализованно на практике, если только это не вписано в стандартные бизнес-процессы компании, ее не проводят. Обычно вклад в проект определяется по методике, сходной с оценкой 360, но оценивают только вышестоящие (PM, заказчик, другие формальные и неформальные лидеры проекта), мнение коллег учитывается редко, и оценка производится по качественным критериям, то есть ''на глаз''. :) Иногда решения по вкладу в проект принимает один человек - PM. А иногда на его решение еще и накладываются корректировки извне (например, для той же слабой матричной структуры - со стороны генерального или финансового директора компании). :) Но инструмент полезный, если члены проектной команды способны объективно оценить работу других.
Профессор, Москва
Спасибо, Светлана! Ей-Богу, видел, что бонус распределяется по 360. НО! Там в документах компании было прописано, что бонус состоит из двух частей. Одна часть - это по сути дела вклад (то, о чём вы говорите и именно так, сверху, распределялся), вторая - бонус за КОМАНДНУЮ работу, и вот тут работала оценка 360 по критериям, которые сами члены согласовали ''на берегу''. С уважением, Станислав.
Нач. отдела, зам. руководителя, Москва

Интересная тема, но что-то дискуссия зашла непонятно куда...

Матричная структура управления имеет массу самых серьёзных недостатков. Хуже неё я ничего не видел! :)
В такой структуре РП - это всегда и везде ''козел отпущения''! (прямым текстом, извините)

Управление в такой структуре в немалой степени сводится к разрешению внутренних вопросов, процессов, конфликтов.
Это становится чуть ли не основным и главным направлением всей работы РП. Отсюда все последствия.
При такой структуре часто применяется практика костов (Costs), где уже включены премиальные (всего и каждого отдела, включая, конечно же, и всех руководителей отдела(-ов), чьи сотрудники участвуют в проекте(-ах)).

Таким образом, РП здесь практически не имеет основного мотивирующего инструмента для команды, как финансового.
Помимо этого инструмента, он не имеет ещё и прямого подчинения к себе участников проекта. Оно лишь косвенное и временное (по сути - формальное). Об этом прекрасно знают участники (специалисты), об этом знает и их руководство (а себя они почитают рангом повыше Вас, РП, и ''вес'' в компании, как правило, имеют особый и больше, чем Вы).

В проектном бизнесе ИТ-компаний такая структура (и схема) практически ''де-факто''. К большому сожалению!!!
Благоприятно это складывается лишь на общих затратах копании (а затраты на персонал - одна из главный статей всех расходов!), но вносит значительный внутренний отрицательный эффект (в части организации и управления) для каждого её проекта, совокупность которых, является, по сути, её бизнесом (и доходом)!

P.S. Точно так, конкретно, ситуация обстоит у системных интеграторов.

IT-менеджер, Москва
Сергей. Я думаю, матричную структуру лучше обсудить в отдельной ветке в разделе ''Project management. Как управлять проектом''. Тема серьёзная. Моё мнение: избежать ''матричности'' в современных проектах невозможно. Даже если команда работает на проекте full time, остальные участники проекта - нет. А управлять ими нужно. А дискуссию по моей статье можно закрыть. В общем, все высказались. Спасибо всем, кто откликнулся на мою статью. Лично мне было полезно узнать Ваше мнение.
1 9 11
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
РБК представил рейтинг работодателей 2024

Средняя заработная плата в компаниях — участниках рейтинга составила около 155 тыс. руб. в месяц.

Названы самые привлекательные для молодежи индустрии

Число вакансий для студентов и начинающих специалистов выросло за год на 15%.

Россияне назвали главные условия работы мечты

Основные требования – широкий социальный пакет, а также все условия для комфортного пребывания в офисе.

Власти Москвы заявили об отсутствии безработных в столице

При этом дефицит кадров наблюдается во всех отраслях.