Прочитайте о расписаниях обновления здесь.

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

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

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

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

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

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

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

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

Ниже перечислены некоторые рекомендации, которые можно использовать для расстановки приоритетов.

• Влияние (затраты/выгоды) результата
• Объем новой работы, требуемый для достижения результата
• Объем работы, необходимый для обслуживания результата

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

Чтобы узнать больше об инструментах, доступных в Salesforce для получения справки по расстановке приоритетов, см. «Инструменты, связанные с намеренными».

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

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

Плохое или отсутствующее дорожное картирование приводит к:

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

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

Бизнес-дорожные карты помогают заинтересованным лицам планировать организационные изменения, использовать возможности роста и быть в курсе корпоративных целей. Бизнес-дорожные карты также предоставляют способ обеспечить соответствие расходов на ИТ общему бизнес-видению.

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

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

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

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

• Документация всех новых и обновленных функций
• Поддержка существующих функций, необходимых для поддержки новых функций
• Обновления связанных систем, необходимые для поддержки интеграций
• Повышенная поддержка со стороны проектных групп сразу после запуска
• Тестирование, обучение и управление изменениями

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

Чтобы узнать больше об инструментах Salesforce, которые могут помочь вам с дорожной картой, см. Инструменты, связанные с намеренными.

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

Без надлежащего управления рабочие группы столкнутся с целым рядом проблем, включая:

• Запросы на накладывающиеся функции и функции поступают ситуативно
• Группы внедрения приоритизируют «более легкие» усилия или запросы от более влиятельных заинтересованных лиц, не учитывая должным образом бизнес-ценность, компромиссы или общие организационные цели
• Отсутствие согласованных процессов утверждения и рассмотрения
• Несогласованные каденции выпуска и качество
• Высокий уровень дефектов, перезаписи, конфликты и избыточная работа в области разработки

Пожалуй, самый ясный признак отсутствия эффективного управления в системе – медленные и сложные выпуски. Важно признать, что размер системы управления не является мерилом ее эффективности. Фактически, сложные системы управления (подобно тем, которые существуют на многих крупных предприятиях) могут препятствовать скорости и частоте выпуска.

Благое управление — это затруднение прохождения ранних этапов разработки плохими настройками и предсказуемое и последовательное внедрение хороших настроек в производство.

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

Ниже перечислены элементы, которые должны использоваться при создании инфраструктуры для системы управления Salesforce.

• Запросы на работу. Как пользователи могут запрашивать функции или функции? Как сообщаются об ошибках?
• Приоритизация и планирование работы. Кто решает, какие запросы на работу важны? Как объем работы, приоритеты, а также принятие или подписание?
• Среды и планирование выпуска. Что такое ожидаемые продажи среды для разработки, тестирования и выпуска? Кто что делает для инициализации, обновления и предоставления доступа? Кто обрабатывает развертывания и проверку? Как и когда выходят изменения? Как обрабатывать развертывания или среды во время цикла выпуска Salesforce? (Дополнительные сведения см. в разделе Управление жизненным циклом приложения.)
• Ответственность за обслуживание и производственная поддержка. Кто и что поддерживает? Кто занимается горячими проблемами в производстве? Как эти элементы тестируются и выпускаются? Кто отвечает за общие стандарты безопасности организации?

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

Чтобы узнать больше об инструментах Salesforce, доступных для управления, см. Инструменты, связанные с намеренными.

Следующая таблица отображает выбор схем для поиска (или создания) в организации и антисхемы для избежания или нацеливания на исправление.

✨ Ознакомьтесь с дополнительными схемами стратегии в проводнике по схемам и антисхемам.

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

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

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

Salesforce предлагает ряд готовых решений — Sales Cloud, Service Cloud и многие отраслевые решения Salesforce, а также возможность создания собственных настраиваемых решений. Базовые службы, питающие собственные облачные решения Salesforce, также доступны любым настраиваемым решениям, созданным на платформе Salesforce Customer 360. Используйте готовые службы и решения от Salesforce в качестве надежной основы для как можно большего количества решений.

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

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

