Следует ли платить деньги в качестве мотивации тестировщикам и разработчикам за обнаружение и создание ошибок?

Я прочитал идею о повышении производительности в компании. Это было так:

Имейте определенный фонд, который будет бонусом. Скажем, 100 000 долларов. За каждую обнаруженную ощутимую ошибку тестировщики получают 5-15 долларов. Все, что осталось в конце месяца/года, идет разработчикам.

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

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

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

Основная идея здесь заключается в том, что лучше соревноваться с командой, чем сотрудничать. И нет, даже если вы игнорируете практические проблемы этого плана, это прямой путь к провалу.
Это мотивирует обе команды работать усерднее. Они получают вознаграждение за то, что делают свою работу лучше.
@TobiAlafin посмотрите видео, на которое я дал ссылку в своем ответе, чтобы понять, почему оно их совсем не мотивирует. Одни только деньги — ужасный мотиватор, несмотря на то, что многие думают.
может быть, для первого забега, тогда я буду сидеть там, зная, что мой коллега получил огромную премию, а я нет, хотя мы работали одинаково усердно, это не улучшит мой моральный дух.
Я проголосовал за вопрос, потому что это действительно важная концепция. Но, пожалуйста, прислушайтесь к совету всех этих респондентов, у которых много разного опыта и опыта, и все они согласны с тем, что это идея со МНОЖЕСТВОМ вредных побочных эффектов, которые могут иметь гораздо более негативные последствия, чем любая польза, которая может прийти. от него.
Баг — это решимость. Вы считаете, что программное обеспечение ведет себя неким «неправильным» образом и это важно для бизнеса. В действительности может оказаться, что то, что вы думаете, неправильно или нормально, потому что это не влияет на потребности бизнеса. Чтобы доказать и то, и другое, нужно пройти долгий путь, и если замешаны деньги, будут окопные войны. Разработка новых функций будет остановлена ​​из-за страха. Люди A и A+ скоро уйдут.
В Daily WTF есть отличная история о чем-то похожем на это, и вы можете увидеть, что произошло: Черный рынок дефектов.
Этот вопрос как бы показывает пределы ультраконкурентного мышления.
Ааааа геймификация разработки и отладки! Играйте во что угодно, и люди начнут в нее играть, манипулировать ею, обманывать, взламывать, обыгрывать ее...
@FixedPoint и QA/разработчики, как правило, ХОРОШИ в играх. Обычно лучше, чем менеджеры, устанавливающие правила игр...
Какая мотивация у программистов для исправления ошибок? Как только ошибка отмечена как ошибка, ее безопаснее НЕ исправлять - мы не будем добавлять новую ошибку, а деньги все равно будут потеряны.
С какой стати использовать решение с нулевой суммой? По крайней мере, найдите решение с положительной суммой (баллы за программное обеспечение, прошедшее проверку клиента). Имея это в качестве основы, вы можете подумать о том, как правильно распределить выгоды.
Я решил принять ответы, которые я видел, и я отказался от этого как от идеи, которую буду использовать в будущем. Видео Эрика убедило меня.
Обязательная ссылка на Дилберта: dilbert.com/strip/1995-11-13
Именно такой сценарий случался в истории (не помню где), но проще говоря, когда разработчикам платили за каждую исправленную ошибку. Это привело к тому, что разработчики создали и исправили огромное количество «ошибок».
Вместо денег как насчет того, чтобы использовать что-то глупое и тривиальное, например, кексы?
Как насчет ситуации, когда разработчик находит ошибку и исправляет ее, но она все равно попадает в Jira или Bugzilla, чтобы отдел контроля качества знал, что ее нужно протестировать? Эта идея слишком черно-белая и слишком «мы против них».
Кексы вообще будут работать?
По моему опыту, кексы будут работать значительно лучше, если идея вообще сработает. Это потому, что он продвигает дружескую компетенцию, в которой одна сторона может ткнуть другой в лицо, не будучи ужасными ужасными людьми. У него есть потенциал, чтобы пройти как товарищеский турнир, а не, скажем, как голодные игры. Ключевое слово потенциал. Если вы планируете стать менеджером, вам крайне необходимо понять разницу.
@Jeff: у кексов тоже есть проблемы, особенно если команда тестирования находит много ошибок. Начальный диабет, закупорка артерий, больные колени (о, откуда я знаю про больные колени!), и т.д., бла. Не делай этого! Просто пришлите МНЕ кексы, и я позабочусь о них для вас. Это для твоего же блага... :-)
Классический Дилберт . Да, правильно - я выпишу себе минивэн!
@BobJarvis, да, я никогда не думал об этом в таком ключе. Отправка кексов на 100 000 долларов прямо сейчас. Если серьезно, я был в командах, которые делали что-то подобное (на самом деле это были отдельные члены команды, которые покупали пончики другой команде, если они справлялись лучше, чем мы). Это работало очень хорошо, пока мы не начали передозировку сахара...
google.com/search?q=dilbert+write+me+a+minivan , когда ваша идея точно из мультфильма Дилберта…
Лично, если бы вы наложили на меня эту систему, я бы начал делать ставки на то, кто будет драться на стоянке и как скоро. Это просто самый глупый план, о котором я когда-либо слышал.
Это рецепт катастрофы. Единственная ситуация, в которой я вижу, что это может работать, — это ситуация, когда спецификации на 100 % написаны, на 100 % обновляются всякий раз, когда принимается решение о малейших изменениях в проекте, и на 100 % пригодны для точного определения ожидаемого поведения кода. разные контексты. Если ситуация не такая (а обычно это не так), вы теперь будете смотреть на непрерывные споры о том, является ли это ошибкой или нет. Или, другими словами, теперь тестировщики (финансовые!) заинтересованы в том, чтобы разработчики делали ошибки, а разработчики заинтересованы в том, чтобы тестировщики пропускали ошибки.
Бонус за производство ошибок? ПОДПИСЫВАТЬСЯ!!!
Новое название «бонус за создание ошибок» не имеет особого смысла.
Ржунимагу. Я не тот, кто изменил его.

