Dimensiones de gestión para RRHH del sector IT

¿Cuántas personas necesitamos? ¿De qué perfil? ¿Cuándo necesitamos a cada una? ¿Cuántos tenemos disponibles en la empresa que podrían desempeñar ese mismo papel? ¿Cuánto tiempo vamos a necesitar ese perfil? ¿Hasta qué punto será fácil reubicarlo cuando hayamos terminado con la necesidad actual que necesitamos cubrir?

Éstas y otras muchas son cuestiones que los responsables de RRHH del sector IT se preguntan todos los días… o unas cuantas veces cada día.

Las malas noticias es que parecen muchas cuestiones difíciles de contestar todas al mismo tiempo, y son todas necesarias… pero las buenas noticias es que sí, se pueden contestar, si se tienen en cuenta una serie de “dimensiones”, o hablando con propiedad, una serie de datos que se pueden y deben obtener de la propia operativa diaria del departamento IT.

Cuando decimos “departamento IT” nos referimos a los proyectos y servicios de IT que se proporcionan tanto a clientes externos, como a los que se prestan de forma interna en la propia organización; en definitiva, a toda la capacidad y recursos (humanos) del ámbito TI que sean necesarios.

¿Cuáles son estas dimensiones? Vamos a hacer un recorrido por las mismas… desde “quién está haciendo qué” hasta cuestiones relacionadas con prioridades.

¿Cuánto trabajo llevamos entre manos?

Por ser aparentemente tan obvia, a menudo la respuesta a esta pregunta no está nada clara. Las empresas no dejan de buscar personas para afrontar los contratos y proyectos que están por venir, pero… ¿Y hasta qué punto estamos cubriendo adecuadamente todo lo que ahora mismo tenemos que resolver? Debemos pensar en esa circunstancia tan repetida: la empresa consigue un nuevo contrato, y para cubrir esta necesidad asigna 3, 5 o 10 personas que estaban en otros proyectos o servicios… lo cual, por supuesto que debe hacerse, pero la pregunta es: ¿teníamos sobreasignación de personas en estos otros proyectos vivos? ¿Estamos considerando si el desempeño en esos proyectos puede continuar adecuadamente con menos personas?

Y si no tenemos perfectamente claras estas cuestiones… ¿entonces con qué criterio práctico asignamos y reubicamos profesionales?
En definitiva, siendo “obviamente necesario”, demasiadas veces falta un cuadrante o mapa de recursos asignados a cada contrato (proyecto, servicio…) y hasta qué punto está equilibrado.

¿Sabemos hacer el trabajo?

Muy relacionada con la cuestión anterior… no sólo a nivel global en cada contrato (capacidad suficiente en relación a la contratada o comprometida), pero a nivel detallado ¿esas personas tienen el conocimiento específico y adecuado en relación a lo que están haciendo? Y tenemos tendencia natural a decir “sí, claro que sí, por supuesto…”, pero si así fuera entonces nunca habría que formar a los profesionales porque cualquier tecnología, innovación o novedad se daría por conocida. Es decir, suena a in-creíble (es decir, poco creíble) que podamos tener personas con experiencia y conocimiento para cada una de las tecnologías, herramientas, entornos, frameworks y versiones posibles…

Moraleja: la respuesta a esta pregunta debería ser el contenido de algún plan de formación o actualización, y no simplemente tener “diseñadores web donde hace falta hacer diseño web”. Si por autocomplacencia nos decimos que “tenemos todo el conocimiento necesario siempre muy bien cubierto”, en seguida llegará el día en el que no sepamos qué hacer en un proyecto actual (ni siquiera un proyecto nuevo). El cambio tecnológico es imparable así que… asumamos que no sabemos todo lo necesario, y que tenemos que retar el status quo de forma permanente.

¿Cuál es el estimado del trabajo pendiente?

Una cosa es lo que está planificado en los contratos y en los pliegos… pero otra es la realidad de los proyectos. Por ejemplo, un pliego escrito hace 1 año, ¿reflejaba realmente la capacidad que ahora es necesaria? Y no sólo en cuanto a cantidad de personas, sino a las capacidades concretas… así que, ¿estamos realmente convencidos de que las personas que hacen falta son realmente las que señalaban en esos documentos, o estamos cotejando esta información con la real, con la que sí resulta cierta (o al menos, más acertada) procedente de las estimaciones de los responsables de proyecto?

