Не знаю, как вы, а я люблю экспериментировать над людьми.
Обычно я не спрашиваю мнения людей, но в этот раз эксперимент проводился по их собственному желанию.
Люди хотели, чтобы я создал для них новую систему мотивации.
Ну, я это сделал.
Статья немного длинная, потому что.
Я постарался изложить не только вход и выход, но и процесс разработки системы, проблемы, которые возникали на этом пути и как мы их решали.
Возможно, вам будет полезен наш опыт – если не весь, то какая-то его часть.
Итак, на входе стоит небольшая команда программистов 1С из трёх человек, работающих на фиксированной основе.
Плюс я, их руководитель, по своей основной компетенции еще и программист 1С.
Бизнес процесс - самый распространенный: 1. Программистам ставят задачи от любого отдела; 2. Задания согласовываются при необходимости.
Список утверждающих различен для разных задач; 3. Задачи имеют срок выполнения и могут быть перенесены (не более двух раз).
До начала исполнения сроки согласовываются обеими сторонами; 4. Существуют проекты автоматизации, реализованные по каскадному принципу.
Задачи в проекте живут той же жизнью, что и остальные — есть сроки, есть согласования и т. д.; 5. Есть техподдержка в дежурном виде - программисты по очереди сидят на ней 1 неделю.
Система мотивации : 1. У программистов зарплата в зависимости от их квалификации; 2. Происходит демотивация за невыполненные вовремя задачи; 3. Есть бонусы за завершение проектов.
Автоматизация из всего этого добра - самое обычное.
Для постановки задач используется общекорпоративная система, например 1С:Документооборот. Содержит инструкции и памятки, в которых живут задачи.
Имеется некоторая автоматизация управления каскадными проектами.
Идет автоматический расчет демотивации при срыве сроков.
Вроде как - живи и радуйся, работай - не бей того, кто упал.
Соблюдать сроки несложно, если вы участвуете в их установлении.
Работа не особо сложная, ничего сверхъестественного.
Я, как руководитель, ничем не выделяюсь среди других — в других службах управление задачами, сроками и проектами ведется по тем же принципам.
Но нас не давал покоя один вопрос - как заработать больше денег? В нынешней системе было два рычага – добиться повышение заработной платы или бонусы проекта .
Компании обычно не любят повышать зарплату программисту 1С, потому что… плохо понимают Почему этому парню нужно платить больше денег? .
Для повышения квалификации или какой-то категоризации, например оценок? Не особо понятно, зачем за это платить больше, если квалификация не влияет на результаты.
А если у программистов разные результаты, связано ли это с формальной квалификацией? Насколько вам следует увеличить свою зарплату, если вы все равно пойдете по этому пути? Текущие зарплаты были примерно равны среднерыночным.
Программистам удалось повысить зарплату в пару раз.
Например, сертификацию прошли нанятые французские специалисты.
Другой получил прибавку, потому что был хорош на рынке и стоил дороже (по субъективной оценке).
Но невозможно часто повторять этот путь, не услышав «ты там совсем офигел, что лиЭ» Также невозможно усердно работать над увеличением бонусов проекта, т.к.
тема достаточно скользкая.
В любом случае, бонус проекта — это дополнительная оплата за уже оплаченную работу .
Конечно, можно это как-то перефразировать, например, доплата за досрочное выполнение, или за активное участие во внедрении, или за быстрое доведение автоматизации до требований заказчика.
Но рано или поздно руководитель начинает задаваться вопросом – если человек всегда выполняет проекты раньше срока, почему я должен за это доплачивать? Может срок неправильно посчитали? Немного подумав, мы с программистами решили создать для себя систему мотивации и изменить свою работу так, чтобы она явно приносила больше пользы компании.
Предполагая, что мы получим больше денег за большую выгоду.
Правильнее всего поговорить с самой компанией о преимуществах для компании, что я и сделал.
Я разговаривал с менеджерами, директором, владельцем.
Высказанные мнения были разными, но если сгруппировать их и ранжировать, то основная идея заключалась в следующем: мы хотим того же, что вы уже делаете, только быстрее .
Или другими словами: мы хотим получить больше за то же время.
Очевидно, речь идет о скорость программирования и внедрения .
Следует отметить, что на тот момент мы ничего не знали о Scrum как о методе, ускоряющем работу программистов.
Для меня, как руководителя, очень важным был следующий момент: Я хотел, чтобы программисты сами заботились о своих результатах .
Я не хотел их давить, стоять над ними, контролировать процесс и сроки.
Мне нужна была автономная система, которая могла бы обойтись без меня и вообще без менеджера.
Ближайшей платежной системой, подходящей для наших целей, оказалась сдельная оплата за выполненную работу .
Это звучало многообещающе и легко доказывалось: вот человек, вот проделанная работа, вот доход. Мотивировать не нужно – если человек не хочет работать, он не будет зарабатывать, и это станет очевидным.
С таким человеком можно расстаться без угрызений совести.
Возник ключевой вопрос - как оценивать работу и сколько за нее платить ? Во франшизах этот вопрос решается проще – есть оценка трудоемкости в часах, за которые платит клиент. Программист по сути получает процент от почасовой ставки.
У нас не было ни клиентов, ни финансовых связей, но работу нужно было как-то оценивать.
Идея пришла быстро, как и ее реализация и доказательная база.
Я решил оценить задачи в часах лучшего программиста .
Если лучший программист решает задачу за 1 час, то она стоит 1 час.
Другой программист, решивший эту задачу за 4 часа, получит за это 1 оплаченный час.
Чтобы оценивать задачи «по мнению лучшего программиста», нужно понимать, кто он такой.
Мы решили так: лучший программист обладает всеми необходимыми знаниями о том, как решить задачу .
Знает методологическую область, знает необходимые механизмы платформы, знает метаданные и «где все находится».
В общем, садится и делает, не теряя времени.
Основная цель такой оценки – стремиться минимизировать потери времени, сделав его нерентабельным.
В работе программиста очень много потерь, причем по объему потери часто превышают половину рабочего времени.
Лично я поставил «лучшую» оценку, и это, пожалуй, узкое место всей системы.
Сразу стало понятно, что необходимо сделать систему оценивания если не прозрачной, то проверяемой ретроспективно.
Поэтому я решил сделать классификатор оценки должностей — простой справочник, содержащий стандартные компоненты для решения задачи и их оценки.
Он заполнялся постепенно, мы называли смету на работу.
"прецедент" — в классификатор включены задания, проверенные на практике, с измеренным временем выполнения.
Классификатор содержал, например, следующие позиции:
- Разработка простого отчета типа «Продажи» для одного кассы по системе контроля доступа в пользовательском режиме.
Оценка – 15 минут;
- Создание регистра накопления с простой записью движений, полностью определяемых контекстом документа.
Оценка – 15 минут;
- Разработка роли, без RLS, с небольшим списком (до 10) разрешенных объектов.
Оценка: 10 минут.
В случае возникновения ошибки в рабочей базе данных на основании изменений, созданных в данном задании, ошибки исправлялись исполнителем за свой счет. Каждая задача, которую выполняли программисты, получала такой рейтинг перед началом выполнения.
Понятно, что некоторые задачи содержали несколько пунктов классификатора — например, реестр плюс несколько реквизитов, плюс отчет, плюс автозадание.
Время в данном случае суммировалось.
Теперь предстояло определиться сколько платить за час работы лучшего программиста .
Мы решили этот вопрос в лоб.
Среднестатистический хороший программист тогда получал на рынке 60 тысяч рублей.
Мы решили, что лучший программист должен получить 100 рублей.
Понятно, что эту цифру впоследствии можно изменить в любую сторону.
Простые расчеты и округления дали нам почасовую ставку лучшего программиста: 600 рублей в час .
Цифра выглядит неплохо, поскольку она составляет половину почасовой ставки местных французских рабочих и ниже, чем стоимость фрилансеров, которые тогда просили 700-900 рублей в час.
Но главное, что в нашу почасовую ставку включено только прямая работа .
Не было никакого мышления, моделирования, анализа решений и т. д. Однако понимая, что разговор об этой ставке с руководством все равно состоится, мы решили убедиться в своей правоте.
Для этого мы пообщались со знакомыми и незнакомыми французами и фрилансерами.
Мы дали этим ребятам на оценку несколько задач и задали простой вопрос – сколько денег вы возьмете за такую работу? Результат был предсказуем — ребята просили за работу в 2-3+ раза больше, чем мы (с учетом налогов на зарплату).
На этом мы успокоились – задница накрыта.
Теперь необходимо было сбалансировать систему исходя из суммы ежемесячного начисления, чтобы избежать ошибок в обе стороны.
Первая сторона — программисты.
Мало ли, вдруг окажется, что программист заработал 10 тысяч рублей.
- Ему нечем будет кормить семью.
Решение простое, я видел его, когда работал во Франции - установить минимальный ежемесячный платеж , меньше которого программист не получит. Недолго думая, мы решили, что это будет текущая зарплата.
Вторая сторона – компания.
Просто минимальный платеж невыгоден, потому что.
с его помощью можно обмануть систему.
Например, выполнить за месяц 20 задач, пока состояние «почти готово», получить зарплату, а в следующем месяце совершить прорыв, выполнить 20 незавершенных задач и еще 30 новых и получить сделку.
Кстати, по-французски именно так было, и все этим пользовались.
Выход из ситуации тоже прост - «помни минус» .
Отработал за 40 тысяч рублей, получил зарплату 60 тысяч рублей.
— ок, запомни «минус» 20 тысяч рублей.
В следующем месяце ты будешь должен.
В следующем месяце вы выполните работу на 80 рублей.
- получишь 60 тр, и не будешь должен.
При этом на всякий случай установили потолок выплат в 100 тысяч рублей.
Было решено, что работа, выполненная сверх этой суммы, в следующем месяце будет засчитана в плюс.
Теперь нам нужно было придумать, что делать с проектами.
Проект, если упростить, — это набор задач, связанных друг с другом каким-то смыслом или целью.
Но компания заинтересована не только в ускоренном выполнении каждой из этих задач, но и в максимально быстром выполнении всего перечня задач проекта и получении результатов.
Решение тоже простое и опять же подсмотренное другими - накапливать часть сдельной зарплаты и выплачивать ее по окончании проекта .
Мы решили, что это будет 20%.
Пока проект продолжается, программист получает 480 рублей в час, а остальные 120 рублей получает за каждый час по завершении проекта.
Ну вот вроде всё просчитано и продумано, надо приступать к опытной эксплуатации.
Первое, что нам было нужно, это изменить бизнес-процесс работа программистов: 1. Задачи теперь должны ставиться не лично исполнителю, а мне, руководителю; 2. Теперь мне приходится оценивать каждую задачу в часах; 3. После принятия и оценки задача становится доступной к исполнению.
Ок, бизнес-процесс изменился, нужно автоматизировать .
Чтобы было больше творческой свободы, мы перестали пользоваться инструкциями и памятками (их использовали все), а придумали и сделали для себя два новых объекта за 1-2 дня: 1. Заявление в ИТ-отдел со всеми необходимыми полями для нашей оценки; 2. Упрощенная система учета проектов и задач в них, с той же системой оценок.
И тут же сделали отчет, в котором показывалась выработка в часах и заработанные деньги, чтобы программисты могли видеть свои результаты каждый день.
Мы приступили к работе и сразу столкнулись с трудностью - программисты начали ныть, что оценки за задачи слишком низкие .
«Надо подумать», «Никогда не сталкивался с переработкой, надо разобраться», «Однажды делал автозадание, есть инструкция почитатьЭ» и т. д. Я послушал их и стал задумываться о философской глубине вопроса: Должна ли компания платить своим сотрудникам за получение знаний? Кажется, ответ очевиден – так и должно быть.
Но действительно ли все так очевидно? Что происходит. Одному программисту дано задание заполнить субсчет Склад в проводке на счет 003 (в стандартном УПП он почему-то не заполняется).
А вот про обработку он не знает ни на стороне поставщика, ни на стороне переработчика.
Типа, сядь и разберись, что это такое, они всегда так делали.
В традиционной системе заработной платы работодатель будет платить вам за то время, пока вы сидите и ковыряетесь.
Но это не так просто.
Из четырёх человек (три программиста + я, менеджер) двое хорошо разбираются в обработке, а задача досталась тому, кто не разбирается.
Когда мы придумали переработку отходов? Программист на моей прежней работе, я на нынешней, потому что.
Раньше на практике не было дилеров/переработчиков.
Оказывается, что действующая компания уже заплатила за получение этой компетенции .
И платить второй раз, хотя бы в той же сумме, похоже, неправильно.
Что вам следует делать сейчас? Правильно, передать компетенцию тому, кто получил задание.
Возник еще один вопрос – зачем это нужно обладателю компетенции? У него тоже сдельная зарплата, и вместо того, чтобы передавать знания, он предпочел бы больше работать.
Я начал размышлять над еще более философским вопросом: Должна ли компания платить за передачу компетенции между сотрудниками? Традиционно передача знаний считается чем-то само собой разумеющимся.
Но все мы знаем, что качество такой передачи оставляет желать лучшего.
Исключение составляют программы адаптации и наставничества, но они не очень распространены.
Итак, решение стало для нас очевидным: 1. За передачу знаний и помощь друг другу приходится платить; 2. За приобретение новых компетенций нужно платить.
Второй момент — про знания, которых нет ни у кого в команде.
Например, у нас была задача постоянно перетаскивать данные из внешней системы в 1С с помощью прямых запросов к MS SQL. Задача не сложная, но раньше этого никто не делал.
Я сделал так — оформил от своего имени заявку, суть которой заключалась в работе с внешними источниками данных на уровне, достаточном для решения конкретной задачи.
Оценка задачи — 1 час (но сидеть там можно целый день).
В результате решения задачи мы получаем специалиста, умеющего решать проблемы с внешними источниками данных, и мы не будем платить больше за эту компетенцию .
Только для передачи другим программистам.
Мы решили платить за передачу компетенций и взаимопомощь, и для этого придумали соответствующий термин — затраты на анализ и проектирование.
Чтобы не тратить время на лишнюю бюрократию, мы нарисовали в Word таблицу с данными: 1. Проблема, которая обсуждалась/проектировалась/о которой сообщалось; 2. Время начала и окончания обсуждения с точностью до минут; 3. Участники.
В систему учета был добавлен отдельный документ, в который раз в неделю заносились результаты таких обсуждений.
Обычно обсуждения длились 5 минут. , иногда достигая 15 минут. В неделю это было 3-5 часов для всех .
Что важно: Всем участникам было оплачено время обсуждений , т. е.
было выгодно и приобретать, и передавать знания.
Помогать коллегам было выгодно, потому что.
человеческие законы никуда не делись - если ты помогаешь, то и тебе помогут, а если ты держишь знания при себе, то будь готов, столкнувшись с незнакомой задачей с оценкой 1 час, сидеть с ним 2 дня.
Конечно, были исключения, когда я сам вычеркивал из списка участников того, кто сидел и считал ворон.
Да, все подобные встречи нужно было проводить в моем присутствии, потому что… я отвечал за качество системы перед внешним миром.
Все обсуждаемые вопросы отражались в системе, и при необходимости можно было вернуться и посмотреть, законно ли были потрачены деньги.
Остался еще один «грязный» вопрос — техническая поддержка.
.
Противно - потому что мне не нравится наличие техподдержки, она притупляет умы пользователей, отнимает драгоценное время специалистов, не принося особой пользы компании.
Формально наша техподдержка тогда — это выделенный дежурный сотрудник, который должен помогать людям в течение недели.
Сколько платить программисту, который сидит в техподдержке? Сначала идея была не платить вообще, а уменьшить базу расчета зарплаты при расчете выплаты.
Например, если у программиста зарплата 60 рублей, он тратил 2 недели в месяц на техподдержку, то при расчете учитывайте половину зарплаты — 30 рублей, а в остальное время учитывайте транзакцию.
Но сразу понятно, что это какая-то ерунда - компания не очень большая, и объективно техподдержка не занимает целый день.
Соответственно, у программиста есть время на решение задач и он может использовать схему «рывок».
Есть гораздо более простой выход – посчитать, причём сколько времени в день лучший сотрудник тратит на техническую поддержку? , и заплатите программисту за эти дни в такой же сумме.
Потому что меня считали лучшим в этой банде, вот я и мерил это на себе.
Я просто несколько дней сидел на опоре с секундомером и целью - не сопли размазать, а побыстрее помочь людям.
Правильно перенаправляйте свои вопросы в задачи.
Предоставляйте ссылки на инструкции, если человек их не читал и ему требуется онлайн-обучение чему-то, что знают все вокруг.
Ну и т.д. По результатам измерений выяснилось, что техническая поддержка занимает в среднем 2 часа в день .
Отлично, вот номер.
Мы договорились, что дежурному будут платить в таком размере – 2 часа в день, или 10 часов в неделю.
Понятно, что оказывать только техническую поддержку невыгодно — это стоит примерно 25 тысяч рублей в месяц.
Чтобы дежурному не было скучно, мы дали ему листок бумаги и заставили записывать всех, кто к нему обращался, - только фамилию.
В системе учета был создан документ, в который дежурный в конце дня вносил все «обращения».
Почему – смотрите в конце статьи, в рубрике «Приятный бонус».
На самом деле, На этом картина была завершена, и мы продолжили тестовую эксплуатацию системы.
.
Среди программистов наблюдалось беспрецедентный энтузиазм .
Вцепились в задания, дым стоял столбом, пока они их выполняли.
Программист, который раньше любил обсуждать «какая сложная задача, столько подводных камней», начал работать молча; он мог часами обсасывать эти подводные камни, увеличивая свою ценность (непонятно, правда, зачем зарплату).
Программист, который раньше любил сидеть часами и «думать об оптимальном решении», сразу же начал придумывать оптимальные решения, потому что теперь оптимальное решение генерировалось командным мозговым штурмом за 5 минут. Программист-интроверт, который мог два дня сидеть над уже решенной задачей, потому что стеснялся разговаривать с заказчиком, стал общаться с заказчиками в разы чаще.
Стало появляться гораздо больше толковых, качественных задач от пользователей, потому что в их разработке стали помогать программисты.
Программист-новичок, который раньше стеснялся задать вопрос коллегам, перестал сидеть часами и тупить, потому что «неудобно отвлекаться, они будут раздражаться» (надо сказать, раньше действительно раздражались).
Программисты стали азартный и жадный , в хорошем смысле этого слова.
Я, как руководитель, добился своей цели — система начала работать, хоть и не совсем без меня, но с минимальным моим участием.
Мое участие стало прозрачным и понятным, это всего лишь моменты бизнес-процесса: 1. Прием и оценка заданий, я делал это раз в день, минут 15; 2. Участие в аналитических и проектных совещаниях (это ~3 раза в день по 5 минут).
Общий управлять тремя программистами - 30-60 минут в день .
Не надо никого пинать, следить за исполнением и сроками, мотивировать, проверять качество - все было сделано само собой .
Я мог просмотреть результаты в любое время через систему.
Нельзя сказать, что мы добились полного самоуправления, но мы были к нему максимально близки.
Мы провели тестовую эксплуатацию в течение 3 месяцев.
В течение этого времени Наша производительность в часах увеличилась вдвое , а зарплата, рассчитанная с учетом новой мотивации, составляет 30%.
Разница очевидна – теперь зарплату пришлось отрабатывать .
По словам самих программистов, так интенсивно работать им еще никогда и нигде не приходилось.
Именно интенсивно, а не много и надолго – я всегда был против более чем 8-часового рабочего дня.
Но здесь это не важно Что говорили об интенсивности работы, и Как они это сказали.
Они говорили горжусь собой .
Не только потому, что новая система сделала их работу более эффективной, но и потому, что они сами были авторами этой системы.
Они сами сделали себя эффективнее, сами сделали свою работу прозрачной и измеримой, сами стали по-другому смотреть на компанию, ее руководителей и сотрудников.
Я объясняю успех так: 1. Если посмотреть сквозь призму тезисов о разработке систем мотивации, то станет ясно, что мы хорошо определили продукт. Продукт – это решенная проблема.
За этот товар платят чистые деньги.
Все остальное за свой счет (мысли, интернет, общение в мессенджерах, перекуры, нытье, депрессия и т. д.).
2. Если посмотреть на процесс развития через самоуправление, то можно увидеть, что система создавалась при непосредственном участии людей, которые в ней работают. 3. Сделали систему максимально измеримой - в соответствии с требованиями контроллинга.
Измерение выполненной работы в одиночку заставило людей двигаться быстрее и перестать заниматься ерундой.
После тестовой эксплуатации я прошел несколько итераций защиты новой системы: директор по персоналу, финансовый директор, директор, владелец, внешний консультант по персоналу (Москва, видимо, очень известная).
Система всем понравилась.
Мне как руководителю его развития было особенно интересно мнение HR-консультанта, потому что.
он хорошо знает мировую практику и выполнил сотни проектов по разработке систем мотивации.
Его оценка моей системы оказалась очень высокой, особенно ему понравились контуры защиты («помни о минусе» и максимальный лимит выплат).
Впоследствии принципы этой системы стали основой для других систем мотивации предприятия.
Приятный бонус Итак, у нас была смета в рублях на все работы, включая анализ, проектирование и техническую поддержку.
Грех было не воспользоваться такой возможностью и не сделать расчет стоимости автоматизации по заказчикам и проектам .
Ведь мы теперь точно знали, кто сколько денег компании съедает за счет автоматизации, и если посмотреть на эти данные с точки зрения полезности , то мы получим просто шикарную картинку.
Например, мы узнали, что на техническую поддержку заместителя главного бухгалтера, который по должностной инструкции должен знать СПП лучше, чем кто-либо другой в бухгалтерии, уходит больше денег, чем этот человек получает зарплаты.
Мы также узнали, что люди, которые всегда ноют «на нас плевать», тратят 40% всех денег на автоматизацию.
Интересно было смотреть на растущий из месяца в месяц бюджет проектов, у которых не было владельца (это когда директор, например, говорит - автоматизируйте этот сервис, но автоматизация не остановила сервис, а вынуждены сами пишите задачи, чтобы они ходили по кругу) .
Апофеозом стал доклад на стратегической сессии с неутешительным результатом - Компания тратит больше половины своих денег на бессмысленную автоматизацию .
Бессмысленность — вполне осмысленная характеристика.
Например, функционал разработан, замечаний нет, но он не используется («но как-то все руки не доходят»).
Или функционал, который призван помочь улучшить процесс управления за счет изменения значения показателя - но значение показателя либо остается прежним, либо ухудшается (и в начале проекта было сказано - это вам, ребята, не поможет, у тебя другая проблема).
Каков результат? Нас стали слушать чаще и внимательнее, особенно ДО начала работы.
Потому что теперь мы смогли прогнозировать результаты проекта, опираясь не только на системное мышление, но и на статистику в цифрах.
Объем бессмысленной работы в первые месяцы снизился до 30% – несмотря на то, что структура «бессмысленности» улучшилась.
Но это уже другая история.
P.S.
Есть люди, которые повторили мой опыт — то есть тоже выстроили систему управления и мотивации, основанную на определенных нормах рабочего времени.Говорят, с ними все в порядке.
Хотя, кто согласится.
Не знаю, как вы, а я тупой.
Опыт, описанный в статье, произошел года 4 назад, если я правильно помню.
Потом я узнал о Scrum — точнее, купил на распродаже книгу — и увлекся, и забросил все старое.
Потому что он глупый.
Всегда хочется не думать, а брать то, что готово.
Scrum, PMBOOK, CORE PM, Kanban, TOC или что-то еще, «внедрить» или, что более модно, «внедрить».
А некоторые мудаки, вроде разработчиков scrum-гайда, еще и подогревают ситуацию, говоря что-то вроде «если вы не делаете по мануалу, то у вас нет Scrum».
Хотя они сами в книге написали, что думать нужно своей головой.
Опыт, описанный в статье, бесценен.
Для меня, конечно.
Хотя бы потому, что он показал важность оценки задач в каких-то более-менее стабильных подразделениях.
Потом, уже в Скраме, это превратилось в баллы.
Опыт также показал, что правильная система мотивации делает с людьми.
Он также показал, что при правильной системе управления и мотивации людям не нужен лидер.
И он показал гораздо больше.
Как вы? Здоровый? Или, не заморачивайтесь, это про 1Сников.
Теги: #системы мотивации #программирование #Анализ и проектирование систем #Управление проектами #Управление персоналом #Карьера в IT-индустрии
-
Вверх По Песочнице!
19 Oct, 24 -
Оптимизация Сайта. Диагнозы И Курсы Лечения
19 Oct, 24 -
Пользователи Twitter В Русской Википедии
19 Oct, 24 -
Data Fest 2020 – Завтра Полностью Онлайн
19 Oct, 24
