¿Está tu empresa orientada a la creación de talento?

Atraer el talento, retenerlo, aprovecharlo.. las empresas consideran (o deberían) que el talento es su recurso más valioso.

Pero.. además de atraerlo, comprarlo.. ¿lo generas?

Si además te dedicas al sector TIC.. ¿sabrías hacerlo?

Desde un punto de vista empresarial, si una compañía tiene identificado su core business y no lo desarrolla sino que intenta subcontratarlo para simplemente revenderlo como empresa tendrá poco recorrido ya que su propuesta es de poco valor añadido.

Es por esto por lo que por mucho que se le de vueltas (a veces sin sentido) en torno a la gestión del talento, no hay atajos. Si tu empresa no lo genera, le costará atraerlo, retenerlo y capitalizarlo.

Esto es así en cualquier sector, pero, en el sector de la tecnología.. ¿existen recetas para generar talento? ¿Pongo toboganes y máquinas recreativas? ¿me llevo a los chicos de excursión?

Pueden ser iniciativas con un resultado incierto.. pero en todo caso.. sigues intentando gestionar el talento de tus colaboradores (llamarles recursos penaliza.. y lo sabes).

Ante todo hay que ser consciente que generar talento es lo más complicado.. por eso tiene más valor.. y requiere una inversión (se supone que es el core business de tu empresa).

No obstante, se impone una reflexión previa.. ¿qué es para tí el talento?

Una definición para mí acertada es la que expone Jose Antonio Marina en su libro Objetivo: Generar talento:

"Talento es la inteligencia que elige bien las metas,  maneja la información, gestiona las emociones y pone en práctica las virtudes de la acción necesarias para alcanzarlas, ampliar su capacidad de acción y conseguir una mejora continua. Es un concepto valorativo. Una acción y no una capacidad. Es el acto de invertir bien la inteligencia."

¿Cómo estructurar tu organización para la utilización eficiente de la inteligencia y orientar la acción a objetivos concretos?

Prospección tecnológica:

Como empresa necesitas conocer con la mayor profundidad posible tu dominio tecnológico y las principales tecnologías que engloba.

Esto supone entender cuales son los aspectos técnicos clave para una implantación exitosa en cada caso y el desarrollo de metodología y técnicas de modelado específicas para cada caso.

Algunas de las técnicas útiles para prospección tecnologica son:

• Modelado de escenarios

• Análisis de riesgos

• Prototipado

• Documentación y presentaciones técnicas internas

• Análisis de tendencias tecnológicas y roadmaps de los principales fabricantes

Propagación del conocimiento de forma transversal:

La prospección tecnológica debe estar disponible para los equipos que generan los productos, implantan los proyectos o proporcionan los servicios TIC a tus clientes.

Algunas de las técnicas útiles para la propagación y consolidación del conocimiento son:

• Realizar formaciones internas actualizando los conocimientos de los equipos técnicos

• Obtener feedback sobre las necesidades de conocimiento y best practices obtenidas en proyectos

• Dar soporte tecnológico de alto nivel

• Potenciar a los analistas y arquitectos junior para que adquieran habilidades de negocio y sepan traducir los requerimientos de negocio a la definición de sistema bidireccionalmente.

Técnica + Fuerza + Dirección.. Merece la pena probar, ¿no?

Arquitectura emergente o caos encubierto

En un post reciente Tony 'Bulldozer' se pregunta si el paradigma ágil realmente es aplicable en sistemas complejos

https://bulldozer00.com/2016/06/02/is-there-really-such-a-thing/

En mi opinión, teóricamente si, pero es cierto que en la práctica la mayoría de los proyectos planteados iterativamente van perdiendo la coherencia y la vinculación entre requisitos / funcionalidades / artefactos / etc.

Creo que  es un problema de base la generalización del mito que si hacemos un proyecto con "Scrum" o "Kanban" o lo que sea, no es necesario documentación técnica, ni especificaciones precisas, etc.

La cuestión es que si una vez realizadas 2 o 3 iteraciones la gestión se lleva al nivel de micro-tareas se pierde la visión global y poco a poco la supuesta ventaja de un sistema ágil deja de serlo.. ya que al perderse de vista la visión de conjunto el conocimiento se disgrega y cada desarrollador empieza a tomar decisiones arquitectónicas sobre la marcha y hasta se pierden las prácticas estándar de desarrollo 

Esto tiene además el agravante de que en cada sprint no se incluyen tareas no funcionales para esta consolidación del diseño y la implementación , la típica respuesta al programador de "es que no hay horas" cuando reclama tiempo para arreglar algo, con lo que al final tenemos un sistema monolítico, mal diseñado y prematuramente en crisis.. ante lo cual se plantea si evolucionarlo o refactorizarlo

Hay que insistir en que un sistema ágil no es un sistema low cost, de hecho tiene que tener un nivel de calidad superior para ser ágil en la entrega y sostenible en el tiempo

Esto podría considerarse pecados graves en un arquitecto 

Pero, fundamentalmente el problema está en que el mito del desarrollo ágil en el que la arquitectura se hace sola y el diseño se hace entre todos, la figura de la arquitectura y del arquitecto se obvia.

Si el sistema es complejo y/o lleva acumulada mucha inversión en tiempo y recursos, no es fácil su reencauzamiento, sobre todo porque el origen del problema no es técnico sino de tener la suficiente cultura y organización para la realización efectiva de proyectos.

Cuando la carencia de la arquitectura es patente y que el mito de la arquitectura emergente que surge sin una organización y una dedicación se desmorona, suele cometerse un nuevo error:

La misión consiste en contratar los servicios de un arquitecto, "el gurú", para lo cual se define una job description que más que un trabajo es una wish list.

El arquitecto debe hacer de interlocutor con usuarios, prospectar todas las tecnologías, definir y actualizar las arquitecturas, metodologías, realizar las auditorías de calidad y además formar a los desarrolladores y solucionar incidencias fantasma.

Vamos de mito en mito.. tan sólo por enumerar tus deseos no es suficiente para hacer que se hagan realidad.

Como comentaba en la entrada anterior, un arquitecto puede tener muchos roles, pero es una figura transversal que necesita del resto de la organización para poder realizar sus funciones.