Si la estimación no coincide con lo que decía un contrato… ¿no vamos a hacer nada al respecto? Ya no vivimos en aquel mundo el que decíamos que “como lo pone el contrato, eso es lo que hacemos…”, esto ya apenas nos sirve, hoy en día la ejecución de proyectos TI es mucho más dinámica, más cambiante… y esto no es nada “negativo”, al contrario. Permite que las empresas y los profesionales con más y mejor capacidad de aprender y de adaptación sean los que hacen mejor las cosas, tienen a los clientes más satisfechos y afrontan los cambios (de contexto técnico y de otro tipo) mucho mejor que los que simplemente “se remiten a la cláusula 13.4 del contrato de renovación del servicio de….”

Por lo tanto, un plan de capacidad creíble para una empresa no sólo se debe basar en los “supuestos” de pliegos y contratos, sino en las “realidades” más inmediatas que los gestores y los equipos transmiten. Por cierto, para esto es necesario que dichos gestores y equipos tengan la libertad y los medios para transmitir qué necesitan, cuándo, por qué, qué está cambiando, y cuál es la previsión a corto y medio plazo (no tanto a largo plazo porque, como estamos diciendo, ésta resulta cada día menos creíble en el contexto de transformación en el que nos estamos moviendo).

¿Cuál es el incurrido real?

Acabamos de comentar la importancia del estimado real, el que nos dicen los equipos y las personas que están en la ejecución del proyecto o del servicio, esto es necesario sin duda pero… una cosa es estimar, y otra diferente es adivinar; se puede aprender a estimar muy bien con la experiencia pero… una estimación siempre es una “suposición” bien justificada, no una “afirmación” de lo que realmente va a pasar; por mucho que nos esforcemos no podemos aprender a adivinar así que además de estimar tenemos que hacer algo más: comparar el estimado con el incurrido, es decir, comprobar realmente cuánto nos ha costado hacer algo; aquí cada empresa decidirá cómo medirlo: por perfil, por tarea, por coste, por proyecto, por persona… lo que sea necesario para poder saber si lo que estimamos se ha cumplido o no, hasta qué punto se ha cumplido o por qué no se ha cumplido… para poder aprender.

Si no registramos los incurridos, no aprenderemos a estimar mejor porque no sabremos en qué nos equivocamos al estimar; es decir, si ahora hacemos malos planes de capacidad, los seguiremos haciendo igual de mal en el futuro… así que estamos a tiempo de evitarlo: si sabemos qué hemos necesitado para hacer algo, no podremos “adivinar” cuánto necesitamos para hacer lo siguiente, pero sí estaremos un poco más cerca de estimarlo y justificarlo mejor, por lo tanto nuestras previsiones serán más fiables.

Y en segundo lugar: medir el incurrido no sólo sirve para proyectar mejor el futuro próximo, sino para:

• Hacer mejores ofertas para los clientes, porque podemos explicarles si se equivocaron en sus pliegos y por qué; como expertos deberíamos aportarles este valor si somos capaces.
• Tener mucho mejor criterio para saber si debemos presentar una oferta a cierto contrato o no; si el cliente opina que con 100 horas se hace un trabajo, pero nuestras métricas nos dicen que son necesarias 200… no parece que vaya a resultar nada rentable (otra cosa es que queramos hacerlo por cuestiones de negocio).
• Poner a trabajar a las personas de RRHH en lo que realmente soluciona los problemas; si el incurrido dice que en cierto contrato hacen falta 3 ingenieros de datos, y renovamos dicho contrato… pues hay que cubrir ese perfil con 3 personas, tanto si lo dice el pliego del cliente, como si no. Y si no disponemos de esas 3 personas, tenemos al menos un buen criterio para decidir si debemos afrontar dicho trabajo o dejarlo pasar.

Como conclusión, debemos admitir que, si no registramos los incurridos, no hace falta que nos preocupemos de estimar… porque acertar en la estimación se reduciría a una mera cuestión de suerte, así que resulta más barato no hacerla.

La buena noticia es que la tendencia a trabajar con un enfoque ágil en entornos TI es muy clara, esto debe incluir paneles de ejecución del trabajo (tableros kanban y similares), sobre los cuales cualquier herramienta de gestión ágil de proyectos y servicios genera estas métricas de incurridos con enorme detalle: incurridos por estado, petición, tipo de tarea, tiempo de parada, retrabajos, incidencias, entornos, etc…

