La documentación es una parte crucial del éxito de los proyectos de Salesforce. En este artículo, presentaré un conjunto de artefactos de documentación que son esenciales para cualquier proyecto saludable, grande o pequeño. Al final del artículo, debería:
- Entender la diferencia entre documentos técnicos y funcionales;
- Ser capaz de identificar los artefactos técnicos y funcionales de alta prioridad;
- Tener acceso a un conjunto de herramientas y recursos para reducir el tiempo dedicado a la producción de estos documentos.
- Tener acceso a un conjunto de herramientas y recursos para reducir el tiempo dedicado a la producción de estos documentos
Asegurarse de que este conjunto de artefactos críticos se incluye en su proyecto puede ahorrar tiempo, presupuesto y dolores de cabeza en el futuro.
Documentación funcional y técnica
Cada org de Salesforce que gestione debe tener un conjunto de documentos funcionales y técnicos coherentes que lo respalden.
- Documentación funcional describe el negocio y los requisitos empresariales que soporta la solución técnica. Define el por qué de la solución.
- Documentación técnica describe «cómo» la solución cumple los requisitos empresariales. Fundamenta las decisiones técnicas y explica a los lectores cómo se pretende que funcione el sistema.
- La documentación técnica
Los artefactos funcionales y técnicos son diferentes pero igualmente importantes para formar una imagen completa de la solución entregada que sea concisa, contextualizada, coherente y conectada.
Consejo profesional: Puede aumentar el valor de su documentación asegurándose de que sus artefactos técnicos están vinculados a los requisitos funcionales que soportan. Consulte la metodología de descomposición funcional para aprender a relacionar las soluciones con los requisitos.
A continuación, explicaré los artefactos funcionales y técnicos más importantes que debe incluir en sus implementaciones de Salesforce.
Artifactos funcionales
Los artefactos funcionales esbozan el problema a resolver y definen qué valor debe aportar la solución a la organización. Los artefactos funcionales críticos para los proyectos de implementación de Salesforce incluyen:
- Glosario empresarial: Resume la terminología empresarial clave para ayudar a los equipos de proyecto a desarrollar un lenguaje compartido correcto y cohesivo con el cliente. Más adelante, puede utilizar el glosario para ayudar a documentar los cambios de etiquetas de Salesforce.
Ejemplo:
| Término | Acrónimo | Definición |
|---|---|---|
| Alianza de Asociaciones | PA | Un grupo de usuarios internos con los mismos privilegios de todos los departamentos que son responsables de las decisiones estratégicas relacionadas con las asociaciones. |
| Director de Alianzas | PM | Una única persona responsable de gestionar una cartera de DOP. El PM informa de los progresos al PA. |
| Socio Operativo Directo | DOP | Un socio externo que interactúa directamente con los Gestores de Partenariados. Los DOP son responsables de la presentación de informes financieros a la AP y de la gestión de los POI. |
| Socio Operativo Indirecto | IOP | Socio externo que se relaciona indirectamente con la organización a través de los DOP. Los IOP interactúan con los DOP, salvo en circunstancias excepcionales en las que el DOP puede elevar los problemas al PM o al PA. Los IOP son responsables de llevar a cabo las tareas dirigidas por el DOP. |
- Org Chart o Stakeholder Map: Describe los roles y su jerarquía en el negocio. Los organigramas se pueden utilizar para ayudar a definir la jerarquía de roles y esbozar la propiedad de los registros por hacer durante el diseño de la solución.
- Organograma o mapa conceptual
- Modelo conceptual: Esboza las entidades clave (funcionales) y sus relaciones antes de desarrollar el modelo de datos técnicos. Los modelos conceptuales se redactan normalmente durante la fase de descubrimiento y pueden utilizarse posteriormente para validar el modelo lógico o ERD; no tienen que ajustarse necesariamente a los objetos de Salesforce.
- Modelo funcional: describe las entidades clave (funcionales) y sus relaciones antes de desarrollar el modelo de datos técnico
- Diagrama de descomposición funcional: cuenta la «historia» funcional de la empresa, destacando las funciones y procesos empresariales clave. Asegurarse de que cada proceso de nivel inferior esbozado en el diagrama tiene al menos una historia de usuario puede ayudar a garantizar que su corpus de historias de usuario está completo.
- Diagrama de descomposición funcional: cuenta la «historia» funcional de la empresa, destacando las funciones y procesos empresariales clave
- Flujos de procesos: Esbozar los procesos de negocio clave para ayudar a apoyar una comprensión general del negocio. Universal Process Notation es el estilo de notación recomendado para los proyectos de Salesforce
- Personas: Describa los grupos de usuarios a los que prestará asistencia la solución. Los personajes proporcionan una estructura centrada en el usuario para los requisitos y ayudan a garantizar que la solución proporciona un valor demostrable a las personas reales de la empresa
- Personajes, historias de usuario y criterios de aceptación del usuario: Resuma los requisitos que deben resolverse en un formato digerible y centrado en el usuario, así como los criterios utilizados para validar si la solución cumple el requisito. Las historias de usuario deben seguir el marco «INVEST», y los criterios de aceptación del usuario pueden estructurarse utilizando enunciados «Dado, Cuándo, Entonces» para mejorar la calidad.
- Criterios de aceptación del usuario
Artifactos técnicos
Los artefactos técnicos describen el estado a ser y la solución entregada, ayudando a los lectores a entender cómo la solución soporta los requisitos de negocio. Los artefactos técnicos críticos para los proyectos de implementación de Salesforce incluyen:
- Resumen narrativo de la solución: Proporciona un resumen en lenguaje sencillo de cómo la solución respalda los requisitos empresariales, incluidas las funciones clave y las decisiones de diseño, los productos y las herramientas, y las limitaciones.
- Los elementos clave de la solución son los siguientes
- Modelo lógico: Describe los objetos y sus relaciones. Este ERD debe ajustarse a las relaciones de entidad conceptuales del modelo conceptual, pero debe modificarse para hacer referencia a los objetos estándar y personalizados de Salesforce.
- Modelo lógico: describe los objetos y sus relaciones
Consejo profesional: Anote su modelo lógico con los volúmenes de datos previstos, la configuración predeterminada en toda la organización (OWD) sugerida para el objeto y el propietario de registro previsto para mejorar su utilidad.
- Diagrama del sistema: Se debe utilizar un diagrama del entorno del sistema actual y futuro para describir el entorno actual de herramientas y tecnologías, así como la visión futura de cómo Salesforce interactuará con otros sistemas.
- Diagrama del entorno del sistema
- DevOps Pipeline o diagrama de gestión de versiones: Describe su estrategia y procesos de gestión de versiones, incluidos los entornos relevantes (sandboxes) utilizados en su proceso de desarrollo.
Ejemplo (simplista):
- Resumen de seguridad y uso compartido: Proporciona un resumen en el lenguaje del plan de los permisos de objetos y la estrategia de acceso a registros utilizada en la org, incluida la referencia a cualquier herramienta, protocolo y mecanismo de seguridad de datos.
- Automatización
- Seguridad y uso compartido
- Especificaciones de automatización: Proporcionar una representación visual de la automatización en la org, incluido el contexto de activación y cualquier acción invocable para que los lectores puedan comprender rápida y fácilmente el panorama de la automatización y cómo las diversas piezas de automatización pueden influir o apoyarse mutuamente.
- Especificaciones de automatización
- Diccionario de metadatos:
Ahorra tiempo con las plantillas
Cada proyecto de implementación viene con un conjunto de restricciones. Estas pueden estar relacionadas con el plazo de entrega, el presupuesto, las competencias y el compromiso con los procesos acordados. Cuando los recursos son escasos, los equipos deben hacer todo lo posible por ceñirse al proceso. La clave está en contar con una estrategia fiable que ayude a su equipo a entregar documentación de calidad de forma eficiente.
Existen innumerables herramientas en el ecosistema de Salesforce para ayudar a estandarizar y crear plantillas de documentos clave:
- Salesforce Architects cuenta con un tesoro de diagramas, modelos y marcos de trabajo precreados a su disposición de forma gratuita.
- Salesforce Architects cuenta con un tesoro de diagramas, modelos y marcos de trabajo precreados a su disposición de forma gratuita
Consejo profesional: Abra ciertos diagramas y modelos de datos en LucidChart para convertirlos en la marca de su organización. Guarde el nuevo documento como plantilla para utilizarlo como punto de partida en cada nuevo proyecto.
Consejo profesional: Salesforce se integra con LucidChart, lo que le permite importar información de su organización directamente a Lucid, como su esquema de objetos para una creación más rápida de diagramas de modelos de datos.
Consejo profesional: Utilice esta plantilla de estrategia de documentación de Salesforce para crear rápidamente su estrategia y ayudar a su equipo a mejorar la coherencia y calidad de la documentación.
Su equipo también puede «desplazar a la izquierda» el esfuerzo dedicado a la documentación mediante la creación de plantillas de los artefactos clave descritos anteriormente. Esto garantizará la coherencia y corrección de su corpus de documentación para cada proyecto y ahorrará tiempo a los miembros del equipo en la generación de nuevos artefactos.
Resumen
La generación de documentación lleva tiempo, pero un conjunto enfocado de documentación de alta calidad siempre ahorrará tiempo a largo plazo al ayudar a su equipo a entender, mantener, depurar y mejorar su sistema a largo plazo.
Antes de embarcarse en su próximo proyecto de Salesforce, acuerde los artefactos críticos con su equipo y establezca plantillas para ayudar a que su documentación sea mejor y más rápida.
El autor
Caitlin Graaf
Caitlin es arquitecta de soluciones Salesforce en Vera Solutions, interesada en el diseño de sistemas que apoyen el cambio social positivo. Su formación combina la experiencia en el sector sin ánimo de lucro, la metodología de investigación cualitativa y la fluidez técnica de Salesforce, proporcionando una base para su especialización en la práctica del análisis empresarial. Más información sobre Caitlin en Medium.
