¿El código de outsourcing es más costoso a largo plazo? ¿Daña la calidad del código? [cerrado]

Soy consciente de una empresa que posee la propiedad intelectual de un producto de software decente y obtiene un excelente ingreso anual de licencias. Sin embargo, el director (no técnico) se queja del costo de mantener el equipo de desarrollo, ya que afecta significativamente los márgenes de beneficio y está considerando el desarrollo de la subcontratación de módulos específicos a otros países que cobran a una tasa más baja.

Personalmente, no creo que sea una solución más rentable a largo plazo. Esto puede conducir a fallas en la comunicación cuando hay problemas, además, las especificaciones deberán ser herméticas, lo que puede llevar más tiempo de todos modos. En mi opinión, cuando se trabaja en equipos, la comunicación es clave, ¿o hay una forma efectiva de hacer que esto funcione?

Estoy seguro de que alguien tiene un ejemplo de esto funcionando, pero no lo he visto.

He trabajado en una compañía Fortune 500 durante muchos años, donde subcontrataron mucho desarrollo. No tengo un solo ejemplo en esos años de un proyecto subcontratado que cueste menos que si lo hubiéramos hecho nosotros mismos (internamente).

Si bien sus tasas de programación fueron menores que las nuestras, pasamos 3 veces la cantidad de tiempo administrando el equipo subcontratado que lo que hacemos para los equipos internos. Eso se suma al tiempo adicional necesario para tener los requisitos más detallados que las necesidades de nuestro equipo interno y el tiempo adicional necesario en el control de calidad porque el código nunca estuvo cerca de ser correcto.

Puede tenerlo rápidamente, puede tenerlo a bajo costo, o puede hacerlo bien. No puedes tener los tres, y diría que incluso dos de cada tres pueden ser una exageración.

Para una compañía de software, esto es simplemente estúpido. Lo más cerca que podrían llegar a una decisión razonablemente inteligente sería trasladar la empresa a otra ubicación que tenga un talento más barato.

Una empresa de software que externaliza su desarrollo de software ya no es una empresa de software. Yo diría que cualquier ganancia obtenida será de corta duración, porque está creando su propia competencia. Una vez que se dan cuenta de que conocen el producto mejor que tú, también se dan cuenta de que ya no te necesitan.

Mi única experiencia de outsourcing a una empresa en otro país será la última. La compañía que fue contratada, no completó su trabajo a tiempo o ni siquiera cumplió con las especificaciones de forma remota, y resultó en que tuvimos que rehacer todo el lote nuevamente internamente.

Sin embargo, si puede encontrar una compañía confiable en la que pueda confiar (es decir, que haya visto / escuchado cosas buenas de otras personas), entonces tal vez valga la pena.

El director quiere reemplazar a algunos de sus desarrolladores locales con experiencia por personas en un país distante cuya experiencia no es competente para juzgar, que no tienen experiencia con el código y que no pueden ser supervisados ​​o asesorados directamente por nadie que sepa el código.

He pasado por eso dos veces. En ambos casos, las firmas extranjeras de bajo costo no lograron entregar a tiempo con la calidad adecuada. Cuando los desarrolladores locales escucharon que el trabajo se dirigía al extranjero, encontraron otros trabajos en lugar de esperar a ser despedidos. A medida que continuó la hemorragia de experiencia, los horarios se deslizaron, los errores críticos no se solucionaron, los clientes se enojaron y cambiaron a sus competidores, y finalmente ambas compañías se retiraron.

También hubo problemas extraños con la comunicación, las expectativas y la cultura. Por ejemplo, un equipo extranjero no estaba registrando mucho código o respondiendo rápidamente al correo electrónico. Resultó que el gerente de TI local obtuvo una bonificación por mantener bajos los costos, por lo que tenía toda la oficina con una conexión a Internet de baja velocidad. En otra ocasión, los probadores de control de calidad del tercer mundo ponen rutinariamente varios errores muy diferentes en el mismo informe de error; su gerente tenía miedo de quedarse sin números de errores.

Algunos equipos en lugares económicos están bien. Por lo que escuché, Red Hat parece tener un equipo muy competente en Beijing. Pero ya tenían años de experiencia con personas que trabajan en todo el mundo a través del teletrabajo antes de comenzar a hacerlo, y la gente de Beijing son empleados de Red Hat, no una empresa de outsourcing.

Sí, obtienes lo que pagas.

En mi experiencia, a menos que sus necesidades de mercado y desarrollo sean tan simples que pueden explicarse fácilmente por correo electrónico a cualquier desarrollador con una posible barrera del idioma, y ​​tan simple que incluso un desarrollador que no está realmente invertido en la compañía aún puede tener éxito al crear un producto de calidad, entonces sí, su producto sufrirá .

