- Что делать, чтобы успевать разрабатывать фичи в срок?
- Если кто-то знает хороший ответ на этот вопрос - сообщите мне его контакты, пожалуйста.

Дедлайн: нервы и риск или разумная ответственность? Многие программисты склонны оценивать себя весьма оптимистично. При оценке времени на разработку многие не учитывают тестирования, правок в процессе ревью и банальной усталости. Как правило, это приводит к срыву сроков. Что с этим делать и как корректно оценивать время на разработку (никак), - опытом делятся программисты Mail.Ru Group: руководитель подразделения разработчиков Сергей Лихобабин и руководитель Лаборатории Технопарка Илья Лебедев.




Как часто тебя просят оценить время на разработку?
Сергей Лихобабин: Почти каждый заказчик или менеджер хочет знать, когда он получит желаемый функционал, так что оценивать сроки приходится для большей части задач.
Илья Лебедев: Никакая задача не идет в работу, пока не будет оценена. Оценка срока часто меняет очередность задач или саму задачу.

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

Закладываешь ли ты запас?
С.Л.: Конечно. Объем этого запаса даже является предметом шуток в кругах разработчиков и менеджеров. Учитывая природный человеческий оптимизм, первоначальную оценку можно смело умножать как минимум на три. Детализация требований позволяет повысить точность оценки, но лишь до определенного предела, ведь требования могут и измениться в процессе реализации, и это реальность с которой приходится мириться.
И.Л.: Я руководствуюсь точностью описания задачи. Если то, что мы должны получить, максимально детально описано в рамках технического задания, то спрогнозировать время можно вполне точно. Любая ошибка оценки планирования - это, как правило, допущение или умолчание в техническом задании. Или, что хуже всего, его отсутствие. Если мы говорим про срок выполнения конкретной задачи разработки, то никаких формул запаса не существует. А если, например, нужно оценить время, спустя которое мы сможем анонсировать продукт, важно помнить, что кроме разработки тут надо сделать несколько этапов тестирования, провести тестовый прогон, убедиться, что все в порядке с инфраструктурой. Помимо этого есть риски, связанные с людьми: заболел, взял внезапный отпуск, не смог сделать. Здесь как раз возникает эвристическая формула “оценка разработчика умножить на три”. Но по факту все это выдумки, и требуемое время вполне понятно. Мы просто делаем запас на риски, которые добавляются к процессу.

Что ты думаешь о планировании?
С.Л.: Планирование может приносить как пользу, так и вред. Назначение сроков ради назначения сроков, на мой взгляд, пустая бюрократия. Важно понимать, чего именно мы хотим добиться с помощью четких сроков. Например, добавить дисциплины или уложиться к какому-то объективному дедлайну. Также стоит искать индивидуальный подход - не каждый способ назначения сроков будет работать хорошо для любой команды. На мой взгляд, не нужно ударяться в микроменеджмент и планировать слишком далеко с высокой детализацией. Часть сроков будет неизбежно сорвана, а усилия, которые будут потрачены на планирование, могут оказаться бесполезными, не говоря уже о демотивации, связанной со срывом сроков.
И.Л.: Я планирую и рабочее, и нерабочее время, разграничиваю то, что нужно сделать для бизнеса, и то, что я делаю ради собственного интереса. Считаю, что правильно иметь долгосрочное, среднесрочное и краткосрочное планирование. Долгосрочное - план продуктов на полгода, среднесрочное - то, что мы ожидаем сделать за месяц, краткосрочное - то, что нужно сделать за текущую неделю. Конечно же, хочется сделать как можно больше, но человек не машина, и мы стараемся оценивать сроки справедливо и корректно, планировать рабочее время.

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

Как убедить заказчика, что на разработку задачи нужно больше времени?
С.Л.: Исполнитель априори разбирается в сроках лучше, чем заказчик. Если экспертной оценки исполнителя недостаточно, чтобы убедить заказчика, лучше, по возможности, не работать с таким заказчиком - себе дороже. А в целом, как ни выставляй сроки, на скорость выполнения это практически не повлияет (не будем учитывать типичную ситуацию “за день до дедлайна” - на нее лучше не рассчитывать). Доверять экспертной оценке и не брать на себя дополнительные риски - в интересах самого же заказчика.
И.Л.: Я много раз сталкивался с тем, что заказчик хочет чего-то в невозможные сроки. Метод убеждения очень прост: соглашаться. В итоге заказчик ничего не получает вовремя и вынужден еще месяц тратить на то, чтобы все поправить. Зато в следующий раз мы предлагаем ему выбор: сделать, как в прошлый раз, или все-таки выставить адекватный срок и написать техническое задание. Замечу, кейс “убедить заказчика в том, что нужно больше времени” сам по себе достаточно странный. Возможно, этим и обусловлена некая странность его решения. Сам по себе термин “заказчик” в рамках одной компании странен. Должен быть продуктовый менеджер, стоящий рядом с командой, доверяющий ей и работающий с ней, а не противопоставленный ей заказчик, не верящий в сроки.

Участвуют ли в планировании твои подчиненные?
С.Л.: В нашем отделе разработчики в большинстве случаев напрямую взаимодействуют с заказчиками. Это значительно уменьшает бюрократию, исключает излишне долгие встречи с участием большого количества людей и минимизирует эффект испорченного телефона.
И.Л.: Оценивать сроки - вроде как не задача разработчика. У нас были случаи декомпозиции задач и глобальной оценки времени на разработку самими программистами. Кто-то из них реагирует на это спокойно, а кто-то спрашивает: “Почему этим должен заниматься я?”. Я хорошо понимаю этих людей. Планирование - это тоже работа, и, на мой взгляд, совершенно не стоит нагружать этим разработчиков. Оценку сроков и планирование всего проекта я не делегирую. Но оценка конкретной задачи - все-таки дело программиста. Я не вправе говорить за них, сколько это займет времени. Таким образом, разработчики участвуют в планировании на локальном уровне.

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

Некоторые разработчики жалуются: порой и из-за сроков страдает качество и падает мотивация. Был бы ты счастливее, если бы сроков на разработку не стояло?
С.Л.: Если от твоего продукта не зависит никто, кроме тебя самого, то и сроков никаких не будет. Проблема в том, что в крупных проектах взаимодействие с другими разработчиками и командами неизбежно - отсюда и возникают сроки. Было бы мне проще работать, не назначая сроков? Пожалуй, да. Сроки, как и любая другая ответственность, жизнь, как правило, не упрощают. Но без них не удастся создать по-настоящему больших, сложных и интересных проектов.
И.Л.: Скорее нет, чем да. Качество и мотивация падают, когда принесенные сверху сроки меньше оценки сроков на разработку, когда некий заказчик хочет, чтобы все было сделано как можно быстрее. При этом падает качество. Сделанное плохо вызывает демотивацию. Адекватному разработчику не интересно делать плохо в поставленный сверху срок. Если при этом не было хорошего понимания нужного результата, то в срок, поставленный сверху, получается не то, что на самом деле хотели, и результат разработки еще и критикуют. Это демотивируют на все 146%. С рядом “не-до-заказчиков” в этом отношении приходится проводить воспитательные работы. На месте разработчика я был бы счастлив иметь хороший запас времени на реализацию, нужные инструменты и хорошее понимание нужного результата моей работы. Бесконечный срок на разработку или его отсутствие для этого не требуется.