Соревнования внутри команды - тот тренд в командах разработки, который я начал замечать в последнее время. Story Points, Bonus Points, рейтинг - все это разные названия, по сути, одного и того же. Общая система заключается в следующем: управленец выбирает какие-то критерии(зачастую - "полезные" часы), после чего начинает делать на этом акцент. То есть постоянно стимулируют рост этого критерия у каждого разработчика, создают списки лучших по критериям, постоянно о них напоминают. Так же поощряет(в основном - в денежном эквиваленте) лучших в этой системе. Однако, с моей точки зрения, эта система имеет ряд проблем, о которых я сейчас и постараюсь рассказать.

Ухудшение остальных параметров в угоду критериям.

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

Враг - это твой коллега.

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

Соревновательный дух - это не про каждого.

Не открою вам Америку, но не все любят соревноваться. Тут работает метод кнута и пряника - кому-то нравится кнут, кому-то пряник, а кому-то - все вместе. Система соревнования может просто не прижиться к организму команды, что повлечет только дополнительные проблемы. Так же на это влияет и возраст разработчиков. Более старые и опытные - более размеренные и осторожные. Молодые и горячие - не боятся ошибок и делают первое возникшее решение. Но коллектив редко состоит из одной возрастной группы. Полагаться на большинство - иногда правильное решение, но тут начнется дискриминация меньшинства. Старички без проблем найдут другую работу, где будут другие ценности, молодые - редко терпят плохое отношение к их идеалам. Таким образом вы просто потеряете ценных сотрудников(а если они не были ценны для вас - тогда почему они все еще в коллективе?).

Всё хорошо в меру

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