Trabajé en una empresa donde teníamos un gran equipo de desarrollo local, y nuestro producto sufrió simplemente porque el equipo de gestión invirtió más dinero y esfuerzo en las ventas. Debido a que se invirtió tanto esfuerzo en las ventas, parecía que lo estábamos haciendo "bien", pero significaba obtener ingresos que estábamos obligados a seguir invirtiendo dinero y recursos en el proceso de ventas.

Teníamos un equipo remoto pero los integramos completamente en la empresa y participaron al mismo nivel que nuestros equipos locales. Esa es la única forma en que puede funcionar . Yo era el líder del equipo local para ellos y volamos a trabajar con ellos regularmente. Les dimos camisas y chaquetas de la compañía al igual que los equipos locales. Después de todo lo considerado, tal vez nos ahorró un 20-30%. Si crea un sistema que intenta reducir los costos en más de eso, su producto sufrirá en consecuencia.

Si está trabajando con un equipo de outsourcing de calidad, y la gerencia está dispuesta a comunicar y hacer cumplir los criterios de aceptación.

Entonces el costo será aproximadamente la misma tasa que un producto desarrollado internamente.

También puede obtener la misma calidad, si tiene suerte.

Puedo estar un poco parcial porque mi empresa tiene un personal de desarrollo interno y no ha subcontratado ningún desarrollo de productos. Sospecho que las experiencias que hemos tenido con socios de integración que han subcontratado el desarrollo tuvieron algo que ver con esa decisión.

En mi experiencia, externalizar un proyecto no es la mejor solución cuando se trata de obtener mejores márgenes.

En el trabajo teníamos algo así y, como otros también dijeron, terminamos rehaciendo el agujero y manteniendo lo que estaba en un servidor de producción. Conclusión sobre el asunto, costó el doble.

Mi opinión al respecto es que si está pensando en tratar de hacer una diferencia en los desarrollos de externalización de márgenes, podría estar desperdiciando su inversión. Si lo piensas bien, el éxito del producto es cuestión de que las cosas funcionen como se espera, por lo que si cambias el equipo de desarrollo, las cosas podrían ponerse feas.

El software de código abierto bien planificado / hecho podría ser su respuesta, ya que puede ser altamente rentable y el mantenimiento se delega de alguna manera en una comunidad, pero no hay una receta para el éxito. El mejor consejo que puedo dar es recomendar varias charlas sobre lo que realmente es de código abierto y sus travesuras:

• "Cómo iniciar un proyecto de código abierto" por Jeremy Ruston (BT) http://vimeo.com/856110
• "El código abierto es magia" por Chris DiBona (Google) http://www.youtube.com/watch?v=hmZyyBVbkOQ
• "Los motores de la comunidad" por Jono Bacon (Canonical) http://www.youtube.com/watch?v=zKOrWubmzAY
• "Proyectos de código abierto y personas venenosas" Ben Collins-Sussman y Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
• "¿Qué hay para mí? Beneficios del código de abastecimiento abierto" Ben Collins-Sussman y Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

Y quizás también:

• "Cómo elegir un modelo de negocio" por Roan Lavery (FreeAgent) http://vimeo.com/5588154

El tema del código abierto, en mi opinión, es construir algo de valor e interés no solo para usted sino para todos, el poder del código abierto reside en las comunidades.

Además, si su jefe / empresa es reacia a abrir el software, simplemente aísle los detalles de su propia lógica y conocimientos empresariales. Entonces, qué estarías haciendo:

1. Incube un proyecto de código abierto con sus recursos.
2. Crecer una comunidad
3. ???
4. Beneficio =)

Sí, lo digo en serio y "???" implica cualquier estrategia que desee seguir después de reunir suficiente interés. Con las herramientas actuales, como Github y Twitter, puede correr la voz más fácilmente, pero tenga en cuenta que su primera impresión debería ser lo suficientemente interesante.

Si en realidad no desea el código abierto ( que debe comprender como modelo de negocio antes de implementarlo, si desea tener éxito ), siempre puede lanzarlo como un servicio, para eso verifique el video Carsonified, pero eso implica un todo Muchas otras cosas para su empresa.

Al final, ser de código abierto o lanzarlo como un servicio son formas de hacer que el proyecto sea sostenible a largo plazo.

No recuerdo al autor de esta cita, pero da en el clavo.

"Los equipos débilmente acoplados que trabajan juntos en componentes estrechamente acoplados fallan. Inevitablemente "

Outsourcing = equipos poco acoplados.

Intentar reducir costos dividiendo geográficamente el trabajo en componentes interdependientes siempre falla.

Por otro lado, según mi experiencia, mover una parte completa de la cartera de software podría funcionar, lo que significa que puede desarrollarse en buena calidad con costos reducidos.