En el Post pasado comentamos como se hace el Levantamiento Inicial de un proyecto. Platicamos como hay que entender el proyecto primero a nivel muy general, definiendo la Necesidad o Misión del proyecto, para después irlo bajando a Objetivos más específicos, y finalmente a nivel de Historias de Usuario o Escenarios de Comunicación o Desatendidos.

Pero antes de hacer las Historias necesitamos entender muchas más cosas a detalle, principalmente los procesos de negocio que se pretenden sistematizar, incluyendo todas las reglas y personas que participan. Esto lo realiza normalmente un analista, pero es importante que los desarrolladores entiendan todo proceso que estén desarrollando. Recuerda que muchas veces el Product Owner y los usuarios no conocen estos conceptos, por lo que tienes que usar tu experiencia y conocimiento para poder entender y validar lo que realmente es importante.

A continuación, veremos qué es lo importante que debes de saber.

¿Qué es un Proceso de Negocio?

Para empezar a entender los procesos que se desean automatizar. Es necesario primero saber que es un proceso:

“Un proceso es una serie de pasos, ejecutados por uno o más roles, para convertir insumos de entrada en un resultado de salida.”

En resumen, un proceso es simplemente tener una Entrada (input), realizar un proceso, y generar una Salida (output). Es algo que debe de ser completamente natural para un desarrollador, porque eso es lo que hacemos todo el tiempo cuando programamos. Tomamos datos de entrada, realizamos un procesamiento, proceso, o función, y generamos una respuesta.

Con esto, podemos empezar haciendo una lista de cada uno de los procesos que se desean automatizar. Luego, lo que necesitamos entender de cada Proceso es:

Roles

Empezamos por entender cuáles son los Roles de las personas que participan en el proceso. Hay que enfocarse específicamente en los que si utilizarán el sistema.

“Un Rol es un usuario, o grupo de usuarios, que comparten los mismos permisos y funciones en el proceso.”

Es bueno tratar de aclarar que permisos debería tener cada uno de los Roles. Que si puede ver. Que no puede ver. Que si puede hacer. Que no puede hacer. Y como estas interacciones cambian el flujo del proceso.

Es importante separar bien los roles, y al mismo tiempo agrupar los permisos en la menor cantidad de roles. Mientras más roles, más complejos se vuelve el sistema, hasta el momento que va a ser más fácil hacer un sistema de permisos algo que aumenta mucho la complejidad.

Existen casos donde no hace falta crear roles adicionales. Un ejemplo típico es los vendedores, que solo deben de tener acceso a sus clientes y no a los de los demás vendedores. En este caso no hace falta un Rol por vendedor. Simplemente se define dicha regla y se aplica a todas las Historias del Vendedor.

Muchos procesos requieren autorizaciones. Es importante también mencionar estos Roles que “solo” autorizan, y poner atención en las reglas de autorización.

Trigger o Detonador

Un detonador o Trigger es la acción que provoca la ejecución de un proceso, que detona el Proceso. Este puede ser detonado por algo externo, como un cliente que hace una compra, o un proveedor que entrega un pedido, o algo interno como otro proceso. Es importante entender estos detonadores porque son los que conectan los procesos en un sistema.

Inputs y Outputs

Todo proceso es una serie de pasos para transformar uno, o varios Inputs, en uno o varios Outputs. Es importante aclarar con el cliente esta información. Entender que es lo que el cliente genera con el proceso nos ayudará a entender la expectativa del cliente. Muchas veces es solo documentación, otras veces pueden ser materiales o productos, incluso una simple comunicación verbal, lo importante es que se identifiquen y sepamos para que se usan.

• Inputs típicos
  • Documentos físicos.
  • Capturas de información.
  • Decisiones o aprobaciones.
  • Información de otros sistemas.
  • Archivos de textos, Xml, Csv, etc.
• Outputs típicos
  • Captura de la información en una BD.
  • Pantalla de Detalle.
  • Conexión con otros sistemas.
  • Solicitudes de autorización.
  • Envíos de mercancía.

Flujo del Proceso

Para entender el proceso, es bueno tener un contexto general, de punta a punta, pero sin profundizar a detalle en lo que se realiza en cada paso, al menos que el paso se pretenda ejecutar en el sistema. Hay que ayudar al cliente a enfocarse en los procesos que se desean sistematizar, para que te de toda la información necesaria.

Los procesos deben de estar explicados en base a los Roles. Ej. El [Rol] entra al sistema, y crea un nuevo documento. Posteriormente el [Rol] revisa el documento y lo aprueba. Esto detona una orden a almacén donde el [Rol] saca el material y lo entrega al cliente.

No puedes esperar que el cliente te vaya a decir todo el proceso a detalle. Cuando estás muy familiarizado con un proceso, es común olvidarse de variantes, cambios o excepciones que surgen durante el proceso. Pregúntale al cliente cosas que en tu veas que puedan pasar, casos típicos son:

• ¿Qué pasa si una persona no aprueba?
• ¿Qué pasa cuando el proceso requiere un cambio?
• ¿Qué pasa si a la mitad del proceso se desea cancelar?
• ¿Qué pasa cuando un [Rol] se equivoca?
• ¿Qué pasa cuando falta X información?

