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

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

Итак, на входе — небольшая команда программистов 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Сников.

Комментарии (32)


  1. n0wheremany
    25.12.2018 10:01

    Успех данного проекта лишь в том, что минимальная оплата работника — текущий оклад. Тут любой будет качественно и быстро работать, что бы увеличить ЗП, но при этом «ЕслиЧё» остаться при своём.

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

    Есть ли у Вас аналитики, как вы проводите обследование процессов, перед реализацией.

    Не понятно как вы решаете вопросы — типа сделал, нужно проверить бухгалтеру, и на этом ожидание… А проект висит.

    Что вы будите делать, если руководство скажет — давайте уменьшим минимальную оплату, что бы Не скакал ФОТ.

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


    1. nmivan Автор
      25.12.2018 12:44

      Программистов четыре, включая меня.
      Задач 100-150 в месяц.
      Аналитики — мы сами.
      Проекты, как сущность, мы тогда уже выкинули — был только поток.
      Ожидание проверки было, до месяца — дальше сам закрывал, без проверки. Но, в целом, проблем не было, потому что не принимал от человека новую задачу, если он старую не проверил.
      Если руководство скажет уменьшить ставку, то придется искать новых программистов.
      А задач становилось все больше, т.к. мы делали их все быстрее.

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


  1. topa
    25.12.2018 10:12

    Спасибо за статью! Интересный опыт. Благодаря подобным статьям у программистов может и отношение к 1С поменяться :)

    Странными кажутся оценки задач, приведенные в статье — по 10-15 минут. Здесь речь больше про конфигурирование/администрирование, или всё-таки про разработку? Если про разработку, то как в такое в такое время влазит тестирование?


    1. dzmitry_li
      25.12.2018 10:36

      И меня тоже смутило:

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

      Вот не учтено время проверки взаимодействия всего этого (тестирование). По раздельности может всё и работает, а вместе?


    1. Mofinak
      25.12.2018 12:38

      Я сомневаюсь, что отношение к ним может поменяться, опоздали на несколько лет)


    1. nmivan Автор
      25.12.2018 12:45

      10-15 минут вполне достаточно, чтобы сделать, например, отчет по одному регистру накопления, без понтов с оформлением. Ну и тестировать там, вроде, особо нечего.

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


  1. Asmody
    25.12.2018 11:23

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


    1. nmivan Автор
      25.12.2018 12:47
      +1

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


  1. SbWereWolf
    25.12.2018 11:50

    Статья конечно интересная, спасибо что поделились опытом, но оценка задачи в 15 минут, на аналитику 5 минут… про тестирование ни чего, про возврат на доработку не чего, про заказчик пердумал ни чего, про бодания на приёмо сдаточных испытаниях ни чего, учесть ваш опыт можно, но в чистом виде мне кажется не применимо

    И если была такая система мотивации которая всех устраивал, то зачем её поменяли на скрам и другие не понятные слова? или вы поменяли место работы и там эта система не взлетела?

    И все приятные бонусы от этой системы это следствия учёта, а учёт метрик это по моему первое дело любого руководителя, научиться ходить па приборам, а не по субъективным оценкам


    1. nmivan Автор
      25.12.2018 12:48

      о оценка задачи в 15 минут, на аналитику 5 минут… про тестирование ни чего, про возврат на доработку не чего, про заказчик пердумал ни чего, про бодания на приёмо сдаточных испытаниях ни чего


      во-во, так программисты и говорили поначалу. А потом поняли, что и 15 минут — много, если сопли не жевать.


      1. SbWereWolf
        25.12.2018 15:54

        Значит специфика задач такая что для творчества в ней места нет :) и всё что программисты делают это применяют наработанные навыки и шаблоны. Я от такой работы сбежал при первой возможности.


        1. kaichou
          25.12.2018 18:34

          Задачи разные бывают же. И на 15 минут, и на 15 дней.
          Здесь даже самоменеджмент можно проявить: с утра для разогрева пощёлкал пару мелочевок, а потом взял рыбу покрупнее.


  1. EarlAthos
    25.12.2018 12:08

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


    1. SbWereWolf
      25.12.2018 12:37

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


    1. kinall
      25.12.2018 12:45

      Я бы даже конкретизировал: как быть, если в результате ввода описанной «полусдельной» оплаты окажется, что на отдел из, например, трёх программистов, идёт поток задач такой, что загружены будут не все три, а 2,5? То есть одного не уволишь – оставшиеся будут перегружены, но в текущем составе постоянный недогруз (а значит, падание доходов, грызня за приходящие задачи и прочие признаки безработицы).


    1. nmivan Автор
      25.12.2018 12:49

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


      1. Vantela
        25.12.2018 13:31

        Этот комментарий удивительно коррелирует с фразой из статьи:

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


        1. nmivan Автор
          25.12.2018 13:46

          ну, все честно. То, что инициировал я — полезное, остальное — вредное :)


          1. Vantela
            25.12.2018 13:53

            Вот это по нашему! Так и должно быть. :D
            *пошел чекаться с Наполеоном из соседней платы*


  1. Vantela
    25.12.2018 13:30

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

    Ну и… если оклад отмерен 60тр. То с чего бы платить 100? Общее количество работы 1Сшников на предприятии то не меняется. А по вашей же статье — упало.

    Хотя можно зачесть в «экономию» то что выявилось в «приятном бонусе». Вот это действительно результат.


  1. boxvk257
    25.12.2018 13:30

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


  1. molec
    25.12.2018 17:49
    +1

    Жестковато.
    Люди после 3-6 месяцев не потянулись на выход?
    Как по мне, в таком режиме можно выполнять только простейшие, разжованнейшие задачи. Возьми там, положи туда, умножь и сложи. И то возможны конфликты типов данных, проблемы масштаба, скорости работы и т.п.

    Где-то читал, что достижимый результат для программиста — работать 5 часов в день, час через час, большинство либо работает меньше, либо не то чтобы программирует. Программирование != только написание кода, большая часть работы — его обдумывание, в т.ч. неявное. Плюс оформление, тесты, приемка, доработка ТЗ, доставка до прода.


  1. i86com
    26.12.2018 02:00

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

    Потому что обычный программист «на окладе» нет-нет да и начнёт сравнивать себя с мужиком, который за 15-20 т.р. работает на заводе или ЖД, со школьным учителем с 12-часовым рабочим днём и т.д. И сравнение явно будет не в свою пользу (получает в разы больше, а работает в разы меньше, в более «тепличных» условиях).

    Кто-то, боясь «разоблачения», начинает работать максимально втихую — мол, если не отсвечивать, то может, начальство не заметит и не уволит. Кто-то наоборот, начинает громко набивать себе цену, спуская на это кучу рабочего времени.

    А с переменной ЗП необходимость в этом пропадает — всем сразу видно, за что и сколько платят, всё по-честному, а не по недосмотру.


  1. mSnus
    26.12.2018 03:53

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


    Я бы свалил подальше от таких оценок, удивительно, что программисты согласились так работать. Это вдвойне странно, учитывая, что оцениваются задачи по "идеальному программисту", а таковых в вашем коллективе нет, кроме вас)) то есть люди заранее соглашаются с недооценкой задачи, у них гарантировано уйдёт больше времени? При этом оценка в полтора-три раза ниже, чем у внешних оценщиков… Или все так стремились стать идеальными, или где-то подвох.


  1. androidt1c
    26.12.2018 09:32
    +1

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

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

    Вроде — сядь и разберись, чего такого-то, всегда так делали»

    Стоп… Программисту поставлена конкретная задача «сделать заполнение субконто Склад». Зачем ему лезть в изучение схемы по переработке?
    Или это тупое транслирование бездумной хотелки какого-то бухгалтера «хочу видеть субконто на 003 счете»? Тогда проблемы на фирме очень большие, и не в программистах и их мотивации, а в отсутствии на фирме грамотного постановщика задач, а вся дальнейшая суета — смысла не имеет, ибо задачи ставятся черт-те как.


  1. frankmasonus
    26.12.2018 11:30

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


  1. Samedi_Da_Kapa
    26.12.2018 11:30

    У нас была одно время схожая система, но с другим подходом к оценке. Нас было 4 человека и ЛПР. В пятницу мы просматривали задачи на следующую неделю и ставили свои оценки — ту я сделаю за полчаса, эту за час и т.д. Оценки видны только оценивающему и ЛПР, чтобы оценки были независимы. Это была наша сторона.
    Со стороны ЛПР использовалась корелляция оценки с учетом опыта — один занижал время, считая что сделает на раз-два, другой наоборот всегда брал резерв «на всякий случай». И уже на основании этого принималось решение — сколько каждая задача должна решатся. Это время и шло в зачет, вне зависимости от рельно затраченного.


  1. LunaLlena
    26.12.2018 11:30

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


  1. mikleh
    26.12.2018 11:30

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


    1. Vantela
      26.12.2018 11:34

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


  1. vassabi
    26.12.2018 12:28

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

    А потом я ушел к игроделам. Это не программисты. Это алхимики\физики-ядерщики. Какие оценки проектов, если никто раньше не делал это?
    «Ребята, вот новый телевизор из Кореи, его еще не выпустили на продажу, подпишите НДА. Там внутри вроде бы линукс. Надо разобраться и портировать на него вот эту игру. Скажите, сколько вам надо на это времени, но только нужно успеть до старта его продаж 25 декабря» — вот почти типичная постановка задачи.


  1. blMoPKoBKa
    26.12.2018 12:32

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

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