Versión 3.0: hazlo mejor

La empresa está desarrollando constantemente sus productos de TI. No hay forma de "detener el momento", de lo contrario, incluso el mejor programa inevitablemente quedará obsoleto. Contamos cómo creamos una nueva versión de la aplicación médica para Europa y qué problemas se resolvieron al mismo tiempo.

Aplicación de hospital

Estamos trabajando con una aplicación médica para hospitales en Europa. Ayuda a los médicos a pasar más tiempo con los pacientes al reducir el papeleo. Los médicos dictan información sobre pacientes y exámenes, la aplicación traduce las grabaciones de audio a formato de texto, completa una plantilla y genera documentos para trabajadores médicos y pacientes. En cada etapa del trabajo, se establece su propia lógica de negocios e integración con varios sistemas externos.

El cliente nos asignó la tarea de desarrollar una nueva versión de la aplicación para la demostración a los inversores.

Detalles del proyecto

Audio

Cómo grabar audio en la versión 2.0:

1. Abrí la aplicación.
2. Haga clic en el botón Agregar registro.
3. En la ventana que apareció, seleccionamos la versión deseada del dispositivo de grabación.
4. Grabación de audio dictada.
5. Se ingresó el número de paciente, fecha de visita, número de visita (visita = cita con el médico).
6. Hicieron clic en el botón Completar para cargar audio y visitar datos al servidor.

Ahora, en la versión 3.0, se requiere menos esfuerzo para escribir:

1. El doctor abre la aplicación.
2. Selecciona una cita (por fecha, hora, número o nombre del paciente) de la lista y hace clic 1 vez para abrir una tarjeta de visita.
3. Graba audio.
4. Presiona el botón Completo para enviar audio al servidor.

En la versión 3.0, el trabajo del médico es lo más automatizado posible. El número de operaciones ha disminuido, mientras que el programa mismo agrega datos sobre los pacientes.

Trabajar con letras

Trabajar con letras también se ha vuelto más fácil. En la versión 2.0, había una cola difícil para su procesamiento. El médico no pudo recibir de inmediato una lista completa de cartas, solo en partes y en un cierto orden. Para comenzar, tenías que:

• haga clic para obtener una lista de sus cartas;
• ve a otra ventana;
• haga doble clic en la carta para abrirla;
• después de procesar las letras de la lista, haga clic nuevamente para recibir las siguientes letras en la lista.

En la versión 3.0, el médico ve todas las cartas disponibles para procesar. Puede seleccionar un documento de dos maneras: manualmente en la lista o usando filtros y tipos (puede guardarlos para abrir más la carta con un solo clic). Para abrir la carta, solo haga clic una vez.

Interfaz

En general, la interfaz de la versión 2.0 era engorrosa e inconveniente. La tarea inicial de la aplicación era ahorrar tiempo a los especialistas médicos al reducir el flujo de trabajo en papel y trabajar con grabaciones de audio. En la práctica, la aplicación no hizo frente a esta tarea tan bien como nos gustaría. Para hacer un registro, el médico tuvo que elegir muchas configuraciones de largas listas desplegables.

Nuestros expertos trabajaron con la interfaz y destacaron el botón de audio para que los usuarios puedan completar su tarea en el menor número de clics.

A continuación, daremos detalles sobre cómo desarrollamos la nueva versión.

Nuevas necesidades

Cuando un cliente nos contactó para actualizar la versión 2.0, la aplicación ha estado funcionando durante aproximadamente tres años. Era familiar para los usuarios y tenía ciertas ventajas:

• Había un conjunto de funciones para realizar una lógica empresarial compleja, la integración con sistemas de terceros;
• los clientes están acostumbrados al programa y no desean abandonarlo;
• El personal de soporte técnico conocía la aplicación y rápidamente ayudó a los usuarios;
• Había configuraciones flexibles para configurar el sistema para cualquier deseo comercial;
• Se estableció el seguimiento de posibles problemas en las partes del servidor del sistema, se conocían soluciones para resolverlos.

Sin embargo, al analizar el funcionamiento de la aplicación, encontramos estos problemas:

• desarrollar y probar nuevas características tomó más y más tiempo;
• al agregar nuevas funciones, aparecieron errores en el sistema;
• Como resultado, hasta el 30% de las mejoras complejas se dejaron de lado, lo que amenazaba con desactualizar la aplicación. Por ejemplo, en los hospitales, aparecieron plantillas cada vez más complejas, era necesario agregar nuevas funciones en Workflow;
• la arquitectura de la aplicación no podía soportar nuevas soluciones;
• El 40% del tiempo de desarrollo se gastó en soporte;
• hubo dificultades al instalar nuevas versiones y actualizaciones del producto de escritorio;
• la interfaz engorrosa de la década de 2000 ahuyentó a los nuevos clientes;
• un sistema de configuración inconveniente impidió que el sistema se iniciara rápidamente y también aumentó los riesgos de errores.

