Lea sobre nuestras programaciones de actualización aquí.

Las soluciones intencionadas entregan valor comercial de inmediato y con el tiempo. Las arquitecturas intencionales se planifican y se entregan estratégicamente, se pueden mantener de forma efectiva y son fáciles de leer y comprender para los humanos.

Las funciones y soluciones se priorizan y se entregan de formas transparentes para las partes interesadas comerciales y tecnológicas por igual. Las opciones de ingeniería crean implementaciones fáciles de trabajar para los equipos de entrega y mantenimiento, sin funciones o complicaciones adicionales. Las arquitecturas intencionales son más fáciles de poseer, mantener y evolucionar con el negocio porque siguen patrones de implementación claros y coherentes. Los generadores pueden interpretar e implementar diseños para nuevas funciones, y los equipos de mantenimiento pueden comprender la documentación de lo que se implementó.

Puede crear sistemas más intencionados centrándose en tres áreas clave: estrategia, capacidad de mantenimiento y capacidad de lectura.

Estrategia en arquitectura significa que los sistemas se planifican y entregan cuidadosamente. Significa que los equipos de entrega y mantenimiento tienen una visión clara del trabajo que se debe realizar hoy y en el futuro, y todos están alineados alrededor del “por qué” del trabajo que se debe realizar. Significa que las solicitudes urgentes se pueden procesar de forma efectiva y eficiente, y que las partes interesadas pueden comprender claramente las repercusiones y las ventajas de las solicitudes.

Puede crear una estrategia más clara en su arquitectura centrándose en la priorización, la hoja de ruta y la gobernanza.

Priorización significa planificar el orden y el alcance del trabajo que entregará. La priorización implica comprender el impacto real de los productos en el negocio, evaluar esos impactos en otras solicitudes de trabajo y la hoja de ruta general para su producto o programa.

Una forma de evaluar la repercusión de un elemento de trabajo concreto es observar el coste o beneficio real para el negocio. Una vez haya identificado los KPI para la automatización, puede utilizar una hoja de cálculo de impacto comercial para evaluar el coste o beneficio general de la implementación. Estos cálculos pueden ayudarle a obtener la alineación y la aceptación de sus partes interesadas acerca de qué automatizaciones crear y en qué orden. También pueden ayudarle a identificar automatizaciones para posponer o evitar. Para automatizaciones, consulte Diseño de procesos para obtener más información acerca de la identificación de trabajo efectivo.

Establecer un marco de prioridad para la entrega también le ayudará a usted y a sus equipos de mantenimiento a gestionar las expectativas de los usuarios y permanecer alineados con su hoja de ruta.

Algunas consideraciones que puede utilizar para la priorización incluyen:

• Repercusión comercial (coste/beneficio) del producto
• Cantidad de nuevo trabajo requerido para el producto
• Cantidad de trabajo requerida para mantener el producto

La lista de patrones y antipatrones a continuación muestra el aspecto de la priorización apropiada (y deficiente) cuando se trata de trabajo de Salesforce. Puede utilizarlos para validar sus planes de implementación o identificar dónde necesita identificar mejor las prioridades antes de crear.

Para obtener más información acerca de las herramientas disponibles en Salesforce para obtener ayuda con la priorización, consulte Herramientas relevantes para intencional.

Una hoja de ruta es una vista priorizada, validada y bien definida de lo que se debe hacer. Las hojas de ruta efectivas proporcionan una imagen clara de la repercusión comercial y la repercusión tecnológica del trabajo futuro. Implicar a sus partes interesadas comerciales y técnicas es una parte clave de la hoja de ruta. Las hojas de ruta le permiten obtener comentarios y aceptación sobre el enfoque y los resultados antes de que comience cualquier trabajo. En última instancia, las hojas de ruta alinean a cada parte interesada sobre el “por qué” del trabajo que tenemos por delante.

Si su equipo utiliza un retraso, es importante comprender que su hoja de ruta no es un resumen o una lista de los elementos en el retraso. La relación es la opuesta: Los elementos solo se incluyen en el desfase si se pueden vincular de forma clara y creíble a un producto en su hoja de ruta. Las hojas de ruta de alta calidad, creadas con la participación de las partes interesadas, proporcionan a los equipos de entrega y mantenimiento una visión clara de en qué deben centrarse y cómo deben priorizar las solicitudes, facilitando la tarea de ordenar las solicitudes en conflicto y gestionar las expectativas de las partes interesadas.

