Lista de verificación para la incorporación de desarrolladores
Una rampa de acceso cronológica desde la clonación hasta la primera PR fusionada para ingenieros de Python nuevos (o nuevos en este sistema), ordenada antes de la llegada, día 1, semana 1 y continuo.
Cómo usar esta lista de verificación
- Sigue los elementos en orden cronológico: los elementos anteriores desbloquean los posteriores.
- El compañero es responsable de marcar las casillas junto con el nuevo desarrollador, no por él.
- Cumple el mínimo requerido antes del día 2; los elementos del techo pulen la semana 1.
- Cualquier elemento que exceda el tiempo asignado es un error de herramientas o documentación; arréglalo para la próxima contratación.
Fase 1 - Antes de que lleguen
- Acceso previo al archivo: Organización de GitHub, CI, consola en la nube (staging de solo lectura), rastreador de errores, wiki de documentación; el acceso es el principal bloqueo del primer día.
- Enviar README + enlace al documento de incorporación: Documento canónico en el repositorio
docs/onboarding.mdcon el nombre del propietario. - Asignar compañero: Un par (no el gerente) con un control diario de 15 minutos la primera semana.
- Entorno de desarrollo de hardware o en la nube: Imagen de portátil o plantilla de Codespaces con Python 3.14 + uv documentado.
- Primer ticket listo: "Buena primera tarea" limitada a 1-2 archivos con criterios de aceptación claros.
Fase 2 - Día 1
- Clonar e iniciar:
git clone,uv sync,uv run pytest -qen verde según la Lista de verificación de configuración del entorno. - Ejecutar la aplicación localmente:
uv run uvicorn app.main:app --reloadomake run; accede a/healthen el navegador o usa curl. - Extensiones del IDE: Python, Ruff, mypy/pyright según el estándar del equipo; formato al guardar habilitado.
- Conocer al equipo: Resumen de arquitectura de 30 minutos: monolito vs. servicios, principales almacenes de datos, cadencia de implementación.
- Orientación del código base: Orientación del código base con preguntas y respuestas del compañero.
Fase 3 - Semana 1
- Rastrear una solicitud de extremo a extremo: Sigue la ruta HTTP hasta la base de datos y viceversa; dibuja un diagrama personal.
- Leer convenciones: Convenciones y guía de estilo - reglas de ruff, formato de commit.
- Observar revisión de código: El compañero revisa una PR abierta: lo que esperan los revisores (Directrices de revisión de código).
- Primera PR fusionada: Pequeño cambio real (corrección de documentación, adición de prueba, error tipográfico en mensaje de error), no una rama de descarte.
- Registrar lagunas en la documentación: Cada "Tuve que preguntar" se convierte en una PR al documento de incorporación esa misma semana.
Fase 4 - Continuo (30-90 días)
- Observar guardia (si corresponde): Emparejarse en un incidente de staging o simulacro de incendio.
- Ser responsable de una pequeña función: Ticket de tamaño de 2-3 días con nota de diseño si es necesario.
- Presentar aprendizaje: Demostración de 5 minutos o documento sobre un subsistema descubierto.
- Contribuir a python-rules o ADR: Proponer una aclaración de regla a partir de confusiones durante la incorporación.
- Retroalimentación: Nuevo empleado + compañero + gerente: qué agregar/eliminar de esta lista de verificación.
Aplicación de la lista de verificación en orden
- Fase 1-2 (1-10): Acceso y pruebas locales en verde antes de esperar contribuciones de código.
- Fase 3 (11-15): La primera PR fusionada demuestra que el pipeline funciona para esta persona, no solo para CI.
- Fase 4 (16-20): La propiedad y la retroalimentación cierran el ciclo para la próxima contratación.
Preguntas frecuentes
¿Omitir la lista de verificación para contrataciones sénior?
Comprime el cronograma pero aún ejecuta el acceso, la arquitectura y las convenciones; los sénior omiten pasos y se convierten en puntos únicos de falla.
¿Incorporación remota?
Misma lista de verificación; agrega horas de superposición de zona horaria y resumen de arquitectura grabado.
¿Contratista vs. Empleado a tiempo completo?
Los contratistas necesitan la misma incorporación técnica; acorta la Fase 4 si el compromiso es corto.
¿Múltiples repositorios?
Comienza con un repositorio de servicio "hogar"; documenta los enlaces entre repositorios en el documento de orientación.
Relacionado
- Lista de verificación de configuración del entorno - herramientas
- Orientación del código base - estructura
- Mejores prácticas del equipo - normas del equipo
- Configuración de Git - configuración de git
Versiones de la pila: Esta página se escribió para Python 3.14.0 (estable 3.14, mantenimiento 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+ y uv 0.6+.