¿Cómo manejar la administración impulsando los sistemas heredados?

  

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.

  

Ya he escrito un informe que indica mis inquietudes

Bien. Eso es sobre el alcance de lo que puedes hacer como interno. Para referencias futuras al escribir dichos informes, enfatizo la presentación de hechos concretos de una manera imparcial y profesional que carece de prejuicios emocionales. No sabe quién leerá el informe, posiblemente alguien que puede o no haber causado algunos de los problemas que está describiendo o que tomó decisiones que condujeron a estos problemas. Cualquier otra cosa que no sean hechos fríos pueden ser tomados por tales personas como una afrenta o una ofensa, y harán que no les agrades y posiblemente no tomen nada en serio.

  

La administración ahora quiere extender el proyecto por un año más, y en el proceso casi triplicará la base de usuarios

Tenga en cuenta que las decisiones de negocios 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 lidiar con la refactorización o una reescritura?

La mayoría de las veces no lo hacen, especialmente si el software no es el pan y la mantequilla de la compañía, y la calidad y la satisfacción del usuario con el software no afectarán directamente el resultado final. Tomar este tipo de decisiones a veces es la razón por la que ser un gerente apesta porque a menudo se encuentra en una situación de pérdida-pérdida, sin importar lo que haga.

  

mantener un sistema obsoleto que ha sido desarrollado por múltiples desarrolladores (en diferentes momentos) a lo largo de los últimos 5 años

Se cometieron errores a lo largo del proyecto que lo llevó a este punto. La falta de información 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 en la actualidad. Aunque no sé si obsoleto es la palabra correcta. ¿La tecnología subyacente se basa en marcos y tecnologías incompatibles, o simplemente no es la tecnología más avanzada o ideal?

  

Como pasante (o cualquier posición de nivel de entrada), ¿cómo "rechazo"?

Estás en una posición de menor potencia y eres temporal en eso. No importa si tiene razón, no esperaría que un interno me "rechazara". Espero que aprendan, discutan los problemas a medida que los ven y siguen las órdenes. Eso es todo. Una vez que se da una orden, espero que se lleve a cabo de la mejor manera posible, porque el momento de la discusión ha terminado en ese momento.

Eres un interno. Dudo mucho si usted está al día con los imperativos de negocios del día a día en su conjunto y, como otras personas han notado, una base de código de 5 años no es realmente tan antigua.

Las decisiones sobre la sustitución de sistemas heredados no siempre son impulsadas técnicamente; son impulsados por los cambiantes requisitos del negocio. La entrada a esos puede ser dificultades relacionadas con el mantenimiento; pero al final del día, debe reconocer que su posición no significa necesariamente que tenga todos los conocimientos disponibles y necesarios. Me atrevería a decir que en realidad tiene muy poco del conocimiento necesario para hacer el llamado sobre cuál es el mejor movimiento en este momento.

Mi consejo para usted es este: aprenda de la experiencia y deje de suponer que su conocimiento supera al de las personas que tienen que dirigir el negocio día a día.

Su trabajo es mantener el sistema en funcionamiento, no sugerir un nuevo reemplazo 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 del trabajo de programación que el diseño de sistemas nuevos y brillantes /

No empujes hacia atrás. Lo único que debe hacer es expresar sus inquietudes 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 costosos de reemplazar.

En muchos casos, incluso puede tener las mejores intenciones de reemplazar el sistema actual con un sistema mejor. Sin embargo, puede introducir errores nuevos y diferentes ... cuando abandone el sistema, se convertirá rápidamente en un sistema heredado nuevamente. La compañía estará en el mismo lugar que antes. Nada está obsoleto hasta que ya no sirve su propósito o es 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 funciona, pero el soporte para la tecnología anterior está disminuyendo y su funcionamiento con los navegadores web modernos consume cada vez más tiempo.

Lo que puedes hacer:

Deja las cosas más limpias

Cuando mantienes algo, déjalo más limpio que cuando empezaste. haga su corrección, 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, documéntelo.

