any2.video vs. contratar a un redactor técnico: dos respuestas al mismo problema de cobertura
Un buen redactor técnico es una de las contrataciones con más impacto que puede hacer una empresa de software, y nada de lo que hay aquí es un argumento en su contra. La documentación escrita y el video verificado responden a mitades distintas del problema de cobertura, y elegir entre ellos es en realidad preguntarse qué mitad está rota ahora mismo.
Qué demuestra cada opción
| Pregunta | Redactor técnico | any2.video |
|---|---|---|
| Qué produce | Texto que se puede buscar, enlazar y corregir. | Una grabación en la que la tarea se completa, más una guía escrita. |
| Responde a “dónde está el botón” | Con palabras, que el lector tiene que trasladar a la pantalla. | Mostrándolo. |
| Responde a “por qué existe esto” | Muy bien. Para eso está el texto. | Mal. Al video se le da mal el material de referencia. |
| Velocidad de cobertura | Rápida para el texto, lenta para todo lo que necesite una captura de pantalla. | Dos días por tarea, en lotes. |
| Dónde se encuentra | Tu sitio de documentación y los buscadores. | YouTube y los asistentes de IA, donde se hacen las preguntas sobre productos. |
| Mantenerse al día | Depende de la disciplina y del proceso de revisión. | Una etiqueta de versión y una nueva ejecución con cada versión. |
Cuándo un redactor técnico es la opción adecuada
- Tu documentación está incompleta, es contradictoria o nadie la cuida. Arregla eso primero. Un video encima de una mala documentación solo propaga el error.
- El contenido es material de referencia: parámetros, superficies de API, límites, explicaciones conceptuales.
- Los lectores necesitan buscar, copiar y enlazar. Nadie copia un comando de un video.
- Necesitas el contenido dentro del proceso de publicación de versiones, no al margen.
Cuándo no lo es
- El paso escrito existe y los usuarios siguen haciéndolo mal, lo que suele significar que la pantalla no se parece a la frase.
- La pregunta es “¿funciona de verdad?”, y eso el texto no puede zanjarlo, pero la evidencia en pantalla sí.
- Tus compradores se están formando una opinión en YouTube, donde tu documentación no aparece.
- El redactor que contrataste se pasa la semana haciendo capturas de pantalla en lugar de escribir.
El orden en que conviene hacerlo
Primero, la documentación. Si el procedimiento escrito está mal, un video del procedimiento equivocado es un procedimiento equivocado más convincente. Hemos rechazado trabajos por este motivo y lo volveríamos a hacer.
Cuando la documentación ya es correcta, lo que falta no es información, sino prueba y reconocimiento. Un usuario que ha leído el paso y sigue sin encontrar el interruptor no necesita volver a leer la frase. Necesita ver la pantalla.
Cada paso a paso viene con texto
Por eso la guía escrita y las notas de solución de problemas están incluidas en lugar de venderse como un extra. Cada ejecución verificada produce los pasos exactos que funcionaron, en orden, con los intentos que fallaron y sus soluciones. Ese resultado a menudo es mejor que lo que había en la documentación, porque salió de una ejecución y no de la memoria, y tu redactor puede pasarlo directamente a la documentación.
Qué gana un redactor con esto
Hacer capturas de pantalla es lo que menos valor aporta del trabajo de un redactor técnico, y se le come la semana. Una ejecución verificada le entrega un registro con marcas de tiempo de lo que ocurrió realmente, que es la materia prima que iba a tener que reconstruir a mano.
Preguntas
¿Deberíamos contratar a un redactor técnico o comprar video?
Si la documentación está mal o no existe, contrata primero al redactor. Un video basado en documentación inexacta multiplica el error. Si la documentación es sólida y los usuarios siguen atascándose, lo que falta es prueba y no información, y eso es lo que aporta un paso a paso verificado.
¿El video sustituye a nuestra documentación?
No, y no debería. El texto se puede buscar y copiar, y corregirlo es barato. Al video se le da mal el material de referencia y se le da bien mostrar cómo termina una tarea.
¿Recibimos algo que pueda usar nuestro redactor?
Sí. Cada paso a paso incluye los pasos exactos que funcionaron y los intentos que fallaron, generados a partir del registro de ejecución. La mayoría de los equipos lo pegan directamente en su documentación.
La forma más rápida de zanjar esto es una tarea, hecha de las dos maneras. El primer video de muestra es gratis.
$ get-sample → $ cd /library