Checklist de onboarding remoto para empresas IT (2026) [+ Plantilla gratuita]

La mayoría de las listas de verificación de onboarding remoto están escritas para generalistas de RR. HH. Cubren el envío de equipamiento, los correos de bienvenida y la inscripción en beneficios, y ahí se quedan. No hay nada sobre cómo configurar un entorno de desarrollo, conceder el acceso correcto a los repositorios o conseguir que un nuevo ingeniero haga su primera PR antes del día cinco.

Esta checklist de onboarding remoto es diferente. Está construida específicamente para empresas IT: consultoras de software, equipos de producto y organizaciones de ingeniería distribuidas que contratan en remoto y necesitan que el onboarding funcione de verdad. Encontrarás una lista de verificación por fases (pre-onboarding hasta el primer mes), una tabla de responsabilidades por rol, errores comunes que cometen los engineering managers y las métricas que merece la pena seguir. También hay una plantilla gratuita en PDF y Notion al final.

Si estás contratando desarrolladores en remoto ahora mismo, la guía automatizar onboarding de desarrolladores remotos cubre la parte de automatización documental con más detalle. Este artículo se centra en el proceso humano.

El onboarding remoto en una empresa de software de 40 personas no es lo mismo que en una cadena de retail. Las diferencias importan.

El aprovisionamiento de accesos es, ante todo, un evento de seguridad. Un nuevo desarrollador necesita acceso a GitHub o GitLab, credenciales de AWS o GCP, configuración de VPN y SSO, y una invitación al gestor de contraseñas. Todo esto suele estar listo antes del día uno. Si fallas aquí, el ingeniero pasa 48 horas inactivo mientras se acumulan tickets de IT, o peor, recibe acceso sobreaprovisionado a entornos de producción que aún no debería tocar.

El paquete de documentación también cambia. El onboarding genérico se centra en contratos de trabajo y formularios fiscales. Las empresas IT normalmente necesitan un NDA para contratistas de software, un acuerdo de cesión de PI para desarrolladores y, a veces, un acuerdo de desarrollo de software separado, especialmente para contratistas. Estos documentos protegen tu código fuente y tu propiedad intelectual desde el día uno.

La cultura, además, es async-first. Según el GitLab Remote Playbook, los equipos de ingeniería remotos de alto rendimiento priorizan la comunicación escrita y la documentación exhaustiva. Trabajan con rituales asíncronos estructurados que un nuevo ingeniero debe entender rápidamente. Si no lo hace, o saturará a la gente en Slack o se quedará en silencio. Ambas son malas señales.

La primera contribución productiva, por suerte, es medible. El tiempo hasta el primer commit y el tiempo hasta la primera PR son métricas concretas que las guías genéricas de onboarding de RR. HH. nunca mencionan. Deberían ser tus indicadores de éxito principales, no "cómo se sintió el empleado después del primer día".

Honestamente, la mayoría de las listas de verificación de uso general tratan el onboarding IT como si estuvieras dando la bienvenida a un nuevo coordinador de cuentas por pagar. Los vacíos específicos para desarrolladores son la razón de ser de este artículo.

La checklist está organizada en cuatro fases. Cada fase tiene un responsable claro (RR. HH., IT o el manager que contrata). Síguelas en orden. Saltarse las tareas de pre-onboarding para "ahorrar tiempo" casi siempre genera problemas en la primera semana.

Antes de la fecha de inicio (Pre-onboarding)

Esta fase comienza en el momento en que se acepta la oferta, no el primer día.

Paquete de documentación (responsable: RR. HH., completar en 48 horas tras la aceptación de la oferta):

• Contrato de trabajo o contrato de servicios firmado y contrafirmado
• NDA firmado mediante gestión documental para empresas IT. El registro de auditoría verificado con blockchain garantiza autenticidad
• Acuerdo de cesión de PI firmado. Protege tu código desde el día uno
• Documentación fiscal completada (W-9 para contratistas en EE. UU., formularios correspondientes para tu jurisdicción)
• Verificación de antecedentes o referencias completada
• Materiales de inscripción en beneficios enviados (si es empleado a tiempo completo)