Atascos, parones… la gran batalla

Vamos a suponer que registramos las estimaciones del trabajo en los diferentes proyectos… bien; vamos a suponer que registramos los incurridos en los diferentes proyectos, ¡bien! Pero… si algo nos está demostrando el contexto de transformación (tanto si queremos ponerle el apellido “digital” como si no) que las lecciones aprendidas nos sirven cada día menos: no basta con aprender de lo que ocurrió ayer, para poder solucionar lo que está por llegar mañana.

No podemos evitar que, a veces, los proyectos se paren, o que los clientes tengan “cuestiones y problemas internos” que nos afectan, o que alguna tercera parte con la que tenemos que trabajar sufra un parón, una ausencia o un problema técnico. Esto quiere decir que escucharemos esa frase tan y tan odiada: “estamos a la espera de…”, porque es un tiempo que consume calendario, que nos retrasa, aunque puede que no nos suponga incurrido (porque mientras estamos “a la espera de…” deberíamos ponernos a hacer otra cosa más útil). Pero la cuestión es que estos tiempos muertos, siendo inevitables, son importantes, porque implican alargar calendarios de asignación de personas a proyectos, al mismo tiempo que provocan “huecos de tiempo” que se pueden utilizar para ayudar en otro proyecto, solventar una incidencia, etc.

De nuevo deberíamos proponer a los proyectos que recurran a los paneles de trabajo para señalar estos atascos y parones: son una forma de “levantar la mano” diciendo “aquí hay una persona disponible momentáneamente, por si podemos aprovechar la circunstancia…” o, si no se puede aprovechar, al menos sabremos analizar el impacto que, por culpa de terceras partes, sufrimos en nuestra utilización de recursos (además de potenciales incumplimientos de fechas de entrega, etc.).

¿Nos importa la prioridad?

Y además de todo lo anterior, que no es poco… ¿y qué pasa cuando no tenemos todas las personas que harían falta para acometer todo el trabajo? Pues que toca priorizar, y aquí el reto es que, para cada cliente, su problema es el más importante del mundo, pero… ¿y para la empresa, puede ser que lo más importante de un contrato, sea considerablemente menos importante que lo que tenemos que desarrollar en otro?

Aquí entramos en la cuestión de escalar estas dimensiones de trabajo a nivel de un departamento completo de TI, el cual debe tener un backlog de trabajo, que como concepto es único, aunque tengamos muchos contratos, proyectos y servicios que cumplir simultáneamente.

En artículos posteriores trataremos este tema en profundidad, es lo que denominamos poner en marcha trenes de trabajo: paralelizar iniciativas a escala departamental, aplicando un grupo de 20, 30 ó 200 personas para resolver múltiples proyectos y servicios de manera simultánea, cumpliendo con los productos mínimos viables, entregas y acuerdos de nivel de servicio de cada uno de ellos, al mismo tiempo que se genera un mínimo desperdicio en el uso de recursos, tiempo y coste.

Moraleja: Agile RRHH

De todo esto, la conclusión es muy clara: no podemos prever, ni controlar, ni detallar exactamente por adelantado, todas las capacidades necesarias en cuanto a Recursos Humanos para cubrir y resolver adecuadamente cada uno de los proyectos en curso, ni sobre todo los que están por venir próximamente.

Y no porque sea imposible hacer esta previsión, porque en los pliegos y ofertas aparecen perfiles de profesionales, conocimientos y experiencias necesarias, tecnologías cubiertas… pero siempre hay más información que no conocemos, que aparece más tarde; siempre hay evolución tecnológica (tanto por parte de los clientes como por nuestras propias propuestas), así que la adaptación es un eje central alrededor de esta incertidumbre.

Si nos planteamos las preguntas expuestas en este artículo, será más fácil asumir que esta incertidumbre es “invencible”, es decir, por mucho esfuerzo que pongamos desde el departamento de recursos humanos, nunca vamos a disponer de una planificación detallada por adelantada tal que, si conseguimos seguirla y cumplirla, nunca tendremos carencias o problemas… ojalá se pudiera conformar ese plan detallado; en lugar de desgastarnos en ese esfuerzo, tomemos más métricas del trabajo en curso, estimados e incurridos, atascos, prioridades… que nos ayudarán a tomar decisiones pequeñas pero continuadas para asignar las personas adecuadas a cada contrato y a cada proyecto.