Problemas más comunes en un departamento de programación
Hace poco puede reunir a Javier Garzás, experto en metodologías AGILE y a Pablo Cruz, de Visual Trans, para hablar sobre una historia real de transformación a metodologías ágiles por videoconferencia con el fin de grabar la conversación. Al final salieron muchos temas y decidimos sacar varios episodios sobre la transformación AGILE. En este primer vídeo salieron varios problemas relacionados con el trabajo en equipo que padecen muchos departamentos de desarrollo de software.El objetivo de esta serie de vídeos no es otro que el de mostrar un caso real de las dificultades que entraña la gestión del cambio hacia una metodología AGILE partiendo de un sistema más tradicional en cascada, y no todo es ni tan fácil, ni tan guay como lo pintan. La gestión del cambio siempre es complicada.
Experiencias de un responsable de programación
Pablo Cruz nos cuenta su experiencia como programador y como coordinador de un departamento de desarrollo en todo el proceso transformación ágil en visualTrans, que lleva más de 20 años desarrollando soluciones software y ERP para el transporte y la logística (transitarios, agentes de aduanas, consignatarios y operadores logísticos integrales), y todo desarrollado en Velneo.Cuando comenzaron a trabajar con agilidad, tenían un departamento de programación de 8 personas. Prácticamente todos, además de programar, hacían tareas también de análisis al ser los "responsables" de cada uno de los módulos que llevaban. En este vídeo Pablo comenta que muchas veces los programadores tenemos un perfil individualista, y nos creemos que vamos a programar mejor las cosas que los demás o que haciéndolo en grupo.
Otra manera de hacer las cosas
Cuando Pablo programaba ya sabía que cada programador iba un poco a lo suyo, con sus tareas de programación, sin ayudar a los demás, creándose en ocasiones muchos cuellos de botella en los flujos del trabajo. Esta "insolidaridad" no se debía a un mal ambiente, sino a que cada desarrollador era responsable de su parcela y los demás no sabían ni cómo ayudar.Muchas veces se percibía la ayuda como un estorbo, más que como una forma de avanzar, ya que cada programador tenía la visión de su propia parcela y no estaba abierto ni a compartir información, ni a explicarle al resto su trabajo... Lo único que importaba es que cada uno de los módulos funcionara bien. Eso creaba desajustes ya que había momentos en que un módulo necesitaba más mantenimiento o programación que otros y los demás solo podían "mirar desde la barrera", con impotencia y cierta resignación.Javier Garzás siempre se refiere a esta cultura de trabajo en cascada como el lado oscuro, o los walking dead. Explica que esta forma de trabajar es muy común en las empresas de desarrollo, que siguen metodologías que considera anticuadas, como el trabajo en cascada.Cuando Pablo tomó la coordinación del departamento de programación estos problemas se hicieron más evidentes para él al tener que coordinar todo el trabajo del departamento y fue en ese momento cuando tomó verdadera conciencia de que había que cambiar la forma de trabajar en el departamento.
La programación y la mentalidad de silo
Cada desarrollador era responsable de su propio módulo y nadie más se podía meter a programar lo del resto, y se creó una mentalidad de silo dentro del departamento que afectaba también al resto de la organización, porque en realidad la mentalidad del silo es realmente una forma organizativa de pensar. Ocurre cuando los departamentos o grupos de gestión no comparten información, objetivos, herramientas, prioridades y procesos con otros departamentos. Se cree que la mentalidad del silo tiene un impacto en las operaciones, reduce la moral de los empleados y puede contribuir al fracaso general de una empresa o de sus productos y cultura.Los silos organizacionales típicamente no comparten las mismas prioridades, objetivos o incluso las mismas herramientas, por lo que los departamentos operan como unidades de negocio individuales o entidades dentro de la empresa. Los silos ocurren debido a la forma en que una organización está estructurada. Los gerentes son responsables de un departamento específico dentro de una organización y cada gerente tiene diferentes prioridades, responsabilidades y visión.A menudo, los gerentes en las empresas de programación no son conscientes de las prioridades y objetivos de otros departamentos y hay poca comunicación, colaboración y trabajo en equipo entre estas unidades de negocio.
Rompiendo con los silos en programación
Hoy en día, los gerentes tienen la tarea de romper la mentalidad de silo para asegurar que la información fluya libremente entre todos los departamentos de una organización. El objetivo es cambiar y mejorar las relaciones entre las unidades de negocio mediante la promoción de un mejor trabajo en equipo. La comunicación y la colaboración son esenciales para romper la mentalidad del silo.En las empresas de tecnología existe la necesidad de romper los silos de TI. En el lado del desarrollo se necesita una mejor comunicación y colaboración para servir mejor a las necesidades empresariales de TI de la organización. Pablo cuenta que para él esto ya supuso su primer reto dentro de la coordinación del departamento de desarrollo.
Los silos pueden arruinar tu software
La división del trabajo es una forma lógica y contrastada de resolver la mayoría de los problemas de forma más rápida. La especialización también es habitual, especialmente en áreas que exigen una variedad de habilidades demasiado amplias para que alguien pueda dominarlas completamente. En programación ambos enfoques pueden ser útiles a corto plazo, pero la experiencia demuestra que muchas veces es mejor avanzar más lento y de forma acompasada porque ningún desarrollo es bueno que dependa exclusivamente de un programador.Al igual que su homónimo agrícola, los silos de programación parecen ser inocuos y eficientes. Proporcionan una manera de organizar el conocimiento y la experiencia de tu equipo de desarrollo de software muy bonito sobre el papel: Ana es la experta en X, Santa y Diego son dueños de todo lo que tiene que ver con el Sistema Y.A primera vista, los silos parecen hacer que la responsabilidad y la identificación con la propiedad de los desarrollos sea simples y clara. Pero desde la experiencia, son tremendamente negativos, lo que conduce a proyectos de software más lentos y fragmentados y a trabajar en detrimento de una buena dinámica de equipo.
Dos tipos de silos de programación más frecuentes
Cuando se piensa en silos en programación de software, probablemente se piensa en silos verticales: una sola persona o un solo equipo que es dueño de una funcionalidad, o de un subsistema o un módulo completo.Pero a diferencia de sus equivalentes en tierras agrícolas, los silos en el desarrollo de software pueden extenderse tanto horizontal como verticalmente. ¿Alguna vez has trabajado en un proyecto que tuviera una división estricta entre los desarrolladores de backend y frontend, o en un equipo de devops que estuviera totalmente desvinculado de los desarrolladores? Estos son buenos ejemplos de silos horizontales.
Porqué los silos son malos para el equipo de programación
¿Por qué Pablo en el vídeo se muestra tan contrario a los silos? En su experiencia, son poco saludables para la empresa y para los programadores ya que en su experiencia causan una serie de problemas específicos como explica en el vídeo.#1 Los silos crean cuellos de botella en el seno de los equiposEsta es obvia. Cuando una persona tiene todo el conocimiento sobre una parte en particular de un proyecto de desarrollo de software, entonces todo lo relacionado con esa parte puede atascarse por esa persona. Incluso si asumes que en el mejor de los casos -es decir, un individuo que está dispuesto a compartir lo que sabe con el resto del equipo-, tienes que lidiar con el factor tiempo de aceleración y otras ineficiencias cuando más te pueden hacer daño.#2 Los silos hacen que el proyecto se vuelva más vulnerableEsta es la consecuencia natural del punto anterior. Si una persona posee todo el conocimiento de un equipo sobre alguna parte de la base de código, el factor autobús es peligrosamente alto. Todo, desde unas simples vacaciones hasta algo más serio como que esa persona se marche a otro trabajo, tiene el potencial de arruinar todo el proyecto, o al menos ralentizarlo considerablemente.#3 Los silos reducen la cohesión del equipo de desarrolloEste problema es particularmente evidente en equipos con silos horizontales. La segregación de las personas o equipos que trabajan en el código puede perjudicar mucho la cohesión de un producto.Los equipos que están demasiado separados empiezan a formar visiones completamente diferentes (y a menudo incompatibles) sobre un producto o una funcionalidad. Esto puede conducir a conflictos dentro del equipo e incluso a errores o bugs en el sistema.#4 Los silos promueven la desconfianza y las dicotomías en la empresa y en los equiposEste es el mayor problema con silos. Cuanto mayor sea la separación entre las personas o los equipos, más probable es que cada unidad se sienta como si estuviera trabajando en un proyecto diferente con sus propias metas y objetivos. Si esos objetivos comienzan a estar fuera de sincronía con cualquier otro equipo de la empresa, se entra en el terreno de la atribución de culpas, los conflictos y, en definitiva, en productos empantanados.
Una manera más inteligente de programar y especializarse
Si quieres saber más de como organizar mejor las tareas de un departamento de programación no te pierdas el canal de Javier Garzás en Youtube. Al margen de sus consejos, mucho mejores que los míos, simplemente añadir que la especialización no siempre es mala, y es necesaria. Otra cosa es que se fomente de forma responsable e inteligente por el bien de los equipos de desarrollo.El hecho de que se eviten los silos no significa que se deba evitar la especialización. Puede ser muy importante, y a veces incluso crítico para el éxito de un equipo. Es factible ser la persona más conocedora de un módulo o un subsistema en particular, a la vez que se comparte y se desarrolla con otros programadores.Y es posible especializarse en el desarrollo de backend y bases de datos, sin dejar de conocer suficientemente bien el código de la interfaz de usuario para ponerlo a prueba y sentir empatía con los que trabajan en el frontend. (Al fin y al cabo, están desarrollando el mismo software que los demás, ¿no?).Se puede dividir y conquistar. Se puede especializarse. Lo que hay que evitar a toda costa son los silos. Si quieres ver todos los vídeos de la serie Primeros pasos hacia una metodología AGILE, te recomiendo que lo hagas ahora :)
4 problemas más comunes para un departamento de programación en 2024
Los problemas más comunes en un departamento de programación pueden variar según la organización, pero aquí hay cuatro problemas comunes que podrías enfrentar:
1. Comunicación ineficiente: La falta de comunicación clara y efectiva entre los miembros del equipo puede conducir a malentendidos, errores y retrasos en los proyectos. Esto puede incluir la comunicación entre desarrolladores, así como entre el equipo de programación y otros departamentos, como diseño, marketing y ventas.
2. Planificación y gestión de proyectos deficientes: La falta de una planificación adecuada, priorización y seguimiento del progreso de los proyectos puede llevar a la sobrecarga de trabajo, incumplimiento de fechas límite y baja calidad del producto final. Una gestión ineficiente del proyecto puede generar una distribución desequilibrada de tareas y recursos, y dificultar la capacidad del equipo para cumplir con los objetivos establecidos.
3. Falta de habilidades técnicas actualizadas: La tecnología cambia rápidamente, y los equipos de programación deben mantenerse al día con las últimas herramientas, lenguajes de programación y prácticas de desarrollo. La falta de habilidades técnicas actualizadas puede resultar en la incapacidad de adaptarse a las nuevas tecnologías y la utilización de enfoques obsoletos, lo que puede afectar negativamente la calidad y el rendimiento del software.
4. Falta de estándares y buenas prácticas de desarrollo: La falta de estándares de código y buenas prácticas de desarrollo puede conducir a un código de baja calidad y difícil de mantener. Esto incluye la falta de documentación adecuada, la falta de pruebas y control de calidad, y la falta de un proceso de revisión de código sistemático. Estos problemas pueden aumentar el tiempo necesario para solucionar errores, implementar nuevas funciones y mantener el software en el largo plazo.
Para abordar estos problemas, es importante fomentar una comunicación abierta y eficiente, implementar una planificación y gestión de proyectos sólida, invertir en la formación y el desarrollo profesional de los empleados, y establecer estándares y buenas prácticas de desarrollo en el equipo.
