Hace poco me contaba un directivo de una empresa de tecnología española, muy conocida por sus proyectos de defensa, seguridad… que contrata cientos de desarrolladores para sus proyectos cada año, que hace poco contrató un “experto” devops que le acabó causando un perjuicio de más de 300.000 euros en menos de 1 mes de trabajo.
Otro caso, muy comentado en foros online de desarrolladores de software, representa los riesgos de incorporar la inteligencia artificial sin contar con el personal adecuado. En un equipo del sector bancario, la falta de experiencia para evaluar, supervisar y utilizar correctamente estas herramientas llevó a gastar más de 200.000 euros en menos de una semana.
Por supuesto, tampoco hubo control que lo hubiera limitado: no fue la IA la quefalló, sino la selección de personas sin la preparación necesaria para utilizarla con criterio.
Para no quedarnos en la comedia nacional, donde andamos empeñados en reflotar el género picaresco con buscones glorificados, conviene recordar que estos desastres no son patrimonio exclusivo de España.
Hace poco una empresa de outsourcing europea contrató un equipo de ingenieros de redes para un proyecto internacional. La sorpresa llegó después, cuando se descubrió que ninguno había hecho un solo proyecto de ese tipo en su vida… y tras abandonar el proyecto sin finalizar con retraso, y de forma apresurada, la empresa tuvo que desembolsar tres millones de euros en rehacer el proyecto y pagar las indemnizaciones correspondientes.
¿Estos son casos aislados? No, en absoluto, y lo peor es que esto hace 20 años era anecdótico.. y hoy es lamentablemente “lo normal”.
¿Es el desarrollador de software culpable del fracaso del proyecto?
Todos sabemos que el talento es una cualidad escasa; pero seguimos llamando talento a cualquiera que dice que sabe hacer eso que necesitamos para facturar. Por tanto, si siempre conseguimos Talento…no puede ser tan escaso… ¿verdad? o a lo mejor es que el Talento está realmente en ese comercial que consigue vender arena en el desierto, hielo en el Polo y, si se tercia, un proyecto informático a quienes no distinguen un código de programación del menú del bar de la esquina.
Las grandes empresas, entretanto, trabajan como una interminable cadena de montaje donde la responsabilidad pasa de mano en mano ágilmente, como pasa una patata caliente. Nadie parece haber decidido nada, pero todo el mundo ha decidido algo; nadie es culpable, aunque el desastre tenga autores, firmas, sellos y reuniones previas.
Y al final de la cadena queda el profesional, pobre hombre, metido en un proyecto para el que no ha sido preparado, ni formado, ni advertido, pero al que se le exige que obre el milagro y entregue resultados con la puntualidad de un tren (en España no claro).
En informática, además, como todavía se trabaja con una mezcla de ingeniería, artesanía, intuición y superstición, el desastre suele estar servido antes de que el primer programador abra el editor. Al profesional sólo le quedan sus armas: el ingenio para fabricar excusas, disimular, en la medida de lo posible, su ignorancia y su inexperiencia, y escudarse en la falta de apoyo de una organización que lo lanzó al combate con un mapa incompleto y las municiones contadas.
A eso se añaden las arquitecturas innecesariamente complicadas, la documentación que llegó tarde, y ahora, el toque final: el uso incorrecto de lainteligencia artificial, esa herramienta prodigiosa que, manejada sin conocimiento, no resuelve la deuda técnica, sino que la engorda, la perfuma y la deja cuidadosamente escondida bajo otra capa de código.
Por suerte para ese equipo de desarrolladores, no suele haber un responsable con capacidad de revisar el trabajo, ese código tipo espagueti western que ni Clint Eastwood en sus tiempos mozos se acercaría. ¿Queréis hacer la prueba? Preguntadle cuantos MR semanales hace su equipo y el nivel de cobertura de código.
Con esto tenemos la explicación de porqué el 70% de los proyectos de desarrollo de software son un fracaso (cancelación, sobrecoste, retraso e incumplimiento de objetivos clave), según Boston Consulting Group. En otras palabras: Se sobrevende o/y se contrata un equipo destinado al fracaso.
Las evaluaciones son necesarias
Quienes hemos tenido la experiencia de pasar por empresas grandes, startups y microempresas sabemos que en todas se hacen regular las cosas, aunque cada una tenga su manera particular de equivocarse.
En la empresa grande, por ejemplo, se evalúa al candidato de asuntos que poco o nada tienen que ver con el trabajo diario del desarrollo: materias académicas, preguntas de formulario y cuestiones generales que cualquier programador con un mínimo de oficio, paciencia y acceso a una IA puede sacar adelante sin consumir apenas tokens.
En la empresa pequeña, en cambio (la startup, la microempresa en esa oficina/”piso patera” que tu tia “MariCarmen” te prestó para que arrancaras con dos amigos y una fe desmedida en el futuro) más que seleccionar se vende la empresa.
Ya es bastante milagro que alguien manifieste su deseo de trabajar allí, entre la incertidumbre, los cafés de marca sin filiar y la promesa de unas opciones sobre acciones que, quizá, algún día valgan algo. Y si, además, el candidato acepta el sueldo y lleva camiseta negra, queda demostrado que es un auténtico fenómeno, un crack, quizá incluso un visionario.
Naturalmente, todo lo anterior es una exageración. Pero una exageración que, como suele suceder, retrata con bastante fidelidad la mayoría de las ocasiones.
¿Qué debe incluir una prueba técnica para desarrolladores?
Quien ya se ha decidido a contratar un equipo para su proyecto, debe empezar por estimar las magnitudes principales: tiempo, sistemas, presupuesto, integraciones.. y si es un prototipo, un PMV o producto “escalar”. Con esto, un experto podrá identificar los roles y habilidades que cada miembro del equipo de desarrollo va a necesitar para hacer viable el proyecto.
Buscando un caso de éxito, modelo a seguir, podemos volver la mirada hacia aquellos viajes a las Españas de ultramar que cruzaban el Atlántico en el siglo XVI, cuando el riesgo del capital no era muy distinto del que hoy asume unempresario al poner dinero en un proyecto tecnológico de cierta envergadura.
En ambos casos, tanto el aspirante a piloto, como el desarrollador comienzan en un proyecto que deben diseñar hasta el último detalle, con apenas una guía de objetivos, pasaje, y destinos o fechas estimadas. Un armador en el siglo XVI no contrataba a un piloto para dirigir su nave publicando una oferta y filtrando las cartas que recibía.
El puesto de piloto era para una única ruta. Debía venir recomendado por otros pilotos, demostrar haber navegado en dicha ruta y además superar una prueba real que le habilitaba únicamente para pilotar una ruta concreta de la Carrera de Indias.
El candidato debía demostrar que conocía:
- la ruta concreta que pretendía pilotar;
- los vientos y las corrientes;
- las costas, los bajos, los puertos y los fondeaderos;
- el manejo de las cartas y de los instrumentos náuticos;
- los cálculos necesarios para determinar rumbo, posición y distancia;
- y la manera de salir airoso de los problemas que pudieran presentarse durante la travesía.
Lo examinaba un tribunal formado por el piloto mayor, un catedrático de cosmografía y un cosmógrafo fabricante de instrumentos. Y no se entretenían en preguntarle teoría, porque la teoría, como el valor al soldado, se le suponía.
Todo eran casos prácticos sobre los problemas más habituales a los que podría enfrentarse en dicha ruta. Si suspendía, no podía volver a examinarse inmediatamente: debía realizar antes otro viaje a las Indias.
La experiencia, en aquellos tiempos, no era una palabra decorativa del currículo, sino una obligación que se pagaba con meses de navegación, hambre, tormentas y la incertidumbre de no saber con exactitud qué había al otro lado del horizonte.
Más o menos a lo que se enfrenta un equipo de desarrollo cuando entra un nuevo proyecto. Aquí hambre no, pero fines de semana sin pegar ojo.. unos cuantos.
Volvamos ahora a nuestros días, que tampoco son precisamente tranquilos. Yo no pondría un proyecto en manos de profesionales que no me ofreciesen seguridad en la ejecución de las funciones que deberán desempeñar; ni en las de quienes no hayan adquirido, en trabajos anteriores, habilidades frente a dificultades y retos semejantes a los que presenta el proyecto que se les encomienda.
Con el grado de ficción que alcanzan hoy algunos currículos, este documento ha perdido valor, como la moneda fiat. Y como en la inversión debemos buscar un valor menos alterable… Las referencias ayudan, pero no bastan; y lo que el propio candidato cuenta de sí mismo, aunque lo cuente con aplomo y buena dicción, tampoco constituye una garantía.
La única base razonable para saber si un desarrollador es el adecuado consiste en verlo trabajar frente a un reto técnico que contenga alguna de las dificultades con las que habrá de encontrarse en el proyecto real. Incluso conviene que aparezca algún asunto que probablemente desconozca, pues de ese modo podrá observarse no solo lo que sabe, sino también cómo aprende, cómo pregunta, cómo desconfía, cómo descarta una mala solución y cómo encuentra una buena.
Ya no se evalúa su memoria de repetir el código de una algoritmo voraz, sino su criterio para elegir el adecuado, las librerías más propicias para el proyecto, y la integración adecuada con el resto del código del proyecto.
Debe permitir observar cómo utiliza el candidato las herramientas disponibles, incluida la inteligencia artificial; cómo formula los prompts; cómo comprueba las respuestas; qué consejos acepta y cuáles rechaza; cómo detecta un error elegante y peligroso; y qué decisiones toma cuando la máquina ofrece una solución rápida, convincente y equivocada.
Porque la cuestión no es averiguar si el desarrollador sabe pedirle cosas a una IA. La cuestión es saber si conserva el juicio suficiente para no obedecerla cuando la IA se equivoca. Ahí, precisamente ahí, empieza la diferencia entre quien lleva el timón y quien se limita a mirar cómo gira.