Las malas o inexistentes hojas de ruta conducen a:

• Falta de claridad sobre cuándo estarán disponibles nuevas funciones y características
• Prioridades en conflicto entre las partes interesadas
• Una desconexión entre las soluciones que se entregan y la visión organizativa general
• Dificultad para comprender qué trabajo está en curso
• Cargas de trabajo desiguales entre equipos
• Falta de visibilidad de las relaciones y dependencias entre elementos de trabajo
• Implementaciones estancadas, debido a dependencias mal gestionadas

Las partes interesadas a menudo necesitan información que se ajuste a sus funciones para tomar decisiones. La creación de hojas de ruta efectivas requiere una comprensión clara de su audiencia y el tipo de información que necesita. Las hojas de ruta se clasifican en dos estilos para dar cobertura a audiencias comerciales y técnicas. Cada estilo contiene dos niveles de granularidad para admitir diferentes tipos de información.

Las hojas de ruta comerciales ayudan a las partes interesadas a planificar cambios organizativos, capitalizar oportunidades de crecimiento y mantenerse alineadas con objetivos corporativos. Las hojas de ruta comerciales también proporcionan una forma de garantizar que el gasto de TI se alinea con la visión comercial general.

• Cree una hoja de ruta de funciones comerciales para mostrar a las partes interesadas ejecutivas las funciones que se activarán. Este tipo de hoja de ruta contiene detalles de alto nivel sobre las funciones en sí mismas y cómo se alinean con los objetivos comerciales, como el aumento de la eficiencia operativa o el lanzamiento de una nueva línea de productos.
• Cree una hoja de ruta de funciones comerciales para profundizar en una función específica y mostrar sus funciones y características de asistencia cuando necesite ayudar a las partes interesadas comerciales con la planificación de recursos, el presupuesto y la gestión de cambios.

Las hojas de ruta de tecnología ayudan a las partes interesadas técnicas con la planificación de presupuestos y asignación de recursos. También ayudan a los equipos de implementación a comprender dónde se ajustan sus proyectos como parte de un panorama general más amplio e identificar cualquier dependencia entre equipos.

• Cree una hoja de ruta del sistema de tecnología para mostrar los sistemas específicos que se implementarán, junto con cualquier dependencia a nivel del sistema. Este tipo de hoja de ruta muestra información de sistema de alto nivel y la alineación entre sistemas y funciones comerciales.
• Cree una hoja de ruta de componente de tecnología para desglosar los componentes específicos de un sistema que se implementarán para ayudar con la planificación de recursos y los requisitos de activación. Este tipo de hoja de ruta muestra información a nivel de componente y requisitos de implementación (por ejemplo, desarrollo declarativo, código pro, etc.).

Asegúrese de que sus hojas de ruta contienen cronologías realistas. Un error común es incluir solo la cantidad de tiempo que tomará implementar un sistema sin considerar también la cantidad de tiempo que tomará completar actividades relacionadas. Esto puede dar como resultado una asignación excesiva de miembros del equipo de implementación y retrasos más largos de lo previsto. Al crear una hoja de ruta, tenga en cuenta el tiempo que tardará en completar lo siguiente:

• Documentación de todas las funciones nuevas y actualizadas
• Mantenimiento de funciones existentes necesarias para dar cobertura a nuevas funciones
• Actualizaciones en sistemas relacionados requeridas para admitir integraciones
• Apoyo elevado de los equipos de proyectos inmediatamente después del lanzamiento
• Pruebas, formación y gestión de cambios

Las hojas de ruta comerciales y tecnológicas que están bien alineadas comunican una visión integral de cuándo se pondrán en marcha las funciones y qué tecnología hay detrás de ellas. La lista de patrones y antipatrones a continuación muestra el aspecto de las hojas de ruta apropiadas (y deficientes) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de hoja de ruta.

Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle con la hoja de ruta, consulte Herramientas relevantes para intencionado.

