Frecuentemente sale en las conversaciones en las que participo con colegas del ámbito académico y profesional, el asunto de la experiencia laboral. Es un tema sobre el que hay muchas percepciones pero que, creo, todos comparten o perciben su importancia (especialmente aquellos que han aplicado por un empleo asalariado).

Antes, creo que vale la pena hacer algunas acotaciones. Primero, ¿qué debemos entender por experiencia laboral? El concepto de experiencia laboral debe verse y entenderse como un conjunto de conocimientos, aptitudes, criterios y razonamientos que un individuo ha adquirido a partir de realizar alguna actividad laboral en un transcurso de tiempo determinado. El aprendizaje y madurez (adquiridos y alcanzados) son considerados elementos de diferenciación (elementos de valor para el individuo) que serán primeramente considerados antes de cualquier capacitación o grado académico (y quizás en ese orden), cuando existan varios candidatos aplicando por una vacante.

El conocimiento práctico (habilidad— forma de aplicar algo de forma rápida y eficiente —,  uso de la tecnología— el conocimiento de las herramientas y técnicas para hacer uso o permitir hacer el uso de algo o aplicarlo—, y la práctica— el tiempo de hacerlo) son elementos altamente valorados y decisivos para aplicar por un puesto. El grado académico no basta (de hecho es lo último que se toma en cuenta), como tampoco la capacitación al respecto (cursos de actualización o certificaciones), pese a que ambas (y especialmente la  primera) son elementos clave de preparación profesional.

Así, la práctica común es medir la experiencia laboral en años que una persona ha dedicado a alguna actividad específica. En términos cualitativos se consideran los tipos y diversidad de trabajo que ella haya realizado. No hay una regla en esto último. Para un empleador, empleos de diversa naturaleza pueden ser vistos como signos de inestabilidad mientras que para otro pueden ser elementos enriquecedores en términos de multidisciplinariedad.

En un segundo término, y como rezan los encabezados de estas entradas en el blog, éstas son reflexiones y opiniones a título personal. Tercero, no soy alguien cuya única experiencia está en el terrenos académico, tengo ya tres décadas de experiencia profesional, en más de una decena de empleos que han ido desde la función pública, hasta la investigación en la informática médica computacional, pasando por la industria de la construcción, retail, ingeniería aeronáutica y administración de transporte aéreo; cátedra en programas de maestría; comercio electrónico, banca, finanzas y el mercado bursátil; consultoría en ciencia de datos y procesamiento de lenguaje natural; y administración de sistemas para la TV por cable. En todos ellos desempeñando actividades de la función informática. Así que… creo que este es un tema sobre el que puedo dar una opinión basada en experiencias y conocimientos de primera mano, y sobre el que puedo hacerlo tanto desde el punto de vista académico y como el profesional.

Muchos, si no la mayoría de los proyectos de software comercialmente útiles, son ejercicios de integración. La mayoría de los trabajos implican mantener el software existente, por lo que la mayoría de los programadores construyen repetidamente proyectos de software tratando de mejorar lo que funcionó y evitando lo que no, pero el adquirir práctica para crear nuevo software de alta calidad para que otros puedan trabajar es algo que llega con calma.

Adicionalmente, la mayoría de los trabajos que crean software realmente nuevo no involucran a la totalidad del personal. No es raro ver que esta oportunidad se desperdicia y que encontramos a diferentes personas repitiendo los mismos errores. La escasez de nuevos desarrollos, el crecimiento exponencial de empleos, y la migración a roles que no son de desarrollo, limitan el número de mentores potenciales y la adquisición de experiencia.

La mayoría de los puestos de trabajo que tienen líderes de ingeniería o desarrollo (hablamos de software o labores informáticas), llegaron allí al pasar un tiempo relativamente largo en alguna empresa, y fueron mudándose a labores administrativas por escalamiento de puestos y mejores ingresos. Estos líderes hacen que el proceso de creación de software sea menos probable (exitoso) que aquellos en donde los líderes son activos aún en el desarrollo de productos de software o en actividades técnicas. Mi argumentación se sustenta en el hecho de que los administradores son finalmente políticos en un ecosistema cerrado (la empresa), donde se centran en mantener sus feudos y cotos de poder, llegando a creer que el actuar decretando objetivos y fechas de acuerdo a sus propias agendas y experiencia es tanto lo correcto como lo adecuado.  Pero las actividades informáticas de hoy en día ya no son las mismas (salvo que la empresa, su mercado, clientes y entorno no cambien en la tecnología que emplean, lo cual es difícil hoy en día).

Así que administrar en la misma forma en la que el actual gerente o líder de proyecto fue administrado alguna vez, es una mala idea. Primero porque la tecnología y métodos de trabajo para su empleo y administración no serán los mismos y, segundo, no se puede administrar lo que se desconoce.