Скажи мне, как ты относишься к переработкам, и я скажу, кто ты... 

Пролог

Задаваться вопросом о том, как вообще происходит так, что люди перерабатывают, я начал ещё в раннем детстве. Матушка моя периодически задерживалась на службе, из-за чего я допоздна сидел с воспитателями в садике, осознавая, что на вечерние мультики я уже не попадаю. Так я впервые познакомился с неудобствами, которые несут переработки, даже если ты сам имеешь отношение к работе чуть менее, чем никакое.

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

Годы шли, я взрослел и на каждом этапе моего развития в голове зрела мысль, что переработка — одна из неотъемлемых составляющих успеха. Всё логично: ты инвестируешь больше времени в какое-то дело, время количественно переходит в какое-никакое качество и на дистанции всё это приводит тебя к триумфу. Сначала амбассадором подобного подхода была школа, потом университет, а дальше эстафетную палочку перехватил мой первый работодатель, к которому я попал на собеседование в далеком 2013. Там я познакомился с вопросом «как вы относитесь к переработкам?» Помню, что ответил «нормально» или что-то вроде того. 

Этот вопрос мне задавали на последующих собеседованиях в течение пяти лет. Каждый раз, когда я отвечал это самое «нормально», у меня случался флэшбэк и перед глазами появлялся пятилетний сопливый мальчишка с лопаткой и недоумевающим взглядом, одетый в пальтишко и шерстяные рейтузы, к которым со всех сторон уже налип снег вперемешку листвой, и произносил: «Дядь, ты чего? Ты так и хочешь всю жизнь прожить без вечерних мультиков?» Так я понял, что на самом деле никаким «нормально» по отношению к переработкам и не пахнет. Пахнет желанием разобраться в том, почему вообще возникают подобные ситуации. 

Как вы могли догадаться, речь сегодня пойдет про такую обыденную вещь, как переработки. С уважением ко всему IT-сообществу, я надеюсь, что многие найдут её если и не полезной, то хотя бы занимательной. 

Цель 

Моя основная цель — научиться классифицировать переработки, отличать один вид от другого и сводить риск их появления к минимуму. 

Мини-глоссарий

Для начала определимся с основными действующими лицами, которые помогут нам проанализировать различные сценарии. 

Переработка — ситуация, когда человек-работник для выполнения вверенного ему объёма задач начинает трудиться сверх своего рабочего времени. 

Систематическая переработка — та же переработка, но на постоянной основе. 

Дискретная переработка — обычная переработка, которая возникает разово на почве внезапно возникших обстоятельств.

Мой доайтишный опыт

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

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

Мой околоайтишный опыт 

Since November 2017 я уволился с работы и сел учить Python дома, чтобы ворваться в эту вашу айтиху. Никогда не забуду один из случаев, который произошёл со мной во время нарешивания задач.

Мой обычный день состоял из того, что я смотрел всякие курсы и решал задачки. Так вот, мне попалась задача, которая виделась мне довольно простой, но упорно не поддавалась решению. Я просидел за ней сначала 2, потом 4, а потом и 8 часов. Моя девушка, глядя на это, просила меня бросить это занятие и уже, наконец, отдохнуть. 

Как вы могли догадаться, слушать мудрую женщину я не стал. В итоге счётчик разогнался до 12 часов. И никакого результата. Эта ситуация меня просто убивала. 

Мой айтишный опыт

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

На мороз меня после испытательного срока не выставили, из чего я сделал вывод, что со своими задачами я справлялся сносно, однако для этого приходилось часто работать по 12-14 часов. Моих навыков не хватало, а лишний раз отвлекать ребят я не хотел, да и боялся (привет, комплекс самозванца!). 

Это замечали старшие товарищи и говорили мне, что не надо перерабатывать, это приводит к не самым лучшим последствиям. 

Сила свежести

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

В случае с задачкой, когда я открыл утром глаза ответ уже был у меня в голове и я поспешил к ноутбуку, чтобы проверить его. Я был в ужасе от того, что решение действительно было правильным и все тесты успешно прошли. В случае с моим айтишным опытом я свалился в настоящую яму: меня не отпускало ощущение, что я попал в очень крутое место и надо сидеть и вкалывать, как папа Карло, чтобы проявить себя.