Ответы (11)

Я прочитал идею о повышении производительности в компании. Это было так:

Имейте определенный фонд, это будет бонусом. Скажем, 100 000 долларов. За каждую обнаруженную ощутимую ошибку тестировщики получают 5-15 долларов. Все, что остается в конце месяца/года, идет разработчикам.

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

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

(Я съеживаюсь, когда читаю такие «мотивационные» схемы.)

Возможно, автор этой идеи определяет «производительность» иначе, чем я.

Цель большинства компаний, производящих программное обеспечение, состоит в том, чтобы зарабатывать деньги и, возможно, максимизировать сумму денег, которую они зарабатывают. Цель системы Bug Bounty менее ясна и, конечно же, не имеет ничего общего с производительностью. Много времени будет потрачено на то, чтобы получить бонусные деньги, и мало времени будет потрачено на то, чтобы отправить программное обеспечение (именно так компания зарабатывает деньги).

Представьте себе компанию с одним разработчиком и одним тестировщиком.

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

Я работал в компании, которая вознаграждала разработчиков похвалой, а не деньгами, и именно такую ​​стратегию использовал один разработчик. Билды отправлялись в QA каждые 2 недели. И каждую вторую пятницу у нас было собрание всей команды, на котором объявлялось количество ошибок в текущей сборке. Если у разработчика никогда не было ошибок, его выделяли и хвалили за отличную работу.

Один разработчик решил обыграть систему. Она откладывала сборку (всегда имея разумные причины) вплоть до еженедельной встречи. Затем она выпустила сборку, был запущен отчет о количестве ошибок, и «волшебным образом» у нее было нулевое количество ошибок как раз к встрече.

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

В настоящее время я работаю в магазине, который наказывает разработчиков за количество ошибок, связанных с их работой во время проекта. Ожидается, что они «улучшат» количество ошибок по сравнению с предыдущим годом. Это часть их MBO и часть того, что входит в их ежегодную выплату бонусов.

Неудивительно, что им потребовалось много времени, чтобы создать первую тестируемую сборку для контроля качества. И попросили QA потратить много времени на тестирование в среде Dev (где нельзя писать баг-репорты). Им были даны все возможности производить меньше ошибок в системе отчетности и, следовательно, максимизировать свой бонус.

Менеджер по продукту даже решил изменить многие отчеты об ошибках на «запросы на улучшение», чтобы не влиять на MBO разработчиков. Его аргумент был таков: «Ну, разработчики еще не полностью разработали эту функцию, поэтому они улучшат ее, когда у них будет время».

