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

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

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

Бизнес-процесс — самый обычный:

1. Программистам ставятся задачи, от любых отделов;
2. Задачи проходят согласование, если требуется. Список согласующих — разный для разных задач;
3. У задач есть срок, есть возможность его переноса (не более двух раз). До начала выполнения срок согласовывается обеими сторонами;
4. Есть проекты автоматизации, выполняемые по каскадному принципу. Задачи в проекте живут той же жизнью, что и остальные — есть сроки, есть согласования и т.д.;
5. Есть тех.поддержка в форме дежурства — программисты по очереди сидят на ней по 1 неделе.

Система мотивации:
1. У программистов есть оклад, в зависимости от квалификации;
2. Есть демотивация за невыполненные в срок задачи;
3. Есть премии за выполнение проектов.

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

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

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

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

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

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

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

Но рано или поздно руководитель начинает задавать вопрос — если человек все время делает проекты раньше срока, почему я за это должен доплачивать? Может, срок неправильно рассчитан?

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

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

Очевидно, речь о скорости программирования и внедрения. Надо отметить, мы тогда ничего не знали о скраме, как методе, ускоряющем работу программистов.

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

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

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

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

Если лучший программист решит задачу за 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 час (а просидеть можешь хоть целый день).

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

Передачу компетенций и взаимную помощь мы решили оплачивать, и для этого придумали соответствующий термин — затраты на анализ и проектирование. Чтобы не тратить время на большую бюрократию, нарисовали в ворде таблицу, содержащую данные:
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. Если взглянуть на процесс разработки через self-management, то видно, что система создавалась при непосредственном участии людей, которым в ней работать.
3. Мы сделали систему измеримой, насколько смогли — в соответствии с требованиями контроллинга. Одно только измерение выполненных работ заставило людей шевелиться быстрее и не заниматься ерундой.

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

Мне, как руководителю ее разработки, особенно интересно было мнение HR-консультанта, т.к. он хорошо знает мировую практику и выполнил сотни проектов по разработке систем мотивации. Его оценка моей системы оказалась очень высокой, особенно ему понравились контуры защиты («запомнить минус» и ограничение максимальной выплаты).

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

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

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

Еще узнали, что люди, которые вечно ноют «нами не занимаются», потребляют 40 % всех денег на автоматизацию.

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

Апофеозом стал доклад на стратегической сессии с неутешительным итогом — больше половины денег компания тратит на бессмысленную автоматизацию. Бессмысленность — вполне осмысленная характеристика. Например, функционал разработан, замечаний нет, но не используется («да как-то все руки не доходят»). Или функционал, который призван помочь улучшить процесс управления, через изменение значения показателя — а значение показателя или стоит на месте, или ухудшается (а в начале проекта было говОрено — вам это не поможет, ребята, у вас в другом проблема).

Что в итоге? Нас стали чаще и внимательнее слушать, особенно ДО начала работ. Потому что мы теперь умели прогнозировать результаты проектов, опираясь не только на системное мышление, но и на статистику в цифрах. Объем бессмысленных работ за первые месяцы уменьшился до 30 % — притом, что улучшилась структура «бессмысленности». Но это уже другая история.

P.S.

Есть люди, которые повторили мой опыт — ну то есть тоже построили систему управления и мотивации на основе неких нормочасов. Говорят, у них все хорошо. Хотя, кто ж признается…

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

Всегда же хочется не думать, а взять готовое. Скрам, PMBOOK, CORE PM, Канбан, ТОС или еще что-то, «внедрить» или, говоря моднее, «имплементировать». А некоторые засранцы, вроде разработчиков scrum guide, еще и подогревают ситуацию, говоря что-то вроде «если делаете не по методичке, то у вас не скрам». Хотя в книжке сами писали, что надо своей головой думать.

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

Вам как? Полезно? Или бэээ, не тру, это ж про 1Сников.