header-background
Назад

Дедлайны, редлайны, их природа и законы подлости

Авторское 08.12.2023
дедлайны и редлайны

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

Небольшое введение в курс дела

Практически все уже встречали в своей жизни такой термин, как “дедлайн”. Куда реже встречается в обиходе термин “редлайн”. Для завтравки и логического течения разговора стоит сразу обозначить их определения, а точнее нагло скопировать с Википедии:

Дедлайн – (от англ. deadline – мертвая линия) крайний срок выполнения задачи или работы, определённый момент времени, к которому должна быть достигнута цель или задача. По истечении этого времени элемент можно считать просроченным.

Редлайн – (от англ. readline – красная линия)  это  крайний срок сдачи продукта внутри компании. Между дедлайном и редлайном всегда должен оставаться ощутимый разрыв во времени.

За время нашей практики термин и применение редлайна встречался до такой степени редко, что само слово вызывало удивление. Многие команды, специалисты и компании оперировали исключительно дедлайном, стремясь привести продукт к готовности, ориентируюсь исключительно на обозначенную дату. С нашей точки зрения, это ошибка, за доказательством которой необходимо обратиться к святая святых всех процессов – законам Мёрфи (законам подлости). Настоятельно рекомендуем с ними ознакомиться. 

Дело тут вот в чем. Если вы уверены, что закончили проект, он готов и полностью соответствует ТЗ, а до дедлайна еще жить и жить, у вас еще есть запас времени на различные непредвиденные случаи, которые мы опишем ниже. Как часто такие непредвиденные случаи возникают? Самое важное, что они возникают порой всего один раз, чтобы это уже стало чаще, чем вы бы того хотели. Поэтому, стремясь завершить (не сдать) проект  к редлайну, вы будете всегда на несколько шагов ближе к стратегическому успеху. 

Какие бывают ситуации

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

Причина 1. Событие

Это одна из самых жестких и непрощающих причин, в буквальном смысле это уже не дедлайн, это deadwall. Под событиями подразумевается, что вы обязаны сдать проект, который должен функционировать в конкретный момент времени, так как там что-то должно случиться. Это может быть 1 сентября, Новый год, фестиваль – что угодно. То есть даты, которые невозможно перенести. Тут даже открытие магазина не всегда подходит, поскольку и магазин-то открыть можно раньше, чем вы запустите мобильное приложение или веб-сайт, а вот всем миром договориться отметить Новый год через два дня будет уже сложнее. 

На таких дедлайнах прогорали все. Прям вообще все. Даже именитые многомиллиардные корпорации. А все почему? А потому что срок есть срок, и девять женщин не родят одного младенца за один месяц. Подтверждает это правило и закон Мёрфи, который гласит: “Увеличение числа участников при подготовке опаздывающей программы только замедляет процесс”. 

Есть ли выходы из такой ситуации? Конечно есть, но они сразу не очень-то очевидны, рассмотрим их позже.

Причина 2. Сами подписались 

Тут все обычно, совершенно тривиально и происходит максимально часто. Заказчик в каком-то виде спрашивает исполнителя о сроках и цене, а исполнитель, в меру своего опыта, что-то ему отвечает. Вся тонкость этого момента состоит в том, что порой исполнитель, чаще в силу неопытности, называет срок поменьше, стараясь выслужиться перед заказчиком, мол, мы очень постараемся для вас и сделаем быстрее. Допустим, проект с запасом обычно рассчитан на срок в 6 месяцев, а исполнитель называет 4, тогда как реальное расчетное время – 3 месяца. И вроде как все хорошо, целый месяц в запасе, но не тут-то было. Как это обычно происходит, что-то начинает идти не так: то исполнитель заболеет, то резко вклинивается с умоляшками генеральный заказчик, то дизайн по три раза согласовывается, то еще что-то – и вот он, дедлайн. И началось: трубки не берем, а если берем, то начинаем сдвигать дедлайн и кормить заказчика завтраками, и уже через неделю таких телодвижений он закипает. Вот вам и выслужились. Но даже здесь есть выходы из положения, которые мы обсудим позже.

Причина 3. Требование заказчика

