Actualmente me encuentro en una pasantía remunerada y me han asignado la tarea de mantener un sistema obsoleto desarrollado por múltiples desarrolladores (en diferentes momentos) durante los últimos 5 años. La gerencia está de acuerdo en que "el sistema tiene soporte vital", y recibo un suministro bastante regular de informes de errores de los usuarios finales que actualmente usan el sistema.
El sistema no está obsoleto si la gente todavía lo está utilizando y está apoyando las actividades comerciales. Dado que todavía se está utilizando, el negocio no puede simplemente desecharlo, debe ser soportado hasta que la necesidad del sistema ya no exista. Eso podría ser un cambio en los objetivos comerciales o se ha desarrollado, probado e implementado con éxito un nuevo sistema para los usuarios finales.
Realmente, 5 años no es tan largo. He trabajado con código que tenía 10 años antes. Si todavía está satisfaciendo las necesidades del usuario, ¿por qué desecharlo? Eso es tirar un montón de dinero gastado para desarrollarlo. Hasta que no sea factible mantener debido a los costos crecientes o los requisitos cambien drásticamente, no hay razón comercial para deshacerse de ellos.
La administración ahora quiere extender el proyecto por un año más, y en el proceso casi triplicará la base de usuarios.
Si la administración dice que este sistema está "en soporte vital", ¿por qué intentan implementarlo más? Es común que las actividades de mantenimiento continúen en un sistema heredado hasta que sea reemplazado, pero si un sistema está al final de su vida útil, generalmente no se implementa en más personas. Extender el mantenimiento es una cosa, pero agregar usuarios que confían en el sistema es una situación completamente diferente.
Para mí, parece que no es realmente el final de la vida útil, sino que está en una fase de mantenimiento y seguirá allí hasta que el sistema ya no satisfaga las necesidades de los usuarios.
Como pasante (o cualquier posición de nivel de entrada), ¿cómo "rechazo"? Ya he escrito un informe en el que se expresan mis preocupaciones, aunque en un documento abierto. ¿Hay protocolo o tipo de documento para sugerir cambios? ¿Estoy en condiciones de hacer sugerencias o simplemente debo seguir brindando soporte al sistema anterior?
Necesitas continuar soportando el sistema anterior. Más adelante, usted menciona que el software no es el negocio principal de su compañía. En tal entorno, el trabajo de los equipos de software es apoyar el negocio principal de la compañía. Sin embargo, los equipos de software también deben tener en cuenta los objetivos comerciales.
Mientras tanto, capture sus sugerencias de una manera que no sea dominante. Indique otras tecnologías o técnicas que podrían integrarse con el sistema o usarse si / cuando se crea un nuevo sistema y sus pros / contras. La forma de hacer esto depende de la compañía, pero considerando algunos puntos posteriores, tal vez sería útil establecer un wiki u otro sitio de colaboración.
En una empresa que no es de software, el software es un costo y los equipos de software (especialmente los gerentes de programas / proyectos de software) deberían trabajar para minimizar el costo de construir y mantener los sistemas de software tanto como sea posible, mientras se respalden las necesidades Los usuarios finales. Desechar un software que (por lo que puedo decir, de su publicación, de todos modos) satisface las necesidades de los usuarios va en contra de lo que más le conviene al equipo de software.
* Para aclarar, el desarrollo de software no es el negocio principal de mi empresa. Como tal, no existen protocolos internos. Además, el proyecto no tiene ninguna documentación formal, ningún documento de requisitos. El desarrollo es muy ad hoc.
Para mí, este es el problema. No producir documentación, no desarrollarse según una especificación y la falta de coherencia tiende a aumentar el costo de desarrollar software. Trabajar para solucionar esto sería mi máxima prioridad, y lo haría trabajando en cosas como un estándar de codificación, control de versiones, producción de código de auto-documentación y documentos de diseño, seguimiento de defectos y especificaciones de requisitos.