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.
Respuestas:
La cita de Martin Fowler es relevante: "Puede cambiar su organización o cambiar su organización". Dado que aparentemente ha decidido cambiar su organización (mejorarla) en lugar de cambiar su organización (trabajar para una organización diferente), aquí hay algunas sugerencias.
Primero, gran parte de su curso de acción depende de los detalles sobre las estructuras de poder y la política en el trabajo. ¿Hay un administrador de desarrollo de software o varios? Si hay varios, ¿hay alguno de ellos que no sea reacio al cambio? ¿Cuántos desarrolladores de software hay? ¿Los desarrolladores están interesados en cambiar? Si es así, hay algunos cambios que debería poder realizar incluso sin la aprobación de la gerencia. (Como sugiere Fowler en Refactorización , es posible que ni siquiera tenga que decirle a la gerencia. Es probable que lo contraten para desarrollar el software lo mejor que pueda, así que si hay una mejor manera de hacerlo, simplemente hágalo).
En segundo lugar, tenga en cuenta que la administración puede tener buenas razones para lo que están haciendo. Eres un desarrollador de software; su trabajo es desarrollar un buen software y conocer buenas técnicas para hacerlo. El trabajo de la gerencia es comprender los problemas más generales y las consideraciones comerciales que pueden estar más allá de su alcance. Incluso si tiene razón y están equivocados acerca de cuáles son las consideraciones comerciales (sus preocupaciones sobre la falta de innovación, la entrega tardía, las quejas de los clientes, etc.), comprender de dónde proviene la administración lo ayudará a comunicarse en sus términos, aliviar sus preocupaciones, y así sucesivamente.
Tercero (y relacionado), asegúrese de poder hablar el idioma de los negocios. Una empresa no está (correctamente) directamente relacionada con buenas prácticas de desarrollo de software; una empresa se preocupa por atender las necesidades de los clientes y obtener ganancias. (Y muchas empresas obviamente atenderán las necesidades mínimas posibles para obtener ganancias). Serás más efectivo en la promoción del cambio si puedes explicar cómo las malas prácticas de desarrollo de software y la falta de innovación afectarán las ganancias de la compañía a largo plazo. salud.
Cuarto, cambiar la cultura de una empresa desde la posición de un trabajador de base es extremadamente difícil. James Shore (un consultor y autor ágil) escribió un diario de cambios describiendo sus propios esfuerzos para hacerlo. Recomiendo leerlo todo. Algunos puntos relevantes:
fuente
La respuesta breve obvia es abandonar la empresa. Otros ya se han ido, y su gerente es una obstrucción activa para el progreso. Si te quedas en esa posición, decaerás lentamente (tanto en la moral como en las habilidades). Encontrar un nuevo trabajo no siempre es fácil, pero en este caso es necesario.
En caso de que elija no abandonar la empresa (la primera línea de su pregunta lo delató):
¿Tu jefe tiene un jefe? Si es así, ¿cómo ve el jefe ese producto? ¿Puedes (me atrevo a decirlo?) Pasar por alto la cabeza de tu gerente y acercarte a su jefe? No lo fastidie con detalles técnicos, solo exprese interés y entusiasmo en crecer dentro de la empresa. Presente ideas tangibles para mejoras que puedan afectar de manera medible el resultado final. Es posible que te asciendan por debajo del obstáculo.
Sin embargo, tenga cuidado: mientras que algunas ruedas chirriantes se engrasan, otras se reemplazan. Harás que a tu gerente te desagrade mucho. Él va a escuchar sobre esto, y él va a decir cosas desagradables sobre usted a su jefe. Camine con cuidado, pero recuerde: sin riesgo, sin recompensa.
Lo peor que puede suceder es que esté buscando un nuevo trabajo, lo que debería hacer de todos modos.
fuente
Parece que es hora de que aprendas sobre vacas en efectivo. Ve aquí y aquí . Y eche un vistazo a la Matriz de crecimiento compartido . El GSM proporciona información adicional sobre por qué la vaca de efectivo es un buen estado para estar.
Investopedia (segundo enlace) probablemente tenga la mejor cita en este caso.
Como notó, hay algunas ventajas de estar en un proyecto de vaca de efectivo.
Y como también notó, hay algunos inconvenientes en esos proyectos.
Una vez trabajé en un proyecto donde tuve muchas quejas similares a las que has planteado. Recuerdo claramente que compartí mis preocupaciones sobre la base del código con mi jefe en ese momento. Su visión no fue particularmente esclarecedora, así que no la compartiré. Pero mantuve el proyecto y la verdad sea dicha, fue uno de los mejores proyectos que he visto. No, no fue llamativo. Sí, no cumplimos con los plazos. Sí, acumulé algunas marchas de la muerte desde allí. No, la tecnología de código no era tan innovadora, pero generamos algunas soluciones sorprendentes.
El problema fui yo. No tenía suficiente perspectiva para entender lo que realmente requiere una base de código para sobrevivir. No tenía la experiencia para ver dónde realmente estaba ocurriendo la innovación. No entendía los fundamentos del mercado que dictaban cuál era el nivel apropiado de financiación para ese proyecto de vaca de efectivo.
Le animo a que vea esto como una oportunidad de aprendizaje para comprender mejor cómo funciona el negocio y cómo puede mejorar sus habilidades para adaptar un producto a las necesidades del negocio. Si bien el trabajo puede no ser llamativo, el potencial de aprendizaje es alto y esas habilidades te ayudarán mucho más adelante en tu carrera. La mayoría del desarrollo a nivel corporativo gira en torno a todas las limitaciones que acaba de mencionar. El código apesta; las cosas se pusieron en su lugar para contener plazos que ya habían escapado; Muchos desarrolladores son resistentes al cambio.
En algún momento, seguirás saliendo del proyecto. Las lecciones que puedes llevarte contigo pueden ser lecciones reales para hacer carrera.
fuente
Su gerente probablemente se resiste al cambio porque no ve que el valor (comercial) esté cambiando las prácticas. El negocio no ve ningún problema real porque lo que se le pide al equipo de desarrollo finalmente se hace y las quejas de los clientes no llegan a las personas que se preocupan y / o pueden hacer algo para garantizar un mejor resultado. O eso o la empresa ha llegado a aceptar el estado actual de las cosas como inevitable.
Si va a cambiar las prácticas de desarrollo, debe mostrarles que el estado actual de las cosas no es inevitable. Y la única forma en que se le escuchará es creando un caso de negocios que muestre cómo el estado actual de las cosas está aumentando el costo del producto y frenando el potencial de ingresos dado otro estado de cosas.
Para construir ese caso de negocio, necesita hablar con el gerente de producto de este software. El gerente de producto es la persona que decide la prioridad de los artículos que se desarrollarán en función del valor comercial que representan. El gerente de producto es (debería ser) el que puede ver el beneficio y el valor comercial de poder construir un mejor software más rápidamente. (Y espero que no sea el mismo que está a cargo del equipo de desarrollo).
El caso de negocios debe abordar cuáles son los efectos en los ingresos comerciales de:
El caso de negocio también debe mostrar cómo las prácticas de desarrollo actuales están afectando la velocidad y el costo de desarrollar características muy necesarias:
Y, por supuesto, debe mostrar cómo la adopción de mejores prácticas de desarrollo va a afectar estas cifras.
Probablemente esté enfrentando la necesidad de una reescritura (principal) de partes (principales) del software. Incluso si no lo hace, entonces Cómo sobrevivir una reescritura desde cero sin perder la cordura es una lectura obligada sobre cómo abordar este tipo de proyectos.
Nota final: si el gerente de producto no está interesado en todo esto, estás perdido: saltar de barco.
fuente
Creo que este es un problema realmente difícil sin una solución directa. Aquí hay algunas ideas sobre lo que podría intentar hacer:
Miedo al cambio Sobre el tema de cambiar las cosas para mejor, entiendo por qué la gerencia teme el cambio. La gente está acostumbrada a las cosas de cierta manera y si la cambias, los usuarios se rebelarán (tal vez). El cambio es algo aterrador y generalmente requiere mucho pensamiento y estudio antes de hacerlo. Lo que necesita son datos que demuestren que esto es mejor y que los usuarios lo desean. Hablando de gmail, podría considerar hacer algo como "Google Labs", donde podría habilitar / deshabilitar nuevas funciones para que los usuarios puedan probarlas. Luego, conecte algunos datos recopilados para ayudarlo a hacer una copia de seguridad de sus cambios.
Cambio del proceso de desarrollo de software Nuevamente, cambiar es difícil, la gente no solo cambia porque usted dice que hay una mejor manera. Creo que en este escenario mi mejor recomendación es dar el ejemplo. Haga las cosas de la manera que desea que se hagan y muestre a las personas lo mejor que es. Además, y esta es la clave, debe encontrar a los demás que comparten sus pensamientos. Si puede conseguir algunas personas a bordo, eso ayudará mucho a su causa. Una vez que pueda mostrar algunos resultados, puede acercarse a la administración para ampliar estos cambios. Me parece que un esfuerzo de arriba hacia abajo y de base realmente ayuda a hacer cambios.
También en el lado de las herramientas, las empresas temen actualizarlas o cambiarlas porque cuestan dinero y los resultados de las nuevas herramientas no siempre son medibles. Mi recomendación aquí es hacer tus propias herramientas. Si hace el suyo propio, se ahorrará tiempo y trabajará mejor. Esperemos que la gente empiece a darse cuenta y luego quiera usarlos también.
Cambio de gestión Esto es difícil y no estoy seguro de cómo hacerlo, aparte de ser alguien que produce resultados y valora su opinión. Una vez que se valora su opinión, las personas pueden comenzar a escuchar o no.
Por último, recuerde que el cambio es difícil y lleva tiempo. Aguanta allí y comienza con algo pequeño y aumenta.
fuente