Бывает и такое, что заказчик сам требует (а кстати, чаще всего только просит) уложиться в какую-то дату. Причин может быть масса, но две из них самые частые:

  • Тупо вредность заказчика (уважаемый заказчик, давайте не надо!)
  • Желание заказчика как можно скорее перейти в светлое будущее с новым продуктом.

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

На самом деле все это вполне ожидаемо и происходит согласно третьему закону проектирования, который гласит:

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

Как бороться с дедлайнами

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

Первое правило, которое вы должны усвоить: ваш клиент – ваш друг! 

Кстати, где то есть целая идеология “Наш клиент – наш враг”, но вроде бы сторонников этого вероисповедания давно заперли в специальных учреждениях.

Работайте вместе с клиентом против дедлайна. Это как настольная игра, где все игроки играют против игры (рекомендуем к применению игру “Зомби в доме” для дома, офиса и компаний друзей). Поверьте, если все обсудить заранее и говорить только правду друг другу, то почти всегда все будет хорошо (собственно, чем это отличается от обычной жизни?), даже если вы сами свой дедлайн поставили, и никто вас не гнал. Главное, чтобы эти разговоры не начались за день до дедлайна. Вот сами посудите: заказчик ждет, вы ему там наобещали, он в вас верит, вы же крутой! И он уже людей подготовил, деньги в рекламу заложил, все на низком старте, а предмет ожидания где-то в районе Юпитера. Сами понимаете, что будет, если все не решить заранее. В противном случае ваш заказчик начнет играть на стороне дедлайна. 

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

Посмотрев на такой замечательный опыт, некоторые студии сказали: “Игра выйдет тогда, когда она будет готова. Ждите”. И что бы вы думали? Стали выходить замечательные, качественные продукты, потому что если что-то требует 100% часов работы, то, будьте уверены, потребуется именно этот объем. В таких договоренностях с заказчиком или аудиторией нет обманутых ожиданий, все просто ждут хорошего и качественного продукта. 

Но есть тот самый опасный случай, когда дедлайн приурочен к какой-то дате. Если времени впритык или даже его заранее не хватает, то с самого начала действовать нужно:

  • во-первых, быстро;
  • во-вторых, эффективно; 
  • в-третьих, сообща с заказчиком. 

На такие проекты нужно запускать только самых эффективных людей, а все вопросы заранее согласовывать с заказчиком.  Начать стоит с того, что надо всем сразу признаться – времени не хватает, а значит, мы не успеем сделать полноценный продукт вовремя! Следовательно, нужно разбить производство на несколько итераций каждая из которых будет уже функциональной и готовой. К примеру:

  • не успеваете построить автомобиль – пока опустите такие узлы, как музыка, электронные настройки кресел и их массажные функции. Сделайте самое главное – то, что делает автомобиль автомобилем. 
  • если делаете сайт, опустите некоторые функции, а часть функционала при возможности замените готовыми библиотеками или плагинами. 

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

Выводы

В любом деле, будь то работа или личная жизнь, важно помнить: если что-то может пойти не так, оно действительно может пойти не так. Нельзя быть готовым ко всему на свете и даже там, где нет ни каких помех, вам непременно их кто-нибудь (или что-нибудь) создаст. 

Когда наступает кризисная ситуация (в нашем случае это злосчастный дедлайн), важно оставаться честным, договариваться и не замалчивать возникшие проблемы. Не думайте, что кто-то пытается вас убрать и захватить все ваши деньги в лучших традициях средневековья. Все гораздо проще: изначально все на вашей стороне, и только вы сами можете повернуть ситуацию против себя. Ваша задача – оставаться профессионалом, который трезво оценивает сроки, широко смотрит на ситуацию и всегда выходит на диалог.

Читайте также

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

Узнайте, какие факторы определяют цену создания просто сайта-визитки и сложного интернет-магазина, почему локация исполнителей влияет на расценки, как дизайн, функциональность, интеграции, безопасность определяют цену. Исследуем, сколько специалистов понадобится и как это скажется на стоимости.
При разработке сайта создание технического задания (ТЗ) становится ключевым моментом, который определяет курс и параметры всего процесса. Документ структурирует все требования и пожелания заказчика, прописывает архитектуру и функциональные возможности сайта. Погрузимся в детали этого этапа разработки.