Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
Команда хочет добавить проверку безопасности перед выпуском. Администратор обнаруживает, что её workflow используется ещё шестью проектами. Если просто вставить новый обязательный переход, чужие команды получат непредусмотренное ожидание, а роботы перестанут завершать задачи по старой логике.
До проектирования попросите команду разобрать несколько недавно выпущенных изменений и одно отклонённое. Так станет видно, где реально происходила проверка, кто принимал решение и какие сведения требовались. Новый процесс лучше строить вокруг существующего полезного контроля, а не искусственно добавлять обязательную кнопку.
Модель и договорённости
Нарисуйте путь задачи и отдельно опишите значение каждого состояния. Решите, является ли проверка обязательной для всех типов или только для релизных изменений. Для каждого нового перехода укажите исполнителя, необходимые данные и поведение при отказе. Не заменяйте статусом каждое кратковременное действие: процесс должен оставаться читаемым.
Для каждого состояния определите ожидаемое действие и ответственного за его завершение. Если задача может ждать без владельца, новый статус лишь скрывает очередь. Согласуйте, что происходит при отпуске проверяющего, отмене выпуска и обнаружении проблемы уже после положительного решения по предыдущей версии изменения.
Порядок внедрения
Создайте отделённую конфигурацию для пилота и проверьте ассоциации схемы. Подготовьте сопоставление старых и новых статусов для существующих задач. Обновите правила, которые ищут конкретные статусы или выполняют переходы. Перед публикацией проведите разбор с владельцами досок, отчётов и интеграций, а затем примените изменение на выбранной группе задач.
Зафиксируйте контрольную версию схемы и полный список её потребителей до подготовки пилота. Для нового этапа проверки безопасности сохраните образец задачи, в котором уже заполнены все необходимые данные. Если проверяющий не может принять решение по этому образцу, исправьте состав запроса до публикации статуса: дополнительный переход не компенсирует нехватку информации.
Проверки на реальных сценариях
Проведите через процесс обычную задачу, отказ проверки, повторное открытие и задачу с отсутствующим согласующим. Сравните видимость на доске и результаты отчёта о незавершённой работе. Отдельно прогоните автоматические переходы: наличие кнопки у администратора не доказывает, что актор правила имеет нужное разрешение.
Проверьте задачу, которая уже была в работе до изменения схемы, и новую задачу того же типа. Их траектории могут различаться. На доске обратите внимание на отображение новых состояний, а в отчёте — на границу завершённой работы. Пользователь должен понимать следующий шаг без чтения административной схемы.
Ошибки и диагностика
Наиболее неприятный результат — формально завершённая задача остаётся в отчётах как незавершённая из-за несогласованной логики завершения. Также встречаются петли между автоматизацией и переходом. Не исправляйте их добавлением универсального перехода из любого статуса: это может обходить согласование. Сначала найдите конкретную зависимость, которую изменили.
Если переход недоступен только роботу, сравните его идентичность с пользователем, у которого кнопка работает. Наличие перехода в схеме ещё не подтверждает возможность выполнить его всем участникам.
Возврат и восстановление
Сохраните прежнюю схему, соответствие статусов и список задач пилота. Перед возвратом решите судьбу задач, уже попавших в новое состояние. Переведите их в согласованное старое состояние с комментарием о причине, затем верните ассоциацию конфигурации. Обратный переход не должен стирать фактическое решение проверяющего.
Возврат схемы требует явного решения о задачах, ожидающих новой проверки. Для каждой определите, допустимо ли продолжать выпуск по старому процессу или требуется ручное согласование. Протоколируйте это решение в задаче. Если новый этап уже выявил риск, возврат конфигурации не должен автоматически трактоваться как разрешение продолжить опасное изменение.
Приёмка и дальнейший контроль
После запуска измеряйте время ожидания проверки, число обходов процесса и количество ручных исправлений перехода. Через один рабочий цикл обсудите, помогает ли новый этап снижать риск или только создаёт очередь. Изменение считают успешным, когда пользователи и автоматизации одинаково понимают, что требуется для следующего шага.
Оставьте владельцу короткую карту зависимостей: доски, фильтры, правила и внешние переходы. Следующее переименование статуса иначе повторит ту же проблему. Результаты пилота обсуждайте с исполнителями: дополнительные ожидания должны объясняться снижением конкретного риска, а не самим наличием нового состояния в workflow.
Механизм продукта и применимость
Workflow-схемы связывают типы задач с рабочими процессами. Перед изменением необходимо определить, какие проекты и типы используют изменяемую конфигурацию.
Общие workflow-схемы и их ассоциации в статье относятся к company-managed проектам. Team-managed проект настраивает собственные процессы и не использует описанную общую схему таким же образом. Для него сохраняют логику пилота, но меняют настройку локального workflow и проверяют собственные типы задач.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу