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