A la caza de fantasmas: cómo ver la contribución real de los desarrolladores

Los «ghost engineers» —desarrolladores fantasma—: uno de cada diez desarrolladores apenas hace trabajo útil y se limita a representar de forma convincente el papel de alguien muy ocupado. Los motivos reales de esa inactividad —otros trabajos en paralelo, el agotamiento o la simple holgazanería— pueden permanecer ocultos para la dirección durante mucho tiempo. (Estudio de Stanford de 2024: hilo original)

A los desarrolladores no les gusta que se hable de su rendimiento. Tras una larga «edad de oro» para la profesión, la industria convirtió en tabú una pregunta muy sencilla: ¿el resultado del trabajo de ingeniería justifica el tiempo y el dinero invertidos? Pero los desarrolladores fantasma también frustran a sus compañeros y, por lo general, es el equipo —no la dirección— quien primero detecta el problema.

Aquí, en Rusia, «chivarse» siempre ha estado mal visto. Así que puede haber mucha gente al tanto del problema sin que nadie quiera decir nada. ¿Para qué meterse en líos ajenos? Todo termina saliendo a la luz cuando la paciencia de todos ya se ha agotado.

Aunque quizá deberíamos dejarlos en paz, a esos fantasmas. Total, no será porque a la empresa le haga falta el dinero.

Pero ahí está el problema…

Cuando hablo de bajo rendimiento, no me refiero a que Álex trabaje a destajo y aun así haga un 10 % menos que Ben. Me refiero a otra cosa: en cada reunión diaria, todo el equipo tiene que escuchar una nueva historia lacrimógena —el otro equipo le falló, el ticket estaba poco claro, los astros no se alinearon—. Pero mañana la tarea estará terminada, seguro. Palabra de honor.

Solo que ese «mañana» ya fue ayer y anteayer, y a estas alturas se ha convertido en tradición.

Los equipos perciben estas cosas enseguida. Quienes de verdad cargan con el trabajo empiezan, como es lógico, a preguntarse: ¿para qué dejarse la piel si basta con contar cuentos y no pasa nada?

Sin embargo, detectar el problema no es suficiente. Sin cifras ni hechos sobre la mesa, la conversación se convierte enseguida en una disputa: el equipo dice «rinde poco» y el desarrollador responde «no me dejan trabajar». Lo habitual es que nadie empiece a investigar hasta que la paciencia se ha terminado y el equipo pide al responsable que sustituya a esa persona.

Es entonces cuando comienza la larga odisea: reunir los hechos, escuchar a las dos partes, dar feedback y conceder tiempo para que la situación mejore. Según mi experiencia, casi siempre acaba con el fantasma rumbo a una nueva empresa, muy afortunada ella.

El problema no es solo que una persona haga menos. La empresa paga dos veces: primero, por un trabajo que nunca llega a hacerse; después, por el tiempo que compañeros y responsables dedican a comprobar, cubrir los huecos y averiguar qué ocurre. Al final, ya no es un solo desarrollador quien rinde por debajo de lo esperado. Es todo el equipo.

¿Puede un responsable detectar el problema antes, ver la anomalía, pedir contexto e investigar antes de que el equipo pierda la paciencia y la empresa pierda tiempo y dinero?

Con suficiente experiencia, estas situaciones suelen reconocerse de antemano por algunos patrones de conducta característicos:

• Todos los éxitos son míos; todos los fracasos son culpa tuya.
• Excusas por el fracaso de una tarea antes incluso de empezar a trabajar en ella.
• La falta de competencia se compensa hablando de más.
• Con el tiempo, el responsable en particular pasa a ser «el culpable».
• A diferencia de alguien que de verdad atraviesa dificultades, esta conducta no mejora ni siquiera después de recibir feedback directo.

Pero toda sospecha necesita un rastro digital.

Veamos las herramientas más habituales para medir el rendimiento en ingeniería y si pueden ayudarnos a encontrar fantasmas.

Antes de compararlas, debo señalar el evidente conflicto de intereses: estás leyendo el blog oficial de DevGhost y yo soy el fundador del producto. Esta es la perspectiva de su autor, no un estudio independiente.

Para evaluar la ingeniería de software en sí —no el negocio ni el producto en su conjunto—, utilizo una tríada sencilla: velocidad, calidad y volumen. Las métricas DORA nos hablan de velocidad; las pruebas y los defectos, de calidad. El volumen es más difícil. Es el terreno menos explorado y también el lugar donde suelen esconderse los fantasmas que buscamos.

