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.
La gerencia ahora quiere extender el proyecto por otro año, y en el proceso casi triplica la base de 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?
- 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, y tampoco documentos de requisitos. El desarrollo es muy ad hoc.
Respuestas:
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.
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.
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 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.
fuente
I've worked with code that was 10 years old before¿Qué tal 25 años? :) Aún cumplía con las necesidades de la compañía e hizo un trabajo increíble para lo que fue diseñado, a pesar de que tocar el código era tan agradable como nadar en el Ártico.Bueno. De eso se trata lo que puedes hacer como pasante. Para referencia futura al escribir tales informes, enfatizo la presentación de hechos concretos de una manera imparcial y profesional, libre de prejuicios emocionales. No sabe quién leerá el informe, posiblemente alguien que haya causado o no algunos de los problemas que está describiendo o que haya tomado decisiones que condujeron a estos problemas. Cualquier otra cosa que no sean hechos fríos podría ser tomada por tales personas como una afrenta o un delito y hará que no les agrades y posiblemente no tomen nada en serio.
Tenga en cuenta que las decisiones comerciales como esta se toman porque están tratando de cumplir con los recursos que tienen a su disposición. Estoy seguro de que la administración probablemente esté al tanto de los problemas con el software heredado, y probablemente esté al tanto de las quejas de los usuarios, pero ¿tienen los recursos de desarrollo de software disponibles para tratar la refactorización o una reescritura?
La mayoría de las veces no lo hacen, especialmente si el software no es el pan de cada día de la compañía y la calidad y la satisfacción del usuario con el software no afectarán directamente el resultado final. A veces, tomar este tipo de decisiones es la razón por la cual ser un gerente apesta porque a menudo estás en una situación de perder-perder sin importar lo que hagas.
Se cometieron errores en todo el proyecto que lo llevó a este punto. La falta de aportes o requisitos sólidos de los usuarios, la falta de una gestión adecuada del producto y el control de cambios para gestionar los requisitos y necesidades cambiantes, y la falta de recursos técnicos adecuados para implementar causaron los problemas tal como existen hoy en día. Sin embargo, no sé si obsoleto es la palabra correcta. ¿La tecnología subyacente se basa en marcos y tecnologías no compatibles o simplemente no es la tecnología más avanzada o ideal?
Estás en una posición de menor poder y eres temporal en eso. No importa si tienes razón, no esperaría que un interno me "rechazara". Espero que aprendan, discutan los problemas tal como los ven y sigan las órdenes. Eso es todo. Una vez que se da una orden, espero que se lleve a cabo lo mejor que pueda, porque el momento de la discusión ha terminado en ese momento.
fuente
Eres un interno. Dudo mucho si está remotamente al tanto de los imperativos comerciales diarios en su conjunto y, como han notado otras personas, una base de código de 5 años no es realmente tan antigua.
Las decisiones sobre el reemplazo de los sistemas heredados no siempre se manejan técnicamente; son impulsados por los requisitos comerciales cambiantes. Los aportes a estos pueden ser dificultades relacionadas con el mantenimiento; pero al final del día, debes reconocer que tu posición no necesariamente significa que tienes todo el conocimiento disponible y requerido. Llegaría al extremo de decir que en realidad tienes muy poco del conocimiento requerido para decidir cuál es el mejor movimiento en la actualidad.
Mi consejo para usted es este: aprenda de la experiencia y deje de asumir que su conocimiento supera al de las personas que tienen que administrar el negocio día a día.
Su trabajo es mantener el sistema funcionando, no sugerir un reemplazo nuevo y brillante.
Me parece que muchos programadores jóvenes no se dan cuenta de que el mantenimiento de sistemas más antiguos es una parte más importante de la programación que el diseño de nuevos sistemas brillantes /
fuente
No retrocedas. Lo único que debe hacer es expresar sus preocupaciones de manera clara y concisa. El hecho es que la mayoría de las empresas en las que trabajará en el futuro tendrán sistemas heredados. Esos sistemas heredados deben mantenerse porque en muchos casos son demasiado caros de reemplazar.
En muchos casos, incluso puede tener las mejores intenciones de reemplazar el sistema actual con un sistema mejor, sin embargo, puede simplemente introducir errores nuevos y diferentes ... cuando salga del sistema, se convertirá rápidamente en un sistema heredado nuevamente y la compañía lo hará. estar en el mismo lugar que estaba antes. Nada es obsoleto hasta que ya no sirva a su propósito o sea completamente incompatible con los sistemas modernos. Mi empresa tiene un sistema de más de 20 años que ahora estamos convirtiendo a ASP.NET. El sistema aún se ejecuta, pero el soporte para la tecnología anterior está disminuyendo y hacer que funcione con los navegadores web modernos es cada vez más lento.
Lo que puedes hacer:
Deja las cosas más limpias
Cuando mantengas algo, déjalo más limpio que cuando empezaste. haga su arreglo, pero también limpie las cosas para que la próxima vez que alguien necesite hacer una modificación sea más fácil de entender.
Crear documentación
Si la falta de documentación es un problema, cree la documentación. Cuando esté trabajando en una parte particular del sistema, documente.
Hazlo menos doloroso
Como dije, puedes expresar tus preocupaciones, pero lo mejor es que solo trabajes diligentemente en el sistema y hagas que sea mejor trabajar para aquellos que están después de ti. Corrige los errores correctamente. Documento. Código disperso de olores. Hacerlo mejor. Y cuando hagas estas cosas, hazles saber a tus superiores. Dígales que está haciendo X, Y y Z para mejorar el proceso de desarrollo. Eso genera credibilidad y, a la larga, eso lo ayudará a usted y a su empresa más que cualquier otra cosa.
fuente
¡NO LO HAGAS! ¡Esta es una gran oportunidad!
¡Eres una pasantía para aprender! Este proyecto es un mundo real como se pone.
Tienes mucha suerte de tenerlo. El hecho de que no estés calificado no es asunto tuyo. (Si \ cuando la gerencia se dio cuenta de esto, habrá ganado mucho)
USTED estará calificado una vez que haya terminado con esta pasantía, y esa es una gran noticia.
PD: Haz copias de seguridad religiosamente, asegúrate de que TODO lo que hagas pueda revertirse. Comience con los problemas que son "soluciones fáciles", pero grandes problemas para los usuarios. Toma pequeños pasos.
fuente
Supongo que, en un sentido muy teórico, no existe un sistema Legacy . Tengo un teléfono muy antiguo (un sistema heredado), y en estos días hay buenos teléfonos Android (plataformas modernas), pero mi teléfono funciona y hace lo que necesito. ¿Por qué debería tirar eso?
Todos los sistemas que usted llama "legado" hoy en día fueron un día los más modernos. Es solo el tiempo que necesitamos. Además, cuando hay un trabajo considerable en su lugar, no es que volver a hacer todo de nuevo en las plataformas modernas, significa que estará automáticamente libre de errores (o sin dolor).
Esto es lo que te recomiendo que hagas:
Deja de lado tu disgusto por el "sistema heredado" primero. Esto te hará muy contraproducente.
Comience a documentar lo que hace ahora y lo que piensa. Aunque paso a paso. Simplemente no hay mejor momento para hacer documentación que aquel en el que te das cuenta de que lo necesitas.
En lugar de intentar retrasar el avance del "sistema heredado", intente definir la ruta para que salga sin problemas. Intente ver que puede convencer a la gerencia de que el desarrollo más nuevo que puede aislarse, puede hacerse paso a paso en plataformas más nuevas sin romper la interoperabilidad con los sistemas antiguos. Lentamente (y esto será muy lento) a medida que las cosas evolucionen, la necesidad de mantener el sistema heredado desaparecería. Esa es la única forma de decir adiós a cualquier sistema antiguo.
Dipan
fuente
La verdad es que nadie les da a los pasantes el trabajo que quieren hacer. Cuando eres la persona más joven, obtienes el trabajo menos emocionante. Qué tan bien manejas personalmente eso dice mucho a la organización en cuanto a si pueden confiar en ti para hacer más el trabajo emocionante.
Así que aquí hay una oportunidad invaluable para demostrar que puede cumplir haciendo las correcciones de errores, que puede refactorizar haciendo que cada parte del código que toque sea un poco mejor, que pueda crear pruebas unitarias, comenzando a crearlas para este sistema y que puede documentar creando documentación para la próxima alma pobre que está atrapada con este sistema. También le brinda la oportunidad de demostrar que puede tratar con los usuarios de manera efectiva (para obtener más detalles sobre los errores reportados) y satisfacer sus necesidades. Si el proyecto no está ahora en control de fuente, colóquelo allí y si los errores no se rastrean en un rastreador de errores, inicie uno. Este tipo de acciones le mostrarán cómo trabajar profesionalmente.
O podría tomar el camino opuesto y simplemente criticar lo malo que es el proyecto y lo genial que sería reemplazarlo. En ese caso, es casi seguro que no se le ofrecerá un trabajo en esa compañía después de su pasantía.
fuente
Probablemente no tenga suficiente información para determinar si es rentable ir otro año o no. Sería interesante entender a la empresa y por qué están agregando usuarios. Parece que puede haber cierto crecimiento y simplemente no pueden darse el lujo de dar un paso atrás financieramente o bajo ciertas limitaciones de tiempo para crear otra aplicación. Crear una nueva aplicación rara vez es la mejor opción de todos modos. 5 años no es tan viejo a menos que lo construyan sobre tecnología antigua para empezar.
fuente