Здесь же — о том, как и за что получают деньги программисты. Задачи, решаемые нашей системой мотивации разработчиков. KPI.
I.Цели и задачи
Система материальной мотивации разработчиков Ultima (СММР) ориентирована на достижение целей из трех групп:
-удовлетворенность заказчика результатом
-качество выдаваемого кода согласно стандартам
-стимулирование профессионального роста разработчиков
Цели СММР достигаются через трансляцию их в соответствующие KPI, значения которых, в свою очередь, определяют повышающие\понижающие коэффициенты и\или бонусы\малусы.
Специальное примечание от Ultima Consulting: СММ в компании Ultima (не только Р!) спроектирована таким образом, чтобы при формировании итогового дохода всех сотрудников без исключения 100% исключить субъективизм и высасываемую из пальца произвольную чушь.
Все считает компьютер в полностью автоматическом режиме — и, соответственно, исключительно на базе объективно измеряемых, фиксируемых и хранимых в базе данных показателей. Никаких “оценок босса”, “итогов встреч” и прочей корпоративно-идиотической ереси.
Каждый сотрудник предельно ясно знает, что ему нужно сделать, чтобы заработать больше. А также, чего НЕ.
Впрочем, это важно, но недостаточно. Намного важнее то, что СММ строится таким образом, чтобы синхронизировать личные интересы сотрудников и общие интересы бизнеса. То есть сотрудник зарабатывает больше денег вместе с компанией и никак иначе.
Строго математически из этого следует, что у нас нет и не может быть системы планирования, использующейся лобовым образом в управлении HR.
Еще одним непосредственным следствием из жирного принципа является отсутствие в штатном расписании должностей, экономическая отдача которых не может быть объективно подсчитана. Собственно, в предыдущей части этот подход демонстрировался на кейсе отказа от внутренних тестировщиков.
Далее все это разберем детально.
II. Зарплатная формула разработчика
Итоговый доход разработчика за период = Сумма Бонусов по выполненным задачам (2.1) + МалусЗаОшибки (2.2) + ОбщеДисциплинарныйБонус (2.3)
Бонус за выполненную задачу (2.1) = ЗатраченныеЧасы (2.1.1) * ТарифнаяСтавкаРазработчика (2.1.2) * КоэффициентПриоритета (2.1.3) * КоэффициентОценкиЗаказчика (2.1.4) * КоэффициентОшибки (2.1.5) * КоэффициентЗвездности (2.1.6) + МалусПросрочкиИсполненияЗаявки (2.1.7)
ОбщеДисциплинарныйБонус (2.3) = МалусЗаНЕСоответствиеСтандартамКодирования (2.3.1) + МалусНЕСоответствияРабочемуГрафику (2.3.2)
Сумма подразумевается алгебраическая: малусы, согласно названию, — отрицательные величины.
Теперь разберем каждый компонент формулы.
2.1 Бонус за выполненную задачу
2.1.1 Затраченные часы
Подробно — см. в предыдущей серии. Коротко — разработчик указывает сколько часов он потратил для решения задачи.
2.1.2 ТарифнаяСтавкаРазработчика
Собственно, базовая ставка часа для программиста (далее будем называть ее внутренний тариф). В предыдущей серии мы смотрели, как через выбор квалификации требуемого разработчика определяется стоимость часа для клиента (внешний тариф). С точки зрения компании, не кривя душой, первую можно назвать себестоимостью, а вторую — продажной ценой. Первая, безусловно, существенно меньше второй — именно на эти “два прОцента” мы и живем.
Внутренний и внешний тариф, естественно, связаны. Но не напрямую, а через таблицу соответствий грейдов разработчиков.
Одной ступени квалификации программиста для клиента (Junior, Developer, Senior) может соответствовать (и соответствует в реальности) несколько грейдов, а внутри каждого грейда может существовать (и существуют в реальности) несколько субгрейдов, для каждого из которых установлена своя базовая ставка часа.
Грейд разработчика является официальной оценкой его профессионального уровня.
Всего у нас шесть грейдов.
Первый грейд разработчик получает после прохождения первоначального обучения. Переходы между субгрейдами и грейдами происходят автоматически — по мере накопления опыта решения задач (экспириенс из Heroes) при условии разумного уровня качества.
Экспириенс считается через суммирование зачардженных часов, плохие оценки и ошибки идут в минус (тривиально — за каждую ошибку столько то часов в минус, за оценку ниже Х столько-то и тд)
Для получения высших грейдов сверх необходимого экспириенса требуется написание статей для внутренней базы знаний.
На практике разработчик получает 5-й грейд примерно через полтора-два года после трудоустройства.
Итак, система внутренних грейдов стимулирует работать больше и лучше тем, что параллельно с профессиональным ростом разработчик получает больше денег (за то же время работы).
2.1.3 КоэффициентПриоритета
За задачи повышенного приоритета разработчик получает усиленное питание (перечеркнуть) повышенный коэффициент, применяемый к базовой ставке, вытекающей из его грейда-субгрейда.
2.1.4 КоэффициентОценкиЗаказчика
При переводе задачи в “выполнено” заказчик выбирает оценку результата:
В нашей внутренней кухне удовлетворительной оценкой считается четверка, соответственно при этой оценке разработчик получит по базовой ставке грейда.
Оценка выше четырех — повышающей коэффициент по этой задаче, меньше — понижающий.
Коэффициент оценки — самый важный модулирующий коэффициент в итоговом доходе.
И разработчик это знает.
Соответственно, привлекательность расклада кнопочек на форме, корректность и своевременность контакта с заказчиком, проникновение в его мысли и желания и так далее — есть стимул за этим смотреть.
Или, по меньшей мере, не действовать “на отъ… бись”.
2.1.6 КоэффициентЗвездности
Напомню, заказчик в заявке может указать не только уровень разработчика, но и конкретного исполнителя для заявки.
Если какой-то из разработчиков пользуется повышенным спросом, повышающий коэффициент может быть применен к его базовой ставке, вытекающей из грейда. Коэффициент применяется только для тех заявок, в которых клиент выбирает только этого исполнителя и не касается заявок, распределенных роботом из общей очереди.
2.1.5 КоэффициентОшибки и 2.2 МалусЗаОшибки
Как я уже писал в прошлой части, задачи типа “Ошибка” обрабатываются специальным образом.
Есть два типа ошибок:
-Созданные как дочерние заявки — то есть на этапе фиксации ошибки в онлайн-трекере известно, в результате реализации какой заявки она возникла
-Отдельно стоящие заявки — когда факт ошибки есть, а источник происхождения не очевиден
“Дочерние” ошибки попадают напрямую к тому исполнителю, который делал основную заявку. Ошибки исправляются бесплатно — и для клиента, и для программиста.
Отдельно стоящие заявки распределяются в общей очереди в соответствии с приоритетом.
Исполнитель, на которого назначается такая задача, может указать виновника ошибки — если это возможно. Работы по исправлению в этом случае будут произведены за счет последнего (по себестоимости).
Если определить автора косяка не представляется возможным, то стоимость исправления равномерно распределяется между всеми разработчиками, участвовавшими в проекте пропорционально сумме зачардженных часов.
Сумма себестоимости исправления личных ошибок разработчика и его пропорциональная доля нераспределенных косяков и составляет его личный месячный МалусЗаОшибки.
Такая практика, несмотря на ее кажущуюся суровость (а, точнее, благодаря) однозначно мотивирует разработчиков действовать в соответствии с принципом “принимать, не создавать, не пропускать брак”.
Почему кажущуюся? Легко сравнить с практикой материальной ответственности кладовщиков или кассиров. У которых она является самой по себе разумеющейся.
Естественным следствием бескомпромиссной мотивации на минимизацию ошибок являются
-улучшение выходного кода в сторону его читаемости
-написание интеграционных тестов
Разработчики ясно видят связь между понятным кодом, в котором легко исправить ошибку (и понести незначительные потери) и невнятной белибердой.
В непонятном коде разработчик, получивший задачу с признаком ошибка, может потратить много времени на разбирательство. А если еще и будет определен виновный (а мотивация его определить тем больше, чем дороже вышло исправление косяка) по задаче, то…
Короче лучше быть богатым и здоровым, то бишь писать понятный код и учиться это делать у других.
Аналогичные рассуждения приводят разработчиков и к написанию интеграционных тестов.
2.1.7 МалусПросрочкиИсполненияЗаявки
Наверняка не только нам знаком вопрос: “Что с заявкой XXX? Уже 3 дня как она должна быть сделана!” Весьма недовольным тоном.
Важный компонент удовлетворенности заказчика — соблюдение прогнозных сроков.
На практике — соблюдение или своевременный перенос перенос этих сроков.
МалусПросрочкиИсполненияЗаявки направлен как раз на информированность заказчика, ибо в реальной жизни возникает много объективных причин для пересмотра срока.
Например — задача требует интеграции с оборудованием у заказчика. И это оборудование сломалось. Приходится ждать его починки или замены.
Итого, нам нужно мотивировать разработчика соблюдать сроки, или хотя бы держать заказчика в курсе изменений.
После многочисленных опытов заработала только отрицательная мотивация.
Для заявок с приоритетом обычная увеличивается МалусПросрочкиИсполненияЗаявки за каждый день сверх плановой даты заявки. Для срочных и критических задач — за каждый час.
Поскольку ожидаемый срок в заявке может перенести только заказчик, то необходимость надлежащего информирования последнего и обоснования при необходимости вытекают автоматически.
2.3 Общедисциплинарный бонус
2.3.1 МалусЗаНЕСоответствиеСтандартамКодирования
В распоряжении каждого разработчика есть Coding Standard. Что как чего надо делать, и чего делать нельзя.
Документ постоянно актуализируется — с одной стороны, от системщиков-ядерщиков при выпуске новых билдов платформы , с другой стороны — от прикладников при разборе причин всплывших косяков (собственно, типичный цикл PDCA).
Часть этого документа содержит достаточно формальные требования, которые мы проверяем автоматически. Например, все наши решения должны работать на русском и английском языках. А значит, в программе не должно быть константных строк (за исключением специально помеченных или однозначно определяемых — например SQL запросов), все строковые константы должны браться из ресурсов, и в ресурсах должны быть значения для всех поддерживаемых языков. Этот и подобные им проверки выполняются с использованием Roslyn в автоматическом режиме. Они реализованы так, что разработчик в принципе не может передать заказчику несоответствующую работу.
В свою очередь, мы стремимся максимально формализовать Coding Standard, чтобы по возможности сократить необходимость ручных проверок.
Малус рассчитывается как фиксированная сумма за каждый случай обнаружения косячного кода.
Полезные рекомендации предложения разработчиков по развитию Coding Standard не только позволяют сократить потери от бесплатного исправления, но и единоразово премируются.
2.3.2 МалусНЕСоответствияРабочемуГрафику
В предыдущей статье я упоминал, что разработчики вольны работать по своему, удобному им графику. Однако, сформировав собственный график, разработчик обязан его придерживаться и быть доступен в установленные им самим часы.
Если выяснится, что разработчик не был на связи в нужное время, плюсуем сабжевый малус — по Х рублей за каждый случай.
В заключение
В итоге многолетнего эволюционного развития СММР мы достоверно наблюдаем реальное повышение удовлетворенности заказчиков, качества и надежности кода, есть мотивационная платформа для введения code review и дальнейшего повышения качества кода и обслуживания.
Средняя оценка по задачам за 2015-й год составляет 4.4, двойка — крайне редкий форс-мажор.
В следующих сериях — что такое бизнес-аналитик (в целях создании интриги — у нас это понятие существенно отличается от общепринятого), зачем он нужен и его мотивация
Автор благодарит Ultima Consulting за неоценимую помощь, как собственно в построении бизнес-процессов компании, так и в создании настоящей серии.
Комментарии (66)
Rupper Автор
14.04.2015 10:50-1А какие Вы видите противоречия?
КЗОТ не предусматривает единственно возможным способ ежемесячного получения идентичной суммы.Rupper Автор
14.04.2015 11:06-1Впрочем, чтобы избежать псевдоюридического флейма про «системы премирования» и обсуждения тонкостей ТК РФ в ущерб основной теме.
Все вышеописанное соотносится со здравым смыслом, естественным правом, а так же является следствием добровольного соглашения сторон.
Ни интереса, ни пиетета к бумаготворчеству богомерзкого РФ-чиновничества мы не испытываем. Равно как и не относимся к его юрисдикции.
lair
14.04.2015 11:42+3Равно как и не относимся к его юрисдикции.
Из профиля компании: «Местоположение: Россия, Москва и Московская обл., Москва»
Как соотносятся эти два утверждения?Rupper Автор
14.04.2015 23:00-1«У женщин свои секреты» (С)
В смысле — у схем структурирования трансграничных холдингов.
Глубже, увы, раскрывать не планируем. Да и к теме не относится.
tangro
14.04.2015 12:46+3Вы предлагаете разработчикам работать бесплатно над исправлением багов. Принудительная неоплачиваемая работа называется «рабство» и запрещена не только КЗОТом, но и вообще-то уголовным кодексом.
Rupper Автор
14.04.2015 23:01Кипение возмущенного разума приводит к кликушеству.
Немножко ссылок по матчасти — для охлаждения перегретого разума:
Рабство: ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B1%D1%81%D1%82%D0%B2%D0%BE
Естественное право: ru.wikipedia.org/wiki/%D0%95%D1%81%D1%82%D0%B5%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%B0%D0%B2%D0%BE
Легизм: ru.wikipedia.org/wiki/%D0%9B%D0%B5%D0%B3%D0%B8%D0%B7%D0%BC
Разрыв в понимании права как легизма в РФ и права как естественного права в развитом мире — Елена Лукьянова echo.msk.ru/blog/novaya_gazeta/1517374-echo
Демонстрация эффективности абсолютно аналогичного подхода тоже в сфере услуг, но не в программировании: www.ultimaerp.com/results/toyota_dzidoka_and_cousma_motherRumlin
15.04.2015 19:43+1Имхо, зря вы это здесь опубликовали. Попадется (или найдется доброжелатель) сотруднику министерства труда и социальной защиты РФ, и в нужный момент они план сделают.
LSD
16.04.2015 16:24+1Демонстрация эффективности абсолютно аналогичного подхода тоже в сфере услуг, но не в программировании: www.ultimaerp.com/results/toyota_dzidoka_and_cousma_mother
Какой характерный пример! Если погуглить отзывы про эти самы «Руки из плеч», то видно кучу негативных отзывов о них. Главная претензия сильно завышенные цены на ремонт. Все по формуле:
— сотрудник завышает сложность работы (накричиваем себе ЗатраченныеЧасы)
— предпочитают полную замену, ремонут (быстрее и надежнее заменить модуль в сборе, чем искать неисправность, и плевать что это дороже)Rupper Автор
16.04.2015 18:03А вы про любой другой сервис попробуйте погуглить.
И сравните.LSD
17.04.2015 12:50Почему бы вам просто не ответить, за то что вы делали (вы же консультировали их), без кивания на других?
К другим сервисам, претензии в основном или по срокам или по качеству. Тут практически полное единодушие: завышенная сложность и как следствие стоимость ремонта. На качество как раз особых нареканий нет. Правда удовлетворенность клиента все равно плохая.
Greesha
14.04.2015 12:47+5А вы точно уверены, что в системе хранятся «исключительно объективно измеряемые показатели»? Не боитесь, что сработает принцип GIGO?
И почему оценка заказчика не подпадает под определение «корпоративно-идиотической ереси»? Заказчики по определению более объективны, чем своя команда и босс, «высасывающий чушь из пальца»?Rupper Автор
14.04.2015 23:03Очень хороший вопрос.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
tangro
14.04.2015 12:52+5Несмотря на то, что система нелогична и контр-продуктивна в целой куче моментов, остановлюсь только на одном: система вообще не предполагает развития долгосрочных отношений с программистом и заказчиком. Представьте себе типичный огромный энтерпрайз-проект, длящийся годами. На этапе разработки всё будет хорошо, но вот пройдёт пару лет — и большинство задач (процентов 80) будут относиться к поддержке и багфиксингу. И что же вы — будете в каждом случае докапываться кто сделал этот баг много лет назад и списывать расходы на него? Или распределять затраты на всех новых программистов, которые вообще к этому коду раньше отношения не имели, а тут вдруг, оказывается, что они почему-то на ровно месте оштрафованы на %стоимость_фикса% / %количество_разработчиков% денег?
В общем, всё это может выехать при ведении дел в духе «нанимаем только студентов, у них глаза горят, они готовы работать за еду и унижаться», а иначе — никак.Rupper Автор
14.04.2015 23:04-1Неверно. Как по логике, так и по практике.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.tangro
15.04.2015 11:41+2Вы знаете, что сделайте — не сами «развёрнуто ответьте» (понятно, что рабовладелец всегда самому себе объяснит, почему иметь рабов — хорошо), а предложите своим сотрудникам АНОНИМНО «развёрнуто ответить». Только реально анонимно — с домашнего компа и левой почты. Могут, например, мне на почту написать (адрес в профиле), а я тут опубликую. Вот это будет объективно!
tangro
15.04.2015 18:05+1Как и обещал — публикую анонимное письмо от человека, представившегося работником компании:
"
1. текучка кадров есть ибо не все способны выдержать подобный темп и лентяи долго не задерживаются, но чаще дело не доходит до найма, когда они узнают правила игры.
2. люди от которых много гемороя и ошибок так же сильно не задерживаются.
3. на прежних местах работы я много раз сетовал на то, что отдельные люди не работают а получают ЗП столько сколько и я. здесь я зарабатываю столько сколько хочу. своей ЗП я более чем доволен, более того за последние 3 года она выросла в 2 раза.
4. да, увы за последние 3 года условия стали жёстче нежели чем когда я приходил, но проблем с ЗП я не наблюдаю
5. насчёт долгого взаимодействия и багфиксов: я бы сказал в любой промежуток времени 95% это разработка и 5% багфикс (именно по текущим задачам) и все понимают правила игры и ошибок реально становится меньше.
небольшое дополнение, что бы информация про наличие текучку была понята правильно:
все разработчики работающие сейчас в компании работают больше 2 лет"Rumlin
15.04.2015 19:47+1все разработчики работающие сейчас в компании работают больше 2 лет
как-то цепляет все — после фразы «дело не доходит до найма, когда они узнают правила игры» воспринимается как «никого нового за два года на работу не приняли»Rupper Автор
16.04.2015 18:24Анонимки не комментируем. По фактологии: на текущий момент в штате есть несколько человек со стажем менее 2-х лет. В четвертом квартале прошлого года в связи с очевидными тенденциями в экономике мы остановили набор разработчиков. В процессе фоновой текучки при отсутствии притока новых кадров, естественно, вымываются в первую очередь наименее квалифицированные сотрудники.
Archon
14.04.2015 14:26+9Выигрышный алгоритм:
1. Завышаем сроки исполнения задач. Не сильно, но ощутимо. Как только заказчики начинают привыкать к вашим срокам, дуем ещё немного.
2. Облизываем заказчиков, объясняя, что ну никак быстрее не получится, родненькие. Общаемся с ними хорошо, чтобы хорошо чувствовалось противопоставление белых и пушистых вас и стандартного айтишника-интроверта, шлющего по любому поводу на три буквы.
3. Делаем задачи медленно, пишем код как можно проще и прямолинейнее, формально подгоняя его под эти ваши стандарты. На производительность пофигу, трайкэтчим каждый написанный блок, подпираем всё костылями, лишь бы работало.
4. Какое-то время живём припеваючи, премия за раздутые часы капает, все довольны.
5. Как только вычеты за ошибки начинают превышать разумный предел и премии перестаёт хватать на красную икру, уходим из компании, сваливая все будущие вычеты поровну на оставшихся неудачников.
Опять же, этот алгоритм выигрышный, если ваша ставка разработчика плюс премия превышает реальную зарплату подобного же разработчика у конкурентов. Если же вы набираете на низкий оклад, заманивая высокими премиями, после которых зарплата выравнивается до среднерыночной, то выигрышный алгоритм — не приходить к вам вообще.Rupper Автор
14.04.2015 23:06-3Несмотря на видимую логичность выводов — вы ошибаетесь. В системе присутствуют противовесы, которые страхуют от такого развития событий, на которые вы не обратили внимания.
Ну и практика говорит об обратном.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.Archon
15.04.2015 08:51+3Мне всё-таки больше интересно, как соотносится фактическая зарплата ваших разработчиков, загнанных в такие жёсткие рамки, со среднерыночной. То, что эта система, по вашим заявлениям, у вас как-то работает, говорит о трёх возможных вариантах: либо у вас работают студенты-энтузиасты, которым на оплату в принципе пофигу (пока задачи интересные), либо оклад плюс премия получается существенно выше среднерыночной оценки для подобного же разработчика (т.е. разработчики меняют остаток своей свободы на деньги), либо у вас адовая текучка.
Rupper Автор
15.04.2015 14:45-1Факты: доход рыночный, текучка минимальна. В следующей части покажем, где вы ошибаетесь в логике.
dhj
14.04.2015 20:59+4Как только я перестаю думать о деньгах — я пишу хороший код.
Если же программируя я буду думать о бонусах/малусах — то нафиг такое.
Формальный, автоматический процесс премирования только сподвигнет «сломать систему», писать прямолинейный, не изящный код.
Это как хрущевки/брежневки — вроде жить можно, но нет в таких домах элегантности.
Плюс при всякой возможности искать виноватых в коллегах. А как же коллективная ответственность за продукт? Или как в старом монологе — «к пуговицам претензии есть?», а на остальное — все равно?Rupper Автор
15.04.2015 14:48-1Собственно, забегая вперед — описанная система заставляет думать не бонусах\малусах, а об интересах клиента. А не о позитивном впечатлении начальника. Вот и все.
Бонусы\малусы суть инструмент, который в условиях нормального рабочего процесса и довольного заказчика на итоговый доход влияет крайне несущественно, и то в основном в плюс.
Но, еще раз, эти моменты будут освещены ярче в следующей части.Manitou
15.04.2015 23:41+1Отнюдь, позволю себе не согласиться с этим утверждением. Если заранее известен набор параметров и вес каждого из них, то при такой постановке вопроса, сотрудник будет думать ни о клиенте, а о том как оптимизировать соотношение затраченные усилия\вознаграждение, и выберет из возможного набора KPI те, которые конкретно ему будет проще, в силу каких-то причин, закрыть с минимальными усилиями при максимальной личной выгоде, причем часто будет оказываться, что цели закрываются не совсем с теми результатами, на какие рассчитывает разработчик KPI. Оставшиеся же показатели будут либо выполнены формально, либо вовсе проигнорированы. Так как для сотрудника не будет иметь ровным счетом никакого значения, на сколько выбранный им показатель важен в конечном счете. Всё что мы увидели, получив систему KPI, так это то, что она отлично стимулирует оставаться посредственностями. Ну и смекалку развивает у сотрудников, это тоже стоит отметить.
Rupper Автор
16.04.2015 18:10Логическая цепочка из набора утверждений без фактов и предположений без аргументации. Это не в плане поругаться, а констатация факта. Соответственно. предмет содержательной дискуссии отсутствует.
MadJeck
15.04.2015 09:02+1К сожалению именно так в основном работают большие корпорации. С точки зрения бизнеса это хороший стабильный подход, но для каждого конкретного разработчика это провал, люди очень медленно развиваются профессионально в таких компаниях.
craft_brother
15.04.2015 15:21+3Сугубо, ИМХО.
Что измеряете, то и получите.
Мне всегда представлялось, что ПО — продукт командной работы. А в командной работе важен общий результат, а не то сколько километров пробежал форвард, сколько ног сопернику переломал защитник и сколько раз прыгал за мячом вратарь. Все это не важно, если команда проиграла.
Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.Rupper Автор
15.04.2015 15:32-1Если мыслить в той же стилистике, то вводя «общие» KPI, вы получите СССР.
Rupper Автор
15.04.2015 15:35-1Однако, очень правильно замечено — «что измеряете, то и получите». Основное, что мы измеряем — удовлетворенность клиентов.
Joshua
15.04.2015 16:54+3Мне кажется, есть четыре проблемы:
1. Есть коллективная ответственность с багами. Должно снижать мотивацию.
2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимсть бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.
3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.
4. Если уж идет попытка сделать справедливую стоимость оплаты, в зависимости от пользы компании, то к чему Грейды? Если я младший программист и делаю эту задачу так же хорошо как и старший программист — я должен получать столько же.
Встречаете ли Вы у себя эти проблемы? Если да, то как решаете. Если нет, то как избежали?
Manitou
15.04.2015 22:17+2Если хотите, мнение сотрудника одной крупной компании, которая после нескольких лет работы, решила внедрить и поставить во главу угла KPI, вроде тех, о каких написано в статье, только сфера деятельности другая.
Знаете, в какой момент ломается вся эта стройная игра в KPI? После первой выплаты вознаграждения по итогам отчетного периода. А знаете почему? Потому что сотрудники не настолько глупы, что бы не понять, что теперь они получают деньги не за выполнение работы, а за выполнение показателей KPI. И весь рабочий процесс рядового сотрудника перестраивается на то, что бы показатели стали «зелеными», при этом ни о каком качестве выполнения работ, или хоть каком-то желании что-то оптимизировать или внедрять новое речи уже не идет. Просто нет смысла. И всё становится еще хуже, когда до сотрудников начинает доходить, что они бегут за морковкой которая болтается на веревке перед их носом, в то время как затраченные усилия не соответствуют уровню получаемой за них компенсации. Ну и розочкой на торте является любимая песня менеджмента про коллективную ответственность, — «ну мы же все в одной лодке», вот после этого самые талантливые и производящие добавленную стоимость окончательно понимают, что с пудовой гирей на ногах далеко не убежишь. Собственно занавес.
FractalizeR
16.04.2015 10:42Вы имеете ввиду, что KPI вообще зло и не приносят никакой пользы?
Я думаю, что примерно то же самое можно сказать о том, что термин «выполнение работы» (без KPI) субъективен, всеми понимается по-разному. При этом все подстраиваются по понимание руководством этого термина и о нормальном выполнении работы уже речь не идет. Все просто стараются «ублажить» руководителя.Manitou
16.04.2015 12:21+2Я имею ввиду, что введение жестких KPI подменяет для сотрудника цель его работы, с «выполнение работы», каким бы субъективным ни было это понятие, на «получение зеленого KPI». Т.е. для индивида, подменяется связь «результат работы-компенсация», на «зеленый KPI-компенсация». То, что «результат работы» и «зеленый KPI» это будут две принципиально разные цели, видимо, сомнений возникать не должно.
Я согласен, что для менеджера всё должно быть измеримым, по-другому это не работает, но для конкретных исполнителей, чем сильнее бъет «линейка», тем больше желание что-нибудь с этим сделать, и на работу времени уже не остается.FractalizeR
16.04.2015 12:56+1Согласен, за исключением
То, что «результат работы» и «зеленый KPI» это будут две принципиально разные цели, видимо, сомнений возникать не должно.
Разве руководители компаний такие уж болваны, чтобы проектировать оторванные от жизни KPI?
datacompboy
16.04.2015 13:11Разве руководители компаний такие уж болваны, чтобы ставить цели, которые достижимы без напряга?
FractalizeR
16.04.2015 14:54Вы не ответили на вопрос. Руководители должны ставить достижимые цели и выбирать KPI таким образом, чтобы достижение высоких KPI показателей коррелировало с достижением этих целей.
Почему вы считаете, что результаты работы и высокий KPI в жизни вещи несовместимые?datacompboy
16.04.2015 18:38Как тут недавно напомнили, в Hola есть отличный стайлгайд по коду.
Там включен следующий пункт:
Do not write code with bugs
— Bugs slow up the development process and make angry customers. So do NOT write bugs in the code.
Тоже очень жизненный, отлично улучшает качество кода и следование ему снижает стоимость разработки.
Вот почему-то большинство KPI создаются строго в таком вот ключе.
Не знаю почему. Наверное, просто мир не идеален.
lair
16.04.2015 13:29+1Я знаю очень мало руководителей компаний, которые включают в KPI снижение технического долга.
FractalizeR
16.04.2015 15:01Технический долг подразумевает накопление ухудшений качества кода в угоду скорости разработки, верно?
Трудно говорить абстрактно, не имея реального примера, но я думаю следующее:
- Рефакторинг кода трудно поддается объективной оценке. Его сложно выразить в числах
- Качество кода (величину технического долга) вполне реально отслеживать другими KPI показателями. Например, скорость разработки, количество багов в единицу времени
lair
16.04.2015 15:06Рефакторинг кода трудно поддается объективной оценке. Его сложно выразить в оценке
На самом деле, у него есть объективные метрики, просто их улучшение противоречит улучшению метрики «скорость разработки».
Качество кода (величину технического долга) вполне реально отслеживать другими KPI показателями. Например, скорость разработки, количество багов в единицу времени
В обоих случаях (как низкая скорость разработки, так и количество багов) низкий показатель KPI может быть вызван как техническим долгом, так и квалификацией разработчика. Нет объективных способов определить, что есть что. Более того, технический долг, создаваемый сейчас, отразится на описанных вами KPI через полгода или позже, когда уже никто не вспомнит, откуда взяли эти решения.FractalizeR
16.04.2015 15:20На самом деле, у него есть объективные метрики, просто их улучшение противоречит улучшению метрики «скорость разработки».
Можете привести пример метрик? По поводу скорости разработки — я думаю, ухудшение происходит только в краткосрочной перспективе.
В обоих случаях (как низкая скорость разработки, так и количество багов) низкий показатель KPI может быть вызван как техническим долгом, так и квалификацией разработчика. Нет объективных способов определить, что есть что.
В принципе, верно. Но ведь для этого руководитель и есть, разве не так? Не думаю, что разумно полностью бездумно довериться KPI.
Более того, технический долг, создаваемый сейчас, отразится на описанных вами KPI через полгода или позже, когда уже никто не вспомнит, откуда взяли эти решения.
Я думаю, это достаточно просто проследить, используя VCS вроде Git. Всегда можно посмотреть, кто автор кода, относительно которого в последствии оказалось, что он привел к росту технического долга.
Моя точка зрения такова, что не стоит брать какую-то одну проблему (например, наличие технического долга), возводить ее в ранг абсолюта и утверждать, что из-за нее внедрять KPI вообще бесполезно.lair
16.04.2015 15:33Можете привести пример метрик?
Степень связности компонентов. Тестовое покрытие.
По поводу скорости разработки — я думаю, ухудшение происходит только в краткосрочной перспективе.
Вы думаете неправильно. Как раз наоборот, технический долг становится хорошо виден только в долгосрочной перспективе.
Но ведь для этого руководитель и есть, разве не так?
Так, да не так. Если вы обратите внимание, то в статье делается упор на то, что руководитель никак не влияет на зарплату сотрудника — только метрики.
Всегда можно посмотреть, кто автор кода, относительно которого в последствии оказалось, что он привел к росту технического долга.
А если технический долг вырабатывался последовательно, по строчке (феномен разбитого окна)? А если автор кода — не тот же человек, который принял решение (например, решение навязано тимлидом или выработано на совещании)?
Моя точка зрения такова, что не стоит брать какую-то одну проблему (например, наличие технического долга), возводить ее в ранг абсолюта и утверждать, что из-за нее внедрять KPI вообще бесполезно.
Никто не утверждает, что KPI бесполезны. Лично я считаю, что KPI — это полезный, но не основной способ оценки качества работы команды.FractalizeR
16.04.2015 16:29Вы думаете неправильно. Как раз наоборот, технический долг становится хорошо виден только в долгосрочной перспективе.
Мы говорили об уменьшении скорости разработки из-за рефакторинга, а не из-за технического долга. Я имел ввиду, что рефакторинг действительно уменьшает скорость разработки, но только в краткосрочной перспективе. С кодом, прошедшим рефакторинг становится удобнее и проще работать (в идеале, конечно).
Так, да не так. Если вы обратите внимание, то в статье делается упор на то, что руководитель никак не влияет на зарплату сотрудника — только метрики.
Да, я заметил. В этом я с вами согласен. Руководителя из схемы исключать нельзя.
А если технический долг вырабатывался последовательно, по строчке (феномен разбитого окна)?
Я думаю, что факт такого возникновения долга тоже можно проследить по VCS. Хотя для его учета в работе сотрудников нужен будет руководитель (от которого в статье предлагается уйти).
А если автор кода — не тот же человек, который принял решение (например, решение навязано тимлидом или выработано на совещании)?
Да, это действительно проблема. Но она существует безотносительно к KPI. Такое может произойти в любой компании и в любой ситуации.
Никто не утверждает, что KPI бесполезны. Лично я считаю, что KPI — это полезный, но не основной способ оценки качества работы команды.
Согласен с вами.lair
16.04.2015 16:46Я имел ввиду, что рефакторинг действительно уменьшает скорость разработки, но только в краткосрочной перспективе.
Зато радикально. Учитывая, что оценка в посте идет от заказчика, а заказчику плевать на технический долг, он на это не согласится.FractalizeR
16.04.2015 17:07Не думаю, что радикально. Кроме того, думаю, заказчику не обязательно знать, сколько времени пошло на рефакторинг кода, а сколько на написание нового. Обычно заказчику предоставляется смета по общей скорости разработки.
заказчику плевать на технический долг
Я думаю, что если есть необходимость, заказчику все можно будет объяснить.lair
16.04.2015 17:22Не думаю, что радикально.
Ну, порядок (неделя вместо дня) вполне встречается.
Я думаю, что если есть необходимость, заказчику все можно будет объяснить.
Я только что (literally) провел полчаса, пытаясь объяснить заказчику стоимость доработки. Если заказчик убежден, что он знает технологии лучше разработчика, то вы ему ничего не объясните. А если во главе оценки стоит удовлетворение заказчика, то он будет давить на то, что его оценка верная, а все остальное считать неудовлетворенностью.FractalizeR
16.04.2015 18:58Я согласен, но если заказчик убежден, что он знает все лучше, чем разработчик, вам придется послать к черту рефакторинг, KPI, собственное мнение, сделать так, как хочет он, а потом остаться виноватым в том, что получится.
lair
16.04.2015 19:02… только в том случае, если удовлетворение заказчика стоит на первом месте.
FractalizeR
16.04.2015 19:40В общем, да. Только… я бы остерегался обращаться в компании, у которых желание удовлетворить заказчика не стоит на первом месте ;)
lair
16.04.2015 23:25А зря. Потому что желание решить проблему заказчика полезнее, чем желание доставить ему удовольствие.
FractalizeR
17.04.2015 10:33Давайте не будем играть словами. Я думаю, вполне понятно, что имелось ввиду.
lair
17.04.2015 10:43Вам — вполне понятно. Но одно. А автору статьи может быть вполне понятно другое.
А в моей рабочей практике удовлетворение заказчика и решение его реальных задач часто друг другу противоречит. Именно благодаря тому, что заказчик сам лучше все знает.FractalizeR
17.04.2015 10:49Я имел ввиду, что «удовлетворить заказчика» означает решить его проблему. На мой взгляд это единственно правильный подход к делу.
lair
17.04.2015 11:05На мой — тоже, но, к сожалению, далеко не все заказчики (да и руководители) разделяют этот подход. Когда успешность проекта определяется заказчиком субъективно с помощью слайдера — это как раз доставить удовольствие. Чтобы решать проблемы, нужно их определить и выявить формальные критерии их решения.
Manitou
16.04.2015 15:14Похоже, что я не достаточно ясно сформулировал мысль. Позвольте пару простых примеров, думаю идею вы поймаете.
«KPI — написание качественного кода для успешного прохождения тестов». Что хочет получить работодатель? Качестенный код. А что он получит? Код успешно проходящий тесты.
«KPI — количество открытых инцидентов в стеке». Что хочет работодатель? Что бы запросы клиентов обрабатывались максимально быстро. А что он получит? Чистый стек и абы как закрытые инциденты.FractalizeR
16.04.2015 15:31Мне кажется, вы неверно выбрали KPI для обсуждения. «Написание качественного кода» не является количественным показателем и не может служить KPI.
«количество открытых инцидентов в стеке» может служить показателем, но не может рассматриваться отдельно. Лучше всего внедрять KPI в соответствии с чем-то вроде ССП.
Вы же понимаете, что аргументация «вот я выбрал KPI наобум, смотрите как они не работают» не может служить доказательством того, что KPI вообще не может соответствовать целям компании. Да и бессмысленно рассматривать одни показатели отдельно от других.
Если ваши KPI не работают на достижение целей компании, это значит, что вы выбрали их некорректно. И еще — внедрение KPI не нужно возводить в ранг абсолюта и думать, что как только внедрили, вселенское счастье должно наступить немедленно и безусловно.Manitou
16.04.2015 15:37внедрение KPI не нужно возводить в ранг абсолюта и думать, что как только внедрили, вселенское счастье должно наступить немедленно и безусловно.
Об этом и речь.
Rupper Автор
16.04.2015 18:14Разрешите встрять в дискуссию
Как известно, «ничто не хорошо само по себе и все хорошо применительно к обстоятельствам». Правильно спроектированная ССП — великое благо, неправильно — приводит как раз к последствиям, описываемым Маниту. Собственно, тема статьи и есть — описание нашей ССП, ее, по нашему мнению, преимуществ и ожидание конструктивной критики в целях ее оптимизации.
eugzol
17.04.2015 11:17> Бонус за выполненную задачу (2.1) = ЗатраченныеЧасы (2.1.1) * ТарифнаяСтавкаРазработчика (2.1.2)…
Есть ровно одно изменение формулы, которое снимет все возражения комментаторов выше + возможность по предложенным им алгоритмам «похачить» систему (злоупотреблять формулой, делая не слишком полезную работу).
Изрекаю: заменить «ЗатраченныеЧасы» на «НормоЧасы».
А дальше можно садиться и очень очень долго думать, как нормировать работу программиста. Но результат окупится.Rupper Автор
20.04.2015 17:44Помните анекдот про стратегических консультантов — «ежики, станьте совами»?
В предыдущей серии мы писали про принципиальную бесперспективность попыток «нормирования».
Но если вдруг придумаете что-то реально работоспособное — наша благодарность не будет знать границ. В разумных пределах :)
datacompboy
Всё супер. А как теперь это соотносится с КЗОТом?
Да и законодательством вообще?