Harvard · Resume

Documentación y UX 2026

CV de Redactor/a Técnico/a (Formato Harvard)

Convierte la complejidad técnica en documentación que la gente sí termina de leer — y demuestra que tu CV también lo hace.

Empezar mi CVgratis · sin login
Harvard Resume··~5 min

¿Cómo se hace un CV de CV de Redactor/a Técnico/a (Formato Harvard) en formato Harvard?

A un redactor técnico lo contratan para reducir tickets de soporte, acortar el tiempo hasta la primera llamada exitosa y hacer usable un producto complejo — no para escribir prosa bonita. Un buen CV en formato Harvard demuestra que documentas como código (Markdown, Git, CI), que dominas la arquitectura de información y las referencias de API, y que conectas cada documento con un resultado medible como la tasa de deflexión o el tiempo de onboarding. Esta guía te enseña a cuantificar un trabajo que normalmente queda escondido en Confluence.

Qué buscan los recruiters

  • Dominio de docs-as-code: Markdown/AsciiDoc/reStructuredText escrito en Git con pull requests, generadores de sitios estáticos (Docusaurus, MkDocs, Hugo, Antora) y builds en CI (linting con Vale, verificación de enlaces rotos)
  • Documentación de API y para desarrolladores: generación de referencia con OpenAPI/Swagger, colecciones de Postman, ejemplos de código en 2+ lenguajes y herramientas como Redocly, Stoplight o ReadMe
  • Autoría estructurada y single-sourcing: DITA, autoría basada en topics y herramientas CCMS/HAT (Paligo, MadCap Flare, Oxygen XML, Adobe FrameMaker)
  • Impacto medible: tasa de deflexión de documentación, reducción de tickets de soporte, tiempo hasta la primera llamada exitosa (API), tasa de éxito de búsqueda y satisfacción del documento (CSAT / pulgar arriba)
  • Sistemas de estilo y calidad: propiedad de una guía de estilo (Microsoft/Google Writing Style Guide o una propia), reglas de Vale y objetivos de legibilidad (nivel Flesch-Kincaid)
  • Credibilidad transversal: trabajar desde tickets de ingeniería, leer código/PRs, conducir entrevistas con expertos (SME) y publicar la documentación dentro del ciclo de release del producto

Secciones requeridas, en este orden

Encabezado y banda de skills

  • Usa un encabezado de una línea: nombre, email, LinkedIn y la URL de un portafolio o docs publicadas — en un redactor, la falta de portafolio es una alerta roja
  • Agrupa una banda de skills compacta por categoría: Autoría (Markdown, DITA, AsciiDoc), Herramientas (Docusaurus, MadCap Flare, Git, Vale), API (OpenAPI, Postman, Redocly) y Dominios (SaaS, fintech, devtools)
  • Menciona las guías de estilo con las que has trabajado (Microsoft Writing Style Guide, estilo de docs de Google, propia) — demuestra que sabes que existen reglas de la casa
  • Evita adjetivos genéricos como 'detallista' o 'excelente comunicador'; en un redactor el propio CV es la prueba, así que usa la línea para una herramienta o un dominio concreto

Logros de experiencia (fórmula Harvard XYZ)

  • Empieza cada viñeta con el resultado que le importa a un líder de documentación: deflexión de tickets, tiempo de onboarding, éxito de búsqueda — luego nombra el set de docs y la herramienta
  • Cuantifica la escritura: número de artículos/endpoints documentados, páginas migradas, % de reducción de contactos de soporte o % de mejora en el CSAT de la documentación
  • Demuestra propiedad del proceso, no solo del output: 'establecí el pipeline docs-as-code', 'redacté la guía de estilo del equipo', 'gestioné el SLA de revisión' — señalan seniority
  • Incluye la mecánica de colaboración — entrevistas con SMEs, lectura de PRs, trabajo desde Jira — para que se vea que operas dentro de ingeniería, no al lado

