Ultima ratio regum
Текст, который будет написан ниже, побужден слайдкастом "Путь овертаймов", подготовленным Сергеем Бережным.
В целом все сказанное в этом ролике звучит вполне убедительно. Но есть одна штуковина в коротком, но емком фрагменте, где Сергей говорит о финансовой компенсации овертаймов по полуторному или двойному тарифу и последующими по завершении фазы отпусками. С учетом КЗОТ-а это, к моему глубокому сожалению, рождает предположение о том, что Сергей не очень знаком с овертаймами со стороны руководителя проекта. А такой вывод не способствует уверенности в том, что тема в слайдкасте раскрыта в полной мере.
Но я пойду дальше сомнений.
Начнем с того, что попробуем ответить на вопрос: овертайм - это плохо или хорошо? Казалось бы, что ответ очевиден. Команда, выходящая в овертайм на протяжении двух и более недель подряд действительно демотивируется, действительно снижается эффективность ее работы, а Заказчику в общем случае по-большему счету все равно, что там происходит с командой. Ему нужен продукт к конкретной дате в рамках конкретного бюджета. И даже если Заказчик умный (как это рассмотрено в слайдкасте) и понимает все недостатки овертаймов, его желание получить продукт в срок и в рамках обозначенного бюджета это никак не отменяет.
Ведь для Заказчика система, которую пишет команда, является инструментом достижения целей. А ложка хороша к обеду. Поэтому если ложка к обеду не поспевает, возникает потребность либо сдвинуть время обеда, либо форсировать ее доставку. Когда время обеда дальше двигать некуда, возникает потребность овертайма. В связи с этим мне лично сложно сказать, овертайм - это хорошо или плохо.
В слайдкасте рассмотрены только негативные моменты, связанные с овертаймом. Основными, как я понял, названы снижение эффективности работы команды, усталость и потери, связанные с компенсацией переработок. Тему про удорожание продукта я не буду рассматривать, поскольку мне пока ни разу не приходилось делать проекты без оговоренных границ бюджета. В остальном все верно.
Но если посмотреть с другой стороны, то что мы увидим? У Заказчика есть потребность в срок получить необходимый функционал. Если он, этот функционал, нужен по зарез, то начинается давление на Разработчика о необходимости поставить его в срок. Еще хуже, если срок сдвигается к нам. Но мы ведь не хотим потерять Заказчика? На дворе не шоколад, за новые проекты приходится биться. Потеря хорошего (в плане финансово выгодного) Заказчика оборачивается простоем команды, сокращением прибыли компании и, как следствие, урезанием бонусных фондов и снижением темпа роста заработной платы. Можно конечно сказать, что люди уйдут в другую компанию и т.п. Но ведь кто-то останется и о них тоже надо думать.
Выходит, что иногда возникают ситуации, когда надо вваливать больше и сильнее. Причем в основном потому, что это надо в первую очередь нам самим. Но ведь и сказанное в слайдкасте справедливо. Овертайм действительно убивает всякое желание работать.
А вывод отсюда получается буквально следующий: овертайм - это злой неприятный инструмент, которым иногда приходится пользоваться. Но, как и любой другой инструмент, он может быть эффективным, а может быть неэффективным. Он может принести проекту пользу, а может покалечить людей. Все зависит от того, умеет ли менеджер им пользоваться.
Соответственно я не согласен с выводом слайдкаста. Далеко не всегда менеджер виноват в овертайме. Но он всегда виноват в тех последствиях, которые овертайм приносит в команду.
В целом все сказанное в этом ролике звучит вполне убедительно. Но есть одна штуковина в коротком, но емком фрагменте, где Сергей говорит о финансовой компенсации овертаймов по полуторному или двойному тарифу и последующими по завершении фазы отпусками. С учетом КЗОТ-а это, к моему глубокому сожалению, рождает предположение о том, что Сергей не очень знаком с овертаймами со стороны руководителя проекта. А такой вывод не способствует уверенности в том, что тема в слайдкасте раскрыта в полной мере.
Но я пойду дальше сомнений.
Начнем с того, что попробуем ответить на вопрос: овертайм - это плохо или хорошо? Казалось бы, что ответ очевиден. Команда, выходящая в овертайм на протяжении двух и более недель подряд действительно демотивируется, действительно снижается эффективность ее работы, а Заказчику в общем случае по-большему счету все равно, что там происходит с командой. Ему нужен продукт к конкретной дате в рамках конкретного бюджета. И даже если Заказчик умный (как это рассмотрено в слайдкасте) и понимает все недостатки овертаймов, его желание получить продукт в срок и в рамках обозначенного бюджета это никак не отменяет.
Ведь для Заказчика система, которую пишет команда, является инструментом достижения целей. А ложка хороша к обеду. Поэтому если ложка к обеду не поспевает, возникает потребность либо сдвинуть время обеда, либо форсировать ее доставку. Когда время обеда дальше двигать некуда, возникает потребность овертайма. В связи с этим мне лично сложно сказать, овертайм - это хорошо или плохо.
В слайдкасте рассмотрены только негативные моменты, связанные с овертаймом. Основными, как я понял, названы снижение эффективности работы команды, усталость и потери, связанные с компенсацией переработок. Тему про удорожание продукта я не буду рассматривать, поскольку мне пока ни разу не приходилось делать проекты без оговоренных границ бюджета. В остальном все верно.
Но если посмотреть с другой стороны, то что мы увидим? У Заказчика есть потребность в срок получить необходимый функционал. Если он, этот функционал, нужен по зарез, то начинается давление на Разработчика о необходимости поставить его в срок. Еще хуже, если срок сдвигается к нам. Но мы ведь не хотим потерять Заказчика? На дворе не шоколад, за новые проекты приходится биться. Потеря хорошего (в плане финансово выгодного) Заказчика оборачивается простоем команды, сокращением прибыли компании и, как следствие, урезанием бонусных фондов и снижением темпа роста заработной платы. Можно конечно сказать, что люди уйдут в другую компанию и т.п. Но ведь кто-то останется и о них тоже надо думать.
Выходит, что иногда возникают ситуации, когда надо вваливать больше и сильнее. Причем в основном потому, что это надо в первую очередь нам самим. Но ведь и сказанное в слайдкасте справедливо. Овертайм действительно убивает всякое желание работать.
А вывод отсюда получается буквально следующий: овертайм - это злой неприятный инструмент, которым иногда приходится пользоваться. Но, как и любой другой инструмент, он может быть эффективным, а может быть неэффективным. Он может принести проекту пользу, а может покалечить людей. Все зависит от того, умеет ли менеджер им пользоваться.
Соответственно я не согласен с выводом слайдкаста. Далеко не всегда менеджер виноват в овертайме. Но он всегда виноват в тех последствиях, которые овертайм приносит в команду.