Comments 67
Всё супер. А как теперь это соотносится с КЗОТом?
Да и законодательством вообще?
Да и законодательством вообще?
А какие Вы видите противоречия?
КЗОТ не предусматривает единственно возможным способ ежемесячного получения идентичной суммы.
КЗОТ не предусматривает единственно возможным способ ежемесячного получения идентичной суммы.
Впрочем, чтобы избежать псевдоюридического флейма про «системы премирования» и обсуждения тонкостей ТК РФ в ущерб основной теме.
Все вышеописанное соотносится со здравым смыслом, естественным правом, а так же является следствием добровольного соглашения сторон.
Ни интереса, ни пиетета к бумаготворчеству богомерзкого РФ-чиновничества мы не испытываем. Равно как и не относимся к его юрисдикции.
Все вышеописанное соотносится со здравым смыслом, естественным правом, а так же является следствием добровольного соглашения сторон.
Ни интереса, ни пиетета к бумаготворчеству богомерзкого РФ-чиновничества мы не испытываем. Равно как и не относимся к его юрисдикции.
Равно как и не относимся к его юрисдикции.
Из профиля компании: «Местоположение: Россия, Москва и Московская обл., Москва»
Как соотносятся эти два утверждения?
Вы предлагаете разработчикам работать бесплатно над исправлением багов. Принудительная неоплачиваемая работа называется «рабство» и запрещена не только КЗОТом, но и вообще-то уголовным кодексом.
Кипение возмущенного разума приводит к кликушеству.
Немножко ссылок по матчасти — для охлаждения перегретого разума:
Рабство: 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
Немножко ссылок по матчасти — для охлаждения перегретого разума:
Рабство: 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
Имхо, зря вы это здесь опубликовали. Попадется (или найдется доброжелатель) сотруднику министерства труда и социальной защиты РФ, и в нужный момент они план сделают.
Демонстрация эффективности абсолютно аналогичного подхода тоже в сфере услуг, но не в программировании: www.ultimaerp.com/results/toyota_dzidoka_and_cousma_mother
Какой характерный пример! Если погуглить отзывы про эти самы «Руки из плеч», то видно кучу негативных отзывов о них. Главная претензия сильно завышенные цены на ремонт. Все по формуле:
— сотрудник завышает сложность работы (накричиваем себе ЗатраченныеЧасы)
— предпочитают полную замену, ремонут (быстрее и надежнее заменить модуль в сборе, чем искать неисправность, и плевать что это дороже)
А вы про любой другой сервис попробуйте погуглить.
И сравните.
И сравните.
Почему бы вам просто не ответить, за то что вы делали (вы же консультировали их), без кивания на других?
К другим сервисам, претензии в основном или по срокам или по качеству. Тут практически полное единодушие: завышенная сложность и как следствие стоимость ремонта. На качество как раз особых нареканий нет. Правда удовлетворенность клиента все равно плохая.
К другим сервисам, претензии в основном или по срокам или по качеству. Тут практически полное единодушие: завышенная сложность и как следствие стоимость ремонта. На качество как раз особых нареканий нет. Правда удовлетворенность клиента все равно плохая.
А вы точно уверены, что в системе хранятся «исключительно объективно измеряемые показатели»? Не боитесь, что сработает принцип GIGO?
И почему оценка заказчика не подпадает под определение «корпоративно-идиотической ереси»? Заказчики по определению более объективны, чем своя команда и босс, «высасывающий чушь из пальца»?
И почему оценка заказчика не подпадает под определение «корпоративно-идиотической ереси»? Заказчики по определению более объективны, чем своя команда и босс, «высасывающий чушь из пальца»?
Очень хороший вопрос.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
Это технократическое безумие. Была такая компания МВ там использовался подобный подход. На 500 сотрудников было 30 сотрудников отдела программирования!
Бесконечное решение одной и той же задачи и исправление одних и тех же ошибок в разных окнах и армах программы.
Штрафа и бессмысленные инструкции, оставляют в компании глупых программистов которые научились без ошибок как обезьянки делать шаблонные задачи.
Мне кажется чисто программистские проблемы архитектуры этого продукта создали этот безумный KPI.
На сайте вроде написано, что 3 клиента у этой компании. Сколько там программистов на 3х клиентов если нужна такая система распределения?
Бесконечное решение одной и той же задачи и исправление одних и тех же ошибок в разных окнах и армах программы.
Штрафа и бессмысленные инструкции, оставляют в компании глупых программистов которые научились без ошибок как обезьянки делать шаблонные задачи.
Мне кажется чисто программистские проблемы архитектуры этого продукта создали этот безумный KPI.
На сайте вроде написано, что 3 клиента у этой компании. Сколько там программистов на 3х клиентов если нужна такая система распределения?
Несмотря на то, что система нелогична и контр-продуктивна в целой куче моментов, остановлюсь только на одном: система вообще не предполагает развития долгосрочных отношений с программистом и заказчиком. Представьте себе типичный огромный энтерпрайз-проект, длящийся годами. На этапе разработки всё будет хорошо, но вот пройдёт пару лет — и большинство задач (процентов 80) будут относиться к поддержке и багфиксингу. И что же вы — будете в каждом случае докапываться кто сделал этот баг много лет назад и списывать расходы на него? Или распределять затраты на всех новых программистов, которые вообще к этому коду раньше отношения не имели, а тут вдруг, оказывается, что они почему-то на ровно месте оштрафованы на %стоимость_фикса% / %количество_разработчиков% денег?
В общем, всё это может выехать при ведении дел в духе «нанимаем только студентов, у них глаза горят, они готовы работать за еду и унижаться», а иначе — никак.
В общем, всё это может выехать при ведении дел в духе «нанимаем только студентов, у них глаза горят, они готовы работать за еду и унижаться», а иначе — никак.
Неверно. Как по логике, так и по практике.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
Вы знаете, что сделайте — не сами «развёрнуто ответьте» (понятно, что рабовладелец всегда самому себе объяснит, почему иметь рабов — хорошо), а предложите своим сотрудникам АНОНИМНО «развёрнуто ответить». Только реально анонимно — с домашнего компа и левой почты. Могут, например, мне на почту написать (адрес в профиле), а я тут опубликую. Вот это будет объективно!
Как и обещал — публикую анонимное письмо от человека, представившегося работником компании:
"
1. текучка кадров есть ибо не все способны выдержать подобный темп и лентяи долго не задерживаются, но чаще дело не доходит до найма, когда они узнают правила игры.
2. люди от которых много гемороя и ошибок так же сильно не задерживаются.
3. на прежних местах работы я много раз сетовал на то, что отдельные люди не работают а получают ЗП столько сколько и я. здесь я зарабатываю столько сколько хочу. своей ЗП я более чем доволен, более того за последние 3 года она выросла в 2 раза.
4. да, увы за последние 3 года условия стали жёстче нежели чем когда я приходил, но проблем с ЗП я не наблюдаю
5. насчёт долгого взаимодействия и багфиксов: я бы сказал в любой промежуток времени 95% это разработка и 5% багфикс (именно по текущим задачам) и все понимают правила игры и ошибок реально становится меньше.
небольшое дополнение, что бы информация про наличие текучку была понята правильно:
все разработчики работающие сейчас в компании работают больше 2 лет"
"
1. текучка кадров есть ибо не все способны выдержать подобный темп и лентяи долго не задерживаются, но чаще дело не доходит до найма, когда они узнают правила игры.
2. люди от которых много гемороя и ошибок так же сильно не задерживаются.
3. на прежних местах работы я много раз сетовал на то, что отдельные люди не работают а получают ЗП столько сколько и я. здесь я зарабатываю столько сколько хочу. своей ЗП я более чем доволен, более того за последние 3 года она выросла в 2 раза.
4. да, увы за последние 3 года условия стали жёстче нежели чем когда я приходил, но проблем с ЗП я не наблюдаю
5. насчёт долгого взаимодействия и багфиксов: я бы сказал в любой промежуток времени 95% это разработка и 5% багфикс (именно по текущим задачам) и все понимают правила игры и ошибок реально становится меньше.
небольшое дополнение, что бы информация про наличие текучку была понята правильно:
все разработчики работающие сейчас в компании работают больше 2 лет"
все разработчики работающие сейчас в компании работают больше 2 лет
как-то цепляет все — после фразы «дело не доходит до найма, когда они узнают правила игры» воспринимается как «никого нового за два года на работу не приняли»
Анонимки не комментируем. По фактологии: на текущий момент в штате есть несколько человек со стажем менее 2-х лет. В четвертом квартале прошлого года в связи с очевидными тенденциями в экономике мы остановили набор разработчиков. В процессе фоновой текучки при отсутствии притока новых кадров, естественно, вымываются в первую очередь наименее квалифицированные сотрудники.
Ад.
Выигрышный алгоритм:
1. Завышаем сроки исполнения задач. Не сильно, но ощутимо. Как только заказчики начинают привыкать к вашим срокам, дуем ещё немного.
2. Облизываем заказчиков, объясняя, что ну никак быстрее не получится, родненькие. Общаемся с ними хорошо, чтобы хорошо чувствовалось противопоставление белых и пушистых вас и стандартного айтишника-интроверта, шлющего по любому поводу на три буквы.
3. Делаем задачи медленно, пишем код как можно проще и прямолинейнее, формально подгоняя его под эти ваши стандарты. На производительность пофигу, трайкэтчим каждый написанный блок, подпираем всё костылями, лишь бы работало.
4. Какое-то время живём припеваючи, премия за раздутые часы капает, все довольны.
5. Как только вычеты за ошибки начинают превышать разумный предел и премии перестаёт хватать на красную икру, уходим из компании, сваливая все будущие вычеты поровну на оставшихся неудачников.
Опять же, этот алгоритм выигрышный, если ваша ставка разработчика плюс премия превышает реальную зарплату подобного же разработчика у конкурентов. Если же вы набираете на низкий оклад, заманивая высокими премиями, после которых зарплата выравнивается до среднерыночной, то выигрышный алгоритм — не приходить к вам вообще.
1. Завышаем сроки исполнения задач. Не сильно, но ощутимо. Как только заказчики начинают привыкать к вашим срокам, дуем ещё немного.
2. Облизываем заказчиков, объясняя, что ну никак быстрее не получится, родненькие. Общаемся с ними хорошо, чтобы хорошо чувствовалось противопоставление белых и пушистых вас и стандартного айтишника-интроверта, шлющего по любому поводу на три буквы.
3. Делаем задачи медленно, пишем код как можно проще и прямолинейнее, формально подгоняя его под эти ваши стандарты. На производительность пофигу, трайкэтчим каждый написанный блок, подпираем всё костылями, лишь бы работало.
4. Какое-то время живём припеваючи, премия за раздутые часы капает, все довольны.
5. Как только вычеты за ошибки начинают превышать разумный предел и премии перестаёт хватать на красную икру, уходим из компании, сваливая все будущие вычеты поровну на оставшихся неудачников.
Опять же, этот алгоритм выигрышный, если ваша ставка разработчика плюс премия превышает реальную зарплату подобного же разработчика у конкурентов. Если же вы набираете на низкий оклад, заманивая высокими премиями, после которых зарплата выравнивается до среднерыночной, то выигрышный алгоритм — не приходить к вам вообще.
Несмотря на видимую логичность выводов — вы ошибаетесь. В системе присутствуют противовесы, которые страхуют от такого развития событий, на которые вы не обратили внимания.
Ну и практика говорит об обратном.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
Ну и практика говорит об обратном.
Развернуто ответим в следующей (промежуточной) части, которая будет посвящена ответам на вопросы читателей.
Мне всё-таки больше интересно, как соотносится фактическая зарплата ваших разработчиков, загнанных в такие жёсткие рамки, со среднерыночной. То, что эта система, по вашим заявлениям, у вас как-то работает, говорит о трёх возможных вариантах: либо у вас работают студенты-энтузиасты, которым на оплату в принципе пофигу (пока задачи интересные), либо оклад плюс премия получается существенно выше среднерыночной оценки для подобного же разработчика (т.е. разработчики меняют остаток своей свободы на деньги), либо у вас адовая текучка.
Как только я перестаю думать о деньгах — я пишу хороший код.
Если же программируя я буду думать о бонусах/малусах — то нафиг такое.
Формальный, автоматический процесс премирования только сподвигнет «сломать систему», писать прямолинейный, не изящный код.
Это как хрущевки/брежневки — вроде жить можно, но нет в таких домах элегантности.
Плюс при всякой возможности искать виноватых в коллегах. А как же коллективная ответственность за продукт? Или как в старом монологе — «к пуговицам претензии есть?», а на остальное — все равно?
Если же программируя я буду думать о бонусах/малусах — то нафиг такое.
Формальный, автоматический процесс премирования только сподвигнет «сломать систему», писать прямолинейный, не изящный код.
Это как хрущевки/брежневки — вроде жить можно, но нет в таких домах элегантности.
Плюс при всякой возможности искать виноватых в коллегах. А как же коллективная ответственность за продукт? Или как в старом монологе — «к пуговицам претензии есть?», а на остальное — все равно?
Собственно, забегая вперед — описанная система заставляет думать не бонусах\малусах, а об интересах клиента. А не о позитивном впечатлении начальника. Вот и все.
Бонусы\малусы суть инструмент, который в условиях нормального рабочего процесса и довольного заказчика на итоговый доход влияет крайне несущественно, и то в основном в плюс.
Но, еще раз, эти моменты будут освещены ярче в следующей части.
Бонусы\малусы суть инструмент, который в условиях нормального рабочего процесса и довольного заказчика на итоговый доход влияет крайне несущественно, и то в основном в плюс.
Но, еще раз, эти моменты будут освещены ярче в следующей части.
Отнюдь, позволю себе не согласиться с этим утверждением. Если заранее известен набор параметров и вес каждого из них, то при такой постановке вопроса, сотрудник будет думать ни о клиенте, а о том как оптимизировать соотношение затраченные усилия\вознаграждение, и выберет из возможного набора KPI те, которые конкретно ему будет проще, в силу каких-то причин, закрыть с минимальными усилиями при максимальной личной выгоде, причем часто будет оказываться, что цели закрываются не совсем с теми результатами, на какие рассчитывает разработчик KPI. Оставшиеся же показатели будут либо выполнены формально, либо вовсе проигнорированы. Так как для сотрудника не будет иметь ровным счетом никакого значения, на сколько выбранный им показатель важен в конечном счете. Всё что мы увидели, получив систему KPI, так это то, что она отлично стимулирует оставаться посредственностями. Ну и смекалку развивает у сотрудников, это тоже стоит отметить.
К сожалению именно так в основном работают большие корпорации. С точки зрения бизнеса это хороший стабильный подход, но для каждого конкретного разработчика это провал, люди очень медленно развиваются профессионально в таких компаниях.
Сугубо, ИМХО.
Что измеряете, то и получите.
Мне всегда представлялось, что ПО — продукт командной работы. А в командной работе важен общий результат, а не то сколько километров пробежал форвард, сколько ног сопернику переломал защитник и сколько раз прыгал за мячом вратарь. Все это не важно, если команда проиграла.
Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.
Что измеряете, то и получите.
Мне всегда представлялось, что ПО — продукт командной работы. А в командной работе важен общий результат, а не то сколько километров пробежал форвард, сколько ног сопернику переломал защитник и сколько раз прыгал за мячом вратарь. Все это не важно, если команда проиграла.
Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.
Мне кажется, есть четыре проблемы:
1. Есть коллективная ответственность с багами. Должно снижать мотивацию.
2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимсть бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.
3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.
4. Если уж идет попытка сделать справедливую стоимость оплаты, в зависимости от пользы компании, то к чему Грейды? Если я младший программист и делаю эту задачу так же хорошо как и старший программист — я должен получать столько же.
Встречаете ли Вы у себя эти проблемы? Если да, то как решаете. Если нет, то как избежали?
1. Есть коллективная ответственность с багами. Должно снижать мотивацию.
2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимсть бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.
3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.
4. Если уж идет попытка сделать справедливую стоимость оплаты, в зависимости от пользы компании, то к чему Грейды? Если я младший программист и делаю эту задачу так же хорошо как и старший программист — я должен получать столько же.
Встречаете ли Вы у себя эти проблемы? Если да, то как решаете. Если нет, то как избежали?
Если хотите, мнение сотрудника одной крупной компании, которая после нескольких лет работы, решила внедрить и поставить во главу угла KPI, вроде тех, о каких написано в статье, только сфера деятельности другая.
Знаете, в какой момент ломается вся эта стройная игра в KPI? После первой выплаты вознаграждения по итогам отчетного периода. А знаете почему? Потому что сотрудники не настолько глупы, что бы не понять, что теперь они получают деньги не за выполнение работы, а за выполнение показателей KPI. И весь рабочий процесс рядового сотрудника перестраивается на то, что бы показатели стали «зелеными», при этом ни о каком качестве выполнения работ, или хоть каком-то желании что-то оптимизировать или внедрять новое речи уже не идет. Просто нет смысла. И всё становится еще хуже, когда до сотрудников начинает доходить, что они бегут за морковкой которая болтается на веревке перед их носом, в то время как затраченные усилия не соответствуют уровню получаемой за них компенсации. Ну и розочкой на торте является любимая песня менеджмента про коллективную ответственность, — «ну мы же все в одной лодке», вот после этого самые талантливые и производящие добавленную стоимость окончательно понимают, что с пудовой гирей на ногах далеко не убежишь. Собственно занавес.
Знаете, в какой момент ломается вся эта стройная игра в KPI? После первой выплаты вознаграждения по итогам отчетного периода. А знаете почему? Потому что сотрудники не настолько глупы, что бы не понять, что теперь они получают деньги не за выполнение работы, а за выполнение показателей KPI. И весь рабочий процесс рядового сотрудника перестраивается на то, что бы показатели стали «зелеными», при этом ни о каком качестве выполнения работ, или хоть каком-то желании что-то оптимизировать или внедрять новое речи уже не идет. Просто нет смысла. И всё становится еще хуже, когда до сотрудников начинает доходить, что они бегут за морковкой которая болтается на веревке перед их носом, в то время как затраченные усилия не соответствуют уровню получаемой за них компенсации. Ну и розочкой на торте является любимая песня менеджмента про коллективную ответственность, — «ну мы же все в одной лодке», вот после этого самые талантливые и производящие добавленную стоимость окончательно понимают, что с пудовой гирей на ногах далеко не убежишь. Собственно занавес.
Вы имеете ввиду, что KPI вообще зло и не приносят никакой пользы?
Я думаю, что примерно то же самое можно сказать о том, что термин «выполнение работы» (без KPI) субъективен, всеми понимается по-разному. При этом все подстраиваются по понимание руководством этого термина и о нормальном выполнении работы уже речь не идет. Все просто стараются «ублажить» руководителя.
Я думаю, что примерно то же самое можно сказать о том, что термин «выполнение работы» (без KPI) субъективен, всеми понимается по-разному. При этом все подстраиваются по понимание руководством этого термина и о нормальном выполнении работы уже речь не идет. Все просто стараются «ублажить» руководителя.
Я имею ввиду, что введение жестких KPI подменяет для сотрудника цель его работы, с «выполнение работы», каким бы субъективным ни было это понятие, на «получение зеленого KPI». Т.е. для индивида, подменяется связь «результат работы-компенсация», на «зеленый KPI-компенсация». То, что «результат работы» и «зеленый KPI» это будут две принципиально разные цели, видимо, сомнений возникать не должно.
Я согласен, что для менеджера всё должно быть измеримым, по-другому это не работает, но для конкретных исполнителей, чем сильнее бъет «линейка», тем больше желание что-нибудь с этим сделать, и на работу времени уже не остается.
Я согласен, что для менеджера всё должно быть измеримым, по-другому это не работает, но для конкретных исполнителей, чем сильнее бъет «линейка», тем больше желание что-нибудь с этим сделать, и на работу времени уже не остается.
Согласен, за исключением
Разве руководители компаний такие уж болваны, чтобы проектировать оторванные от жизни KPI?
То, что «результат работы» и «зеленый KPI» это будут две принципиально разные цели, видимо, сомнений возникать не должно.
Разве руководители компаний такие уж болваны, чтобы проектировать оторванные от жизни KPI?
Разве руководители компаний такие уж болваны, чтобы ставить цели, которые достижимы без напряга?
Вы не ответили на вопрос. Руководители должны ставить достижимые цели и выбирать KPI таким образом, чтобы достижение высоких KPI показателей коррелировало с достижением этих целей.
Почему вы считаете, что результаты работы и высокий KPI в жизни вещи несовместимые?
Почему вы считаете, что результаты работы и высокий KPI в жизни вещи несовместимые?
Как тут недавно напомнили, в 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 создаются строго в таком вот ключе.
Не знаю почему. Наверное, просто мир не идеален.
Там включен следующий пункт:
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 создаются строго в таком вот ключе.
Не знаю почему. Наверное, просто мир не идеален.
Я знаю очень мало руководителей компаний, которые включают в KPI снижение технического долга.
Технический долг подразумевает накопление ухудшений качества кода в угоду скорости разработки, верно?
Трудно говорить абстрактно, не имея реального примера, но я думаю следующее:
Трудно говорить абстрактно, не имея реального примера, но я думаю следующее:
- Рефакторинг кода трудно поддается объективной оценке. Его сложно выразить в числах
- Качество кода (величину технического долга) вполне реально отслеживать другими KPI показателями. Например, скорость разработки, количество багов в единицу времени
Рефакторинг кода трудно поддается объективной оценке. Его сложно выразить в оценке
На самом деле, у него есть объективные метрики, просто их улучшение противоречит улучшению метрики «скорость разработки».
Качество кода (величину технического долга) вполне реально отслеживать другими KPI показателями. Например, скорость разработки, количество багов в единицу времени
В обоих случаях (как низкая скорость разработки, так и количество багов) низкий показатель KPI может быть вызван как техническим долгом, так и квалификацией разработчика. Нет объективных способов определить, что есть что. Более того, технический долг, создаваемый сейчас, отразится на описанных вами KPI через полгода или позже, когда уже никто не вспомнит, откуда взяли эти решения.
На самом деле, у него есть объективные метрики, просто их улучшение противоречит улучшению метрики «скорость разработки».
Можете привести пример метрик? По поводу скорости разработки — я думаю, ухудшение происходит только в краткосрочной перспективе.
В обоих случаях (как низкая скорость разработки, так и количество багов) низкий показатель KPI может быть вызван как техническим долгом, так и квалификацией разработчика. Нет объективных способов определить, что есть что.
В принципе, верно. Но ведь для этого руководитель и есть, разве не так? Не думаю, что разумно полностью бездумно довериться KPI.
Более того, технический долг, создаваемый сейчас, отразится на описанных вами KPI через полгода или позже, когда уже никто не вспомнит, откуда взяли эти решения.
Я думаю, это достаточно просто проследить, используя VCS вроде Git. Всегда можно посмотреть, кто автор кода, относительно которого в последствии оказалось, что он привел к росту технического долга.
Моя точка зрения такова, что не стоит брать какую-то одну проблему (например, наличие технического долга), возводить ее в ранг абсолюта и утверждать, что из-за нее внедрять KPI вообще бесполезно.
Можете привести пример метрик?
Степень связности компонентов. Тестовое покрытие.
По поводу скорости разработки — я думаю, ухудшение происходит только в краткосрочной перспективе.
Вы думаете неправильно. Как раз наоборот, технический долг становится хорошо виден только в долгосрочной перспективе.
Но ведь для этого руководитель и есть, разве не так?
Так, да не так. Если вы обратите внимание, то в статье делается упор на то, что руководитель никак не влияет на зарплату сотрудника — только метрики.
Всегда можно посмотреть, кто автор кода, относительно которого в последствии оказалось, что он привел к росту технического долга.
А если технический долг вырабатывался последовательно, по строчке (феномен разбитого окна)? А если автор кода — не тот же человек, который принял решение (например, решение навязано тимлидом или выработано на совещании)?
Моя точка зрения такова, что не стоит брать какую-то одну проблему (например, наличие технического долга), возводить ее в ранг абсолюта и утверждать, что из-за нее внедрять KPI вообще бесполезно.
Никто не утверждает, что KPI бесполезны. Лично я считаю, что KPI — это полезный, но не основной способ оценки качества работы команды.
Вы думаете неправильно. Как раз наоборот, технический долг становится хорошо виден только в долгосрочной перспективе.
Мы говорили об уменьшении скорости разработки из-за рефакторинга, а не из-за технического долга. Я имел ввиду, что рефакторинг действительно уменьшает скорость разработки, но только в краткосрочной перспективе. С кодом, прошедшим рефакторинг становится удобнее и проще работать (в идеале, конечно).
Так, да не так. Если вы обратите внимание, то в статье делается упор на то, что руководитель никак не влияет на зарплату сотрудника — только метрики.
Да, я заметил. В этом я с вами согласен. Руководителя из схемы исключать нельзя.
А если технический долг вырабатывался последовательно, по строчке (феномен разбитого окна)?
Я думаю, что факт такого возникновения долга тоже можно проследить по VCS. Хотя для его учета в работе сотрудников нужен будет руководитель (от которого в статье предлагается уйти).
А если автор кода — не тот же человек, который принял решение (например, решение навязано тимлидом или выработано на совещании)?
Да, это действительно проблема. Но она существует безотносительно к KPI. Такое может произойти в любой компании и в любой ситуации.
Никто не утверждает, что KPI бесполезны. Лично я считаю, что KPI — это полезный, но не основной способ оценки качества работы команды.
Согласен с вами.
Я имел ввиду, что рефакторинг действительно уменьшает скорость разработки, но только в краткосрочной перспективе.
Зато радикально. Учитывая, что оценка в посте идет от заказчика, а заказчику плевать на технический долг, он на это не согласится.
Не думаю, что радикально. Кроме того, думаю, заказчику не обязательно знать, сколько времени пошло на рефакторинг кода, а сколько на написание нового. Обычно заказчику предоставляется смета по общей скорости разработки.
Я думаю, что если есть необходимость, заказчику все можно будет объяснить.
заказчику плевать на технический долг
Я думаю, что если есть необходимость, заказчику все можно будет объяснить.
Не думаю, что радикально.
Ну, порядок (неделя вместо дня) вполне встречается.
Я думаю, что если есть необходимость, заказчику все можно будет объяснить.
Я только что (literally) провел полчаса, пытаясь объяснить заказчику стоимость доработки. Если заказчик убежден, что он знает технологии лучше разработчика, то вы ему ничего не объясните. А если во главе оценки стоит удовлетворение заказчика, то он будет давить на то, что его оценка верная, а все остальное считать неудовлетворенностью.
Я согласен, но если заказчик убежден, что он знает все лучше, чем разработчик, вам придется послать к черту рефакторинг, KPI, собственное мнение, сделать так, как хочет он, а потом остаться виноватым в том, что получится.
… только в том случае, если удовлетворение заказчика стоит на первом месте.
В общем, да. Только… я бы остерегался обращаться в компании, у которых желание удовлетворить заказчика не стоит на первом месте ;)
А зря. Потому что желание решить проблему заказчика полезнее, чем желание доставить ему удовольствие.
Давайте не будем играть словами. Я думаю, вполне понятно, что имелось ввиду.
Вам — вполне понятно. Но одно. А автору статьи может быть вполне понятно другое.
А в моей рабочей практике удовлетворение заказчика и решение его реальных задач часто друг другу противоречит. Именно благодаря тому, что заказчик сам лучше все знает.
А в моей рабочей практике удовлетворение заказчика и решение его реальных задач часто друг другу противоречит. Именно благодаря тому, что заказчик сам лучше все знает.
Я имел ввиду, что «удовлетворить заказчика» означает решить его проблему. На мой взгляд это единственно правильный подход к делу.
На мой — тоже, но, к сожалению, далеко не все заказчики (да и руководители) разделяют этот подход. Когда успешность проекта определяется заказчиком субъективно с помощью слайдера — это как раз доставить удовольствие. Чтобы решать проблемы, нужно их определить и выявить формальные критерии их решения.
Похоже, что я не достаточно ясно сформулировал мысль. Позвольте пару простых примеров, думаю идею вы поймаете.
«KPI — написание качественного кода для успешного прохождения тестов». Что хочет получить работодатель? Качестенный код. А что он получит? Код успешно проходящий тесты.
«KPI — количество открытых инцидентов в стеке». Что хочет работодатель? Что бы запросы клиентов обрабатывались максимально быстро. А что он получит? Чистый стек и абы как закрытые инциденты.
«KPI — написание качественного кода для успешного прохождения тестов». Что хочет получить работодатель? Качестенный код. А что он получит? Код успешно проходящий тесты.
«KPI — количество открытых инцидентов в стеке». Что хочет работодатель? Что бы запросы клиентов обрабатывались максимально быстро. А что он получит? Чистый стек и абы как закрытые инциденты.
Мне кажется, вы неверно выбрали KPI для обсуждения. «Написание качественного кода» не является количественным показателем и не может служить KPI.
«количество открытых инцидентов в стеке» может служить показателем, но не может рассматриваться отдельно. Лучше всего внедрять KPI в соответствии с чем-то вроде ССП.
Вы же понимаете, что аргументация «вот я выбрал KPI наобум, смотрите как они не работают» не может служить доказательством того, что KPI вообще не может соответствовать целям компании. Да и бессмысленно рассматривать одни показатели отдельно от других.
Если ваши KPI не работают на достижение целей компании, это значит, что вы выбрали их некорректно. И еще — внедрение KPI не нужно возводить в ранг абсолюта и думать, что как только внедрили, вселенское счастье должно наступить немедленно и безусловно.
«количество открытых инцидентов в стеке» может служить показателем, но не может рассматриваться отдельно. Лучше всего внедрять KPI в соответствии с чем-то вроде ССП.
Вы же понимаете, что аргументация «вот я выбрал KPI наобум, смотрите как они не работают» не может служить доказательством того, что KPI вообще не может соответствовать целям компании. Да и бессмысленно рассматривать одни показатели отдельно от других.
Если ваши KPI не работают на достижение целей компании, это значит, что вы выбрали их некорректно. И еще — внедрение KPI не нужно возводить в ранг абсолюта и думать, что как только внедрили, вселенское счастье должно наступить немедленно и безусловно.
внедрение KPI не нужно возводить в ранг абсолюта и думать, что как только внедрили, вселенское счастье должно наступить немедленно и безусловно.
Об этом и речь.
Разрешите встрять в дискуссию
Как известно, «ничто не хорошо само по себе и все хорошо применительно к обстоятельствам». Правильно спроектированная ССП — великое благо, неправильно — приводит как раз к последствиям, описываемым Маниту. Собственно, тема статьи и есть — описание нашей ССП, ее, по нашему мнению, преимуществ и ожидание конструктивной критики в целях ее оптимизации.
Как известно, «ничто не хорошо само по себе и все хорошо применительно к обстоятельствам». Правильно спроектированная ССП — великое благо, неправильно — приводит как раз к последствиям, описываемым Маниту. Собственно, тема статьи и есть — описание нашей ССП, ее, по нашему мнению, преимуществ и ожидание конструктивной критики в целях ее оптимизации.
UFO just landed and posted this here
Sign up to leave a comment.
Тайны мадридского двора. Часть II: система материальной мотивации разработчиков