La gobernanza es la estructura que utiliza para gestionar la priorización, la toma de decisiones y la gestión de cambios con sus partes interesadas. La gobernanza deja claro cómo se toman y comunican las decisiones. Proporciona formas coherentes para que los comentarios y las solicitudes entren en el proceso de toma de decisiones, y para que todas las partes interesadas comprendan el estado del trabajo de mantenimiento y desarrollo. La gobernanza ayuda a que los procesos de gestión de versiones sean claros y coherentes, y ayuda a todos los miembros del equipo a comprender sus funciones y responsabilidades.

Sin una gobernanza apropiada, los equipos experimentarán una variedad de problemas, incluyendo:

• Las solicitudes de funciones y funciones superpuestas llegan ad hoc
• Los equipos de implementación priorizan esfuerzos "más sencillos" o solicitudes de partes interesadas más influyentes, sin tener en cuenta adecuadamente el valor comercial, las compensaciones o los objetivos organizativos generales
• Falta de procesos coherentes de aprobación y revisión
• Calidad y cadencias de liberación incoherentes
• Altos índices de defectos, sobrescrituras, conflictos y trabajo redundante en los esfuerzos de desarrollo

Quizás la señal más clara de que un sistema no tiene una regulación efectiva es la lentitud y la incomodidad de las versiones. Es importante reconocer que el tamaño de un sistema de gobernanza no es una medición de su eficacia. De hecho, los sistemas elaborados de gobernanza (como los que se encuentran en muchas grandes empresas) pueden reducir la velocidad y la frecuencia de las liberaciones.

El buen gobierno consiste en dificultar que las malas personalizaciones superen las etapas tempranas del desarrollo y que las buenas personalizaciones lleguen a producción de forma predecible y coherente.

Con demasiada frecuencia, los esfuerzos de gobernanza son reaccionarios. Se inician o redoblan cuando un problema, como una deuda técnica excesiva, comienza a convertirse en un problema comercial. En muchos casos, la respuesta desafortunada es que el negocio “bloquee” los esfuerzos y versiones de desarrollo, en vez de crear estándares de diseño efectivos y crear automatización para aplicar esos estándares en cadenas de herramientas de desarrollador y sistemas de control de origen.

Cuando cree el marco de trabajo para su sistema de gobernanza de Salesforce, incluya los siguientes elementos y considere estas preguntas clave para responder:

• Solicitudes de trabajo. ¿Cómo pueden los usuarios solicitar funciones o características? ¿Cómo se reportan los fallos?
• Priorización y planificación del trabajo. ¿Quién decide qué solicitudes de trabajo importan? ¿Cómo se define el ámbito, la prioridad y la aceptación o la firma del trabajo?
• Entornos y planificación de versiones. ¿Cuál es la canalización de entorno para desarrollo, pruebas y versión? ¿Quién hace qué para aprovisionar, actualizar y proporcionar acceso? ¿Quién gestiona las implementaciones y la validación? ¿Cómo y cuándo se publican los cambios? ¿Cómo gestiona implementaciones o entornos durante un ciclo de versión de Salesforce? (Para obtener más información sobre esto, consulte Gestión del ciclo de vida de aplicaciones.)
• Propiedad de servicios y asistencia de producción. ¿Quién apoya qué? ¿Quién gestiona problemas de producción de “solución rápida”? ¿Cómo se prueban y se publican esos elementos? ¿Quién es responsable de los estándares de seguridad generales de la organización?

La lista de patrones y antipatrones que aparece a continuación muestra el aspecto de la gobernanza adecuada (y deficiente) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de gobernanza.

Para obtener más información acerca de las herramientas de Salesforce disponibles para la gobernanza, consulte Herramientas relevantes para intencional.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su solución.

✨ Descubra más patrones para la estrategia en el Explorador de patrones y antipatrones.

La capacidad de mantenimiento significa que un sistema se puede mantener en un estado saludable, con nuevas funciones moviéndose y deuda técnica saliendo del sistema de forma regular y predecible. Los sistemas con capacidad de mantenimiento permiten a sus equipos entregar valor al negocio con velocidad y calidad predecibles. La capacidad de mantenimiento de un sistema depende de varios factores, incluyendo cuán legible es, cuán acoplado está libremente y cuán minuciosa es su estrategia de prueba.

Lo que es más importante, la mantenibilidad de un sistema depende de la sencillez de su diseño. Esta sección trata formas de crear diseños de soluciones más sencillos y aumentar la capacidad de mantenimiento.

