Sabemos que a muchos de los usuarios les interesa conocer de qué manera se manejan los procesos en el área de desarrollo, los cuales son los motores del buen funcionamiento del sistema, sean requerimientos personalizados o mejoras dentro del producto.

¿Cómo se realizan?

Se encuentran divididos en 3 grandes procesos en HAYLLI

Solución de BUGS

¿Qué es un BUG? Una falla, inconsistencia, error en el software.

Proceso: Identificación – Solución – Pruebas – Despliege

IDENTIFICACIÓN

1. El área de Soporte recepciona del usuario detalles, audios, fotos, videos del “error” (el cual hasta que no se verifique no puede ser catalogado como tal).
2. Se intenta reproducir al máximo la “falla” en “DEMO”, si NO se logra reproducir exactamente, se procede a evaluar la cuenta personal del usuario, de NO encontrar la “falla” se debe a un USO INCORRECTO del sistema por parte del usuario.

SOLUCIÓN

1. Si ha sido un error por parte del usuario: Se procede a realizar una capacitación para lograr el USO ADECUADO del sistema.
2. Si NO ha sido un error por parte del usuario: El equipo de “Developers” recepciona la falla.

PRUEBAS

1. Se reproduce el BUG en su rama (en su dispositivo, NO en el sistema), se identifica el error, se procede con la solución del BUG, se vuelve a realizar pruebas, de comprometer a otros módulos, se continúa con el proceso de identificación-pruebas-solución hasta que el error sea corregido.

DESPLIEGUE

1. Se despliega los cambios en “DEMO”, el equipo realiza pruebas para verificar que sea correcto, de NO ser correcto, se reportan los errores y se vuelve a realizar el ciclo hasta que sea validado. Una vez validado, el “Chief Technology Officer” verifica que esté conforme, de NO estar conforme se reportan los errores y el equipo de “Developers” resuelve el error.
2. Habiendo pasado diversas pruebas y verificaciones se procede a desplegar los cambios en “PRODUCCIÓN”, se notifica al usuario con el fin de recepcionar la conformidad, en caso aún NO sea correcto se vuelve a realizar todo el proceso de pruebas-despliegue, hasta ser validado por el usuario.

Requerimiento Personalizado

1. Se recepciona este requerimiento, la parte comercial Soporte o Ventas lo comunica al área encargada.
2. El “Product Manager” evalua el alcance, que tan factible es, si afectará el producto, si realmente ayudará al usuario, si puede o no realizarse: En caso NO sea posible, se comunica al equipo comercial para que a su vez sea comunicado al usuario.
3. En caso SI sea posible, el requerimiento pasa al equipo de “Developers”, el cual evalúa la parte funcional a nivel código.
4. El requerimiento pasa al “Chief Technology Officer”, quien se encarga de validar la solución que propone el equipo de “Developers”, y se procede a agregar el requerimiento al Sprint.
5. El Product Manager asigna la prioridad y define una fecha límite, además se realiza una maqueta para validar funcionalidades y ser presentada al usuario.
6. El área de Soporte informa al usuario, se realiza una reunión donde se muestra el avance y el usuario retribuye con su opinión.
7. Se procede a realizar la parte técnica del requerimiento por parte del equipo de “Developers”, los cuales inician a realizar pruebas en su ambiente local. SI es correcto, se desplegará en una “DEMO” para que pueda ser probada por el “Product Manager” y el área Comercial, si NO es correcto, resuelve los errores en el mismo local y se realizan pruebas nuevamente, este ciclo se repetirá hasta que todo sea correcto.
8. Desplegado en “DEMO”, el “Product Manager” realiza pruebas nuevamente, de preferencia en compañía del usuario o el área Comercial, con el fin de poder recibir un feedback. SI se cumple con los requisitos, se aprueba la solución, si NO cumple los requisitos, se notifica los errores al equipo de “Developers”, se procede a repetir el ciclo, hasta que la solución sea correcta.
9. El “Chief Technology Officer” verifica en “DEMO” que la solución sea correcta con el fin de evitar fallas en la cuenta de “PRODUCCIÓN”, SI es correcto, se despliega en producción, se notifica al área Comercial para que pueda ser comunicado al usuario. Si NO es correcto, se notifican los errores al equipo de “Developers” y se vuelve a realizar el ciclo (ITEM 7, 8, 9)
10. Al ser desplegado en “PRODUCCIÓN”, se notifica al área Comercial, el cual informa al usuario para recepcionar la conformidad o el feedback. SI es correcto, el requerimiento estará listo. Si NO es correcto, se vuelve a realizar el proceso desde el despliege en “DEMO” (ITEM 7, 8, 9, 10)

La duración estimada puede variar debido a nuestro exhaustivo Protocolo de Pruebas, previas a subir un cambio a “PRODUCCIÓN”.

Nueva Funcionalidad

1. El área de Product realiza una investigación, sea tomando en cuenta las nuevas tendencias o las nuevas sugerencias de los usuarios. Se define la funcionalidad, en qué va a consistir, qué función va a cumplir.
2. Se consulta la factibilidad con el “Chief Technology Officer”, si NO es factible el proceso, vuelve a ser replanteado. En caso de SI ser factible el proceso continúa.
3. El “Product Manager” realiza una maqueta y realiza una validación con el equipo y algunos usuarios, para conocer qué tan útil lo consideran, de NO ser conforme se vuelve a consultar la factibilidad de los cambios con el equipo de “Developers” en base a las opiniones de los usuarios. En caso de SI ser conforme el “Chief Technology Officer” lo agrega al SPRINT para su planificación.
4. El equipo de “Developers” inicia a realizar el requerimiento, realiza pruebas, de SI ser correcto se procede a desplegar en “DEMO”, de NO ser correcto, resuelve errores en su rama y se vuelve a realizar el ciclo hasta poder desplegar en “DEMO”.
5. Una vez desplegado, el “Product Manager” realiza la mayor cantidad de pruebas posibles en “DEMO”, de preferencia junto al usuario o el equipo de Soporte al usuario que tiene mayor contacto con ellos.
6. De acuerdo al feedback recibido, si NO cumple los requisitos, se notifica los errores y nuevamente el equipo de “Developers” realiza los ajustes correspondientes hasta que pueda ser nuevamente presentado al usuario.
7. En caso de SI ser aprobada la solución, el “Chief Technology Officer” verifica la solución, si NO está conforme se notifican los errores y el equipo de “Developers” vuelve a realizar los arreglos correspondientes, realizando el ciclo hasta llegar al (ITEM 6)
8. SI está conforme, se despliega en “PRODUCCIÓN”.

Si aún no eres usuario de HAYLLI pero deseas visualizar una demostración gratuita, puedes agendarla con uno de nuestros asesores, haciendo CLIC AQUÍ