Если бы мне платили «за ошибку», я мог бы довольно легко найти массу ошибок, независимо от того, насколько хорош разработчик. (Я занимаюсь этой работой почти 30 лет). Сначала я бы сосредоточился на низко висящих фруктах и ​​​​пропустил все, что отнимало бы много времени. Мои отчеты об ошибках будут минимальными и не очень полезными — в основном все, что потребуется, чтобы ввести отчет об ошибке в систему и получить деньги.

Результатом было бы множество поверхностных отчетов об ошибках, которые были бы «достаточно осязаемы», и программное обеспечение неизбежно осталось бы с некоторыми серьезными критическими ошибками. Я не могу представить, что система когда-либо будет выпущена.

Разработчики сосредоточат все свое время и внимание на новом коде. Исправление уже обнаруженных ошибок не принесет абсолютно никакой финансовой выгоды. И у них будет стимул выпускать крошечные, незначительные релизы. Если они выпускают релиз, содержащий только одну строку идеального кода, они получают бонус в размере 100 тысяч долларов! Зачем вообще добавлять какие-то хитрые функции?

Обе команды яростно спорили о каждом отчете об ошибке и о том, действительно ли это была «осязаемая» ошибка или нет. (Это красивый и нечеткий термин. Я хотел бы услышать, как команда попытается дать ему конкретное определение). Такого рода аргументы не подготавливают почву для того, что я бы назвал продуктивностью.

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

И эта последняя часть имеет большое значение. Для работников умственного труда часто прикрепление денежных премий к задачам, которые они считают важными, является большим сдерживающим фактором. Если вы хотите лучше понять виды дисфункций, которые могут возникнуть из-за такого рода систем стимулирования, я настоятельно рекомендую вам прочитать «Измерение и управление эффективностью в организациях» Роберта Д. Остина.

Короче говоря, это ужасная идея.

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

«Запросы на улучшение» — хороший момент здесь — как разработчик, если вы вычитаете деньги из моей оплаты за каждую ошибку, в моих интересах бороться зубами и когтями за спецификацию: «в истории никогда не упоминалось поле «Дата рождения». не может быть в будущем. Это не ошибка, это дополнительная история». В дополнение к вознаграждению разработчиков за то, что они работают медленнее и менее полезны команде контроля качества, вы также стимулируете их игнорировать здравый смысл и требовать, чтобы все документировано владельцем продукта/аналитиком в N-й степени.
Вдобавок ко всему этому, я могу себе представить, что за пределами офиса разработчиков будет висячий столб для любого, кто посмеет рефакторить старый код, оставив кодовую базу в полном беспорядке, потому что «Если это не содержит ошибок, даже не пытайтесь потрогай это!"
«Один разработчик решил обыграть систему». - Протест через "големный труд" или просто в похвалу? В любом случае, я думаю, что она гений, и хотел бы найти способ побудить ее быть на моей стороне.
Хотя установка, описанная в OP, действительно довольно ужасна, реальная, правильная награда за ошибку может быть в порядке. Однако создание враждебной конкуренции между разработчиками и QA не является надлежащим вознаграждением за обнаружение ошибок. Лучший способ сделать это — просто наградить тестировщиков QA бонусом за каждую найденную ошибку. И, возможно, также ваших разработчиков за каждую обнаруженную ошибку, которую они исправляют.
@aroth - Сегодня днем ​​я выпишу себе новый минивэн! dilbert.com/strip/1995-11-13 (будьте осторожны с тем, за что вы платите - вы не получите того, на что рассчитывали)
@WorkerDrone - достаточно честно. Хотя «будьте осторожны, не нанимайте коррумпированных/неэтичных разработчиков» кажется столь же правдоподобной интерпретацией.
Я думаю, что @aroth был прав со своими замечаниями. Хотя ОП вряд ли справится с его настройкой, это можно было бы оформить лучше. Даже комментарии к этим сообщениям могут быть легко удалены с помощью простой структуры (например, только основные/критические ошибки получают вознаграждение, только ранее существовавшие ошибки, и это не делает соревнование между разработчиками и тестировщиками).
Дата рождения может быть в будущем. Очевидный случай, когда дата рождения оценивается, это может быть 8 месяцев в будущем. Менее очевидный случай, когда мать пересекает линию даты точно в нужном направлении в нужное время, дата рождения (которая является текущей датой в то время и в том месте, где родился ребенок) может быть «на следующий день». "после пересечения линии перемены дат. Или проще, родить сразу после полуночи в одном часовом поясе, а затем переехать незадолго до полуночи предыдущего дня в другом часовом поясе.

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

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

