Contenidos
Introducción
En este artículo veremos en qué consiste una estrategia de deslocalización de la producción de un producto software.
Recordemos que anteriormente hicimos un análisis para definir qué mínimos hay que cumplir como para tener una garantía de éxito en la tarea de deslocalización. Este análisis se publicó anteriormente en dos artículos (1 y 2).
Posteriomente a este análisis se asume que ya llevamos trabajando aún de modo centralizado pero aplicando los cambios en el proceso de producción para acumular experiencia, antes de comenzar con la deslocalización.
Comentamos en un artículo anterior que la refactorización a realizar sobre el producto software tenía relación con la estrategia de deslocalización que apliquemos. En este artículo veremos los motivos.
Contenidos de la estrategia
En el diseño de una estrategia de deslocalización de un producto software es preciso identificar qué aspectos debe contemplar esta estrategia y que pueden resumirse en los siguientes:
- Qué objetivos persigue conseguir la estrategia.
- Analizar qué partes del producto se pueden deslocalizar.
- Averiguar qué sitios hay disponibles o puede haber en un futuro cercano.
- Cuáles son las formas de distribución del trabajo que se van a aplicar entre los sitios disponibles.
- Posibilidades en la evolución de la estrategia a lo largo del tiempo .
- Plan para llevar a cabo la estrategia.
Cabe destacar que estos aspectos está bastante interrelacionados entre sí. Por ejemplo, las partes del producto que están lo suficientemente maduras como para que sean deslocalizadas van a determinar las formas de distribución del trabajo. A su vez, los sitios que haya disponibles y los perfiles profesionales de las personas de cada sitio también influyen en las formas de distribución del trabajo y en las partes del producto seleccionadas.
En los siguientes puntos vamos a ver diferentes posibilidades que identificamos para cada aspecto.
Objetivos
La estrategia de deslocalización de un producto software se querrá aplicar para conseguir una serie de objetivos. Identificamos los siguientes tipos:
- Económico: coste menor de la persona, coste menor de alquiler o adquisición de oficinas.
- Adquisición de talento: puede haber una escasez de talento disponible en el entorno cercano de tu sitio principal debido a la gran oferta de trabajo existente. Al incluir otros sitios remotos se amplía el potencial talento.
- Presencia física en una ciudad o país concreto para optar a oportunidades locales.
Los objetivos de la estrategia marcarán un hilo conductor de los aspectos restantes de la estrategia.
Partes del producto deslocalizables
La estrategia de deslocalización de un producto software deberá considerar qué partes del productos son posibles deslocalizar. Puede darse el caso de que no todo el producto esté lo suficientemente maduro como para deslocalizarlo. Con madurez nos referimos a que su construcción cumpla un mínimo de calidad.
Por tanto, lo primero que necesitamos identificar es qué partes consideramos como candidatas para tenerlas en cuenta en la deslocalización. Para hacer esto podemos invertir el criterio, centrándonos en identificar qué partes son inmaduras.
Una parte será inmadura si se cumple alguna de las siguientes condiciones. Se está produciendo muchos bugs en producción o si no se producen muchos pero el esfuerzo para corregir cada bug es alto. Si el esfuerzo en evolucionar esta parte incluyendo nuevas features es alto. Si al incluir estas features se incrementa el esfuerzo en testing y en la posterior resolución de bugs porque se ha desestabilizado
No obstante, puede ser que nos interese deslocalizar a toda costa una parte del producto que no sea madura. En este caso tendremos que hacer una labor de refactorización sobre esa parte para incrementar su calidad y que pueda ser deslocalizada sin conllevar un riesgo alto.
Sobre técnicas de refactorización ya hablaremos más adelante en otro artículo.
Una vez que tenemos identificadas las partes candidatas que pueden ser deslocalizadas, entonces tendremos que elegir las que finalmente deslocalizaremos. Esta elección va a depender de cómo distribuyamos el trabajo entre los diferentes sitios.
Sitios de trabajo y personal disponible
La estrategia de deslocalización de un producto software debe definir qué sitios va a disponer la compañia. Como sitio de trabajo nos referimos a centro de trabajo que agrupe a un colectivo de personas o a una oficina o casa particular que acoja a una sola persona.
En un entorno de trabajo no distribuido identificaremos dos tipos de sitios: el sitio principal y los sitios secundarios. El primero es el que gobierna y organiza al resto de sitios secundarios. En un entorno de trabajo distribuido no hay esta distinción y el gobierno y la organización está también distribuida, no estando adscritas físicamente a un sitio principal.
Podemos tener diferentes escenarios en función de los sitios que tengamos. Por ejemplo, podemos tener un centro de trabajo principal, dos centros de trabajo secundarios y tres personas trabajando en remoto desde sus casas. Más adelante veremos evoluciones posibles en estos escenarios de sitios.
Para cada sitio registraremos que perfiles profesionales hay asignados ya que esto será más adelante de utilidad a la hora de decidir las formas de distribuir el trabajo.
Es posible que a priori no tengamos un centro de trabajo identificado pero sí una fuente potencial de perfiles profesionales en un núcleo de población y que por este motivo nos decidamos de arrancar un centro en ese núcleo.
Además de tener una fuente de talento cercana, hay otros factores que pueden determinar la elección de un nuevo sitio. Por ejemplo, es posible que una o varias personas tengan necesidades personales de mudarse a otra ciudad, por diferentes motivos. Si hay un grupo de personas interesadas en la misma ciudad podría plantearse abrir un nuevo centro, haciendo previamente un análisis económico. Si no hubiera suficientes personas, entonces trabajarían en remoto desde sus casas.
Lo importante a resaltar en este punto es que el modelo cambia. Ya no estamos hablando de una compañia que tiene su estructura física establecida en inamovible y son las personas quienes se acomodan forzosamente a esta estructura. Ahora es la compañia la que tiene una estructura más flexible y se acomoda a las necesidades de las personas con el objetivo de cazar al mejor talento de profesionales disponible.
Formas de distribuir el trabajo
Uno de los aspectos más importantes de la estrategia de deslocalización de un producto software es cómo distribuir el trabajo entre los diferentes sitios. Se puede distribuir el trabajo de varias formas.
La primera forma es distribuir las fases de producción. La segunda es distribuir por backend y frontend. La tercera es deslocalizar enteramente un subproducto del producto. Finalmente podemos hacer una tercera mezclando todas las anteriores.
Pongamos varios ejemplos para clarificarlo. Podemos tener la siguiente distribución de fases de producción, aplicables tanto a backend como a frontend:
- Fases de análisis funcional, de diseño detallado y de testing en el sitio principal.
- Fase de implementación en el sitio secundario.
O podemos tener la siguiente distribución por fases de producción y por backend/frontend:
- Todas las fases del backend en el sitio principal.
- Fases de análisis funcional y de testing del frontend en el sitio principal.
- Fases de diseño detallado y de implementación del frontend en el sitio secundario.
Estas distribuciones van a depender mucho de los perfiles profesionales que tengamos en cada sitio y del grado de madurez que tengan cada parte del producto afectado por esta deslocalización.
En el primer ejemplo que pusimos, el conocimiento del negocio y del producto están únicamente en el sitio principal. Y por otro lado, hay mayor potencial de desarrolladores en el sitio secundario.
En el segundo ejemplo, el conocimiento del negocio y del backend están únicamente en el sitio principal. Mientras que hay mayor potencial de desarrolladores frontend en el sitio secundario.
Por lo que vemos, la distribución del trabajo y la ubicación de los perfiles profesionales en cada sitio están íntimamente relacionados.
Distribución por subproducto
Dedicamos un capítulo a este tipo de distribución del trabajo por tratarse ésta de una forma extrema de distribución.
Utilizamos aquí el concepto de subproducto como el de una parte del sistema que tiene una dependencia muy débil con el resto del producto y que tiene unas features muy diferenciadas del resto del producto. Suele ser común que la integración del subproducto con el resto del producto que se implemente mediante API-REST o por mensajería.
Además, se suele dar el caso de que el dominio del negocio del subproducto y el dominio del resto del producto tampoco tiene una dependencia fuerte. Si se incluyen nuevas features en el producto lo más probable es que no afecten al subproducto. Esto deriva en que si el producto sube de versión, el subproducto no tenga que hacerlo necesariamente.
En el caso de que podamos caracterizar alguna parte de nuestro producto como subproducto atendiendo a lo anterior, se puede deslocalizar la producción entera del subproducto a un sitio remoto. Esto implica deslocalizar todas las fases de producción. Esto hace que el sitio remoto tenga una mayor autonomía, por lo que las comunicaciones con el sitio principal son mínimas.
Esta forma de distribución puede ser un inconveniente si no hay ningún miembro que sepa del negocio en el sitio donde se deslocaliza y pueda colaborar en la fase de análisis funcional. Este miembro también debería conocer las features actuales del producto, su arquitectura a alto nivel y el roadmap futuro del producto para analizar posibles impactos que haya en el subproducto como consecuencia de nuevas features a incluir en el resto del producto.
Asimismo, garantizar la misma calidad en el subproducto puede suponer un inconveniente, pues es fácil perder el control del proceso de producción. Para evitar esto, si fuera necesario tendrían que planificarse acciones de auditoría interna.
Se debe dejar claro qué sitio se hace cargo del soporte del subproducto así como de su evolución porque de lo contrario puede suponer un conflicto con el equipo del sitio principal.
Forma de distribución a evitar
La siguiente forma de distribución no es aconsejable aplicarla. Esta forma de distribución de trabajo consiste en distribuir la fase de implementación por capa existente en el proceso de desarrollo. En backend típicamente se suelen tener las siguientes capas: capa de interfaz hacia afuera con otros sistemas, capa de lógica negocio y capa de persistencia de datos.
Un inconveniente es que hay muchas dependencias entre estas capas y por lo tanto se darán muchas comunicaciones entre los miembros de diferentes sitios.
Otro inconveniente es que los desarrolladores no tienen la foto global en vertical de cada feature que les permita un pensamiento lógico de lo que están desarrollando. Se tienen que ceñir por completo a lo que indique el diseño por lo que es fundamental que los diseños sean de buena calidad.
Un inconveniente más es si se tiene al comienzo un equipo con desarrolladores sin tener expertos en ninguna capa en concreto. Por otro lado, se puede tender a especializar demasiado a los miembros del equipo. Esto depende de qué prefieran. Hay personas que prefieren ser full-stack developer y otros prefieren estar especializados en backend o frontend.
Otro inconveniente es que se pueden dar muchas situaciones de bloqueo durante el desarrollo debido a las dependencias que hay entre las capas. Esto se puede mitigar definiendo bien las interfaces entre las capas. Cuando llegue el momento de realizar las pruebas a nivel de componente se ha de elegir a algún miembro del equipo que haya estado en el desarrollo de este componente pero como seguramente haya tocado solamente una capa tendrá que hacer un sobreesfuerzo para tener la foto global de todas las capas para poder hacer estas pruebas.
La única ventaja es que la asignación de tareas es más sencilla porque cada desarrollador implementará aquella capa en la que tiene más experiencia.
Por todo esto, se desaconseja esta forma de distribuir el trabajo.
Comunicaciones
Cuando estamos diseñando una estrategia de deslocalización de un producto software es indispensable analizar como las comunicaciones quedan influenciadas por el modo de distribuir el trabajo.
Por ejemplo, si se deslocaliza la fase de implementación a un sitio secundario se deberá poner especial atención a como adaptar las comunicaciones entre los diseñadores que están en el sitio central y lo desarrolladores que están en el sitio secundario. Varios desarrolladores pudieran necesitar las aclaraciones de un diseñador, por lo que habrá que definir estas comunicaciones para no saturar al diseñador y minimizar lo máximo posible las interrupciones diarias. Se deberá tener cuidado en utilizar un lenguaje adecuado para ambos lados, diseño e implementación, con el objetivo de que la comunicación sea eficaz y eficiente.
En cuanto a los diseños creados, deberán ser de buena calidad y con suficiente detalle para que los desarrolladores implementen la solución esperada.
Sería aconsejable incluir una tarea nueva destinada a realizar la auditoría del código implementado. Se deberá asignar esta responsabilidad al rol de diseñador. Para realizar esta auditoría será necesario definir el DoD (Definition of Done) de una tarea de desarrollo para que el desarrollador pueda dar como finalizada dicha tarea desde el punto de vista de su implementación. El diseñador realizará esta auditoría tomando como referencia este DoD.
Hemos visto el caso de deslocalización de la fase de implementación. En general, habría que analizar como se ven afectadas las comunicaciones cuando apliquemos cualquier forma de distribución del trabajo.
Posibilidades de evolución de la estrategia
La estrategia de deslocalización de un producto software puede cambiar a lo largo del tiempo ya que debe debe adaptarse al nuevo entorno en que la compañía se desenvuelve.
Dimensiones
La estrategia puede cambiar a lo largo del tiempo en varias dimensiones.
En cuanto a la dimensión de los sitios de trabajo, un modo de transición orgánico para pasar de un modo de trabajar centralizado a uno distribuido es el siguiente:
- En la situación inicial todo el personal está en un único centro de trabajo.
- Después se pasa a tener un centro principal y varios centros secundarios.
- Cuando esta nueva organización esté madura entonces podemos tener un centro principal, varios centros secundarios y varios sitios particulares.
- Cuando se adquiera madurez entonces podemos descentralizarlo aún más teniendo varios centros distribuidos y varios sitios particulares.
- Se puede incluso llegar a seguir el paradigma office not required seguido por algunas compañías como Basecamp y Automattic, en el que no se tiene ningún sitio de trabajo físico y por tanto todo se descentraliza.
Para el arranque de un nuevo sitio secundario suele funcionar bien la siguiente técnica. Una persona del sitio principal se desplaza temporalmente (o de modo indefinido) al sitio secundario. Esta persona será el enlace entre ambos sitios mitigando el riesgo de que se de una situación de nosotros y vosotros entre los dos sitios. Además, se encargará de formar al personal del sitio secundario en el modo de trabajo establecido así como en el negocio y en el producto.
En cuanto a la dimensión de la forma de distribución del trabajo se puede comenzar de modo conservador deslocalizando la fase de implementación. Después se sigue deslocalizando enteramente el frontend y acabar deslocalizando un subproducto. En esta dimensión las posibilidades de evolución son infinitas y dependerá de diversos factores estratégicos de la compañia y de los recursos que nos ofrezca el entorno (sitios y personal).
Ejemplo de evolución
Veamos a continuación una posibilidad de evolución de una estrategia de deslocalización. Iremos viendo como se van dando las diferentes etapas a lo largo del tiempo.
Etapa 1
| Sitio | Fase de producción | Parte del producto |
| principal | análisis, diseño | todas |
| principal | implementación | legacy code, backend |
| principal | testing | todas |
| secundario | implementación | middleend, frontend |
En el sitio secundario solamente hay desarrolladores. Las partes con legacy code es un riesgo alto deslocalizarlas ya que la tecnología es antigua, la calidad del código es pobre y su evolución y mantenimiento es muy costosa incluso por personas con experiencia en el producto. El backend también tiene cierta complejidad que hacen que su deslocalización acarree un riesgo que la compañia no quiere asumir.
Etapa 2
| Sitio | Fase de producción | Partes del producto |
| principal | análisis, diseño | todas |
| principal | implementación | legacy code |
| principal | testing | todas |
| secundario | implementación | backend, middleend, frontend |
Se han llevado a cabo ciertas refactorizaciones en el backend pasando de tener un monolito a tener un conjunto de microservicios. Se ha actualizado la tecnología y ahora se usa Spring como framework de desarrollo. Esto hace que que el riesgo de deslocalizarlo al sitio secundario disminuya.
Etapa 3
| Sitio | Fase de producción | Partes del producto |
| principal | análisis | todas |
| principal | implementación | legacy code |
| principal | diseño | backend |
| principal | testing | todas |
| secundario | diseño | middleend, frontend |
| secundario | implementación | backend, middleend,frontend |
El conocimiento profundo del negocio sigue estando en el sitio principal. Sin embargo, el sitio secundario va ganando en autonomía progresivamente (etapas 2 y 3). Las personas de este sitio van aprendiendo del negocio y del producto.
Etapa 4
| Sitio | Fase de producción | Partes del producto |
| principal | análisis, diseño | backend |
| principal | implementación | legacy code |
| principal | testing | backend |
| secundario | análisis, diseño, implementación, testing | frontend |
| secundario | testing | middleend |
| persona en remoto | análisis, diseño, implementación | middleend |
El sitio secundario sigue ganando en autonomía en esta etapa. Ya saben lo suficiente del negocio coma realizar además el análisis y testing del frontend y el testing del middleend.
Una persona del sitio secundario pasa a trabajar en remoto desde su casa por necesidades personales. Se le asigna el análisis, diseño e implementación del middleend. Esta persona sigue haciendo de enlace entre el sitio principal y el sitio secundario pero ahora lo hace en remoto. Ya sabe como trabajan las personas del sitio secundario y esto hace que el riesgo de pasar a trabajar en remoto sea mínimo.
Siguientes etapas
Como se observa la compañia va evolucionando su estrategia según cambia el entorno. El conocimiento de las personas de cada sitio va cambiando. Las necesidades de movilidad de cada uno también van cambiando. La compañia sigue manteniendo el objetivo económico y la contratación de talento en el sitio principal sigue siendo costosa.
Por lo tanto, las siguientes etapas que puedan existir deberán ajustarse a los nuevos entornos que se vayan dando.
Lo importante a destacar en este punto es que el equipo ya tiene cierta madurez en trabajar de modo distribuido y las opciones futuras posibles se multiplican.
Plan
El diseño de una estrategia para la deslocalización de un producto software debe incluir un plan para ejecutar esta estrategia a lo largo del tiempo.
El plan debe incluir las primeras etapas que se tiene pensado llevar a cabo, como hemos visto en el ejemplo anterior.
Para cada etapa se deben identificar al menos lo siguiente:
- Los riesgos que pueden ocurrir, definiendo un plan para gestionar estos riesgos.
- Un duración estimada antes de pasar a la siguiente etapa.
- Análisis económico de costes:
- Pérdidas previstas por la posible pérdida de productividad hasta que la etapa logre estabilizarse.
- Sobre costes por establecer los sitios secundarios nuevos.
- Ahorro de costes en el sitio principal.
- Qué beneficios estratégicos espera aportar la etapa a la compañia.
- Experiencia prevista acumulada tras la ejecución de la etapa y qué posibilidades se pueden dar en el futuro gracias a esta experiencia.
- Definir un criterio de éxito para saber si la etapa ha resultado bien o no. Este criterio se basará en los anteriores puntos.
Una vez que termine la etapa habrá que revisar los puntos anteriores y ver qué grado de cumplimiento ha habido en cada uno de los puntos para saber cómo de exitosa fue la etapa.
Conclusiones
En este artículo hemos visto qué contenidos debe incluir una estrategia para deslocalización un producto software y qué objetivos se espera que logre esta estrategia para la compañia. También se ha visto como la estrategia puede evolucionar a lo largo del tiempo para adaptarse a nuevos entornos.Finalmente se ha visto que es necesario establecer un plan para llevar a cabo esta estrategia y monitorizar su éxito en cada etapa.
Es clave hoy en día que cualquier compañia se adapte al nuevo paradigma de trabajo distribuido, adaptando su estructura de centros de trabajo a la situación actual y la que posiblemente venga.
Por otro lado, es primordial que la productividad se mantenga y para ello es necesario establecer una buena estrategia de deslocalización que inevitablemente tendrá que evolucionar en el tiempo.
La adquisición de buenos profesionales es un activo que las compañías deben buscar para conseguir para poder ofrecer un valor diferenciador en sus productos y servicios. Al distribuir el trabajo, se accede a un potencial de talento no restringido a una única área geográfica sino que potencialmente es todo el mundo.