Al evaluar las fortalezas y los desafíos, llegamos a la conclusión de que la aplicación debe hacerse más móvil (versión web en lugar de escritorio) y conveniente, competitiva y fácilmente adaptable a las tareas comerciales.

Requisitos de versión

Analizamos las funciones de la aplicación e identificamos las más importantes que hicieron que el producto fuera valioso para el negocio. En base a estos datos, determinamos cuál debería ser el programa en la nueva versión:

• Se necesitan funciones clave de la aplicación intuitiva para médicos y otros usuarios;
• Debería ser fácil para los usuarios, proveedores de atención médica y personal de apoyo, aprender cómo usar el programa;
• eliminar la pérdida de datos incluso en condiciones extremas (cortes de energía, acceso inestable a Internet, etc.);
• los documentos generados por el sistema deben cumplir con las normas y requisitos de la ley;
• durante las actualizaciones del sistema, se deben minimizar los posibles inconvenientes para el usuario y el servicio de soporte;
• es necesario crear una arquitectura modular orientada a servicios basada en componentes distribuidos, acoplados libremente, que les permita ser utilizados para construir sistemas de software complejos;
• Use Active Directory para configurar uniformemente su entorno de trabajo.

Además, era imposible permitir que la nueva versión fuera un "clon complicado" de la anterior. Por lo tanto, las funciones clave tenían que guardarse, pero sin sobrecargar la aplicación. Abandonamos implacablemente configuraciones complejas redundantes.

Los analistas de negocios que trabajan con la versión 2.0 no aceptaron de inmediato los cambios. En los términos de referencia, a menudo se encuentran frases: "Debería estar aquí como en la versión 2.0", "Tome el esquema de trabajo en la versión 2.0". Lo más difícil en esta etapa fue la resistencia a la tentación de tomar todo, como en la versión anterior.

Equipo de proyecto

Como regla general, al comienzo de cada proyecto, en SimbirSoft nos conectamos con un equipo de expertos de diferentes perfiles: analistas, especialistas en control de calidad (QA) y otros. Cuando trabajamos en una aplicación médica, reunimos el siguiente equipo:

• desarrolladores que escribieron código y adaptaron características de la versión 2.0;
• Especialistas en Aseguramiento de Calidad (QA). Ellos, junto con los desarrolladores, estaban familiarizados con el código heredado, las soluciones arquitectónicas y los errores de la versión 2.0, y también probaron nuevas funciones;
• Test Automation Engineer (SDET), que configuró la verificación automática de casos de prueba en las versiones de escritorio y web;
• Inteligencia de negocios. Hablaron con el cliente y los médicos, descubrieron cómo se construyeron los procesos comerciales, cuáles son los requisitos y los deseos de la aplicación. Después de eso, elaboraron diagramas de procesos de negocio que eran comprensibles para todo el equipo;
• Diseñador y experto en usabilidad. Fueron responsables de desarrollar una interfaz fácil de usar.
• Gerente de proyecto que participó en la gestión y programación del tiempo.

En el proceso, mantuvimos constantemente tablas de los supuestos riesgos en la nueva versión. Para evitarlos, pensamos en un sistema flexible de configuración de aplicaciones y automatizamos sus pruebas para proteger a los usuarios de los errores. En particular, nuestro especialista en SDET escribió un marco que ayudó a verificar rápidamente todos los cambios en el código y a dedicar menos tiempo a las pruebas de regresión.

Desafíos y soluciones

Al actualizar la aplicación, enfrentamos varias etapas difíciles, que discutiremos a continuación.

Diseño de la aplicación

Como la versión anterior tenía una interfaz engorrosa, rediseñamos el diseño de la aplicación. Propusimos cinco opciones preliminares y las mostramos al grupo focal de entre los usuarios de la aplicación, realizamos pruebas de usabilidad. Como resultado, los especialistas médicos eligieron una opción, que, en su opinión, resultó ser la más conveniente, atractiva y fácil de usar.

Desarrollo de plugins para diferentes navegadores.

Hemos proporcionado varios riesgos técnicos asociados con la aplicación. Por ejemplo, el complemento elegido para la implementación podría no ser adecuado para algunos navegadores de Internet. Para reducir este riesgo, primero desarrollamos un complemento para el software que se utiliza en la mayoría de las instituciones médicas asociadas. En el futuro, desarrollamos con calma el complemento para otros navegadores.

Hipótesis comerciales inválidas

Nuestra tarea era desarrollar una versión limitada del producto para su presentación a los inversores. Por esta razón, buscamos implementar en la aplicación solo las funciones más necesarias. Analizamos algunas hipótesis del cliente y nos negamos a implementarlas.

Por ejemplo, el cliente sugirió crear un calendario para planificar el trabajo de especialistas médicos. Según la hipótesis, el calendario podría facilitar el trabajo de los médicos. Sin embargo, en condiciones reales, esta función no tuvo éxito, por lo que al final se apagó. Más tarde, el calendario se adaptó a las necesidades de otro grupo de usuarios: pacientes, no trabajadores médicos. Hipótesis no válidas: esta es una parte integral del negocio y debe estar preparado para ellas.