В этот момент я понял, что все эти сказки про то, что надо отдыхать, совсем не сказки.

Почему же люди перерабатывают?

Оценив все возможные мотиваторы, я разбил их на две большие группы: 

• Внутренние: человек мотивирует себя сам.

• Внешние: что-то извне мотивирует человека.

Можно с уверенностью утверждать, что мотиваторы внутри групп могут быть разделены на «белые» (положительные) и «чёрные» (отрицательные), но это, по моему мнению, тема для отдельной статьи. Для нас сейчас важен простой факт, что человек перерабатывает, потому что что-то внутри или извне оказывает на него давление.

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

Я утверждаю, что когда возникает систематическая переработка, это говорит о том, что где-то в процессах что-то построено или функционирует не так.

Почему я говорю про систематичность? Потому что я считаю, что избавиться от переработок нельзя. В том или ином количестве они будут присутствовать. И это правда эффективный инструмент для решения некоторых проблем, но их можно сравнить с разрядкой аккумулятора в режиме «турбо», и за это придётся платить лояльностью к компании и здоровьем сотрудника.

Основная проблема видится мне в двух аспектах:

• систематическую переработку часто путают с дискретной;

• неправильно понимают суть выстраиваемых процессов.

А теперь я бы хотел рассмотреть всё это подробнее на парочке случаев. 

Хорошая девочка Лида

Мне посчастливилось воочию наблюдать ситуацию, в которую попала замечательная девочка Лида (имя изменено). Лида работала в компании 5 лет, трудилась за троих, к её работе претензий не было. Она приходила очень рано, а уходила очень поздно. Лида плакала, говорила руководству, что перегружена, просила подумать об открытии новой ставки на параллельной позиции.  

Позиция руководства была такова, что если толпа народу не приходит и не сигнализирует о чём-то, значит проблемы нет и это всё исключительно в голове у одного человека. Так что ситуацию методично спускали на тормозах. Сейчас не до новых ставок, в бюджете на это нет ресурсов, да и по характеру Лида так и будет работать и терпеть до самой пенсии. И вот не так давно я узнал, что Лида уволилась! Её не смогли удержать ни деньгами, ни сладкими позициями в других отделах. Человек дошёл до того, что не хотел иметь с компанией ничего общего, и сейчас в разговоре со мной она вспоминает то время как адский ад. В момент ухода Лиды в компании на какое-то время накрылась вся локальная складская логистика, заказчики перестали получать услуги в срок, компания начала нести убытки. Обязанности спешно начали раскидывать между другими сотрудниками — можете себе представить, как они были рады.  

Ну а Лида сейчас счастлива в своей новой жизни. 

Reason: 

• Хотели запихать объём работ для нескольких человек в одного.

• Обратной связи от исполнителя не придавали большого значения.

How to fix: 

• Всегда нужно брать во внимание, а что мы будем делать, если завтра человек по каким-то причинам перестанет выходить на работу (bus factor).

• Выстраивать процессы сбора обратной связи даже на самом атомарном уровне (уровень рядового исполнителя).

Слабый исполнитель

Когда я начинал свой трудовой путь, то сталкивался с тем, что другие инженеры не хотят помогать мне «за спасибо», несмотря на то, что мы трудимся в одном цехе. У работодателя это было не принято. Ништяки они хотели не от меня, а, разумеется, от руководства. Это было большой проблемой на инженерном старте: мой комплекс самозванца улетал в стратосферу. Особенно когда нужно было отвечать на вопросы заказчиков. Всё усугублялось тем, что нагуглить что-то по узкоспециализированному оборудованию не представлялось возможным, и единственным источником информации для меня был мануал со всеми его неточностями и опечатками. Никому не пожелаю.

Теперь ближе к IT. Провентилируем такую ситуацию: абстрактного Лёху приняли на должность разработчика, однако его уровень ощутимо ниже, чем у Серёги. Согласно штатному расписанию и должностной инструкции Лёха должен выполнять сопоставимый с Серёгой объем работ: пилить фичи, тестировать, проводить полноценные ревизии кода и так далее. Однако суровая реальность диктует свои правила. 