DORA: velocidad y fiabilidad de las entregas

DORA muestra con qué rapidez y fiabilidad lleva un equipo sus cambios a producción. El modelo utiliza cinco métricas: tiempo desde el commit hasta producción, frecuencia de despliegue, porcentaje de despliegues que provocan fallos, tiempo de recuperación y proporción de retrabajo no planificado.

Es una buena medida del proceso de entrega, pero no de la contribución individual. Si una persona hace el trabajo de tres mientras otra se esconde detrás del resultado global del equipo, DORA no te lo dirá.

Además, estas métricas resultan tremendamente cómodas como KPI. En una empresa en la que trabajé, llevábamos exprimiéndolas desde 2018: todos los paneles acababan convenientemente en verde y todo el mundo se quedaba contento. El modelo DORA actual.

Pruebas y defectos: cómo de bien se hizo el trabajo

Los métodos están bien asentados y funcionan en la práctica. La calidad se controla mediante revisiones de código, pruebas y análisis estático; las consecuencias se siguen a través de defectos e incidentes.

Pero estas señales no dicen nada del volumen. Un parche minúsculo e impecable pondrá todos los indicadores en verde, y el fantasma seguirá siendo invisible.

Jira y story points: cuántos tickets se cerraron

Jira muestra los tickets cerrados y los story points, pero las estimaciones las hace el propio equipo. Un mismo trabajo puede valorarse en tres puntos o en trece, dividirse en cinco tickets o agruparse en uno.

Los story points son útiles para planificar, pero poco fiables como medida de la contribución individual. En cuanto los puntos se convierten en el objetivo, la gente empieza a optimizar para conseguir puntos.

También son KPI muy cómodos. Se introducen datos y se mueven tickets solo para pasar los controles de calidad. Muchísimo trabajo manual sin ningún valor.

Commits y líneas de código: hechos sin contexto

Git no depende de las estimaciones del equipo, así que resulta tentador contar commits y líneas. Pero cinco commits pueden corresponder a un parche diminuto, mientras que un único squash commit puede representar una semana de trabajo.

El formateo, el código generado, las copias y los movimientos de código inflan el recuento de líneas, mientras que una corrección difícil puede ocupar apenas diez.

Swarmia, LinearB y Waydev: todo el sistema de ingeniería en un solo lugar

Swarmia, LinearB y Waydev reúnen Git, los gestores de tareas y CI/CD. Los responsables pueden ver métricas DORA, colas de revisión, tiempos de entrega de cambios y resultados de encuestas.

Ofrecen una imagen útil del sistema de ingeniería y, a menudo, revelan que el problema está en el proceso y no en una persona. Sin embargo, medir en una escala comparable el volumen de trabajo de cada desarrollador no es la pregunta central que intentan responder estas plataformas. Swarmia, LinearB, Waydev.

GitClear: lo que queda después del ruido del código

GitClear distingue entre código añadido, movido y copiado, excluye los archivos generados y tiene en cuenta si el código nuevo se reescribió o eliminó más adelante.

Así obtiene Diff Delta, la unidad propia de GitClear para medir los cambios relevantes que permanecen en el código base. El código copiado o descartado poco después pesa menos que un cambio compacto que sigue funcionando en producción. Cómo funciona Diff Delta.

Diff Delta no responde a la pregunta de cuánto trabajo hizo falta. Responde cuánto cambio relevante quedó después del ruido y el retrabajo. GitClear destaca al medir la durabilidad y la calidad del código, así como al analizar el impacto de la IA.

Ya nos vamos acercando. El servicio publica benchmarks, pero Diff Delta sigue siendo una unidad propia: una cifra como 10.000 dice poco sin la comparación adecuada y sin entender la metodología. No existe una referencia clara del tipo «el 100 % es lo normal». Benchmarks de Diff Delta.

BlueOptima: la misma pregunta a escala empresarial

Conozco BlueOptima de primera mano. Empecé a trabajar con la plataforma en 2019. Aquella experiencia fue la que me inspiró a crear mi propio producto.

El algoritmo Coding Effort analiza cada cambio en el código fuente mediante un conjunto de métricas estáticas, teniendo en cuenta su tamaño, complejidad y relación con el resto del código. Después expresa el resultado en horas.

Esto permite comparar desarrolladores de distintos equipos y stacks tecnológicos, también frente a un benchmark global. Para mí, fue el primer intento convincente de responder no «¿cuántas líneas escribió este desarrollador?», sino «¿cuánto trabajo sustancial representan estos cambios?». Metodología de BlueOptima, benchmark global.

En mi caso, acceder a esas capacidades empresariales exigió un despliegue bastante pesado: hubo que instalar un agente dentro de un entorno de red cerrado, el precio era elevado y los resultados requerían interpretación experta.

Para una empresa con miles de desarrolladores puede estar justificado. Para una startup o un equipo pequeño, probablemente no. Ese vacío fue más tarde una de las razones por las que nació DevGhost.

La misma vara de medir, sin licitaciones

Cuando creé DevGhost, no quería construir otra plataforma todo en uno repleta de todas las métricas de ingeniería imaginables.

Quería la misma respuesta que ofrecía BlueOptima —cuánto trabajo sustancial hay detrás de los cambios—, pero en una forma que el dueño de una startup o un equipo pequeño pudiera utilizar sin una licitación, un despliegue interminable ni un equipo de consultores.

La lógica es sencilla: DevGhost analiza los propios cambios —qué se añadió, eliminó y reestructuró, y lo difícil que fue crear y verificar el resultado—. El formateo, los movimientos de código, las sustituciones automáticas masivas y el código generado se separan del trabajo sustancial.

El resultado es una estimación del esfuerzo expresada en horas equivalentes: cuánto tardaría un desarrollador de nivel intermedio, familiarizado con el código base y trabajando sin IA, en escribir el mismo código. No es el tiempo real pasado frente al teclado, ni una valoración de la calidad o del valor de negocio del código. Es una vara común para comparar cambios. Más información sobre la metodología de DevGhost.

Ghost% compara esa estimación con el resultado esperado de un desarrollador de nivel intermedio, teniendo en cuenta qué parte de su tiempo dedica realmente al desarrollo. Un resultado del 100 % significa que se ajusta a la norma. Un valor inferior es un motivo para investigar; uno superior merece ser estudiado y quizá convertido en una buena práctica.

El benchmark presupone deliberadamente un trabajo sin IA. DevGhost no intenta determinar quién escribió un fragmento concreto de código: una persona, Copilot o un agente autónomo. Evalúa los cambios finales: cuánto esfuerzo habría necesitado un desarrollador de nivel intermedio para crearlos y verificarlos sin IA.

Eso significa que el efecto de la IA no desaparece dentro de la métrica, sino que se vuelve visible. Si durante un periodo un desarrollador crea y verifica un trabajo que antes habría exigido dos o tres veces más esfuerzo, Ghost% lo refleja. El formateo, la generación masiva y otras formas de ruido en el código no deberían producir el mismo efecto.

¿Y quién evalúa al evaluador?

La pregunta más obvia es: ¿por qué debería alguien confiar en una estimación generada por una máquina? La respuesta corta es que nadie debería confiar ciegamente en ella.

Valorar la dificultad de un trabajo es subjetivo por definición. Lo comprobamos pidiendo a varios desarrolladores experimentados que estimaran los mismos cambios, y obtuvimos cifras sensiblemente distintas. Cada persona tiene su ritmo, su experiencia y su propia idea de lo que es difícil.

DevGhost también puede equivocarse. Su ventaja no consiste en acceder a una verdad absoluta. Consiste en que todos los cambios se valoran con la misma vara, sin favoritismos, cansancio ni una opinión previa sobre su autor.

Por eso Ghost% es una señal, no un veredicto. Un resultado bajo puede indicar una contribución débil, pero también explicarse por las responsabilidades de un líder de equipo, el trabajo de arquitectura, la mentoría, los incidentes o los bloqueos.

La cifra indica dónde conviene hacer una pregunta. El responsable aún debe encontrar la respuesta, pero ahora cuenta con una segunda opinión independiente en lugar de depender solo de su intuición.

«Ya sé cómo trabaja cada persona de mi equipo»

Uno de los clientes de DevGhost dirige el área técnica de una empresa de IA que crece rápidamente. Al principio era escéptico ante la propia idea de medir el rendimiento en ingeniería. Su postura era sencilla: un buen responsable técnico ya sabe cómo trabaja cada persona sin necesidad de un panel.