Integración con sistemas externos.

Tomó mucho tiempo acordar con nuestro socio el procedimiento para integrar la aplicación con sistemas externos para enviar y almacenar cartas.

Los usuarios de la aplicación facilities instalaciones médicas ─ querían usar sistemas de integración antiguos y familiares para la versión 3.0, no podían modificarse. Nuestro socio asumió que en este caso la integración sería rápida. Sin embargo, de hecho, muchas tareas se asociaron con la integración:

• Recopilar información general sobre cómo funcionan los sistemas de envío de correo;
• hacer una lista de errores críticos que estaban en 2.0;
• considere estos casos en la etapa de análisis y desarrollo para tenerlos en cuenta y no pisar el mismo rastrillo;
• analizar si las funciones de la versión 2.0 son adecuadas para los procesos de la versión 3.0 o si algo necesita ser cambiado. En caso de cambios, especifique cada vez por qué se necesitan funciones específicas y comuníquese con los especialistas técnicos del cliente, y no solo con los analistas.

En el proceso de negociaciones con el cliente, pudimos demostrar que trabajar con integración lleva tiempo. Nuestro socio estuvo de acuerdo con nosotros: no puede simplemente tomar y transferir el código de una versión a otra.

Pruebas y análisis

La versión anterior del proyecto fue creada sin la participación de analistas. Los desarrolladores y especialistas en control de calidad especificaron los requisitos en el proceso de creación de la aplicación. La tercera versión ya se basaba en los requisitos de los analistas, sin embargo, todavía había dificultades con las pruebas:

• diferentes equipos trabajaron en el proyecto;
• había un gran volumen de tareas paralelas;
• durante el sprint, los requisitos y las tareas a menudo cambiaban;
• Era necesario tener en cuenta la interacción de las nuevas funciones con las ya aprobadas.

Para trabajar en la nueva versión del producto, necesitábamos transformar flujos de trabajo individuales, por ejemplo:

• Hemos fortalecido la analítica desde el lado del desarrollo y el control de calidad y hemos establecido horas adicionales para esto.
• Era una regla indicar el propósito de la función que se estaba probando en los requisitos para la revisión. Esto mejoró la comprensión de las tareas para los analistas y brindó la oportunidad de proponer la solución óptima.
• Para aclarar los términos de trabajo, cambiamos la terminología: en lugar de una estimación aproximada en horas, comenzamos a clasificar las tareas como "grandes" o "pequeñas". Comenzamos a calcular el tiempo de entrega solo después de una revisión completa de la tarea desde el lado del desarrollo, el control de calidad y la aprobación de la versión final de los requisitos por parte del cliente. Si la tarea se expandió, volvimos a calcular la estimación de los costos de tiempo.
• Comenzamos a planificar qué funciones deberían implementarse en los próximos trimestres ─ para los próximos 2-3 lanzamientos. Para predecir con mayor precisión el desarrollo, ya no incluimos en el plan de lanzamiento aquellas tareas que no pasaron la evaluación.
• Para la comodidad de los analistas y una mejor comprensión del sistema, indicamos en las listas de verificación qué interacciones deben tenerse en cuenta al hacer los requisitos. También desarrollamos reglas comunes para escribir artículos en Confluence y documentación en JIRA y comenzamos a adherirnos a ellos.

Las reuniones regulares en línea con el cliente nos ayudaron a mejorar nuestra comprensión de sus procesos comerciales. Durante la conversación, nuestro socio contó los detalles de cómo trabajan los médicos y explicó los objetivos comerciales. Nosotros, a su vez, explicamos los matices técnicos y mostramos varios casos no obvios. Esto nos permitió formular requisitos de productos que cubren las necesidades de las instituciones médicas y son óptimos en términos de costos de implementación.

Resumen

La flexibilidad en los procesos de trabajo y la atención a las necesidades comerciales nos permitieron superar todas las dificultades que surgieron durante el proceso de desarrollo. Hemos realizado y lanzado con éxito una nueva versión de la aplicación para instituciones médicas en Europa.

Ahora continuamos desarrollando el producto e introduciendo nuevas características. Observamos cómo los usuarios reales trabajan con el sistema, recopilan casos no contados e historias de usuarios e identifican nuevos valores comerciales.

Al crear una nueva versión de un producto, los desarrolladores, por regla general, enfrentan los mismos problemas que nosotros, por ejemplo:

• son posibles hipótesis incorrectas desde el lado de los negocios;
• existen contradicciones en los deseos de los usuarios (dejar todo como estaba o rehacerlo de una manera nueva);
• a veces es necesario reestructurar el trabajo del equipo para lograr un mejor resultado.

Lo principal es que el lanzamiento de la nueva versión del producto de TI no es una copia del código "Ctrl + C", "Ctrl + V" de la versión anterior, sino un desarrollo completo, desde cero. Esto se debe a que los procesos comerciales, los requisitos del usuario, así como la situación en el mercado de soluciones de TI, están cambiando.

Gracias por su atencion! Esperamos que encuentre útil este artículo.