Outsourcer dice: No subcontrate

No externalice el desarrollo de software.

Sí, ha leído bien. Trabajo para una empresa de subcontratación de desarrollo de software y le digo que no subcontrate.

Pero, ¿por qué no? Todo el mundo lo hace, y todo el mundo no puede equivocarse, ¿verdad? La percepción común es que la subcontratación ahorra dinero basándose en el arbitraje laboral. Puede haber otros factores, pero principalmente las empresas lo hacen para obtener más software, probablemente más rápido, por menos dinero.

Sin embargo, la economía de la subcontratación es mucho menos sencilla de lo que sugiere la comparación de las tarifas laborales. No existe el "arbitraje laboral" en el desarrollo de software. A diferencia del cobre o el trigo, no todos los desarrolladores son iguales, por lo que no se trata exactamente de materias primas. Además, la externalización no está exenta de riesgos, como veremos más adelante. Así que el concepto de arbitraje no se aplica, y con él se va toda la propuesta.

En primer lugar, ¿estamos comparando manzanas con manzanas? Sí, esa empresa extranjera sólo te cobra $20/hora por un desarrollador. Pero, ¿cuánto valor está obteniendo en esa hora? ¿Hasta qué punto es competente ese desarrollador? ¿Tiene en su equipo a gente fuerte, o en su mayoría universitarios recién licenciados con niveles de habilidad cuestionables? ¿Qué experiencia tienen? Un desarrollador interno con experiencia ($100/h) puede aportarle más valor que cinco o incluso más desarrolladores junior ($20/h) en el extranjero.

Recuerde también que tiene que formar a los recursos externos. Al principio, no conocen su producto, no conocen su proceso y no han trabajado juntos antes, por lo que se necesita tiempo antes de que puedan empezar a producir valor. Aunque necesaria, la inversión en una curva de aprendizaje se come definitivamente el ahorro previsto. Y ese desarrollador interno senior que está totalmente al día volverá a superarle.

Supongamos que ya ha superado la transferencia inicial de conocimientos. ¿Ya ha conseguido ese ahorro? Difícilmente. En el desarrollo de software, la comunicación es clave. A veces ya es bastante difícil explicar a una persona con experiencia en la misma habitación lo que quieres que construya. Imagínese hacer lo mismo con alguien que está a miles de kilómetros de distancia y que se basa sobre todo en el correo electrónico y la mensajería instantánea, y a veces en llamadas de voz y vídeo por Skype. El desarrollo de software es un proceso social en el que las personas comparten ideas complejas y conceptos abstractos. Y no, la documentación no lo solucionará del todo: no se puede documentar realmente todo sobre un sistema por adelantado, y cualquier El texto escrito siempre está sujeto a múltiples interpretaciones. Además, el mercado cambia tan deprisa que, para cuando la documentación está completa, suele estar obsoleta y las nuevas necesidades obligan a cambiar de sistema. El desarrollo de software tiene que ver con el conocimiento tácito y la comprensión emergente. De nuevo, ya es bastante difícil dentro de la empresa y aún más con un proveedor externo (pensemos en diferencias culturales, acentos, barreras de comunicación, etc.).

¿Y la posibilidad de poner más cuerpos en un proyecto? Por ejemplo, va retrasado en su calendario de lanzamientos y está tentado de añadir recursos deslocalizados más baratos para cumplir los plazos. Por desgracia, si lo hace Ley de Brooks es probable que surta efecto. Este famoso principio afirma que añadir recursos a un proyecto tardío lo hará más tardeo, como formuló más coloridamente su autor Fred Brooks, "Nueve mujeres no pueden hacer un bebé en un mes". Incluso cuando un proyecto no se retrasa, más gente no equivale a más valor. Con las complejidades de la comunicación, un equipo más grande avanza más despacio, a veces de forma significativa, con la consiguiente pérdida de productividad. Su inversión puede comprarle más desarrolladores en el extranjero, pero no necesariamente más valor en forma de software comercializable por su dólar.

Tampoco hay que olvidar los costes de gestión adicionales que supondrá comunicarse con el proveedor y supervisar su rendimiento. El estudio de Aberdeen Group muestra que más del 76% de los clientes declaran que los costes de administración de proyectos y gestión de proveedores son de 1.000 millones de euros. mucho mayor de lo esperado, lo que no sorprenderá a nadie que haya hecho alguna externalización.

Por último, considere el riesgo general de fracaso del proyecto. Las estadísticas varían pero, según la fuente, entre el 30 y el 50% de los proyectos externalizados fracasan rotundamente: o bien se abandonan por completo (y el trabajo vuelve a realizarse internamente con un coste adicional), o bien se quedan radicalmente cortos en cuanto a la funcionalidad y el valor empresarial que aportan. Es cierto que no todos los proyectos internos llegan a buen puerto, pero con la externalización el riesgo de fracaso es mayor.

Así que, por favor, no externalice el desarrollo de su software.

A menos que sea absolutamente necesario. Y a menos que lo hagas con Agile. Más concretamente, Scrum.

A veces, mantener un proyecto dentro de la empresa no es una opción. Por ejemplo, puede que necesite aumentar rápidamente su equipo de desarrollo para enviar un producto en una fecha concreta o arriesgarse a que se cierre la ventana de oportunidad, pero sabe que no puede contratar a suficientes personas de alta calidad en su zona geográfica. Si opta por la distribución, en esencia estará subcontratando y se le aplicarán al menos algunas de las dificultades inherentes al desarrollo de software tradicional. Sin embargo, subcontratar a una empresa que utilice Scrum le ayudará a superar los obstáculos que hacen que el enfoque tradicional sea difícil de manejar e ineficaz, y que provocan fracasos endémicos en los proyectos. 

Inspirado en el Sistema de Producción Toyota (TPS), el Scrum se presentó por primera vez en un documento de conferencia de Dr. Jeff Sutherland y Ken Schwaber en 1995. Scrum está diseñado en torno a varios principios y prácticas fundamentales, como el desarrollo en iteraciones cortas, la entrega incremental de software potencialmente despachable después de cada iteración, la priorización de características en torno al valor empresarial y la participación directa del cliente en la planificación, elaboración y aceptación.

A diferencia del enfoque tradicional de "cascada", en el que todo el software se entrega una vez, al final del proyecto, Scrum se centra en proporcionar un flujo continuo de valor al cliente, lo que minimiza el riesgo del proyecto y aumenta el rendimiento de la inversión. Con Scrum, los fracasos catastróficos de proyectos como el reciente Debacle del Sistema de Gestión Judicial de California (CCMS) $500 millones son imposibles por definición.

La investigación de Sutherland muestra que, cuando se ejecuta correctamente, Scrum puede ayudar a lograr -incluso en un proyecto grande y distribuido globalmente- el tipo de hiperproductividad/velocidades extremas que sólo se creían posibles en pequeños equipos co-localizados, velocidades que son varios múltiplos de la productividad típicamente vista en equipos en cascada, internos o deslocalizados. Aplicado en el contexto del desarrollo de software subcontratado y distribuido, Scrum actúa como catalizador de la comunicación y como un potente foco que ilumina todos los aspectos de la relación cliente-proveedor, forzando la responsabilidad por un lado y desencadenando una enorme productividad por otro.

Sutherland, que actualmente asesora al equipo de inversión de OpenView Venture Partners, con sede en Boston, y entrena a las empresas de cartera de OpenView en el uso de técnicas de desarrollo ágiles, me explicó que aconseja exactamente lo siguiente a las empresas de cartera de OpenView: o subcontratan a empresas Scrum o no subcontratan en absoluto.

Steve Denning en Forbes califica el Scrum de gran descubrimiento de gestión y, de hecho, sostiene que sus fundadores deberían recibir un Premio Nobel de gestión, si lo hubiera. ¿Puede, de hecho, ayudarle a incorporar personas, incluidas las deslocalizadas, y ¿ir más rápido que más despacio? ¿Puede ayudarle a entregar software de forma fiable cuando trabaja con proveedores externos? Mi propia respuesta a estas preguntas es un "Sí" sin reservas, pero investigue y averígüelo usted mismo. Especialmente si subcontratas, No creo que pueda permitirse no hacerlo. Y sospecho que sus competidores ya lo han hecho.

1.       Scrum alcanza velocidades hasta 5 veces superiores a la media del sector en cascada (Capers Jones, Jeff Sutherland)

2.       Los proyectos en cascada tienen un índice de fracaso tres veces mayor (29% frente a 9%) y un tercio de éxito (14% frente a 42%) que los proyectos ágiles. (Grupo Standish, Informe CHAOS 2012)

3.    Sistema de Gestión Judicial de California: Fracaso sonado en cascada en el que el coste previsto era de $500M, el coste real fue de $2B, que superaba las estimaciones originales en 630%, y el proyecto se abandonó por completo.

4.    Los analistas sugieren a los responsables de TI que digan adiós a la cascada (Guía de planificación de Gartner 2012: estrategias de entrega de aplicaciones)

5.    Entre los líderes del sector que utilizan Scrum se encuentran Google, Microsoft, Yahoo, Citrix, Facebook, Adobe, Salesforce.com, Nokia, Siemens y muchos otros.