Это просто не приходит мне в голову. Никогда не пытайтесь мотивировать программистов и тестировщиков деньгами, это просто ужасно. Их работа основывается на внутренней мотивации.

Кроме того, взгляните, пожалуйста, на этот анимированный TED-выступление о драйве и мотивации, так как он намного лучше объясняет, почему любая установка, включающая мотивацию умных людей деньгами, потерпит крах:

https://www.youtube.com/watch?v=u6XAPnuFjJc

+1 Я думаю, также стоит отметить, что вы находитесь на рынке разработчиков и конкурируете с другими фирмами. Отрицательные внешние эффекты этого предложения приведут к ситуации, когда хорошие разработчики уйдут, а лимоны останутся. QA будет доволен, так как изменение состава по качеству инженеров-программистов приведет к большим бонусам для них по этой схеме. Это одна из самых разрушительных идей, с которыми я сталкивался.
+1 Это, вероятно, вызовет враждебность среди команды, которая может выйти за рамки технической команды и QA. Разработчики будут спорить о том, кто внес ошибку и является ли она ошибкой в ​​первую очередь или, возможно, результатом плохо написанной спецификации, плохого дизайна и т. д.
Я посмотрел видео (сеть была плохой, так что это заняло некоторое время). Я был полностью продан на нем. Достаточно сказать, что это вызвало еще один вопрос.
Аргумент о сговоре вполне реален. Я читал о случае, когда разработчики предоставили тестировщикам несколько крутых лазеек и предостережений, они разделили бонусы. Я думаю, что схема была обнаружена, потому что они становились слишком большими, слишком часто, т.е. супер скрытые ошибки начали появляться и обнаруживаться с подозрительной скоростью.
«QA начнут сообщать о всевозможных вещах, которые на самом деле хороши, но могут быть истолкованы как «глючные»». Сотрудники QA, где я работаю, в любом случае делают это. Половина «ошибок», обнаруженных QA в моем проекте, — это советы по дизайну («Поместите счетчик загрузки на эту страницу»), исправления грамматики (которые обычно неверны) и вещи, которые работают, как задумано, но не в соответствии с ожиданиями QA. Несколько раз из-за этого мы почти упускали из виду ошибки, которые могут привести к концу света. Если бы им платили за это бонусы, они бы завалили нас фальшивыми мусорными жуками.
@JoeStrazzere Не хватает шага. Команда QA также будет лишена людей, которые ценят качество выше вознаграждения. Остальные члены QA будут довольны ситуацией, так как они получают более низко висящие плоды, что означает для них больше денег.
@Torisuda: Хотя, к сожалению, специалисты по обеспечению качества ошибаются в вопросах грамматики, я, безусловно, считаю ошибки (орфография, грамматика и т. д.) в тексте пользовательского интерфейса проблемами качества, которые необходимо выявить на каком-то этапе процесса обеспечения качества.
Вот, возможно, правдивый анекдот о такой ситуации: thedailywtf.com/articles/The-Defect-Black-Market .
@Torisuda, QA интерпретирует требование иначе, чем разработчики, является явным признаком того, что требование неверно. Однако это всегда означает, что нужно проконсультироваться с людьми, выдвинувшими требование, о том, какая интерпретация является правильной, и тогда предпринятые действия будут зависеть от этого ответа. Это действительная ошибка, которую нужно поднять, и ее никогда не следует отбрасывать, это правильный путь. Я видел много спасенных проектов, потому что это несоответствие в том, что имелось в виду, было поднято, и QA на самом деле был прав в отношении того, что означало требование. Я всегда благодарен, когда QA поднимает такую ​​​​ошибку.
@HLGEM: хорошо, если QA уловит это, но намного лучше, если будет достаточно общения, чтобы разработчики поняли это до того, как создадут его :)
Да, я согласен, что многим, если не большинству, разработчикам нужно больше разговаривать с пользователями/стейкхолдерами/ассистентами при проектировании и не допускать такого рода неверных интерпретаций, но я видел, как слишком многие принимают требование за чистую монету, никогда не задавая соответствующих, даже очевидных вопросов. , вопросы. Кроме того, отчасти причина для QA состоит в том, чтобы кто-то с другой точки зрения посмотрел на то, как все было сделано. Вот почему заставлять разработчиков самостоятельно заниматься контролем качества — плохая идея. Именно эти вещи разработчик никогда не найдет, потому что он знает, что, по его мнению, требуется.
@HLGEM Мы привлекаем зарубежную фирму по обеспечению качества, поэтому персоналу по обеспечению качества не хватает многих знаний в предметной области и контекста; по этой причине их интерпретация редко бывает правильной, хотя объяснение им иногда помогает мне самому лучше понять требование.
@Torisuda, когда ты сделал свой первый комментарий, это было первое, о чем я подумал. Из тех раз, когда я видел, как это пытались, я пришел к выводу, что не стоит иметь QA за границей. Это действительно то, что вы должны иметь дома.
Или вы можете попробовать предоставить им знания предметной области. Это то, что мы сделали с нашим зарубежным QA. Мы потратили деньги, чтобы привезти пару их старших сотрудников сюда на пару месяцев для обучения. Это принесло огромные дивиденды.
Да, по крайней мере, у них должно быть отличное знание предметной области. И хорошее понимание родного языка приложения. Без этого вы не можете быть хорошим QA.
@Erik По моему опыту, я согласен, что было бы намного лучше иметь собственный контроль качества. К сожалению, эта система существовала задолго до того, как я начал работать, и, вероятно, будет действовать еще долго после того, как я уйду. У них неплохое знание английского языка, но есть диалектные различия, которые вызывают некоторую путаницу, и их знание предметной области неплохое, но есть пробелы, которые нелегко исправить, поскольку они находятся за границей.
@HLGEM Это хорошая идея. Я не думаю, что у нашей компании есть ресурсы для этого, но я мог бы попробовать это сделать. Даже несколько видеочатов с ключевыми людьми могут помочь.

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

