¿Pasos para asegurar que los detalles importantes no se editan de los documentos técnicos?

7

Como muchos aquí, estoy seguro, mi empresa tiene una persona que actúa como enlace entre el desarrollo y la mayoría de las otras áreas de la empresa, así como a nuestros clientes. La mayoría de las comunicaciones relacionadas con nuevos lanzamientos, correcciones, problemas conocidos, etc. se realizan a través de esta persona.

Sin embargo, debido a que esta persona no es un desarrollador y no está profundamente involucrado en los proyectos de desarrollo, a veces lo que los desarrolladores envían para su difusión se edita por brevedad o simplicidad, y en el proceso, se pierden los detalles clave o las sutilezas.

He estado presionando para un proceso de revisión que incluya al autor del documento original, sea lo que sea, antes de que se publique el material. Entre otras cosas, creo que esto permitiría que la persona con el mayor conocimiento técnico sobre lo que se habla (el que realmente escribió el código para el nuevo programa, característica o solución) pueda hacer una aportación sobre cualquier cosa que pueda haber sido simplificada o simplificada. ha recibido un error de hecho por el proceso de edición.

La persona que maneja la comunicación, por su parte, siente que el problema es la educación; La persona es relativamente nueva en la empresa y no tiene una amplia experiencia con todas las aplicaciones de software y otros productos que el desarrollo produce y respalda. La persona siente que a medida que obtiene esta experiencia a través de la capacitación y la lectura del material que llega a través de sus manos, el problema se resolverá solo. También sienten que la ida y vuelta desperdiciaría el tiempo.

Creo que hay mérito en ambos sentidos. ¿Qué piensan ustedes?

    
pregunta KeithS 28.09.2011 - 21:50

3 respuestas

4

No estoy seguro de que los dos lados del debate realmente estén diciendo cosas diferentes.

Si el desarrollador que escribe las notas de la versión revisa la versión editada antes de que se publique, esa información es una de las formas más eficientes para que el coordinador conozca todas las aplicaciones que produce y respalda la compañía. Esto ayudará al coordinador a conocer dónde hay complejidad en la línea de productos y dónde es más fácil resumir y simplificar las descripciones. Con el tiempo, a medida que el coordinador se entera de lo que pueden simplificar y de lo que no pueden, los desarrolladores gastarán cada vez menos tiempo en revisar la documentación, por lo que cada vez se dedicará menos tiempo al trabajo. Una vez que el coordinador esté completamente al día, los desarrolladores probablemente le darán un vistazo casual a las ediciones antes de aprobarlas en la gran mayoría de los casos.

    
respondido por el Justin Cave 28.09.2011 - 22:21
4

Así que acepta dejar de tener las revisiones cuando las revisiones dejen de encontrar algo útil. Sin embargo, en mi experiencia, la gente llega a valorarlos después de un cierto tiempo. Para ayudar al principio, deje en claro que las revisiones no son una acusación de ningún individuo, solo un reconocimiento de que diversos puntos de vista tienden a crear un resultado más sólido.

    
respondido por el Karl Bielefeldt 28.09.2011 - 22:16
0
  

presionando para un proceso de revisión que incluya al autor del documento original, sea lo que sea, antes de que se publique el material

La palabra empujar de alguna manera me hace sentir que estás experimentando ciertas dificultades para llegar allí, ¿verdad? Si ese es el caso, preferiría en cambio tirar del proceso inverso de revisar los documentos anteriores .

Esa forma de tirar es fácil: por lo general, no se necesitan aprobaciones para simplemente revisar el documento publicado y transmitir sus comentarios. E incluso puedes mantener un buen seguimiento sin tener que recurrir a otra persona fuera del equipo de desarrollo. Solo usa tu rastreador de problemas (supongo que tienes uno, ¿no?) Para recopilar los datos.

  • "Problema # 1234 creado para revisar Memo 666 y proporcionar comentarios. - Problema 1234 asignado a Bob Programmer. - Bob Programmer pasó 2 horas en el análisis solicitado por Issue 1234. - Bob actualizó el Issue 1234 con una copia del correo Memo 666: dev team notes que se envió a Jane Liason con el equipo de dev, que contiene 56 correcciones, aclaraciones y enmiendas. El número 1234 está cerrado. "

En una nota relacionada, la pérdida de detalles o sutilezas puede no ser un problema tan grave como el que percibes. Quiero decir que si usted convence a ese liason de que su mensaje anterior no detectó algo realmente importante, podría ser fácil para ella pasar la corrección. Esto es especialmente cierto si ese tipo se especializa en comunicación.

  • Una vez estuve trabajando estrechamente con un profesional de marketing y ella me mostró algunos de los trucos típicos que usan en la práctica de las comunicaciones. Como decir cosas asertivas que resultan fáciles de descartar después. O como redactar correcciones despiadadas de errores tontos de una manera que suena como expandir lo que se dijo anteriormente. Bastante asombroso.
respondido por el gnat 29.09.2011 - 10:17

Lea otras preguntas en las etiquetas