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

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



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



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

* Я хотел бы указать, что единственное исключение будет, если закон требует от вас что-то изменить, например, внедрение GDPR (хотя для GDPR было предупреждение за 2 года, и все же всем приходилось бороться, давай, сделай это дальше). время)

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

Комментарии

Итак, давайте посмотрим на некоторые из полученных мной комментариев. Начнем с того, за кого проголосовали больше всего

«Я люблю дедлайны. Мне нравится свистящий звук, который они издают, когда пролетают ». ~ Дуглас Адамс

Автор _samsara_

Никаких комментариев не требуется

Ради бога, перестань употреблять «конец года».

Автор hobbykitjr

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

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

Автор mattgrave

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

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

Вы ведь понимаете с управленческой точки зрения, что не бывает «произвольных сроков», верно? Я бы даже сказал, что вы можете установить произвольные сроки только в том случае, если (1) на ваш продукт нет спроса, (2) нет стороннего клиента и (3) есть неограниченные денежные средства.

Автор sharddblade

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

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

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

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

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

Честно говоря, я не понимаю, почему люди жалуются на дедлайны. Я проработал в отрасли более 5 лет, работал с 3 разными клиентами по контрактам и никогда не чувствовал спешки. На самом деле у меня было слишком много свободного времени. Я также никогда толком не встречал разработчика, который жаловался бы на дедлайны.

Автор THEGOD_PARTICLE

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

Я также думаю, что этот комментарий показывает, что нам не всем приходится иметь дело с плохим менеджментом (на случай, если комментатору повезет), и это хорошо. Я надеюсь, что еще больше из нас (разработчиков) испытают это.

В своей исходной статье я написал следующее:

Оценки являются приблизительными и обычно крайне неточными.

bkuehlhorn ответил на это следующим образом:

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

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

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

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

Разработчики все лучше оценивают, чем больше они это делают и тем лучше понимают инструменты, с которыми работают. Но он никогда не бывает идеальным и никогда не будет.

Я закончу эту статью о ответах на ответы цитатой из одного из ответов на Reddit, написанного EmperorOfCanada, который, на мой взгляд, был очень подходящим. (Кстати, отличное имя пользователя)

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

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

[...]

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