Mostrando entradas con la etiqueta empresa. Mostrar todas las entradas
Mostrando entradas con la etiqueta empresa. Mostrar todas las entradas

jueves, julio 26, 2012

¿Cuánto pagar a los mejores empleados?

jueves, julio 26, 2012 por Martín

Hoy me he encontrado con un artículo en portada de la revista Inc. que me ha gustado mucho. Además me ha coincidido muy bien en el tiempo porque ayer justo alguien me decía que eramos muy caros con respecto a lo que cobrábamos por nuestro trabajo diario. Así que no he podido evitar sentirme de algún modo identificado. No realmente por pretender ser "los mejores empleados" si no más bien porque sé perfectamente que lo que ofrecemos vale lo que pedimos o mucho más.

viernes, julio 01, 2011

Creando una empresa en 24 horas por 100€

viernes, julio 01, 2011 por Martín

El pasado Jueves recogí en la notaría los papeles de mi nueva empresa cuyo nombre corto es Canteira Software.

A principios de Junio me encontré con la necesidad de crear una nueva empresa, con lo que ya tengo dos (sigo siendo socio de Jobsket), y además es que la necesitaba bastante rápido. Por diversos medios me enteré de ese decreto que permite crear empresas en 24h por cien euros y pensé: vamos a probar. ¿Se puede crear una empresa en 24h? ¿Es posible? Os voy a contar mi experiencia.

lunes, abril 18, 2011

Emprender en España. Mito 3. Necesito un comercial.

lunes, abril 18, 2011 por Martín


La verdad es que ya hace bastante que no me busco problemas, ni fomento la seguramente ya existente animadversión de guruseles y demás cancamuseo del sector emprendedor. Así que llega la hora de un nuevo mito. Esta vez uno que quizás hayáis oido a más de uno/a por ahí, porque es muy común. Necesito un comercial.

Esta frase es habitual en startups que no han considerado la parte comercial en su desarrollo. Probablemente startups formadas en su mayor parte por técnicos, que de repente se dan cuenta de la cruda realidad: tienen un producto excelente desde el punto de vista tecnológico, pero apenas materializan ventas. Entonces basándose en lo que se puede leer en blogs de cancamusa y gurúses varios, toman la peor medida posible: Contratar a un comercial.

martes, noviembre 09, 2010

¿Alquilarías un Director Técnico?

martes, noviembre 09, 2010 por Martín


Hace poco leía en la prensa financiera algo que me ha sorprendido bastante. Un ex Vice Presidente de Merrill Lynch y veterano en las Tecnologías de la Información que ha creado una compañía para alquiler de CTOs, acrónimo de Chief Technical Officer o en Español lo que sería un Director Técnico.

Esta compañía se especializa en el sector financiero. ¿Y por qué querría alguien del sector financiero alquilar a un CTO? Bueno, básicamente la idea es que las agencias de trading, gestoras de capital, gestoras de fondos, y otros gamblers financieros en general se dedican a las finanzas. Sin embargo tienen que tratar en el día a día con montones de herramientas diferentes, algunas de ellas junto con la elección tecnológica pueden ser muy relevantes a la hora de captación de fondos.

Es decir que la labor del CTO es fundamental pero muy puntual. En estos casos la necesidad de tener un director técnico en el equipo de manera permanente es muy dudosa. En su web lo resumen de la siguiente manera:

"Institutional investment is key to hedge funds. Investors are now demanding greater transparency, reporting and accountability. Many aspects of this apply to technology and the associated business processes. Cambridge CTO brings you institutional-strength process and management, filling the gaps left by multiple technology vendors across infrastructure, market data, trading systems providers and other business partners. Our engagements provide you with the level of diligence that investors are seeking; additionally relieving you from routine technology management, allowing your focus on core business."

A mi la idea me parece bastante buena. No deja de ser una consultoría tradicional, pero aquí lo que vendes es el mandarte a un super-consultor, la creme de la creme de los CTOs, para que esté contigo un par de semanas, te ayude a definir tu estrategia y te pase la factura. Hablamos claro de un coste que si fuera permanente sería muy alto. Me imagino que en Londres un CTO en el sector financiero no debería bajar de las 100.000 libras anuales tirando por lo bajo, así que ya es un gasto.

Y la cuestión es, ¿funcionaría esto en España? Está complicado, ¿verdad? Pero nunca se sabe. Si eres una persona con experiencia en el sector y contactos en empresas que se lo puedan permitir y se ajusten a estas necesidades no parece un mal negocio. ¿Qué opináis?

jueves, noviembre 04, 2010

La lista de la verguenza de España: Las 100 principales empresas de software europeas

jueves, noviembre 04, 2010 por Martín


Estos días he estado categorizando los posts del blog y he dado con algunos temas muy interesantes. Uno de ellos tiene que ver con un post de hace nada menos que 3 años.

Mostraba la lista con los 100 vendedores de software más importantes de Europa en el 2007. Por supuesto, no había ni una sóla empresa española en el listado.

Claro, con estás he pensado. ¿Y cuántas empresas habrá ahora en el 2010 en al listado? ... ¿Qué creéis?

En efecto: NINGUNA UNA (Gracias Carlos. Había buscado 'ES' en vez de 'SP'). Oye por lo menos en tres años ya tenemos a una. !!! Panda Security, y hay que decir que tienen mucho mérito.

Aquí tenéis para nuestro lamento personal la lista de los mayores vendedores europeos de software del 2010.

miércoles, marzo 24, 2010

Programas "Made In China"

miércoles, marzo 24, 2010 por Martín


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!

sábado, marzo 20, 2010

La horda de testers

sábado, marzo 20, 2010 por Martín

El término Mongolian Horde proviene de las hordas mongolas de Genghis Khan y sus hijos que conquistaron gran parte de Asia y Europa durante los siglos 13 y 14. La estrategia que seguían en sus combates era lanzar miles y miles de soldados contra sus enemigos sobrepasándolos en número y consiguiendo victorias sencillas.



Mongolian Horde es un término que se utiliza en la actualidad en el mundo de los negocios al tratar de resolver un problema a base de asignar más y más personas a la resolución del mismo, pensando (muchas veces inocentemente) que el disponer de más personas asignadas a una tarea hará que ésta llegue satisfactoriamente a su fin. En el mundo del software este término toma relevancia especial por lo habitual que han llegado a ser este tipo de situaciones. George Stepanek lo explica muy bien en su libro "Why software projects fail":

A naive project manager who saw developers as equivalent to each other would be tempted to use the so-called "Mongolian Horde" approach, which uses a large number of cheap and inexperienced developers. Just as with the original Horde, the end result is chaos. Even allowing for their limited design and programming skills, the developers just don't have the experience to organize and deliver a system of this scale.

Some developers can even bring negative productivity to a team. They may not understand the sophistication of the team's code, and will introduce bugs that require lots of rework. They may demand so much help that their own work fails to compensate for the lost productivity of the other team members...


En uno de los últimos proyectos en los que he trabajado me encontré con algo muy similar, pero en un campo en el que nunca lo había experimentado, que es el del testing de programas. Tener testers no es algo demasiado habitual en España, salvo en grandes empresas, mientras que en Irlanda era el pan nuestro de cada día. En todos los proyectos en los que participé había un departamento separado de pruebas. No sólo eso, los testers no tenían idea de programación, ni siquiera eran informáticos. La idea es en este caso tener personas con experiencia en el negocio que aunque no esan informáticos sepan realmente como debe funcionar la aplicación, y no tenga ideas preconcebidas sobre desarrollo de software sino que se comporten como meros usuarios. No es mala idea, pero eso es otro tema.

El caso es que en uno de estos proyectos estaban unos ocho testers. Pero había un problema, nuestro software, que básicamente era una conversión entre formatos de ficheros para entornos bancarios, tenía miles y miles de posibles entradas y salidas. El equipo de testers era muy tradicional, y su lider se negaba a recibir cualquier tipo de ayuda de automatización. Esto hacía que cada vez que lanzábamos una release, que era tras tres semanas porque en desarrollo seguíamos el dictamen Agile, tenían que probar todas esas combinaciones manualmente. Algo totalmente imposible. Nunca llegaban al 20% de pruebas, así que poco a poco el producto iba ganando más y más bugs lo que nos afectaba a desarrollo.

La solución ideada por los managers fue crear una Horda de testers. Contrataron más personas e incluso una agencia externa de testing. Llegó a haber un equipo de 38 testers!!! ¿Os lo podéis imaginar en una empresa que no llega a los 100 empleados? Ni que decir tiene que la iniciativa fue un fracaso. Ellos mismos se dieron cuenta de que tener más testers no significa probar más y mejor la aplicación. De hecho el número de errores aumentó y el número de pruebas realizada disminuyó. Era simplemente demasiado complejo el controlar y formar a tanta gente en tan poco tiempo como necesitaban.

¿Cuál fue la solución? En este caso el marrón me tocó a mi, pero desde desarrollo conseguimos convencerlos de que la única opción es que nos dejasen proporcionarles herramientas para automatizar su trabajo. Lo que hicimos fue separar un grupo de swats (desarrolladores kamikaze jejeje) que creamos un sistema para que ellos pudiesen diseñar tests automatizables. Muy simple y en lenguaje natural. De modo que ellos definian los tests y por detrás nosotros lanzábamos sin que se diesen cuenta acciones de HTMLUnit que iban probrando las páginas webs. Imaginaros, un test podría ser:

- upload /tmp/Test1.xml
- Login:username=martin,password=martin
- click "Results"
- assertExists "Upload Test1.xml successful"
- Validate /results/Test1.xml

Esto es algo totalmente inventado, el lenguaje era incluso más sencillo que esto. Pero os da una idea. Además, los testers podían reutilizar los tests, para crear sus propias cadenas de tests más complejos. En un principio recibieron la herramienta con escepticismo. Ya sabeis, "Aquí vienen estos con más trabajo con lo ocupados que estamos". Pero en cuanto vieron que ahora podían repetir los tests cuando quisieran, que no tenían que andar continuamente haciendo el mismo setup manual, y que un test que les llevaba media hora hacerlo pasaba a llevarles un minuto, la historia cambio. En unas pocas semanas tenían automatizado el 30% del trabajo, mucho más de lo que habían conseguido nunca. Y lo más importante para nosotros, los desarrolladores, al incluir los tests en la build, teníamos garantía de que todo funcionaba.

No sé si alguno de vosotros habéis vivido una experiencia similar, pero os animo a compartirla. Espero que os haya interesado mi historieta.

martes, noviembre 03, 2009

Benchmarking IT Industry 2009 : España por los suelos

martes, noviembre 03, 2009 por Martín


Ninguna sorpresa. He llegado a un informe del mes pasado de la publicación británica The Economist donde analizan la fuerza de la industría de las TI en diferentes países de todo el mundo. Podéis ver vosotros mismos el informe desde este enlace.

Como era de esperar, la clasificación de España, por los suelos. En el mundo hemos nos colocamos en el puesto 25 justo por encima de potencias IT como son la republica Checa, Chile, Hungría, Eslovenia, Portugal, Lituania o Grecia por ejemplo. El número es mejor, aunque no la clasificación si nos limitamos a Europa Occidental. Ahí ocupamos el puesto 14, sólamente por encima de Portugal y Grecia.

Ahondando un poco en las razones, la puntuación para lo que el informe llama "Entorno de investigación y desarrollo" es prácticamente tercermundista, superando sólo a países como Portugal, Polonia, Mexico, Tailandia, Turkia, Bulgaria, Colombia, y en fin... supongo que os imaginais el resto de la lista.

Como siempre, por la cola. ¿Cuántas crisis tendrán que llegar para que espabilemos?

martes, junio 23, 2009

UBS y Citi deshaciéndose de parte sus departamentos de IT

martes, junio 23, 2009 por Martín

Hoy me he encontrado con un par de noticias muy interesantes, dan para mucho que hablar. Reportaban en Finextra que Citi está intentando vender su plataforma IT a alguna multinacional India. Mencionan Tata Consultancy Services y Wipro como posibles compradores. También referenciaban a UBS como otro gran banco que se está intentando deshacer de sus plataformas de IT, más concretamente de sus centros de Polonia y la India.

Si consiguen vender sus departamentos, serán unos genios. Porque a ver quien se cree que sus plataformas las pueden vender a otras firmas. Bueno, tampoco hay que ser talibanes del software, todos sabemos lo buenos que los vendedores pueden llegar a ser, y si nos dicen que la plataforma de trading del Citi va a funcionar sin problemas en el Banco Etxeverria, pues seguro que habrá algún directivo que hasta se lo crea.

En fin, a mi estas noticias me hacen reflexionar. Pensar lo abajo que estamos en la escalera de decisión y lo poquita cosa que puede ser un programador para un super-banco como este. Y es que el ahorro de costes en IT parece que no tiene fin. Empiezas con tu cubículo en Suiza, el banco ahorra costes y te subcontratan a una empresa Suiza, el banco ahorra costes y te subcontratan a un centro de producción en Polonia, el banco ahorra más costes y te venden a una empresa de subcontratas India.

De hecho es una pasada todo lo que han crecido estas empresas de subcontratación como Wipro. Resulta sorprendente que sean estas compañías las que estén pujando por el software de estos gigantes bancarios...

Nada, unas reflexiones a golpe de Martes.

miércoles, junio 03, 2009

La historia de Linkedin

miércoles, junio 03, 2009 por Martín


En CNNMoney.com publican una entrevista a Reid Hoffman, el creador de Linkedin. La entrevista es muy interesante.

Reid de 41 años quería emprender y tras acabar su carrera en Standford, tenía algunas ideas, así que se aproximó a los inversores. Lo primero que le preguntaron fue "¿Tienes experiencia lanzando software?" Ante el no de la respuesta, le dieron un consejo "Sal a fuera y busca un trabajo".

Tras trabajar en Apple como desarrollador y en Fujitsu como manager de producto, en 1997 creó su primera compañía, Socialnet. De esta experiencia Reid cuenta que aprendió mucho. Era una empresa orientada al dating, pero que quería hacer demasiado: buscar compañeros de piso, gente para jugar al golf, ... Consiguió capital de riesgo, pero no funcionó. La lección que aprendió es que no llega con tener una idea, porque esta puede fallar. Ellos pensaban en asociarse con periódicos, pero no funcionó, y después no pudieron escalar. Hay que pensar en como llegar a millones de usuarios.

Tras su época en Socialnet, se une a Peter Thiel y Max Levchin y entra en Paypal como vicepresidente en cargo del desarrollo de negocio. Paypal es un éxito. Después de Paypal, Reid decide reinvertir sus ganancias en un proyecto nuevo, Linkedin. Esto es en el 2003, y Reid sigue un modelo en Linkedin que no todo el mundo puede permitirse. Con su dinero, financia el proyecto, centrándose en crear un producto que llegue a las masas.

No es hasta el 2005 cuando empiezan a crear fuentes para monetizar Linkedin. Comenzaron con anuncios de trabajo, siguieron con las funcionalidades para contactar otros usuarios y expandir tu red de contacto, y por último añadieron los anuncios. Todas estas funcionalidades vinieron a raiz de tener un sitio web con millones de usuarios.

Los comienzos de Linkedin fueron los mismos que cualquier otra empresa. Para empezar, y porque tenían miedo de que el sistema no fuese estable, comenzaron sólo con 113 usuarios, amigos de las 13 personas que estaban en la compañía. Una vez el sistema estaba funcionando, se hicieron la pregunta: "¿Cómo llegamos a un millón de usuarios?". Fácil, ¿no? :)

Según comentan en la entrevista, Linkedin es una empresa con unas cuentas envidiables y dinero en el banco. El año pasado consiguieron más de 80 millones de dólares en inversiones, y tienen algo más de 300 empleados (aunque también echaron al 10% de su plantilla).

Bueno, no sé a vosotros pero a mi la entrevista me ha gustado. Yo, mientras, me quedo pensando como llegar al millón de usuarios.

domingo, mayo 31, 2009

Sobre la crisis, consultoras y el estado de nuestras IT

domingo, mayo 31, 2009 por Martín

Recojo el relevo de Julio César Pérez Árques que comenta en su blog que la crisis está empezando a afectar a las empresas de IT y aunque ya he escrito un comentario ahí, no puedo aguantarme y necesito poner mi opinión muy modesta y personal por aquí.

Algunas veces, las cosas son más sencillas de lo que parecen, y para mi, esta es una de ellas. Hace ya unos años dejaba una pregunta abierta por aquí: ¿Dónde están las empresas de software?. Y sinceramente, sigo sin encontrarlas. O al menos, sigo sin oir sobre ellas, porque esto es como las meigas, haberlas háilas, pero promoción y ayudas parece que se les dan más bien pocas. A bote pronto me encanta seguir lo que hacen la gente de Abiquo, pero por lo demás, poco oímos sobre gente que esté peleando ahí con los grandes de Silicon Valley.

Sí que es cierto que poco a poco las startups que van saliendo, sí lo hacen mirando al exterior. Parece que esta lección la tenemos aprendida. Y algunos servicios que se me vienen ahora a la cabeza como Nuroa, Trovit, Rentalia, etc. parece que están vendiendo fuera. Pero igualmente, se cuentan con las manos. Y tampoco son el tipo de servicio que vayan a hacer las portadas de los diarios de IT y economía internacionales. Chapeau, para los chicos de Abiquo que están recibiendo reseñas en medios de todo el mundo. Pero, y corregidme si me equivoco porque quizás me esté olvidando de gente, pero creo que nos quedamos en eso. O eso, o simplemente nadie se presenta a a informes como este.

¿Cuáles son las razones? ¿Quizás la desregulación de la profesión?, ¿el intrusismo profesional?, ¿o la falta de formación práctica?, ¿universidades?

Sinceramente yo creo que no. Para mi la razón de todo es mucho más simple. ¡Somos Españoles! Ya lo dice el dicho, "Spain is different". En España nos va la sangría, la fiesta, los toros, y sobre todo, el dinero fácil. El pelotazo, en sus más variopintas formas, sea fútbol, sean sellos, sean ladrillos o terreno. Qué más da. Hay que hacer dinero fácil, rapido y sin currar, porque si no serás un fracasado. ¡Quién diablos quiere montar una empresa de hacer programas de ordenador cuando puedes hacer millones juntando ladrillos! Y, ¿por qué va un ayuntamiento a financiar proyectos de emprendedores?, si puede simplemente recalificar y especular con el terreno.

Pero bueno, me estoy desvíando al terreno del ladrillo, y tampoco quería. Volviendo a las consultoras. Pues ya sabemos todos lo que hay, y de qué va el negocio, y es lo que hay. Los tiempos buenos de vender hierro pasaron, y ahora toca vender carne que sigue dando dinerillo. Puedes vender carne de cerdo, puedes vender carne de ternera, o de buey, o dar cerdo por ternera que es más rentable aún. Sea como sea, el negocio es a corto plazo, ningún secreto por aquí.

Me preguntaba Julio que como era la cosa en Irlanda. Que si las grandes consultoras se ganaban todos los contratos como pasa en España. A lo que yo respondo con un no. O al menos esa ha sido mi percepción a raiz de vivir ahí y leer las noticias. La primera razón por la que digo no es porque en Irlanda apenas hay consultoras. Te llegan los dedos de la mano para contarlas. Cierto es que cuando se abren contratos específicos para implementaciones concretas, sí que acuden las consultoras proporcionando gente; y cierto es también que ahí están todas las empresas grandes como las IBM, HP, Oracle, etc. compitiendo a gran escala. Pero también es cierto que cuando los gobiernos necesitan un producto, tienden mucho más a contratar productos de software realizado por empresas autóctonas que buscar, que a buscar una empresa que le haga ese mismo producto y que se quedará ahí criando malvas por los siglos de los siglos. Y es que esto tan simple y de perogrullo, parece que por aquí no lo entendemos. Y que nuestros gobiernos cuando toca hacer algo, prefiere hacerlo 17 veces, y pagar 17 contratos a 17 consultoras diferentes, que hacero una vez. Y eso, me temo que no va a cambiar, y también sería otro tema de discusión.

Por otra parte, yo estuve trabajando en Irlanda en tres empresas diferentes. Las tres irlandesas. Las tres startups que habían ganado contratos importantes con bancos extranjeros y se encontraban en su momento más dulce. Todas ellas recibieron varios millones de euros del gobierno en forma de grants para expandir su negocio. La última, 16 millones de euros, hace sólo unos meses, en plena recesión. ¿Alguna noticia de inversión similar en una empresa de software española?

Hace unos días salieron varios reportajes en La Voz de Galicia sobre lo mal que está Irlanda, lo malas que son sus infraestructuras, y lo que han desperdiciado el dinero. Pues mira, sí, han desperdiciado el dinero, y sus infraestructuras son penosas, pero yo envidio su tejido tecnológico, y yo envidio que cualquier pequeña startup pueda plantarse en Silicon Valley, en Tokyo o en Sydney, vender sus productos sin ningún problema y generar riqueza para su pais.

¿Soluciones? En mi opinión son tan simples como complejas de realizar en este el país del cachondeo:

  • Modificar el modelo de negocio de las consultoras: Y aquí no se trata sólo de pedirles a las consultoras y resto de empresas que cobren menos, y que inviertan en I+D para generar productos exportables. Porque sólo con buenas palabras, las cuentas no salen. Es fácil pedirle a una empresa que cree software, pero por ahora, a falta de que se inventen los robots programadores, la gente necesita comer. Todos tienen que poner su grano de arena.

    Hay que buscar fórmulas más creativas en los contratos. Si una consultora o cualquier otra empresa hace un proyecto para el estado, no tiene sentido que el estado se quede con toda la propiedad intelectual y que ese software quede condenado al ostracismo. Porque eso no genera ninguna riqueza a largo plazo y sí genera enormes costes. Quizás por ejemplo la propiedad se pueda compartir y el estado ser accionista de ese producto poniendo dinero para facilitar el esfuerzo de exportación comercial del mismo, no sé, es una idea. Hay montones de posibilidades, sólo hay que escapar de esa mentalidad de "firma el contrato y corre" que existe ahora mismo.

  • Inversión: En línea de la solución anterior, y ya centrándose en las ayudas, no puede ser que el dinero del gobierno vaya para lo de siempre, que si telefónicas, endesas, ayuda a bancos, ayuda a constructores, etc. No puede ser que el gobierno sólo invierta en proyectos 100% seguros y con muchos años de negocio. Esto, lo comentaba muy sabiamente José Ramón García en el primer iniciador de La Coruña. No puede ser que tengamos esquemas de VC que no arriesguen nada. Lo dicho antes, en Irlanda habrá también mucho ladrillo y poca infraestructura, pero si hay que soltar 16 millones de euros en un proyecto prometedor, se sueltan.

  • Diversificar: Como comenta Álvaro Sánchez-Mariscal, no puede ser que sólo las consultoras o empresas grandes con enorme facturación puedan ganar los concursos públicos. Esto estrangula y anula por completo cualquier posible atisbo de tejido empresarial, ya sea local, autónomico o estatal, y obviamente a largo plazo no ayuda a absolutamente nadie.



Puede que haya más soluciones, pero para mi estas tres son las más importantes. Sin estos pilares básicos, no hay nada que hacer. Seguiremos a la cola tecnológica mundial.

martes, mayo 19, 2009

Carlos Barrabés: El mundo no es para estudiar, es para probar.

martes, mayo 19, 2009 por Martín


Hoy he estado en el evento Día do Emprendedor en Santiago de Compostela, que ha sido bastante interesante. La charla que más me ha gustado ha sido sin lugar a dudas la de Carlos Barrabés de barrabes.com, caso de éxito en Internet notable y modelo de emprendedor donde los haya.

La conferencia fue más bien una charla por el tono ameno de este hombre que rezumaba sencillez al tiempo que sabiduría, y si no, tomad nota de alguos de sus consejos:


  • El mundo es para probar, no para estudiar. Todo va demasiado deprisa. Puedes pasarte dos años estudiando algo, y cuando lo quieras probar, ya se te habrán adelantado diez. Hay que dejarse de tanta teoría y más práctica. Probar, probar y probar.

  • Si vas por la calle ver el éxito es inmediato, ahi donde hay cola son la leche.

  • Observación. Antes de empezar barrabés.com, el y su hermano se pasaron 6 meses anotando matrículas y viendo lo que hacían en la montaña. Al cabo de ese tiempo llegaron a la conclusión de que la gente no iba a la nieve como todo el mundo pensaba, la mayoría se iba simplemente a la montaña.

  • Favorecer a los hiperusuarios. Los early adopters. Los que más te ayudarán y te darán feedback. Convertir la experiencia del cliente en una experienca diferencial.

  • Buscar el ser tendencia. Eso es lo más importante, porque si eres tendencia hay cosas como la publicidad que de inmediato pasan a tener coste cero.

  • O molas, o eres barato. ¿Ser barato para una pyme? Olvidaros. Es muy difícil ser una low cost.

  • El mundo ya no es para innovar en las empresas. Se va demasiado rápido. Ahora mismo la gente que ha hehco dinero es la que ha comprado e integrado ideas de otros. Gente como Danone, Google, Toyota... Hoy en día si tienes una idea disruptiva, te acabarán comprando. Para una empresa siempre es mejor comprar que intentar hacerlo ellos todo.



Que obvio suena todo cuando vienen de gente tan experta. Buenisima charla.

miércoles, abril 22, 2009

Cinco cosas malas de ser contractor

miércoles, abril 22, 2009 por Martín


El anterior post "Cinco cosas buenas de ser contractor" tuvo bastante buena acogida. Así que es hora de bajar a todo el que estaba pensando en hacerse contractor a la tierra y hablar sobre las cosas malas de trabajar por tu cuenta, que haberlas hailas.


  • Inestabilidad laboral: Si buscas estabilidad laboral, entonces ser contractor no es lo tuyo. Olvídate de ello inmediatamente. Los contratos normalmente son a corto plazo, tres o seis meses, como mucho un año. Una vez terminado el contrato puede que continues o puede que no, dependiendo claro de muchas otras circunstancias.

    Es raro que un contract esté en una empresa más de un par de años. Lo natural es que su andanza termine tras varios meses, ya que o bien el proyecto ha terminado, o su tarea ha terminado, o simplemente porque la empresa cree que es el momento de que decida si quiere ser permanente o ir a otra parte. Aunque ojo, hay excepciones. Yo he conocido casos de personas con hasta diez años de contractors en el mismo lugar.

    Hay muchas empresas que tras tener a contractors varios meses en plantilla, intentan reconvertirlos a permanentes ofreciéndoles mejores puestos. Normalmente esto sucede cuando la empresa tiene mucho interés, pero no quiere tener contractors muchos años, ya que en tal caso el resto de trabajadores podrían empezar a considerar el por qué ellos no son contractors.

    En resumen, que hoy estás aquí y mañana estás a treinta quilómetros en otra empresa. Esa es la vida del contractor y no todo el mundo está preparado para ello. Hay gente a la que hacer esto le gusta, lo ve como cambiar, aprender cosas nuevas, menos monótono, etc. Pero otras personas prefieren tener tranquilidad en un sitio y dedicarse más a progresar. Si eres de estos últimos, mejor no ser contractor.

  • Los primeros en caer: Si hay despidos, los contractors serán los primeros en irse. Es natural por varias razones, ya que primero suelen ser recursos más caros; segundo, no cuentan para las cifras de despidos de la empresa; y tercero porque si el resto de empleados permanentes ven que los despiden a ellos y que los contractors se quedan, bajaría la moral considerablemente.

    Si eres contractor y ves que no hay señales de renovación o que en la empresa se empieza a rumorear que hay despidos, entonces lo mejor es que pongas a funcionar la maquinaria de encontrar trabajo. No vale eso de esperar a la última semana, porque normalmente a un contractor le lleva más tiempo encontrar un trabajo que a alguien que busque un puesto permanente.

    La demanda de contractors es mucho menor que la de empleados fijos, así que hay bastante competencia por los puestos que van saliendo. Esto hace que si pierdes tu trabajo quizás pasen varios meses hasta que encuentres uno nuevo. Es por eso importante el comenzar a buscar pronto, quizás con un mes de adelanto, si no se ve ningún progreso en tu contrato actual. Si tras pasadas unas semanas tu actual cliente te ofrece renovar, pues bueno en el peor de los casos tendrás dos trabajos donde elegir.

  • Difícil evolucionar profesionalmente: Hay mucha gente que le gusta ascender. Ir evolucionando. Ahora soy junior, ahora soy senior, ahora soy gerente, ahora soy presidente. Si ese es tu perfil, lo cual es perfectamente lícito, entonces olvídate de ser contractor, porque los trabajadores independientes no ascienden. Para algo son independientes :)

    Un contractor puede estar en el mismo puesto durante meses o años y ver como otros compañeros, quizás menos aptos que él, van consiguiendo puestos con más nombre y avanzando en la empresa. Esto es lo normal, y una empresa cuando contrata a un contractor no considera que lo tenga que mover a un puesto mejor pasado un determinado tiempo.

    Aunque ojo, eso no quiere decir que el contractor no progrese laboralmente. Conforme pasan los años puedes incrementar tu salario, o simplemente aplicar a puestos diferentes para aprender otras cosas. Aunque si por ejemplo eres un programador y quieres trabajar como Jefe de Proyecto pues tendrás que convencer a tu cliente de que puedes hacer esa labor.


  • Marrones!: Estaba pensando en llamar a esta desventaja "retos profesionales", o algo así, pero voy a ser más directo: marrones. Esto no es algo generalizado, yo he tenido que trabajar en auténticos marronazos y en proyectos que empezaban desde cero.

    Pero es importante que el contractor tenga claro que su trabajo no tiene necesariamente que ser divertido, y debe estar preparado para todo, tanto para pasárselo bien diseñando sistemas maravillosos, como para pasarse largas tardes aburridas haciendo mantenimientos.

    Esto depende mucho de la empresa. Hay empresas que buscan expertos y que intentarán aprovechar al máximo lo que estas personas puedan aportar, ya que teóricamente se trata de recursos caros. Pero por otra parte, otras muchas empresas buscan contractors para hacer tareas que su personal no quiere/puede realizar. Esto pueden ser tareas aburridas, corrección de errores, etc.

    Las tareas también pueden cambiar. Lo que al principio puede parecer un buen trabajo después se puede volver un infierno en cuestión de segundos. Recuerdo uno que he tenido en el que comencé haciendo un sistema muy interesante, pero que lamentablemente el proyecto se canceló por problemas internos de la compañía. El último mes lo pasé haciendo perl mientras buscaba otro empleo. Y eso no fue divertido :)

    Y por supuesto, una de las razones más comunes para contractar contractors es porque los proyectos están naufragando. Es decir, que desde un principio entras en el marrón, quizás con otros diez contractors para salvar ese proyecto que nunca se salvará (porque ya sabemos que eso de salvar proyectos a base de contratar más y más gente no funciona, ¿no?). La mejor forma de estrenarse de contractor, proyecto en peligro y con horas extras a mansalva :)

  • Aislamiento de la empresa: Esto también depende de la empresa, pero lo más normal es que el contractor no se integre dentro de la mecánica normal de trabajo. Es decir, que si hay reuniones internas es posible que el contractor no esté invitado; que si hay que pensar en funcionalidades futuras, diseños, arquitecturas, etc. el contractor tampoco tenga palabra sobre ello, etc.

    Yo estado en empresas en las que los contractors tenían voz y voto, y en otras en las que no lo tenían. Sea como sea, como contractor tienes que aceptarlo. A fin de cuentas es normal que algunas empresas intenten proteger ciertas cosas, aunque al final cualquier empleado podría también crear algo por su cuenta y empezar a competir.

    Respecto a la vida en la empresa, nuevamente y dependiendo de donde se esté trabajando, puede que te integren más o menos. Si de pronto un día se van de cena a un casino pagado por el club de ocio, pues puede que no estés invitado a no ser que pagues un extra; si un fin de semana toca viajecito a hacer surf, más de lo mismo; ¿Cena de Navidad? Pues igual. A fin de cuentas, un contractor es una empresa en si mismo y puede pagarse estas cosas si lo desea.



Pues nada, espero que os haya sido útil. Tanto este como el anterior post resumen lo que he ido percibiendo durante estos meses. Pero ni que decir tiene que esto son sólo mis opiniones personales, y quizás alguno de vosotros tenga algo más que decir. Así que los comentarios son más que bienvenidos.

Después de leer esto, ¿Qué os parece?, ¿Vale realmente la pena meterse en este mundo?

martes, abril 07, 2009

Cinco cosas buenas de ser contractor

martes, abril 07, 2009 por Martín


Mi época como contractor parece que va llegando a su fin. No he mantenido muy al día el blog debido a la gran cantidad de trabajo que he tenido los últimos meses pero iré actualizando sobre esto en los próximos días. El caso es que hace unos meses que he cumplido un año como contractor.

Han sido doce meses muy emocionantes en los que he trabajado para dos compañías diferentes, curiosamente ambas dentro del mundo de los pagos o transacciones bancarias. La primera compañía se dedica a los pagos online mientras que la segunda se dedica a la implantación de productos de gestión de transacciones compatibles con el estandar SEPA. En fin, que eso no viene mucho a cuento. El motivo de este post es intentar expresar lo que en mi experiencia han sido las mejores cosas de ser contractor, por si alguno de vosotros está pensando en un cambio. Ahí vamos:


  • Dinero: Decir lo contrario sería ser hipócrita. Un contractor normalmente está en una compañía un corto espacio de tiempo, pueden ser tres meses, seis meses, un año, dos años, o incluso en algunos casos incluso más, pero esto ya no es lo normal. Esto descarta el evolucionar profesionalmente en la empresa. Y si lo que buscas no es una carrera laboral en la empresa entonces lo único que queda es el dinero.

    Un contractor gana bastante más dinero que una persona con el mismo trabajo pero con contrato permanente. Aquí estaríamos hablando de ganar el doble, el triple, o incluso más. Si le echáis un vistazo a cualquier informe de salarios para contractors en Irlanda o UK la diferencia salta a la vista.

    Especialmente si vas a vivir al extranjero únicamente por la experiencia y tienes pensado volver, el ser contractor es una opción muy a tener en cuenta.

  • Experiencia: El ser contractor te permite hacer algo que está muy mal visto en otro caso, y que es el trabajar en múltiples empresas a lo largo de un corto espacio de tiempo. De hecho, no es sólo que te lo permita, sino que en muchos casos no te queda más opción porque los contratos pueden ser de duración muy corta.

    No a todo el mundo le gusta estar cambiando continuamente de empresa, pero por otra parte esto te permite descubrir nuevas formas de trabajar, nuevas tecnologías, nuevas arquitecturas, trabajar en nuevos sectores en los que nunca habías trabajado, ampliar enormemente tu currículum, y por supuesto el hacer nuevos contactos y amistades.

  • Impuestos: Volviendo a lo importante, y dependiendo de como te establezcas como contractor (autónomo, trabajar para una umbrella company, o tener tu propia empresa) pues podrás ahorrar más o menos en impuestos, pero por lo general ahorrarás más dinero que si fueras permanente. Lo normal es que recibas dietas por día trabajado, que recibas compensación por el gas, la electricidad o incluso el alquiler de tu casa que se considera como tu oficina, que puedas pasar gastos de cosas que necesites comprarte como ordenadores, libros, etc. Todo eso se aplica sobre tu sueldo antes de impuestos por lo que te saldrá mucho más barato de lo normal.

    Ojo aquí con las empresas paragüas que te ofrecen contratarte desde su sede en algún paraiso fiscal y que así obtendrás el 90% de tu sueldo bruto. Esto es totalmente cierto, pero son operativas que buscan agujeros en la ley, y te puede salir bien o te puede salir mal. A mi, por ejemplo, me ofrecieron establecerme en la Isla de Man y les dije que ni loco. Un ex-compañero mio sin embargo estaba con su empresa en la Isla de Man y tan contento, cuando lo volví a ver hace unos meses me contó que la "Hacienda" irlandesa le había ido detrás y que lo había pasado bastante mal, y que desde esas cambió la forma de contratar. Recordar que os digan lo que os digan, puede que su operativa sea legal, pero a efectos prácticos vosotros estáis evadiendo impuestos. Os puede salir bien, o mal.

  • Horarios y horas extra: Un poco triste que sea así pero el horario y condiciones de trabajo de un contractor están claramante especificadas en su contrato. X euros al día o a la hora durante Y horas, y punto. Eso es lo que se trabaja y nada más. En caso de tener horas extras, pues tu contrato especificará (si no lo hace deberías mirarlo) el precio de la hora extra.

    Así que bueno, en el caso de un contractor no debería existir eso de trabajar doce horas y cobrar ocho, o pasarse los fines de semana porque corre prisa y no cobrar nada. En muchos casos ni te llaman para hacer fines de semana o ni consideran que te vayas a quedar. Y cuando no se cumple esto, pues en muchos casos al contractor le viene bien porque claro, es más dinero.


  • Oportunidades: Esto viene un poco al hilo de la segunda razón expuesta anteriormente. Como consecuencia de la cantidad de contactos que haces, y de que la empresa te ve como otra empresa en lugar de como un empleado más, es posible que tengas nuevas ofertas laborales. Muchas veces es más sencillo por ejemplo el ir a trabajar desde casa ya que las empresas lo ven simplemente como una operación de offshoring.

    También, si eres bueno y tienes la suerte de estar en el sitio adecuado, pues puede que tengas la oportunidad de ampliar tu negocio. Quizás te pregunten si conoces más gente buena y puedas montar una pequeña empresa. Algo parecido he visto por ejemplo en una de las empresas donde he trabajado, donde dos de los contractors montaron una empresa y ahora tienen más de diez personas en Polonia desarrollando.

    Vamos, que es mucho más sencillo que aparezcan oportunidades cuando eres un proveedor de servicios más, que cuando eres un empleado más en la empresa. Con un contractor pueden tratar de igual a igual. Con un empleado hay que ser mucho más cuidadoso, ya que lo que hagan se comparará con el resto de empleados.



Y resumiendo estás serían mis cinco razones más importantes por las que en mi opinión vale la pena hacerse contractor. Pero no todo lo que reluce es oro, y en breve publicaré un post con cinco cosas malas de ser contractor. Y a partir de ahí, ya depende de cada uno. Hay gente a la que le gusta; hay gente a la que no; hay gente que simplemente piensa en eso como un período estacionario.

Sea lo que sea, si te animas a hacerte contractor, piensa que no tienes nada que perder y que como poco será una experiencia, ya que la forma de trabajar es totalmente diferente y se aprende muchísimo, para bien o para mal.

Imagen via Shmoomeema@Flickr.

martes, enero 13, 2009

Adoptando metodologías ágiles en un entorno hostil

martes, enero 13, 2009 por Martín

Ayer estuve viendo una presentación de esas que te enganchan. Se trata de Agile Tales de Claudio Perrone que podéis encontrar unas líneas más abajo. Es de esas presentaciones en las que tienes pocas esperanzas puestas pero que en los cinco primeros minutos te enganchan y después quieres saber como termina.

Claudio cuenta en los 50 minutos de la charla la historia de un proyecto "difícil", de esos que hay por ahí. Uno de esos proyectos que llevan años ejecutándose pero del que nunca ha salido ningún resultado. Un proyecto tóxico, en el que alguna compañía ya ha desaparecido en el intento de sacarlo adelante. Pero bueno, eres joven, y todopoderoso. Nadie te puede superar técnicamente. Lo sabes absolutamente todo en tu dominio. Has trabajado muchos años ya, has tenido puestos importantes, eres contractor, en definitiva, un experto. Nadie te puede vencer.




Hasta que claro, llegas a un proyecto como este en donde lo importante no es la capacidad técnica sino la capacidad comunicativa y el carisma. Puñaladas traperas, agendas escondidas, dobles intereses, acomodamiento, hipocresia, sarcasmo, un equipo de desarrolladores absolutamente desmotivado donde el desarrollador más amable te comenta "no eres bienvenido aquí". No parece el entorno más agradable para sacar un proyecto adelante. Seguro que a más de uno le suena.

Pero Claudio lo consiguió, y en esta charla comenta como lo hizo. La base es alterar lo preestablecido. Forzar a los desarrolladores a trabajar en iteraciones pequeñas para que obtengan resultados visibles y aumente la motivación del equipo; forzar al equipo de QA a testear desde el comienzo y a olvidarse de pasar meses preparando docuemntos de pruebas para testear una aplicación que no da visto la luz; acostumbrar a los managers a trabajar con transparencia, a establecer unos objetivos fijos al principio de las iteraciones y respetarlos hasta el final; trabajar duro en las iteraciones para implantar esa inercia en el equipo gracias a la transparencia de los Sprints diarios. Todas estas son algunas de las sugrencias de Claudio que son consecuencias de adoptar una metodología ágil en una empresa anquilosada en procesos obsoletos y abocados al fracaso.



Muy recomendable el escuchar la charla. Aquí tenéis también las transparencias.

jueves, septiembre 25, 2008

Lo que me motiva

jueves, septiembre 25, 2008 por Martín

En Navegapolis, unos de los mejores blogs en lenguaje castellano sobre desarrollo de software Juan escribe unas cuantas citas en uno de sus posts sobre el libro el mito de la motivación sobre los resultados contraproducentes que pueden tener algunas técnicas de motivación.

Personalmente no hay nada que menos me motive que un bonus económico. Me hace sentir realmente mal. Es como si de principio entrases a trabajar con presunción de no-profesionalidad. Como si desde un principio te pusieran una zanahoria delante para que no se te olvide que a final o principios de años tendrás el premio que te mereces, por tu esfuerzo y dedicación. Y eso dejando a un lado la incertidumbre de si cobrarás ese tan ansiado "bonus" o no, ya se sabe, la crisis, la recesión, la falta de ventas, la competencia en el mercado, la dificultad del momento actual.



Claro que puede ser peor. A un buen amigo mio que está trabajando aquí en una cadena de supermercados al llegar la navidad le hicieron un regalito. Aquí en Irlanda, no se llevan las cestas de navidad, no os creáis, así que este era un detallazo que se le ocurrió a los jefes para motivar al personal. El regalo era un paquetito que si no recuerdo mal contenía unos Christmas Crackers, una corona de dorada de papel, dos manzanas gala con merry christmas grabado y una botella de pepsi de medio litro, de las doradas. Tan dorada que mi amigo al principio y de lejos se había pensado que era una botella. Imaginaros la motivación con la que salió :-) Aún nos reímos con ella hoy.

El caso es que los dos coincidíamos más o menos con lo que nos podía motivar. Y esto es lo que me motiva a mi:

  • Una compañía que te deje trabajar tranquilo. Sin mucha burocracia, reuniones, control, timesheets, etc. Una compañía que confie en ti.

  • Un proyecto con futuro; que presente retos para la compañía y todos los que forma; que te apetezca ir cada día a intentar solucionar nuevos problemas.

  • Un conjunto de tecnologías actuales y pragmáticas. Que no se hayan escogido por escoger. Que permitan aprender y disfrutar de tu profesión al tiempo que te faciliten tu trabajo.

  • Directivos, managers, responsables y arquitectos profesionales y con capacidad. Que impongan respeto y que de gusto trabajar con ellos por todo lo que se puede aprender.

  • Tener un grupo diverso de trabajo. Tener compañeros de los que se pueda aprender y tener compañeros a los que les puedas ayudar a aprender lo que tú ya sabes.

  • Tener un buen ambiente de trabajo.

  • Estar en una empresa que te ayude a mejorar tus conocimientos; que te permita pasar tiempo leyendo artículos o videos de conferencias; que no tenga problemas en subvencionarte la asistencia a cursos o eventos.

  • Un buen club social que no se limite a salir de pintas todos los jueves por la noche.

  • y por supuesto... las partidas de poker a la hora de comer de los mártes y los jueves.


La verdad es que casi todas de estas condiciones se cumplen en mi empresa actual y es que las cosas menores como una simple partida de poker pueden tener un efecto mucho más motivador que cualquier bonus.

Imagen by Simon Clayson@Flickr .

martes, septiembre 09, 2008

Un pequeño problema informático de esos que valen millones

martes, septiembre 09, 2008 por Martín


Hoy me voya desviar un poco de la temática habitual, aunque me mantendré de cierto modo dentro del mundo del software. Una de mis aficiones es la economía. Me encanta seguir los mercados, las noticias, las inversiones y todas estas cosas.

El Lunes fue uno de esos días emocionantes en las bolsas. Las empresas financieras americanas Freddie Mac y Fannie Mae se habían desplomado en la bolsa en la pasada sesión y el gobierno de los Estados Unidos había acudido a su salvación. El Lunes se esperaba una carrera de compras como no se había vivido en meses (o años). Aún así, no fue un día muy feliz en el London Stock Exchange ya que fueron incapaces de operar durante prácticamente toda la sesión.

En la prensa se comenta que la caida duró unas siete horas, y que muchos traders se vieron forzados a moverse a sistemas de la competencia para intentar operar. Wow, siete horas de inactividad en la bolsa valen miles de millones. Parece ser que todo se debió a un fallo informático dentro de un aplicativo llamado Infolect que es el sistema de envio de datos que utilizan.

En ZDNet tienen un artículo interesante que comenta más detalles sobre este sistema. Y en CIO comentan que es un sistema lanzado hace un par de años (no sé en donde leí que lo habían actualizado este verano) basado en .NET, SQL Server y desplegado en más de 100 servidores Proliant Intel 32 bits.

Parece que hace poco que LSE ha encontrado verdadera competencia en dos exchanges alternativos, Chi-X y Turquoise que se animaron a comentar el fallo y no dudaron en recomendar a todo el mundo migrar a sus redes más modernas y más baratas.

La verdad es que independientemente de si el fallo estaba en el software, en los servidores, en la red, en lo que sea, lo cierto es que este tipo de noticias son esas que leeremos en años en los libros ya que te demuestra como pequeños fallos, o sistemas no preparados para picos de carga enormes pueden generar perdidas millonarias al tiempo que impactan enormemente en la imagen de las compañías y proporcionan jugoas oportunidades a la competencia para captar a tus clientes.

A ver si algun publicación online nos desvela un poco más sobre este fallo.

lunes, septiembre 08, 2008

El Arquitecto de Software en versión española.

lunes, septiembre 08, 2008 por Martín

En muchos países europeos, US, Japón y otros, la figura de Arquitecto de Software está realmente valorada. Ser arquitecto de software es el paso natural para muchos desarrolladores senior, y requiere sobre todo experiencia y buenas capacidades de análisis, raciocionio y abstracción. Coding de Architecture es uno de los mejores blogs existentes sobre el trabajo de Arquitecto de Software y tiene varias entradas donde se define el scope de un arquitecto o el perfil que debería tener un arquitecto.

Entre las tareas de un Arquitecto de Software destacarían:

  • Definición de la arquitectura.

  • Selección del software.

  • Selección de la infraestructura.

  • Requisitos no funcionales.

  • Liderazgo.

  • Mentoring.

  • Metodología de los proyectos.

  • Proceso de desarrollo.

  • Prácticas y estándares.

  • Análisis de las tendencias en desarrollo de software.

  • Aporte de experiencia.

  • Participar en el desarrollo.



Esta lista está recogida en este fichero PDF y es probablemente el último de los puntos que he puesto el que causa más polémica, aunque bueno más o menos está aceptado que es un bueno que un arquitecto participe de alguna forma en el desarrollo, aunque el dedicar más del 30% de su tiempo a dichas tareas indicaría que hay algo que está iendo mal.

Viendo como trabajan las empresas en el extranjero y sobre todo el reconocimiento que se le tiene a arquitectos y desarrolladores senior, a uno no le deja de sorprender el encontrarse ofertas en España buscando Arquitectos de Software con experiencia de al menos un año programando en J2EE. O mismamente la siguiente lista de requisitos para un Arquitecto J2EE en Valencia:

Descripción de la oferta
Buscamos un arquitecto en las tecnologías Java/J2EE, para proyectos de primer orden y pioneros en el ámbito de desarrollo de software. El candidato seleccionado se responsabilizará de:
-Captura y análisis de requisitos técnicos y de negocio
- Análisis y diseño funcional y técnico de proyectos de desarrollo de software
- Definición y ejecución de planes de pruebas
- Desarrollo Java/J2EE
- Realización de la documentación técnica asociada al proyecto
- Impartición de formación a usuarios y técnicos implicados en el ámbito del proyecto


Es decir en este caso Arquitecto = consultor, business analyst, tester, programador, documentador y formador. En fin, que cualquier parecido con la realidad del mundo exterior a nuestro peculiar país es mera coincidencia. Aunque está claro que en muchas empresas sí se reconocen los puestos de desarrollador senior y arquitectos, lo cierto es que todavía son la mayoría las que desconocen completamente lo que es el mundo del desarrollo de software, sus perfiles, el trabajo que se debe realizar, los roles y responsabilidades, etc. El arquitecto de software no deja ser "el que controla" o "el que nos saca las castañas del fuego".

Así nos va.

martes, julio 08, 2008

¿Es Google el nuevo malo de la película?

martes, julio 08, 2008 por Martín


En este blog hay bastantes entradas sobre Google, probablemente como en la mayoría de blogs sobre informática. Esta compañía ha aportado tanto a la informática y es tan, tan, tan poderosa que es casi imposible el dejar de hablar de ella. Pero como suele pasar en estas compañías, a medida que van ganando poder, van perdiendo simpatizantes, y Google no es una excepción.

Greg Linden comenta en su blog que lo mismo pasaba con Amazon cuando él trabajaba allí, allá por el 2000, y muestra diferentes referencias a artículos de prensa atacando a Google, todos bastante recientes, incluyendo uno de hace un par de días donde en el New York Times presentan a Google como una especie de tirano más preocupado en ahorrar costes (¿qué raro en una empresa, no?) que de mantener los actuales beneficios de sus empleados.

El caso es que normalmente esto no me llamaría la atención, si no fuese que justamente este fin de semana, cuarioseando en boards.ie (que son unos foros realmente importantes en Irlanda, hasta el punto de ser referenciados en la radio o de que profesionales de diferentes tipos ofrecen consultas grauitas en los mismos ) me encontré un hilo sobre trabajo donde gente que trabaja en Google da sus impresiones, tanto positivas como negativas, aunque parece que predominan estas últimas. Como sabéis, Google tiene los cuarteles generales en Europa localizados en Dublin

Esta opinión es realmente interesante, y muestra (si asumimos que es real) las fuertes diferencias entre puestos técnicos y no técnicos en la compañía. Otros hilos hablan de la enorme competencia dentro de la empresa, la importancia de relacionarse, y en resumen muchas cosas lejos de la imagen idealizada que pudiese tener mucha gente de la compañía. Pero ojo, no os quedéis sólo con lo malo porque también hay opiniones buenas, y los beneficios que se obtienen trabajando en Google son únicos (aunque por ahora no sea más en forma de acciones).

¿Qué os parece a vosotros? "An average large company", ¿como comentan por ahí? Sea como sea seguro que merece la pena trabajar ahí aunque sólo sea un tiempo para aprender de la experiencia.

viernes, junio 27, 2008

IONA

viernes, junio 27, 2008 por Martín


IONA (Technologies) es una de esas compañías que ha marcado una era. Surgida del Trinity College en Dublin como startup allá por el 1991, es una de esas compañías que a los de mi época comenzaba a sonarnos un poquillo cuando andábamos por la Universidad, y que al salir y descubrir un poco el mundo exterior y empezar a leer las revistillas, y las páginas web, pues descubrías que era la empresa donde más se innovaba en el momento. La empresa donde cualquier ingeniero de software le gustaría trabajar, la empresa que acaparabalos titulares de los TheServerSide de la época.

En Answers.com tienen una biografía excepcional de la compañía. Su mayor éxito fue Orbix ORB. Top ventas donde los haya y que todavía se vende. La primera implementación comercial de un estándar, que empezaba a sonar en la época, llamado CORBA. Esa innovación, el ser los primeros en adoptar un estándar avalado por HP, IBM, Sun, Apple, y todo el resto de miembros del OMG, les valió el convertirse en la empresa del momento, y una de las de mayor éxito de la década de los 90.

Un Object Request Broker, nada más y nada menos, lo que ahora mirado desde lejos parece lo más sencillo del mundo, pero que en aquella época era algo que daba vértigo sólo de pensarlo. ¡O al menos a mi me lo daba en las prácticas de CORBA! Leyendo la biografía es sorprendente todo lo que crearon durante esa época. OrbixTalk lo que suena a los modernos Event Driven Servers que nos venden hoy en día, Orbix Transaction Monitor, Orbix MX (multimedia, video streaming, ...), Orbix COMet (para crear aplicaciones Windows y ejecutarlas en otros sistemas operativos), partnetship con Visual Cafe (¿quién se acuerda de ese IDE?), Homebase EJB, ... y otro montón de productos que supongo que pasaron con más pena que gloria.

Según comentan los irlandeses, y en general todo el sector, el golpe del 2000 fue demasiado para ellos. Nunca consiguieron levantar cabeza al nivel de antes (5ª compañía en el Nasdaq 1997), y muchos de los miembros aprovecharon para canjear las acciones y comprarse unas buenas casitas como cuenta Joe Drumgoole en su blog. Como también comenta, el gran fallo es que nunca supieron realmente como unirse al carro de Java y EJB, y probablemente hayan lamentado el no comprar WebLogic en su momento si son ciertos los rumores.

En los últimos años la esperanza de IONA ha sido el Open Source, pero siempre dando esa impresión de no tener un rumbo fijo. La compra de C24 y ServiceMix parece haber enfocado su negocio en el mundo de la integración, interoperabilidad entre estándares y el Open Source. Tiene productos interesantes (casualmente esta semana he estado en un seminario sobre uno de ellos), pero siguen dando exactamente esa impresión de no saber realmente donde está su negocio.

Esta semana IONA ha sido comprada por Progress, por un precio de 163 millones de dólares, o lo que es lo mismo sobre 4 dólares por acción, en lo que claramente es una operación para deshacerse de la compañía. Un precio bastante miserable para una compañía que en el 1997 valía 1 billón de dólares. Mucho me temo que en la oficina estarán ya pensando en cuando caerán los despidos. Malos tiempos para Irlanda que pierde a lo que ha sido la compañía de software más importante que ha salido de la isla.