Я отказываюсь иметь антагонистические отношения со своими тестировщиками. Я ценю их. Они делают меня лучшим кодером.

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

Творческая работа не лучше всего мотивируется деньгами. Его лучшими мотиваторами являются:

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

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

QA — это творческая работа. Задача действительно состоит в том, чтобы придумать то, о чем не подумали разработчики. Вот почему QA должен автоматизировать. Однажды придуманный тест не следует «ставить» снова и снова, как бродвейскую пьесу. Это должно быть автоматизировано, чтобы QA мог перестать думать об этом и подумать о следующем тесте. QA должен быть заполнен вашими самыми талантливыми разработчиками. Потому что они пытаются перехитрить другую команду разработчиков.

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

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

Мы не делаем бессмысленную работу здесь.

Имейте определенный фонд, это будет бонусом. Скажем, 100 000 долларов. За каждую обнаруженную ощутимую ошибку тестировщики получают 5-15 долларов. Все, что остается в конце месяца/года, идет разработчикам.

Это ужасно. По всем причинам в других ответах и ​​из-за того, что он не проходит этот очень простой тест:

  • Что, если все ваши сотрудники молодцы, а багов не обнаружено?

    Производство работает отлично и все деньги пойдут в DEVS

  • Что делать, если все ваши сотрудники дерьмо?

    Производство просто сгорело дотла из-за багов, но эй, какая разница, деньги пойдут разработчикам.

Даже если бы деньги были мотиватором в нашем бизнесе, это было бы ужасно неправильно.

Возьмите деньги и наймите кого-нибудь, кто действительно хорош в написании спецификаций и планировании проектов с выполнимыми сроками. И DEV, и QA будут счастливее, чем любые деньги, которые они когда-либо могли сделать.

Хороший момент, чтобы предложить альтернативные варианты использования фонда в 100 000 долларов. Вероятно, есть несколько других вариантов использования этих больших денег, чтобы сделать команду разработчиков и QA более продуктивной. Хотя я думаю, что начинать мозговой штурм с ними было бы не по теме.
«Производство просто сгорело дотла из-за ошибок, но эй, какая разница, деньги пойдут разработчикам». - теоретически это стимул для QA работать лучше, потому что им будут платить за то, что они не позволят производству сгореть дотла.

Это может быть апокрифом, но мне дали подобный пример в 1980-х годах, когда я освещал «Закон непреднамеренных последствий» в рамках курса BPR.

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

