I passaggi per garantire che i dettagli importanti non vengano modificati dai documenti tecnici?

Non sono sicuro che i due lati del dibattito stiano davvero dicendo cose diverse.

Se lo sviluppatore che scrive le note sulla versione rivede la versione modificata prima di uscire, quel feedback è uno dei modi più efficienti per il coordinatore di conoscere tutte le applicazioni che l'azienda produce e supporta. Ciò aiuterà il coordinatore a capire dove c'è complessità nella linea di prodotti e dove è più facile riassumere e semplificare le descrizioni. Col passare del tempo, mentre il coordinatore apprende ciò che è in grado di semplificare e ciò che non può, gli sviluppatori dedicheranno sempre meno tempo a rivedere la documentazione, in modo da dedicare sempre meno tempo all'approvazione. Una volta che il coordinatore è completamente in grado di accelerare, gli sviluppatori probabilmente daranno un'occhiata informale alle modifiche prima di approvarle nella maggior parte dei casi.

Quindi accetta di interrompere le recensioni quando le recensioni smettono di trovare qualcosa di utile. Tuttavia, nella mia esperienza le persone vengono a valutarle dopo un certo periodo di tempo. Per aiutare in un primo momento, chiarire che le recensioni non sono un'accusa di alcun individuo, ma solo il riconoscimento che i diversi punti di vista tendono a creare un risultato più strong.

pushing for review process that includes the author of the original document, whatever it was, before the material is released

La parola che spinge in qualche modo mi fa sentire che stai vivendo certe difficoltà nel raggiungerlo, giusto? Se è così, preferirei tirare un processo inverso di revisione dei documenti passato release.

Il modo in cui tirando è facile - in genere non è necessaria l'approvazione per rivedere il documento rilasciato e passare il loro feedback. E puoi anche tenerne traccia senza ricorrere a qualcun altro al di fuori del team di sviluppo. Usa il tuo tracker dei problemi (presumo che tu ne abbia uno, non è vero?) Per raccogliere i dati.

• "Il numero 1234 è stato creato per revisionare Memo 666 e fornire feedback. - Numero 1234 assegnato a Bob Programmer. - Bob Programmer ha dedicato 2 ore all'analisi richiesta per il numero 1234. - Bob ha aggiornato il numero 1234 con una copia della mail Memo 666: note del team di sviluppo inviate a Jane Liason CCed al team di sviluppo, contenente 56 correzioni, chiarimenti e modifiche. - Numero 1234 chiuso. "

Su una nota correlata, i dettagli o sottigliezze persi potrebbero non essere un problema grave come si percepisce. Voglio dire, se convinci che il ragazzo liason che il suo messaggio precedente ha perso qualcosa di veramente importante, potrebbe essere facile per lei passare la correzione. Questo è particolarmente vero se quel ragazzo si specializza nella comunicazione.

• Una volta ho lavorato a stretto contatto con il marketing pro e lei mi ha dimostrato alcuni dei tipici trucchi che usano nella pratica delle comunicazioni. Come dire cose assertive che risultano facili da liquidare in seguito. O come la formulazione di correzioni spietate di errori stupidi in un modo che sembra espandere quello che è stato precedentemente detto. Piuttosto sorprendente.