Contextualiza a tu equipo

Esta semana mi cliente Clickennet ha decidido que es el momento de dar a su equipo motivación y conocimientos para que ellos mismos puedan, a partir de ahora, ser capaces de mejorar los procesos que existen en la empresa para llevar a cabo un proyecto de software de manera satisfactoria, algo en lo que les he estado ayudando desde hace más de un año. Personalmente tanto la idea como el momento me han parecido geniales y muy acertados, así que les he propuesto dar una pequeña charla sobre algo que creo que es muy importante para los desarrolladores, contextualizar.

Creo que contextualizar (y hacerlo a diferentes niveles) es muy importante para que el desarrollador pueda tomar las mejores decisiones, tanto técnicas como a nivel de procesos y pueda entender el porqué de los procesos que hay establecidos (o el porqué no) y por supuesto para que pueda en el futuro seguir tomando esas decisiones.

 

Contexto histórico

¿Por qué ahora están tan de moda las palabras Agile o SCRUM? ¿Sabes a partir de qué momento en la historia se empezaron a oír estas palabras y cuál es el motivo? ¿Por qué ahora tienes que programar las funcionalidades semana a semana o mes a mes, no sería mucho más fácil que nos dejaran en paz hasta que el proyecto estuviera terminado?

Pasado

Esto último es exactamente lo que se hacía antaño: desarrollar un proyecto software durante un año o más, desde la recogida de requerimientos y documentación al desarrollo y finalmente despliegue y distribución del software. Esta metodología es conocida por el nombre de waterfall y se usó mucho entre los años 1970-1990, consiste en dividir un proyecto por fases y pasar de una fase a otra cuando la anterior está terminada. ¿El problema? Que casi siempre se terminaba entregando un proyecto obsoleto, ya fuera porque la tecnología había avanzado o porque los requerimientos del negocio habían cambiado (en esos tiempos también existían startups). Aunque la metodología waterfall se hizo ya con la intención de poder soportar cambios y volver a una fase anterior para hacer ajustes, en la práctica esto acarreaba un coste económico elevado y se terminaba obviando.

A causa de estos problemas, personas como Jon Kern, Kent BeckWard Cunningham o Robert C. Martin se empezaron a reunir de manera informal para idear maneras más rápidas de producir y entregar software, consiguiendo así ponerlo a disposición del usuario en un menor tiempo y obtener feedback para poder hacer ajustes y mejores decisiones sobre el futuro de los proyectos. Es a través de estas reuniones que nace allá por el año 2000 el movimiento Agile, el manifiesto Agile y todas las metodologías derivadas como SCRUM, RAD o Extreme Programming, metodologías que han influido en mayor o menor medida en la forma en la que trabajamos hoy en día.

Unas décadas antes del nacimiento del movimiento Agile, sobre el 1940, en la industria automovilística ocurría algo similar con el movimiento lean thinking, que buscaba eliminar los desperdicios de todo tipo, materiales, temporales, enconómicos, etc.

Presente

Es la convergencia de estos dos movimientos lo que sienta las bases de cómo se desarrollan los negocios tecnológicos hoy en día, por mucho que Agile se originara para construir software y lean thinking para construir empresas y sus productos, se influencian uno al otro constantemente dando como resultado por ejemplo herramientas como el Kanban, originalmente usado por Toyota para construir coches hoy en día es extraño encontrar equipos de desarrollo de aplicaciones que no lo usen.

Ahora mismo la herramienta más de moda que aprovecha esta sinergia y que es el nirvana del desarrollo Agile es la integración continua y la actualización continua (CI/CD), juntamente con la cultura DevOps, ya que permiten llevar las iteraciones del desarrollo de sotfware al día a día (por no decir a la hora) y desplegar con facilidad varias versiones de una aplicación y por ejemplo llevar a cabo un test A/B que ayude a decidir qué dirección tomar y así reducir al máximo los desperdicios.

Futuro

