Стимулирование внедрения пользователями с помощью архитектурных решений

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

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

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

Установите критерии внедрения до начала проектирования

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

Добавьте эти пункты в критерии завершения проектирования и не переходите к этапу сборки, пока дизайн им не соответствует:

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

Этот последний критерий имеет решающее значение. Иногда определенные неудобства — это правильный выбор, например, поле для соблюдения нормативов, которое должно быть заполнено на раннем этапе. Обновленный фреймворк Salesforce Well-Architected уделяет особое внимание тому, чтобы сделать компромиссы очевидными, помогая архитекторам принимать их осознанно.

Сделайте обоснование заметным и для пользователей. Используйте контекстную справку на уровне полей, «Руководство к успеху на пути» (Guidance for Success on Path) и сообщения об ошибках правил валидации, которые объясняют, почему поле необходимо, а не просто то, что оно пропущено. Пользователи более охотно принимают неудобства, которые они понимают.

Знакомство с новым фреймворком Well-Architected

Изучите пять новых принципов и концепцию Agentic Enterprise, которые помогут вам ориентироваться в компромиссах и принимать обоснованные архитектурные решения в эпоху ИИ-агентов.

Проектируйте по пути наименьшего сопротивления

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

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

Выявляйте то, что сбивает пользователей со спроектированного пути

• Слишком много заинтересованных сторон на одном макете. Макет Account, который обслуживает отделы маркетинга, продаж и операций, скрывает два поля, необходимых торговому представителю для квалификации Lead или Opportunity. Вместо этого предоставьте каждой ключевой персоне собственное представление: используйте Dynamic Forms с правилами видимости или назначайте разные страницы записей Lightning в зависимости от приложения, типа записи и профиля.
• Обязательные поля на неподходящем этапе. Когда поле становится обязательным до того, как пользователи смогут заполнить его точно, они начинают гадать или вводят временные данные. Пользователи расстраиваются, а отчеты заполняются некачественными данными. Требуйте заполнения поля на том этапе, на котором у пользователя действительно есть ответ, используя правило валидации на основе этапа, вместо того чтобы делать его обязательным везде.
• Процессы, отражающие иерархическую структуру компании. Например, Opportunity не может продвигаться дальше, пока отдельная команда ценообразования не утвердит ее из своей очереди. Представитель ждет, сделка застаривается, а реальные переговоры переносятся в электронную почту и таблицы. Направляйте на согласование только те решения, которые действительно требуют участия другой команды, и не мешайте представителю двигаться дальше тем временем.

Обучение не закроет эти пробелы. Оно учит пользователей тому, что они должны делать, а не тому, что они будут делать, когда за ними никто не наблюдает. Модуль Trailhead по стратегиям внедрения Salesforce охватывает человеческую сторону изменений; ваши архитектурные решения должны покрывать все остальное.

Пройдите процесс от лица целевого пользователя

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

• Какое действие является самым частым? Поместите его на первое место на странице, чтобы оно не требовало никакой навигации.
• Что пользователь действительно знает на момент создания? Только эти поля имеют там право находиться. Соберите остальное позже, в контексте.
• Кто чаще всего использует эту страницу? Проектируйте макеты, приложения Lightning и типы записей вокруг этой основной персоны, а не случайного проверяющего.
• Где еще пользователи хранят эту информацию? Если ответом является электронная таблица, цепочка писем или блокнот, выясните, что этот инструмент дает им такого, чего нет в организации — как правило, скорость или гибкость. Затем заложите это в дизайн или устраните шаг, который отправляет их туда.

Обновленный фреймворк Salesforce Well-Architected подкрепляет это через принцип справедливости (Fairness), который призывает архитекторов проектировать доступные и равноправные системы. Проектирование для обычного пользователя, а не для опытного (power user), начинается именно с этого.

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

Сядьте рядом с реальным пользователем (не с опытным пользователем или волонтером UAT с правами администратора) и попросите его выполнить самую распространенную задачу с нуля. Воспринимайте каждое колебание, неверный первый клик и обходной путь как архитектурный сигнал о том, что путь наименьшего сопротивления и спроектированный путь разошлись.

Исправьте это сейчас. Перемещение поля на этапе проектирования занимает минуты. После запуска это означает переобучение пользователей и восстановление доверия.

Встройте механизмы обратной связи в решение

Внедрение не заканчивается в день запуска, поэтому и проектирование не должно на этом завершаться. Примените принцип операционного совершенства Well-Architected к внедрению: наблюдайте за тем, как люди используют систему, и постоянно улучшайте ее. Сбои во внедрении оставляют сигналы, которые вы можете обнаружить:

• Поля, от которых зависит процесс, остаются незаполненными. Они не являются обязательными в системе, поэтому пользователи пропускают их, и последующие этапы становится сложнее завершить. Обнаруживайте это с помощью отчета о заполнении полей по этапам.
• Записи застариваются на каком-то этапе. Обнаруживайте это с помощью отслеживания истории полей на полях стадий и статусов, а также отчетов о времени нахождения на этапе.
• Использование падает после первых нескольких недель. Обнаруживайте это с помощью еженедельного подсчета созданных и обновленных записей по ролям, а также с помощью приложения Lightning Usage App для активных пользователей и просмотра страниц.

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

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

Отслеживайте уровень принятия пользователями с помощью приложения Lightning Usage App

Отслеживайте количество активных пользователей в день (DAU), просмотры страниц и использование лицензий, чтобы лучше понимать, как пользователи взаимодействуют с Lightning Experience, и находить возможности для улучшения.

Проектируйте поэтапное внедрение, а не единовременный запуск

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

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

• Делайте каждый этап независимым. Первый этап должен иметь смысл даже в том случае, если второй этап никогда не будет выпущен. Например, если второй этап добавляет объект Contract, не делайте так, чтобы объект Opportunity на первом этапе зависел от обязательной связи с ним, и не создавайте поток первого этапа, который предполагает наличие записей контрактов. Добавьте связь, когда настанет время второго этапа.
• Используйте наборы полномочий (permission sets), чтобы включать функции для разных групп. Предоставьте пользователям профиль с минимальным доступом и открывайте каждую функцию с помощью собственной группы наборов полномочий. Сначала внедрите новую возможность для пилотной группы. Каждый пользователь воспринимает изменения порционно, а отзывы пилотной группы дорабатывают функцию до того, как ее увидят все остальные. Если она вызывает затруднения, отмените доступ для этой группы, не затрагивая никого другого.
• Показывайте каждой волне только то, чем она пользуется. Не показывайте вкладки для функций, которые волна пользователя еще не получила. Добавляйте их в приложение Lightning по мере запуска каждой функции. Сфокусированная панель навигации поддерживает уверенность первых пользователей и изолирует сигналы об использовании, позволяя понять, вызвано ли напряжение новым процессом или сторонними функциями. Добавление вкладки занимает десять минут. Вернуть доверие пользователя, решившего на первой неделе, что Salesforce ему не подходит, гораздо сложнее.

Проектируйте так, будто от этого зависит чья-то работа. Потому что так оно и есть.

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

Примените это на практике за четыре шага:

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

Тот же вопрос применим и при добавлении агентов. Новый подход Agentic Enterprise в рамках фреймворка включает в работу возможности на базе агентов: когда агент передает работу человеку, передавайте вместе с ней контекст (о чем просил клиент и что агент уже попробовал), чтобы человек, принимающий задачу, не начинал с нуля.

Принятие не выигрывается в день запуска. Оно закладывается с первой сессии у маркерной доски.