ТЗ на Planfix: объекты, статусы, доступы и проверка сценариев

Начните с маршрута работы, который можно показать

ТЗ на Planfix должно объяснять, как конкретная работа проходит от входящего обращения до принятого результата. Названия полей и список автоматизаций полезны после этого описания. Если разные сотрудники по-разному понимают слово «готово», система закрепит разногласие, а отчёт начнёт смешивать выполненные задачи с теми, которые только передали дальше.

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

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

Опишите объекты и данные без лишнего дублирования

В актуальной документации Planfix объект объединяет настройки формы, полей, статусов и поведения задачи. Поэтому в требованиях полезно сначала назвать виды сущностей, с которыми работает команда, и их отличия. Заказ на обслуживание, внутренняя задача специалиста и согласование расходов могут иметь разные жизненные циклы. Не объединяйте их только ради одинакового внешнего вида карточек.

Для каждого поля укажите смысл, тип, допустимые значения, обязательность на конкретном этапе и источник заполнения. «Телефон клиента» требует решения: это контакт для текущего обращения или справочное значение организации? «Срок» может означать обещанную клиенту дату, внутренний дедлайн или план следующего контакта. Если эти значения различаются, одно поле создаёт путаницу при изменениях и отчётности.

Проверьте связь задач с контактами, проектами и другими задачами. Укажите, что происходит при смене клиента, объединении записей и удалении ошибочной связи. Для импортируемых данных нужен устойчивый внешний ключ и правила сопоставления. Добавьте примеры пустого значения, неизвестного справочника и слишком длинного текста. Приёмка должна выявлять потерю смысла данных, а не только возможность сохранить карточку.

Согласуйте статусы и ответственность за переход

Составьте матрицу переходов в рабочем документе. В каждой строке должны быть исходный статус, действие, роль, обязательные данные и конечный статус. Переход «выполнено → принято» обычно требует другого подтверждения, чем «новое → в работе». Если решение о приёмке принимает заказчик или руководитель, исполнитель не должен незаметно подменять его своим действием.

Для учебной настройки можно описать возврат так: руководитель возвращает задачу на доработку, указывает причину, задача сохраняет историю предыдущего выполнения и снова получает исполнителя. Проверяются не только новый статус и уведомление, но и сохранённые файлы, комментарии, срок и отражение в отчёте. Число доработок не должно исчезать после очередного изменения карточки.

Назначение ответственного тоже требует правил. Кто принимает работу при отсутствии сотрудника? Можно ли передать задачу без согласия нового исполнителя? Что происходит с просроченным обещанием после передачи? Укажите очередь для случаев, которые не удалось распределить автоматически. У этой очереди должен быть владелец, иначе формально успешно созданная задача останется без человека, который действительно обязан её разобрать.

Проверьте доступы в рабочих ролях

Опишите видимость и возможность изменения отдельно. Сотрудник может видеть сроки общего проекта, но не иметь доступа к внутренним финансовым данным. Внешнему участнику может требоваться обсуждение своей задачи без просмотра соседних обращений. Общая фраза «доступ по ролям» не объясняет, как должны работать поиск, связанные карточки, вложения и уведомления.

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

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

Сделайте автоматические сценарии наблюдаемыми

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

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

Для интеграций согласуйте идентификаторы и владельца каждого изменяемого поля. Опишите повтор, недоступность внешней системы и восстановление после паузы. В журнале нужен способ найти исходное событие и связанную задачу без просмотра секретов или лишних персональных данных. Если автоматическое действие не завершилось, оно должно оставлять видимое состояние и ответственную очередь, а не только техническую ошибку, доступную разработчику.

Отделите перенос данных от обычной работы

До переноса подготовьте инвентарь: какие активные задачи, контакты, файлы и исторические события действительно нужны в новой системе. Архив для поиска и рабочий список задач могут требовать разных правил. Уточните, сохраняются ли старые номера, даты, исполнители и связи. Искусственно назначенная текущая дата способна исказить отчёт о сроках и загрузке.

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

План переключения должен описывать, когда прекращается запись в старый инструмент, кто переносит последние изменения и как команда узнаёт новый порядок работы. Проверьте возможность повторного запуска импорта без новых дублей. Отдельно сохраните отчёт о непринятых данных и правила ручного разбора. Успешная загрузка большинства строк не означает, что оставшиеся обращения можно незаметно оставить без решения.

Примите процесс по контрольным задачам

Соберите приёмочный набор из разных сценариев, а не из десяти копий успешного пути. Нужны неполные данные, запрещённый переход, смена исполнителя, отказ внешнего сервиса, повтор входящего события и возврат на доработку. Для каждого заранее опишите исходное состояние и ожидаемые изменения. Это позволяет обсуждать расхождение с требованием, а не вкусовое впечатление от демонстрации.

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

Сохраните доказательства: идентификаторы контрольных задач, время проверки, роль, фактическое состояние и найденные отклонения. После исправления повторяют затронутую цепочку, включая соседние сценарии. Отчёты сверяют с исходными задачами: что считается выполнением, просрочкой и повторной работой. Красивый график не подтверждает правильность данных, пока несколько его значений нельзя объяснить через конкретные записи.

Пример заполненной карточки требования: «При переходе обращения в работу система создаёт одну связанную задачу специалиста, переносит согласованные поля и сохраняет ссылку на исходное обращение». Исходные данные — тестовый клиент, выбранная услуга и действующий исполнитель. Проверяющий открывает обе записи под ролью руководителя и сверяет тему, срок, контакт и вложение. Затем повторяет входное событие. В протоколе заранее указано, что вторая рабочая задача появиться не должна. Если исходное обращение отменено до выполнения сценария, ожидаемое поведение фиксируется отдельной строкой, а не додумывается во время показа.

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

При оценке объёма попросите исполнителя отдельно назвать настройку объектов, прав, автоматизации, интеграций, переноса и обучения команды. Это помогает увидеть, что именно включено в предложение. Если в оценке нет проверки внешнего участника, она не возникает автоматически из строки «настройка доступов». Если нет очистки исходных контактов, импорт перенесёт существующие ошибки вместе с данными. Уточнения должны превращаться в конкретные работы или явно принятые ограничения. Сравнивайте предложения по одинаковому набору контрольных задач и условиям передачи, сохраняя отдельный список зависимостей от сотрудников заказчика. Для каждого отложенного решения укажите, какая часть оценки может измениться после ответа. Так бриф остаётся рабочим документом, даже когда не все детали известны с первого интервью.

Передайте владельцу управляемую конфигурацию

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

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

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