Лёхе приходится много времени уделять развитию собственных базовых hard skills даже в рабочее время. И работодатель никуда от этого не денется: на рынке кадровый голод, а тасочки в Jira надо закрывать уже вчера. 

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

Именно поэтому я с приходом новых сотрудников в команду стараюсь уделить им столько времени для адаптации, сколько возможно. Занимательный факт: именно после таких встреч с новобранцами родилось много документации for internal use: там содержится не только описание сервисов, но и список типовых мини-задач в рамках проекта, которые призваны показать новичку нашу «боевую систему», — прямо как в нубских локациях WoW :) 

Reason: 

• Кандидат обладает недостаточными профессиональными навыками.

• Отсутствует культура наставничества, менторства и обучения.

How to fix: 

• Качественная адаптация сотрудников с решением типовых сценариев помогает быстро сориентироваться в происходящем.

• Хорошо написанная документация по критической функциональности сервисов дополняет предыдущий пункт.

• Наставничество должно быть естественным и неотъемлемым процессом внутри команды.

• Инвестиция в обучение сотрудников.

Оптимизм — наше всё

Прошло полгода, наш Лёха стал писать годный код, вовлёкся в процессы и готовился трудиться в спокойном режиме. Его стали приглашать на встречи, где ему в лоб задавали вопросы о том, в какие сроки он сможет запилить ту или иную фичу. 

Я лично знаю людей, которые в приватной беседе где-нибудь в курилке называли мне одни сроки исполнения, а по факту на встрече «падали в цене» до каких-то невероятных значений. Знаете, почему? Потому что не хотели перед заказчиком показаться некомпетентными и неспособными быстро что-то написать. При этом сам заказчик был бы готов ждать столько, сколько потребуется, но проклятый комплекс самозванца брал своё. А ещё бывали такие ситуации, когда человека откровенно продавливали на определённый срок, тем самым сбрасывая с себя ответственность за их провал. Так сказать, ловили за язык.

Разрешить подобную ситуацию без посторонней помощи надзирающего эксперта, на мой взгляд, практически невозможно. Лёха так и будет лажать с оценкой, что неминуемо приведёт его к профессиональному выгоранию и желанию поскорее уйти из этого места куда-нибудь ещё. И тут важно объяснить Лёхе, что проблема, как говорится, не в клозетах, а в головах! Именно для этого и существуют более опытные коллеги, лиды и так далее. Именно они могут помочь взглянуть на мир со стороны своей собственной экспертизы. И именно поэтому я не верю в то, что в каком-то отделе, где человек является единственным разработчиком, да ещё и малоопытным, можно трудиться без переработок.

Кстати, похожая ситуация описана в книге «Чистый код».

Reason: 

• Неправильно оценён объём работ и сроки.

• Заказчик хочет услышать «сладкий» срок выполнения, нежели реальный.

• Давление по срокам на этапе договоренностей.

How to fix: 

• Научить(-ся) говорить твёрдое нет или брать время на подумать, чтобы проконсультироваться.

• Осознать, что все плывут в одной лодке и делается общее дело с общей ответственностью: лучше лишний раз переспросить, сколько именно времени нужно на ту или иную задачу без давления.

А у вас документов нет!

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

Бытует мнение, что работающий продукт важнее исчерпывающей документации. Так гласит один из постулатов Agile. Однако следом стоит обратить свой взор на то, что написано дальше: не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. 

На собственном примере могу сказать, что можно ценить всё, что угодно, но если на документацию забить совсем, то есть риск в какой-то момент увидеть, что и продукт работать перестал :) 

Кроме того, документация — самый лучший носитель экспертизы авторов продукта. А авторы продукта имеют свойство переходить из компании в компанию. А ещё хорошая документация послужит невероятным катализатором качественной адаптации новичков. 

Reason: 

• Отсутствует документация (техническая и деловая).

How to fix: 

• Систематически выделять квоту на поддержание документации в надлежащем виде.