• Настройка платформы означает изменение и расширение, а не копирование. При создании или оценке архитектуры необходимо задать следующие вопросы: Это уже существует где-то на Salesforce Platform? Если ответ будет «Да, но...», используйте готовую функцию платформы. Архитектурная работа заключается в определении наиболее полезных способов настройки готовой функции Salesforce в соответствии с бизнес-ожиданиями.
• Никакие настройки не являются пустяками. Со временем каждое изменение имеет последствия. Если вам нужно внедрить настраиваемое решение, вы можете уменьшить неизбежную техническую задолженность вашей системы, выбрав технологию низкого кода при любой возможности и создав составные единицы в внедрениях.
• Учитывайте спектр «строительство - покупка». Salesforce AppExchange - это площадка приложений и решений для расширения Salesforce. Приложения AppExchange могут предоставлять функциональность без накладных расходов, связанных с созданием и обслуживанием настраиваемого решения. При оценке решений AppExchange учитывайте следующее:
  • Определите функции решения и пробелы. В идеале, вы найдете приложение, соответствующее всем вашим бизнес-требованиям. В действительности, вы можете не найти идеального соответствия. При оценке решений соотнесите функции потенциального решения с приоритетным списком бизнес-требований. Это поможет вам найти решение, наиболее соответствующее вашим самым важным требованиям.
  • Используйте безопасные среды и бесплатные пробные версии. Используйте бесплатные пробные периоды для оценки приложений в безопасной среде и определения оптимальной посадки. Определите, потребуются ли приложениям изменения конфигурации, противоречащие существующей конфигурации.
  • Рассмотрите краткосрочные и долгосрочные затраты. Оцените долгосрочную экономию на обслуживании приложения по сравнению с периодическими расходами на приложения на основе подписки. Избегайте сценариев, при которых вам придется оплатить текущие расходы за многие функции, которые не будут использоваться бизнес-заинтересованными лицами.
• Используйте готовые модели данных из Salesforce. Salesforce предоставляет готовые модели данных для Sales, Service и разных отраслевых вертикалей. Использование моделей данных, предоставленных Salesforce, обеспечивает определение возможностей в вашей системе только один раз (исключение избыточности и изолированности), устанавливает единый источник истины во всей системе, упрощает понимание данных приложения посредством аналитики, упрощает использование готовых служб искусственного интеллекта Salesforce, снижает затраты на обслуживание (уменьшая настройки, которые нужно поддерживать) и уменьшает техническую задолженность.

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

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

Чтобы узнать больше об инструментах Salesforce, которые могут помочь вам повысить ремонтопригодность, см. «Инструменты, связанные с намеренно».

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

Ключевым преимуществом создания приложений с помощью Salesforce Customer 360 Platform является обратная совместимость, встроенная в платформу. Это значит, что новые инновации платформы могут изменить схему, которую следует использовать для продвижения решений, но повседневная функция решений, созданных на основе предыдущих технологий Salesforce, будет работать и дальше. Со временем любое решение, основанное на устаревшей технологии, начнет создавать риски или преграды для добавления новых функций в приложения, а также понизит общее состояние решений.

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

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

Ключи к решению проблемы технического долга с точки зрения архитектуры включают:

• Определение фактических издержек или выгод для предприятия в сравнении с бездействием
• Правильная дорожная карта
• Создание составных решений

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

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

Ниже приведен список шаблонов и антипаттернов, отображающих корректное (и плохое) техническое управление долгом для организации Salesforce.

Чтобы узнать больше об инструментах Salesforce, которые могут помочь вам с техническим долгом, см. Инструменты, связанные с намеренно.

Следующая таблица отображает выбор схем для поиска (или создания) в организации и антисхемы для избежания или нацеливания на исправление.

✨ Ознакомьтесь с дополнительными схемами обслуживания в Проводнике по шаблонам и антипаттернам.

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