Preguntas de este tipo le ayudarán al cliente a recordar variantes o excepciones que haya olvidado.

Recuerda que primero hay que entender el “Happy Path”, que es lo que pasa cuando todo sale bien. Pero es igual de importante entender las Excepciones, que pasa cuando se cortan los procesos o existen errores. Enfatiza con el cliente que pasa en estas Excepciones.

Reglas de Negocio y Estatus del Proceso

Las Reglas de Negocio definen todas las posibilidades y decisiones que se pueden necesitan durante la ejecución del Proceso. En base a estas reglas, se generan los Estatus en los que se puede encontrar el proceso.

Necesitamos entender cuáles son todas las variables que puede tener el proceso y los diferentes caminos que puede tomar. Que Inputs adicionales se necesitan. En que cambian estos caminos los outputs diferentes Outputs. En basé a cada camino debe de existir uno o múltiples estatus en los que se puede encontrar el proceso. Entender dichos estatus es la base para poder sistematizar un proceso.

Necesitamos conocer la información, o variables, que detonan cambios en el flujo del proceso. Esto es muy importante, porque cada campo, que puede generar un cambio en estatus que se acumula con los demás para generar nuevas posibilidades de manera exponencial. Todos estos se reflejan en diferentes estatus.

Finalmente hay que definir cuáles son los estatus en los que puede estar el proceso. Como pueden cambiar dichos estatus. De qué estado se puede cambiar a que estado, y como o porque podría cambiar. Es indispensable

Información Adicional

Al ir entendiendo el proceso que nos presenta el cliente, es importante ir visualizando las diferentes Historias de Usuario que se van generando. Recuerda que las Historias de Usuario no son el proceso, son interacciones que surgen de los requerimientos del proceso, para que un Rol requiera de interacción con el sistema.

Recuerda solicitar al cliente cualquier tipo de información que pueda ayudar a entender mejor su proceso y requerimiento.

• Es común que tengan ejemplos de otros sistemas que utilizan actualmente, o que conocen. Si es así solicita que te muestren el proceso en el sistema. Es mucho más fácil darte una idea de cómo diseñar el sistema si ya existe otro para darte idea.
• Si tienen documentos físicos, o archivos, como parte de su proceso actual, solicita copias de referencia de estos documentos. Estos nos ayudarán a definir los Inputs y los Outputs que requiere el sistema.

Tener cuidado con cosas como:

• Comentarios del tipo: “No sé cómo hacerlo, o como se hace, pero necesito que solucione esto”. Esto usualmente indica que requieren consultoría de procesos, no desarrollo.
• Gente que va dictando como debe de ser el sistema, en vez de decir los requerimientos que tiene. Haz que se enfoque en el requerimiento que es lo que tienes que entender, después podrán hablar de detalles de diseño.
• Que no compartan información, o que no conozcan bien el proceso. De ser así posiblemente no sean los Key Users.
• Gente que duda acerca del proceso. O que, si le preguntas que pasa cuando N, y responde que no sabe.
• Gente que no quiere participar. Muchas veces por situaciones políticas, o por resistencia al cambio.
• Gente que participa demasiado, soltando ideas que podrían costar mucho, pero solucionar poco.

En todos estos casos es importante hablar con el Product Owner para conseguir a las personas indicadas. En especial porque son problemas internos que se tienen que solucionar antes de poder hacer el desarrollo. No hay que enfocarse en los detalles funcionalidades, es mejor buscar los “Lowest hanging fruit”. Soluciones fáciles de desarrollar, y que ayudarán mucho al negocio. Hay que tener cuidado en diferenciar entre lo que piden, y lo que requieren. Lo que buscamos es solucionar los Requerimientos y cumplir los Objetivos, no en hacer lo que piden.

Resumen

Para entender el requerimiento del cliente es importante entender los procesos que pretende sistematizar. Dicha comprensión es la base necesaria para comenzar la definición de las Historias de Usuario y escenarios de comunicación, que veremos en el siguiente post. Por lo pronto recuerda:

• En proceso es una serie de pasos, ejecutados por múltiples roles para convertir entradas en salidas. Lo que necesitamos entender de todo proceso es:
  • Roles: Las personas que participan en el proceso.
  • Flujo: La serie de acciones y caminos que puede tomar el proceso. Pregunta por todos los caminos y excepciones.
  • Reglas de Negocio: Las variables, formulas y reglas que definen como se ejecuta el proceso.
  • Estatus: Los diferentes estatus en los que se puede encontrar el proceso, en base a sus Reglas de Negocio.
  • Información Adicional: Recuerda solicitar ejemplos de otros sistemas que ya usen, o que conozcan, además de documentos físicos o archivos que utilicen actualmente como parte del proceso.
• Ten mucho cuidado con gente que no conoce el proceso, o que no quiere compartir la información, o procesos que no están bien definidos. Háblalo con el Product Owner para conseguir a la gente correcta, o que se defina correctamente el proceso antes de comenzar el desarrollo.