Лучшие реализации SCRUM-практик

Всем доброе время суток.

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

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

Начинаем :)

Итак, основные треования к бонусной схеме следующие:

Бонус должен быть командным, а не индивидуальным

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

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

1. Решение о распределении или использовании бонуса принимается только в том случае, если ВСЕ члены команды согласны с решением. Мне кажется, что вариант с большинством голосов в данном случае работать не будет, т.к., например, в случае команды из 10 человек меньшинство — это аж 4 человека, т.е. довольно много. Если у вас совсем нет никаких идей о том, как можно достичь такого всеобщего соглашения смотрите как выбирают папу римского (хотя там требуется 2/3 голосов + 1 голос) :)
2. В случае, если команда решает разделить деньги, то единственный доступный вариант — это просто деление всей суммы бонуса на количество человек. Варианты «я дольше работаю», «это ОН сломал билд», «так она же весь спринт проболела» не принимаются. Обсудите это с командой заранее и см. п. 1
3. Часто случается, что в команде есть отличный специалист и замечательный товарищ, но этот товарищ всегда  работает очень медленно, например потому, что всегда старается сделать свой код идеальным, или потому, что всегда до байта оптимизирует свой код. Во всех придуманных нами схемах есть фактор времени или фактор объема выполненных работ, и в случае, если у вас в команде есть такой человек, могут возникнуть проблемы. Не думаю, что стоит напрямую обсуждать эту тему с командой или с этим человеком. Просто оговорите, что никогда и никто из команды не будет обвинен в срыве релиза или недополучении бонуса. В этом случае виноваты все: товарищ, что делал слишком медленно и слишком идеально, команда, что недосмотрели. Опять же, все должны принять это простое правило. У вас же на ретроспективах никто никого не обвиняет в проблемах, надеюсь?!

Сумма бонуса должна основываться на числах, а не на чувствах

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

Схема расчета суммы бонуса должна быть простой и понятной всем

В нашем случае это означает:

1. На собственно расчет суммы бонуса должно тратиться минимум времени, расчет должен быть прост и очевиден
2. Очень желательно, чтобы сумма бонуса рассчитывалась на основе той статистики и тех данных, которыми команда уже владеет или которую несложно и недолго собирать. Например, бонусные схемы, основанные на количестве написанных строк, количестве возвратов из code review и из QA, количество открытых багов и пр. представляются нам излишне сложными

Бонусы должны начисляться на основе результатов одного спринта

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

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

1. Выставление оценок или принятие решения о сумме бонуса может приниматься исключительно Product Owner'ом, Product Owner'ом и Scrum Master'ом, Product Owner'ом и командой со сравнением результатов и т.д. 
2. Может допускаться обсуждение суммы бонусов в случае, если какая-то сторона считает, что бонус рассчитан неправильно/несправедливо. Да, нам всем нужны деньги, но в данном случае смысл не только в них. Если вы не проводите ретроспективные митинги, или постоянно их откладываете, то бонусы могут быть как раз тем, что вам нужно, потому, что ретроспективы очень важны для постоянного улучшения процесса работы и для обмена мнениями между Product Owner'ом и командой. Проблема, о которой знают все — это уже наполовину решенная проблема
3. Бонусы могут аккумулироваться или выплачиваться сразу после начисления

А теперь переходим непосредственно к возможным бонусным схемам.

Схема, основанная на прибыльности команды

Размер бонуса — это процент от прибыли, полученной от реализации продуктов, реализованных командой. С данной схемой есть несколько проблем:

1. Расчет прибыльности, да еще и каждые 2 недели (длина нашего спринта) может превратиться в большую головную боль
2. Собственно, сам расчет прибыльности не очевиден: кроме команды над проектом наверняка работают менеджеры по продажам, консультанты, служба поддержки, системные администраторы и пр.
3. Реализация схемы может быть проблемой для заказчика, особенно если заказчик не из «цивилизованной Европы», где ежемесячно всем сотрудникам высылается полнейший отчет о финансовых достижениях компании
4. Допускаю, что этот вариант может оказаться меньшим мотивирующим фактором, чем остальные схемы, поскольку команда (если только в ней нет менеджеров по продажам) скорее всего лишь косвенно влияет на чистый доход от проекта. С другой стороны, если команда может активно влиять на ход проекта или на его функционал (например, предлагая собственные идеи), эта схема становится одним из лучших вариантов
5. Допускаю, что этот вариант не лучший для заказчика, т.к. у него нет прямых рычагов стимулирования и мотивации команды

