Редко кто из программистов не сталкивался с таким явлением как переработки. В этой статье попробуем поразмышлять о них и их влиянии на рабочий процесс, его результат и самого программиста.
Переработка (овертайм (англ. overtime)) – это, согласно толковому словарю Ушакова, время проработанное сверх установленной нормы. Или по-другому сверхурочная работа.
Почему же возникает необходимость работать, например четырнадцать часов вместо восьми, выходить в выходные, отпуска и т.д.?
На самом деле это обусловлено одной из трёх причин или их комбинацией (такое, к сожалению, тоже бывает).
Причины переработок
Первая причина почему приходится трудиться сверхурочно это форс-мажор.
Как и любое другое техническое решение, софт и аппаратное обеспечение, на котором он работает не застрахованы от сбоев, ошибок, поломок и т.д. Но, самое печальное ни программа, ни сервер/компьютер/мобильное устройство/etc не будут ни у кого спрашивать, когда им «зависнуть», сломаться и т.п. Подобные события просто происходят и тогда их нужно просто устранять.
Случается, что нужно подменить заболевшего коллегу, да и мало ли что бывает в этой жизни?..
Утешает то, что форс-мажоры как правило возникают довольно редко.
Следующие причины переработок являются уже скорее не превратностями судьбы, а «творением рук человеческих».
Вторая причина переработок — это некомпетентность менеджмента.
Как говорится, у плохих генералов всегда много героев. Не выстроенные должным образом процессы, необоснованно сжатые сроки и прочие издержки неграмотного планирования и т.д. За всё это фактически приходится «отдуваться» программисту.
И наконец последняя причина сверхурочных «подвигов» программиста – это он сам.
Трудоголизм, проблемы с тайм-менеджментом, наконец банальный недостаток квалификации вполне могут воспрепятствовать завершению работы в положенное время.
Влияние переработок
Переработки могут дать кратковременный положительный эффект, как форма концентрации усилий человека для решения поставленной задачи, но в целом их влияние только отрицательное.
Любая сверхурочная работа отнимает у человека не только дополнительные силы, но и время на их восстановление (в то время, когда вам положено отдыхать, вы работаете). В случае единичных «авралов», организм со временем восполняет понесённый урон и это ощущается почти не заметно. Однако регулярные переработки рано или поздно неизбежно вызывают вполне очевидные последствия.
Вследствие накопившейся усталости падает работоспособность, ухудшается внимание и мыслительные способности. Как закономерный результат снижается не только объём выполняемой работы, но и в первую очередь её качество.
Если не принять своевременных мер хотя бы по возвращению к нормальному режиму труда и отдыха программист со временем переходит в аутсайдеры, попутно утягивая за собой туда проект и компанию. Следом наступит выгорание (возможно даже с определёнными последствиями для здоровья).
Также стоит отметить, что если программист перерабатывает, он будет медленнее развиваться как профессионал, т.к. на то, чтобы почитать книги или поупражняться в чём-нибудь за пределами «офиса» будет оставаться меньше времени или его не будет оставаться вовсе.
Как следует из вышесказанного, от переработок страдают не только сами программисты, но и их заказчики и работодатели. И здесь особенно интересна позиция компаний, в основе бизнеса которых положены такие принципы, как «результат любыми средствами», «выкладываться на 110%», «пока не сделаю, не лягу спать» и т.д.
Подобные подходы действительно, как сейчас принято говорить, «выстреливают». Но чаще всего не праздничным салютом в вечернее безоблачное небо, а тяжёлыми свинцовыми пулями сразу в обе ноги. Более близкую по смыслу аллегорию, к тому, что происходит с компанией, где люди работаю якобы «на результат с полной выкладкой» подобрать на самом деле сложно.
Как минимум в таких компаниях сотрудники не могут раскрыть весь свой потенциал и как следствие компания не может занять ту позицию в бизнесе, на которую могла бы претендовать при другом стиле менеджмента. Наоборот, падение качества и производительности приводит к тому, что компания вполне может оказаться там, где владельцы и менеджмент меньше всего хотели бы её видеть.
Резюме
Выводы, которые здесь можно сделать лежат на поверхности.
И программистам, и менеджменту нужно серьёзно относиться к соблюдению графика труда и отдыха при разработке программного обеспечения. И если его соблюдать очень сложно, следует задуматься и трезво проанализировать возможные пути конструктивного решения данной проблемы. Чтобы программист имел возможность продуктивно работать и развиваться, а менеджмент и владельцы компании получать ожидаемый результат от этого.