Externalización IT
Desarrollo de software externalizado
Equipos que se integran en su forma de trabajar, no un proveedor que entrega un binario y desaparece.
En resumen: equipos de desarrollo full stack, móvil y de producto, integrados en su hoja de ruta y sus procesos. El código, la documentación y la propiedad intelectual son suyos desde el primer día, y conviene dejarlo fijado en el contrato.
El desarrollo externalizado falla casi siempre por la misma razón, y no es técnica: el equipo externo no tiene contexto suficiente sobre el negocio para tomar las decisiones pequeñas que se toman cada día sin consultar.
Por eso el modelo que funciona no es el de encargo cerrado sino el de equipo integrado, con acceso al mismo repositorio, el mismo tablero y las mismas conversaciones que su equipo interno.
Qué incluye
Configurado según el proyecto en la propuesta.
- Desarrollo full stack, móvil y de producto
- Integración en su repositorio, su tablero y su proceso de revisión
- Revisión de código y pruebas automatizadas como parte del flujo
- Documentación técnica mantenida durante el proyecto
- Participación en las ceremonias ágiles que ya tenga
- Traspaso ordenado al finalizar, con documentación al día
Qué no incluye
Los límites que evitan una expectativa equivocada.
- Decisiones de producto y priorización de la hoja de ruta, que son suyas
- Compromisos de plazo sobre alcance no definido
- Administración de su infraestructura de producción, que corresponde a servicios gestionados
- Garantía de resultado de negocio derivada del software entregado
Desde dónde se presta
Desde Polonia cuando el proyecto exige residencia del dato dentro del Espacio Económico Europeo o coordinación síncrona completa, ya que comparte huso horario con la España peninsular.
Desde Uzbekistán cuando el trabajo se mide por entrega y basta con una ventana de coordinación diaria. En ese modelo recomendamos siempre un responsable técnico que haga de puente, porque las conversaciones de diseño y de alcance se producen en inglés técnico.
Propiedad intelectual y acceso a datos
El código, la documentación y los derechos de propiedad intelectual generados en el proyecto son suyos. Conviene fijarlo expresamente en el contrato en lugar de darlo por supuesto, junto con el régimen de dependencias de terceros y licencias de código abierto utilizadas.
Sobre datos: la medida más eficaz en un proyecto de desarrollo suele ser estructural, trabajando sobre entornos de desarrollo y datos de prueba, y restringiendo el acceso a entornos con datos reales a lo estrictamente necesario, con control por rol y registro de accesos.
Si el proyecto exige acceso continuado a datos personales reales de clientes europeos desde fuera del Espacio Económico Europeo, conviene revisar el modelo de entrega antes que el contrato.
Preguntas frecuentes
¿De quién es el código?
Suyo. Se fija expresamente en el contrato, junto con la documentación y el régimen de licencias de las dependencias utilizadas.
¿Trabajan en nuestro repositorio?
Sí, es el modelo que recomendamos. Un equipo que trabaja en un repositorio paralelo acumula divergencia y convierte cada integración en un proyecto.
¿Qué pasa si el proyecto termina antes de lo previsto?
El traspaso está previsto desde el inicio: documentación al día durante el proyecto y no redactada al final, que es cuando ya nadie recuerda por qué se tomó una decisión.
¿Pueden trabajar con nuestro equipo interno?
Es lo habitual y lo que mejor funciona. El modelo de equipo integrado supone compartir tablero, revisión de código y contexto, no trabajar en paralelo.
¿Necesita ampliar capacidad de desarrollo?
Cuéntenos la hoja de ruta, el stack y el modelo de coordinación que espera.