Portafolio, formación y certificaciones

  • Añade una línea de portafolio con artefactos concretos: 'Referencia de API publicada (en vivo), guía de onboarding y runbook de migración' con la URL — es lo primero que abre quien recluta
  • Lista certificaciones con precisión: Google Technical Writing, participación en Write the Docs, documentación de API (curso de Postman / 'I'd Rather Be Writing') o una credencial CPTC
  • La formación ocupa una o dos líneas: título, institución, año — añade asignaturas relevantes (comunicación técnica, informática, UX) solo si refuerzan una experiencia corta
  • Si vienes de otro perfil (ingeniería, soporte, QA), preséntalo como ventaja: profundidad de dominio que te permite documentar sin que te lleven de la mano

Ejemplo en formato Harvard

CV de Redactor Técnico — Formato Harvard
Harvard format · 1 página

Bullets fuertes vs débiles

Antes

Escribí y mantuve la documentación de los productos de software de la empresa.

Después

Reduje el volumen de tickets de soporte un 31% en 6 áreas de producto reescribiendo más de 140 artículos del centro de ayuda en docs-as-code (Markdown + Docusaurus) e instrumentando cada uno con feedback de pulgar arriba para priorizar las 20 peores páginas.

Abre con el % de deflexión, nombra el alcance (140+ artículos, 6 áreas), la toolchain y el bucle de feedback que guió la priorización.

Antes

Mejoré la documentación de la API y la hice más fácil de usar para los desarrolladores.

Después

Reduje el tiempo hasta la primera llamada exitosa a la API de 47 a 12 minutos generando una referencia OpenAPI 3.1 en Redocly, añadiendo ejemplos de código ejecutables en Python y JavaScript y publicando un quickstart de 5 minutos validado con 8 pruebas de usabilidad con desarrolladores.

Usa una métrica real de developer experience, nombra la versión de la spec y las herramientas, y muestra las pruebas de usabilidad que respaldan la afirmación.

Antes

Ayudé a montar un nuevo sistema de documentación y una guía de estilo.

Después

Implementé el pipeline docs-as-code (Git, MkDocs, linting con Vale en CI) y redacté una guía de estilo de 40 reglas adoptada por 14 ingenieros, recortando el tiempo de revisión de docs un 60% y dejando los enlaces rotos en cero dentro de CI.

Muestra propiedad del proceso, la disciplina de linting/CI, la escala de adopción y dos mejoras concretas de antes/después.

Antes

Migré la documentación antigua a una nueva plataforma.

Después

Migré 1.200 páginas heredadas de Confluence a una arquitectura DITA single-sourced en Paligo, reutilizando el 38% del contenido como topics compartidos y reduciendo el coste de localización a 6 idiomas en unos 45.000 USD anuales.

Cuantifica el volumen, nombra el enfoque de autoría estructurada, el % de reutilización y conecta el single-sourcing con un ahorro real de localización.

Errores comunes específicos

  • No incluir enlace a portafolio ni a docs publicadas — para un redactor es descalificante; quien recluta quiere leer tu trabajo real, no tu descripción de él
  • Listar herramientas como un muro de logos sin mostrar qué construiste con ellas; 'MadCap Flare' no dice nada sin el entregable y el resultado asociados
  • Verbos vagos ('apoyé en', 'ayudé a mantener') que ocultan si fuiste dueño del set de docs o solo corregiste erratas
  • Cero métricas — sin tasa de deflexión, sin tiempo de onboarding, sin CSAT — lo que hace ver la escritura como trabajo no medible
  • Erratas, mayúsculas inconsistentes o tiempos verbales mezclados en el CV de un redactor; el documento es la muestra de trabajo y un error pequeño se lee como fatal

Tu CV empieza aquí. Decides después si pagas.

Empezar mi CV

Preguntas frecuentes

¿Cómo cuantifico la redacción técnica si no controlo las analíticas?
Usa indicadores que puedas defender: número de artículos o endpoints documentados, páginas migradas, reducción de preguntas repetidas en soporte (pide al líder de soporte las etiquetas de tickets), tiempo de revisión de docs o feedback de pulgar arriba/abajo en las páginas. Incluso 'documenté los 84 endpoints del lanzamiento de la API v2' es concreto. Si de verdad no tienes números, cuantifica el alcance y la adopción (p. ej., 'guía de estilo adoptada por 14 ingenieros').
¿Necesito saber programar para ser redactor técnico?
Para documentación de API o para desarrolladores, sí — al menos lo suficiente para leer código, ejecutar una petición curl, editar un ejemplo y trabajar en Git con pull requests. Pon en tu banda de skills los lenguajes que sabes leer (Python, JavaScript, SQL). Para documentación de usuario final o hardware no se exige programación profunda, pero el dominio de Git y Markdown es cada vez más imprescindible.
¿Debo incluir un enlace a portafolio o adjuntar muestras de escritura?
Incluye una URL de portafolio en vivo en tu encabezado — es la línea de mayor apalancamiento en el CV de un redactor. Enlaza a docs reales publicadas (referencia de API, quickstart, runbook). Si tu mejor trabajo está tras un login o NDA, construye un set público pequeño: extractos redactados o un sitio de docs propio para una herramienta open source.
¿Vale la pena aprender docs-as-code si vengo de Word/FrameMaker?
Sí — la mayoría de roles modernos de software ya esperan Markdown o AsciiDoc en Git con checks de CI (Vale, verificadores de enlaces) y un generador de sitios estáticos (Docusaurus, MkDocs). No necesitas ser desarrollador, pero mostrar un proyecto docs-as-code en tu CV amplía mucho los puestos a los que aplicas. Las skills de autoría estructurada/DITA (Flare, Oxygen, Paligo) siguen siendo muy valoradas en grandes empresas e industrias reguladas.

Recursos relacionados