Puede crear soluciones que son más fáciles de mantener centrándose en dos claves: el uso de funciones estándar sobre personalizadas y la gestión de deudas técnicas.

Salesforce ofrece una gama de soluciones preconstruidas: Sales Cloud, Service Cloud y muchas soluciones del sector de Salesforce, así como la flexibilidad de crear sus propias soluciones personalizadas. Los servicios básicos que impulsan las soluciones en la nube propias de Salesforce también están disponibles para cualquier solución personalizada creada sobre Salesforce Customer 360 Platform. Utilice los servicios y soluciones preintegrados de Salesforce como base de confianza para tantas soluciones como sea posible.

El uso de servicios de plataforma preintegrados tiene dos beneficios diferentes. En primer lugar, sus aplicaciones se benefician naturalmente de las últimas innovaciones de Salesforce con cada versión. En segundo lugar, sus equipos de desarrollo pueden centrarse en ampliar y profundizar las funciones comerciales proporcionadas por sus soluciones de Salesforce en vez de gestionar trabajos pesados arquitectónicos básicos.

Seleccionar correctamente cuándo utilizar funciones estándar y cuándo crear funciones personalizadas no es un reto desde un punto de vista arquitectónico. Las claves son:

• Personalizar la plataforma significa modificar y ampliar, no copiar. A medida que diseña o evalúa su arquitectura, debe preguntar: ¿Existe esto ya en algún punto de la plataforma Salesforce? Si la respuesta es “Sí, pero...[inserte cambios que una parte interesada comercial desea aquí...]”, utilice la función preconstruida en la plataforma. El trabajo arquitectónico que se debe realizar es identificar las formas más útiles de configurar la función preconstruida de Salesforce para cumplir las expectativas comerciales.
• Ninguna personalización es trivial. Con el tiempo, cada cambio tiene consecuencias. Si necesita implementar una solución personalizada, puede mitigar la inevitable deuda técnica que generará su sistema eligiendo utilizar tecnología de código bajo siempre que sea posible y creando unidades que se pueden componer en sus implementaciones.
• Considere el espectro de creación-compra. Salesforce AppExchange es un mercado de aplicaciones y soluciones para ampliar Salesforce. Las aplicaciones AppExchange pueden entregar funciones sin el gasto que implica crear y mantener una solución personalizada. Tenga en cuenta lo siguiente cuando evalúe soluciones AppExchange:
  • Identifique funciones y brechas de soluciones. Idealmente, encontrará una aplicación que cumpla todos sus requisitos comerciales. En realidad, es posible que no encuentre un ajuste perfecto. A medida que evalúa soluciones, asigne funciones en la posible solución a una lista priorizada de requisitos comerciales. Esto le ayudará a encontrar la solución que mejor cumpla sus requisitos más críticos.
  • Utilice entornos sandbox y pruebas gratuitas. Utilice periodos de prueba gratuitos para evaluar aplicaciones en entornos sandbox e identificar el mejor ajuste. Determine si las aplicaciones le requerirán realizar cambios de configuración que entren en conflicto con su configuración existente.
  • Considere los costes a corto y largo plazo. Evalúe los ahorros de mantenimiento de aplicaciones a largo plazo frente a los costes recurrentes de aplicaciones basadas en suscripciones. Evite escenarios donde tenga que pagar costes recurrentes por muchas funciones que sus partes interesadas comerciales nunca utilizarán.
• Utilice los modelos de datos preintegrados desde Salesforce. Salesforce proporciona modelos de datos preintegrados para Ventas, Servicio y una variedad de verticales del sector. El uso de los modelos de datos proporcionados por Salesforce garantiza que las funciones en su sistema se definan solo una vez (eliminando la redundancia y los silos), establece una única fuente de verdad en todo el sistema, facilita la comprensión de los datos de la aplicación con análisis, facilita el uso de los servicios de inteligencia artificial preintegrados de Salesforce, reduce los costes de mantenimiento (reduciendo las personalizaciones que necesita asistencia) y reduce la deuda técnica.

Así de simple. Como puede ver en los patrones y antipatrones a continuación, los antipatrones se reducen a replicar funciones estándar en una solución personalizada o utilizar tecnología más compleja para entregar personalizaciones.

