Дополнительные работы по сайту: как согласовать цену, срок и ожидаемый результат

Цена небольшой просьбы

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

Рассмотрим запрос на доработку формы: добавить выбор направления обращения и передавать его в CRM. Здесь CRM — программа, где отдел продаж получает и обрабатывает заявки. Направление можно предложить ввести текстом или выбрать из списка, а выбор затем связать с автоматическим назначением менеджера. Внешне разница невелика. Но в последнем варианте придётся определить ответственных, обработать незнакомые значения и убедиться, что прежние заявки продолжают приходить. Поэтому оценивать доработку по размеру нового поля — плохой способ планировать бюджет.

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

Ошибка, уточнение или новая функция?

Обсуждению цены предшествует простой вопрос: что именно меняется по сравнению с принятым заданием? Форма уже должна была передавать направление в CRM по принятому заданию, но не передаёт? Это повод разбирать несоответствие заданию. Если передачи в задании не было, а необходимость появилась позже, исполнитель оценивает новую работу. Решающее значение имеет исходная договорённость.

В споре полезнее открыть описание результата и макет: если на рисунке есть только поле, а передача его значения в CRM нигде не описана, сторонам сначала предстоит договориться о поведении формы и лишь затем оценивать отличие от исходного задания. Фраза «заявка поступает менеджеру нужного направления» задаёт более определённый результат. Когда документы расходятся, сначала запишите общее понимание этого поведения и только затем решайте вопрос оплаты. Порядок оплаты и устранения недостатков уточняют по документам сторон.

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

Есть и третий случай: цель прежняя, а способ ещё не выбран. Если команда пока обсуждает, как удобнее собирать направление обращения, каждый предложенный макет не обязательно означает новую функцию. Точкой отсчёта служит принятый объём, а не количество сообщений в переписке.

Что включить в оценку исполнителя

Оценка полезна, когда по ней видно, откуда появилась сумма. Для формы нужны разбор значений, изменение страницы, передача данных в CRM, испытание и выпуск на рабочий сайт. Если подрядчик считает только добавление поля, попросите объяснить, кто оплатит остальные действия. Пропущенная работа всё равно понадобится. В форме запроса изменения Jira Service Management отдельно предусмотрены Change reason — причина, Change risk — риск, Approvers — ответственные за одобрение, Planned start и Planned end — плановые даты. Это названия полей конкретного продукта, а не обязательный стандарт для вашего сайта. Их полезный смысл можно перенести в обычную карточку задачи: зачем меняем, что может пострадать, кто решает и когда ожидаем результат.

Главный источник неопределённости стоит назвать прямо. Для списка направлений это может быть доступ к CRM или отсутствие окончательного перечня значений. Пока вопрос открыт, разумнее оплатить ограниченный разбор и получить варианты, чем соглашаться на точную цену, рассчитанную по неизвестным правилам. Исполнитель указывает, что выяснит и какой документ отдаст после разбора. Заказчик получает основание для выбора, а не обещание «разобраться по ходу».

Отдельная строка нужна для того, что предоставляет компания: названия направлений, ответственные сотрудники, тексты подсказок и доступ к тестовой CRM. Если эти материалы задержатся, календарь изменится без увеличения объёма программирования. В оценке укажите, с какого события начинается отсчёт срока: утверждения списка, передачи доступа или оплаты.

Сравнение полного, сокращённого и отложенного варианта

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

Для регулярного распределения между подразделениями я выберу список: свободные формулировки заставят сотрудников угадывать, относятся ли «обслуживание» и «сервис» к одной услуге. Автоматическое назначение менеджера стоит добавлять, когда продажи уже определили, кому передавать спорные обращения. Код не разрешит организационный спор. До этого момента единая очередь с ручным назначением честнее и предсказуемее незавершённой автоматизации.

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

Почему часы работы не равны сдвигу запуска

Доработка меняет общий план: даже если разработчик быстро добавит поле, выпуск будет ждать, пока отдел продаж утвердит значения, администратор откроет доступ к CRM, а принимающий сотрудник найдёт время отправить заявку и посмотреть результат. Календарный срок включает ожидание. Его нельзя получить простым сложением часов разработчика.

Сравнивать стоит два расписания: с доработкой и без неё. В первом видно, какие действия начнутся позже, кто больше не успеет к своей дате и можно ли выпустить основную часть отдельно. Если новая форма использует общий обработчик заявок, её нельзя без объяснения объявить независимой от запуска. Подрядчик показывает связь: какие страницы используют этот обработчик, как отделяется новая версия и что останется доступным при переносе функции на следующий выпуск.

Процесс Atlassian включает в план изменения ожидаемый результат, ресурсы, сроки, испытания и способ возврата. Для небольшого сайта достаточно краткого ответа по каждому пункту. Возврат особенно нужен там, где ошибка перекроет поток заявок: кто вернёт прежнюю форму и как будут обработаны обращения, уже отправленные через новую.

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

Как закрепить решение и принять доработку

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

Для формы из этого разбора образец содержания такой: посетитель выбирает направление из утверждённого списка, после отправки название сохраняется в заявке CRM, а обращение без выбора обрабатывается по заранее названному правилу. К записи прикладывают перечень значений. Отдельно описывают старые формы, которые продолжат отправлять заявки без нового поля. Подрядчику тогда не приходится додумывать, нужно ли останавливать отправку, подставлять первое значение или направлять обращение в общую очередь.

Приёмку лучше поручить сотруднику продаж: он отправит тестовые заявки с выбранным направлением и без него, найдёт их в CRM, сравнит содержимое карточек с формой и установит, кому досталось каждое обращение. Когда проверяется только внешний вид, ошибка передачи останется за пределами показа.

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

Решение, которое можно исполнить

Согласование заканчивается выбором одного варианта: выполнить функцию целиком, сократить её или вернуться к ней позже, когда ожидаемая польза для сотрудников оправдает затраты и подготовку, необходимые для изменения работающей формы и порядка обработки обращений. Для выбора направления это частота ручного распределения, готовность справочника и влияние на ближайший запуск, а не впечатление, что «добавить поле недолго».

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

Сокращение функции тоже требует решения. Компания сохраняет деньги и срок, если понимает, какую ручную работу оставляет сотрудникам и при каком изменении нагрузки вернётся к автоматизации.