Es increíble ver como la industria del desarrollo de software ha pasado en pocas décadas de solucionar problemas en años a tardar días y ver que no tiene intención de dejar de optimizar procesos y herramientas. A causa de esta reinvención continua, es fácil que los equipos queden atrás con el tiempo si no se preocupan de estar actualizados y pierdan la oportunidad de tener herramientas tan potentes como la CI/CD por el simple hecho de no saber que existen o de no invertir tiempo en implementarlas por no querer parar de producir.

Contexto de tu cultura empresarial

Este tipo de contexto creo que es importantísimo si eres una empresa pequeña.

Si lideras un equipo, explícales a tus programadores para qué sirve su trabajo, evita que se sientan unos "frikis" que únicamente saben picar código o una pequeña pieza de un engranaje. No olvides que los tienes para aplicar soluciones, para pensar, no para usar un teclado y entender un lenguaje.

Explícales los objetivos de la empresa para que todos podáis estar alineados, ¿de qué te sirve un desarrollador si resulta que no está de acuerdo con la ideología de la empresa y se va a ir tan pronto como tenga experiencia? ¿y lo mucho que ganas por tener a un ingeniero entendiendo cómo funcionan todas las piezas de un puzzle? Coméntales por ejemplo si quieres equipos multidisciplinares o gente especializada.

Cuéntales quién y cómo es el cliente para el que estáis trabajando, aunque nunca medien una palabra con él, que entiendan el por qué esa persona necesita la aplicación y más importante aún por qué la necesita en los plazos establecidos. Nunca es agradable oír a un compañero de equipo quitarle importancia a una entrega, como si no pasase nada si se retrasa unos días, ¿y si el cliente va a asistir a una feria donde quiere enseñar una funcionalidad en concreto? ¿y si la empresa pierde el cliente y eso termina en un despido por no poder asumir el coste de las nóminas?

Como desarrolladores, creo que tenemos la responsabilidad de hacer que nuestro trabajo sea lo más fácil y simple posible día tras otro y la manera de conseguirlo no es encerrarnos en la zona con unos auriculares (al menos no cada día) sino obteniendo contexto, buscándolo proactivamente para poder hacer ajustes y mejoras en los procesos de la empresa o en proyectos. Una vez hayas encontrado una manera de mejorar las cosas y tengas una buena idea, díselo a tus líderes y convéncelos de que necesitas realizar esa idea para hacer mejor tu trabajo

 

Conclusión

Espero que mi intención en este artículo haya quedado clara.

Si eres un desarrollador, pide contexto sobre tu empresa y sus clientes, infórmate mejor de por qué el desarrollo de software se gestiona como se gestiona y cuando tengas una idea para mejorar algún proceso, comunícala a tus líderes.

Si eres un project manager, CEO o CTO da contexto a tus empleados para que podáis trabajar mejor, dales la oportunidad de hablar y escúchalos y cuando te guste la idea que te plantean, busca la manera de sacar tiempo para que pueda ser implementada a expensas de dejar de producir durante unos días para poder ahorrar muchos más días en el futuro. 

En ambos casos, para obtener el contexto presente y futuro y así estar al día de los avances del sector, te recomiendo que socialices. Tanto a nivel global como local hoy en día es fácil estar informado y también relativamente fácil discriminar la información realmente valiosa para ti, lugares como twitter o medium es donde más se mueve el sector de las TIC. Una vez hayas encontrado un tema que quieras aprender, busca cursos online, busca un mentor o pídele a tu empresa que contrate a un instructor.

¿Te ha gustado el artículo? ¿Quieres que te avise de mis próximas publicaciones?

¿Quieres seguir aprendiendo?

¿Qué es npx?

No sé si os ha pasado lo mismo que a mí, y es que últimamente cuando encuentro repositorios en github que requieren la instalación de una CLI, por ejemplo el proyecto create-react-app, veo que de la noche a...

Seguir leyendo