Históricamente, las empresas se han manejado bajo una cadena de comando bastante acotada. Esto proviene de varias escuelas de administración tales como la de Taylor, que buscaban que el operario fuera controlado para extraer su máximo rendimiento. Con el pasar del tiempo, este tipo de metodología estructurada de trabajo demostró ser muy útil en áreas de producción, como fábricas o, posteriormente, cadenas de comida rápida ya que las tareas a realizar son sumamente mecánicas.

Pero los tiempos han cambiado y ahora son mucho más dinámicos. Gran parte de las tareas que se requieren realizar ya no son mecánicas, sino que son más bien de índole creativa. Dentro de estas tareas, obviamente se encuentran el diseño y la programación. Si bien esta última tiene fama de ser muy estructurada, la realidad es que demanda mucha creatividad e interrelación de conocimientos para realizar algo que funcione, respete los estándares y las buenas prácticas, funcione correctamente y sea seguro, mantenible, reutilizable y escalable.

Por eso mismo, en áreas de la programación se inventó la metodología Agile, que busca justamente romper con este paradigma del jefe que funciona como la cabeza y los operarios que vendrían a ser sus manos.

La metodología Agile

El paradigma de Agile parte de una premisa: los equipos deben ser autodirigidos, no existe una figura de jefe controlador, sino que el jefe es el mismo equipo en conjunto. Después de todo, diez cabezas piensan mejor que una. Agile también plantea otro cambio fundamental: dejar de utilizar etiquetas de puestos como si fueran una línea de ensamblaje para comenzar a utilizar solamente tres figuras: el developer team, el Scrum Master y el Product Owner. Si uno analiza esto, puede fácilmente notar que en las metodologías tradicionales cada uno tenía una tarea específica de la cual no podía desviarse: la entrada de uno era la salida del otro. Dentro del marco de Agile, en cambio, hoy por hoy es muy usual que el developer team asuma el 100% de las responsabilidades de todos aquellos roles antes mencionados. Y ¿cómo es que llegamos a lograr este cambio? La respuesta está en un concepto que se conoce como T-Shape.

T-Shape

Al concepto T-Shape lo acuñó allá por el 2009 Tim Brown. Se usa mucho en la agilidad y hace referencia a que cada miembro de equipo debe ser capaz de tomar distintas tareas, a la par de especializarse en un área.

En el developer team, todos los miembros deben ser capaces de realizar todas las tareas. Hoy, el software engineer o developer tiene más responsabilidades que nunca: debe saber programar, testear, maquetar, cómo organizar el trabajo, evaluar el trabajo de otros compañeros, dar feedback, hablar con el cliente para relevar sus necesidades, documentar, entender el dominio de negocio. El developer team actual ya no es más un operario, es una persona con múltiples roles, que requiere un sinfín de soft y hard skills. Esta es la razón por la que, en muchas empresas, un programador puede ganar más dinero que un jefe de otra empresa, o quizás más que su propio jefe. También es el motivo por el cual hay tanta demanda de personas, pero tan poca oferta para cubrir dicha demanda.

Porque reclutar gente que sepa o quiera aprender todo lo mencionado es difícil. No solamente se complica la tarea de encontrar estos perfiles, sino que, una vez ubicados, es difícil que quieran seguir mejorando o actualizándose constantemente.

Uno puede ver esta realidad como algo negativo, o como una gran oportunidad para aprovechar si se tiene en cuenta que con el solo hecho de ser autodidacta, tener acceso a internet y tener ganas de nunca parar de aprender, se puede llegar más lejos que nunca en la historia.

(*) Yari Taft: SSr. Full Stack developer de intive