En la práctica, es posible que se encuentre con un escenario en el que las partes interesadas comerciales vean un antipatrón de funcionalidad personalizado como la mejor o única forma viable de avanzar. En estos casos, es esencial que explique a las partes interesadas las compensaciones implicadas en la elección de este camino y luego documente minuciosamente la decisión, su justificación y su implementación. Este es también un área donde la entrega temprana de valor principal y la adaptación con el tiempo pueden ayudar sus partes interesadas a comprender mejor el mejor camino a seguir.

Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle a aumentar la capacidad de mantenimiento, consulte Herramientas relevantes para intencionado.

La deuda técnica es una parte natural de cualquier sistema. Los diseños de sonido de ayer pueden convertirse en antipatrones cuando cambian las necesidades tecnológicas o comerciales. Quizás algo creado para rellenar un vacío en la funcionalidad de la plataforma Salesforce de repente se vuelve redundante con una nueva versión de Salesforce o lanzamiento de producto. Quizás una tecnología más eficiente o flexible sustituya a una tecnología que ya implementó. La deuda técnica se puede crear de muchas formas.

Un beneficio clave de la creación de aplicaciones con Salesforce Customer 360 Platform es la retrocompatibilidad incorporada en la plataforma. Esto significa que las nuevas innovaciones de plataforma pueden cambiar el patrón que debe utilizar para soluciones en adelante, pero la función diaria de soluciones que creó en tecnologías anteriores de Salesforce seguirá funcionando. Con el tiempo, cualquier solución basada en tecnología anterior comenzará a plantear riesgos o cuellos de botella para agregar nuevas funciones a sus aplicaciones y reducir el estado general de la solución.

La planificación y realización de trabajo regular para solucionar la deuda técnica es esencial para mantener diseños sencillos y saludables en una solución de Salesforce. No planificar, auditar y remediar la deuda técnica es una forma segura de crear un sistema mal diseñado.

Una forma de minimizar la deuda técnica es evitar introducirla tanto como sea posible, evitando accesos directos y prefiriendo la funcionalidad estándar sobre la personalizada. Los accesos directos, como los valores de codificación, pueden ser tentadores para ahorrar tiempo, pero a largo plazo crean deudas que se deben pagar.

Las claves para abordar la deuda técnica desde una perspectiva arquitectónica incluyen:

• Identificación del coste o beneficios reales para el negocio de acción frente a la inacción
• Hoja de ruta adecuada
• Construcción de soluciones componebles

La dificultad puede ser conseguir que las partes interesadas estén alineadas con la acción. Algunas partes interesadas pueden percibir el mantenimiento continuo como la solución de “errores de ayer” o la eliminación de las funciones que desean que admita su presupuesto.

Mostrar las repercusiones comerciales reales de la acción y la inacción, junto con entregas y plazos claramente definidos, puede ayudar sus partes interesadas a comprender el valor y la prioridad relativa de abordar la deuda técnica. Hacer el trabajo de forma coherente para conectar la deuda técnica con impactos comerciales no solo ayudará a sus partes interesadas a comprender mejor el trabajo que se debe realizar. También le ayudará a asegurarse de que está identificando y abordando la deuda técnica de formas que realmente benefician a los usuarios.

La lista de patrones y antipatrones a continuación muestra el aspecto adecuado (y deficiente) de la gestión de deudas técnicas para una organización de Salesforce.

Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle con deudas técnicas, consulte Herramientas relevantes para intencionado.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su solución.

✨ Descubra más patrones para la capacidad de mantenimiento en el Explorador de patrones y antipatrones.

En esencia, el concepto de legibilidad consiste en crear coherencia que facilita a las personas la comprensión de cómo funcionan las cosas. La creación de sistemas legibles alinea los equipos de entrega y mantenimiento, y ayuda a las personas que no están familiarizadas con el sistema a comprender rápidamente cómo encajan las piezas. Significa que su equipo puede depender menos de personas individuales con Knowledge institucional o histórico para incorporar de forma efectiva proveedores o nuevos miembros del equipo. Significa que las personas expertas en un equipo pueden centrarse en la calidad y las ventajas de las opciones que se están realizando, porque la configuración y el código del sistema son fáciles de leer y comprender para los humanos. La legibilidad puede acelerar los procesos de gobernanza y garantía de calidad, y ayudar los equipos a identificar mejor cuándo podrían crear personalizaciones redundantes. También puede aumentar las posibilidades de tener un sistema que se comporte de formas reutilizables y comprobables.