¿No estás seguro de la diferencia entre un contrato y un simple acuerdo? La guía de contrato vs acuerdo explica cuándo corresponde cada uno.

Aprovisionamiento de accesos IT (responsable: IT, completar 2–3 días hábiles antes de la fecha de inicio):

• Correo corporativo y cuenta SSO creados
• Invitación al gestor de contraseñas enviada (1Password, Bitwarden o equivalente)
• Credenciales de VPN configuradas. NIST SP 800-46 recomienda MFA en todo acceso remoto
• Cuenta de GitHub o GitLab aprovisionada con acceso de mínimo privilegio (solo repositorios específicos, no toda la organización)
• Credenciales de cloud configuradas con el rol IAM correcto (sin acceso a producción el primer día)
• Hardware enviado y entrega confirmada (portátil, monitor, periféricos)
• Herramientas de comunicación instaladas: Slack o Teams, Zoom, Loom
• Acceso a herramienta de gestión de proyectos: Jira, Linear o equivalente

Lectura previa enviada por el manager (3–5 días antes del inicio):

• Documento de visión general de la arquitectura o README compartido
• Acceso a wiki de ingeniería o espacio de Confluence concedido
• Documento de normas de trabajo del equipo (horarios async, expectativas de revisión de PR, ritmo de reuniones)
• Documento del plan 30-60-90 días compartido con antelación para que la nueva contratación pueda leerlo antes del día uno
• Buddy asignado y correo de presentación enviado

Día 1 — Las primeras impresiones cuentan

El primer día no es el momento para saturar de información. Es un día para generar confianza.

• Videollamada de bienvenida: manager + equipo inmediato (mantenla bajo 30 minutos: la gente está nerviosa)
• 1:1 con el manager: repasar el plan 30-60-90 explícitamente. No des por hecho que lo ha leído.
• Revisión IT: confirmar que todas las cuentas funcionan, la VPN conecta y las herramientas de desarrollo están instaladas
• Sesión de configuración del entorno de desarrollo: emparejar a la nueva contratación con un ingeniero senior para la configuración del entorno (Docker, desarrollo local, configuración del IDE). No mandes documentos y esperes lo mejor.
• Primer ticket asignado: elegir un problema pequeño y bien delimitado etiquetado como "good first issue" o equivalente. Algo completable en 1–2 días.
• Proceso de revisión de código explicado: estrategia de ramificación, convenciones de mensajes de commit, plantilla de PR
• Formación de seguridad completada: concienciación sobre phishing, política de manejo de datos, política de uso aceptable

Semana 1 — Cogiendo ritmo

• Inmersión en el stack tecnológico: días 1–2 centrados en herramientas de comunicación, días 3–4 centrados en orientación sobre el código base principal
• Primera revisión de código: la nueva contratación revisa una PR existente antes de escribir la suya propia. Esto se subutiliza como herramienta de onboarding.
• Sesión de pair programming: mínimo 2 horas con un ingeniero senior en el primer ticket
• 1:1 con el tech lead: decisiones de arquitectura, hoja de ruta técnica, prioridades del sprint actual
• Puntos de contacto sociales: café informal con 2–3 miembros del equipo (programarlos: no suceden de forma natural en equipos remotos)
• Revisión de fin de semana con el manager: qué no está claro, qué está bloqueado, qué va bien

Primer mes — De incorporado a productivo

• Primera PR mergeada en los primeros 5–7 días hábiles. Este es un hito, no solo una tarea.
• Revisión a los 30 días con el manager: rendimiento frente al plan, necesidades de acceso ajustadas, preguntas sobre cultura respondidas
• Auditoría de accesos: eliminar cualquier acceso temporal o sobreaprovisionado concedido durante la configuración
• Contribución a la documentación: la nueva contratación documenta una cosa que ha tenido que averiguar por sí misma (un hábito recurrente para pagar la deuda de onboarding)
• Comprobación cultural: ¿la comunicación async se siente natural? ¿Asiste a las reuniones recurrentes correctas?
• Plan de desarrollo iniciado: qué habilidades desarrollar en los meses 2–3, estructura de mentoría confirmada