Чистый эффект заключался в том, что служба контроля качества отбраковывала больше продуктов, чем раньше, а производство «идеальных» изделий занимало больше времени, поэтому общий объем производства снизился, а затраты выросли из-за поощрительных выплат. Качество не пострадало.

Это работает плохо. Я не видел этого с разработчиками и тестировщиками. Но министерство юстиции Новой Зеландии в какой-то момент периодически награждало надзирателей за каждого задержанного, которого они нарушили. Это произошло от одного нарушения в плохую неделю до того, что некоторые задержанные получили по 6 нарушений в день и оказались в тюрьме из-за этого. В итоге пострадал надзиратель.

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

Я понятия не имею, что значит изнасиловать задержанного.
Я предполагаю, что «нарушить задержанного» означает «сделать официальную запись о том, что задержанный нарушил правило».
@emory Насколько я понимаю, это была официальная запись, и если задержанный получал 3 в рамках своего приговора, его арестовывали, доставляли обратно в суд и повторно приговаривали к тюремному заключению.

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

Вы пытаетесь привязать деньги к тому, что в конечном счете указано на бумаге. Это число не создаст никаких денег. Что еще хуже, число, которое вы хотите использовать, в основном случайное: продукт, в котором никогда не было ошибок, внезапно имеет 50, и все они опечатки в документации. Ошибка, которая искажает цвет выделения 200 элементов, становится 200 ошибками. Как только вы попросите кого-нибудь заставить число волшебным образом увеличиться, это число станет совершенно бесполезным воображаемым числом. И вдобавок ко всему вы потратите десятки тысяч долларов в виде заработной платы на абсолютно бессмысленные встречи, где люди спорят о том, что является ошибкой, а что нет.

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

Как было сказано в комментариях к вашему вопросу, некоторые формы геймификации могут работать. Как насчет присуждения трофея за «Лучшую ошибку», найденного за определенный период, присуждаемого голосованием обеих команд вместе ?

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

Трофей должен быть чем-то очень простым, потому что речь не идет о его внутренней ценности: маленькая табличка, кекс, плитка шоколада.

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

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

Игра против этой системы может быть чрезвычайно легкой.
Для разработчиков: поздние сборки. Для тестировщиков: концентрация на тривиальных ошибках.
При поздних сборках раннее тестирование невозможно. Мало времени для тестирования и удовлетворения количества ошибок? Тестировщики концентрируются на тривиальных ошибках, таких как орфографические ошибки или некоторые некритические случаи.
Если вы хотите знать, хорош ли продукт, просто спросите своего клиента.

Короче говоря. Разработчики и тестировщики работают на одной лодке — в вашей компании.

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

Если ошибка попала в окончательную сборку, и клиент сообщил об этом, кого следует винить? Разработчик за то, что написал баг, или тестировщик за то, что не отловил?

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

Если у вас дружественное рабочее пространство и вы хотите вознаградить всех за отлов ошибок, разделите бюджет по справедливости, составьте список разработчиков, и за каждую ошибку разработчик будет платить 1 доллар в банк. Организуйте рождественскую вечеринку и используйте банк, чтобы вознаградить всю команду. Убедитесь, что это веселее, чем награда/наказание, и что никто не воспринимает это (слишком) серьезно. Награждайте как «худших», так и «лучших» среди разработчиков и тестировщиков.

Честно говоря, стимул в лучшем случае кажется бесполезным, а в худшем — вредным. Если у вас есть преданная команда QA, вы уже выделили средства на поиск ошибок, поскольку это будет большой частью их должностных обязанностей. Между ними не будет большого дополнительного антагонизма, так как будет больше отношения к самой политике. Если вы на самом деле настолько обеспокоены этой проблемой, что бросаете деньги своим нынешним сотрудникам с определенными условиями, было бы лучше нанять кого-то, кто вам нужен, либо в QA, либо в dev.

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

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

Но меньше им не платят. Я не вычитаю их оговоренную зарплату. Я даю им премию в зависимости от того, сколько ошибок отсутствовало в их коде. Если более длительные периоды проверки означают немного лучшее качество, то почему бы и нет. Тем не менее, должны быть установленные политикой временные рамки для проверки.
@TobiAlafin: Им платят меньше, чем если бы ошибок не было обнаружено. Человеку свойственно думать об этом как о потере.
Следует ли платить деньги в качестве мотивации тестировщикам и разработчикам за обнаружение и создание ошибок?
СпросиСетьПолитика конфиденциальности1y, 0v