С другой стороны, если возложить расчет суммы дохода на финансовый отдел компании и изменить временной промежуток, за который выплачивается бонус так, чтобы он совпадал по времени, например, с подготовкой ежемесячных отчетов финансовым отделом компании, то схема может оказаться вполне интересной и работоспособной. Например, чистая прибыль компании от реализации продуктов за месяц составила $300000, команда получает 1%, что в данном случае составит $3000 на команду в месяц. Тут возможны подварианты с зависимостью процента, получаемого командой от самой суммы прибыли.

Схема, основанная на уменьшении от максимальной величины бонуса

Допустим, команда договаривается о максимальной сумме бонуса за спринт в $1000. Реальная сумма бонуса рассчитывается по следующей формуле:

$Реальная = $Максимальная * Фактор_1 * Фактор_2 * ... * Фактор_N

В самом простом случае каждый из факторов_N — это дробное число от 0 до 1, оценивающее достижение той или иной цели. Например, у нас есть следующие факторы:

 
• Скорость
 
• Качество
• Объем работ
 
• Дисциплина

Если product owner совершенно удовлетворен скоростью работы команды в течении спринта, то этот фактор становится равным 1, если у него есть лишь небольшие замечания — 0.9, если заказчик скорее недоволен, чем доволен — 0.2 и т.д. Точно также определяется значение для остальных факторов. Для примера, Скорость = 1, Качество = 0.6, Объем работ = 1, Дисциплина = 0.8. Получаем, что командный бонус будет равен $1000 * 1 * 0.6 * 1 * 0.8 = $480.

Мне кажется, что в случае этой схемы, оценки должны выставляться:

1. Product Owner'ом
2. Scrum Master'ом отдельно от команды (особенно если он не принимает непосредственного участия в разработке, т.е. не пишет код)
3. Каждым членом команды

Проблемными и подлежащими дискуссии считаются минимальные и максимальные значения оценок. Возможно, заказчик очень просил команду реализовать данный набор задач и команда сделала это, но пожертвовав качеством и побузев немного :) В таком случае будет честно, если команда сможет обговорить этот вопрос с заказчиком. Но опять же, не для того, чтобы каждый из них получил на $20 больше, а для того, чтобы выявить возможные проблемы в понимании, определении цели и средств проекта и  т.д.

Схема, основанная на удовлетворении нужд заказчика

Какие бы параметры мы не выбирали для расчета, основной задачей является именно удовлетворение заказчика. Вы можете делать все супер быстро и с наивысшим качеством,   но если заказчик при этом все равно остается недоволен (заказчики разные бывают, ага), будет ли это честно, если команда потребует максимальную сумму бонуса? Или, например, команда реализовала все, что ОНА запланировала (никто, кроме команды, не имеет права решать, что войдет в текущий спринт, помним?), но при этом отказалась поработать 2 дня в режиме аврала, хотя это было критично для заказчика.

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

Сама схема проста: заказчик определяет сумму бонуса на основе того, насколько он удовлетворен работой команды и ее результатами. У этого подхода множество минусов, но несомненным плюсом является то, что такой подход может стимулировать диалог между product owner'ом и командой, что, опять же, приведет к высветлению и обсуждению существующих проблем, а значит так или иначе к их решению.

Схема с фиксированной оплатой

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

Еще одним плюсом данной схемы, кроме ее простоты, является возможность для заказчика регулировать финансовые вложения в команду. Если финансы не позволяют заказчику провести очередной пересмотр заработной платы, то данная бонусная схема может быть идеальной. С одной стороны она-таки позволяет повысить доход членов команды при наличии такой возможности, с другой стороны, в случае, если такой возможности нет, лично я предпочел бы потерять бонус, чем члена команды или часть своей заработной платы. Вобщем, такой себе бюджетный вариантик :)

К сожалению, на данный момент это все, на что мы оказались способны. И к сожалению, ни одна из схем в чистом виде не подходит.

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

Всем заранее большое спасибо! До встречи в комментариях :)

Tags: bonus, бонус