Externalización de software en Türkiye: selección de proveedor
Elija un socio de desarrollo de software en Türkiye por competencias, contrato y protección de datos, no solo por tarifas: haga un piloto pagado antes de comprometerse y deje por escrito la propiedad intelectual, los deberes de KVKK y GDPR, las cláusulas de salida y la moneda del contrato, porque la inflación de la lira y los tipos de cambio mueven el presupuesto a mitad de proyecto.
¿Por qué considerar Türkiye para la externalización de software?
Nearshore, definido en una línea: externalizar hacia un país lo bastante cercano en zona horaria y en distancia de vuelo para que la colaboración diaria funcione. Para un comprador europeo, Türkiye cae dentro de un solapamiento de jornada laboral que convierte las sesiones en vivo en algo habitual y no excepcional, y está lo bastante cerca para un vuelo de arranque de proyecto o de taller de trabajo sin un día de desfase horario a ningún lado.
Tres razones prácticas por las que los compradores lo incluyen en su corta lista:
- Solapamiento de zona horaria. Los horarios de Türkiye se solapan en buena medida con Europa occidental y central y con el Golfo y el Levante; la mañana en Berlín o en Dubái es la tarde en Estambul, que es la ventana en la que las preguntas se contestan el mismo día y no al siguiente.
- Profundidad técnica e idioma. Türkiye tiene un gran mercado laboral de software centrado en Estambul, Ankara e Izmir, con equipos que trabajan a diario en inglés; para los compradores que quieren sesiones presenciales ocasionales, el turco, el alemán y el árabe también son habituales.
- Posición de coste. Las tarifas suelen situarse entre los precios offshore del sur y el sureste de Asia y los precios de agencia de Europa occidental; lo interesante para un comprador no es la cifra por hora, sino lo que esa cifra compra: niveles de experiencia del equipo, disciplina de revisión y hábitos de documentación.
Modelos de colaboración
| Modelo | Mejor para | Riesgo principal | Control a añadir |
|---|---|---|---|
| Equipo dedicado | Una hoja de ruta que evoluciona, productos de recorrido largo, entrega continua | El coste sube a medida que el equipo se familiariza con el trabajo | Revisiones de capacidad, una ruta de escalamiento definida y un responsable con nombre en cada lado |
| Alcance fijo | Proyectos bien especificados con requisitos estables | Disputas de alcance; todo lo no definido se convierte en negociación | Un alcance escrito con criterios de aceptación y un procedimiento de cambios |
| Tiempo y materiales | Trabajo en evolución donde la velocidad importa más que una cifra fija | Deriva presupuestaria sin señales visibles de progreso | Informes de presupuesto semanales, cadencia de demostraciones y un plan de consumo acordado |
| Híbrido (equipo más bloques fijos) | Trabajo de producto mezclado con entregables definidos | Dos ritmos de gestión que sostener a la vez | Una sola línea de informe; mantener los bloques fijos realmente acotados |
La elección del modelo importa menos que la disciplina que la rodea: un proyecto de alcance fijo con un buen procedimiento de cambios le gana a un proyecto de alcance fijo que finge que nada cambiará, y un equipo de tiempo y materiales con informes semanales honestos le gana a uno más barato por el que no puede mirar dentro.
¿Cómo elige un proveedor? Una lista de comprobación de 15 puntos
- Trabajo entregado relevante — pida dos o tres proyectos parecidos al suyo en tamaño y en dominio, y cuál fue el papel del propio equipo en ellos.
- Quién escribe el código — equipo interno o subcontratistas; si se subcontrata, quién responde contractualmente ante usted.
- Composición del equipo ofrecida — roles, mezcla de niveles de experiencia y quién es el contacto de cada día.
- El inglés en la práctica — no una afirmación de un perfil: sostenga la primera llamada en inglés y juzgue la discusión técnica, no la charla.
- Solapamiento de zona horaria ofrecido — qué horas se garantizan para la colaboración en vivo y qué trabajo es asíncrono por diseño.
- Cesión de propiedad intelectual por escrito — que todos los derechos sobre código, documentación y derivados se transfieren a usted, incluido durante la relación.
- NDA y confidencialidad — firmado antes de la revelación técnica detallada y cubriendo al personal tanto como a la empresa.
- Posición en protección de datos — si trabajan bajo KVKK, bajo GDPR o bajo ambos, y quién es su contacto de datos; pregúntelo y verifíquelo después con documentos.
- Prácticas de seguridad — el estado de ISO/IEC 27001 como pregunta, ciclo de vida de desarrollo seguro y gestión de dependencias y vulnerabilidades.
- Estándares de codificación y revisión — disciplina de control de versiones, revisión de código, pruebas automáticas y qué significa «terminado» antes de fusionar.
- Traspaso y documentación — qué documentación existe en cada fase y dónde reside.
- Referencias a las que pueda llamar — una persona con nombre en un cliente anterior que atienda su llamada.
- Condiciones contractuales — calendario de pagos, aceptación, responsabilidad, terminación y asistencia en la transición.
- Moneda y mecanismo de precio — en qué moneda se fijan los precios y cómo se gestionan los movimientos de cambio a mitad de proyecto.
- Salida y transmisión — cómo se devuelven el trabajo, los accesos y el conocimiento si termina la relación.
Zona horaria, idioma y rutinas de comunicación
El solapamiento de zona horaria es un recurso, no una garantía: solo produce respuestas el mismo día si la colaboración está diseñada para aprovecharlo. Tres rutinas marcan la diferencia:
- Una ventana de solapamiento fija. Acuerde por escrito, al principio y con los dos husos horarios sobre la mesa, las horas que siempre están en vivo.
- Una cadencia de demostraciones. Software en funcionamiento mostrado a un ritmo fijo detecta los errores de dirección cuando todavía son baratos; los informes de estado, no.
- Un solo registro escrito. Decisiones en un documento compartido y no en llamadas a las que medio equipo se quedó fuera; para un equipo de varios idiomas, esto también es el rastro de auditoría.
Legal y datos: contratos, propiedad intelectual, KVKK y GDPR
Tres instrumentos jurídicos hacen la mayor parte del trabajo, y cada uno tiene una sola función:
- NDA — protege la revelación antes de que exista la relación. Fírmelo antes de compartir detalles técnicos y comerciales.
- Contrato — fija alcance, precio, aceptación, responsabilidad, terminación y transición. Alcance fijo o tiempo y materiales cambia el núcleo comercial, no la necesidad del resto.
- Cesión de propiedad intelectual — la cláusula que transfiere a usted la propiedad de lo construido. Debe cubrir código, documentación, configuraciones y derivados, y debe aplicarse desde la creación, no solo en el pago final.
| Tema | Pregunta | Documento |
|---|---|---|
| Ley aplicable y jurisdicción | Qué ley rige y dónde se sustancian las disputas | Contrato marco |
| Titularidad de la propiedad intelectual | Cuándo se transfieren los derechos y exactamente a qué | Cláusula de cesión de propiedad intelectual |
| Confidencialidad | Cuánto tiempo sobrevive la confidencialidad tras la terminación | NDA / contrato |
| Roles en datos personales | Quién es responsable y quién encargado del tratamiento, y para qué datos | Acuerdo de encargo de tratamiento |
| Transferencia transfronteriza | Qué datos salen del país y bajo qué mecanismo | Cláusula de transferencia / anexo |
| Subencargados | Quién más toca los datos y cómo se presta la aprobación | Acuerdo de tratamiento |
| Incidentes de seguridad | Plazo y contenido de la notificación ante una brecha | Anexo de seguridad |
| Auditoría y evidencia | Qué puede inspeccionar y con qué frecuencia | Cláusula de auditoría |
| Salida y devolución de datos | Cómo se devuelven o eliminan los datos y el código al final | Cláusula de terminación |
Expectativas de seguridad
La seguridad se gestiona mejor como un conjunto de preguntas verificables que como una declaración de confianza:
- ISO/IEC 27001 — pregunte si el proveedor lo tiene y qué cubre el alcance de la certificación; un certificado que cubre la oficina comercial pero no el equipo de entrega le dice algo muy concreto. Si no lo tiene, pregunte por escrito qué controles equivalentes existen.
- Ciclo de vida de desarrollo seguro — dónde se sitúa la seguridad en el diseño, la revisión de código y las pruebas, y si la gestión de dependencias y vulnerabilidades es rutinaria.
- OWASP Top 10 — una lista de comprobación muy utilizada con los riesgos de seguridad más comunes de las aplicaciones web; preguntar si forma parte de su revisión es una pregunta concreta y contestable, no un vago «¿es seguro?».
- Control de acceso — quién puede alcanzar sus repositorios, sus entornos y sus datos; cómo se concede el acceso, cómo se registra y cómo se retira cuando alguien se va.
Proyecto piloto y hitos
La herramienta de selección más fiable que existe es un piloto pequeño y pagado: trabajo real, código real, una fecha real y una factura real. Su propósito no es el tamaño del entregable, sino observar cómo trabaja el equipo cuando la especificación está incompleta, cuando una pregunta no es clara y cuando una fecha se mueve.
Diseñe bien el piloto:
- Que sea real. Una porción representativa del trabajo real, no una tarea de juguete que esconda toda la parte difícil.
- Defina «terminado» por escrito. Criterios de aceptación antes del inicio; de lo contrario, no aprenderá nada sobre la disciplina de alcance.
- Incluya un cambio a mitad de camino. Cómo gestiona el equipo un requisito cambiado le dice más que cómo gestiona uno limpio.
- Observe la comunicación. Tiempos de respuesta, preguntas hechas antes de construir y calidad de la demostración: eso es el producto.
- Fije de antemano la regla de decisión. Qué le haría extender, ampliar o detener; escrito antes del piloto, no racionalizado después.
Riesgos y cómo gestionarlos
| Riesgo | Cómo se manifiesta | Cómo gestionarlo |
|---|---|---|
| Riesgo de persona clave | El arquitecto principal o el desarrollador senior es el único que entiende las decisiones centrales | Obligaciones de documentación, trabajo en parejas sobre los módulos críticos y relevos designados en el equipo |
| Deriva de alcance | Se acumulan pequeños añadidos y el presupuesto original se estira sin que nadie decida | Procedimiento de cambios escrito, estimaciones de impacto antes de cada cambio y revisiones periódicas de alcance |
| Dependencia del proveedor | Solo el proveedor puede mantener el sistema; salir significaría reescribirlo | Código fuente y accesos en su poder desde el primer día, estándares de documentación y revisión independiente periódica |
| Moneda e inflación | Los precios en liras se mueven contra su presupuesto, o los costes se recortan en silencio para sostener una cifra ya ofertada | Precios fijados en una moneda con nombre, mecanismo declarado para los movimientos de cambio y cláusulas de revisión periódica de precios |
| Deriva de subcontratación | La entrega se desplaza en silencio a terceros sin nombre | Derecho de aprobación sobre los subcontratistas, cláusulas de transparencia y derecho a rechazar |
| Deterioro de calidad después del arranque | El equipo senior gana el contrato y un equipo junior hace el trabajo | Equipo con nombre en el contrato, cláusula de notificación de cambios y evidencias de revisión de código |
El riesgo de moneda merece una frase más de la que la tabla le dedica: la volatilidad de la lira es un riesgo contractual reconocido en los proyectos en Türkiye, y corta en ambos sentidos. Una lira al alza encarece su proyecto; una a la baja puede llevar a un proveedor a recortar en lo esencial para sostener un precio con el que ya no puede cubrir el equipo. Un contrato sin mecanismo de moneda acaba, sin ruido, entregando más caro o recortando en silencio, y ninguna de las dos cosas la planificó usted. Una moneda de contrato nombrada, con un mecanismo de ajuste declarado, protege a las dos partes y es una condición comercial normal que proponer, no una ofensa.
Costes: cómo se estructuran los precios
Los precios de este mercado se estructuran de unas cuantas maneras: tarifas mensuales por rol para un equipo dedicado, tarifas diarias para tiempo y materiales, pagos por hito para el alcance fijo y cuotas periódicas para el soporte continuo. Cada una sitúa el riesgo de cambio en un lugar distinto. El tratamiento completo, con las preguntas sobre lo que incluye una tarifa, está en la página de modelos de coste y precios.
Lo que corresponde aquí es la parte relevante para la selección: compare ofertas por el coste total de la relación, con la partida de cambios incluida, y no por la tarifa de titulación; y pregunte qué ocurre comercialmente cuando el alcance se mueve, porque la respuesta le dice qué modelo está comprando de verdad.
¿Quién no debe externalizar en Türkiye?
Una respuesta honesta, porque un encaje malo le cuesta a las dos partes:
- Proyectos que necesitan al equipo físicamente incrustado a diario. Si su proceso requiere a los desarrolladores en su oficina todos los días, el nearshore no encaja; contrate localmente.
- Organizaciones que no pueden definir la aceptación. Si en su lado nadie puede decir qué significa «terminado», ningún modelo de contrato salvará el proyecto; arregle eso primero.
- Construcciones de presupuesto ultrabajo y sin especificaciones. El escalón más barato de este mercado compite con el escalón más barato de todas partes, con los mismos patrones de fracaso.
- Trabajo que exige una jurisdicción que no puede verificar. Si su equipo legal o de cumplimiento no puede calificar el contrato y las condiciones de datos, no los firme.
Preguntas frecuentes
¿Es Türkiye un buen destino para externalizar software?
Para compradores de Europa y del Golfo, normalmente merece la evaluación: un solapamiento sustancial de zona horaria, un gran mercado de ingeniería centrado en Estambul y una posición de coste entre los precios offshore asiáticos y los de Europa occidental. Si es adecuado para usted depende de las preguntas de encaje de más arriba —competencias, calidad del contrato y protección de datos— y no del país por sí solo.
¿Qué modelo de colaboración conviene para un primer proyecto?
Un piloto pagado con alcance fijo y, después, uno de los dos modelos principales según lo que revele el piloto: alcance fijo si sus requisitos se estabilizan, tiempo y materiales o equipo dedicado si siguen evolucionando. Lo que conviene evitar en un primer proyecto es un compromiso de equipo abierto en el tiempo sin haber observado los hábitos de trabajo.
¿Quién es dueño del código?
Usted debe serlo, por contrato: una cláusula de cesión de propiedad intelectual que transfiera los derechos sobre código, documentación y derivados desde la creación y no solo en el pago final. Si un proveedor propone que la titularidad se transfiera «con el pago completo», negocie y defina qué sucede con el trabajo entregado por etapas.
¿Cómo afectan KVKK y GDPR a la externalización?
KVKK es el régimen de protección de datos de Türkiye, y el GDPR se aplica a usted cuando hay datos personales de la UE, dondequiera que esté ubicado el encargado. Para un comprador, las preguntas prácticas son qué datos cruzan la frontera, bajo qué mecanismo contractual, quién es responsable y quién encargado, y qué dice el acuerdo sobre subencargados y notificación de brechas. Busque asesoramiento jurídico sobre las respuestas, no sobre si debe hacer la pregunta.
¿Debo pedir ISO/IEC 27001?
Sí, como pregunta con seguimiento: ¿lo tiene el proveedor y qué cubre el alcance certificado? Un certificado que excluye al equipo de entrega no es evidencia sobre las personas que escriben su código; cuando no existe, pregunte qué controles escritos hay en su lugar.
¿Cuánto debe durar un piloto?
Defínalo por entregables y no por calendario: una porción representativa con criterios de aceptación, un cambio a mitad de camino y una demostración al final. Un piloto demasiado pequeño para revelar cómo maneja el equipo la ambigüedad no le enseña nada que valga el ahorro.
¿Cómo afronto la volatilidad de la lira?
Con el contrato y no con la previsión: una moneda de contrato nombrada, un mecanismo declarado para el movimiento del tipo de cambio y cláusulas de revisión periódica de precios si la relación es larga. La volatilidad de la lira es un riesgo reconocido en los proyectos en Türkiye; un mecanismo acordado en la firma sale más barato que una renegociación en el quinto mes.
¿Puede trabajar con mi equipo actual?
Pregúntelo directamente en el piloto: los equipos mixtos —su gente más la del proveedor— son habituales, y las preguntas que importan son cómo se registran las decisiones, de qué estándares sigue el código y cómo se transfiere el conocimiento cuando la relación cambia de forma. Como grupo, delimitamos los encargos como lo haría un equipo de operaciones, en torno a los sistemas y las restricciones con los que el negocio ya funciona, y eso suele ser el factor decisivo en una configuración mixta.
Fuentes y estándares
- ISO — entidad publicadora de ISO/IEC 27001 (gestión de la seguridad de la información); confirme la edición vigente y el alcance de la certificación antes de apoyarse en un certificado.
- OWASP — entidad publicadora de la lista de los 10 riesgos principales de seguridad de aplicaciones web citada en esta página.
- KVKK y GDPR se nombran como los marcos de protección de datos aplicables; esta página lista las preguntas que conviene hacer y no constituye asesoramiento jurídico. En esta página no se afirma ninguna tarifa, certificado, nombre de cliente ni cifra de rendimiento para WorldwideTradeX.
Páginas relacionadas
Desarrollo de software · Modelos de coste y precios · Lista de comprobación RFP para proveedores · ERP a medida frente a estándar · Auditoría y consultoría de TI · Consultoría de soluciones de IA · Infraestructura digital · Solicitar presupuesto