Теория Y гласит, что люди в принципе высокомотивированы на достижение результатов и сама работа приносит им удовольствие. Опять же всем нам знаком типаж людей с большой самомотивацией. У них и вокруг них всегда кипит работа (передаю привет моей команде), они успевают за день сделать не одно дело, и их производительность труда намного выше среднего.
Необходимо внимательно следить за мотивацией своей команды, четко понимать, чего она ожидает, поддерживать каждый успех и внимательно следить за инициативами, чтобы они не пропадали, а реализовывались. Управлять лучше по отклонениям, не сильно наседая. При осуществлении контроля в данном случае необходимо ставить четкие цели и добиваться, чтобы команда их понимала и разделяла.
Обычно руководитель работает на стыке обеих теорий, используя тот или иной подход в зависимости от ситуации. В общем случае надо стараться работать по принципу теории Y, зажигая людей, в крайнем – прибегать к методам теории X, четко объясняя, в чем именно проблема.
Для работы в рамках Scrum команда должна состоять в основном из людей, которые больше соответствуют теории Y, иначе команда не будет самоорганизованной и эффективной.
Скажи, как ты будешь измерять мою эффективность, и я скажу, как я буду себя вести.
Э. Гольдратт
Самые важные вещи нельзя измерить.
У. Деминг
Чтобы узнать, посолен ли борщ, достаточно опустить в него два электрода, а затем пустить по ним ток. Если появится запах хлора, значит, борщ уже посолен.
В физике есть такое понятие, как эффект наблюдателя: если над системой ведется наблюдение, оно вносит изменение в ее поведение. Очень интересно этот эффект проявляется в организации работы команд разработчиков (да и в любых производственных процессах). Как только мы начинаем считать любые метрики, мы вносим изменения в поведение команды и отдельных ее членов.
С точки зрения управления мерить в численном виде (вводить метрику) – идея, на первый взгляд, очень здравая. Мы получаем точные данные и на их основе производим необходимые действия. Однако, к сожалению, не все так просто: как только мы вводим метрику, поведение команды начинает меняться. Команда и каждый ее член начинают подстраиваться под введенную нами метрику.
Далеко за примерами ходить не надо. Все знают понятие «индусский код»: как только разработчикам начинают платить за количество написанных строчек кода, они начинают писать больше кода, зачастую бессмысленного, забывают о рефакторинге, так как его делать становится невыгодно, и т. д. Таким образом, наше начинание по замеру производительности оборачивается против нас.
