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