Подрядчик и заказчик в проекте — каждый видит только свою часть

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

Разница с «пригласить и попросить не смотреть лишнее» принципиальная: контур не зависит от аккуратности гостя. Он один раз собран на структуре компании, ограничении доступа к виду и запрете удаления задач — и дальше повторяется для каждого нового подрядчика по чек-листу.

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

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

Итог: проект формально прозрачный, а управлять границей нечем. Каждый новый подрядчик — заново переговоры о том, что ему можно.

• Называйте внешние виды языком клиента: «Этапы и приёмка», «Монтаж: город А», а не «Backlog Q4».
• Держите чек-лист приёмки доступа и проходите его под тестовым внешним аккаунтом при каждом новом подрядчике — это 10 минут и снятый риск.
• Ведите список внешних аккаунтов с датой подключения и датой проверки. Временные расширения прав фиксируйте с датой окончания.
• Фиксируйте фильтры и группировку внешнего вида. Свободный фильтр превращает вид в окно во весь проект.
• Правило «перенос срока — только с комментарием» внесите в договор или приложение к нему, а не только в регламент.
• Критичные события границы (новая задача от подрядчика, смена срока, комментарий заказчика) дублируйте в мессенджер команды.
• Когда подрядчик уходит с проекта, отключайте аккаунт в тот же день — задачи и переписка остаются на месте.

Команда до 10 человек. Отдельное пространство под внешних можно не заводить: достаточно двух-трёх видов с ограниченным доступом внутри того же проекта. Право удаления оставьте у одного человека — руководителя. Чек-лист приёмки держите в одной задаче-шаблоне и копируйте при каждом подрядчике.

Средняя команда с несколькими подрядчиками. Здесь уже нужен отдельный внешний контур и рабочие процессы: статус «Принято заказчиком» не должен выставлять подрядчик. Полезно разделить виды по подрядчикам, а внутренний вид менеджера держать сводным — по всем внешним исполнителям сразу.

Корпорация и PMO. Внешний доступ описывается регламентом: кто подтверждает выдачу, какой срок действия, кто проводит ежемесячную ревизию списка внешних аккаунтов. Приёмка доступа становится обязательным пунктом при старте подряда, а отчёт по правкам сроков внешними участниками — частью разбора проекта. Если требования безопасности запрещают облако, разворачивайте on-premise.