„А можно ещё вот это?“ Как я обсуждаю дополнительные задачи
Как отличить исправление от новой функции, оценить влияние на сроки и стоимость и договориться с клиентом. С условным примером AI-помощника, таблицей правок и готовыми формулировками.
«А можно ещё вот это?» — нормальный вопрос по ходу проекта. Клиент увидел первый результат, понял возможности и придумал, как сделать работу удобнее. Иногда за такой просьбой стоит полезное уточнение. Иногда — отдельная функция, которая меняет половину плана.
Я хочу сохранить в этом разговоре две вещи: готовность разобраться в задаче и ясность договорённостей. Если каждую просьбу встречать счётом, совместная работа быстро становится тяжёлой. Если на всё отвечать «конечно», однажды выяснится, что стороны ждут разного результата к одной и той же дате.
В статье о старте проекта я разбирал, что стоит зафиксировать до начала работы. Здесь — следующий шаг: как обсуждать изменения, когда работа уже идёт.
1. Сначала я выясняю, зачем нужна новая задача
По формулировке «добавить кнопку» нельзя понять ни пользу, ни объём работы. За кнопкой может стоять готовое действие, а может — новая интеграция, правила доступа и обработка ошибок.
Поэтому мой первый ответ звучит примерно так: «Давайте разберёмся. Что должно стать проще для пользователя и в какой ситуации это понадобится?»
Дальше мне нужны конкретные ответы:
- кто будет пользоваться дополнением;
- какое действие он сейчас выполняет вручную;
- что произойдёт, если оставить текущий вариант;
- почему изменение нужно именно в этом этапе.
Условный пример. Мы готовим AI-помощника, который составляет черновики ответов на входящие обращения. Менеджер проверяет текст и отправляет его сам. Клиент просит: «А пусть помощник ещё создаёт сделку в CRM».
Здесь полезно выяснить, зачем это нужно. Возможно, менеджер тратит время на повторный ввод контактов. Тогда сначала стоит проверить, можно ли решить проблему более простым способом. А возможно, бизнесу нужен полноценный автоматический процесс с выбором воронки, ответственным и защитой от дублей. Это уже другой состав работы.
Сначала я хочу описать желаемый результат словами клиента. Техническое решение выбираю после этого.
2. Я отделяю исправление от изменения договорённостей
Мне важно не объявлять дополнительной работой всё, чего нет отдельной строкой в списке задач. Сначала нужно вернуться к согласованному результату, примерам и критериям приёмки.
Если мы договорились, что помощник показывает источник ответа, а он его не показывает, это несоответствие требованиям. Его нужно исправить в рамках принятого обязательства. Сам факт дополнительного труда ещё не превращает исправление в новую услугу.
Если же после согласования черновиков появляется просьба автоматически отправлять ответы клиентам, меняются полномочия системы и последствия ошибки. Такую просьбу я рассматриваю отдельно.
Для разговора полезно различать несколько ситуаций. Все примеры в таблице условные.
| Что происходит | Пример | Как я предлагаю действовать |
|---|---|---|
| Результат не соответствует согласованному | Нет обещанной ссылки на источник | Зафиксировать несоответствие и исправить |
| Уточняется уже согласованное поведение | Нужно пояснить подпись существующей кнопки | Сверить с задачей и проверить влияние на работу |
| Меняется ранее подтверждённое решение | Вместо одной CRM нужна другая | Оценить переделку и согласовать новые условия |
| Появляется новая возможность | Помощник должен создавать сделки | Описать отдельный запрос и варианты выполнения |
Бывает и спорная ситуация: клиент считает функцию очевидной частью результата, а исполнитель её не заложил. Тогда я бы сначала разобрал исходную переписку, предложение и примеры. Возможно, описание задачи действительно было неполным. В этом случае важнее признать пробел и договориться о решении, чем доказывать, что нужного слова нет в документе.
Правило для меня простое: сначала выяснить, что было обещано, затем обсуждать, что изменилось.
3. Я оцениваю последствия, которые не видны в самой просьбе
Короткое описание задачи не означает короткую работу. В условном примере с CRM мало научиться создавать запись. Нужно определить, когда её создавать, какие поля заполнять, как выбирать ответственного и что делать, если контакт уже существует.
Отдельный вопрос — сбой. Если система не получила подтверждение от CRM, можно ли повторить действие? Как проверить, что первая попытка всё-таки прошла? Кто увидит ошибку и сможет продолжить работу?
Я бы разложил оценку на четыре части:
- Реализация: что именно меняется в сценарии и интеграциях.
- Зависимости: какие данные, доступы и решения нужны от клиента.
- Проверка: как проверить новую функцию и убедиться, что прежняя работа сохранилась.
- Эксплуатация: кто будет разбирать ошибки и поддерживать изменённый процесс.
Влияние на срок тоже стоит объяснить отдельно. Задача может быть небольшой по трудозатратам, но ждать решения другой команды. Или потребовать повторной проверки уже готового этапа. Поэтому я хочу показать клиенту, от чего зависит новая дата, а не просто дописать несколько дней к прежней.
Если данных для оценки недостаточно, предлагаю ограниченный разбор: что именно проверим и какой результат получим. Если он требует отдельной оплаты, это обсуждается до начала. Пока существенные вопросы открыты, оценку нужно так и обозначать — предварительной.
В материале PMI Scope change control запрос на изменение связывается с его целью, влиянием на сроки и стоимость и необходимыми согласованиями. Для небольшого проекта мне достаточно короткой понятной записи, которая отвечает на эти вопросы.
4. Я показываю варианты: добавить, заменить или отложить
После оценки у клиента должен появиться выбор.
Добавить в текущий этап. Сохраняем прежний результат и включаем новую работу. Обсуждаем обновлённые сроки, стоимость и условия проверки. Если что-то остаётся прежним, это тоже фиксируем.
Заменить часть объёма. Новая задача важнее другой, ещё не выполненной. Тогда решаем, что исключаем. Но две задачи одинакового размера в списке могут сильно различаться по трудоёмкости. Сохранение бюджета и срока нужно подтвердить оценкой.
Отложить до следующего этапа. Завершаем текущий результат, а дополнение рассматриваем отдельно. Записываем, когда и на каком основании вернёмся к вопросу. Запись в списке идей сама по себе не обещает будущую реализацию.
Есть и четвёртый возможный итог: отказаться от идеи после обсуждения. Например, ожидаемая польза не оправдывает усложнение поддержки. Хороший разбор запроса вполне может закончиться решением оставить всё как есть.
Небольшое дополнение иногда разумно включить без изменения цены. Но и тогда я бы обозначил, что именно включено и влияет ли это на срок. Несколько незаметных уступок подряд способны изменить реальный объём проекта.
Похожий принцип описывает Atlassian в разборе scope creep — неконтролируемого расширения объёма: изменения нужно делать видимыми, оценивать и согласовывать. Для меня это способ обсуждать приоритеты с клиентом.
5. Как я бы ответил клиенту
Сначала полезно дать короткий ответ, который сохраняет разговор и не создаёт преждевременного обещания:
Да, давайте рассмотрим. Уточню, какой результат вам нужен, сравню с текущим составом работ и покажу влияние на сроки и стоимость. После этого выберем, включать задачу сейчас или оставить на следующий этап.
После разбора ответ становится предметным. Вот условный пример для той же CRM:
Сейчас в этапе согласованы черновики ответов и проверка менеджером. Создание сделки добавляет запись данных в CRM. Для этого нужно согласовать поля, правило поиска дублей, ответственного и поведение при сбое.
Можно включить эту работу в текущий этап с обновлённой оценкой. Можно заменить ею другую задачу после сравнения трудоёмкости. Или сначала запустить согласованный сценарий, а интеграцию оценить отдельным этапом.
Подготовлю варианты с составом работ, сроками и стоимостью. После вашего выбора зафиксируем итог. До этого продолжаем согласованную часть, которую новый запрос не затрагивает.
В реальном сообщении после оценки должны появиться конкретные условия: что меняется, какая дата предлагается и как рассчитывается стоимость. Общая фраза «будет чуть дороже и немного дольше» оставляет слишком много места для разных ожиданий.
Если изменение затрагивает то, что команда делает прямо сейчас, я бы отдельно договорился, какую работу продолжать, а какую приостановить до решения. Иначе можно потратить время на результат, который уже собираются заменить.
6. Я записываю решение так, чтобы команда могла по нему работать
Итог разговора должен попасть туда, где команда ведёт задачи. Одного сообщения «обсудили с клиентом, всё хорошо» недостаточно.
В записи об изменении я хочу видеть:
- запрос и его причину;
- ссылку на прежний согласованный состав работ;
- что добавляется, меняется или исключается;
- влияние на стоимость, сроки и зависимости;
- критерий проверки нового результата;
- кто и когда подтвердил решение с обеих сторон.
Для нашей условной CRM критерий «сделка создаётся» слишком общий. Нужно договориться о полях, разрешённых сценариях, дублях и действиях при ошибке. Проверка должна соответствовать тому, что клиент действительно принимает.
Полезно сохранить и прежнюю версию договорённостей. Тогда понятно, откуда появилась новая задача и почему изменился план.
Если предложение ещё обсуждается, я оставляю его в статусе «на согласовании». Отсутствие ответа не считаю подтверждением. Одобрение должно прийти от человека, который вправе менять условия проекта. Пожелание будущего пользователя можно принять в работу на оценку, но оно ещё не означает согласование бюджета.
7. Где здесь полезен AI
AI может помочь собрать запросы из переписки, сопоставить их с согласованным описанием и подготовить черновик изменений. Я бы просил для каждого вывода показывать исходное сообщение или пункт задачи, а не просто выдавать уверенное резюме.
Но решение «это точно входит в цену» или «клиент уже согласовал» я не отдаю модели. Здесь важны контекст, полномочия и ответственность за обещание. Оценку проверяет исполнитель, условия подтверждают уполномоченные участники.
У автоматизации есть и собственные границы. Просьба перевести помощника от подготовки черновиков к самостоятельным действиям требует отдельного обсуждения. Подробнее об этом я писал в статье о полномочиях AI-агента.
Для меня хороший итог разговора о дополнительной задаче — понятное совместное решение. Клиент видит, какую пользу получает и чем за неё платит: деньгами, временем или отказом от другой работы. Команда понимает, что теперь нужно сделать. И никто не узнаёт об изменившихся условиях только в день сдачи.