Часто бывает, что на встрече заказчик просит назвать дату. Задача пока описана общими словами. Часть требований имеется. Часть вводных обещают прислать позже. Но срок нужен уже сейчас, обосновывая это различными причинами.
В этот момент оказываешься в неудобной точке. Назовешь дату - ее быстро начнут считать обещанием. Не назовешь совсем - может прозвучать так, будто команда уходит от ответа. Особенно если речь не про большой проект с длинным этапом обследования, а про доработку или срочную правку, где заказчик уже ждет результат.
Я с таким чаще сталкивался именно на доработках. Требования ещё до конца не собрали, а срок уже хотят получить как точную дату. Даже если задача и оценивается в каком то виде, то ориентируются уже на озвученные сроки. И это не зависит от того, что в процессе сбора требований содержание задачи уже поменялось 10 раз.
Я и сам раньше иногда называл срок слишком рано. Потом через пару встреч задача успевала вырасти, появлялись новые условия, а дата уже существовала без привязки к описанной задаче. И возвращать разговор к переоценке становилось заметно сложнее.
Одинаковое название задачи еще не значит одинаковый объем
В переписке задача может называться так же, как и неделю назад. Но внутри она уже другая. В теме письма или карточке задачи ничего не поменялось, но объем её уже значительно вырос.
Срок держится не только на часах разработки. На него влияют правила, критерии приемки, ограничения текущего процесса, тестовые данные, согласования и решения, которые еще не приняты. Поэтому дата, названная после первой встречи, обычно относится не к "задаче вообще", а к тому объему, который был понятен на тот момент.
Например, команда оценила доработку по одному сценарию. Потом выяснилось, что нужен второй сценарий. Для заказчика это может выглядеть как небольшое уточнение. Для исполнителя это уже новая логика, отдельная проверка или совсем другой функционал.
Или сначала обсуждали одно правило. Через пару дней появилось условие: правило должно применяться только к части документов, с исключениями и отдельной проверкой при приемке.
Поэтому рядом со сроком полезно держать простую фиксацию: что именно оценили, какой сценарий включили, какие ограничения приняли и по каким критериям результат можно будет принять. Если эта картина поменялась, дату нужно хотя бы заново обсудить.
Дата для спокойствия потом мешает всем
Иногда очень хочется дать срок просто чтобы закрыть напряженный разговор. Заказчик ждет ответ. Команда еще не разобрала детали, но "примерно" уже что-то понятно и есть возможность назвать какую то дату.
Но в памяти обычно остается не весь разговор, а дата. Слова "предварительно", "по текущему пониманию", "если ничего не изменится" быстро теряются. Через неделю остается только фраза: "вы же обещали к пятнице".
После этого команда попадает в неприятный режим. Нужно либо пытаться уложить выросший объем в старый срок, либо объяснять, почему дата больше не подходит.
Я бы в такой ситуации не пытался выглядеть увереннее, чем есть на самом деле. Лучше назвать срок, но сразу привязать его к условиям:
"Ориентир по текущему объему — до 18 числа. В эту оценку входит основной сценарий и критерии приемки, которые обсудили сегодня. Если добавляется второй сценарий или меняется правило проверки, срок нужно пересмотреть."
Возможно это повлечет за собой споры и обсуждения. Но такая формулировка позволяет зафиксировать, что дата была дана не "вообще", а под конкретный объем.
Новые вводные нужно оценивать по влиянию на работу
Не каждое новое условие автоматически должно сдвигать срок. Иногда заказчик просто что-то уточняет. В таком случае оценка может остаться прежней.
Другая ситуация — когда новое условие меняет логику, проверку или критерии приемки. Даже небольшие изменения на словах могут повлечь за собой значительное увеличение трудозатрат со стороны команды разработки.
В одной ситуации у нас сначала обсуждался один понятный сценарий. По нему и появился предварительный ориентир. Потом выяснилось, что условий несколько, часть зависит от роли пользователя, а приемка должна проверять разные варианты. Контекст вырос очень заметно. Я бы сказал, процентов на семьдесят. В такой момент странно делать вид, что старая дата все еще относится к новой картине.
Заказчик при этом не обязательно пытается раздуть задачу. Часто он сам только собирает картину, как должно быть. В таких случаях фраза "вы поменяли требования" обычно только портит разговор. Она звучит как обвинение, даже если по смыслу там есть правда.
Я бы здесь смотрел не на сам факт изменения, а на его влияние. Если новое условие не меняет работу и приемку, срок может остаться прежним. Если меняет сценарии, правила проверки или критерии результата, значит, старая оценка уже не полностью подходит.
Лучше это сразу обозначить:
“Изначально мы оценивали один сценарий. Сейчас добавилось исключение для отдельной группы заявок. Это меняет проверку и добавляет второй путь. Старую дату можно оставить, если этот сценарий пойдет следующим этапом. Если включаем его сейчас, срок пересчитываем.”
В такой формулировке нет претензии к заказчику. Есть связка между новым условием, работой и сроком.
Как говорить, если вводные еще неполные
Полностью отказываться от разговора о сроке обычно бесполезно. Заказчику нужен ориентир: он планирует запуск, обещает результат дальше или, возможно, закладывает бюджет. Фраза "пока ничего сказать не можем" часто только усиливает давление.
Лучше дать оценку настолько точно, насколько сейчас можно. Не изображать полную уверенность, но и не уходить от ответа.
"Сейчас можем оценить только тот объем, который описан на встрече. Если добавится второй сценарий, срок пересчитаем."
"По текущему описанию ориентир такой. В нем пока нет правила по исключениям, поэтому после его подтверждения я отдельно скажу, меняется ли дата."
"Если срок нужно зафиксировать сегодня, давайте рядом зафиксируем, что входит в эту оценку и что пойдет отдельно."
Обе стороны должны понимать, какую именно задачу сейчас оценивают. В этом случае при изменении вводных разговор о сроке не выглядит как внезапная попытка выпросить дополнительные дни.
Почему я бы чаще называл одно число, а не диапазон
Диапазон выглядит честным способом показать неопределенность. Но в живом разговоре он часто работает криво. Если сказать "от пяти до восьми дней", заказчик запомнит пять. Потом семь или восемь дней будут восприниматься уже как задержка.
Поэтому в таких ситуациях я бы чаще называл одно реалистичное число, уже с учетом понятных рисков. Не самый оптимистичный срок, при котором все должны сработать идеально, а срок, который будет максимально реалистичным. Если получится быстрее, это станет хорошей новостью для заказчика. Если назвать минимальную дату, любая новая вводная сразу превращает разговор в конфликт.
Но риски нельзя прятать. Их нужно проговорить рядом:
"Ориентир — до 18 числа. В эту дату уже заложен риск по уточнению правила. Если появится еще один сценарий, я вернусь с новой оценкой и покажу, на что он влияет."
Иногда вместо диапазона лучше дать варианты. Например: основной сценарий к ближайшей дате, расширенный вариант позже. Или запуск в два этапа: сначала то, что критично, потом дополнительные пожелания.
Что проверить перед тем, как назвать срок
Перед датой полезно быстро проверить, на чем она будет держаться. Не нужно превращать встречу в длинный опрос. Обычно достаточно нескольких вещей:
- что именно должно быть готово к этой дате;
- какие сценарии входят в текущую оценку;
- по каким критериям заказчик будет принимать результат;
- что зависит от заказчика или смежных участников;
- что точно не входит в текущий объем;
- при каких изменениях срок пересматривается.
Самые чувствительные пункты — объем и критерии приемки. Если они не проговорены, команда может сделать то, что поняла, а заказчик будет ждать другой результат. В этом случае причина будет в разном понимании готовности.
Если после обсуждения появляются дополнительные пожелания, лучше не запихивать их внутрь старой оценки. Лучше так: "это добавим следующим этапом и оценим отдельно". Если заказчик настаивает, что нужно включить сейчас, значит, вместе с этим включается и переоценка срока.
Когда дата особенно хрупкая
Бывает такое, что задача описана общими словами, а срок ждут уже сегодня. Еще один плохой признак - вводные обещают прислать потом, но дату хотят зафиксировать сейчас. То же самое, если на каждой встрече появляется новое правило или никто не может сказать, что точно не входит в текущий объем.
В таких случаях я бы не называл дату без условий. Эта дата не будет иметь ничего общего с реальностью. Через пару дней почти наверняка выяснится, что кто-то имел в виду еще один сценарий, дополнительную проверку или другой вариант приемки.
Если заказчик давит
Давление на срок неприятно, но иногда у заказчика правда есть внешний дедлайн: проверка, отчетность, запуск, обещание руководству. Раздражаться в ответ не помогает. Лучше вернуть разговор к выбору.
Если звучит "мне все равно, нужен срок сегодня", можно ответить спокойно:
"Ориентир сегодня назвать могу. Тогда фиксируем, что он предварительный и относится к текущему описанию. В него входят основной сценарий и такие-то критерии приемки. Если добавляется новое правило или второй сценарий, я отдельно показываю влияние на часы и дату."
Другой вариант:
"Если дата жесткая, давайте выберем, чем управляем. Можно оставить дату и сократить объем. Можно оставить объем и перенести дату. Можно идти с текущей датой, но тогда отдельно фиксируем риск и кто принимает решение по нему."
Технические подробности лучше не использовать как щит. Длинный рассказ про внутреннюю сложность редко убеждает. Заказчику полезнее увидеть варианты: что можно сделать к дате, что придется вынести отдельно, какой риск появляется при попытке оставить все сразу. Как вариант, можно предложить 3 варианта в такой формулировке, чтобы нужный выглядел самым выгодным для заказчика.
Как сказать то же самое спокойнее
Вместо: "Вы сами поменяли требования".
Лучше: "После нового условия задача стала шире. Давайте отдельно зафиксируем, что добавилось, и пересмотрим срок."
Вместо: "Мы так не успеем".
Лучше: "К этой дате можно успеть основной сценарий. Если включаем еще и исключения, срок нужно пересчитать."
Вместо: "Мы это не оценивали".
Лучше: "В прошлой оценке этого сценария не было. Я могу добавить его в текущий объем, но тогда покажу новую оценку по часам и дате."
Разница вроде небольшая, но в разговоре она чувствуется. Первая версия звучит как защита. Вторая возвращает разговор к задаче, объему и выбору.
Как фиксировать договоренность
После разговора о сроке нужна короткая письменная фиксация. Через пару дней забудется: кто что имел в виду, какие условия обсуждали, что решили вынести отдельно.
Я бы фиксировал несколько вещей: какой объем оценивали, какие критерии приемки приняли, что не входит в текущую оценку, какие вопросы остаются открытыми, какие решения нужны от заказчика, какие риски уже видны и при каких изменениях срок пересматривается.
"Зафиксирую договоренность по сроку. Оцениваем доработку по основному сценарию, который обсудили сегодня. В приемку входят такие-то проверки. Сценарий с исключениями пока не включаем, его оценим отдельно после описания правила. Ориентир по текущему объему — до 18 числа. Если исключения нужно включить в этот же запуск, срок пересчитываем."
Такая запись помогает не возвращаться к спору в момент сдачи функционала "мы думали, что это тоже входит". Особенно на срочных правках, где решения принимаются быстро, а память о деталях живет недолго.
Простая опора для трудного разговора
Я не люблю официальные скрипты переговоров. Они часто звучат неестественно. Но в сложном разговоре полезно держать в голове обычную последовательность: сначала напомнить, какой объем оценивали, потом назвать новое условие, показать его влияние на работу и предложить варианты.
Например: оставить дату и вынести часть объема в следующий этап. Или включить новый объем и пересчитать срок. Или сохранить текущую дату, но отдельно зафиксировать риск. Главное - не сводить разговор к фразе "мы не успеем". Она сама по себе почти ничего не объясняет и часто только раздражает.
Не стоит доказывать, что команда хорошая, а во всем виноват кто то другой. Задача проще: показать, что старая дата относилась к одной версии задачи, а сейчас обсуждается уже другая.
Вывод
Я бы не пытался угадывать финальную задачу заранее. Если вводные еще движутся, срок нельзя считать окончательно зафиксированным. Старая дата могла быть честной на момент обсуждения, но относилась она к другой версии задачи.
Поэтому лучше спокойно вернуться к договоренности и пересобрать ее: что оценили, что изменилось, какие есть варианты. Иногда дата останется прежней. Иногда ее придется перенести. Иногда получится сохранить срок, но часть объема уйдет в следующий этап.
В любом случае это лучше, чем делать вид, что ничего не поменялось. Старый срок сам по себе не обязан выдерживать новые вводные. И чем раньше это проговорить, тем меньше потом будет разговора в стиле "вы же обещали".