Plan 30-60-90 días para contrataciones IT

El plan 30-60-90 días da a las nuevas contrataciones objetivos explícitos en lugar de expectativas vagas de ramp-up. Mantenlo concreto.

Días 1–30 (Aprender): Entender el código base, entregar 2–3 tickets pequeños, completar la formación de seguridad, aprender las normas async del equipo. Éxito = primera PR mergeada y auditoría de accesos limpia.

Días 31–60 (Contribuir): Liderar una funcionalidad de complejidad media de principio a fin, participar activamente en revisiones de código, identificar un área de mejora de procesos. Éxito = funcionalidad entregada en staging.

Días 61–90 (Liderar): Liderar un proyecto o sprint pequeño, proponer una mejora de proceso o herramienta, comenzar a mentorizar si es senior. Éxito = contribución medible a la velocidad del sprint.

El fallo de onboarding más común no es un elemento que falte en la checklist: es que todo el mundo asume que otra persona lo está gestionando. Esta tabla hace explícita la propiedad. Si dos personas son responsables de algo, en realidad no lo es ninguna.

Estos errores aparecen una y otra vez en equipos de ingeniería que por lo demás funcionan bien. La mayoría se pueden corregir con un solo cambio de proceso.

Retrasar el aprovisionamiento de accesos hasta el primer día es el error más fácil de evitar. Esperar hasta la primera mañana del ingeniero para crear cuentas significa que pasará la mitad del día uno mirando colas de tickets de IT. La VPN, GitHub y SSO deberían estar listos 48 horas antes de la fecha de inicio. Es el cambio que más retorno te da por el menor esfuerzo.

Sobreaprovisionar accesos "para ser amable" es otro clásico. Dar a un nuevo ingeniero acceso completo a la organización en GitHub, o derechos de administrador en AWS, es un error con buenas intenciones. Crea exposición de seguridad y, en la práctica, le dificulta encontrar lo que realmente necesita. El acceso de mínimo privilegio con una ruta de escalado documentada es mejor para todos. NIST SP 800-63 recomienda el control de acceso basado en roles desde el día uno.

Saltarse el paquete de documentación antes de empezar a trabajar es arriesgado. No quieres que un desarrollador escriba código antes de que se firme el acuerdo de cesión de PI. No es paranoia, es un riesgo real de propiedad intelectual. Gestiona el paquete de documentación (NDA, cesión de PI, contrato de trabajo o de servicios) antes del primer commit, no después. Puedes procesarlo todo de forma digital con firma electrónica y gestión de contratos diseñada para equipos IT.

Enviar documentación sin una sesión en vivo tampoco funciona. "Aquí tienes nuestra wiki de 80 páginas" no es onboarding. Pasear a un nuevo ingeniero por la arquitectura durante 45 minutos y luego señalarle la documentación funciona. La documentación async es para consulta, no sustituye a la orientación sincrónica.

No tener un hito de primera PR es dejar a la nueva contratación en tierra de nadie. La primera PR mergeada es el momento en el que un ingeniero pasa de sentirse visitante a sentirse parte del equipo. Los que no han entregado nada para el día siete empiezan a preguntarse si encajan. Intégralo explícitamente en el plan: un ticket bien delimitado, una sesión de pair programming, una revisión de código oportuna.

Saltarse la auditoría de accesos a los 30 días es invitar a problemas. Los accesos temporales se acumulan. El nuevo ingeniero recibe permisos de administrador temporales para una tarea específica, y nadie los elimina. Ejecuta una auditoría de accesos formal a los 30 días y otra a los 90. Toma 20 minutos y cierra una brecha de seguridad real.

Según la investigación de SHRM, las organizaciones con programas de onboarding estructurados ven una retención de nuevas contrataciones un 50 % mayor. En IT, esa brecha de retención es aún más costosa: reemplazar a un ingeniero de nivel medio cuesta entre el 50 % y el 200 % de su salario anual.

