Hoy he tenido una conversación que es bastante recurrente en esto del mundo de Internet. Básicamente el argumento sería el siguiente:
"Es que hoy por hoy en Internet yo puedo construir cualquier servicio desarrollado por 3 o 4 programadores llevándolo a China, Europa del Este o Uruguay. Por el sueldo que pago yo aquí en España puedo tener un crack allí."
(vaya por delante una nota, y es que yo soy español pero todo lo que voy a comentar en esta entrada sería igualmente aplicable a una empresa uruguaya, china o de europa del este que quisiera hacer offshoring en España, Portugal o Malta por decir algo)
A más de uno seguro que os suena el argumento. Típico caso de offshoring. El problema de estos argumentos es que siempre vienen de gente que no tiene ni idea de desarrollo de software y se creen que pueden encargar un container de líneas de código y listo, a vender. La realidad es que sí que lo pueden hacer, pero como en la mayoría de los casos sucede lo mismo que pasa con cualquier otra importación de bienes, lo bien que te salga la jugada dependerá de lo que quieres recibir y la calidad que necesitas. Por ejemplo, traerse programas de fuera tiene sentido cuando:
- Se trata de pequeñas porciones de código, componentes muy concretos y aislados, plantillas, diseños web para trabajos muy concretos, y en definitiva cualquier llamémosle software que pueda ejecutarse o integrarse con facilidad y no requiera de ningún tipo de mantenimiento adicional o necesite únicamente un mantenimiento a corto plazo. Por ejemplo, encargar un reproductor de vídeos, o un visor flash de cadenas para una joyería (como un amigo mio), o una plantilla para el blog corporativo se me antojan como tareas sobre las que no necesitas llevar demasiado control.
- Cuando no requieras ningún tipo de propiedad intelectual o no te preocupe que te copien. Tenlo claro. Si encargas un diseño a una tienda offshore no te esperes demasiada exclusividad en el resultado. Si encargas un programa para gestionar torneos de pádel, no te extrañe que después otra web tenga un programa como el tuyo (bueno, siendo optimistas, siempre puedes intentar firmar algo con ellos y confiar en que tu abogado sepa de chino en caso de que te copien).
- Cuando no necesites mucha calidad en el resultado. Cualquiera que haya trabajado con este tipo de factorías ya lo sabe. Yo he tenido tres experiencias. Y los resultados han ido desde desastroso hasta aceptable. Pero siempre que se ha querido un plus de calidad ha sido necesario el poner fondos extra y apretar. Pero es que es normal. Hay gente que se piensa que contrata esclavos chinos que viven en una nave en la que en lugar de máquinas de coser tienen PCs encendidos todo el día, ahí con el Eclipse, y al final la mayoría de las veces son trabajadores asalariados que harán lo mínimo necesario para terminar la tarea. Así que muchas veces o aceptas y te fías con lo que te ofrecen o no te queda otra que supervisar.
- Cuando necesitas un prototipo sucio de algo y no te importa la calidad. Simplemente necesitas el tener algo que presentarle quizás a un inversor, o para lanzar y ver si hay mercado, etc. Es decir, cuando tienes muy claro de antemano el que si la cosa va para serio, tendrás que contratar gente y rehacer todo desde cero.
En cualquier otro caso, olvídate. Cualquier desarrollo complejo necesita que seas dueño de él, de uno u otro modo. Tendrás que mejorarlo, ampliarlo, mantenerlo. Querrás algo que no esté fallando continuamente. Algo de calidad. Algo que sea resistente, algo que sea predecible. Seguramente necesitarás un produto que funcione para cien usuarios y siga funcionando para cien mil, o por lo menos que se pueda ampliar sin tener que empezar desde cero. El desarrollo de software es algo muy intelectual, no es como fabricar sillas en china.
Recuerdo un caso, en una empresa de las que estuve, en el que el desarrollo era complejo, pero como era un poco marroncillo tuvieron la genial idea de llevárselo a la India. Era como un merge especial de nuestro producto, que nadie quería hacer, así que nada, para allá se fue. Como había muchísima pasta, asumieron que con un ejercito de desarrolladores en la India podrían solucionar el problema rápidamente. Cuando me fuí, habían pasado ya tres años desde que empezara el proyecto. El resultado era seis millones de euros gastados, un proyecto sin ninguna traza de terminarse, un equipo en la India con decenas de personas que había rotado ya en más de tres ocasiones y no quedaba absolutamente nadie del equipo original y un banco muy cabreado. Eso sí, cuando se mandaba a alguien de visita a intentar poner algo de orden, siempre traía anécdotas muy graciosas.
Sinceramente, a parte de los casos que expongo arriba, el único modo que se me ocurre para que una externalización de este tipo funcione, es el que tus socios sean de otro país. Es decir, si tienes un socio en Venezuela por ejemplo (o si eres de Venezuela y tu socio es de España, para que no haya malentendidos), entonces la situación es diferente. Porque esa persona/equipo se beneficiará de lo que hace con algo más que un simple salario de esclavo. Un equipo que desarrolle un producto y qe por ejemplo adquiera los derechos de explotación y comercialización en su continente, aunque sea a comisión, va a ser muchísimo más productivo y tendrá mucha más responsabilidad que otro equipo que simplemente se dedique a mandarte líneas de código en un barco.
Me gustó también mucho lo que nos comentaba Carlos Espinal, en Seedcamp, y era que su compañía sólo invertía en empresas que fuesen dueños y productores de sus propios productos. Es decir, que si eras una startup con 2 MBAs que tenían una fantástica web creada en Polonia por cuatro dueros, ya podías ir saliendo por la puerta. La principal razón, nos comentaba, era porque ¿qué iba a pasar cuando no tuvieses más dinero para comprar fuera? Se trata de una visión mucho más economista, pero no deja de ser cierta. Si los desarrolladores no son parte del equipo, no son socios, o simplemente trabajan por un simple salario. ¿Qué vas a hacer cuando se acabe el dinero? ¿Quién va a programar? ¿Vas a pedirnos más dinero? ¿Y si no hay dinero, ya se ha acabado el proyecto?
Por cierto que yo no he podido ir a la charla pero todo esto que escribo, si no me equivoco está bastante relacionado con lo que cuentan este fin de semana David Bonilla y Jerónimo López en su HumanWare, o explicado con sus propias palabras: "Un programador no es un botijo".
Y no me enrollo más. Seguro que más de uno tiene experiencias que compartir. ¡No dudéis en comentarlas!