Puede aumentar la legibilidad a través de estándares de diseño y documentación efectivos.

Los estándares de diseño proporcionan directrices para mantener todas las personalizaciones coherentes, incluso en las etapas más tempranas del desarrollo. Los estándares de diseño actúan como barandillas, manteniendo todos los equipos de entrega y mantenimiento trabajando en su sistema alineados en cómo abordar e implementar personalizaciones. La definición de estándares de diseño ayuda a potenciar la productividad de sus equipos de entrega y mantenimiento, facilita la realización de revisiones de código y arquitectura y proporciona una base para una mejor documentación.

Sin estándares de diseño, los equipos tienen más probabilidades de trabajar en silos. Sin la coherencia que proporcionan los estándares de diseño, los negocios se encontrarán en dificultades con:

• Los proveedores y equipos de desarrollo utilizan patrones y enfoques ad hoc entre soluciones, lo que podría introducir antipatrones y reducir la reutilización (consulte Separación de problemas).
• Mayor tiempo para resolver problemas de producción y equipos de asistencia requeridos para incorporar nuevos miembros del equipo y ayudarles a comprender un conjunto dispar de patrones y enfoques.
• Mala colaboración entre equipos, redundancias en el trabajo entre equipos, tiempo perdido resolviendo conflictos y fallos descubiertos durante las pruebas de integración.
• Mayor frustración y mayores índices de rotación.

Un beneficio clave de los estándares de diseño se deriva de las conversaciones y decisiones que las partes interesadas deben tomar para crearlos. Específicamente, el proceso proporciona a su negocio y a los candidatos de tecnología la oportunidad de alinearse en torno al aspecto óptimo del diseño para su negocio.

Incluya lo siguiente en sus estándares de diseño

• Convenciones de nomenclatura para metadatos de Salesforce. Defina un conjunto de convenciones para el nombre de cada personalización en un sistema. Las buenas convenciones de nomenclatura no solo aplican la coherencia entre los nombres de objetos, campos, código, flujos y otros elementos de su sistema. Las buenas convenciones de nomenclatura también ayudan a los equipos de desarrollo a utilizar nombres que transmiten información acerca del propósito y la funcionalidad de lo que están creando. Como resultado, otras partes interesadas pueden comprender mejor una personalización en particular, solo viendo su nombre.
• Patrones de diseño aprobados y sus casos de uso. Establezca una biblioteca de Pattern & Anti-Pattern Explorer, junto con información clave sobre cuándo (y cuándo no) utilizar cada patrón. La biblioteca podría incluir patrones de desencadenador Apex requeridos o patrones de orquestación de flujos basándose en la capacidad de composición que desea en su sistema.
• Entorno de desarrollo y orientación de herramientas. Mantenga una lista clara de las herramientas que los equipos de desarrollo deben utilizar para su trabajo. Esto podría incluir idiomas y cadenas de herramientas aprobados para cualquier usuario que escriba código o funciones declarativas que estén (o no) aprobadas para el desarrollo de código bajo. Sus estándares podrían incluir una lista de sistemas de control de origen para la personalización y documentación, así como pasos de registro/salida obligatorios. También pueden incluir una lista de entornos que se utilizarán para diferentes tipos de trabajo de desarrollo.

Además de definir estos estándares, tendrá que decidir cómo y dónde mantenerlos y almacenarlos. Si los equipos de toda su empresa no pueden encontrar sus estándares de diseño (o ni siquiera saben que existen), no serán efectivos. Idealmente, sus estándares de diseño viven dentro del mismo sistema que su documentación (consulte la siguiente sección para obtener más información).

La lista de patrones y antipatrones a continuación muestra el aspecto de los estándares de diseño apropiados (y deficientes) para una organización de Salesforce. Puede utilizarlos para validar o mejorar sus estándares de diseño.

Para obtener más información acerca de herramientas de Salesforce que pueden ayudarle a definir estándares de diseño, consulte Herramientas relevantes para intencionado.