Analizamos el historial de un repositorio que conocía bien. Ya existían dudas sobre tres desarrolladores: sus tickets avanzaban despacio, pero trabajaban en un servicio separado, por lo que era difícil compararlos con el resto del equipo. DevGhost mostró resultados bajos y constantes para los tres durante unos seis meses.

Más adelante, cuando los desarrolladores empezaron a marcharse, salió a la luz que durante todo ese tiempo también habían estado creando sus propios productos. DevGhost no podía conocer el motivo. Se limitó a sacar a la superficie algo que el número de commits, los pull requests y las conversaciones diarias en Slack no habían mostrado: su volumen de trabajo era notablemente inferior a lo esperado.

Pero el análisis no se convirtió en una lista de despidos. Para otros dos desarrolladores, un resultado bajo permitió dar feedback concreto, investigar las causas y mejorar el rendimiento. Ambos siguieron en el equipo.

Los desarrolladores que él consideraba buenos también aparecieron exactamente donde esperaba. Y ahora podía ver no solo quién superaba las expectativas, sino con qué constancia lo hacía.

Un solo caso, por supuesto, no demuestra que el método sea preciso. Lo que sorprendió al cliente fue lo mucho que coincidía la imagen global con aquello que hasta entonces solo se sabía por intuición y que, en algunos casos, no resultó evidente hasta mirarlo en retrospectiva.

¿Y si un desarrollador entrega tanto como tres?

Cazar fantasmas es la parte más llamativa de esta historia. Pero el extremo superior del gráfico puede resultar aún más útil.

Si un desarrollador obtiene de forma constante un resultado varias veces superior a la media, conviene averiguar exactamente cómo lo consigue.

Hoy la pregunta ya no es si un desarrollador utiliza IA —para muchos se ha convertido en una parte normal del trabajo—. La pregunta es con qué eficacia convierte los agentes en capacidad adicional de entrega.

Una persona se queda en el autocompletado. Otra sabe proporcionar a los agentes el contexto adecuado, definir reglas claras, llevar varias tareas en paralelo y revisar el resultado con cuidado. Por eso, el mismo acceso a la IA puede generar aumentos de productividad radicalmente distintos.

Un Ghost% alto ayuda a identificar a los desarrolladores que ya están obteniendo buenos resultados de esa combinación entre persona y agente, y a entender qué prácticas podría adoptar el resto del equipo.

Si el resultado alto está respaldado por la calidad del trabajo y la valoración de su responsable, ese desarrollador merece reconocimiento, conviene retenerlo y debería ser considerado para un ascenso. Sus prácticas deben estudiarse y extenderse al resto del equipo.

No conviertas la vara de medir en un arma

Todas las métricas corren la misma suerte: tarde o temprano, alguien intenta convertirlas en un KPI. Ghost% no sirve para eso.

Convierte Ghost% en un KPI de equipo y la gente empezará a adaptar su trabajo a la métrica. Publica una clasificación y desaparecerá la confianza. Convierte la puntuación en un botón de despido y los errores serán inevitables.

Yo establecería cuatro reglas:

• No saques conclusiones de una sola medición ni de un periodo breve.
• Ten en cuenta el rol de la persona, la parte de su tiempo dedicada al desarrollo y el trabajo que sucede fuera del código.
• Muestra el resultado al desarrollador y dale la oportunidad de explicar el contexto.
• No utilices Ghost% como único fundamento para una decisión de personal.

Si un resultado bajo persiste, el responsable debe investigar primero las causas. Tal vez la persona tenga dificultades reales para rendir. O quizá esté trabajando en arquitectura, resolviendo incidentes de otros o bloqueada por los procesos del equipo.

Si el problema se confirma, debe haber un plan de mejora concreto y una nueva evaluación después del periodo acordado.

Rechazar las métricas no elimina la evaluación de las personas. Solo deja sensaciones, historias contadas en las reuniones diarias y las preferencias personales del responsable.

Velocidad, calidad y volumen requieren herramientas distintas. DORA muestra cómo llegan los cambios a producción. Las pruebas y los defectos muestran la calidad. DevGhost añade una estimación del trabajo que hay detrás de los cambios en el código.

Ninguna de estas métricas debería tomar decisiones por el responsable.

El valor de una cifra no está en dictar sentencia. Está en hacer que una conversación difícil empiece antes y se apoye en hechos.

¿Cómo evalúas el volumen de trabajo de los desarrolladores y dónde trazas la frontera entre una transparencia útil y la vigilancia?