Повысить читаемость можно с помощью эффективных стандартов дизайна и документации.

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

Без стандартов проектирования рабочие группы чаще работают в элеваторах. Без согласованности, обеспечиваемой стандартами проектирования, предприятия столкнутся со следующими трудностями:

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

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

Включите в стандарты проектирования следующее

• Условия наименования для метаданных Salesforce. Определите набор условностей для наименования каждой настройки в системе. Правила хорошего наименования не только внедряют согласованность имен объектов, полей, кода, потоков и других элементов системы. Правила хорошего наименования также помогают группам разработчиков использовать имена, которые передают информацию о цели и функциях того, что они создают. Таким образом, другие заинтересованные лица могут лучше понять конкретную настройку, просто просмотрев ее имя.
• Утвержденные схемы проектирования и их способы использования. Создайте библиотеку Проводника по шаблонам и антипаттернам, а также ключевую информацию о том, когда (и когда) использовать каждую схему. Библиотека может содержать обязательные схемы триггеров Apex или схемы оркестрации потока, в зависимости от составимости системы.
• Руководство по среде разработки и инструментам. Поддерживайте четкий список инструментов, которые должны использоваться группами разработчиков для своей работы. Это может включать утвержденные цепочки инструментов и языки для любого, кто пишет код, или декларативные функции, утвержденные (или не утвержденные) для разработки низкого кода. Ваши стандарты могут содержать список исходных систем управления для настройки и документации, а также обязательные этапы регистрации/убытия. Они могут также включать перечень сред, которые должны использоваться для различных видов деятельности по разработке.

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

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

Чтобы узнать больше об инструментах Salesforce, которые помогут вам определить стандарты проектирования, см. Инструменты, связанные с намеренными.

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

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

Отсутствие четкой документации может привести к целому ряду проблем, включая:

• Циклы разработки, затраченные на переработку существующих внедрений
• Повторяющиеся дискуссии по пересмотру или недоумению в отношении предыдущих решений
• Более длительная адаптация для новых участников рабочей группы или поставщиков
• Чрезмерная зависимость от лиц, обладающих институциональными или историческими Knowledge
• Избыточные архитектуры для поддержки одинаковых или похожих возможностей в бизнесе
• Сложность информирования ключевых заинтересованных лиц о цели и ценности вашего решения

В решениях Salesforce сохраните документацию для:

• Обзоры решений. Диаграммы позволяют вам и заинтересованным лицам визуализировать решения на разных уровнях детализации. Инфраструктура диаграмм Salesforce помогает создавать диаграммы, отображающие бизнес-возможности решений, а также сведения о техническом внедрении.
• Записи решений. Запишите рассмотренные варианты, компромиссы, окончательное решение и аргументацию в центральном расположении, доступном всем участникам рабочей группы для дальнейшего использования.
• Код. Формат кода сам по себе является ключевым элементом документации, и он может (и должен) соответствовать вашим стандартам дизайна. Вам также нужно иметь журнал ключевых сведений и обновлять его при каждом изменении части кода. Для всех классов, триггеров и компонентов задокументируйте следующее:
  • Автор кода
  • Когда был написан код
  • Что должен делать код
  • Ключевые зависимости
  • Все изменения
• Декларативная настройка. Система Salesforce предоставляет встроенные атрибуты для рабочих групп, позволяющие настраивать метаданные в организации. В стандартах проектирования укажите, как рабочие группы будут использовать эти встроенные функции и как они будут называть декларативные настройки. Также ведите журнал ключевых сведений, идентичных используемым для кода.

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

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

Дополнительные сведения об инструментах Salesforce для документации см. в разделе «Инструменты, относящиеся к намеренным».

Следующая таблица отображает выбор схем для поиска (или создания) в организации и антисхемы для избежания или нацеливания на исправление.

✨ Ознакомьтесь с дополнительными схемами для чтения в Проводнике по шаблонам и антипаттернам.

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