Когда заказчик и подрядчик работают в разных порталах Битрикс24, техническая сторона вопроса решается синхронизацией: приложение «Межпортальные задачи и коллабы» передаёт между связанными карточками сообщения, файлы и обновления полей. Но есть проблема, которую синхронизация не решает, — договорённость о том, что считается завершением работы.
Подрядчик закрыл задачу у себя. Заказчик ещё не проверил результат. Стороны по-разному понимают момент завершения — и общая карточка остаётся спорной, даже если данные между порталами ходят исправно. Поэтому до начала работ стоит разделить два события: «передано на проверку» и «принято заказчиком».
Почему «сделано» не равно «принято»
Состояние задачи и деловая приёмка связаны правилами конкретной команды. Сам факт закрытия карточки ничего не говорит о том, кто проверил результат и по каким критериям. Чтобы не выяснять это задним числом, проверяющий должен явно зафиксировать решение: что принято, какие замечания сняты и осталось ли что-то за пределами текущего объёма.
Важно и другое ограничение: приложение не заменяет решение проверяющего и не согласовывает результат автоматически. Если компания использует отдельное подписание документов, оно проходит в своём инструменте. Переписка в связанных задачах — не электронная подпись.
Критерии записываются до начала работ
Описание вида «сделать удобную форму» трудно проверить — у каждого своё представление об удобстве. Рабочая формулировка называет результат и наблюдаемые условия:
- состав полей формы;
- обязательность заполнения;
- ожидаемое поведение при ошибке;
- способ получения заявки.
Для другого типа работ критериями могут быть комплект материалов, формат выдачи или перечень обработанных замечаний. Заодно определите проверяющего, срок проверки и место, где появится решение. Эти договорённости должны жить в общей задаче, а не в переписке мессенджера. Внутренние рабочие гипотезы подрядчика клиенту отправлять не обязательно — проверяют итог, а не черновики.
Пять этапов приёмки
На практике удобно разложить процесс на понятные шаги:
- Подготовка — исполнитель уточняет ожидаемый результат, заказчик подтверждает критерии и материалы.
- Передача — исполнитель прикладывает результат и описывает порядок проверки, заказчик получает предмет проверки.
- Проверка — заказчик сверяет результат с критериями, исполнитель отвечает на вопросы.
- Доработка — исполнитель исправляет конкретные замечания, заказчик проверяет изменённую часть.
- Решение — исполнитель фиксирует завершение своей работы, заказчик явно сообщает о принятии или оставшихся замечаниях.
Это рекомендуемая схема, а не встроенные статусы приложения. Названия этапов и правила перехода между ними команда определяет сама.
Как передавать результат на проверку
Если обмен в этом направлении разрешён, отправьте новое сообщение в чат связанной задачи: что готово, где лежит результат и что именно нужно проверить. Файлам давайте понятные названия с версией, чтобы заказчик не сравнивал случайные копии.
Рабочий шаблон сообщения выглядит так:
Передаём на проверку форму заявки, версия 3. Добавлены согласованные поля и проверка обязательного телефона. Результат приложен к задаче. Просим проверить пункты 1–4 из описания и сообщить решение до согласованной даты. Если есть замечания, укажите пункт и ожидаемое поведение.
Если проверяется сайт или другой внешний результат, дайте ссылку — без встроенных паролей и персональных ключей доступа.
Как оформлять замечания
Реплика «не так, переделайте» возвращает обе стороны к выяснению требований. Полезное замечание содержит три части: объект, фактический результат и ожидаемое исправление. Например: «В мобильной версии кнопка перекрывает поле телефона; ожидаем, что поле полностью видно при вводе».
Исправления к отправленному замечанию оформляйте новым сообщением: правка старой реплики на исходном портале не меняет уже доставленную в связанную карточку копию. Если замечание выросло в самостоятельную дополнительную работу, согласуйте её отдельно — иначе критерии текущей задачи незаметно раздуваются.
Проверка перед первым согласованием
Перед запуском процесса убедитесь в трёх вещах: обратное направление обмена разрешено, проверяющий видит задачу и может открыть приложенный файл. Старая переписка не импортируется, поэтому ключевые критерии стоит повторить в актуальной постановке. Ограничения по вложениям разобраны в отдельной статье о файлах в межпортальных задачах.
Начните с одной задачи и короткого набора критериев. Когда обе стороны одинаково понимают передачу, проверку и принятие результата, масштабировать процесс с «Межпортальными задачами и коллабами» значительно проще.
Top comments (0)