La mayoría de las empresas miden el éxito del onboarding con una encuesta de satisfacción a los 30 días. Es mejor que nada, pero no es suficiente. Estas son las métricas que realmente te dicen si el onboarding está funcionando.

El time-to-first-commit mide cuántos días calendario pasan desde la fecha de inicio hasta el primer commit de código. Para ingenieros experimentados, deberían ser 2–3 días. Si tarda más, tu proceso de configuración del entorno de desarrollo está roto.

El time-to-first-PR te dice cuánto tarda una nueva contratación en enviar y mergear su primera pull request. El objetivo es 5–7 días hábiles. Los ingenieros que no han entregado nada para el día 10 suelen reportar sentirse desconectados e improductivos.

La tasa de retención a 30 días responde a una pregunta directa: ¿qué porcentaje de nuevas contrataciones sigue en la empresa a los 30 días? La rotación temprana en tecnología suele ser un fallo de onboarding, no de contratación. Haz seguimiento por cohorte.

El access audit clean rate mide, en la auditoría de accesos a los 30 días, qué porcentaje de cuentas tiene cero permisos sobreaprovisionados. Esta es una métrica tanto de seguridad como de calidad de onboarding. El sobreaprovisionamiento significa que el aprovisionamiento no se hizo con cuidado.

El training completion rate verifica si la nueva contratación ha completado la formación de concienciación en seguridad, la de revisión de código y cualquier otra de cumplimiento requerida antes de finales de la segunda semana. La formación incompleta genera riesgo e indica una brecha de proceso.

La manager-reported productivity se basa en una pregunta sencilla en la revisión a los 30 días: "En una escala del 1 al 5, ¿qué tan productiva es esta persona en relación con las expectativas?" Agrega esto entre contrataciones para detectar problemas sistémicos de onboarding.

El Buffer State of Remote Work Report muestra constantemente que sentirse desconectado del equipo es el principal desafío para los trabajadores remotos. Estas métricas te ayudan a detectarlo pronto, antes de que se convierta en una renuncia.

No necesitas un producto dedicado de onboarding. La mayoría de las empresas IT ya tienen todo lo que necesitan: el vacío suele ser de proceso, no de herramientas. Dicho esto, esto es lo que el stack debería cubrir.

Para identity and access management, usa Okta, JumpCloud o Google Workspace para SSO. Un gestor de contraseñas (1Password Teams, Bitwarden Business) cubre las credenciales que no usan SSO. MFA en todo: tokens de hardware para cuentas de administrador, apps de autenticación para acceso estándar.

En comunicación, Slack o Microsoft Teams cubren la mensajería async. Zoom o Google Meet para vídeo sincrónico. Loom para videotutoriales async. Es útil para orientaciones de arquitectura: graba una vez, reutiliza para cada nueva contratación.

Para project management y documentación, Jira o Linear gestionan el trabajo de sprint, y Confluence o Notion almacenan el conocimiento. La wiki de ingeniería es probablemente el activo de onboarding más subinvertido en la mayoría de los equipos.

El entorno de desarrollo necesita Docker para entornos locales reproducibles. Un script de configuración documentado que realmente funcione, pruébalo en una máquina limpia trimestralmente. GitHub o GitLab para control de versiones, con reglas de protección de ramas configuradas antes de la primera PR de la nueva contratación.

En document signing y contracts es donde muchas empresas IT aún usan PDFs adjuntos por correo y esperan lo mejor. Para firmar NDAs, acuerdos de cesión de PI y contratos de trabajo, necesitas firma electrónica y gestión de contratos diseñada para equipos IT, con verificación blockchain, registros de auditoría con marca de tiempo y la capacidad de enviar un paquete de documentación completo en un único flujo de trabajo en lugar de tres hilos de correo separados.

El objetivo no es añadir herramientas. Es asegurarse de que cada herramienta del stack tiene un responsable claro y está configurada antes del primer día de la nueva contratación.