Парадокс сорванных сроков

Сорванные сроки — одна из наиболее распространенных причин, которая может свести на “нет” деловые отношения с клиентом. Даже самые опытные разработчики, независимо от количества прочитанных книг по Time менеджменту, сталкиваются с этой проблемой с самого начала своей карьеры, которая никуда не уходит по мере их профессионального развития. Выбор специалиста, как правило, ограничивается лишь тем, кто именно будет погонять его кнутом — проджект менеджер или заказчик.

Проблема сроков настолько актуальна, что пока вы читаете данный текст, будьте уверены — сотни команд и разработчиков придумывают реалистичные причины переноса дедлайна.

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

Как говориться, не все так однозначно. В большинстве случаев, причины нарушения сроков это обоюдная зона ответственности. Мы проанализировали самые распространенные “проколы” и вот что у нас получилось:

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

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

Заказчики часто пишут на биржах, что ищут исполнителей без хомячков, которые могут внезапно заболеть. Но что делать, если любимый хомяк действительно заболел? Также, очень популярна версия про бабулю из другого города. Шутки шутками, но форс-мажоры бывают у всех. Риски, в данном случае, кратно больше у фрилансеров, поскольку в команде всегда можно найти замену для сотрудника, у которого нет живности (или бабушки).

Какие же ужасные эти ваши разработчики! 😡 Да, это так. Но давайте посмотри на другую сторону медали — заказчика:

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

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

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

Например, дизайнер отправил на проверку макет и ожидает обратной связи для продолжения работы или корректировке дизайна. Ну что же, не под дождем — подождем. А на стороне заказчика никто и не собирается ставить в приоритет проверку, так как есть дела и поважнее. Естественно, любая команда / фрилансер старается “забить” свое время по максимум и ничего не остается, как переключиться на другие проекты. А когда через неделю, когда приходит обратная связь по корректировкам, то дизайнер не сможет оперативно взять

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

Как известно, все самые “удачные” идеи приходят тогда, когда проект находится уже после утвержденного ТЗ. Это как с мыслями перед сном — когда поспорил с коллегой днем на рандомную тему, но победителя не выявили. А потом засыпаешь и думаешь “Блин! Надо было вот так ему ответить, а если бы он такой аргумент привел, то я бы ему так и так, чтобы у него совсем шансов не осталось! Вот бы сейчас меня сонного обратно в этот спор!” . На утро, как правило, стыдно за такие мысли. Примерно также происходит и с проектом. Любые изменения в техническом задании, однозначно ведут к увеличению сроков.

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

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

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

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

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

Помимо договора, объясните зону ответственности устно или письменно, лучше всего один раз подготовить шаблон и переиспользовать его от проекта к проекту. Донесите до клиента, что существует активная фаза проекта (реальная работа) и неактивная (на проверке, согласование, корректировка).

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

Любые существенные изменения в ТЗ, которые были согласованы в процессе работы, следует оформлять дополнительным соглашением. В соглашении должны быть указаны отдельные сроки, которые затем добавляются к основному договору.

Зачастую, проблема сроков сильно преувеличена. Готов поспорить, что не было еще ни одного некролога, в котором было бы написано “Умер от передозировки сроками”. Однако, существует такая категория проектов, в которой, кровь из носу необходимо прийти к финишу вовремя. Например, разработка сайта может быть привязана к выставке, где заказчик намерен раздавать визитки с контактными данными. Обязательно зафиксируйте эту информацию.

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

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

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

Иногда переговоры по срокам могут превратиться в ультиматум, после которого можно впасть в уныние.

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

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

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

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

Например, в статусах «В работе” или «Доработка” очевидна ответственность исполнителя, это его полезное (рабочее) время. Статус »На проверке” и »Ожидается оплата” сугубо клиентские, исполнитель не может повлиять на оперативность проверки промежуточных результатов или оплаты.

Нередко бывает, когда проект находится “на проверке” дольше остальных статусов.

Поэтому, если вы заметили на горизонте кричащего клиента, который с ускорением приближается в вашу сторону, и уже можно рассмотреть, что указательный палец устремлен в приложение № 1. Не паникуйте, подпустите его поближе. Убедитесь, что речь точно идет о сроках. Затем резким движением пришлите ему отчет, закройте дверь и продолжайте работу. Не забудьте про реверанс с улыбкой (не ухмылкой!).

Битва за сроки продолжается уже ни одно поколение. Сорванные дедлайны разработчиков с одной стороны и нереалистичные сроки от бизнеса будут существовать всегда. Человечество не способно решить эту проблему под корень (даже британские ученые).

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