Хабрахабр

В погоне за лучшим

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Другой программист, решающий эту задачу за 4 часа, получит за нее 1 оплаченный час. Если лучший программист решит задачу за 1 час, то стоит она 1 час.

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

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

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

Классификатор содержал, например, такие пункты:

  • Разработка простого отчета, типа «Продажи», по одному регистру, на СКД в пользовательском режиме. Оценка — 15 минут;
  • Создание регистра накоплления, с простой записью движений, полностью определяемых контектстом документа. Оценка — 15 минут;
  • Разработка роли, без RLS, с небольшим перечнем (до 10) разрешенных объектов. Оценка — 10 минут.

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

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

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

Несложные подсчеты и округление дали нам часовую ставку лучшего программиста: 600 рублей в час.

Цифра выгядит неплохо, потому что она вдвое меньше часовой ставки местных франчей, и ниже стоимости фрилансеров, которые тогда просили 700-900 рублей за час.

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

Для этого пообщались со знакомыми и незнакомыми франчами и фрилансерами. Однако, понимая, что разговор про эту ставку с руководством все равно состоится, мы решили убедиться в своей правоте. Результат был прогнозируемый — ребята просили за работу в 2-3+ раз больше, чем мы (с учетом налогов на з/п). Мы дали этим ребятам несколько задач для оценки, и задали простой вопрос — сколько возьмете денег за такую работу? На этом успокоились — задница прикрыта.

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

Просто неснижаемая выплата невыгодна, т.к. Вторая сторона — компания. Например, сделать 20 задач за месяц до состояния «почти готово», получить оклад, а в следующем месяце совершить рывок, закрыть 20 недоделанных задач и еще 30 новых, и получить сделку. с ее помощью можно обманывать систему. Кстати, во франче было именно так, и все пользовались.

Сделал работ на 40 т.р., получил оклад 60 т.р. Выход из ситуации тоже простой — «запоминать минус». В следующем месяце будешь должен. — ок, запоминаем «минус» 20 т.р. — получишь 60 т.р., и должен не будешь. Сделаешь в следующем месяце работ на 80 т.р.

Договорилиь, что выполненные сверх этой суммы работы зачтутся в следующем месяце «плюсом». Заодно, на всякий случай, установили потолок выплаты — 100 т.р.

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

Мы решили, что у нас это будет 20 %. Выход тоже простой, и опять же подсмотренный у других — часть сдельной зарплаты накапливать и выдавать по окончании проекта. Пока проект идет, программист получает за час 480 рублей, а оставшиеся 120 рублей с каждого часа получает по окончании проекта.

Ну, вроде все посчитали и продумали, надо начинать тестовую эксплуатацию.

Задачи теперь должны ставиться не персонально исполнителю, а мне, руководителю;
2. Первым делом понадобилось изменить бизнес-процесс работы программистов:
1. После принятия и оценки задача становится доступна для выполнения. Я теперь должен каждую задачу оценивать в часах;
3.

Чтобы иметь больше свободы творчества, мы перестали использовать поручения и служебные записки (ими пользовались все), а придумали и за 1-2 дня изготовили себе два новых объекта:
1. Ок, бизнес-процесс изменили, надо автоматизировать. Заявка в ИТ-отдел, со всеми необходимыми полями для нашей оценки;

Упрощенную систему учета проектов и задач в них, с той же системой оценки. 2.

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

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

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

Но так ли уж все очевидно? Вроде ответ очевиден — должна. Что получается.

А он в переработку не знает, ни на стороне давальца, ни на стороне переработчика. Вот одному программисту поставлена задача — сделать заполнение субконто Склад в проводке по счету 003 (в типовой УПП, почему-то, не заполняется).

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

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

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

Но все мы знаем, что качество такой передачи оставляет желать лучшего. Я стал размышлять над еще более философским вопросом: должна ли компания платить за передачу компетенция между сотрудниками? Традиционно считается, что передача знаний — само собой разумеющееся. Исключение — программы адаптации и наставничества, но они встречаются не очень часто.

За передачу знаний и помощь друг другу надо платить;
2. Итак, решение стало для нас очевидным:
1. За получение новых компетенций надо платить.

