Когда сроки начинают подгорать
Эта статья — часть внутренних лекций студии.
Изначально вопрос звучал так:
Клиент просит оперативно выполнить задачу. Времени на это уходит чуть больше, но он об этом знает, так как на протяжении её выполнения с ним поддерживается связь. По факту человек видит, что работа идёт и даже даёт комментарии по предложенным вариантам.
Также клиент знает, что перед сдачей макетов на вёрстку, он должен согласовать их и сказать нам об этом. А так же, что у всех разные часовые пояса (включая наших разработчиков).
В итоге: задача отдана 27 декабря (пятница). 30 числа (пн) клиент молчит (а я знаю, что напоминать ему бесполезно, потому что он посмотрит задачу в любом случае, только когда у него будет время). Время у него появилось 31 декабря, когда наши разработчики уже не были на связи. Он даёт комментарии по макетам (несогласовав их) и спрашивает срок на вёрстку. После пояснения, что макеты надо сначала согласовать, а разработчики не на связи, напоминает, что просил сделать всё быстрее.
После праздников опять спрашивает про срок и говорит, что всё нужно быстрее.
Как в такой ситуации вести себя с клиентом, если знаешь, что любая фраза, например, что мы всегда сначала ждём согласование макетов, а только потом отдаём на вёрстку, что он и так видел, что работа ведётся и задача оказалась сложнее, чем он представлял и тд будет выглядеть как оправдание и только разозлит его?
Непрозрачность работы
В описанной ситуации есть непрозрачность работы. Клиент думает, что работа будет выполнена быстрее, чем он ожидает. Возможные причины:
- Клиент посчитал, что указанные сроки включают в себя правки, ожидание и обсуждение (и так бывает не редко).
- Клиент забыл о договоренностях по срокам.
- Клиент не ожидал, что верстка займет так много времени.
Разберем эти три ситуации.
Клиент посчитал, что указанные сроки включают в себя правки, ожидание и обсуждение
На протяжении всего проекта на каждом его этапе следует проговаривать, что вы сделали такую-то работу, следующий шаг у вас такой-то, займет он столько времени. Когда речь идет о сроках, то мало кто может спрогнозировать количество итераци, которые и влияют на срок. Возможные выходы (и можно использовать оба):
- Сообщать о сроках не готовности всей работы, а только определенного его этапа без учета ожидания реакции со стороны клиента. Фактически, будет срок отгрузки интерфейса с вашей стороны. А дальше идет процесс, который вы не можете контролировать (скорость реакции клиента) и потому не можете за него отвечать.
- Если с клиентом работа ведется не впервые, можно спрогнозировать количество правок и скорость его ожидания. Полученный прогноз стоит транслировать клиенту в виде вилки: займет от X дней до Y недель. В итоге и у вас, и у клиента будет срок, на который будут все ориентироваться и стараться в него уложиться.
Как эти два способа совместить: сообщить о сроках с вашей стороны до времени первой отгрузки результата и сообщить о прогнозируемых сроках на основе имеющегося опыта взаимодействия.
Вот вы и познакомились с частью управления ожиданиями клиента.
Клиент забыл о договоренностях по срокам
Идеальной памяти не существует. Поэтому все договоренности следует фиксировать в письменном виде, доступном в любой момент любому участнику проекта. Когда закрадывается подозрение, что сроки эти могут быть сорваны или клиент торопит, но зря, потому что срок был оговорен ранее, стоит клиенту мягко напомнить об этих договоренностях. Например:
— На всякий случай напоминаю обо всех наших договоренностях, чтобы никто ничего не забыл и все были спокойны за ход работы.
Клиент не ожидал, что верстка займет так много времени
Такое случается, когда планирование работы было недостаточно прозрачным для клиента. Если работа состоит из двух частей, например, дизайна и верстки, то, конечно, клиенту нужен срок по всей работе. Тут уже нету большой разницы для клиента займет ли верстка 10 процентов времени, а дизайн остальные 90 процентов или наоборот, потому что ему нужна не часть работы, а вся работа целиком.
Верстку спрогнозировать проще, имея макет. А вот спрогнозировать макет куда сложнее, но и у него должен быть свой срок.
Два возможных пути:
- Отталкиваться от имеющихся сроков и планировать работу так, чтобы и верстка в них уложилась, и макеты.
- Уточнять срок по мере приближения к завершению работы — это когда изначально сообщается приблизительный срок, но с каждым этапом этого срока вилка сужается.
Про фразы
Чтобы фразы не звучали как оправдание, следует их не как оправдание подавать, а говорить, что «мы следовали нашим договоренностям по рабочему процессе, и, к сожалению, отход от этих договоренностей может привести к увеличению сроков на работу». В этом нет ничего оправдательного, просто напоминание, что мы так договорились.
А вот чтобы клиент не услышал «задача оказалась сложнее», следует прогнозировать сроки.
Итого
Непрозрачность работы может привести к завышенным ожиданиям клиента по срокам, поэтому важно четко проговаривать этапы работы и фиксировать договоренности в письменном виде.
Оптимальный подход — сообщать о сроках выполнения отдельных этапов и прогнозировать общий срок с учетом возможных правок.
Чтобы избежать недопонимания, стоит заранее объяснять логику сроков и напоминать клиенту о договоренностях, подавая это не как оправдание, а как следование рабочему процессу.