Дедлайны

Работа инженера сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: Это слишком долго. Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: Это слишком долго. У тебя есть время до пятницы. Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.

Часто менеджер ставит невозможный дедлайн, например, три дня, чтобы решить проблему, которая, вероятно, займёт месяц. Это означает, что у инженера два варианта. Он может сделать некачественную (то есть паршивую) работу. Или может вернуться через три дня и сказать боссу, что работа не закончена. Очень часто, если он выбирает первый вариант, все счастливы, что есть какой-то результат, даже если это полный мусор, который абсолютно ни на что не годен. Если инженер возвращается через три дня и говорит менеджеру, что работа не завершена, его босс спрашивает, почему. Тот факт, что времени было недостаточно, не является приемлемым ответом. Но если работа всё же должна быть выполнена, инженеру дают больше времени. Подозреваю, что если работа изначально не была очень важной, босс просто говорит, что время истекло и нужно идти делать что-то другое.

Мне кажется, что такое взаимодействие между менеджером и инженером ни что иное, как игра. Либо для менеджера, либо со стороны компании. В первом случае это может быть демонстрация власти, а во втором реализация стратегии увеличения прибыли компании. Другими словами, если босс не совсем глуп (как иногда кажется), то он понимает, что инженер не может выполнить за три дня работу, которая занимает месяц. Но он играет по правилам компании: она хочет, чтобы инженер делал неоплачиваемую сверхурочную работу столько, сколько способен выдержать. Вот почему так много инженеров в некоторых компаниях работают по 70 часов в неделю.

Многие ИТ-компании фактически сдают своих инженеров в аренду клиентам по часам. ИТ-компании взимают плату за работу либо по количеству часов, которое потребуется для выполнения работы, либо по количеству инженерных часов, которые работа фактически занимает. Они берут с клиента плату за каждый час. Когда их инженеры работают бесплатно в течение долгого времени, это чистая прибыль для компании. Таким образом, у компаний есть огромный финансовый стимул, чтобы заставить инженеров бесплатно работать сверхурочно. В результате многие компании пытаются заставить своих инженеров работать как можно больше неоплачиваемых сверхурочных, даже если приходится придумывать фальшивые дедлайны.

Вы можете спросить, разве это законно? Да, это законно в Соединенных Штатах, поскольку инженеры получают фиксированную зарплату, а не почасовую оплату. Работнику выдают одинаковую сумму каждую неделю независимо от того, сколько часов он фактически работает. Почему это законно? Вероятно, это связано с тем, что крупные ИТ-компании могут позволить себе нанимать лоббистов, а инженеры нет.

Для Соединенных Штатов это означает, что многие инженеры перегружены работой и производят мусор. Когда ваш новый ноутбук умирает через шесть месяцев или в новом американском автомобиле через год взрывается прокладка головки цилиндра, причина может быть в этом. Жадные и эгоистичные компании заставляют врать и своих менеджеров, и инженеров. Они вынуждены говорить, что работа выполнена, когда она не выполнена, чтобы компания получила больше прибыли. Похоже, топ-менеджеров проблема не волнует. Вероятно, отчасти это объясняется тем, что большинство из них социопаты и психопаты. К сожалению, многие из наших компаний, по-видимому, стали оруэлловскими машинами, которые привели этих людей к власти, а оказавшись там, они порождают полный хаос для всех нас.

Дедлайны сами по себе вещь неплохая, я бы даже сказал, где-то и хорошая. Лично у меня работа получается более продуктивной, если мысленно ориентироваться на какие-то сроки, а когда у проекта совсем нет никаких временных рамок, это может ему в итоге повредить. Здесь главное мыслить реалистично и выдерживать баланс.

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

Я тогда работал в стартапе; фронтенд-команда у нас состояла из троих человек, еще имелась бэкенд-команда таких же размеров. Мы работали над обновленной версией мобильного приложения и должны были уложиться с релизом до четко обозначенного дня. Одна проблема: этот день был произвольно выбран то ли простым директором, то ли техническим без каких-либо оснований для подобного решения.

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

Так или иначе, наша приблизительная оценка стала результатом двухдневных совещаний: сначала общий обзор новых функций, потом подробный разбор каждой в отдельности, потом еще более дробный анализ Наконец по каждому этапу работ прикинули количество часов, перепроверили, соотнесли с UX и UI-дизайном, всё сложили, накинули сколько-то часов сверху и вот получился срок выполнения работ.

Вы сейчас, наверное, подумали: ну, раз у них UX и UI-дизайны уже готовы, да еще и про запас часы заложены, то, наверное, всё должно пройти нормально? В большинстве случаев при установке сроков условия бывают похуже. Ну, в общем, нет. Нормально ничего не прошло.
Продолжительность работ была установлена в три-четыре недели не слишком много времени, если говорить о релизе нового продукта силами небольшой команды. Само собой, после первых двух недель мы уже стали отставать от графика. Не потому что медленно работали или мало часов тратили на проект, а потому что всё всегда идёт не по плану.

Бэкенд корпел над реализацией API для приложения, когда вдруг выяснилось, что система не может нормально взаимодействовать с простым дополнением, а значит, нужно переписать уже готовый фрагмент API с учетом этого обстоятельства. На доработку эндпоинта понадобилось два не заложенных в расписании дня.

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

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

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

В обновлении не было ничего такого уж важного, что бы мотивировало необходимость релиза именно в эту дату и ни днём позже. Никто из пользователей не знал про то, что готовится новая версия, никто (ни клиенты, ни инвесторы) не строил планов с опорой на дату. Да, функции полезные, но разве кому-то стало бы хуже, если бы их выпустили на один день позже? Разве это вообще на ком-нибудь сказалось бы?

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

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

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

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

По моим прикидкам (статистику я не собирал, так что ручаться не могу), толк от этой переработки был только в краткосрочной перспективе. Ну да, выпустили приложение в срок. А следующий релиз уже пришлось задерживать, потому что многое переписывали. Разработчики были недовольны (и, как вы уже догадались, активно увольнялись), атмосфера в команде стала напряженной. И это мы еще не учитываем последствия багов, с которыми пользователи столкнулись после релиза.

Как нужно?

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

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