Yendo más lejos, como hablamos de profesionales autónomos y autogestionados ya incluso los nuevos gerentes ni siquiera gerencian (¡Qué ironía!) (...) Son de ése estilo que verifican que todo vaya bien cada equis intervalo de tiempo y pare de contar... Son lo que yo llamo como "Gerente calibrador de ruta".
No puede haber una visión más errada de la academia e incluso de algunas empresas al solo orientar sus profesionales para dirigir quizás relegando aspectos más importantes de su formación técnica e incluso humana. Peor aún, tenemos el concepto que no somos potencia para el desarrollo de software, que para todo lo que necesitamos ya hay alguien o algo que lo hace mejor que nosotros mismos y en términos generales que la industria TI ya llegó a su punto máximo cuando aún se necesita avanzar a pasos agigantados. ¿Qué necesitamos para eso? Personas que se unten la manos, que vayan a las tripas del código... Mucho más que los dichosos nuevos gerentes.
Pero esta reflexión va un poco más allá, quiero abordar un problema casi propio del mismo desarrollador que quizás por temor o desconocimiento pareciera aceptar: No pensar.
Ser programador o desarrollador es un rol especial
Este subtítulo suena tonto, como sacado de un libro de superación personal tratando de mejorar el autoestima pero no es así. Conseguir programadores para cualquier empresa no es una tarea fácil y mucho menos si se buscan con experticia y calidad. Sin embargo, el rol parece haber perdido relevancia, no por que no sea importante sino porque parece haber quedado atrás escondido tras el teclado: Alguien que solo codifica.
No hace tiempo ví un meme: "Un programador es alguien que convierte el café en código". Y si bien es una aproximación cierta, es quizás peyorativa, ya que confirma de alguna forma este rol en algo superflúo, mecánico, carente de alma... Y no, lo que yo aprendí sobre programar es que es casi como un arte, una pasión.
El negocio no está por encima de la creatividad
Cuando entra un programador a una empresa, por lo general se le asignan tareas muy concretas. Muchas veces, los directores o líderes técnicos ya han resuelto todo el problema y el desarrollador solo tiene que codificar. Yo no estoy de acuerdo con esta perspectiva, casi siempre intento involucrar a todo el equipo desde el principio de la solución (Nótese el principio, no el requerimiento per sé) para que entre todos se construya la implementación y el aporte de los desarrolladores (Y otros roles como los testers) sea mucho más amplio y enriquecido.
Sin embargo, en cualquier caso esto no quita la oportunidad que el desarrollador tiene de pensar y de aportar mucho más desde su rol. Algunos personajes sostienen que un programador se hace valioso cuando se certifica y aprende un segundo idioma.... Yo creo que un programador se hace realmente valioso cuando aporta proactivamente mucho más de la tarea concreta que se le asigna.
¡Cuántas cosas se pueden hacer con el código! Y nos quedamos en que cuando se diga oprima A, salga B. Y aún si esa fuera la asignación concreta, siempre se pueden proponer nuevas formas que aparezca B, o nuevas formas de interactuar con A; o incluso cambiar A por C porque mejora aún más la experiencia de usuario. Es por esto que digo que los requerimientos de negocio no están por encima de la creatividad... porque distan tanto como la misma idea de la implementación. Incluso si una solución nueva para un producto no es viable por alguna razón, estoy seguro que la dirección y el mismo equipo notará que está corriendo las fronteras de su propio conocimiento y el de la organización con cada prueba de concepto que deseen explorar.
Siempre hay nuevas cosas por aprender, a semejanza del arte, es necesario aprender cierta técnica, ciertos lineamientos, ciertas condiciones pero de ahí adelante es lo que el artista quiera que sea. Por esto la invitación a los desarrolladores es a no dejarse perder entre las historias de usuario, la presión del tiempo y las pruebas de calidad... A ser creativos, a explorar siempre nuevas formas de hacer las cosas más obvias, de proponer sin miedo.
Para los líderes técnicos y directores será importante mantener motivados a los desarrolladores, permitiendo precisamente espacios para las pruebas de concepto y la adopción de nuevas tecnologías. Aunque se vea como pérdida de tiempo frente al negocio, con el pasar de las semanas, se traducirá en un equipo mejor preparado, motivado y más creativo para afrontar nuevos retos.
No hay comentarios:
Publicar un comentario