¿Cómo podemos valorar y estimar los proyectos independientes de redacción técnica?

Estimar proyectos de redacción técnica es un arte, sin embargo, hay algunas buenas pautas. El libro “Gestionando sus proyectos de documentación” de JoAnn Hackos tiene excelentes consejos. Cuando calculo un proyecto, lo primero que hago es averiguar los parámetros básicos: ¿audiencia? ¿contenido? tipo de información necesaria: procedimientos más información de referencia y de concepto, información de capacitación, etc. ¿Hay alguna guía de estilo que deba seguirse? ¿Cómo se entregará la documentación? ¿Hay documentación existente para actualizar / revisar, y en qué forma: MS Word, Framemaker, HTML, etc.?
Entonces, cuento lo que se puede contar. Por ejemplo, si puedo obtener acceso a un prototipo de producto o especificaciones de interfaz de usuario (UI), cuento cada control en cada página, más todas las áreas nombradas de las páginas, más todas las páginas en sí. Los controles incluyen botones, campos, controles deslizantes, elementos de menú, etc. Obtenga un total de todas estas cosas. Cada uno de estos (probablemente) debe estar documentado. Entonces quiero saber qué información estará disponible para los escritores y qué recursos humanos: prototipos, especificaciones (cuántos y de qué tipo), desarrolladores, evaluadores, expertos en marketing, etc. ¿Con qué frecuencia se actualizan las especificaciones y otros documentos? ¿Hay casos de uso / historias de usuario, diagramas de flujo, documentos de requisitos, documentos de diseño, etc.? Cuantos de cada uno? – El número le da una idea del alcance del proyecto, pero también de la madurez del proceso; muchas especificaciones sugieren que le resultará mucho más fácil obtener la información que necesita.
Todo esto comienza a darme una idea del alcance del proyecto. Entonces necesito saber el plan para la documentación. Por ejemplo, solo queremos actualizar la documentación 2.0 con los cambios para 2.1. O bien, nunca hemos tenido documentación real del cliente, debe escribirlo todo desde cero. O bien, tenemos toda nuestra documentación en archivos de Word que tienen docenas de capturas de pantalla y diagramas cada uno, de modo que cada vez que abre un archivo tiende a bloquear su máquina, y queremos que migre la documentación a MadCap Flare. Etc. Hasta que sepa todo o casi todo lo anterior, no puede crear ningún tipo de estimación útil. Armado con la información anterior, puede comenzar a hacer algunos cálculos. Una buena cifra aproximada es de 4 horas de trabajo para un escritor técnico con experiencia moderada con acceso a buenas especificaciones del producto y expertos de producto útiles para escribir 1 página de documentación del usuario, o al mismo tiempo para escribir ayuda en línea para 1 página de IU que tiene 15 o menos controles sobre él. Aumente o disminuya esa cifra según su estimación de la madurez del proceso del equipo del producto: si los desarrolladores no tienen tiempo para interactuar con los escritores técnicos y las especificaciones rara vez se actualizan, aumente la estimación en un 100%, por ejemplo. Puede encontrar otra información útil buscando en estos temas: madurez del proceso, ciclo de vida del desarrollo de software.