La documentación explica el qué, el cómo y el por qué de su sistema. Sin documentación significativa y coherente, los equipos pierden mucho tiempo intentando comprender el sistema tal cual es (y posiblemente malinterpretando funciones y personalizaciones).

Una buena documentación tarda tiempo en crearse. Aunque la mayoría de los equipos están de acuerdo en que la documentación es importante para proyectos de gran tamaño, puede ser un paso tentador omitir al realizar cambios rápidos como actualizaciones de configuración o pequeños ajustes en una automatización. No documentar los cambios que realiza en su sistema siempre es un antipatrón. La omisión de documentación puede ahorrar una pequeña cantidad de tiempo por adelantado, pero la cantidad de tiempo necesaria para solucionar problemas de una organización que no está debidamente documentada cancelará con creces esos ahorros de tiempo. Incluya siempre tiempo suficiente para crear documentación en todas sus estimaciones, independientemente del nivel de esfuerzo requerido para las actualizaciones que está planificando realizar.

La falta de documentación clara puede dar lugar a diversos problemas, entre ellos:

• Ciclos de desarrollo empleados en la reelaboración de implementaciones existentes
• Debates repetitivos que vuelven a examinar o desconciertan decisiones anteriores
• Incorporación más larga para nuevos miembros del equipo o proveedores
• Exceso de dependencia de individuos con Knowledge institucional o histórico
• Arquitecturas redundantes para admitir las mismas funciones o funciones similares en todo el negocio
• Dificultad para comunicar el propósito y el valor de su solución a partes interesadas clave

Para soluciones de Salesforce, mantenga la documentación para:

• Descripciones generales de soluciones. Los diagramas le permiten a usted y a sus partes interesadas visualizar soluciones con varios niveles de detalle. El marco de trabajo de diagramas de Salesforce le ayuda a crear diagramas que muestran las funciones comerciales de las soluciones, así como detalles de implementación técnica.
• Registros de decisiones. Mantenga un registro de las opciones consideradas, las compensaciones, la decisión final y el razonamiento en una ubicación central a la que todos los miembros del equipo puedan acceder para referencia futura.
• Código. El formato del código en sí es una pieza clave de la documentación, y esto puede (y debe) alinearse con sus estándares de diseño. También querrá tener un registro de información clave y actualizarlo con cada modificación de un fragmento de código. Para todas las clases, desencadenadores y componentes, documente lo siguiente:
  • Quién escribió el código
  • Cuando se escribió el código
  • Lo que se supone que debe hacer el código
  • Dependencias clave
  • Todos los cambios
• Personalización declarativa. Para cada tipo de personalización que se puede realizar en los metadatos en su organización, Salesforce proporciona atributos integrados para que los equipos proporcionen información útil acerca del propósito y la intención de los metadatos. Como parte de sus estándares de diseño, incluya cómo utilizarán los equipos estas funciones integradas y cómo asignarán nombres a personalizaciones declarativas. Mantenga también un registro de información clave que sea idéntica a la que utiliza para el código.

Desarrolle un conjunto de estándares de documentación para garantizar que todos los miembros del equipo actuales y futuros puedan interpretar documentos de la misma forma. (los estándares de diseño pueden ayudar con esto.) También es importante considerar cómo los usuarios podrán buscar documentación para encontrar secciones o términos relevantes. A medida que su sistema envejece y crece en complejidad, su documentación también crecerá. La utilidad de la información en su documentación estará directamente relacionada con la frecuencia, la rapidez y la facilidad con que los usuarios pueden buscar y encontrar elementos relevantes.

La lista de patrones y antipatrones a continuación muestra el aspecto de la documentación adecuada (y deficiente) para una organización de Salesforce. Puede utilizarlos para validar o mejorar su estrategia de documentación.

Para obtener más información acerca de las herramientas de Salesforce para la documentación, consulte Herramientas relevantes para intencional.

La siguiente tabla muestra una selección de patrones para buscar (o crear) en su organización y antipatrones para evitar o dirigir para su solución.

✨ Descubra más patrones para la legibilidad en el Explorador de patrones y antipatrones.

Ayúdenos a mantener Salesforce Well-Architected relevante para usted; realice nuestra encuesta para proporcionar comentarios sobre este contenido y díganos qué le gustaría ver a continuación.