Тайны мадридского двора. Часть II: система материальной мотивации разработчиков

    Предыдущий текст серии, описывающий устройство бизнес-процесса постановки и выполнения задач, рекомендован для предварительного ознакомления.
    Здесь же — о том, как и за что получают деньги программисты. Задачи, решаемые нашей системой мотивации разработчиков. 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 за неоценимую помощь, как собственно в построении бизнес-процессов компании, так и в создании настоящей серии.
    Ultima
    43,00
    Компания
    Поделиться публикацией

    Комментарии 67

      +3
      Всё супер. А как теперь это соотносится с КЗОТом?
      Да и законодательством вообще?
        –1
        А какие Вы видите противоречия?
        КЗОТ не предусматривает единственно возможным способ ежемесячного получения идентичной суммы.
          –1
          Впрочем, чтобы избежать псевдоюридического флейма про «системы премирования» и обсуждения тонкостей ТК РФ в ущерб основной теме.
          Все вышеописанное соотносится со здравым смыслом, естественным правом, а так же является следствием добровольного соглашения сторон.
          Ни интереса, ни пиетета к бумаготворчеству богомерзкого РФ-чиновничества мы не испытываем. Равно как и не относимся к его юрисдикции.
            +3
            Равно как и не относимся к его юрисдикции.

            Из профиля компании: «Местоположение: Россия, Москва и Московская обл., Москва»

            Как соотносятся эти два утверждения?
              –1
              «У женщин свои секреты» (С)
              В смысле — у схем структурирования трансграничных холдингов.
              Глубже, увы, раскрывать не планируем. Да и к теме не относится.
            +3
            Вы предлагаете разработчикам работать бесплатно над исправлением багов. Принудительная неоплачиваемая работа называется «рабство» и запрещена не только КЗОТом, но и вообще-то уголовным кодексом.
              0
              Кипение возмущенного разума приводит к кликушеству.
              Немножко ссылок по матчасти — для охлаждения перегретого разума:
              Рабство: 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_mother
                +1
                Имхо, зря вы это здесь опубликовали. Попадется (или найдется доброжелатель) сотруднику министерства труда и социальной защиты РФ, и в нужный момент они план сделают.
                  +1
                  Демонстрация эффективности абсолютно аналогичного подхода тоже в сфере услуг, но не в программировании: www.ultimaerp.com/results/toyota_dzidoka_and_cousma_mother

                  Какой характерный пример! Если погуглить отзывы про эти самы «Руки из плеч», то видно кучу негативных отзывов о них. Главная претензия сильно завышенные цены на ремонт. Все по формуле:
                  — сотрудник завышает сложность работы (накричиваем себе ЗатраченныеЧасы)
                  — предпочитают полную замену, ремонут (быстрее и надежнее заменить модуль в сборе, чем искать неисправность, и плевать что это дороже)
                    0
                    А вы про любой другой сервис попробуйте погуглить.
                    И сравните.
                      0
                      Почему бы вам просто не ответить, за то что вы делали (вы же консультировали их), без кивания на других?

                      К другим сервисам, претензии в основном или по срокам или по качеству. Тут практически полное единодушие: завышенная сложность и как следствие стоимость ремонта. На качество как раз особых нареканий нет. Правда удовлетворенность клиента все равно плохая.
              +5
              А вы точно уверены, что в системе хранятся «исключительно объективно измеряемые показатели»? Не боитесь, что сработает принцип GIGO?

              И почему оценка заказчика не подпадает под определение «корпоративно-идиотической ереси»? Заказчики по определению более объективны, чем своя команда и босс, «высасывающий чушь из пальца»?
                0
                Очень хороший вопрос.
                Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
                  0
                  Это технократическое безумие. Была такая компания МВ там использовался подобный подход. На 500 сотрудников было 30 сотрудников отдела программирования!
                  Бесконечное решение одной и той же задачи и исправление одних и тех же ошибок в разных окнах и армах программы.
                  Штрафа и бессмысленные инструкции, оставляют в компании глупых программистов которые научились без ошибок как обезьянки делать шаблонные задачи.
                  Мне кажется чисто программистские проблемы архитектуры этого продукта создали этот безумный KPI.
                  На сайте вроде написано, что 3 клиента у этой компании. Сколько там программистов на 3х клиентов если нужна такая система распределения?
                  +5
                  Несмотря на то, что система нелогична и контр-продуктивна в целой куче моментов, остановлюсь только на одном: система вообще не предполагает развития долгосрочных отношений с программистом и заказчиком. Представьте себе типичный огромный энтерпрайз-проект, длящийся годами. На этапе разработки всё будет хорошо, но вот пройдёт пару лет — и большинство задач (процентов 80) будут относиться к поддержке и багфиксингу. И что же вы — будете в каждом случае докапываться кто сделал этот баг много лет назад и списывать расходы на него? Или распределять затраты на всех новых программистов, которые вообще к этому коду раньше отношения не имели, а тут вдруг, оказывается, что они почему-то на ровно месте оштрафованы на %стоимость_фикса% / %количество_разработчиков% денег?

                  В общем, всё это может выехать при ведении дел в духе «нанимаем только студентов, у них глаза горят, они готовы работать за еду и унижаться», а иначе — никак.
                    –1
                    Неверно. Как по логике, так и по практике.
                    Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
                      +2
                      Вы знаете, что сделайте — не сами «развёрнуто ответьте» (понятно, что рабовладелец всегда самому себе объяснит, почему иметь рабов — хорошо), а предложите своим сотрудникам АНОНИМНО «развёрнуто ответить». Только реально анонимно — с домашнего компа и левой почты. Могут, например, мне на почту написать (адрес в профиле), а я тут опубликую. Вот это будет объективно!
                        +1
                        Как и обещал — публикую анонимное письмо от человека, представившегося работником компании:
                        "
                        1. текучка кадров есть ибо не все способны выдержать подобный темп и лентяи долго не задерживаются, но чаще дело не доходит до найма, когда они узнают правила игры.
                        2. люди от которых много гемороя и ошибок так же сильно не задерживаются.
                        3. на прежних местах работы я много раз сетовал на то, что отдельные люди не работают а получают ЗП столько сколько и я. здесь я зарабатываю столько сколько хочу. своей ЗП я более чем доволен, более того за последние 3 года она выросла в 2 раза.
                        4. да, увы за последние 3 года условия стали жёстче нежели чем когда я приходил, но проблем с ЗП я не наблюдаю
                        5. насчёт долгого взаимодействия и багфиксов: я бы сказал в любой промежуток времени 95% это разработка и 5% багфикс (именно по текущим задачам) и все понимают правила игры и ошибок реально становится меньше.

                        небольшое дополнение, что бы информация про наличие текучку была понята правильно:

                        все разработчики работающие сейчас в компании работают больше 2 лет"
                          +1
                          все разработчики работающие сейчас в компании работают больше 2 лет

                          как-то цепляет все — после фразы «дело не доходит до найма, когда они узнают правила игры» воспринимается как «никого нового за два года на работу не приняли»
                            0
                            Анонимки не комментируем. По фактологии: на текущий момент в штате есть несколько человек со стажем менее 2-х лет. В четвертом квартале прошлого года в связи с очевидными тенденциями в экономике мы остановили набор разработчиков. В процессе фоновой текучки при отсутствии притока новых кадров, естественно, вымываются в первую очередь наименее квалифицированные сотрудники.
                    +8
                    Ад.
                      –3
                      Адъ и Израиль!
                      +9
                      Выигрышный алгоритм:

                      1. Завышаем сроки исполнения задач. Не сильно, но ощутимо. Как только заказчики начинают привыкать к вашим срокам, дуем ещё немного.
                      2. Облизываем заказчиков, объясняя, что ну никак быстрее не получится, родненькие. Общаемся с ними хорошо, чтобы хорошо чувствовалось противопоставление белых и пушистых вас и стандартного айтишника-интроверта, шлющего по любому поводу на три буквы.
                      3. Делаем задачи медленно, пишем код как можно проще и прямолинейнее, формально подгоняя его под эти ваши стандарты. На производительность пофигу, трайкэтчим каждый написанный блок, подпираем всё костылями, лишь бы работало.
                      4. Какое-то время живём припеваючи, премия за раздутые часы капает, все довольны.
                      5. Как только вычеты за ошибки начинают превышать разумный предел и премии перестаёт хватать на красную икру, уходим из компании, сваливая все будущие вычеты поровну на оставшихся неудачников.

                      Опять же, этот алгоритм выигрышный, если ваша ставка разработчика плюс премия превышает реальную зарплату подобного же разработчика у конкурентов. Если же вы набираете на низкий оклад, заманивая высокими премиями, после которых зарплата выравнивается до среднерыночной, то выигрышный алгоритм — не приходить к вам вообще.
                        –3
                        Несмотря на видимую логичность выводов — вы ошибаетесь. В системе присутствуют противовесы, которые страхуют от такого развития событий, на которые вы не обратили внимания.
                        Ну и практика говорит об обратном.
                        Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
                          +3
                          Мне всё-таки больше интересно, как соотносится фактическая зарплата ваших разработчиков, загнанных в такие жёсткие рамки, со среднерыночной. То, что эта система, по вашим заявлениям, у вас как-то работает, говорит о трёх возможных вариантах: либо у вас работают студенты-энтузиасты, которым на оплату в принципе пофигу (пока задачи интересные), либо оклад плюс премия получается существенно выше среднерыночной оценки для подобного же разработчика (т.е. разработчики меняют остаток своей свободы на деньги), либо у вас адовая текучка.
                            –1
                            Факты: доход рыночный, текучка минимальна. В следующей части покажем, где вы ошибаетесь в логике.
                        +4
                        Как только я перестаю думать о деньгах — я пишу хороший код.
                        Если же программируя я буду думать о бонусах/малусах — то нафиг такое.

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

                        Плюс при всякой возможности искать виноватых в коллегах. А как же коллективная ответственность за продукт? Или как в старом монологе — «к пуговицам претензии есть?», а на остальное — все равно?
                          –1
                          Собственно, забегая вперед — описанная система заставляет думать не бонусах\малусах, а об интересах клиента. А не о позитивном впечатлении начальника. Вот и все.
                          Бонусы\малусы суть инструмент, который в условиях нормального рабочего процесса и довольного заказчика на итоговый доход влияет крайне несущественно, и то в основном в плюс.

                          Но, еще раз, эти моменты будут освещены ярче в следующей части.
                            +1
                            Отнюдь, позволю себе не согласиться с этим утверждением. Если заранее известен набор параметров и вес каждого из них, то при такой постановке вопроса, сотрудник будет думать ни о клиенте, а о том как оптимизировать соотношение затраченные усилия\вознаграждение, и выберет из возможного набора KPI те, которые конкретно ему будет проще, в силу каких-то причин, закрыть с минимальными усилиями при максимальной личной выгоде, причем часто будет оказываться, что цели закрываются не совсем с теми результатами, на какие рассчитывает разработчик KPI. Оставшиеся же показатели будут либо выполнены формально, либо вовсе проигнорированы. Так как для сотрудника не будет иметь ровным счетом никакого значения, на сколько выбранный им показатель важен в конечном счете. Всё что мы увидели, получив систему KPI, так это то, что она отлично стимулирует оставаться посредственностями. Ну и смекалку развивает у сотрудников, это тоже стоит отметить.
                              0
                              Логическая цепочка из набора утверждений без фактов и предположений без аргументации. Это не в плане поругаться, а констатация факта. Соответственно. предмет содержательной дискуссии отсутствует.
                          +1
                          К сожалению именно так в основном работают большие корпорации. С точки зрения бизнеса это хороший стабильный подход, но для каждого конкретного разработчика это провал, люди очень медленно развиваются профессионально в таких компаниях.
                            +3
                            Сугубо, ИМХО.

                            Что измеряете, то и получите.

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

                            Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.
                              –1
                              Если мыслить в той же стилистике, то вводя «общие» KPI, вы получите СССР.
                                –1
                                Однако, очень правильно замечено — «что измеряете, то и получите». Основное, что мы измеряем — удовлетворенность клиентов.
                                  +7
                                  Тогда одна стриптизерша способна окупить месячный провал :D
                                +3
                                Мне кажется, есть четыре проблемы:
                                1. Есть коллективная ответственность с багами. Должно снижать мотивацию.

                                2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
                                Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимсть бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.

                                3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.

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

                                Встречаете ли Вы у себя эти проблемы? Если да, то как решаете. Если нет, то как избежали?
                                  –1
                                  Вопросы приняты. Ответы — в следующей части
                                  +2
                                  Если хотите, мнение сотрудника одной крупной компании, которая после нескольких лет работы, решила внедрить и поставить во главу угла KPI, вроде тех, о каких написано в статье, только сфера деятельности другая.

                                  Знаете, в какой момент ломается вся эта стройная игра в KPI? После первой выплаты вознаграждения по итогам отчетного периода. А знаете почему? Потому что сотрудники не настолько глупы, что бы не понять, что теперь они получают деньги не за выполнение работы, а за выполнение показателей KPI. И весь рабочий процесс рядового сотрудника перестраивается на то, что бы показатели стали «зелеными», при этом ни о каком качестве выполнения работ, или хоть каком-то желании что-то оптимизировать или внедрять новое речи уже не идет. Просто нет смысла. И всё становится еще хуже, когда до сотрудников начинает доходить, что они бегут за морковкой которая болтается на веревке перед их носом, в то время как затраченные усилия не соответствуют уровню получаемой за них компенсации. Ну и розочкой на торте является любимая песня менеджмента про коллективную ответственность, — «ну мы же все в одной лодке», вот после этого самые талантливые и производящие добавленную стоимость окончательно понимают, что с пудовой гирей на ногах далеко не убежишь. Собственно занавес.

                                    0
                                    Вы имеете ввиду, что KPI вообще зло и не приносят никакой пользы?

                                    Я думаю, что примерно то же самое можно сказать о том, что термин «выполнение работы» (без KPI) субъективен, всеми понимается по-разному. При этом все подстраиваются по понимание руководством этого термина и о нормальном выполнении работы уже речь не идет. Все просто стараются «ублажить» руководителя.
                                      +2
                                      Я имею ввиду, что введение жестких KPI подменяет для сотрудника цель его работы, с «выполнение работы», каким бы субъективным ни было это понятие, на «получение зеленого KPI». Т.е. для индивида, подменяется связь «результат работы-компенсация», на «зеленый KPI-компенсация». То, что «результат работы» и «зеленый KPI» это будут две принципиально разные цели, видимо, сомнений возникать не должно.

                                      Я согласен, что для менеджера всё должно быть измеримым, по-другому это не работает, но для конкретных исполнителей, чем сильнее бъет «линейка», тем больше желание что-нибудь с этим сделать, и на работу времени уже не остается.
                                        +1
                                        Согласен, за исключением
                                        То, что «результат работы» и «зеленый KPI» это будут две принципиально разные цели, видимо, сомнений возникать не должно.

                                        Разве руководители компаний такие уж болваны, чтобы проектировать оторванные от жизни KPI?
                                          0
                                          Разве руководители компаний такие уж болваны, чтобы ставить цели, которые достижимы без напряга?
                                            0
                                            Вы не ответили на вопрос. Руководители должны ставить достижимые цели и выбирать KPI таким образом, чтобы достижение высоких KPI показателей коррелировало с достижением этих целей.

                                            Почему вы считаете, что результаты работы и высокий KPI в жизни вещи несовместимые?
                                              0
                                              Как тут недавно напомнили, в 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 создаются строго в таком вот ключе.
                                              Не знаю почему. Наверное, просто мир не идеален.
                                            +1
                                            Я знаю очень мало руководителей компаний, которые включают в KPI снижение технического долга.
                                              0
                                              Технический долг подразумевает накопление ухудшений качества кода в угоду скорости разработки, верно?

                                              Трудно говорить абстрактно, не имея реального примера, но я думаю следующее:

                                              • Рефакторинг кода трудно поддается объективной оценке. Его сложно выразить в числах
                                              • Качество кода (величину технического долга) вполне реально отслеживать другими KPI показателями. Например, скорость разработки, количество багов в единицу времени
                                                0
                                                Рефакторинг кода трудно поддается объективной оценке. Его сложно выразить в оценке

                                                На самом деле, у него есть объективные метрики, просто их улучшение противоречит улучшению метрики «скорость разработки».

                                                Качество кода (величину технического долга) вполне реально отслеживать другими KPI показателями. Например, скорость разработки, количество багов в единицу времени

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

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

                                                  В обоих случаях (как низкая скорость разработки, так и количество багов) низкий показатель KPI может быть вызван как техническим долгом, так и квалификацией разработчика. Нет объективных способов определить, что есть что.

                                                  В принципе, верно. Но ведь для этого руководитель и есть, разве не так? Не думаю, что разумно полностью бездумно довериться KPI.

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

                                                  Я думаю, это достаточно просто проследить, используя VCS вроде Git. Всегда можно посмотреть, кто автор кода, относительно которого в последствии оказалось, что он привел к росту технического долга.

                                                  Моя точка зрения такова, что не стоит брать какую-то одну проблему (например, наличие технического долга), возводить ее в ранг абсолюта и утверждать, что из-за нее внедрять KPI вообще бесполезно.
                                                    0
                                                    Можете привести пример метрик?

                                                    Степень связности компонентов. Тестовое покрытие.

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

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

                                                    Но ведь для этого руководитель и есть, разве не так?

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

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

                                                    А если технический долг вырабатывался последовательно, по строчке (феномен разбитого окна)? А если автор кода — не тот же человек, который принял решение (например, решение навязано тимлидом или выработано на совещании)?

                                                    Моя точка зрения такова, что не стоит брать какую-то одну проблему (например, наличие технического долга), возводить ее в ранг абсолюта и утверждать, что из-за нее внедрять KPI вообще бесполезно.

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

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

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

                                                      Да, я заметил. В этом я с вами согласен. Руководителя из схемы исключать нельзя.

                                                      А если технический долг вырабатывался последовательно, по строчке (феномен разбитого окна)?

                                                      Я думаю, что факт такого возникновения долга тоже можно проследить по VCS. Хотя для его учета в работе сотрудников нужен будет руководитель (от которого в статье предлагается уйти).

                                                      А если автор кода — не тот же человек, который принял решение (например, решение навязано тимлидом или выработано на совещании)?

                                                      Да, это действительно проблема. Но она существует безотносительно к KPI. Такое может произойти в любой компании и в любой ситуации.

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

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

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

                                                          заказчику плевать на технический долг

                                                          Я думаю, что если есть необходимость, заказчику все можно будет объяснить.
                                                            0
                                                            Не думаю, что радикально.

                                                            Ну, порядок (неделя вместо дня) вполне встречается.

                                                            Я думаю, что если есть необходимость, заказчику все можно будет объяснить.

                                                            Я только что (literally) провел полчаса, пытаясь объяснить заказчику стоимость доработки. Если заказчик убежден, что он знает технологии лучше разработчика, то вы ему ничего не объясните. А если во главе оценки стоит удовлетворение заказчика, то он будет давить на то, что его оценка верная, а все остальное считать неудовлетворенностью.
                                                              0
                                                              Я согласен, но если заказчик убежден, что он знает все лучше, чем разработчик, вам придется послать к черту рефакторинг, KPI, собственное мнение, сделать так, как хочет он, а потом остаться виноватым в том, что получится.
                                                                0
                                                                … только в том случае, если удовлетворение заказчика стоит на первом месте.
                                                                  0
                                                                  В общем, да. Только… я бы остерегался обращаться в компании, у которых желание удовлетворить заказчика не стоит на первом месте ;)
                                                                    0
                                                                    А зря. Потому что желание решить проблему заказчика полезнее, чем желание доставить ему удовольствие.
                                                                      0
                                                                      Давайте не будем играть словами. Я думаю, вполне понятно, что имелось ввиду.
                                                                        0
                                                                        Вам — вполне понятно. Но одно. А автору статьи может быть вполне понятно другое.

                                                                        А в моей рабочей практике удовлетворение заказчика и решение его реальных задач часто друг другу противоречит. Именно благодаря тому, что заказчик сам лучше все знает.
                                                                          0
                                                                          Я имел ввиду, что «удовлетворить заказчика» означает решить его проблему. На мой взгляд это единственно правильный подход к делу.
                                                                            0
                                                                            На мой — тоже, но, к сожалению, далеко не все заказчики (да и руководители) разделяют этот подход. Когда успешность проекта определяется заказчиком субъективно с помощью слайдера — это как раз доставить удовольствие. Чтобы решать проблемы, нужно их определить и выявить формальные критерии их решения.
                                              0
                                              Похоже, что я не достаточно ясно сформулировал мысль. Позвольте пару простых примеров, думаю идею вы поймаете.

                                              «KPI — написание качественного кода для успешного прохождения тестов». Что хочет получить работодатель? Качестенный код. А что он получит? Код успешно проходящий тесты.

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

                                                «количество открытых инцидентов в стеке» может служить показателем, но не может рассматриваться отдельно. Лучше всего внедрять KPI в соответствии с чем-то вроде ССП.

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

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


                                                  Об этом и речь.
                                                    0
                                                    Разрешите встрять в дискуссию
                                                    Как известно, «ничто не хорошо само по себе и все хорошо применительно к обстоятельствам». Правильно спроектированная ССП — великое благо, неправильно — приводит как раз к последствиям, описываемым Маниту. Собственно, тема статьи и есть — описание нашей ССП, ее, по нашему мнению, преимуществ и ожидание конструктивной критики в целях ее оптимизации.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Помните анекдот про стратегических консультантов — «ежики, станьте совами»?
                                            В предыдущей серии мы писали про принципиальную бесперспективность попыток «нормирования».
                                            Но если вдруг придумаете что-то реально работоспособное — наша благодарность не будет знать границ. В разумных пределах :)

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

                                          Самое читаемое