Después de casi cualquier publicación de un proyecto de software, es recomendable hacer su mantenimiento evolutivo y dar soporte técnico a sus usuarios. En algunos proyectos es muy fácil justificar esto, pero en otros proyectos no es tan sencillo predecir cuántas horas habrá que reservar anualmente para mantenimiento.
Para ayudar a estimar el mantenimiento evolutivo de nuevos proyectos de software, he preparado la siguiente lista con factores a tener en cuenta. Esta lista puede utilizarse además para explicar a los clientes que reserven presupuesto «para después» y no gasten todo en la versión «1.0» de su software.
Este listado sirve para proyectos de software de escritorio, aplicaciones web y apps móviles. Lo he elaborado con experiencias de los últimos 10 años desarrollando apps móviles y web. Algunos puntos son obvios y otros no tanto. Los he puesto para ayudar a técnicos y no técnicos. Espero que os sea de utilidad 🙂
1. El Documento Funcional inicial no es perfecto. No importa cuánto tiempo haya invertido el cliente y el equipo de desarrollo para redactar el documento que describe la aplicación, siempre habrá casos de uso no previstos. Ejemplos de funcionalidad que a veces no se especifica en el documento: cómo se da de baja un usuario, cómo recibe el administrador los reportes de abuso, cómo se bloquea a un usuario por parte del administrador, qué ocurre cuando un usuario inicia sesión en un dispositivo nuevo…
2. El proyecto siempre necesita quitar o añadir nuevas funcionalidades, nadie «clava» un proyecto de éxito a la primera. Estas funcionalidades que se ponen o quitan son propuestas por cliente, por la parte de negocio, por marketing, por desarrollador, por UX, por usuarios finales o inversores. Para equivocarse lo menos posible al añadir y quitar funcionalidades, es muy importante medir cómo los usuarios utilizan el software antes y después de cada cambio.
3. Las necesidades de los usuarios cambian a lo largo del tiempo. En el futuro solicitarán funcionalidades que hoy descartan o que hoy aún no imaginan.
4. Aparecen nuevos competidores. El software de nuestra competencia seguirá mejorando y aparecerán nuevos competidores. Tendremos que invertir en el mantenimiento evolutivo de nuestra aplicación para seguir siendo competitivos.
5. Hay errores ocultos que habrá que corregir. Aunque muchos errores sean detectados y corregidos durante las fases de desarrollo y testing, algunos errores permanecen ocultos tras la publicación. Según lo acordado en el contrato de desarrollo, los primeros meses suelen estar cubiertos con la garantía y los errores se corrigen sin coste, pero algunos errores ocultos pueden aparecer al cabo de más tiempo.
6. El Mínimo Producto Viable (MVP) es para validar y tirar. Después de iterar sobre el MVP y mejorar los resultados, muchas veces se tira a la basura para volver a hacer el desarrollo desde cero con todo lo aprendido, con más presupuesto, más equipo y más tiempo.
7. Actualizaciones de las librerías de terceros. La mayoría de proyectos de software utilizan frameworks y librerías para lograr soluciones de mayor calidad y reducir los tiempos de desarrollo. Por ejemplo la app Gmail para iPhone utiliza más de 60 librerías opensource o de terceros. Nuestro software tiene que ser testeado con cada nueva actualización y es común que tengamos que hacer algunas adaptaciones en nuestro código por cambios en algún método de las librerías. Antes de incluir una librería se comprueba que esté mantenida activamente por la comunidad u otra empresa.
8. Actualizaciones del Servidor de Aplicaciones. Habrá que mantener actualizado el servidor de aplicaciones (apache, tomcat, nginx, node…). Si no lo actualizamos, también podemos quedar expuestos a errores y agujeros de seguridad conocidos. Algunos proveedores cloud de tipo PaaS y FaaS pueden subirnos obligatoriamente la versión de node o php por ejemplo, si usamos una versión antigua. Normalmente cada versión tiene varios años de soporte. Nuestro software tiene que ser testeado con cada nueva versión, pues podría dejar de funcionar al actualizar las versiones de java, php, node, etc.
9. Actualizaciones del Sistema Operativo en el servidor. Si el backend funciona en un servidor propio, habrá que mantener actualizado el sistema operativo. Si no lo hacemos, estaremos expuestos a errores y posibles agujeros de seguridad conocidos en esta parte. Nuestro software tiene que ser testeado con cada nueva versión.
10. Las APIs para conectar con terceros cambian. Por ejemplo el SDK de Facebook cambia más de lo que gustaría a los desarrolladores y esto provoca que muchas apps dejen de funcionar si no se actualizan.
11. Aparecen nuevos servicios/librerías más competitivos que los que estamos usando y puede convenir invertir horas para cambiar. Ejemplos: proveedor de envío de notificaciones push o de envío de emails, o nuevas pasarelas de pago que cobran menos.
12. Algunos servicios externos mueren. Por ejemplo parse.com †, el servicio de Facebook usado por 500.000 apps para enviar notificaciones push y que anunció cierre en 2016.
13. Algunos servicios fallan puntualmente. ¿Interesa implementar un plan B para estos casos? Decidir qué hacer si la plataforma de anuncios no devuelve anuncios temporalmente, si la pasarela de pagos no funciona con cierto tipo de tarjetas, etc.
14. La Ley cambia. Y nos obligan a añadir política de cookies, rgpd, cambiar la ubicación geográfica de los servidores, cambia la forma de emitir una factura, el tipo de impuesto, varía la forma de darse de baja de una web, los registros para auditorías, etc…
15. Las normas de los marketplaces de apps cambian. Apple, Google, Microsoft y otros añaden restricciones. Por ejemplo, cambian los motivos por los que puedes pedir un permiso al usuario o cómo debe ser el formulario de registro. Estos cambios requieren dedicar un poco de esfuerzo para actualizar las apps. Si no cumples estas normas, la app puede ser eliminada de la app store.
16. La info que solicitan los marketplaces de apps crece. Iconos de más resolución, banner promocional, vídeo de la app, links a política de privacidad, edad mínima recomendada (PEGI), más capturas de pantalla y a más resolución… Si publicaste tu app hace ya tiempo y no pones los campos nuevos, tu app puede ser retirada.
17. El algoritmo de Google cambia, y tu web debe adaptarse para no perder visitantes por SEO: diseño responsive, certificado SSL, velocidad de carga, AMP, etc…
18. Nuevas tecnologías avanzan y se democratizan. Funcionalidades que en versiones anteriores de tu proyecto no existían o fueron descartadas (por coste o por poco conocida), ahora pueden tener sentido: streaming de vídeo, blockchain, asistente por voz…
19. Aparecen nuevos dispositivos. ¿Tiene sentido adaptar nuestro software a nuevos dispositivos? (relojes inteligentes, altavoces inteligentes, TVs, tablets, etc…). A veces sí interesa adaptar nuestro software a ellos y a veces no.
20. El Sistema Operativo de tus usuarios cambia. Por ejemplo, en iOS y Android las nuevas versiones de SO han hecho que algunas apps dejen de funcionar (https obligatorio en todas las APIs, solicitar los permisos de acceso a lista de contactos, métodos deprecados, cambio de 32 bits a 64 bits en todas las apps a partir de iOS11, etc). Una app que no se mantiene acaba muriendo.
21. Las pantallas del usuario cambian de resolución, de aspect ratio y le aparece una ceja. Tanto la maquetación de las páginas web o pantallas de app como la resolución de las imágenes debe adaptarse a las nuevas pantallas. Además, desde la presentación del iPhone X muchos dispositivos de otras marcas han incorporado su notch en una parte de la pantalla. Estos cambios no son transparentes y requieren trabajo de los desarrolladores y diseñadores para adaptar las apps móviles.
22. Optimizar cuellos de botella. En la fase de análisis inicial es imposible conocer al 100% el comportamiento de los usuarios. Solo midiendo datos reales podremos detectar todos los cuellos de botella y decidir cuánto invertir en optimizarlos. Además, el consumo de recursos en el servidor no será constante y en el futuro puede aumentar hasta afectar al rendimiento de alguna parte del sistema. Si no se definen primero alarmas que nos avisen en el servidor y después no se amplían los recursos ni se optimizan los cuellos de botella, puede ocurrir que los usuarios dejan de poder utilizar el servicio.
23. Hay tareas de administración periódicas que hay que hacer todos los años. Renovar los certificados de notificaciones push del servidor, renovar dominios, renovar cuentas de desarrollo…
24. El backend necesita tareas periódicas para no perder rendimiento. Ajustar reglas de escalado, revisar logs, mover logs, optimización de la base de datos, reinicio programado…
25. Cambios periódicos en las claves de acceso y administración. Cambio periódico de contraseñas de usuarios activos, baja de usuarios que se desvinculan de la organización, cambio de contraseñas inmediato en servicios externos que se han visto comprometidos.
26. Ante un fallo crítico (fallo de hardware o un sabotaje por ejemplo). Hay que recuperar las copias de seguridad y restaurar el servicio.
27. Añadir nuevas métricas. Necesitarás medir más y mejor cómo tus usuarios utilizan la app o web, cómo se comportan ante nuevas funcionalidades y nuevas campañas.
28. Añadir nuevos idiomas, nuevas monedas, nuevos mercados. La localización de un proyecto de software para nuevos mercados necesitará mantenimiento.
29. Soporte a los usuarios. Los usuarios finales de la aplicación pueden tener dudas con su funcionamiento. Estas dudas pueden ser dirigidas hacia la persona que ha contratado la aplicación o puede delegarse en un centro de atención al usuario (CAU) que cubra el servicio de soporte técnico.
30. Refactorización de código. La refactorización, que consiste en reorganizar el código fuente para mejorar su legibilidad, eliminar código duplicado y borrar código que no está en uso, es una tarea importante que realiza también durante la fase de mantenimiento y que después suele reducir el coste de añadir nuevas funcionalidades. Algunas tareas de refactorización se hacen en el día a día y otras más complejas requieren ser planificadas.
31. Cambiar el lenguaje de programación. Pasa poco, pero hay casos recientes. A veces un lenguaje de programación es el idóneo para un proyecto y al cabo de los años deja de tener soporte. Los dispositivos de los usuarios dejan de ser compatibles y se reduce considerablemente el nº de programadores que trabajan con dicho lenguaje. Hace 10 años los desarrollos web estaban llenos de Flash y Java pero hoy ya no. Y en 2014 casi todo el mundo optaba por objective-C para desarrollar apps nativas iOS pero hoy el lenguaje Swift ha sustituido a objective-C.
