Цикл публикаций “Тайны мадридского двора” задумывался в намерениях (цитата из первой части):
“...наши решения больных вопросов и используемые технологии работы ни в коей мере не позиционируются как наилучшие. Напротив, имея намерение рассказать коллегам по опасному бизнесу о собственных наработках, мы ожидаем получить в комментах конструктивную критику и встречные идеи, не пришедшие в головы нам.”
Основная, по нашему впечатлению, часть читателей восприняла содержимое статей либо как рекламу компании в разделе вакансий программистов, либо как возможность реализовать давние обиды неоцененных талантов на гадких тупых начальников.
То есть диалога с собственно “коллегами по опасному бизнесу” (в смысле с предпринимателями в сфере производства\внедрения близкого по смыслу софта) не получилось. Видимо, за оных коллег несущественно малым процентом от аудитории Хабра. Mea culpa.
Таким образом, продолжать цикл за отсутствием целевой аудитории смысла мы не будем (по крайней мере, на этой площадке), но, следуя взятым на себя ранее обязательствам, ниже разберем аргументированные возражения и ответим на содержательные вопросы, сформулированные читателями в комментах к предыдущей части и не отвеченные в полном объеме там же.
Отвечает Ultima Consulting.
Greesha:
… почему оценка заказчика не подпадает под определение «корпоративно-идиотической ереси»? Заказчики по определению более объективны, чем своя команда и босс, «высасывающий чушь из пальца»?
tangro:
система вообще не предполагает развития долгосрочных отношений с программистом и заказчиком. Представьте себе типичный огромный энтерпрайз-проект, длящийся годами. На этапе разработки всё будет хорошо, но вот пройдёт пару лет — и большинство задач (процентов 80) будут относиться к поддержке и багфиксингу. И что же вы — будете в каждом случае докапываться кто сделал этот баг много лет назад и списывать расходы на него? Или распределять затраты на всех новых программистов, которые вообще к этому коду раньше отношения не имели, а тут вдруг, оказывается, что они почему-то на ровно месте оштрафованы на %стоимость_фикса% / %количество_разработчиков% денег?
Автор вопроса меняет местами причину и следствие.
Система, нами описанная, ориентирована не на поиски виноватых, а на минимизацию поводов для этого: то есть, ошибок. Мало ошибок — мало багфиксинга — мало проблем — мало расходов. Подход, в теории менеджмента известный как “нуль дефектов”.
Вообще, чрезвычайно распространенная ошибка: подстраивать систему так, чтобы косяки были менее болезненными. Подход легкий, простой, и неверный.
Правильно — подстраивать систему так, чтобы косяки возникали как можно реже. А для этого необходимо, чтобы они были неприятны. Примерно, как ребенок приучается к горшку. Развернуто здесь.
“Баг, много лет назад”. Если баг был сделан много лет назад и никому не мешал, скорее всего, это бывшая фича. И под схему обработки ошибок не попадает.
Касательно системы, “не предполагающей долгосрочных отношений с заказчиком” — бОльшая часть регулярного денежного потока у нас идет от клиентов, с которыми мы работаем более «пары лет».
Archon:
Выигрышный алгоритм:
1. Завышаем сроки исполнения задач. Не сильно, но ощутимо. Как только заказчики начинают привыкать к вашим срокам, дуем ещё немного.
2. Облизываем заказчиков, объясняя, что ну никак быстрее не получится, родненькие. Общаемся с ними хорошо, чтобы хорошо чувствовалось противопоставление белых и пушистых вас и стандартного айтишника-интроверта, шлющего по любому поводу на три буквы.
3. Делаем задачи медленно, пишем код как можно проще и прямолинейнее, формально подгоняя его под эти ваши стандарты. На производительность пофигу, трайкэтчим каждый написанный блок, подпираем всё костылями, лишь бы работало.
4. Какое-то время живём припеваючи, премия за раздутые часы капает, все довольны.
5. Как только вычеты за ошибки начинают превышать разумный предел и премии перестаёт хватать на красную икру, уходим из компании, сваливая все будущие вычеты поровну на оставшихся неудачников.
Опять же, этот алгоритм выигрышный, если ваша ставка разработчика плюс премия превышает реальную зарплату подобного же разработчика у конкурентов. Если же вы набираете на низкий оклад, заманивая высокими премиями, после которых зарплата выравнивается до среднерыночной, то выигрышный алгоритм — не приходить к вам вообще.
Сначала пара цитаток:
“… у теорий заговора одни и те же проблемы совместимости с реальностью: приписываемые заговорщикам способности глобального контроля вкупе с полной секретностью требует безупречной работы механизма заговора, что, при заявленных целях (контроль над миром), наличных силах (относительно небольшая группа людей) и времени действия (десятилетия, века, а то и тысячелетия) исполнимо чуть менее, чем никак.”
“Человеку, воспитанному в традициях европейского рационального мышления, ужасно хочется, чтоб общественные процессы были подчинены какому-то осмысленному плану; пусть злодейскому, человеконенавистническому, но всё же разумному, в смысле – рациональному.”
Потаенного смысла в приведенных цитатах искать не стоит — просто так отчего то в голову пришло. Кхм.
Итак, почему логичная схема Archon не работает, по крайней мере, в наше случае: потому что каждый здоровый человек (то есть — не менее 80% населения) при прочих равных стремится работать хорошо.
Это не прекраснодушный треп, а научно установленный факт: так устроен человеческий (и не только) мозг, в котором, в свою очередь, эти установки заложены миллиарднолетней эволюцией. В частности, поэтому дерьмово работающие люди не бывают счастливыми — необходимой предпосылкой довольства жизнью является удовлетворенность своей работой и ее результатами. И это, опять таки, генетические законы работы мозга — усилием воли их не изменить, так же как еж не может усилием воли превратиться в сову.
Здоровый человек начинает работать плохо только в том случае, когда его к этому относительно жестко и относительно долго стимулирует система. При этом порядка 20% людей все равно продолжают работать хорошо (честный мент из Нашей Раши).
Если же система стимулирует качественный труд, то все легко, хорошо и синергично. Непросто только выстроить подобную систему.
Это с точки зрения теории.
Практика ее подтверждает (и наша, и миллионов хорошо работающих компаний по всему миру, да и сам факт существования рыночной экономики) — и опровергает человеконенавистническую (nothing personal) схему Archon’а.
Далее — два вопроса, которые в минимальных вариациях повторяют вопрос Archon’а, и ответ, в общем, тот же:
Manitou:
Если заранее известен набор параметров и вес каждого из них, то при такой постановке вопроса, сотрудник будет думать ни о клиенте, а о том как оптимизировать соотношение затраченные усилия\вознаграждение, и выберет из возможного набора KPI те, которые конкретно ему будет проще, в силу каких-то причин, закрыть с минимальными усилиями при максимальной личной выгоде, причем часто будет оказываться, что цели закрываются не совсем с теми результатами, на какие рассчитывает разработчик KPI. Оставшиеся же показатели будут либо выполнены формально, либо вовсе проигнорированы. Так как для сотрудника не будет иметь ровным счетом никакого значения, на сколько выбранный им показатель важен в конечном счете. Всё что мы увидели, получив систему KPI, так это то, что она отлично стимулирует оставаться посредственностями. Ну и смекалку развивает у сотрудников, это тоже стоит отметить.
dhj:
Как только я перестаю думать о деньгах — я пишу хороший код.
Если же программируя я буду думать о бонусах/малусах — то нафиг такое.
Формальный, автоматический процесс премирования только сподвигнет «сломать систему», писать прямолинейный, не изящный код.
Это как хрущевки/брежневки — вроде жить можно, но нет в таких домах элегантности.
Плюс при всякой возможности искать виноватых в коллегах. А как же коллективная ответственность за продукт? Или как в старом монологе — «к пуговицам претензии есть?», а на остальное — все равно?
Дополнительно для dhj сверх универсального ответа Архону.
Опять телега впереди лошади.
Хорошая система тем и хороша, что если вы хорошо исполняете свою работу (пишете хороший код) — вам не нужно думать о деньгах, потому что хорошие деньги за хорошую работу вы получите автоматически.
И еще раз оговоримся — мы вовсе не считаем собственную схему работу идеальной. Но она, на текущий момент, — лучшая из систем, которую мы своими скромными силами смогли придумать и реализовать. При этом работа по совершенствованию — бесконечна, вне всякого сомнения («кайдзен»).
Да, по поводу “коллективной ответственности” за продукт. Есть сомнения, что автор вопроса правильно понимает смысл этого термина . “Коллективная ответственность” — это когда за преступление одного еврея сжигают всех евреев. За бегство с поля боя одного бойца расстреливают взвод. За косяк одного программиста штрафуют\увольняют всех. А тимбилдинговое бульканье типа “мы команда и вместе отвечаем за все” — это коллективная безответственность. “Тащи с завода каждый гвоздь, ты здесь хозяин, а не гость”.
craft_brother
Сугубо, ИМХО.
Что измеряете, то и получите.
Мне всегда представлялось, что ПО — продукт командной работы. А в командной работе важен общий результат, а не то сколько километров пробежал форвард, сколько ног сопернику переломал защитник и сколько раз прыгал за мячом вратарь. Все это не важно, если команда проиграла.
Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.
Автор вопроса, возможно — случайно, затронул очень интересный вопрос — правильный баланс между локальными оптимумами (сколько ног сопернику переломал) и итоговым результатом (выиграли или нет). Детально в популярном изложении это рассматривается в работах Голдратта.
Правильным балансом является однозначный приоритет итогового результата. В нашем случае — это прибыль. Автоцитата:
СММ строится таким образом, чтобы синхронизировать личные интересы сотрудников и общие интересы бизнеса. То есть сотрудник зарабатывает больше денег вместе с компанией и никак иначе.
Иными словами, мы берем нужный итоговый результат (выигрыш команды) и декомпозируем его на требования к действиям конкретных игроков. А не наоборот.
Кстати сказать, именно “наоборот” исторически характерно для западной управленческой традиции — в этом кроется причина тамошней популярности в общем то, совершенно очевидных тезисов Голдратта, которыми он переворачивает логику с головы на ноги.
Касательно же “разжигания конкуренции” индивидуальными КПЭ — ну а что, собственно, плохого в конкуренции между сотрудниками, например, качеством работы? Это же не игра с нулевой суммой, выигрыш одного не означает проигрыша остальных.
Даже в дремучем СССР пытались такую конкуренцию разворачивать — “соцсоревнования” и “переходящее красное знамя”.
Joshua
Мне кажется, есть четыре проблемы:
1. Есть коллективная ответственность с багами. Должно снижать мотивацию.
2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимость бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.
3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.
4. Если уж идет попытка сделать справедливую стоимость оплаты, в зависимости от пользы компании, то к чему Грейды? Если я младший программист и делаю эту задачу так же хорошо как и старший программист — я должен получать столько же.
“...наши решения больных вопросов и используемые технологии работы ни в коей мере не позиционируются как наилучшие. Напротив, имея намерение рассказать коллегам по опасному бизнесу о собственных наработках, мы ожидаем получить в комментах конструктивную критику и встречные идеи, не пришедшие в головы нам.”
Основная, по нашему впечатлению, часть читателей восприняла содержимое статей либо как рекламу компании в разделе вакансий программистов, либо как возможность реализовать давние обиды неоцененных талантов на гадких тупых начальников.
То есть диалога с собственно “коллегами по опасному бизнесу” (в смысле с предпринимателями в сфере производства\внедрения близкого по смыслу софта) не получилось. Видимо, за оных коллег несущественно малым процентом от аудитории Хабра. Mea culpa.
Таким образом, продолжать цикл за отсутствием целевой аудитории смысла мы не будем (по крайней мере, на этой площадке), но, следуя взятым на себя ранее обязательствам, ниже разберем аргументированные возражения и ответим на содержательные вопросы, сформулированные читателями в комментах к предыдущей части и не отвеченные в полном объеме там же.
Отвечает Ultima Consulting.
Greesha:
… почему оценка заказчика не подпадает под определение «корпоративно-идиотической ереси»? Заказчики по определению более объективны, чем своя команда и босс, «высасывающий чушь из пальца»?
- Оценка заказчика, несомненно, во многом субъективна. Однако абсолютной объективностью обладают деньги, которыми он оплачивает наши услуги и, следовательно, зарплату программиста.
Чем больше доволен заказчик, тем больше он платит денег (чуть упрощая, и при прочих равных). А, вспоминая Мацуситу, “прибыль — мера полезности компании для общества”. - При, опять же, прочих равных — оценка заказчика менее субъективна, нежели оценка босса. Потому что у заказчика есть объективная потребность, нуждающаяся в удовлетворении (задача к решению). У босса — нет.
Можно сказать, что боссу нужно больше денег, но тогда см. п. 1
Уместно так же вспомнить Джека Уэлша: “Иерархически устроенная компания повернута лицом к боссу и задом к потребителю”. - При нарушении принципа “при прочих равных” из предыдущего пункта (предположим, ответственный сотрудник заказчика — злобная дрянь и всем из ненависти ставит плохие оценки) сработает автоматический стопор — наши разработчики просто не будут принимать на себя его задачи. Кому охота зазря терять в деньгах?
Естественным образом возникает проблема, эскалируемая наверх и у заказчика, и нас — которая разрешается административно-кадровым образом.
Разрешается потому, что обе стороны теоретического конфликта мотивированы на конструктивную договоренность — нам нужны деньги, заказчику нужно решение задач.
Что, если злобной дрянью является самый главный чел заказчика? Крайне маловероятно. Плюс к тому объективная мотивация на конструктивное разрешение никуда не девается и в этом случае.
tangro:
система вообще не предполагает развития долгосрочных отношений с программистом и заказчиком. Представьте себе типичный огромный энтерпрайз-проект, длящийся годами. На этапе разработки всё будет хорошо, но вот пройдёт пару лет — и большинство задач (процентов 80) будут относиться к поддержке и багфиксингу. И что же вы — будете в каждом случае докапываться кто сделал этот баг много лет назад и списывать расходы на него? Или распределять затраты на всех новых программистов, которые вообще к этому коду раньше отношения не имели, а тут вдруг, оказывается, что они почему-то на ровно месте оштрафованы на %стоимость_фикса% / %количество_разработчиков% денег?
Автор вопроса меняет местами причину и следствие.
Система, нами описанная, ориентирована не на поиски виноватых, а на минимизацию поводов для этого: то есть, ошибок. Мало ошибок — мало багфиксинга — мало проблем — мало расходов. Подход, в теории менеджмента известный как “нуль дефектов”.
Вообще, чрезвычайно распространенная ошибка: подстраивать систему так, чтобы косяки были менее болезненными. Подход легкий, простой, и неверный.
Правильно — подстраивать систему так, чтобы косяки возникали как можно реже. А для этого необходимо, чтобы они были неприятны. Примерно, как ребенок приучается к горшку. Развернуто здесь.
“Баг, много лет назад”. Если баг был сделан много лет назад и никому не мешал, скорее всего, это бывшая фича. И под схему обработки ошибок не попадает.
Касательно системы, “не предполагающей долгосрочных отношений с заказчиком” — бОльшая часть регулярного денежного потока у нас идет от клиентов, с которыми мы работаем более «пары лет».
Archon:
Выигрышный алгоритм:
1. Завышаем сроки исполнения задач. Не сильно, но ощутимо. Как только заказчики начинают привыкать к вашим срокам, дуем ещё немного.
2. Облизываем заказчиков, объясняя, что ну никак быстрее не получится, родненькие. Общаемся с ними хорошо, чтобы хорошо чувствовалось противопоставление белых и пушистых вас и стандартного айтишника-интроверта, шлющего по любому поводу на три буквы.
3. Делаем задачи медленно, пишем код как можно проще и прямолинейнее, формально подгоняя его под эти ваши стандарты. На производительность пофигу, трайкэтчим каждый написанный блок, подпираем всё костылями, лишь бы работало.
4. Какое-то время живём припеваючи, премия за раздутые часы капает, все довольны.
5. Как только вычеты за ошибки начинают превышать разумный предел и премии перестаёт хватать на красную икру, уходим из компании, сваливая все будущие вычеты поровну на оставшихся неудачников.
Опять же, этот алгоритм выигрышный, если ваша ставка разработчика плюс премия превышает реальную зарплату подобного же разработчика у конкурентов. Если же вы набираете на низкий оклад, заманивая высокими премиями, после которых зарплата выравнивается до среднерыночной, то выигрышный алгоритм — не приходить к вам вообще.
Сначала пара цитаток:
“… у теорий заговора одни и те же проблемы совместимости с реальностью: приписываемые заговорщикам способности глобального контроля вкупе с полной секретностью требует безупречной работы механизма заговора, что, при заявленных целях (контроль над миром), наличных силах (относительно небольшая группа людей) и времени действия (десятилетия, века, а то и тысячелетия) исполнимо чуть менее, чем никак.”
“Человеку, воспитанному в традициях европейского рационального мышления, ужасно хочется, чтоб общественные процессы были подчинены какому-то осмысленному плану; пусть злодейскому, человеконенавистническому, но всё же разумному, в смысле – рациональному.”
Потаенного смысла в приведенных цитатах искать не стоит — просто так отчего то в голову пришло. Кхм.
Итак, почему логичная схема Archon не работает, по крайней мере, в наше случае: потому что каждый здоровый человек (то есть — не менее 80% населения) при прочих равных стремится работать хорошо.
Это не прекраснодушный треп, а научно установленный факт: так устроен человеческий (и не только) мозг, в котором, в свою очередь, эти установки заложены миллиарднолетней эволюцией. В частности, поэтому дерьмово работающие люди не бывают счастливыми — необходимой предпосылкой довольства жизнью является удовлетворенность своей работой и ее результатами. И это, опять таки, генетические законы работы мозга — усилием воли их не изменить, так же как еж не может усилием воли превратиться в сову.
Здоровый человек начинает работать плохо только в том случае, когда его к этому относительно жестко и относительно долго стимулирует система. При этом порядка 20% людей все равно продолжают работать хорошо (честный мент из Нашей Раши).
Если же система стимулирует качественный труд, то все легко, хорошо и синергично. Непросто только выстроить подобную систему.
Это с точки зрения теории.
Практика ее подтверждает (и наша, и миллионов хорошо работающих компаний по всему миру, да и сам факт существования рыночной экономики) — и опровергает человеконенавистническую (nothing personal) схему Archon’а.
Далее — два вопроса, которые в минимальных вариациях повторяют вопрос Archon’а, и ответ, в общем, тот же:
Manitou:
Если заранее известен набор параметров и вес каждого из них, то при такой постановке вопроса, сотрудник будет думать ни о клиенте, а о том как оптимизировать соотношение затраченные усилия\вознаграждение, и выберет из возможного набора KPI те, которые конкретно ему будет проще, в силу каких-то причин, закрыть с минимальными усилиями при максимальной личной выгоде, причем часто будет оказываться, что цели закрываются не совсем с теми результатами, на какие рассчитывает разработчик KPI. Оставшиеся же показатели будут либо выполнены формально, либо вовсе проигнорированы. Так как для сотрудника не будет иметь ровным счетом никакого значения, на сколько выбранный им показатель важен в конечном счете. Всё что мы увидели, получив систему KPI, так это то, что она отлично стимулирует оставаться посредственностями. Ну и смекалку развивает у сотрудников, это тоже стоит отметить.
dhj:
Как только я перестаю думать о деньгах — я пишу хороший код.
Если же программируя я буду думать о бонусах/малусах — то нафиг такое.
Формальный, автоматический процесс премирования только сподвигнет «сломать систему», писать прямолинейный, не изящный код.
Это как хрущевки/брежневки — вроде жить можно, но нет в таких домах элегантности.
Плюс при всякой возможности искать виноватых в коллегах. А как же коллективная ответственность за продукт? Или как в старом монологе — «к пуговицам претензии есть?», а на остальное — все равно?
Дополнительно для dhj сверх универсального ответа Архону.
Опять телега впереди лошади.
Хорошая система тем и хороша, что если вы хорошо исполняете свою работу (пишете хороший код) — вам не нужно думать о деньгах, потому что хорошие деньги за хорошую работу вы получите автоматически.
И еще раз оговоримся — мы вовсе не считаем собственную схему работу идеальной. Но она, на текущий момент, — лучшая из систем, которую мы своими скромными силами смогли придумать и реализовать. При этом работа по совершенствованию — бесконечна, вне всякого сомнения («кайдзен»).
Да, по поводу “коллективной ответственности” за продукт. Есть сомнения, что автор вопроса правильно понимает смысл этого термина . “Коллективная ответственность” — это когда за преступление одного еврея сжигают всех евреев. За бегство с поля боя одного бойца расстреливают взвод. За косяк одного программиста штрафуют\увольняют всех. А тимбилдинговое бульканье типа “мы команда и вместе отвечаем за все” — это коллективная безответственность. “Тащи с завода каждый гвоздь, ты здесь хозяин, а не гость”.
craft_brother
Сугубо, ИМХО.
Что измеряете, то и получите.
Мне всегда представлялось, что ПО — продукт командной работы. А в командной работе важен общий результат, а не то сколько километров пробежал форвард, сколько ног сопернику переломал защитник и сколько раз прыгал за мячом вратарь. Все это не важно, если команда проиграла.
Вводя индивидуальные KPI вы еще разжигаете конкуренцию и убиваете командную синергию.
Автор вопроса, возможно — случайно, затронул очень интересный вопрос — правильный баланс между локальными оптимумами (сколько ног сопернику переломал) и итоговым результатом (выиграли или нет). Детально в популярном изложении это рассматривается в работах Голдратта.
Правильным балансом является однозначный приоритет итогового результата. В нашем случае — это прибыль. Автоцитата:
СММ строится таким образом, чтобы синхронизировать личные интересы сотрудников и общие интересы бизнеса. То есть сотрудник зарабатывает больше денег вместе с компанией и никак иначе.
Иными словами, мы берем нужный итоговый результат (выигрыш команды) и декомпозируем его на требования к действиям конкретных игроков. А не наоборот.
Кстати сказать, именно “наоборот” исторически характерно для западной управленческой традиции — в этом кроется причина тамошней популярности в общем то, совершенно очевидных тезисов Голдратта, которыми он переворачивает логику с головы на ноги.
Касательно же “разжигания конкуренции” индивидуальными КПЭ — ну а что, собственно, плохого в конкуренции между сотрудниками, например, качеством работы? Это же не игра с нулевой суммой, выигрыш одного не означает проигрыша остальных.
Даже в дремучем СССР пытались такую конкуренцию разворачивать — “соцсоревнования” и “переходящее красное знамя”.
Joshua
Мне кажется, есть четыре проблемы:
1. Есть коллективная ответственность с багами. Должно снижать мотивацию.
2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимость бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.
3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.
4. Если уж идет попытка сделать справедливую стоимость оплаты, в зависимости от пользы компании, то к чему Грейды? Если я младший программист и делаю эту задачу так же хорошо как и старший программист — я должен получать столько же.
- “Коллективная ответственность” с багами применяется только в том случае, когда нет возможности установить автора бага. Возможно (и наверняка) такая практика снижает мотивацию — что плохо.
Однако отсутствие такой ответственности (она у нас не сразу появилась) — влияет на итоговые результаты еще хуже. Благо, нам есть с чем сравнивать.
Собственно, полная аналогия с коллективной материальной ответственностью на складе — легко себе представить, что будет с сохранностью ТМЦ без такой ответственности. Автору ответа, собственно, и представлять не надо — известно из практики. - А не нужно поднимать бревно на 100 метров. Одного метра, скорее всего, вполне достаточно. И вообще (к вопросу п.1), важна не тяжесть наказания, а его неотвратимость.
Оптимальное же значение высоты бревна подбирается из анализа статистики и аккуратного (!), желательно в песочнице, экспериментирования.
“А способ понизить стоимость бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики” — тут, при всем уважении, хочется поерничать. Вы пишете в логике, характерной для внутренних команд разработчиков неспециализированных организаций, сидящих на практически неограниченном бюджете и нелимитированных сроках.
Иначе сложно понять логику, в которой вы понижаете стоимость бага через кратное (!) увеличение регулярной себестоимости рабочего процесса. Причем, как уже говорилось в первой части (“почему у нас нет тестировщиков”) — затраты эти большей частью зряшные.
Более того, на длительной перспективе, при отсутствии персональной мотивации разработчика, приводят к обратному эффекту — качество кода монотонно убывает. - В силу того, что время выполнения задачи не ограничено ничем, разумной добросовестности и согласия заказчика его оплачивать, системных препятствий для рефакторинга нет. По крайней мере, мы их не видим. Напротив, лучший код содержит меньше ошибок и, таким образом, увеличивает доход. Это с одной стороны.
С другой — см. выше ответ Archon’у. - Про справедливую оплату и грейды.
Знаете, “справедливость” — очень плохое слово, единственно пригодное для оболванивания лузеров (типа “общество\государство социальной справедливости” etc) демагогами всех мастей.
Именно под лозунгом справедливости совершались самые отвратительные и массовые зверства в человеческой истории (а история нашей страны — ярчайший из примеров).
Так, например, товарищи из ИГИЛа считают, что было бы в высшей степени справедливым вырезать всех читателей настоящего блога. А Ленин считал, что буржуев справедливее всего вырезать. А Сталин считал, что справедливое состояние мира — когда «последняя Парагвайская социалистическая республика войдет в состав СССР». А Джордж Буш-младший считал, что Саддама справедливо повесить, поскольку он неоднократно пытался устроить покушение на его отца.
А товарищ Кадыров считает, что русские — бессловесное пьяное быдло, справедливая участь которых — собирать и отправлять деньги на беззаботное процветание истинных воинов. А товарищ Путин в целом согласен с товарищем Кадыровым, плюс железно (!) знает, что работать русские не умеют и не хотят, и единственно чем могут прожить, это раздачей нефтяной халявы добрым царем. Причем то, что 100% этой нефтяной халявы оплачивают страшные геополитические враги, развращенные гейропейцы, это тоже более чем справедливо, и картину мира никак не нарушает.
В переводе на русский язык “справедливо” означает “как нравится лично мне”. Не более.
Мы предпочитаем термин «эффективность».
Грейдовая схема — вполне разумна. Как уже говорилось, за “младших программистов” клиенты платят меньше денег. И не просто так — более компетентный и опытный программист сделает задачу за меньшее количество часов при, как минимум, не меньшем уровне качества.
Дискутировать же имеет смысл о качестве настроек параметров в грейдовой схеме — про высоту бревна. Но это выходит, как говорится, за рамки.