Дедлайны сами по себе – вещь неплохая, я бы даже сказал, где-то и хорошая. Лично у меня работа получается более продуктивной, если мысленно ориентироваться на какие-то сроки, а когда у проекта совсем нет никаких временных рамок, это может ему в итоге повредить. Здесь главное – мыслить реалистично и выдерживать баланс.
Дедлайн должен иметь под собой обоснование. «Потому что потому» — это не обоснование. Это никуда не годная практика установки сроков, от которой страдают и компании, и разработчики. Мне повезло: у большей части компаний, в которых я работал, не было обычая брать сроки с потолка. Но бывали и исключения. Об одной ситуации такого рода я хочу рассказать в качестве примера в этой статье.
Я тогда работал в стартапе; фронтенд-команда у нас состояла из троих человек, еще имелась бэкенд-команда таких же размеров. Мы работали над обновленной версией мобильного приложения и должны были уложиться с релизом до четко обозначенного дня. Одна проблема: этот день был произвольно выбран то ли простым директором, то ли техническим без каких-либо оснований для подобного решения.
Ну, то есть не совсем без обоснований – при выборе дня учитывали примерную продолжительность работ, заявленную разработчиками. Если вы работаете с кодом или с людьми, которые его пишут, то уже, наверное, поняли, в чем здесь проблема. Приблизительные сроки всегда приблизительны, то есть очень сильно отличаются от того, что выходит на самом деле. И дело тут не в некомпетентности разработчиков, просто оценить объем работ по целому проекту невероятно сложно. Существует множество моментов, которые могут сильно сдвинуть сроки и которые невозможно предугадать.
Так или иначе, наша приблизительная оценка стала результатом двухдневных совещаний: сначала общий обзор новых функций, потом подробный разбор каждой в отдельности, потом еще более дробный анализ… Наконец по каждому этапу работ прикинули количество часов, перепроверили, соотнесли с UX и UI-дизайном, всё сложили, накинули сколько-то часов сверху – и вот получился срок выполнения работ.
Вы сейчас, наверное, подумали: ну, раз у них UX и UI-дизайны уже готовы, да еще и про запас часы заложены, то, наверное, всё должно пройти нормально? В большинстве случаев при установке сроков условия бывают похуже. Ну, в общем, нет. Нормально ничего не прошло.
Продолжительность работ была установлена в три-четыре недели – не слишком много времени, если говорить о релизе нового продукта силами небольшой команды. Само собой, после первых двух недель мы уже стали отставать от графика. Не потому что медленно работали или мало часов тратили на проект, а потому что всё всегда идёт не по плану.
Бэкенд корпел над реализацией API для приложения, когда вдруг выяснилось, что система не может нормально взаимодействовать с простым дополнением, а значит, нужно переписать уже готовый фрагмент API с учетом этого обстоятельства. На доработку эндпоинта понадобилось два не заложенных в расписании дня.
Из-за этого небольшого изменения API стал работать немного иначе, чем предполагалось на стадии обсуждения, что привело к необходимости переписать отдельные части приложения – работа на несколько часов. Подобные переписывания – обычное дело в мобильных приложениях любого размера, они никого не должны удивлять. Но у нас-то жесткие сроки. И мы теперь уже не укладываемся.
И что же делать? На следующий день нам сказали, что нужно отработать четыре дополнительных часа, чтобы снова идти с опережением. Четыре часа сверху обычного восьмичасового рабочего дня. Ну да, нас покормили, конечно, но ничего полезного для мозга в таких двенадцатичасовых сменах нет и быть не может. Тем не менее, нам удалось нагнать и дальше идти в ногу с расписанием.
Спустя неделю состоялся релиз приложения. Мы порадовались, кто-то принес кексиков, чтобы отметить, и через пять минут все уже опять сидели за мониторами и делали вид, что ничего не произошло.
В обновлении не было ничего такого уж важного, что бы мотивировало необходимость релиза именно в эту дату и ни днём позже. Никто из пользователей не знал про то, что готовится новая версия, никто (ни клиенты, ни инвесторы) не строил планов с опорой на дату. Да, функции полезные, но разве кому-то стало бы хуже, если бы их выпустили на один день позже? Разве это вообще на ком-нибудь сказалось бы?
А вот на разработчиках сказалось. Тут и там люди изливали друг другу свое недовольство; отношения между командой и руководством явно были подпорчены. И это не единичный случай, такое происходило часто, пока я там работал – с периодичностью где-то раз в несколько месяцев.
И какой из этого всего следует вывод? Совсем махнуть рукой на любые сроки? Ну, нет, конечно. Как уже говорилось в начале статьи, дедлайны вообще-то полезны, и самому мне с ними проще работается. Но их нужно воспринимать как ориентиры, а не как жесткие обязательства. Если продукт выйдет на пару дней позже, это не должно считаться концом света. Какой смысл оказывать лишнее давление на разработчиков? Или вы думаете, качество кода от подобных марш-бросков не страдает?
Когда мы после рабочего дня поздно вечером отрабатывали дополнительные часы под знаменем форс-мажора, общий настрой был: «Так, надо это добить поскорее». Часто внедрялись всякие костыльные решения, которые сколько-то поработают, а потом потребуют рефакторинга. В некоторых случаях соответствующий рефакторинг сразу вносился в расписание, в других – о нем благополучно забывали. А бывало, что разработчики и сами толком не осознавали, что делают что-то костыльное, потому что были уставшими и хотели домой.
Когда дело дошло до рефакторинга (там, где вообще дошло), он, вероятно, больше ресурса, чем сам форс-мажор. В кусках кода, написанных второпях, позже стали обнаруживаться баги. Так как приложение уже выпустили, это особенно сильно действовало всем на нервы.
По моим прикидкам (статистику я не собирал, так что ручаться не могу), толк от этой переработки был только в краткосрочной перспективе. Ну да, выпустили приложение в срок. А следующий релиз уже пришлось задерживать, потому что многое переписывали. Разработчики были недовольны (и, как вы уже догадались, активно увольнялись), атмосфера в команде стала напряженной. И это мы еще не учитываем последствия багов, с которыми пользователи столкнулись после релиза.
Как нужно?
Если хотите, чтобы всё делалось качественно – не порите горячку, прислушивайтесь к разработчикам и обязательно отслеживайте прогресс. Если команда не укладывается и причин для срочности нет, сдвигайте сроки! Не произвольно, а на то время, которого на текущем этапе не хватает. Поддерживайте в разработчиках желание сообщать о возможных причинах задержек и рисках. Если кто-то видит что-то, явно не укладывающееся в общее расписание – стоит обратить на это внимание человека, который занимается планированием, чтобы у него была возможность подправить ориентировочные даты.
Всё сделали раньше срока? Ну, в такой ситуации все только выигрывают. И тестирование можно провести как следует, и дать разработчикам возможность что-то улучшить в кодовой базе. Если вы разработчик или общаетесь с разработчиками по работе, то сами знаете: в коде всегда есть места, которые хотелось бы подтянуть. Иногда это всего час и займет, а иногда речь идет о нескольких днях. Лучше не экономить время на том, чтобы сделать код лучше и аккуратнее – как мы все можем подтвердить, в приложениях и так хватает недочетов, которые никто из пользователей не оценит.
