Cuando Los Clientes Piden Cambios en las Aplicaciones?

Antes de los cambios en las aplicaciones

El desarrollo de una aplicación web es un proceso complejo que puede involucrar a muchas personas, si la aplicación es para un cliente, muy posiblemente es una aplicación desarrollada a la medida de sus necesidades y éste proceso ha requerido mucho tiempo en reuniones, en levantamiento y aclaración de requerimientos (ésta es la parte más importante de un proyecto de desarrollo de software), en pruebas, pilotos, más pruebas, control de cambios hasta que después de un gran esfuerzo la aplicación, finalmente sale a producción, en muchos casos el cliente quiere alguna modificación, en éste artículo les voy a contar que hago cuando los clientes piden cambios en las aplicaciones.

Les recomiendo leer el artículo “ENTENDIENDO EL DESARROLLO WEB” para aclarar o profundizar en el concepto.

Luego de un par de días en producción, aparece el usuario que no ha estado en contacto cercano con el proceso de desarrollo e implementación de la aplicación, eventualmente leerá el manual de usuarios, y se lanza a usar la aplicación por primera vez, navega de un lugar a otro, explora las opciones en el menú, analiza las interfaces y la funcionalidad y en general está conforme con lo que ve, pero, PERO le gustaría que en algún modulo, en alguna pantalla específica, se agregara un campo de texto para capturar un dato importantísimo del que no se había percatado antes y hace la solicitud.

Que hacer cuando los clientes piden cambios en las aplicaciones

El proceso de control de cambios en las aplicaciones

El proceso de control de cambios tiene como objetivo que los desarrolladores de software, bien sean empresas o independientes, mantengan el seguimiento de los cambios solicitados por los clientes y cuáles se realizan sobre las aplicaciones, estos cambios puedes originarse por incidencias en la aplicación o por solicitud expresa de los usuarios finales, yo sigo el siguiente protocolo cuando me solicitan cambios en las aplicaciones que he desarrollado.

Determinar y validar el origen de la solicitud.

Clasifico el origen de una solicitud en alguna de las siguientes categorías.

  • Incidencia, Corresponde a una falla en el funcionamiento de la aplicación que debe ser corregida inmediatamente o en el menor tiempo posible.
  • Nueva funcionalidad, corresponde a una solicitud para agregar una funcionalidad nueva o mejorar alguna ya implementada, ésto naturalmente implica cambios en las aplicaciones que no estaban descritos en el documento de requerimientos oficiales aprobado por el cliente. Estos requerimientos o modificaciones se escapan de control porque generalmente surgen cuando un usuario que no ha estado muy cerca del proceso de desarrollo ve la aplicación y determina que hace falta algo o quiere mejorar alguna funcionalidad establecida.

Determinar el impacto en la funcionalidad de la aplicación

Una vez  identificado el origen de la solicitud, la clasifico de acuerdo al posible impacto que pueda tener en la aplicación, así:

  • Leve, en ésta categoría se incluyen esos cambios que no afectan la funcionalidad de la aplicación ni la estructura de datos, por ejemplo el cambio de color de un botón o correcciones en los textos.
  • Moderado, son modificaciones que logran afectar en menor proporción la lógica de la aplicación y requieren pequeñas modificaciones en la estructura de los objetos de la base de datos, por ejemplo agregar un nuevo campo de texto a algun formulario.
  • Profundo, adicionalmente de requerir modificaciones en los objetos de la base de datos, modifica las reglas del negocio que ya están escritas en código y generalmente implican la creación de objetos nuevos en la base de datos, por ejemplo modificar la lógica de algún cálculo matemático, crear un nuevo reporte con mayor detalle, modificar las reglas de aprobación o notificación de algún proceso.

Estimar tiempo y costo

Una vez teniendo claro el origen y el impacto del requerimiento se debe estimar la cantidad de tiempo, recursos y costos de la implementación.

Determinar el tiempo es un proceso subjetivo para cada desarrollador o equipo de desarrollo, de acuerdo a los horarios disponibles, horas extra, fines de semana, etc., yo por lo general calculo el tiempo en horas para cada requerimiento, luego calculo los días que me tomará el desarrollo asumindo que en cada día hábil normalmente se trabajan 8 horas.

