Что такое дедлайн в программировании
Что такое дедлайн у программистов и что значит «дедлайн горит»?
Дедлайн происходит от английского «dead line», что буквально переводится как «линия смерти». В жизни это выражение означает крайний срок чего-нибудь.
Дедлайн-режим — откуда все началось?
Ко использует термин дедлайн?
По сути применить термин «дедлайн» можно ко всему, что имеет какой-либо с р ок. К примеру:
работа начинается в 8.00 — это дедлайн, когда нужно появиться на рабочем месте;
молоко испортится через 24 часа — это дедлайн, до этого времени его можно пить;
купили квартиру в новостройке — дедлайном будет срок ее сдачи;
Дедлайн в продажах. Любая реклама пестрит дедлайнами, все мы встречали что-то подобное: «Только до 14 января!», «Только до конца лета!», «Только на этих выходных!», «Пасхальные скидки до 20 апреля», «Только в честь дня 8 марта» и др. Все эти дедлайны применяются для стимулирования продаж, чтобы не оставлять покупателю врем ени на раздумья, потому что если не успеть вовремя, то цена «вырастет».
Дедлайн в госструктурах. Примеры такого дедлайна: налоги должны быть оплачены до такой-то даты, штрафы ГИБДД должны быть оплачены в течение 2-х недель, сроки исковой давности по каким-либо делам и др.
Дедлайн у журналистов. Репортаж должен выйти в 11 утра и ни минутой позже, статьи в газету для завтрашнего выпуска должны быть написаны до 17.00 и ни минутой позже. Все это делайн-режим.
Дедлайн у программистов. Нужно успеть завершить работу до определенного числа.
Что такое «дедлайн горит»?
дедлайн горит — означает, что у работника поджимают сроки;
Что делать, если дедлайн горит?
Установите новые сроки. Если дедлайн горит и вы просите его отложить, то обязательно нужно указывать время и дату нового дедлайна. Откладывать до неопределенной даты — непра в ильно. Но важно назначить такую дату, до которой вы точно успеете, чтобы не пришлось еще раз переносить окончание работы.
Эти три рекомендации в случае, если дедлайн горит, помогут вам сохранить репутацию, «свое лицо» и клиентов.
Как правильно сформировать и соблюдать дедлайн-режим?
Дедлайн всегда горит, если сроки сдачи работы неправильно рассчитаны и режим работы не соблюдается. Не нужно обозначать дедлайн просто так «с головы», нужен другой подход. Для такого подхода у нас есть рекомендации:
Всегда нужно устанавливать дедлайн с запасом. Лучше сделать немного раньше, чем не успеть вовремя. Даже если вы точно знаете, что успеете все сделать за определенный период времени, всегда на значайте на несколько дней больше — «на всякий пожарный случай». Если сроки устанавливает заказчик, но у вас есть подозрения, что вы не успеете, то это нужно сразу обозначить и четко аргументировать, чтобы получить более длительные сроки.
Дробите большой проект на мелкие части. Дробите проект на части и каждой такой части установите собственный дедлайн. И соблюдайте его, несмотря ни на что. Это поможет не расслабляться на старте, предполагая, что у вас еще очень много времени.
Не время деталям. Первостепенная задача — сделать проект вовремя и качественно, поэтому не нужно изначально включать в себе перфекциониста. Вначале нужно делать все самое важное, а потом, если останется время, то можно уделить его более мелким и маловажным деталям.
Не всегда все зависит от вас. При формировании дедлайна нужно учесть, что уйдет время на создание рабочей группы, покупку и настройку оборудования или ПО и другие проблемы, которые вам не подконтрольны.
Заключение
Соблюдать договоренности и сроки — это правильно. Поэтому изначально все должно быть четко спланировано и организовано, а себя нужно держать в постоянном рабочем состоянии даже на самом старте проекта, чтобы не настало такое время, когда вы будете понимать, что у вас горит дедлайн и вы ничего не успеваете.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Дедлайны в продуктовой разработке
Дедлайны есть во всех без исключения проектах и практически во всех продуктовых процессах разработки. В проектном управлении дедлайны легко напрямую связать с выручкой, но для продуктов всё несколько сложнее. Какую роль играют дедлайны при развитии продукта? Можно ли без них обойтись?
По мотивам статьи Джона Катлера. Публикуется с его разрешения для обсуждения и обмена опытом.
Простейший вид дедлайна — коммерческий. Если его «пробиваешь» — наглядно теряешь много денег. Таких дедлайнов мало: обычно это либо гонка с конкурентом, либо связано с календарным событием (праздником, выставкой и т. п.). Бывает, что декларируется именно коммерческий дедлайн, но после «пробития» оказывается, что деньги не потеряны. Бывает, что декларируется вероятность потерять много денег. Это проверить сложнее, но тоже можно (статистически) — часто оказывается, то прямые потери либо переоценены, либо их нет вовсе.
Это следствие злоупотребления искусственными дедлайнами. Большинство дедлайнов в продуктовой экосистеме (в отличие от проектной) — именно искусственные.
Зачем они бывают нужны:
Примеры неоптимального использования искусственных дедлайнов:
Обсуждение: Какие ещё бывают юзкейсы у дедлайнов? Какие альтернативные подходы могут быть использованы вместо дедлайнов?
Польза и вред от сроков (deadlines) в программировании
Я часто ловлю себя на мысли, что наличие сроков при написании software может давать негативный эффект, хотя многие считают, что сроки – это полезно. Мне кажется, что их нужно применять все-таки с осторожностью (как и любую другую таблетку счастья). Я попытался проанализировать, как же сроками можно навредить проекту, а как сроками можно улучшить будущий результат.
Для тех, кому лень читать всю статью: я считаю, что сроки нужны, но менеджеры и программисты должны понимать, что иногда сроки проваливаются, и что в этом нет большой трагедии. Иногда в проваленных сроках виноваты обстоятельства, а не конкретные люди.
Иметь дедлайны для вещей, которые ты делаешь – это полезно. Но в случае с программированием есть некоторые нюансы.
Как сроки помогают писать софт
Благодаря срокам можно планировать будущее. Если мы планируем закончить работу над фичей Х через 2 месяца, то мы знаем, что через 3 месяца мы можем делать релиз новой версии нашего софта.
Сроки помогают с рационализацией/оптимизацией: если мы знаем, что по срокам Петя заканчивает работу над фичей Х через 2 месяца, а Вася заканчивает работать над своим таском через 2 дня, то нам проще сориентироваться в том, у кого сколько работы. Если завтра появится какой-то баг средней важности, то мы сможем рационально взвесить ситуацию, и решить, что мы дадим фиксать этот баг Васе, который через 2 дня будет свободен.
Сроки могут также выступать в виде дополнительного способа спецификации задания. Программист может маневрировать под влиянием сроков – где-то он будет более усерден и чистоплотен, а где-то он не будет. И это хорошо, т.к. за счет таких маневров, в конечном итоге скорость разработки софта вырастет.
Как сроки мешают писать хороший софт
К сожалению, программирование – сложная штука, и правильно рассчитать сроки наперед не могут даже хорошие специалисты. К тому же большинство программистов оценивают сроки чрезмерно оптимистично. Поэтому часто дедлайны оказываются просроченными. Получается, что программисту нужно вложить много эмоций и усилий для того, чтобы закончить какую-то задачу в оговоренные сроки. Программист может называть неоправданно оптимистичные сроки под давлением менеджеров. Еще хуже, когда менеджеры сами называют сроки программистам.
Сроки в глазах многих программистов — это какой-то карательно-упрекающий инструмент менеджеров. У таких программистов сроки вызывают некоторый эмоциональный дискомфорт. Когда программисту нехорошо на эмоциональном уровне, то скорее всего его эффективность уменьшится.
Кто же виноват? И как спасать ситуацию?
Мораль и раздача призов
Виноватых и правых нет в этой ситуации. Если качество или скорость разработки софта падает из-за политики дедлайнов в компании, то виноваты оба. Сроками пользоваться нужно и полезно. Но мне кажется, что сроки должны быть мягкими – работники должны понимать, что им лучше «провалить» дедлайн, если в противном случае они бы написали костыли или если в противном случае они бы исчерпали себя эмоционально. Мы все-таки не ясновидящие, и сроки всегда будут неточными, поэтому нужно относиться открыто к тому, что сроки можно корректировать.
Дедлайн для программиста: что делать?
Коварный дедлайн – извечный спутник программиста. С ним рано или поздно сталкивается каждый. В принципе, в дедлайне нет ничего страшного. Это просто заранее установленный крайний срок сдачи выполненной работы. Но очень часто при слове «дедлайн» вспоминаются «горящие сроки», работа в жестком режиме, когда времени остается катастрофически мало, а объем работы предстоит еще выполнить весьма серьезный.
Иногда проект не удается завершить в указанный срок по вине заказчика. Это могут быть несвоевременно предоставленные исходники, дополнительные «хотелки», затягивание сроков утверждения промежуточных этапов работы и т.д. Но намного чаще причина сопутсвующих дедлайну проблем кроется в самих исполнителях. Здесь основные причины:
По идее, с опытом подобные сложности должны исчезнуть или стать редким исключением из правил. На самом деле, просроченный дедлайн – частая история и у фрилансеров, и в IT-компаниях. С этим приходится смириться и научиться решать сопутствующие проблемы, по возможности, без потерь финансовых и репутационных.
Для чего нужен дедлайн
Если строгие сроки сдачи способны принести столько неприятностей как заказчику, так и самому исполнителю, то не проще ли от них вообще отказаться? Ответ – нет. Как ни странно, но дедлайн – это чуть ли не главная причина, по которой проекты вообще завершаются успехом.
Когда-то слово «dead-line» напрямую ассоциировалось исключительно с тюремным жаргоном: так называлась линия, пересекать которую заключенным запрещалось под страхом смерти. За нарушение границ «мертвой линии» тюремные охранники стреляли без предупреждения. Сегодня лексическое значение этого слова претерпело существенные изменения и ассоциируется у многих исключительно с работой. Но часть своего значения из прошлого оно все-таки сохранило: пересечь черту дедлайна – значит, оборвать жизнь проекта.
«Работа всегда будет занимать все время, которое на нее выделили». (Закон Паркинсона)
Выполнение практически любой работы займет столько времени, сколько вы сами на нее отведете. И если выделить на определенные действия минимум времени, вы и сами удивитесь, как быстро справились с заданием. Именно поэтому в экстремальных условиях в кратчайшие сроки мы выдаем на-гора такой объем работы, который при обычных обстоятельствах выполняли бы несколько дней, а то и недель. Из закона Паркинсона хорошо виден главный рабочий постулат: нет сроков – нет и работы. В итоге то, что мы можем сделать за пару часов, растягивается на целый день и даже дольше.
Как побороть регулярные срывы сроков
Как заставить работать дедлайн в свою пользу? Решения здесь не самые простые, но, если получится перебороть себя на старте проекта, создать правильное настроение для себя и команды, наличие дедлайна поможет изменить продуктивность и сдать проект вовремя, а, может, даже раньше срока.
Яркий старт
При разработке плана выполнения работ лучше всего продумать максимальную нагрузку на старте проекта, а период ближе к дедлайну, наоборот, разгрузить. В первую очередь нужно остановиться на выполнении самых сложных задач, поскольку они всегда требуют для решения больше времени, чем было запланировано изначально. Вариант яркого старта позволит создать временное окно, которое позволит решить в дальнейшем все незапланированные проблемы. В таком случае, даже если дедлайн будет «на носу», вы уже войдете в курс всех нюансов проекта, поэтому справитесь с работой в срок.
Дополнительный (сокращенный) дедлайн
Это срок завершения работы, который исполнитель должен установить себе сам и который должен наступить раньше реального дедлайна на несколько дней. Чтобы уложиться в дополнительный дедлайн, придется серьезно напрячь силу воли, ведь мозг то и дело будет напоминать, что настоящие сроки совсем другие. Попробуйте простимулировать себя какой-то наградой за выполнение собственного, дополнительного дедлайна. Впрочем, многим достаточно бывает понимания: «я смог, я справился».
Публичное заявление
Расскажите вслух в присутствии коллег, родных или друзей о том, когда вы 100% завершите работу над проектом. Вам будет просто стыдно не уложиться в сроки и подвергнуться возможным насмешкам, особенно, если причина нарушенного обещания – банальная лень. Ведь коллеги, как и родные (в случае работы дома) прекрасно видят, когда человек играется в игры или сидит в соцсетях, а когда – явно работает. Это также мощный стимул для активной и своевременной работы. Особенно он хорошо работает для самолюбивых людей, для которых репутация в глазах окружающих – важный фактор.
Регулярные напоминания о сроках дедлайна
Когда начинается работа над крупным проектом, а сроки весьма далеки, дедлайн становится отдаленным миражом, маячащим далеко-далеко вдали. Но со временем он становится все ближе, и мы начинаем более адекватно оценивать сроки выполнения. В планировщике задач или другой программе с автоматическими напоминаниями установите себе регулярные уведомления о приближении дедлайна. Например: «до окончания проекта осталось 3 недели», потом – «2 недели», потом – «неделя», «3 дня», «сутки».
Конечно, эти сообщения могут вызывать раздражение. Но лучше пусть напоминания вас раздражают, но стимулируют, чем потом столкнуться с проблемой сроков.
«Любая работа длится дольше, чем ожидалось вначале» (Закон Хофштадтера)
Забавный, но правдивый закон от одного весьма уважаемого профессора философии говорит нам о невозможности реалистичного планирования сроков выполнения работы и о пропущенном дедлайне, как о естественном результате. С одной стороны, на него можно списать постоянные нарушения сроков, по крайней мере, для самого себя. С другой стороны, попробуйте варианты решения проблемы, а вдруг и вы сумеете избежать проблемы дедлайна?
Что делать, если дедлайн вот-вот наступит
Если уж дедлайн на подходе, паниковать не стоит. Сохраняем спокойствие и пользуемся следующими советами.
Корректируем план
Как бы мало времени не оставалось, но оно все же есть. Поэтому корректируем план работы, вмещая его в имеющиеся сроки. Первоочередность выполнения – главные задачи, мелочь откладываем на самый конец. Если вы не успеете выполнить какие-то мелочи, но в основном продукт будет работать, заказчик согласится продлить срок для выполнения доработок. Но в случае, если вы все же не уложитесь и сумеете в качестве доказательства показать куски непонятного кода, вероятность отказа от сотрудничества крайне велика.
Оцениваем правильно силы
Даже у лучших разработчиков случаются форс-мажоры, из-за которых они могут не уложиться в дедлайн. Как только почувствовали и осознали, что выполнить работу в отпущенный срок никак не получается, сразу же оповестите об этом заказчика. И чем раньше это будет сделано, тем лучше. Возможно, он даже пойдет вам навстречу и продлит сроки сдачи проекта.
Во время разговора с заказчиком стоит отказаться от детских клише в стиле поломки компьютера и болезни ближайших родственников. Даже если такое случилось на самом деле, лучше использовать формулировку повесомее, например, просто сказать, что «возникли проблемы с программным обеспечением». Это звучит солидно, и практически никто не спрашивает подробности.
Классические причины срыва сроков:
Оставляем панику
Все. Сроки уже «горят». Теперь выход из ситуации лишь один – максимальная продуктивность. Стресс в период приближающегося дедлайна многим идет на пользу, подстегивая и ускоряя работу. Но если стресс слишком сильный и переходит в панику, тогда от него нужно избавиться.
Создаем продуктивную обстановку
Теперь на счету каждая минута, а это значит – ничего не должно вас отвлекать. Уберите все раздражители, которые могут вас отвлечь от выполнения. Это главное условие комфортной и продуктивной работы в период дедлайна. Никаких телефонов, социальных сетей и прочих приложений, которые «съедят» ваше столь драгоценное время. Также постарайтесь пояснить близким суть проблемы, чтобы вас никто не отвлекал. Ваша цель – максимальная концентрация и снижение числа отвлекающих факторов.
Избегаем истощения
Плохой сон и питание – постоянные спутники работы в режиме дедлайна. И если первые несколько дней с усталостью еще можно будет бороться, то дальше она начнет отрицательно влиять на продуктивность.
Просим помощи
Иногда объем работы перед дедлайном остается просто огромным, дедлайн слишком близким, а заказчик крайне вредным, обещающий вам немало проблем в случае срыва сроков проекта. В таком случае единственный вариант – подключить коллег, которые в состоянии помочь вашему цейтноту. Не стесняйтесь просить о помощи друзей и знакомых, коллег в профессиональных сообществах и даже не биржах фриланса. Возможно, от вас потребуется в будущем ответная услуга. Часто за помощь придется заплатить. Но это намного лучше, чем потеря оплаты по проекту и запятнанная репутация. О помощи коллег просят часто – это абсолютно нормально. Не стесняйтесь и вы.
Урезаем скоуп проекта
Если вы все правильно распланировали, то ближе к дедлайну основная работа должна быть практически завершена, остаются мелкие доработки и детали. В случае проблем со сроками этими мелочами можно пожертвовать. Главное, выполнить основную часть. Доработки и мелкие детали можно будет довести до ума при последующих обновлениях. Во многих случаях такой подход срабатывает. К сожалению, возможно это далеко не всегда.
Останавливаем проект
Надеемся, что вам не пришлось доходить до этого пункта, поскольку он самый печальный. Заказчик не получает обещанный проект, а исполнитель – часть оплаты. Но это произойдет только в том случае, если одной стороне выгоднее поступить именно так. Например, заказчик теряет к вам доверие и предпочитает перезаказать работу у более ответственного исполнителя. Либо, что также бывает нередко, дополнительные затраты времени и сил на завершение «проблемного» проекта оказываются невыгодными исполнителю. Это бывает при работе над небольшими сайтами, простыми приложениями или какими-то доработками к существующим системам. И почти всегда подобному разрыву предшествует либо неправильная оценка сложности проекта, либо – сложности в коммуникации с заказчиком, в том числе, попытки получить больше работы за ту же сумму.
Польза и вред от сроков (deadlines) в программировании
Я часто ловлю себя на мысли, что наличие сроков при написании software может давать негативный эффект, хотя многие считают, что сроки – это полезно. Мне кажется, что их нужно применять все-таки с осторожностью (как и любую другую таблетку счастья). Я попытался проанализировать, как же сроками можно навредить проекту, а как сроками можно улучшить будущий результат.
Для тех, кому лень читать всю статью: я считаю, что сроки нужны, но менеджеры и программисты должны понимать, что иногда сроки проваливаются, и что в этом нет большой трагедии. Иногда в проваленных сроках виноваты обстоятельства, а не конкретные люди.
Иметь дедлайны для вещей, которые ты делаешь – это полезно. Но в случае с программированием есть некоторые нюансы.
Как сроки помогают писать софт
Благодаря срокам можно планировать будущее. Если мы планируем закончить работу над фичей Х через 2 месяца, то мы знаем, что через 3 месяца мы можем делать релиз новой версии нашего софта.
Сроки помогают с рационализацией/оптимизацией: если мы знаем, что по срокам Петя заканчивает работу над фичей Х через 2 месяца, а Вася заканчивает работать над своим таском через 2 дня, то нам проще сориентироваться в том, у кого сколько работы. Если завтра появится какой-то баг средней важности, то мы сможем рационально взвесить ситуацию, и решить, что мы дадим фиксать этот баг Васе, который через 2 дня будет свободен.
Сроки могут также выступать в виде дополнительного способа спецификации задания. Программист может маневрировать под влиянием сроков – где-то он будет более усерден и чистоплотен, а где-то он не будет. И это хорошо, т.к. за счет таких маневров, в конечном итоге скорость разработки софта вырастет.
Как сроки мешают писать хороший софт
К сожалению, программирование – сложная штука, и правильно рассчитать сроки наперед не могут даже хорошие специалисты. К тому же большинство программистов оценивают сроки чрезмерно оптимистично. Поэтому часто дедлайны оказываются просроченными. Получается, что программисту нужно вложить много эмоций и усилий для того, чтобы закончить какую-то задачу в оговоренные сроки. Программист может называть неоправданно оптимистичные сроки под давлением менеджеров. Еще хуже, когда менеджеры сами называют сроки программистам.
Сроки в глазах многих программистов — это какой-то карательно-упрекающий инструмент менеджеров. У таких программистов сроки вызывают некоторый эмоциональный дискомфорт. Когда программисту нехорошо на эмоциональном уровне, то скорее всего его эффективность уменьшится.
Когда программист видит, что он не успевает закрыть задачу в нужные сроки, он будет работать с повышенным усердием и повышенной концентрацией. Я вижу 2 следствия из этого:
В конце концов, программист будет думать «В чем я виноват? Из-за чего я теперь должен вкладывать экстра усилия в свою работу? Только потому, что я неправильно оценил сроки?». С такими мыслями любой человек очень быстро потеряет мотивацию к своей работе.
Кто же виноват? И как спасать ситуацию?
Как обычно, истина находится где-то посредине между менеджером и программистом. Со стороны менеджера я бы:
Если бы я был программистом, то я бы:
Мораль и раздача призов
Виноватых и правых нет в этой ситуации. Если качество или скорость разработки софта падает из-за политики дедлайнов в компании, то виноваты оба. Сроками пользоваться нужно и полезно. Но мне кажется, что сроки должны быть мягкими – работники должны понимать, что им лучше «провалить» дедлайн, если в противном случае они бы написали костыли или если в противном случае они бы исчерпали себя эмоционально. Мы все-таки не ясновидящие, и сроки всегда будут неточными, поэтому нужно относиться открыто к тому, что сроки можно корректировать.