Desafíos

Documentación Faltante

• Identificar los responsables de la toma de decisiones para reunir la información necesaria y correcta.
• Validar con las partes interesadas que la información es precisa.

Documentación de baja calidad

• Comenzar la documentación a alto nivel, luego entrarás en detalle.
  • Esto permite elegir que si se puede automatizar y que no, para luego entrar en detalle en lo que sí.
• Lista de verificación para asegurar la documentación sea precisa y consistente.
• Acordar con equipo de desarrollo el nivel de detalle necesitado para el desarrollo.
  • Por ejemplo: tipos de conexiones, tipos de credenciales, etc.
• Solicitar revisión al equipo de desarrollo para tener puntos de vista más completos.

Alcance claro

• El alcance del proyecto debe estar claramente definido y documentado, plantear los problemas existentes o límites del robot desde el inicio a todas las partes interesadas.

Cambios en los requerimientos iniciales

• Analizar el motivo de la solicitud
• Observe cada posible impacto que pueda generar aceptando el cambio.
• Comunicar los impactos de un cambio y obtener aprobación para poder iniciarlo.
• Es importante validar los archivos insumos para confirmar si se pueden utilizar en la automatización.

Es normal que los usuarios se pongan creativos cuando el trabajo no lo realizan ellos!! jajajaja

Es muy importante saber hacer las preguntas correctas en los momentos correctos, partir de lo particular a lo especifico. Importante mapear, validar, afinar y presentar. Y de esta manera se asegura el cumplimiento del ciclo de levantamiento de información.

Creo que es clave que desde el comienzo se definan los formatos de aceptación y los formatos clásicos de change request en caso de pedidos. Es brutalmente normal, que como opera en su día a día, omita en la explicación varios puntos cuando explique al Analista de Negocios, la solución. Lo correcto aunque suene pesado, es que se vea in situ el modo de operación. Creo yo que ahorra varios malestares.

Sería interesante ver como se relaciona con los prinicipios ágiles

Entiendo que el proveedor debe entregar de vuelta el archivo con las métricas por tanto no se si sea posible que se genere una política que obligue al proveedor a dejar el archivo en nueva carpeta del SFTP a una hora especifica y que el archivo XML tenga definido un nombre con una estructura de AAAAMMDD y un consecutivo para que el robot sea capaz de ir a la FTP y validar existencia del archivo, esto evitaría la tarea manual de que la persona tenga que llamar a presionar para que entregue la información.

Importante que el equipo de desarrollo entiendan las reglas de negocio. En mi caso, les pido que me la expliquen desde su visión técnica para confirmar el entendimiento.

Se pueden solicitar archivos PDF de meses anteriores y realizar una prueba de concepto con el desarrollador para valdiar la calidad de la extraccion de los datos.

pedir un que hagan un ejemplo del proceso, y validar las reglas que ellos nos dieron

Desafíos

• Documentación faltante
  – Identificar responsables de decisiones
  – Identificar partes interesadas
• Documentación de baja calidad
  – Documentar a un alto nivel y luego entrar a detalles (esto no)
  – Cree una lista de verificación para asegurarse de que la documentación sea precisa y consistente
  – Acordar con los programadores el nivel de detalle
  – Solicitar a los programadores que revisen la documentación
• Alcance claro
  – Definido y documentado
• Cambios en los requerimientos iniciales
  – Motivo de solicitud
  – Impacto al aceptar cambio

El levantamiento de los requisitos funcionales a automatizar es fundamental, por lo cual es indispensable realizar una adecuada documentación de las actividades.
También es muy necesario realizar preguntas al proceso (a los dueños del proceso).

Sin duda estos desafíos que plantea Cristian son recurrentes en la implementación de proyectos, por eso, es importante mantener una comunicación muy cercana, transparente y clara con el dueño del proceso y partes interesadas sobre el alcance.

La documentación deficiente podría tener un impacto grande en el proyecto, es por ello que se deben considerar todos los detalles que deben estar incluidos y validarlo con el usuario previo a su implementación evitar cualquier omisión que en el futuro pudiera ser un dolor de cabeza y genere retrasos en la entrega.

En el caso de los cambios imprevistos durante el proceso de implementación, las buenas prácticas dicen que hay que llevar un control y aprobación de estos y deben ser cambios que no tengan impacto en el tiempo y costo del proyecto.

muchas gracias!

creo que hay que poner mucha atención en cada intercambio de información, quién da cada entrada y como se entrega a otro paso, y validar si hay restricciones en usar las herramientas que ya tienen o se pueden sustituir por alguna otra.