• По возможности разработать стандарты для структуры документации. Это поможет быстрее в ней ориентироваться при залезании в документацию другой команды.

Власть перегруза

Когда я задерживался в офисе и длина моего рабочего дня систематически переваливала за 11-12 часов, все мои наставники говорили мне, что это хреновый путь, и что если я буду продолжать в том же духе, то ни к чему хорошему это не приведёт. Я отмахивался и говорил, что всё нормально.

Как результат — парочка полноценных нервных срывов. Никогда не забуду, как я засыпал в трясучке, потому что не успевал закрыть задачу в срок и думал, что вот просплюсь и станет легче, но с ужасом просыпался в точно такой же трясучке. А потом ещё мои друзья один за одним стали говорить мне, что я выгляжу как человек, который вот-вот свалится без сил. Но я говорил, что всё окей, сейчас вот ещё один спринт пройдёт, просто он сложный, а дальше будет легче. 

По факту же я просто привык к тому объёму всего вокруг, который на меня наваливался. И отбиваться от него у меня не было сил, и в голове было «будь что будет». 

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

Это состояние можно сравнить с изношенным аккумулятором, который долго заряжается и быстро разряжается, только в отличие от человека аккумулятор проще заменить. Когда люди через одного стали говорить мне «мы за тебя переживаем», стало понятно, что пора что-то менять. Думаю, что это будет материалом для новой статьи, а то тут и так лонгрид получился :) Главное, что сейчас я в порядке. 

Когда в команде наблюдается определённое количество человек с таким же «ударным» подходом к работе, это начинает негативно сказываться на команде. Мне известны случаи, когда люди работали по выходным по просьбам руководства или испытывали на себе давление тех, кто ещё вчера ратовал за то, чтобы работать без перегрузов, а уже сегодня разводил руками со словами «а как вы хотели» или «ну что поделать, я тоже устал». 

Ещё с давних времён стало модным хвастаться тем, как кто-то задолбался на работе. Скажу честно, свой описанный выше опыт я часто использовал как аргумент в разговорах с близкими, мол, «у меня очень много работы, мне некогда». Но сейчас с ужасом понимаю, что это не больше, чем самообман. Зачастую работы может быть столько же, сколько и всегда, а вот ресурсов на её выполнение нет. 

Поэтому теперь когда я вижу, как мне в качестве аргумента предоставляют календарь, где пересекающиеся встречи в два столба я честно говорю: «Камон, бро, ты перегружен! Как ты собираешься быть одновременно на двух обязательных встречах?» 

Reason: 

• Локальные переработки превращаются в систематические. 

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

How to fix: 

• Приглашать сторонних наблюдателей в команду для оценки происходящего.

• Следить за тем, сколько единиц трудоёмкости сжигается человеком и командой в среднем за час, а не за спринт.

Вместо выводов

Что делать со всей вышеперечисленной информацией, каждый решит сам :) Возможно, для кого-то всё написанное мной — очевидные вещи, но я надеюсь, что для кого-то это будет полезным. Википедия любезно сообщает нам, что согласно исследованию Университетского колледжа Лондона больше 15 часов сверхурочных в неделю на треть повышает риск инфаркта и инсульта. 

Так что когда услышите от человека ответ на вопрос «как вы относитесь к переработкам» что-то вроде «нормально», то имейте в виду, что этот человек либо не знает своего истинного отношения к ним, либо врёт, либо он мазохист :) Мнение моё, и оно не обязательно правильное. Будет очень интересно услышать мнение всех неравнодушных к описанным мною проблемам в комментариях!

За факт систематических переработок приходится платить. Сотруднику - своим здоровьем. Работодателю - текучкой кадров и дырами в экспертизе на проектах, которые нельзя заткнуть быстро просто наняв новых рекрутов.

Как итог: 

• Систематические переработки — отличный маркер того, что с процессами что-то не так.

• Переработка — следствие давления. Давления, за которое в любом случае нужно будет расплачиваться по счетам.

• Совсем от переработок избавиться нельзя, но можно научиться их отслеживать и ими управлять.