55. Дедлайны
Я не люблю дедлайны. Вы не любите дедлайны. Никто не любит дедлайны. Но почти все используют.
Дедлайны бывают естественные и искусственные. К примеру, выставка 25 октября — это естественный дедлайн, а фича должна быть готова 1 августа, потому что мы так оценили — искусственный. В разработке ПО очень любят дедлайны. Менеджеры превращают в дедлайны буквально все, до чего дотрагиваются. Любая оценка сроков отливается менеджером в дедлайн. Даты окончания фаз водопадного процесса — дедлайны. Итеративная разработка — бесконечный каскад дедлайнов. Раз их там много, то они для чего-то нужны. Наверное.
Дедлайн является ограничением и содержит в себе пару полезных свойств и несколько отвратительных сайд эффектов. Вот все это мы сейчас и потыкаем палкой, чтобы разобраться в консистенции.
+ Предсказуемость
В основном дедлайны используют именно для этого. Это такой wishful thinking, что к указанной дате будет готово хоть что-то. Ну и работает, черт возьми. У меня по лонгридам дедлайн 24:00 каждый день. И что-то я публикую к этому времени. Не всегда хорошее, но хоть что-то.
Или у вас в контракте заложены штрафные санкции за каждый день просрочки. Ну и я уверен что хоть что-то вы скорее всего поставите клиенту в этот день. Или вот через 3 дня у вас экзамен по ядерной физике. Вероятнее всего, вы что-то почитаете перед ним. А если экзамен через 3 месяца, то хрен вы что будете читать.
+ Минимизация издержек от неверных решений
Можно очень долго делать что-то неправильное. Например, продукт, который никому не нужен. Или фичу, которая никому не нужна. Чем дольше мы делаем не то, тем дороже это все обходится. Крайний срок помогает положить этому конец и не разориться.
Ну или мы делаем что-то правильное, но вообще не правильно, хреново делаем, прямо скажем. Ясно, что все придется переделать. И тут нам на помощь приходит находчивый велоцираптор:
+ Балансировка качества и технического долга
Почти у всех хороших разработчиков есть bias в сторону качества. Они ненавидят технический долг и всю банковскую систему целиком с её процентами, мутными схемами и менеджментом. Хорошие разработчики совершенно уверены, что им никогда не позволят вернуть технический долг, загнав в долговую кабалу новыми фичами и лозунгами опережения рынка.
Поэтому они используют для реализации фич все доступное время, стараясь все сделать как можно круче.
Разработка без дедлайнов требует неимоверного внутреннего профессионализма и чувства баланса, которое есть только у блестящих инженеров (а их мало). Так что разумное использование дедлайнов вводит ограничение на качество, заставляя хороших разработчиков прибегнуть к техническому долгу.
К сожалению, довольно часто дедлайны ставят такие, что остается один сплошной технический долг.
А сейчас о минусах.
- Овертаймы
Они — очевидный итог жестких нереалистичных дедлайнов. Говорят, что в геймдеве все так живут. Интересно посмотреть на процент самоубийств по отраслям нашей индустрии.
В овертаймах нет вообще ничего хорошего. Честно. Переутомление, выгорание, потеря продуктивности, депрессия, исход, долгое восстановление. Овертаймы нужно считать на дни, а не на недели или месяцы. Ну иногда очень надо, это да. Но это дни!
- Чрезмерное использование
Дедлайны тыкают где надо и где не надо. Я недолюбливаю итеративную разработку именно по этой причине. Она навязывает дедлайны на все. Конечно, когда у тебя дедлайн каждые две недели, то ты к этому привыкаешь, цена ошибки не очень большая, овертаймы не требуются, жить можно…
Но вот как-то сложно становится погрузиться на месяц в какую-то важную и нетривиальную проблему, потому что над тобой носится менеджер, требует участвовать в стендапах, разбить все на мелкие задачи, оценить, приоритизировать и все время интегрировать. А тебе вот так хочется расхуячить полсистемы в бранче, вращая в сознании сложные конструкции, и потом собрать все заново в гораздо более красивую форму, испытав инженерный оргазм. Но нет, никаких оргазмов, у нас Scrum.
Так и что?
Я не люблю дедлайны. Но они нужны. Иногда. Выборочно. Разумно. Но нужны. Без них хуже. Мне понадобилось 10 лет, чтобы это понять.