Actualmente estoy en una pasantía remunerada, y se me ha encomendado la tarea de mantener un sistema obsoleto que ha sido desarrollado por múltiples desarrolladores (en diferentes momentos) en el transcurso de los últimos 5 años. La gerencia está de acuerdo en que el "sistema está en soporte vital", y recibo un suministro bastante regular de informes de errores de los usuarios finales que actualmente usan el sistema.
El sistema no es obsoleto si las personas todavía lo usan y está apoyando las actividades comerciales. Como todavía se está utilizando, la empresa no puede simplemente tirarlo a la basura, sino que debe recibir soporte hasta que ya no exista la necesidad del sistema. Eso podría ser un cambio en los objetivos comerciales o un nuevo sistema que se haya desarrollado, probado e implementado con éxito para los usuarios finales.
Realmente, 5 años no es tanto tiempo. He trabajado con código que tenía 10 años antes. Si aún satisface las necesidades del usuario, ¿por qué tirarlo? Eso está desperdiciando mucho dinero gastado para desarrollarlo. Hasta que no sea factible mantenerlo debido al aumento de los costos o los requisitos cambien drásticamente, no hay razón comercial para descartarlo.
La gerencia ahora quiere extender el proyecto por otro año, y en el proceso casi triplica la base de usuarios.
Si la gerencia dice que este sistema está "en soporte vital", ¿por qué están tratando de implementarlo más? Es común que las actividades de mantenimiento continúen en un sistema heredado hasta que se reemplace, pero si un sistema está en el 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 en realidad no es el final de la vida útil, sino más bien una fase de mantenimiento y continuará 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 "retrocedo"? Ya he escrito un informe indicando mis preocupaciones, aunque en un documento abierto. ¿Existe un protocolo o tipo de documento para sugerir cambios? ¿Estoy en condiciones de hacer sugerencias, o simplemente debería continuar apoyando el viejo sistema?
Debe continuar admitiendo el sistema anterior. Más adelante, mencionas que el software no es el negocio principal de tu empresa. En dicho 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. Señale 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 hacerlo depende de la empresa, pero teniendo en cuenta algunos puntos posteriores, quizás sea útil establecer un wiki u otro sitio colaborativo.
En una empresa que no es de software, el software es un costo y los equipos de software (especialmente los gerentes de proyectos / programas de software) deberían trabajar para minimizar el costo de construir y mantener los sistemas de software tanto como sea posible, al tiempo que respaldan las necesidades de los usuarios finales . Desechar el software que (por lo que puedo ver, de su publicación, de todos modos) satisface las necesidades de los usuarios va en contra de lo que es mejor para el 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 documentación formal, ni documentos de requisitos. El desarrollo es muy ad hoc.
Para mí, este es el problema. No producir documentación, no desarrollar 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 autodocumentación y documentos de diseño, seguimiento de defectos y especificaciones de requisitos.