Как принять доработку Битрикс24 у подрядчика: проверка на рабочих примерах

Принимайте согласованное изменение, а не впечатление от демонстрации

Интегратор показывает, как в Битрикс24 появляется задача или обновляется поле, и предлагает закрыть работу. На демонстрации всё выглядит убедительно, но сотрудник компании завтра будет действовать под другой ролью, с неполными данными и повторными обращениями. Приёмка доработки CRM — системы работы с клиентами — должна подтвердить согласованные рабочие сценарии.

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

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

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

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

Подготовьте примеры с известным ожидаемым результатом

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

Сначала согласуйте безопасный способ проверки. Где находятся тестовые записи, как они помечены, какие внешние отправки отключены или заменены? Не нужно ради приёмки отправлять сообщения настоящим клиентам или менять их сделки. Организация тестовой среды — отдельная задача; здесь важно убедиться, что выбранный способ позволяет проверить нужное поведение без побочных действий.

Условный пример: после подтверждения заказа система создаёт задачу на подготовку документов. Ожидаемый результат включает ответственного, название, срок и нужные сведения. Слова «задача появилась» недостаточны, если её получил не тот сотрудник или срок рассчитан по другому правилу.

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

Проверьте результат под ролями сотрудников

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

В справке Битрикс24 о связях компаний, контактов и сделок указано, что действия со связями зависят от предоставленных прав. Это пример того, почему проверять нужно не только наличие данных, но и доступность нужного действия конкретному сотруднику. Точные права согласуйте для выбранного сценария портала.

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

Смена ответственного и отсутствие сотрудника — полезные контрольные случаи. Что происходит с задачей, если прежний исполнитель больше не работает в компании? Кто видит незавершённые действия? Если эти ситуации входят в согласованный объём, они должны пройти приёмку наравне с обычной работой.

Проверьте повторные действия и понятность ошибки

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

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

Битрикс24 документирует ограничения REST API, через который работают многие интеграции. Это основание требовать от исполнителя предусмотренной обработки ограничений, а не обещания, что соединение никогда не прервётся. На приёмке заказчик проверяет наблюдаемое поведение при согласованной имитации сбоя, а технический способ организует специалист.

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

Убедитесь, что соседние процессы продолжают работать

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

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

Для отчётов сопоставьте контрольные записи до и после изменения. Сдвиг суммы может быть ожидаемым исправлением, а может возникнуть из-за потери части данных. В обоих случаях объяснение должно опираться на конкретные карточки и принятую методику расчёта, а не на то, что новый график выглядит аккуратно.

Зафиксируйте, какие области проверены, а какие не затрагивались. Это честнее, чем общее заключение «CRM полностью протестирована». Если исполнитель обнаружил отдельную старую проблему, занесите её в другой пункт с понятным статусом, не подменяя ею результат текущей приёмки.

Оформляйте замечания так, чтобы их можно было воспроизвести

Хорошее замечание содержит сценарий, условия, ожидаемое и фактическое поведение. Добавьте время и идентификатор тестовой записи. Фраза «задача работает странно» заставляет исполнителя заново искать контекст. Описание «под ролью менеджера после повторного перехода появилась вторая задача для того же заказа» позволяет начать проверку сразу.

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

Для списка замечаний достаточно таблицы.

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

Повторно проверьте исправления и условия запуска

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

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

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

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

Что должно остаться у компании после приёмки

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

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

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

Для независимого разбора результата можно обратиться в ШТАБ ИТ с согласованным заданием и списком сценариев. Полезный итог проверки — конкретные подтверждения и замечания, по которым компания может принять работу или вернуть её на исправление.