Cuando tercerizar a otros paises trabajo de desarrollo de Odoo
La idea de este post surgio el día de ayer cuando fui contactado por alguien de una provincia del noroeste que estuvo en los diarios los últimos días gracias a la conducta intachable de sus congresistas. El caso es que este señor pretendía que le prepare un presupuesto, para luego compararlo con unos presupuestos que le habían alcanzado programadores de la India. Viendo que era una mala idea, le indiqué que minimamente el trabajo le iba a costar X$, y que si el número que le habían alcanzado de la India le servía, que vaya con ellos. Y ahí se terminó la conversación.
Y estoy seguro que no voy a hablar más con este señor por varias razones. Creo que la principal es una actitud muy molesta de ver el trabajo de un programador como una actividad barata. Que es un problema que tienen muchos que se acercan a Odoo. Se acercan porque lo ven como un sistema barato (o muy cercano a gratis) en lugar de verlo como un ERP que tiene muchas virtudes.
Pero bueno... dado el caso, si se necesita tercerizar desarrollo en un tercer país. Cuando hacerlo? Es simple, cuando tengan la practica de Project Management para hacerlo. Si pedis un desarrollo a un país que no conoce tus leyes impositivas (no me imagino a un asiatico discutiendo la factura electróncia argentina), no contas con experiencia en implementación de proyectos de software y esperas que el proyecto llegue a buen puerto... Significa que cuando llega diciembre le escribis una carta a Santa Claus y esperas una respuesta. Los proyectos se implementan con código, no con esperanzas.
Si quieren implementar un proyecto de software con un programador en otro pais necesitan asegurarse de lo siguiente: que conoce el problema a resolver, que se pueden comunicar con dicho programador diariamente, y que en un entorno agil pueden gestionar su trabajo. Si fallan en cualquiera de esos puntos... mejor olvidarse.
Por otra parte está la pregunta de, cuando comprar módulos en el exterior? Y ahí creo que hay dos situaciones. Hay módulos que son baratos y que por una módica suma solucionarian el problema. Si es así, comprenlo. Y si ven que no soluciona el problema... bueno, era un módulo barato. Es una opción que salió mal, pero una opción barata ya que muchas veces dichos módulos cuestan menos que una cajita feliz en una cadena de comidas rápidas.
Les comento una charla que tuve con un cliente de una industriosa provincia argentina (cuyos habitantes se caracterizan por tener un increible sentido del humor):
"Gustavo, necesito hacer tal cosa y estuve viendo tal modulo que me cuesta 15USD"
"Genial Delaney!" (buscamos preservar el anonimato ante todo). "El problema se puede resolver, pero va a llevar mínimo tres horas. Si el módulo hace lo que necesitas, y por lo que me comentaste no es caro... dale adelante. Es una buena idea"
Por otra parte hay módulos que cuestan cientos de dolares. Por lo general, son módulos que tienen buen soporte. Si un módulo de esas características estuvo a la venta por más de un año; significa que funciona y que tiene buen soporte. Años atras no sucedía eso, pero ahora tenemos esa buena noticia. Hay módulos que en teoría son caros (en realidad tienen un costo que con toda la furia cuestan 20hs de desarrollo) y que solucionan problemas que son realmente complejos: integrarse con MercadoLibre, integrarse con WooCommerce... etc etc.
Por último, implementar Odoo (o cualquier ERP) no es barato. Tampoco es caro (hay que conocer bien el costo de resolver los problemas). Pero no es barato. Y las horas de los desarrolladores que realmente son productivos, tampoco. Lleva miles de horas llegar a ser un programador productivo con Odoo, es por eso que dichas horas cuestan; no mucho. Pero no son gratis precisamente.
Acerca de:
Gustavo Orrillo
Apasionado de la programación, implementa Odoo para distintos tipos de negocios desde el año 2010. En Moldeo Interactive es Socio fundador y Programador; además de escribir en el Blog sobre distintos temas relacionados a los desarrollos que realiza.