El artículo se basa en un estudio del profesor Amar Bhide de la Universidad de Columbia en el que se entrevistó con 106 CEOs de compañías tecnológicas. A parte de las diferentes conclusiones del artículo, lo que me ha parecido más interesante son los 7 impedimentos más importantes que se encuentran las subcontratas:
- Tener al cliente lejos: Muy a cuento de las metodologías ágiles, si el cliente está lejos, es difícil ajustarse a sus requisitos (y más aún poder tenerlo onsite)
- Los equipos deben trabajar juntos: Tener equipos de desarrollo en diferentes puntos del mapa hace difícil que se compenetren.
- Gestión de equipos: Coordinar los equipos en multiples lugares y zonas horarias se hace complicado.
- Equipos más pequeños a menudo son más productivos: Así que si la razón de sacar el desarrollo a aun país más barato es tener más desarrolladores, entonces quizás esto no solucione el problema.
- Falta de habilidades:Hay paises en el que por falta de infraestructura no se pueden encontrar determinados perfiles (pone el ejemplo de desarrolladores de juegos en India).
- Problemas con la propiedad intelectual: especialmente al mover software a paises como china.
- Competición por el talento: es fácil que las empresas grandes se lleven a los mejores talentos, así que a las empresas difíciles les es difícil encontrar personal adecuado.
No deja de ser una visión interesante. Personalmente no estoy de acuerdo con algunos de los puntos:
- Los equipos deben trabajar juntos: Pensar esto me parece un poco como vivir en el pasado. Hay ejemplos de sobra de equipos que trabajan en diferentes países con éxito (casi cualquier producto Open Source con fama). La clave es que es algo difícil, y por lo tanto requiere calidad, calidad en todos los equipos de desarrollo. Si dispones de gente capacitada, tanto dará donde estén los unos o los otros, al menos desde el punto de vista de crear software.
- Equipos más pequeños a menudo son más productivos: En esto estoy de acuerdo, pero tampoco le veo mucho la relación con la subcontrata. Está la justificación que he comentado arriba de que no se debería subcontratar por el simple hecho de tener más desarrolladores, pero claro, eso no implica que no puedas tener tu pequeño equipo de fueras de serie en ... España por ejemplo. Claro que entonces tocaría pensar en el resto de puntos, como estar lejos del cliente.
- Falta de habilidades: Efectivamente. Pero también hay países que tienen habilidades que quizás no podamos encontrar donde estamos, y en ese caso igual nos tenemos que mover ahí.
Hace poco hablaba con un amigo de por qué Babelgum una empresa de capital italiano que compite con Joost se ha establecido en Dublin centro, en lugar de desarrollar en Italia que es más barato. Pues investigando un poco me comentaba un amigo que simplemente ha sido porque en Italia no podían encontrar los perfiles adecuados para emprender el proyecto.
¿Alguien se anima a opinar?
comments
7 Respuestas a "7 razones para no subcontratar si eres una pequeña empresa tecnológica americana"20:28
A todo esto añado el comentario de un profesor de la universidad que tuvo reuniones con algunas empresas que se quieren asentar en el parque tecnológico de la ciudad.
Nos comentaba que algunas de las empresas se quejaban de la poca implicación que tenían con ellos, los indios (en este caso) se limitaban a realizar el proyecto y adiós muy buenas, no tenian ese espiritu de colaboración entre empresas.
La verdad es que me sorprendió bastante el argumento, no se si sería una simple estrategia para intentar motivarnos o si por el contrario es realmente así. Sea lo que sea, me sorprendió bastante.
Un saludo.
23:03
Bueno, yo puedo decirte que por lo que yo conozco trabajar con equipos en la India es bastante complicado; y hasta subscribiría las palabras de tu profesor.
Un ex-compañero mio estuvo trabajando en Mumbai, y más o menos me contaba lo mismo. Que había gente buena, pero que era difícil encontrarla (los mejores se van); y que lo peor de todo era sin ninguna duda la falta de organización y control.
0:43
Bueno, mis experiencias personales no son exactamente con la subcontratación pero he vivido alguno de los puntos.
Sobre que los equipos deben trabajar juntos, como dices es muy difícil y se necesita calidad, yo lo viví desde una factoría "deslocalizada" donde el que más experiencia tenía eran unos 6 meses y como se puede suponer las cosas no salieron demasiado bien.
En el tema de la gestión de equipos parece que también había algún problemilla, con gente desasignada durante mucho tiempo.
Lo de la falta de implicación, no es exclusivo de los indios, hay por ahí mucho charcutero que su implicación empieza y acaba cuando toca facturar.
17:45
jeje, ¿equipos mas pequeños son mas productivos? si para un proyecto que se necesiten 15 persona, consigues un pequeño grupo de 5 que hagan lo mismo has conseguido multiplicar por 3.
excepto que nos traiga a alguien que no tengan ni idea del entorno (o de programar), si se añade mas gente al equipo, (a excepción de la fase final), libera trabajo.
todo es cuestión de poner claro los objetivos, en tal caso da igual donde estén los "pogramadores", pero, si no somos capaces de hacer el análisis o dejamos que el cliente cambie a diario, da igual lo buenos que sean nuestros "pogramadores" o el montón de ellos que tengamos
18:26
Bueno, Carlos cada uno opina sobre su experiencia personal. Yo he visto equipos pequeños (ej 15), muy compactos y organizados, de gente muy buena, haciendo el trabajo que antes se suponía que hacian 30 o 40.
Al final la diferencia está en los procesos. Si tienes un equipo de 100 con un proceso demasiado pesado, con demasiados jefes, demasiada burocracia, demasiado papeleo, tanto da las personas que tengan, pasaran la mayor parte de su tiempo sin contribuir al proyecto. Por el contrario con un proceso más ágil un equipo más pequeño va a ser más productivo, simplemente porque tendrá más tiempo de trabajo efectivo.
23:12
si lo pones asi claro, ya lo decia yo.
digamos que tienes a 30 personas y coges a 15 al azar (o a los 15 peores) y me dices que los 15 harán el trabajo antes y con el mismo jefe.
igual es cierto.... pero no me lo creo, eso es como algunos entrenadores de futbol que dicen que con 10 se juega mejor, pero nunca he visto que ninguno que tenga la menos 11 salga con 10.
que 15 muy buenos es mejor que 30 muy malos (o regulares), es en lo que todos estamos de acuerdo, y siempre se dice, no contraten a cascarones de huevo (o no la mayoría), y cuando han contratado a gente buena, no paras de decir, con ese sueldo se nos va a ir en cualquier momento.
un saludo.
23:44
Carlos, sí, estaríamos hablando del viejo concepto de mongolian horde. Por otro lado, está claro que tener un equipo pequeño de superprogrammers tampoco tiene que ser lo más productivo, porque siempre hay que ver como son sus relaciones sociales, como llevan el tener competencia, que va a pasar si se van la mitad, etc.
Para mi lo importante es si el tener mucha gente va a añadir excesiva burocracia. Eso es lo que mata muchos proyectos. Cosas como el tener de repente diez jefes de equipo que se llevan a matar y no se ponen de acuerdo paralizando desarrollos; o el tener a seis arquitectos intentando parecer cada uno el más inteligente y creando arquitectura artística porque total, tenemos 100 desarrolladores...
Publicar un comentario