Bueno, la primera razón es que me gusta el rollo “profeta del apocalípsis” 
: me da muy buen resultado en las charlas, como en esta de la Conferencia Agile Spain 2010, en la que solté esta perla y fue ampliamente comentada:
Pero en serio, el caso es que llevo tiempo queriendo escribir sobre el tema siguiendo con la línea de mis dos post anteriores (consultoría Don Simón, Chapatas calentitas), y el hecho de que Xavi me haya remitido hoy un enlace a este artículo referenciado en barrapunto me empuja a hacerlo. La verdad es que coincido en gran mayoría de los aspectos y argumentos comentados por el autor, y específicamente la diferencia fundamental y no entendida entre los procesos de fabricación industrial (Taylorismo / Fordismo) y la naturaleza intrínseca del desarrollo de software es algo que se ha comentado ampliamente en la comunidad Ágil y que podéis ver en algunas de las presentaciones que he realizado al respecto (verbigratia, esta slide).
Naturalmente, cualquier afirmación grandilocuente, generalista y extrema como “No hay una industria del software en España” es tremendamente injusta, ya que al fin y al cabo se trata de un recurso retórico 
. Por supuesto que hay empresas dedicadas al software. Pero el promedio de la industria no es ese, y la dispersión respecto a la media no es muy grande que digamos. Si nos preguntamos cuál es la industria media del software en España, habrá poca gente que piense cosas fuera de un circuito “consultoras, banca, administración…”. Y ahí es donde digo que eso no es una industria del software, porque este tipo de empresas no te venden un software: te venden “horas de programador”. Como si una hora de programador fuera una commodity, es decir, algo perfectamente intercambiable por la hora de cualquier otro programador, y cuyo único valor reside en la cantidad de producto que poseemos o negociamos.
Oh. Dios. Mío. Las cosas pueden estar algo más rotas, pero no mucho, la verdad.
Pensamientos como este conducen a desastres organizativos como las “líneas de montaje” consultor-analista-desarrollador-tester en las que diagramas UML, mapas entidad-relación, modelos de datos y documentos de requisitos viajan por correo electrónico entre personas que no hablan nunca entre ellas. Como si un programador fuera una máquina a la que alimentamos con UML y escupe código. Y claro, en algún momento acabamos por pensar si no habría forma de diseñar algún tipo de máquina o herramienta (no se, llamemoslas CASE) para librarnos del incordio de los programadores, que son unos tíos raros que llevan camisetas frikis, huelen mal y protestan por todo. Bloody programmers. 
¿Veis lo roto que llega a estar todo?
Claro, si al final la oferta se basa únicamente en “horas de programador” y no en producto, la discusión comercial ya no va en términos de funcionalidad, calidad, rendimiento… Si discutimos cobre una commodity, como por ejemplo el petroleo, solo discutimos el precio del barril y dónde me lo vas a entregar. Y cuando de repente vendo diez mil barriles, da igual si cojo dos mil de aquí, tres mil de allá, cuatro mil de acullá y luego voy “sisando” otros mil barriles poco a poco de otros sitios: el proyecto ha sido un éxito.
Pero cuando intento hacer una operación a corazón abierto, a nadie se le ocurre que la primera hora la haga un cirujano, la segunda otro distinto y la tercera ya veremos si pillamos a alguien por el pasillo para que la termine. La ventaja con la que cuentan los médicos es que ya llevaban miles de años gestionando hospitales antes de que los industriales del automovil se alzaran como adalides de la producción en cadena, las economías de escala y los sistemas MRP.
Lo mismo ocurre con los equipos de desarrollo. Nadie que de verdad conozca cómo funciona la creación de un producto sofwtare puede pretender que enfoques como el “pool de recursos” proporcionen mejor rendimiento que un modelo basado en equipos comprometidos, autogestionados y capacitados. Tendré que hacer otro articulo para hablar de los factores de motivación inherentes al trabajo en equipo y su efecto en el rendimiento cerebral de una persona a la que, en realidad, no pagamos por calentar un asiento o imputar horas de “farmville” al proyecto, sino por resolver problemas complejos y únicos de la forma más eficaz y eficiente posible.
¿Alguien puede creerse aun que las economías de escala funcionan necesaria y directamente en el mundo del software? Si eso es así, y teniendo en cuenta que una consultora puede considerarse afortunada si genera entre 60.000 y 200.000 euros por empleado, ¿Cómo es posible que compañías como Craiglists, con 30 empleados, generen un ratio de más de tres millones de dólares por empleado? ¿Cómo consigue 37Signals, creadores de Basecamp y Ruby on Rails, dar soporte a más de tres millones de clientes con una plantilla de en torno a 18 personas?
Y seguimos sin entederlo. Medimos los proyectos por el número de horas que imputamos, y claro, si te acercas a una de estas empresas y les dices “puedo enseñarte cómo hacer ese proyecto de doce años en solo uno” te miran con cara de susto y te responden “¿tú eres idiota? ¿por qué debería cobrar sólo por un año si puedo cobrar por doce?”.
Y tienen razón. Y ganan pasta. Mucha.
No vendemos software: vendemos servicios. Vendemos disponibilidad, horas suboptimas de bajo rendimiento pero en gran cantidad y baratas, muy baratas, más baratas. Las primeras compañías que se dieron el batacazo con el offshoring ya se dieron cuenta que externalizar el trabajo a una compañía que te vende las horas a mitad de precio no es tan buen negocio si luego las horas crecen al cuádruple porque no sabemos gestionar bien proyectos con el “ruido” que introduce un entorno offshore o porque los programadores tan baratos que nos han vendido no distinguen un ordenador de un piano. El panorama ha cambiado y después de décadas de offshoring los proveedores de estos servicios han descubierto muchas cosas respecto al negocio en el que operan, y ahora mandan a gente al origen para que haga de puente entre sus clientes y ellos, forman a sus trabajadores, protegen a sus equipos… Y usan metodologías Ágiles de desarrollo, pero esa es otra historia.
Tengo muy pocas esperanzas puestas en que el negocio de las “cárnicas” cambie, pero las pocas que existen están en el lado del cliente más que en la capacidad de los equipos y miembros de estas empresas para cambiar una mentalidad directiva que solo ve los resultados desde la perspectiva del dividendo y la cifra de negocio. Las consultoras comienzan a llamarme para que las forme porque sus clientes empiezan a exigir enfoques Ágiles de los proyectos, y esto es una gran noticia. Esperemos que la cosa prospere a partir de ahí: mucho más bajo no podemos ir…
Totalmente de acuerdo, excepto con el tema del offshore… lo unico que han descubierto es como cubrir los problemas de comunicación con un monton de metodologia y burocracia, pero esa da para otro tema del que podriamos conversar pues ahora soy justamente un “puente”.
Y si… mal vamos y no mejorara pues el modelo de negocio sigue funcionando…
Sí, tienes razón, debería haber matizado diciendo que “las primeras de la clase” en offshoring, que no son mayoría para nada, han aprendido ha hacer esto. Lamento que tu experiencia no esté en esta línea, pero te animo a seguir desarrollándola, porque te aseguro que se puede
Cuando estudié Informática (Licenciatura, Ingeniería o lo que sea) lo hice porque creía en una herramienta CREATIVA. Cuando comencé a trabajar especialmente con empresas grandes aquello parecía más bien un criadero de pollos, todos picando sin parar pero sin saber qué picaban. ¿Dónde cambió todo tanto? ¿Por qué se perdió el camino correcto? El éxito de empresas pequeñas (o muy pequeñas) y de herramientas como las Metodologías Ágiles que vuelven a recuperar el valor de la “materia gris” de cada uno es una muy buena noticia para todos. Creo que esto sí es crear Software y Soluciones. A ver si logramos ese cambio, más que necesario. O seguiremos como bien dices sin Industria del Software. Un saludo!
Coincido al 100% con el análisis, Angel. Lo que me mata es no tener claro por dónde atacar, más allá de la evangelización de cada uno en nuestro ámbito de actuación y con el ejemplo.
Ayer mismo, en un cliente, comentaban como causa de la dimisión de un *altísimo* cargo al que habían asignado la reestructuración de las divisiones de sistemas.
Al parecer había cometido la torpeza de apostar por la *internalización* para recuperar el control y frenar la sangría de subcontratistas anidados que sólo servían para encarecer el servicio y obtener software que no servía a sus objetivos.
La dirección de la empresa (y tiene narices!), sencillamente no aceptó una solución que, incluso teniendo toda la lógica del mundo, y suponiendo *ahorro* y *mejora de eficiencia*, incurría en el sacrilegio de aumentar la plantilla interna.
Así que desautorización al canto, y aviso a navegantes para que no lo vuelvan a intentar…
¿A dónde va este país cuando la externalización es más estratégica que los sistemas?
Ahora hasta los costes de Argentina parecen caros, y la nueva moda es Filipinas, más que nada porque el patético nivel de inglés de nuestro patio de colegio no permite entenderse con India… no se si reirme o llorar
[disclaimer: trabajo *continuamente* con empresas de Argentina, pero eso, *trabajo con* ellas, con estabilidad y haciendo equipo]
Efectivamente, se ha perdido mucho de lo que es valorar el rol estrategico que supone el conocimiento de IT dentro de la organización, y es eso… mucho de los problemas van por ahi y es mal repetido en las organizaciones que consideran a IT como algo tan contratable como las señoras de la limpieza o las maquinas de vending.
Retomando mi experiencia, creo estar en condiciones que esto del offshore se podria mejorar si desde el cliente se controlara que un % del equipo que te da servicio haya tenido experiencia inshore, pues los problemas que he percibido vienen de la carencia total de experiencia de trabajar directamente con una organizacion de manera NO REMOTA. Ergo… para ser un buen offshore antes hay que haber sido inshore.
Estoy de acuerdo con lo que dices. Es así. Tal cual. Palabra por palabra.
Creo que es interesante puntualizar que fuera de España pasa lo mismo o parecido en la ‘Consultoría Tecnológica’. Y se alimentan de gente mediocre de la misma manera. Y cuando necesitan talento, tiran de contractors para meter el talento, que siempre es necesario.
Lo que pasa es que la gente buena ‘escapa’ a las empresas de Producto, los que innovan. Y eso es lo que falta, empresas de Producto.
¿Por qué no hay empresas de Producto? Básicamente porque es complicado innovar, encontrar financiación y arriesgar. ARRIESGAR. Con mayúsculas. Vender carne tiene pocos riesgos.
De todos modos, me resisto a pensar que estoy constreñido a la realidad española. El software te permite competir en el mundo independientemente de donde seas. Así que miremos hacia fuera y no hacia España.
Qué gozada de artículo, así como el de Barrapunto.
Es por eso que yo he dejado la programación y me he hecho Artista del Software. Y, por supuesto, cobro la línea de código a precio de pincelada de óleo. De algo parecido estuve yo pensando ya hace algún tiempo http://www.lapastillaroja.net/archives/001501.html
Excelente análisis, Angel. Me ha gustado especialmente la comparación con las commodities.
Sobre el comentario de Jorge, me gustaría referirme a este hilo en la lista de correo de Artesanos de Software sobre intercambio de profesionales o uno algo anterior sobre “el mundo real” en la lista de Agile-Spain. Estos ejemplos demuestran que esa “industria artesanal (y algo artística)” es posible y que está en nuestras manos el hacerla posible.
Lo de fabricas del software es vergonzoso y las carnicas peor todavia. Debemos forzar un cambio en la forma de trabajar o el software español sera el peor y nuestro trabajo no tendra futuro.
Ahí va mi ladrillo:
La verdad es que nos enfrentamos a un problema que al menos en parte tiene su origen en la crisis de las punto com. En un lapso de tiempo de apenas unos meses se pasó de pagar a precio de oro todo lo que sonara a tecnología a tratar de hacer desarrollos ajustando todo lo posible en todo lo que sonara a tecnología. Se pasó de sobrevalorar la tecnología y despreciar la viabilidad de negocio (La nueva economía) a considerar que lo único valioso en un proyecto software es el planteamiento de negocio y la gestión y considerar la ejecución técnica como una “commodity”. Tanto un extremo como otro son peligrosos.
Lamentablemente en el extremo en el que estamos las consecuencias negativas se tardan más en ver. La gente con conocimientos de negocio en puestos de relevancia y con visibilidad pública abunda (al menos hasta cierto punto). Pero la gente con conocimientos técnicos para ver esto, en puestos de relevancia y con capacidad de toma de decisiones escasea.
Hay una serie de cuestiones a las que se debe prestar atención:
La tecnología de desarrollo de software evoluciona y se hace cada vez más compleja. Desde el punto de vista
de un problema concreto fijo con unos requisitos fijados se observa como la evolución de la tecnología
hace que la resolución de ese problema sea cada vez más sencilla (en ultima instancia no desarrolles,
compra un producto que ya lo hace o casi). Pero desde una perspectiva más amplia cada avance tecnológico abre un
mundo de posibilidades que plantea un desafío de mayor complejidad que la complejidad que logra disminuir
dicho avance tecnológico, sobre un problema previamente conocido. La mayor parte de los gestores de empresas
tecnológicas españolas ven lo primero pero no lo segundo. De ahí la ilusión por la “comoditización”.
El modelo de desarrollo de software basado en la reutilización de componentes contribuye también a crear
la ilusión por la “comoditización”(de cada vez hace falta menos gente que sepa construir software, me basta
con gente que sepa juntar y configurar componentes prefabricados). Pero como dice Brooks, la reutilización
de componentes no ataca la complejidad de fondo (aunque sea un avance) simplemente cambia el problema
de sitio, donde antes hacía falta hacer mucho esfuerzo de construcción con una base formada por un lenguaje
de programación y una serie de funciones básicas de biblioteca ahora hace falta eso y: plataformas de
desarrollo, de despliegue, frameworks, toolkits, ERPs, en resumidas cuentas un vocabulario más amplio
que necesariamente requiere un profesional con una base más amplia y que se tarda más tiempo en adquirir.
Las empresas de consultoría optan cada vez más por un modelo centrado en la definición de especificaciones
de negocio y subcontratación o externalización de la ejecución den proyecto (me dedico a elaborar especificaciones
de negocio y a gestionar la subcontración que es donde creo que está el valor añadido). Todos sabemos los problemas
que supone en muchos proyectos esto en forma de dificultades de distancia física, cultural, idiomática… pero
en el medio plazo yo vislumbro además otro problema. Hasta ahora esto puede funcionar medio regular en muchos casos
porque del lado de la empresa consultora hay gente que es capaz de entender lo que hay en el otro lado, porque
todavía hay una generación de gestores que ha pasado en mayor o menor medida por las trincheras. Pero qué va a pasar
con futuras incorporaciones si ya no hay trincheras en las empresas de consultoría ¿Ignoramos el problema?
¿Los mandamos a las trincheras a fogearse una temporada aceptando que serán nuestros soldados más caros? Creo
que en última instancia esto, si no se aborda correctamente, puede dar la puntilla a más de una consultora cuyo
negocio puede acabar siendo fagocitado por sus “externalizados” (que son los que en última instancia van a acabar
sabiendo dominar todo el proceso de cabo a rabo).
Desde la cierta distancia (estoy emigrado en Irlanda), coincido mucho con la visión de Angel. Es que me parece que en España, poca industria del software.
Me estoy acordando de este artículo de JoelOnSoftware deonde habla de los 5 mundos del software (http://www.joelonsoftware.com/articles/FiveWorlds.html)
De los 3 mundos que propone, en España se hacen básicamente 2 (internal y throwaway), y de modo bastante chapucero, porque se va poniendo ñapa sobre ñapa, “esto tiene que estar para mañana” y el que venga después, que arree… Eso de estándares de calidad, para cuando tengamos tiempo, mi código es mío y que no me lo lea nadie, el mejor profesional es el que llega 5 minutos antes del jefe y el que se va 5 min después, etc…
Claro, pasa lo que pasa, rotaciones muy altas, productividad muy baja, sueldos bajísimos, y la gente quemadísima.
Es una pena, pero pocas soluciones veo. Creo que hay gente muy muy capaz, pero salvo que alguna empresa pequeña de el pelotazo y un poco suelte el bofetón directamente a mucha gente, mal camino se lleva…
Pingback: La semana en los blogs CCXXI | NotiGeek
Querido Ángel, estoy disfrutando mucho de tu blog y soñando con las aportaciones que podrías realizar a la organización de mi entorno.
Lo cierto es que hace tiempo que desarrollamos con Ágil, pero siendo un equipo de dos programadores es relativamente fácil. Sin embargo, extendería sin dudarlo la misma filosofía a la gestión del resto de procesos… si dependiera solo de mí.
De venir a mi colegio, creo que te sorprendería el alto grado de complejidad de los procesos, la escasa disponibilidad de todo tipo de recursos, la presión exterior para obtener resultados y el muy limitado tiempo de reacción… en resumen, la gestión de un centro educativo es un auténtico reto.
Un fuerte abrazo, seguiré aprendiendo de ti y espero que nos podamos ver pronto.
Pingback: La industría del software en España | Al otro lado del mostrador