Estoy interesado en saber cómo lidiar con un proceso de desarrollo de software actual que no se ha cambiado durante años y que eventualmente conducirá a fallas del producto y del equipo. Sí, probablemente la forma más fácil de resolver esto es cambiar de trabajo, pero con esta economía es más fácil decirlo que hacerlo. Sin embargo, si tiene ejemplos específicos y ha visto o ha estado varias veces en la misma situación y cree que la mejor solución para abordar estos problemas es abandonar la empresa, entonces respalde su respuesta. El punto es que esta pregunta realmente tiene una respuesta, especialmente si varios expertos en el tema terminan indicando que la mejor ruta es la ruta A.
Sé que toneladas de desarrolladores han estado o están en situaciones similares. Esta es una de las principales razones por las cuales las empresas pasan de ser # 1 en su mercado a convertirse en las últimas o incluso fuera del mercado. Esperemos que las respuestas en esta publicación ayuden a otros desarrolladores que enfrentan obstáculos similares. En un equipo de desarrollo pequeño o grande, esto suele suceder:
- Parece que a algunos desarrolladores no les importa y deciden seguir la corriente y prefieren dejar el código con un montón de código que huele como está y el proceso de desarrollo como está,
- Otros se cansan de ningún cambio y renuncian y se mudan a otra compañía,
- Otros parecen tener miedo de hablar y prefieren quedarse callados,
- A veces, muy pocos desarrolladores o solo uno intenta hablar sobre la mejora del producto, y le dice al equipo lo importante que es seguir las mejores prácticas de codificación y los beneficios de hacerlo para los clientes, usuarios y equipo. Este tipo de desarrolladores generalmente deciden quedarse con el equipo debido a razones como la compañía ofrece beneficios que muy pocas compañías de software ofrecen, o el producto tiene mucho potencial, etc.
El producto en nuestro equipo es solo una fracción de donde la empresa obtiene sus ingresos, ya que tiene un conjunto de productos (esta empresa no es una empresa de software / hardware; por lo tanto, no hay litigios de patentes constantes, al menos por ahora, lo que crea trabajo inestabilidad). Lo que he aprendido hasta ahora durante estos años de las experiencias de otros desarrolladores y mi experiencia es que para conocer realmente un equipo de desarrollo, lleva tiempo, no días, ni semanas, sino unos pocos meses. Durante el proceso de entrevista si el equipo quiere contratarte o te necesita; hacen que todo suene genial, y pueden decirte lo que quieres escuchar. Sin embargo, la realidad es diferente cuando comienzas a trabajar en ese equipo y comienzas a cavar dentro del código y avanzas hacia el proceso SDLC completo. Esto es cuando, como desarrollador, comienzas a ver la realidad del trabajo en el que te metiste. Esta realidad hace que sea difícil querer mudarse de una compañía a otra porque es difícil saber si la compañía a la que se mudará será mejor o peor. Sí, puedes leer las reseñas de Glassdoor, etc., pero ¿cuántas de esas reseñas en línea son reales y no de RRHH?
¿Cuál sería la mejor manera de abordar los problemas descritos a continuación considerando que el gerente desde el principio siempre se ha resistido a cambiar, y los desarrolladores anteriores han estado haciendo lo mismo durante años?
Falta de innovación en el producto durante años: el producto tiene mucho potencial y genera buenos ingresos para la empresa, pero parece que se fabricó hace 20 años. Algunos usuarios se han quejado de que el producto no es fácil de usar ni intuitivo, y otros han mencionado que están acostumbrados a aplicaciones como Gmail y se sienten frustrados al usar el producto debido a que no tienen características similares. El problema principal aquí es que cuando intentas como desarrollador hacer cambios en el producto y comienzas a mover elementos principales del producto a solo un par de píxeles de distancia (para que sea más fácil de usar o intuitivo), el administrador entra en pánico y te dice para volver a ponerlo donde estaba. Si intenta agregar una función que beneficiará la productividad de los usuarios, el administrador le pide que la elimine porque "los usuarios están acostumbrados a hacer el proceso de la manera que es, etc." Creo que entendió la resistencia al cambio, la mejora y la innovación (el gerente no está abierto al cambio, incluso cuando usted, como desarrollador, proporciona argumentos sólidos de beneficios). La compañía tiene algunos competidores en el campo (los productos de algunos de ellos son mucho más competitivos), pero de alguna manera la compañía ha mantenido a los clientes actuales durante años.
Falta de coordinación de la gestión del proyecto: como resultado de esto, algunos proyectos se entregan tarde, con errores y algunos clientes se quejan (los clientes también informan los errores), o el presupuesto se usa demasiado rápido antes de entregar el proyecto, etc. Algunos consejos de coordinación de proyectos y las ideas ahora se están utilizando regularmente para rastrear el progreso de los proyectos y tareas a realizar.
Prácticas de desarrollo de software erróneas: el olor de código se ve en la mayoría de los archivos, si no en todos, sin documentación, redundancia de código, nivel de front-end y back-end mezclados en el mismo archivo, herramientas de desarrollo obsoletas, sin un entorno de prueba real ni herramientas de prueba (solo copie y pegue archivos desde el entorno de desarrollo hasta la producción, y luego pruebe manualmente que las cosas se vean bien y se publiquen). La mayoría de las herramientas de desarrollo que uso para el desarrollo y las pruebas son desconocidas por el equipo, ya que el equipo solo usa 2 IDE para el desarrollo del código y el control de la fuente solo está disponible para el entorno de desarrollo. Otros desarrolladores han tratado de usar los marcos más recientes para mejorar los problemas actuales, pero al administrador no le gusta porque "¿qué pasa si te vas, entonces quién va a mantener ese código ?, vamos a dejarlo como está" Algunos de esos desarrolladores ya se fue y se mudó a otras compañías.
En resumen, estoy seguro de que a muchos desarrolladores de otras compañías les ocurren situaciones similares, pero debido a diferentes circunstancias, un desarrollador podría preferir permanecer en el equipo que ir a otra compañía por razones como (conveniencia del trabajo, flexibilidad laboral, beneficios de la compañía o solo porque no ha llegado una mejor oportunidad). No conozco una compañía perfecta, pero ¿cómo se comportaría usted como desarrollador y cómo abordaría todos estos problemas para mantener las cosas positivas y, en última instancia, promover el cambio para mejorar el producto y mejorar el proceso de desarrollo de software (si tiene muchos años de experiencia en desarrollo o solo unos pocos)? Sé que esta publicación es larga, pero preferí dar detalles adicionales para aumentar las posibilidades de obtener comentarios más útiles.
Muchas gracias por todos sus comentarios y tiempo.