Система мотивации команд разработки и внедрения систем управления производством

30.07.18

Команда

Вопросы мотивации каждая компания решает по-своему. Руководитель проектов по автоматизации Артем Шамсутдинов рассказал о том, какую систему мотивации выбрали для себя в компании.

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

 

Как первоначально стимулировали программистов

 

Коротко о нас:

  • Мы занимаемся разработкой и внедрением систем управления производством на базе 1С и не только (большая часть не на 1С);
  • По численности нас – 9 человек, включая руководителя отдела.
  • Команда оформлена по слабоматричной структуре – есть 3 программиста, а остальные сотрудники в разных проектах занимают разные роли: в одних они выступают как аналитики, в других – как инженеры по внедрению (выполняют какие-то вспомогательные функции). Это зависит от специализации – если люди преуспели в каких-то областях, то в проектах по этим областям они становятся экспертами, аналитиками, а в остальных проектах их роли могут меняться – они могут заниматься и установкой систем, и обучением пользователей на местах.

Какая система мотивации была первоначально и была ли она вообще?

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

  • Был фиксированный оклад, у каждого – свой. Он назначался как компромиссный вариант, удобный как работодателю, так и работнику.
  • Были премии по результатам выполнения работы. Они были “стихийными” – выплачивались без четкой привязки к периоду года, к завершению работы над проектом или к другим факторам. Предугадать поступление этих премий до их выплаты было нельзя, поэтому никто к ним особого интереса не проявлял.
  • Самое печальное в этой системе мотивации было то, что сотрудник мог по нескольку месяцев не выдавать результата по работе, но получать при этом зарплату. Вроде он работает, что-то делает, к заказчику приезжает, но эти встречи заканчиваются безрезультатно – заказчик работу не принимает, и процесс зацикливается.

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

Из-за этого эффективность работы сильно падала – большинство проектов завершались с большим опозданием, бюджеты проедались неоднократно. Зарплата выплачивалась, но премий и дополнительных бонусов, естественно, не было…

 

Мотивация – это то, чего ждут сами работники

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

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

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

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

 

Задачи, которые должны были решать нововведения

Что руководство хотело получить от новой системы мотивации?

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

 

Новые правила расчета зарплаты

Система мотивации строилась на двух показателях.

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

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

 

 

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

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

 

Появился еще такой термин как внутренняя «продажа» работы. Что он означает?

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

 

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

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

 

 

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

  • Описание задачи – здесь на слайде я его не указал, но обычно мы сотруднику задачу расписываем очень подробно.
  • Стоимость этой задачи;
  • Срок выполнения;
  • И дополнительный показатель – коэффициент сгорания. Что это такое и зачем нужно – я дальше покажу.

 

 

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

  • Нужно предупреждать руководителя проекта, если задача не укладывается в сроки. Например, сотрудник получил задачу, ему на первых порах вроде бы все понятно, но через пару дней обнаруживаются какие-то трудности. Раньше можно было несколько недель искать решение или ждать, что задача сама разрешится, но сейчас сотрудник знает, что о возможной задержке руководителя нужно предупреждать вовремя, иначе это снизит стоимость работы. А если сотрудник предупредил и обосновал, почему не успевает, тут уже руководитель проекта принимает решение – либо пересматриваются сроки по согласованию с заказчиком, либо находятся какие-то дополнительные ресурсы для выполнения задачи в срок.
  • Спрашивать. Если сотрудник столкнулся с какими-то трудностями и не знает, как задачу выполнять – он также спрашивает либо у руководителя, либо у своих коллег.
  • Соответственно, если сотрудник считает, что сроки все-таки были несколько занижены, он опять-таки должен обосновать это перед руководителем проекта.

 

Каким образом производится расчет выработки?

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

Коэффициент сгорания определяет скорость и снижение стоимости работы для сотрудника:

  • Если задача высокорисковая (например, она выполняется в первый раз или имеет определенный риск), то для нее устанавливается коэффициент 0.95.
  • Если задача типовая, например, разработка какого-то технического задания или разработка какого-то программного модуля, который уже разрабатывался несколько раз с небольшими доработками, то для нее коэффициент – 0.9. Если сотрудник не успевает выполнить такую задачу в срок, стоимость для него сгорает быстрее.

 

Расчет оклада (той зарплаты, которую сотрудник получает в итоге), строится по схеме, представленной на слайде. Определяется до трех шагов:

  • Если выработка за месяц меньше гарантированного оклада за тот же срок (если сотрудник не выработал норму), он получает гарантированный оклад. По-другому было нельзя.
  • Если выработка за месяц больше гарантированного оклада, то рассматривается суммарный показатель выработки нарастающим итогом за все предыдущие периоды, включая текущий. Причем, если раньше мы этот показатель обнуляли, то с того момента, как была введена система мотивации, мы перестали его обнулять, и теперь эта сумма только растет. Так вот, если выработка нарастающим итогом на текущий период меньше гарантированного оклада нарастающим итогом, то также выплачивается гарантированный оклад. В данном случае это некая страховка за предыдущие периоды: если сотрудник раньше не справлялся со своей нормой (по каким-то причинам не вырабатывал ее), то нет смысла выплачивать ему больше.
  • И третий вариант: если выработка нарастающим итогом оказалась выше гарантированного оклада нарастающим итогом (сотрудник выполняет и перевыполняет свою норму), то сотруднику вместо оклада выплачивается сумма выработки. А если превышение более чем 20%, то помимо выработки выплачивается еще и разница между гарантированным окладом и выработкой – некая дополнительная премия за переработку, за высокий темп роста. Но эта премия выплачивается хитро: 70% выработки выплачивается сразу, а 30% – по завершении либо какого-то большого этапа проекта, либо проекта целиком.

 

