La programación no es una commodity

4

Lo he dicho muchas veces. Muchas, muchas veces. Y no me cansaré de repetirlo. Pero a lo mejor, hoy lo diré de forma más directa y usando el lenguaje que los directivos de empresas suelen usar: “La programación no es una commodity”.

¿Qué es una commodity?

Si ya sabes lo que es una commodity, te puedes saltar este punto tranquilamente.

Commodity es una de esas palabras que cuando la traduces al castellano pierde su esencia. No tenemos un termino exacto para commodity. Así que me permitiréis usarlo en inglés.

Traduciendo al castellano la wikipedia:

En economía, una commodity es un bien o un servicio que [..] el mercado trata como equivalentes o muy similares sin preocuparse de quién los ha producido.

Por ejemplo una commodity en nuestro entorno sería la gasolina. Nos da igual la gasolina de un sitio o de otro. Si escogemos una gasolinera será por precio, por servicio, pero es raro que sea por “la calidad de la gasolina”. Típicos commodities en economía son el petróleo, la electricidad, los minerales, el azúcar o el trigo.

Como veis es típico de materias primas, pero hay otros elementos que se “commoditizan” y esto sucede cuando la oferta en el mercado ofrece pocas diferencias de un producto a otro. Ejemplos de estos productos: los medicamentos genéricos o los chips de DRAM.

El trabajo como commodity

Hay muchos entornos en los que la directiva de una empresa considera determinado trabajo como una commodity. Es decir, no importa la persona que haga el trabajo, tiene el mismo valor. Pensar así lleva a situaciones en las que no importa si alguien se va, porque siempre puedo contratar a otro que haga lo mismo, igual de bien.

Esto no es algo nuevo, de hecho la Organización Internacional del trabajo en su declaración de objetivos ya plantea este tema directamente. Hablamos de un documento de 1944 en el que en su primer punto indica los principios de la organización, y el primero de ellos es:

Labour is not a commodity

Pero por muy buenas intenciones que se tengan, la realidad es que hay muchos directivos que consideran que el trabajo que se entrega en determinadas áreas es una commodity. El motivo de esto es claro: la percepción de dirección de que ese trabajo lo hace igual cualquier otra persona con la formación mínima adecuada. ¿Es eso cierto? No lo sé. Pero tratar a personas como recursos olvidando que son personas, es algo simplemente inmoral.

Ahora vamos con TI

Vamos al meollo y a lo que quería realmente comentar. Creo que existen directivos que consideran que el trabajo del personal de TI es una commodity. No importa quien lo haga, el resultado es el mismo. Hablo de programadores en el título, pero lo puedo extender a admins, a soporte, a gestores, a cualquier rol dentro de TI.

Lo peor es que no es que haya algunos, es que son muchos. No todos, por supuesto. Hay grandes y notables excepciones. Pero eso no quita que sean mayoría los que todavía no se han dado cuenta que están muy equivocados al pensar así.

Los motivos

¿Por qué nos pasa esto? Creo que el motivo principal es que muchas empresas que descansan su negocio sobre TI no se han dado cuenta de lo importante que es TI. Cada vez más TI se convierte en un hecho diferenciador de la empresa y cada vez más TI forma más y más parte del core business de la organización. Es la realidad de la transformación digital. Pero los directivos vienen de negocio y muchos de ellos no ven mucha diferencia entre desarrollar una nueva funcionalidad en una aplicación o comprar un camión nuevo para el transporte. Son inversiones.

Si yo tengo 10 camiones y la empresa de enfrente tiene 8, puedo ver que tengo más valor en camiones. Si yo tengo un ERP y la empresa de enfrente tiene un ERP, ¿Tenemos lo mismo? Si fuese una commodity, sí sería lo mismo, pero la realidad es que no. Cada ERP, cada instalación, cada equipo de mantenimiento hace que ese ERP entregue más o menos valor a la organización. Tener un portal de e-commerce no es una commodity. Cada portal es diferente. Incluso con la misma lista de funcionalidades el portal es diferente de una empresa a la otra. Y el resultado es que uno convertirá y venderá más que el otro. Tener “una cesta de la compra en tres simples pasos” no es una commodity. Hay múltiples factores que diferenciarán esa funcionalidad dependiendo de quién la haga. ¿Se colgará de tanto en tanto? ¿Si subimos ventas, mantendrá un buen rendimiento? ¿Se ve claro lo que se está comprando? ¿La experiencia del usuario es rápida? ¿Funciona bien en todos los dispositivos? y podría no parar.

El producto que generan los programadores no es una commodity y nunca lo será. Pero muchas veces el directivo de turno sólo ve “cesta de la compra en tres simples pasos”. Así que para él es una commodity. Pero incluso aunque entendiese el producto entregado a la perfección se perdería en lo que hay tras la capa de chapa y pintura. ¿Es mantenible el código? ¿Hay un plato de espagueti dentro que comenzará a fallar con solo mirarlo mal? Eso no lo ve el directivo.

Muchos diréis que lo terminará sabiendo cuando tenga que pagar el resultado. Pero tampoco. Porque un directivo verá costes que vienen de TI. No sabrá si lo que gastamos en mantener esa aplicación es lo normal o no. No tiene con lo que comparar. Con lo cual nunca podrá valorar si el desarrollo fue magnífico o una auténtica chapuza. Y eso si llega saber lo que se gasta en mantenerlo. La mayoría verá a TI como un centro de coste y punto.