Например, у нас появилась задача постоянно затаскивать в 1С данные из внешней системы прямыми запросами к MS SQL. Второй пункт — про знания, которыми не обладает никто из команды. Я поступил так — оформлял от своего имени заявку, суть которой — раскурить работу с внешними источниками данных на уровне, достаточном для решения конкретной задачи. Задача несложная, но никто такого раньше не делал. Оценка задачи — 1 час (а просидеть можешь хоть целый день).

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

Чтобы не тратить время на большую бюрократию, нарисовали в ворде таблицу, содержащую данные:
1. Передачу компетенций и взаимную помощь мы решили оплачивать, и для этого придумали соответствующий термин — затраты на анализ и проектирование. Время начала и окончания обсуждения, с точностью до минут;
3. Вопрос, который обсуждался/проектировался/передавался;
2. Участники.

Обычно обсуждения укладывались в 5 минут, изредка достигая 15 минут. В учетной системе добавили отдельный документ, в который раз в неделю вбивались результаты таких обсуждений. За неделю получалось на всех 3-5 часов.

было выгодно как приобретать, так и передавать знания. Что важно: время обсуждений оплачивалось всем его участникам, т.е. людские законы никуда не делись — если помогаешь ты, то помогут и тебе, а если ты держишь знания при себе, то будь готов, столкнувшись с незнакомой задачей с оценкой 1 час, просидеть с ней 2 дня. Было выгодно оказывать помощь коллегам, т.к. Разумеется, бывали исключения, когда я сам вычеркивал из списка участников того, кто сидел и считал ворон.

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

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

Сколько платить программисту, который сидит на тех.поддержке? Формально тех.поддержка у нас тогда — это выделенный дежурный сотрудник, который в течение недели должен помогать людям.

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

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

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

Отлично, вот и цифра. По результатам замеров оказалось, что тех.поддержка занимает в среднем 2 часа в день. Договорились, что в таком размере она и будет оплачиваться дежурному — 2 часа в день, или 10 часов в неделю.

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

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

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

Хватались за задачи, дым стоял столбом при выполнении. Среди программистов наблюдался невиданный доселе энтузиазм.

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

Сразу стал выдавать оптимальные решения программист, который раньше любил часами сидеть и «думать над оптимальным решением», потому что теперь оптимальное решение выдавалось командным мозговым штурмом за 5 минут.

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

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

Перестал часами сидеть и тупить программист-новичок, который раньше стеснялся задать коллегам вопрос, потому что «неудобно отвлекать, раздражаться же будут» (надо сказать, раньше и правда раздражались).

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

Прием и оценка задач, я делал это раз в день, минут 15;
2. Мое участие стало прозрачным и понятным, это просто точки в бизнес-процессе:
1. Участие в совещаниях по анализу и проектированию (это ~3 раза в день по 5 минут).

Никого не нужно пинать, следить за исполнением и сроками, мотивировать, проверять качество — все делалось само собой. Итого, на управление тремя программистами — 30-60 минут в день. Нельзя сказать, что получилось полное самоуправление, но мы были к нему максимально близко. За результатами я мог смотреть в любой момент через систему.

За это время выработка в часах у нас выросла вдвое, а рассчитанная по новой мотивации зарплата — на 30 %. Тестовую эксплуатацию мы проводили в течение 3 месяцев. По словам самих программистов, им нигде до этого не приходилось так интенсивно работать. Разница понятна — теперь оклад приходилось отрабатывать. Именно интенсивно, а не много или долго — я всегда был против более чем 8-часового рабочего дня.

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

Если взглянуть через призму тезисов о разработке систем мотивации, то становится понятно, что мы неплохо определили продукт. Успех я объясняю так:
1. За этот продукт платятся понятные деньги. Продукт — это решенная задача. Если взглянуть на процесс разработки через self-management, то видно, что система создавалась при непосредственном участии людей, которым в ней работать.
3. Все остальное — за свой счет (размышления, интернет, общение в мессенджерах, перекуры, нытьё, депрессии и т.д.).
2. Одно только измерение выполненных работ заставило людей шевелиться быстрее и не заниматься ерундой. Мы сделали систему измеримой, насколько смогли — в соответствии с требованиями контроллинга.

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

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

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

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

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

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

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

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

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

P.S.

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть