El gran problema de las StartUps españolas es la Tecnología

3 julio, 2012

Gestión, Tecnología

“Startup busca programador fuera de serie que quiera hacer historia”

Hoy en día es fácil encontrar anuncios de este tipo de Startups que están buscando programadores y que además se quejan de que no hay o de que piden mucho dinero, pero… ¿de verdad buscan un programador?

La verdad no tengo ni idea como hemos pasado de tener unas jerarquias y puestos de trabajo más o menos bien definidos (programador, analista, consultor, jefe de proyecto, etc…) a llamarlo todo “programador”.

Esta claro que la “vieja escuela” de las consultoras donde había más jefes que indios quedó obsoleta, dando paso a equipos multidisciplinares, desarrollo ágil, etc… pero por el camino, al menos en España se perdió mucho, muchísimo, a acabamos dando la misma clasificación laboral a un estudiante de un módulo de formación profesional que aun ingeniero experto en bases de datos…. todos son programadores……

Por eso, cuando una Startup busca un programador, tiene todas las papeletas de literalmente “cagarla”, por que la cosa no es tan sencilla como poner un grupo de programadores y esperar que aquello se transforme en un equipo de desarrollo. Es como intentar construir una casa con albañiles, sin aparejadores, sin arquitectos, sin fontaneros, sin alicatadores, etc… pues eso están haciendo.

Lo que me asombra mucho, es que grandes Startups españolas que acabaron vendiéndose a multinacionales, no tenian un equipo de desarrollo adecuado, tenían “programadores”, un problema más común de lo que parece.

Realmente no hay que inventarse nada, hay mucha literatura, mucha experiencia en el sector para crear equipos de trabajo, pero esa experiencia, ahora mismo está en las grandes consultoras, precisamente esas empresas que intentan evitar los recién titulados, el mundo al revés.

Hablemos de 1999

Creo que fui el jefe de proyectos más joven de mi empresa, con 25 años ya estaba a cargo de varios proyectos, pero hubo uno que supuso un gran reto para mi. Me encargaron que diseñara la arquitectura web para una empresa con millones de clientes, pero además de tener que diseñar la arquitectura, tenía que crear los equipos de desarrollo y lidiar con Microsoft, el famoso “DLL hell” y unos servidores que por entonces tenían 32mb de RAM y con un Pentium II como CPU.

Si hoy en día, le das a un “programador” un proyecto como aquél, se hubieran puesto a programar, y programar, como hicieron otras empresas que habían contratado… todas fracasaron.

Lo primero que hicimos fue definir una arquitectura, creamos componentes para la generación de html, acceso a base de datos, informes, seguridad, etc… después hicimos pruebas de escalabilidad y rendimiento, para comprobar que todo funcionaba correctamente. Por aquel entonces no había mucho OpenSource que utilizar….

Cuando logramos una arquitectura que funcionó, nos tocó crear los equipos de trabajo, y me puse el reto de crearlos desde cero, desde módulos de FP y recién titulados universitarios.

En este sentido preparé un plan de formación que incluía documentación, ejercicios, clases teóricas, etc… de forma que pudimos crear un equipo de más de 30 personas, donde el 80% eran becarios y estaban rindiendo en dos semanas como si llevaran años en la empresa.

Pero la cosa no acabó ahí, creamos un experto en JavaScript y VBScript, un experto en DHTML y un experto en BBDD, cada vez que había algo más complicado de lo normal, se acudía a los expertos que trabajaban de forma paralela entre todos los proyectos, llegamos a un nivel de perfeccionamiento tan alto que TODAS las SQLs eran revisadas para confirmar su plan de ejecución y el uso correcto de indices, relaciones, etc….

Recuerdo que salimos en varios medios de prensa internacionales por que empezamos a hacer Ajax antes de que existiera, que por entonces Microsoft lo llamó Remote Scripting, que no llegó a funcionar, y nosotros si lo conseguimos. Nuestros componentes acabaron en varios portales de seguros, compra venta de coches, etc…

Nosotros aplicamos la metodología de trabajo Microsoft Solution FrameWork, después empezamos a aplicar CMMi y finalmente la empresa decidió disolver el equipo de trabajo por que éramos demasiado productivos, y en algunas empresas, cuando un equipo es 10 veces mejor que el resto de la empresa, eso no es bueno.

Mi opinión….

Las empresas españolas tienen que aprender mucho de lo que se hacía hace unos años, tienen que empezar a recuperar a gente que sigue atrapada en las consultoras con su sueldo y trabajo “comodo”, tienen que empezar a organizar equipo técnicos de forma adecuada y dejar de buscar a Gurus en la programación que aunque son necesarios, al fin y al cabo… sólo son programadores.

[Actualización 04/07/2012]

Por los comentarios recibidos, me doy cuenta que mucha gente “escucha pajaritos” al ver las ofertas en Google, Facebook, etc… y creen que estas empresas no tienen una organización establecida (todo el mundo es programador).

Pues todo lo contrario, estas empresas tienen una fuerte jerarquía de equipos pero de una forma original, por que cada micro equipo funciona como un equipo de programadores guerrilla, gente excepcional con mucha experiencia y unas cualidades extraordinarias en programación, análisis, redes, etc….

Los programadores que conozco que se presentaron a las pruebas de Google, Facebook, Twitter, etc… “escuchando cantos de sirena” no han pasado las pruebas, seamos humildes, reconozcamos que un sueldo de programador de 100.000€ sea en España o en otro país es para un porcentaje muy bajo de los programadores que conocemos…

, ,

6 Responses to “El gran problema de las StartUps españolas es la Tecnología”

  1. Ivan de la Jara Says:

    Quizá sea porque los ingenieros no tienen ni idea puesto que no tienen experiencia laboral alguna…

    Por otro lado parece irónico buscar un “fuera de serie” que como tal, es lógico que tenga un mínimo de inteligencia y por tanto le interese emprender a el por su propia cuenta… Por lo que contratarlo deja de tener sentido. Por eso los americanos dan stock options y demás… Porque la gente que sabe no es tonta y no se mete en esas jerarquías absurdo-militares…

    La jerarquía de la que comentas, es la de IBM de hace décadas. Eso ya no existe… y ni mucho menos puede enmarcarse en el marco de los emprendedores… Eso es para empresas con traje y corbata que tiene millones de euros para tirar en tonterías como esas…

    Es como pretender hacer algo web decente en windows… o crear un experto en javascript en dos semanas… “solo programadores” :motherofgod: :facepalm:

    Lee algo sobre como trabaja google porque te quedaste anticuado…

    P.D: Siento el lenguaje pero la gente universitaria que se cree superior sin tener ni idea me toca el escroto…

  2. JuanMacias Says:

    Ivan, tu has mirado las ofertas de trabajo de Google?

  3. Rafael Vargas Says:

    @Ivan de la Jara:
    Por lo que yo sé, Google crea “micro-equipos” de tres personas + un program manager (Unit, lo denominan) para un producto o para una funcionalidad de producto. Ahora bien, ¿quién te dice a ti que esos micro-equipos no estén jerarquizados?

    Según el tamaño del equipo en la startup será necesario crear una jerarquía. No todas las startups son de 3-5 personas. En la ingeniería del software es muy recomendable utilizar los métodos probados por la industria en vez de creerse más listo que los demás.

  4. Un Informático cualquiera Says:

    Hola a todos,
    Soy un asiduo lector del blog de Juan y:
    1- No entiendo un comentario como el de Ivan, con ese lenguaje y fondo. Te mereces una respuesta pero veo que Juan es una persona educada y elegante, lo cual aplaudo.
    2- Es muy dificil encontrar alguien como Juan que cuente en su blog el tipo de información que da, al cual le estoy muy muy agradecido.

    Por terminar, Juan, enhorabuena por tu blog!
    Es la primera vez que hago un comentario en el mismo, se ve que determinados comportamientos me encienden 🙂

    Un saludo a todos!

  5. Esteban Says:

    Creo que estos tiempos se buscan estructuras flexibles, porque la tecnología y el mercado cambian muy rápidamente, por eso las cosas no se hacen como antes. Los ciclos son más cortos, ya ni se hacen planes a cinco años vista, sino cada seis meses. Es más importante la rapidez y la innovación que la calidad. La calidad ya se pondrá luego, si es que hace falta.

    Creo que de ahí viene el empeño de las startups de pedir profesionales polivalentes, que “hagan de todo”, y los llaman simplemente “programadores” (o mejor “desarrolladores” o “developers”). Profesionales que además de saber hacer software comprendan también que la finalidad de la empresa es vender, y que la calidad del software es en todo caso un medio para vender, no un fin en sí misma. Profesionales que se autoformen (porque si no se quedan obsoletos) y que tengan iniciativa. Profesionales, en definitiva, que no se ajustan a los cánones tradicionales.

    Las estructuras rígidas y los puestos definidos, aquellos dónde uno puede ser “el entendido en esto”, no casan con los tiempos actuales.

    Son tiempos en que un “developer” que sepa hacer uso de herramientas, frameworks y opensource, y esté al día en nuevas tendencias, aunque no tenga título universitario, es más valioso para muchas empresas que un licenciado orgulloso en ser el experto en su rama pero alejado de las novedades y ciego a las necesidades del mercado (“qué chapuceras son las empresas”, “todo son prisas”).

    Anécdota: hace veinte años un profesor de Universidad me decía en clase que Java era un porquería, que no tendría éxito, que tener que instalar una maquina virtual tan pesada para conseguir ser multiplataforma era una chapuza y una estafa, y decía esto mientras hacia el gesto de darle una patada imaginaria.

    En una operadora de teleco dónde estaba, todos los técnicos estábamos que trinábamos con la empresa porque no buscaba la calidad, sólo ahorrar costos, y pensábamos que de esta forma perderían clientes, y que con el tiempo entrarían en razón y se volvería a la situación de antes. Esa mentalidad era de ingeniero puro que no ve más allá de su puesto: las operadoras luchan ahora por los clientes con precios más que con calidad, pero además reducen costos al mismo tiempo que aumentan la calidad mediante equipos de red más automatizados y menos propensos a averías (y despidiendo así a ingenieros innecesarios).

  6. App McAlons Says:

    Como programador no veo que el problema sea la tecnologia, el problema sigue siendo en que la gestión en muchas ocasiones está en incompetentes directores y jefes intermedios con titulos rocambolescos en ingles que sólo piensan en ganar dinero, rápido y con unos tiempos en la mayoria de ocasiones sin consultar a los programadores o aún consultándoles pasándose por el forro los analisis técnicos.

    El problema son eso, los directivos que en muchas ocasiones no entienden de tecnología y sólo de números y comisiones.

    De otro lado sólo grandes compañias pueden permitirse el lujo de tener un programador php, otro para bases de datos, un maquetador, un diseñador, un analista web, un experto en usabilidad, etc etc, la mayoria de pequeñas empresas tienen programadores que saben un poco de todo.

    Y de otro lado está el problema de la globalización que no has comentado en este artículo. Llega un momento en que los programadores mileuristas pasan a ser costes fijos elevados, acabando la empresa contratando personal externo mucho más barato ( Brasil, Argentina, Marruecos, India,…) asi que el problema ni siquiera es de la tecnología, sino de la globalización.

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies