1
Programar no es ser una estrella de rock
El otro día leía el artículo Despedimos a nuestro mejor talento, la mejor decisión que tomamos. Cuenta la historia de un programador al que llaman “Rick”, por el personaje de la serie animada Rick y Morty. A pesar de ser excelente técnicamente, Rick hacía fracasar sus proyectos. No podía trabajar en equipo, prefería trabajar solo, no tenía tiempo para reuniones. Cuando los proyectos comenzaron a retrasarse, él trabajaba día y noche, enojado y sin nunca pedir ayuda de nadie. En una de esas tensas reuniones en las que Rick explicaba por qué estaba retrasado dijo: “Ustedes nunca podrían entender el código que yo hice”. Tenía razón. El problema era que Rick se olvidaba de que cuando escribimos software no lo hacemos sólo para la computadora, sino también para otros humanos. Ser un genio o un “rockstar” no aporta demasiado valor si otros no pueden usar lo que generamos o si nos convertimos en el cuello de botella para la finalización de los proyectos porque todo depende de nosotros. El trabajo de desarrollo es un trabajo colaborativo y no individual. Porque el software, como cualquier creación humana, es mejor cuantas más personas aportan sus perspectivas. Y gracias al mundo del software libre y el código abierto, la cantidad de ojos que podemos tener en nuestro código para hacerlo cada vez mejor adquiere dimensiones globales.
El caso de Rick es sólo un ejemplo de cómo muchas veces los proyectos de software fracasan por motivos de comunicación entre humanos, más que por asuntos técnicos.
Otro escenario donde se manifiestan estos problemas de comunicación suele ser la toma de requerimientos al momento de encarar un proyecto. En esta etapa, hablar con los usuarios del proyecto y entender sus necesidades es fundamental, pero hacer ésto de forma efectiva requiere mucho más que implementar tal cual lo que el usuario pide. Aparentemente Henry Ford una vez dijo “Si hubiera preguntado a mis clientes qué es lo que necesitaban, me hubieran dicho que un caballo más rápido”.
Un tercer punto super importante tiene que ver con la comunicación de nuestras creaciones. ¿De qué sirve haber hecho el producto perfecto si nadie sabe que existe?
Y por nombrar un ejemplo más, durante el desarrollo de un proyecto tiene muchísimo valor que el equipo exponga a tiempo cualquier incipiente foco de conflicto o desviación en las estimaciones de tiempo de trabajo ya que estos hacen al éxito del proyecto.
Pese a todo esto, muchas de las búsquedas de programadores y programadoras piden un (siempre un) Jedi Master, Samurai, Ninja o Rockstar Developer y hacen mucho énfasis en los requerimientos técnicos requeridos para el puesto. No se trata solamente de la manera de especificar cómo se nombra el puesto ni en la pieza comunicacional que se utiliza, sino que realmente se cree que un buen programador es alguien que resuelve sólo los problemas, que no se requiere que sea bueno trabajando en equipo, ni sea bueno comunicándose. En mi opinión, además del conocimiento técnico que por supuesto es super importante, un buen profesional es bueno trabajando en equipo, es bueno escuchando, dando y recibiendo feedback, participa aprendiendo y compartiendo lo aprendido en comunidades de desarrolladores y conferencias.
Más que un individuo brillante, estrella, ninja, lo que deberíamos buscar armar es un equipo que trabaje bien en conjunto, aprendiendo y potenciándose mutuamente.
De más está decir que esto que cuento de los equipos de desarrollo es completamente extrapolable a cualquier área, cada vez es menos importante la individualidad y la apuesta es a lo comunitario.
Carolina Hadad es programadora y co-fundadora de Chicas en Tecnología