Hazlo menos doloroso

Como dije, puedes expresar tus preocupaciones, pero lo mejor es trabajar diligentemente en el sistema y hacer que sea mejor para quienes lo buscan. Corrige errores correctamente. Documento. Dispersa el código del olor. Hacerlo mejor. Y cuando hagas estas cosas, avisa a tus superiores. Dígales que está haciendo X, Y y Z para mejorar el proceso de desarrollo. Eso crea credibilidad y, a largo plazo, ayudará a usted y a su empresa más que a cualquier otra cosa.

¡USTED NO LO HACE! ¡Esta es una GRAN oportunidad!

¡Eres una pasantía para aprender! Este proyecto es un mundo real tal como es.

Tienes mucha suerte de tenerlo. El hecho de que no esté calificado no es su preocupación. (Si \ cuando la gerencia se dio cuenta de esto, habrá ganado mucho)

USTED será calificado una vez que haya terminado con esta pasantía, y eso es una gran noticia.

PS: Haz copias de seguridad religiosamente, asegúrate de que ALGO que hagas pueda revertirse. Comience con los problemas que son "soluciones fáciles", pero grandes puntos de dolor para los usuarios. Tomar pasos de bebé.

Supongo que, en un sentido muy teórico, no existe tal cosa llamada sistema heredado . 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 a los que llamas "legado" hoy, fueron un día el estado de la técnica. Es solo el tiempo que necesitamos. Además, cuando hay un trabajo considerable en marcha, no es volver a hacer todo el proceso nuevamente en las plataformas modernas, lo que significa que estará automáticamente libre de errores (o sin dolor).

Esto es lo que te recomiendo que hagas:

1. Deja tu disgusto por el "sistema heredado" primero. Esto te hará muy contraproducente.

2. Comienza a documentar lo que haces ahora y lo que piensas. Aunque sea paso a paso. Simplemente no hay mejor momento para hacer la documentación que en el que se da cuenta de que necesita una.

3. En lugar de intentar hacer retroceder el avance del "sistema heredado", intente definir la ruta para su salida sin problemas. Trate de ver que puede convencer a la administración de que el desarrollo más nuevo que se puede aislar se puede hacer paso a paso en nuevas plataformas sin romper la interoperabilidad con los sistemas antiguos. Lentamente (y esto será muy lento) a medida que las cosas evolucionan, la necesidad de mantener el sistema heredado desaparecerá. Esa es la única manera de decir adiós a cualquier sistema antiguo.

Dipan.

La verdad es que nadie le da a los internos el trabajo que quieren hacer. Cuando eres la persona más joven, obtienes el trabajo menos emocionante. Qué tan bien maneja usted personalmente eso le dice mucho a la organización si pueden confiar en que usted hará más el trabajo emocionante.

Esta es una oportunidad invaluable para demostrar que puede realizar 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 mediante la creación de documentación para la próxima pobre alma que está atascada con este sistema. También le da 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 código fuente, colóquelo allí y si los errores no se rastrean en un rastreador de errores, inicie uno. Este tipo de acciones le mostrará cómo trabajar profesionalmente. Todo esto es una experiencia mucho más valiosa que solo trabajar en una tecnología divertida haciendo un proyecto que se desechará después de que te vayas (las otras cosas a las que algunos internos se asignan).

O puedes tomar el camino opuesto y simplemente criticar lo malo que es el proyecto y lo genial que sería reemplazarlo. En cuyo caso, es casi seguro que no se le ofrecerá un trabajo en esa compañía después de su pasantía.

Probablemente no tenga suficiente información para determinar si es rentable ir otro año o no. Sería interesante entender a la compañía y por qué están agregando usuarios. Parece que puede haber cierto crecimiento y no pueden darse el lujo de dar un paso atrás financieramente o bajo ciertas restricciones de tiempo para crear otra aplicación. Construir una nueva aplicación rara vez es la mejor opción de todos modos. 5 años no es tan viejo a menos que, para empezar, lo hayan construido con tecnología antigua.