Результаты после внедрения системы мотивации

На слайде показан примерный график, показывающий, как в среднем у нас теперь меняются выплаты:

  • Синяя линия – гарантированный оклад для сотрудника,
  • Желтый тренд – это его выработка,
  • А оранжевые прямоугольники – это то, что сотрудник получает по факту, его реальный заработок.

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

 

 

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

  • Процент закрываемых задач и процент выполнения проектов в срок значительно вырос – до 90%.
  • Доход сотрудников в среднем увеличился на 60-70%.
  • Дополнительный «бонус» – текучесть кадров составила 0%, и те сотрудники, которые работали у нас на момент внедрения системы мотивации, продолжают работать и по истечении этих полутора лет – коллектив остался тот же.

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Болезни роста: эволюция отдела разработки

Коммуникации ИТ-компания Бесплатно (free)

Многие руководители считают, что сто человек работают в сто раз эффективнее, чем один. Однако масштабирование – нелинейный процесс. Производительность большой команды не всегда равна сумме производительностей ее членов. Как сделать так, чтобы члены команды усиливали друг друга, а не тормозили? Компания ИСВС проходила этот путь и знает ответ!

12.04.2024    1311    0    vasilnikol    18    

25

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

Коммуникации Бесплатно (free)

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

27.02.2024    1069    0    user1561517    3    

13

Как реорганизовать работу проектного департамента, чтобы быть №1

Внедрение изменений Бесплатно (free)

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

14.02.2024    616    0    user1270271    2    

7

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

Мотивация Бесплатно (free)

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

13.02.2024    794    0    izybaevda    5    

15

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Для руководителей подразделений новые проекты вызывают желание получить максимальный эффект от реализации идей, а также опасения, верно ли выбран ориентир нововведений. О том, как справиться с трудностями, дойти до цели и внедрить 1С:ERP на производственном предприятии, ежедневно выпускающем десятки тысяч единиц готовой продукции, расскажем в статье.

30.01.2024    7068    0    user1578851    16    

16

Зачем нужны аналитики на проектах автоматизации

Анализ потребностей и поиск решений Бесплатно (free)

Исторически сложилось так, что аналитик 1С многими воспринимается как вечный падаван, который обеспечивает разработчиков информацией, а пользователей – инструкциями. Не согласимся с таким подходом и на примере реального кейса покажем, почему именно аналитик должен стать лидером проекта автоматизации.

18.01.2024    1667    0    user1754524    19    

12

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

Сейчас на рынке много объемных проектов, и специалисты часто сталкиваются c перегрузками. Чтобы сохранить ресурсное состояние и не допустить выгорания, нужна личная работа человека и грамотный подход руководителей. В статье рассказываю, как мы помогаем сотрудникам справиться со стрессом.

15.01.2024    1795    0    KChebykina    0    

32

DevRel: почему им стоит заняться уже сегодня

Коммуникации Обучение и наставничество Бесплатно (free)

DevRel (developer relations или просто технический пиар) – направление развития и поддержки IT-бренда компании: почти как PR (Public Relations), только в центре внимания находятся технические процессы и технологии, а не маркетинг. О том, зачем DevRel нужен компаниям, какие есть форматы, кто уже запустил DevRel, что из этого получилось, и почему это становится трендом, пойдет речь в статье.

09.01.2024    1748    0    a_plastinin    2    

16
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Kutuzov 739 30.07.18 11:05 Сейчас в теме
Здорово, что скорость выполнения задач выросла на 50%. Два вопроса:
1) Почему компания не зарабатывает на 60% больше, чем раньше?
2) Сотрудники сами выбирают себе задачи, или делают то, что скажут? Во втором случае как разруливаете конфликты, что кому-то достаются задачи "по-вкуснее", а кому-то - "шлак"?
+
2. Идальго 227 30.07.18 13:22 Сейчас в теме
Блин, так сложно о такой простой идее... И ещё я не понял, вот "продали" работнику задачу скажем за 10 часов, а потом раз и оказалось, что нужно на неё 30 часов. Клиент согласился на 20. Оставшиеся 10 часов кто оплачивает? Как происходит первичная оценка (скрам голосование, личный опыт или что-то другое?) и последующая корректировка?
+
3. strange2007 144 07.08.18 11:14 Сейчас в теме
Вроде у многих франчей такие системы и внедрены, а часто даже и круче. Только тут у сотрудников ориентация не на то, что бы сделать лучше, а на своевременное закрытие часов и получение более "вкусной" задачи. Тогда как автоматизатор только ориентирован на повышение всяких показателей и получение плюшек в виде денег. Как правило всё такое хорошее заканчивается, как только денег становится мало.
А в целом статья хорошая, т.к. всё кратко и по существу. Думаю, для многих будет полезной.
+
Внимание! Тема сдана в архив