Pero es que la cosa no se queda ahí. Realmente lo que me indigna no es ya que no se sepa valorar la calidad de lo entregado. Sino que realmente lo que se habla es del trabajo del programador. ¿Qué ha costado en hacerse? Siempre he sostenido que hay altísimas diferencias en la productividad entre distintas personas en TI. He visto ratios mayores a 10. Es decir, personas que entregan 10 veces más valor que otras. Pero no ganan 10 veces más que otras. Y el motivo es claro: en las cifras de la empresa son “un programador”. El directivo puede llegar a ver que determinada aplicación ha costado tantas horas de trabajo. ¿es mucho? ¿es poco? Ni idea. Así que esas horas de trabajo no tienen diferencia unas de otras a los ojos del directivo, con lo que: la hora de trabajo de un programador es una commodity.

Esto me recuerda a la escena de 300 al grito de “¡Espartanos!”.

Ya os dije que el trabajo no se puede medir en horas. Es la peor de las medidas que podemos tener.

Como el trabajo no se valora en su medida llega la frustración de los mega-cracks del equipo que ven el grandísimo valor que aportan a la empresa y el salario que reciben a cambio. Pero no pueden alcanzar el nivel que merecen porque: “¿Por qué pagar lo que pide cuando puedo contratar otro programador que lo hará igual de bien?”.

Esto no pasa en otras áreas de negocio. El ejemplo más claro son los comerciales. El directivo suele entender el trabajo que hacen y estimar correctamente su valor. Así hay comerciales que pueden implicar grandísimos contratos y por ello ganar enormes cantidades de dinero. Un comercial no es una commodity.

Como resumen: El directivo no suele tener ni idea de TI, tiene ideas a grandes rasgos. Esto le lleva a no valorar el trabajo que se realiza en el área de TI. Con lo que se termina pensando que ese trabajo es una commodity. La solución la tengo muy clara: que se den cuenta de la importancia de TI y que aprendan lo que pasa allí. Ya os dije que creo que los CIOs de hoy serán los CEOs del futuro.

Nuestra culpa

Los primeros culpables de que esto pase somos nosotros. Si el CEO no entiende, se le explica. Solemos fallar en explicar a negocio esta realidad. Solemos fallar en demostrar el valor que tiene el equipo de TI. Solemos fallar en demostrar el valor entregado y que no se nos vea como un centro de coste, sino como en un generador de valor y negocio.

Pero lo peor es cuando no personalizamos el trabajo de nuestro equipo hacia arriba. ¿Quién hará esto? Pondré a tres programadores. ERROR!. Pondré a Marta, a Juan y a Paco. Y se pueden añadir cosas como “Marta lo hará rápido y con Juan y Paco lo tendremos seguro en muy poco tiempo”.

Y luego está ese miedo a ser políticamente incorrecto y decir abiertamente “Pilar es una fuera de serie. Ella sola saca el trabajo de todo un equipo”. Pobre equipo… Las cosas como son. Si tenemos a alguien que vale lo mismo que todo un equipo, no reconocerlo es fallar a la verdad.

Recuerdo un caso en el que estaba intentando decir a un director el valor de un programador. Esa persona cobraba más que ningún otro, pero sólo un poco más que la media. Yo decía que era justo que cobrase el doble o triple que la media, y aún así seguiría siendo más rentable que el resto. El director se reía y me decía que eso era imposible. Así que llame a su coordinador y, delante del director, le dije: “Tengo un proyecto y te tengo que quitar al crack o a dos personas, ¿qué prefieres?” Su respuesta fue, “Quítame a tres. Quítame a todos. Pero no me quites a ese.”

Hay gente que programa más rápido. Que programa con más calidad. Que entiende mejor a negocio y acierta en lo que hace. Y hay que no. Si eso no se le enseña a los directores, nunca entenderán que es posible tener a un programador que influya más en el rumbo de la empresa que la mayoría de los directores. Y que eso debería pagarse.

El resultado

Lo he adelantado antes. Si se cree que el trabajo de desarrollo es una commodity. Si se cree que el producto que se entrega es una commodity. Entonces estamos perdidos. Ni se ganará lo que se merece ganar. Ni el área de TI recibirá la atención que se merece.

La empresa pagará no haber atendido como tocaba al área de TI. Pero lo peor de todo es que ni se dará cuenta porque no tendrá con qué comparar.

La solución, simple: “No consideres el trabajo de los programadores como una commodity”.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

4 comments

  1. Gonzalo 7 noviembre, 2018 at 16:17 Responder

    Muy buen post! Coincido en todo
    Una cosa que siempre odie es que el sector se llame software fatory, como si fuera una linea de montaje de software como si el codigo se escribiera mecanicamente, sin analisis… que el programador es solo programador, no piensa, pica codigo… prefiero desarrollador o analista programador o lo que sea pero programador a secas aca se entiende como secretaria que escribe cartas en java…

  2. Vicente 8 noviembre, 2018 at 14:21 Responder

    Pues sí, tienes razón. Hay que hablar de personas en concreto, personalizar los éxitos en personas en concreto e intentar generalizar los fracasos si es posible.

    También añadiría que tampoco puedes poner el doble de personas en un proyecto y pensar que irás más rápido, porque quizás hasta vas más lento!

  3. Oscar Oliva 14 noviembre, 2018 at 12:30 Responder

    100 % de acuerdo en lo que comentas. Me ha gustado mucho tu post porque refleja lo que llevo años pensando. Creo que hemos de trabajar para evangelizar al sector y por mi experiencia, aunque a un ritmo todavía muy lento, cada vez más las empresas estan haciendo este cambio de visión y dejan atrás prácticas del pasado. Sigue siendo muy complicado defender que este recurso senior le cuesta el doble a un cliente que este otro pero te aporta 5 veces más, por lo que realmente estás ahorrando. El precio hora es el principal indicador que se utiliza para comparar propuestas partiendo del error que se compara lo mismo, y eso no es así.

Post a new comment