Para determinar el costo de los cambios en las aplicaciones, me baso en el origen del requerimiento, si es una incidencia no lo cobro por que hace parte del cubrimiento de garantía que ofrezco con mis desarrollos, si es un requerimiento nuevo, cobro mi tarifa completa de desarrollador de software. Un tip administrativo, tengo una tarifa por hora de desarrollo, que multiplico por el tiempo estimado en horas que me tomará el desarrollo, pruebas el implementación del requerimiento.

Desarrollo, pruebas e implementación

Una vez determinado el origen, el impacto y haber acordado con el cliente el tiempo y el valor de la modificación se inicia el proceso de desarrollo de los cambios o requerimientos, cuando el desarrollo está finalizado, se hacen pruebas por parte del equipo de desarrollo, pruebas con los usuarios, piloto de los cambios e implementación en el ambiente de producción, no olviden que se deben dejar todas las interacciones con el cliente documentadas, es decir, con actas de entrega y con toda la formalidad que se requiere para éste tipo de proyectos.

Consideraciones Técnicas

Asuntos tecnicos

Las siguientes consideraciones técnicas se basan en un escenario de aplicaciones web en donde no es necesario compilar la solución y el despliegue se hace actualizando los archivos en un servidor web por medio de FTP, ya que las consideraciones a tener en cuenta para aplicaciones de escritorio o con tecnologías que requieren compilación y despliegue son diferentes.

Es muy poco probable, aunque sucede, que el cliente pida un cambio importante en la aplicación y esto puede implicar en términos técnicos modificaciones bien sensibles en la lógica de la aplicación y en el modelo de datos.

Es mucho más probable que solicite ajustes a textos, colores o diseño de la aplicación o también que solicite agregar campos de datos que no afectan la lógica funcional.

Modificar por ejemplo un texto implica normalmente editar un solo archivo y sincronizarlo en el servidor, es decir, cargarlo por FTP, como estamos hablando de aplicaciones web, el cliente deberá refrescar la página en el navegador para actualizarla y ver los cambios.

Cuando el cliente pide un cambio en la aplicación, tipo “es posible agregar un campo de texto en ésta página en el que se pida la opinión del usuario” implica hacer las siguientes modificaciones:

  • Editar el archivo de captura de datos
  • Editar el o los archivos que muestren los datos relacionados, por ejemplo reportes detallados de las transacciones
  • Es posible que las transacciones sean notificadas vía correo electrónico a algunos miembros de la organización, el campo nuevo debe ser actualizado en esos mensajes de correo.
  • Modificar por lo menos una tabla en la base de datos para permitir que el dato del nuevo campo se almacene en la base de datos.
  • Si esa tabla alimenta una vista (tabla virtual derivada de tablas reales de una base de datos) se deben recrear las vistas para que tomen el cambio de la tabla.

Conclusiones y Consejos

  • En los proyectos de desarrollo de aplicaciones, sin importar el contexto corporativo o la tecnología utilizada, generalmente, para no decir que siempre van a ocurrir errores no contemplados o detectados en los escenarios de pruebas, éstos errores o incidencias deben ser atendidos y corregidos lo más pronto posible como muestra de respaldo hacia el cliente e implica hacer cambios en las aplicaciones.
  • Las solicitudes de cambios menores o leves, deben ser atendidas lo más pronto posible, el cliente se sientirá apoyado por su proveedor (nosotros los desarrolladores), no olviden que aunque la lógica y el código sean impecables, lo que los clientes finales ven es la presentación.
  • Yo personalmente no conozco a un cliente que pida cambios por deporte o como algún tipo de venganza personal con el equipo de desarrollo, somos humanos y las omisiones suceden, en ese orden de ideas, cuando un cliente les pida cambios no contemplados, negocien abiertamente con ellos y respáldense en el documento de requerimientos del proyecto, hacer éstos cambios implica fidelizar al cliente y por qué no mencionarlo, facturar un poco más.
  • Lo más importante para no tener conflictos con los clientes, es tener los requerimientos perfectamente claros desde el principio, ojala en un documento firmado, de tal forma que funcione como evidencia y documento de verificación que lo desarrollado fue lo pedido, también es importante hacer pruebas incrementales con los usuarios para que vean anticipadamente la aplicación y así se disminuye la resistencia al cambio.

Ya saben, si quieren ampliar algo sobre éste tema, opinar o simplemente saludar, dejen sus comentarios a continuación.

Deja un comentario