Сообщений в теме: 16

[LeshaL]

Доброе время суток!

Меня уже давненько терзают смутные сомнения в оптимальности процесса тестирования пользовательской документации, по которому у нас все это дело происходит.
Не буду вдаваться в подробности того, что меня беспокоит - по большому счету, документация тестируется относительно неплохо. Но всеже, есть моменты на которые тратится больше времени чем нужно, несостыковки и прочее.

А как это происходит у вас? Хотелось бы прояснить следующие вопросы(и не только):
- пользуетесь ли дефект-трэкером. Если да, то в каких случаях. Если нет - то почему и что взамен.
- как разрешаются конфликты по предлагаемым исправлениям - например, когда два человека просят исправить доку противоположным образом.
- как тестируются случаи, когда продукт содержит одно и тоже руководство пользователя в разных ипостасях; у нас например обычное дело когда их три - PDF, HTML и online-help(неконтекстный) - зачитаться можно!
- как трэкаются и трэкаются ли изменения в продукте, сделаные в последнюю минуту.

Возможно еще что-то, но я сейчас на ночь глядя не могу припомнить. В любом случае интересны все аспекты, касающиеся тестрования документации.

[Mila]

- как разрешаются конфликты по предлагаемым исправлениям - например, когда два человека просят исправить доку противоположным образом.

Это не совсем нормальная ситуация, если все в порядке с процессами и т.п. Поясняю:
Спор по описанию фич самого продукта быть не может, т.к. фичи должны быть четко определены к этому моменту.
Все споры об общей идеологии продукта и фич среди команды должны быть разрешены ДО этапа составления документации - иначе не понятно что эта команда производит. Все улучшения и изменения, как правило, имеют свои планы реализации и т.п.
В спорах о стилистике и т.п. должен выигрывать ответственный за документацию, как более компетентный член команды. В спорах об идеологии продукта между техрайтером и девелопером/тестером должен выигрывать ответственный за идеологию продукта.
Можете привести свой пример спора. :)

- как тестируются случаи, когда продукт содержит одно и тоже руководство пользователя в разных ипостасях; у нас например обычное дело когда их три - PDF, HTML и online-help(неконтекстный) - зачитаться можно!
- как трэкаются и трэкаются ли изменения в продукте, сделаные в последнюю минуту.

Могу немного поделиться нашим опытом:
- Все используемые скриншоты, общие куски текста и т.п. лежат в одном месте, и оттуда автоматически попадают в разные документы, т.е. документация фактически генерится. И это спасает от многих проблем.
- Все баги и улучшения после разборок между девелоперами и тестерами обязательно проходят через техрайтера, который тут же вносит изменения в документацию. Техрайтер обычно успевает все завершить к моменту окончания регрессии. В зависимости от текущей ситуации с изменениями, которая ясна заранее, принимается решение о дополнительном времени на тестирование документации и т.п.
Постановка процесса сильно облегчает жизнь.

[novak]

- пользуетесь ли дефект-трэкером. Если да, то в каких случаях. Если нет - то почему и что взамен.

По своему опыты - да, пользуемся. Как правило, форму обсуждаем с техрайтером - как ему удобно - все ошибки в один баг или несколько багов на разные.

[LeshaL]

Можете привести свой пример спора. :)
...
Постановка процесса сильно облегчает жизнь.

Общий-то процесс есть и работает уже лет 10. По этому процессу работали до меня и после меня будут. И менять глобально мне ничего не хочется. Бывают кое-какие несостыковки иногда, которые являются причиной того, что док-райтер правит кусок один раз(коменты первого ревьювера) а потом опять переделывает (второй ревьювер). И каждый человек ожидает увидеть изменения предложенные именно им(ибо о вторых он и не знает или не обратил внимания изначально).
И тут речь не о спорах или конфликтах, речь о том, что док-райтер иногда оказывается в странном положении. Например:
- один попросил убрать пару неправильных предложений из документации, другой предложил расширить их до двух абзацев, чтобы появился смысл. И зачастую возможны все предлагаемые варианты и получется, что док-райтер не может понять что же от него все-таки хотят и все затягивается.
- два человека правят один нелогичный параграф, но по-разному, не пересекаясь. В итоге, после того как док-райтер сделает обе правки параграф теряет смысл вообще и опять все затягивается.

Можно и другие варианты припомнить, например когда структура переделывается и тд.

[LeshaL]

Могу немного поделиться нашим опытом:
- Все используемые скриншоты, общие куски текста и т.п. лежат в одном месте, и оттуда автоматически попадают в разные документы, т.е. документация фактически генерится. И это спасает от многих проблем.

Очевидно, что у нас нечто подобное. Не один нормальный человек не станет писать один и тот же текст несколько раз и хранить в разных местах. Пишут используя некий сильно платный publishing тул, из него получают PDF и HTML, последний в свою очередь еще и в javahelp преобразуется.

Могу немного поделиться нашим опытом:
- Все баги и улучшения после разборок между девелоперами и тестерами обязательно проходят через техрайтера, который тут же вносит изменения в документацию. Техрайтер обычно успевает все завершить к моменту окончания регрессии. В зависимости от текущей ситуации с изменениями, которая ясна заранее, принимается решение о дополнительном времени на тестирование документации и т.п.
Постановка процесса сильно облегчает жизнь.

Все это хорошо. Но иногда происходят изменения, которые сделаны совсе-совсем на флажке, зачастую это даже не требует каких-то инженерных затрат (например файл с лицензией юристы прислали когда уже продукт готов и оттестирован и его надо только доложить внутрь архива). Иногда посложнее изменения. И некоторые из таких изменений инвалидируют кусочек документации (например переложили файл license.txt из рута в папку license) - все ссылки в документации побились. Конкретно этот пример легко отследить. Хочется решения таких проблем в целом.

[Mila]

И тут речь не о спорах или конфликтах, речь о том, что док-райтер иногда оказывается в странном положении. Например:
- один попросил убрать пару неправильных предложений из документации, другой предложил расширить их до двух абзацев, чтобы появился смысл. И зачастую возможны все предлагаемые варианты и получется, что док-райтер не может понять что же от него все-таки хотят и все затягивается.

В вашем примере я могу предположить:
- первый влез не в свое поле, раз не смог исправить.
- второй - молодец, т.к. следит именно за своими вещами, если он действительно внес нечто новое.
- техрайтер не знает кого слушать, т.к. ВСЕ ГЛАВНЫЕ ВО ВСЕМ. На самом деле техрайтер должен четко понимать от кого и какие содержательные комментарии он должен принимать: размышлизмы обычного девелопера о позиционировании продукта на рынке не нужно немедленно вносить в документацию, а надо передать на рассмотрение PR и т.п. ответственным членам команды... а еще лучше вобще не давать девелоперу этот кусок на рассмотрение, т.к. он все равно не сможет сказать ничего ценного - не та квалификация.
Вобщем, если каждый будет оценивать то, в чем он разбирается, то все в одном абзаце смогут увидеть свои коррективы.

В остальных случаях можно поставить под сомнение квалификацию техрайтера... и прочие несуразности, когда люди просто не знают, что на самом деле нужно написать, но усердно пытаются создать видимость обратного.

[LeshaL]

В вашем примере я могу предположить:
- первый влез не в свое поле, раз не смог исправить.
- второй - молодец, т.к. следит именно за своими вещами, если он действительно внес нечто новое.
- техрайтер не знает кого слушать, т.к. ВСЕ ГЛАВНЫЕ ВО ВСЕМ. На самом деле техрайтер должен четко понимать от кого и какие содержательные комментарии он должен принимать: размышлизмы обычного девелопера о позиционировании продукта на рынке не нужно немедленно вносить в документацию, а надо передать на рассмотрение PR и т.п. ответственным членам команды... а еще лучше вобще не давать девелоперу этот кусок на рассмотрение, т.к. он все равно не сможет сказать ничего ценного - не та квалификация.
Вобщем, если каждый будет оценивать то, в чем он разбирается, то все в одном абзаце смогут увидеть свои коррективы.

В остальных случаях можно поставить под сомнение квалификацию техрайтера... и прочие несуразности, когда люди просто не знают, что на самом деле нужно написать, но усердно пытаются создать видимость обратного.

Вынужден вас огорчить. Все до единого ваши предположения неправильны. Да я и не о том спрашиваю в данной теме. Вы вот лучше раскажите какой у вас процесс тестирования документации.

===========
ЗЫ: К счастью, программные продукты бывают разные, не всегда это окошечко с кнопочками, картинками и табличками. У нас линейка технически сложных продуктов, для ограниченного круга кустомеров. В задачи наших техрайтеров не входит доскональное изучение всех технических тонкостей - это задача девелоперов. Некоторые такие технические аспекты необходимо описать для клиентов и никто кроме разработчиков и тестеров(=первых пользователей) не сможет этого сделать. Ситуации разные возникают, и все мною описанное - это рабочие моменты, а иногда конечно и чьи-то недосмотры, мои в том числе как тест-лида. Вот хочу узнать а как вообще люди документацию тестируют, чтобы перенять чего-нибудь, и по возможности, подкорректировать наш процесс.

===========
ЗЫ2: "не своего поля" у нас не бывает, т.к. каждый наш продукт общий. Например описаный мною случай, к которому вы почему-то придрались, может быть такой. Есть непростой момент, который изначально хотели как-то объяснить пользователям, описав в документации. На взгляд разработчика (у которого в голове куча еще потаенных знаний) получилось понятно, на мой взгляд (человека глубоко не зарывавшегося в спецификации) - получилась ерунда. На взгляд техлида, который больше меня в теме, но меньше разработчика погружен в детали - тоже непонятно получилось. В результате я прошу, например, исправить на более понятное описание (2 абзца, вместо 2-х предложений, которые я сам, разобравшись, могу и написать), а тех лид просит вообще убрать все это нафиг и дать ссылку на спецификацию или сторонню техничекую документацию - типа мы все-равно лучше чем там не напишем. Т.к. ревью проходит независимо у док-райтера два мнения - одно от тех-лида, одно от qa-лида (есть еще старое, девелоперское) - кого ему слушать? Понятно, что потом мы сами уже договариваемся и во второй раз он получает окончательный вариант.

[Mila]

Вынужден вас огорчить. Все до единого ваши предположения неправильны. Да я и не о том спрашиваю в данной теме.

Хм... простите, а откуда мне знать подробности? Я вам озвучила часто встречающиеся ошибки.

ЗЫ2: "не своего поля" у нас не бывает, т.к. каждый наш продукт общий. Например описаный мною случай, к которому вы почему-то придрались, может быть такой. Есть непростой момент, который изначально хотели как-то объяснить пользователям, описав в документации. На взгляд разработчика (у которого в голове куча еще потаенных знаний) получилось понятно, на мой взгляд (человека глубоко не зарывавшегося в спецификации) - получилась ерунда. На взгляд техлида, который больше меня в теме, но меньше разработчика погружен в детали - тоже непонятно получилось. В результате я прошу, например, исправить на более понятное описание (2 абзца, вместо 2-х предложений, которые я сам, разобравшись, могу и написать), а тех лид просит вообще убрать все это нафиг и дать ссылку на спецификацию или сторонню техничекую документацию - типа мы все-равно лучше чем там не напишем. Т.к. ревью проходит независимо у док-райтера два мнения - одно от тех-лида, одно от qa-лида (есть еще старое, девелоперское) - кого ему слушать? Понятно, что потом мы сами уже договариваемся и во второй раз он получает окончательный вариант.

С Ваших же слов:
1. Разработчик - ему все понятно и комментариев нет.
2. Вы не в теме. Вы только попросили объяснить.
3. Техлид в теме и попросил вставить ссылку на стороннюю документацию в качестве объяснений.

Актуальны только пункты 2 и 3.

Теперь приведу два утверждения:
1. Пользователю не интересно читать двухдневные размышления непрофессионала, т.к. на изучение своей предметной области пользователь потратил несколько лет своей жизни.
2. Сторонняя документация никак не может объяснить поведение, узкие моменты и идеологию вашей системы.

В зависимости от содержания техрайтер вполне способен определить лучший вариант, который может быть и комбинированным, с учетом стилистики и общих целей документа.

ЗЫ: К счастью, программные продукты бывают разные, не всегда это окошечко с кнопочками, картинками и табличками. У нас линейка технически сложных продуктов, для ограниченного круга кустомеров. В задачи наших техрайтеров не входит доскональное изучение всех технических тонкостей - это задача девелоперов.

А что входит в задачи Ваших техрайтеров? Писать о том, о чем они вобще не имеют никакого представления, а потом растерянно хлопать глазами, что же делать с двумя предложениями? Вы отвлекитесь и посмотрите на ситуацию со стороны... увидите, что на самом деле я не злая :)
Все упомянутые "технические тонкости", которые нужно знать в предметной области, содержаться в Вашем продукте или очевидны из его функциональности. Об остальном в документации писать не стоит. :)

Вы вот лучше раскажите какой у вас процесс тестирования документации.

Уже описывала. Высказываюсь по озвученным проблемам.
Кстати, Вы уже признались, что предложение о налаживании процессов Вам не по вкусу. Что Вы ожидаете от аудитории? :)

[LeshaL]

Вы вот лучше раскажите какой у вас процесс тестирования документации.

Уже описывала. Высказываюсь по озвученным проблемам.
Кстати, Вы уже признались, что предложение о налаживании процессов Вам не по вкусу. Что Вы ожидаете от аудитории? :)

Да, извините, вы уже написали, за что спасибо.
Но я не писал, что налаживание процессов мне не по вкусу. Переделывание - не по вкусу, корректировка и улучшение - это то что я хочу сделать.

А что входит в задачи Ваших техрайтеров? Писать о том, о чем они вобще не имеют никакого представления, а потом растерянно хлопать глазами, что же делать с двумя предложениями? Вы отвлекитесь и посмотрите на ситуацию со стороны... увидите, что на самом деле я не злая :)
Все упомянутые "технические тонкости", которые нужно знать в предметной области, содержаться в Вашем продукте или очевидны из его функциональности. Об остальном в документации писать не стоит. :)

А я и не думаю, что вы злая :) Я знаю, что вы не знаете, что собой представляют наши продукты.
А в задачи тех-райтера входит написать документацию, как это не странно. Части документации присылаются ему разработчиками, и он, как нативный спикер, переводит с английского на английский :) Но это конечно не все, что делают наши док-райтеры. Но они не технические специалисты, а писатели - они пишут книгу, под названием User's Guide. За правильность технических деталей описанных там, отвечают разработчики и соотвественно мы тестеры, которые убеждаются, что эти детали описаны правильно.

===========
В документации к нашему продукту содержится изрядное количество технической информации совершенно новой для пользователей, т.к. мы работаем над новыми технологиями, которые только через год-два появляются, например, в сотовых телефонах. Зачастую, для использования наших продуктов требуется сложный процесс конфигурирования, причем не только самого продукта, но и environment-а (например создание IPv6 сети). Иногда, пользователям необходимо самим реализовать необходимые компоненты, которые мы просто не можем сделать за них. А как их сделать тоже описывается в доке.
В общем все не просто. Сделать скриншот, описать последовательность действий по какой-нибудь схеме и тому подобное, док-райтеры спокойно могут сделать сами. Но описать процесс создания каких-нибудь нативных библиотек в зависимости от операционки или описать организацию пользовательского канала связи они очевидно не могут.

=======
PS: и еще, я не писал, что я не в теме :) Я сказал, что я глубоко не погружаюсь в детали, если мне этого не надо для проведения тестирования. А вот тестируя документацию, когда я вижу, что описан какой-то процесс, мне необходимо пошагово его реализовать. И если девелопер, зная кучу подробностей, описал его кратко, то мне, чтобы понять его описание надо потратить несколько дней на изучение деталей. Поэтому я пытаюсь добиться того, чтобы процесс, который придется проходить пользователю был описан подробнее. Но иногда, есть альтернатива - не описывать вообще ничего, а сослаться на сторонние документы, детально объясняющие суть происходящего. Случаи разные бывают.

[Mila]

Я знаю, что вы не знаете, что собой представляют наши продукты.
А в задачи тех-райтера входит написать документацию, как это не странно. Части документации присылаются ему разработчиками, и он, как нативный спикер, переводит с английского на английский :) Но это конечно не все, что делают наши док-райтеры. Но они не технические специалисты, а писатели - они пишут книгу, под названием User's Guide. За правильность технических деталей описанных там, отвечают разработчики и соотвественно мы тестеры, которые убеждаются, что эти детали описаны правильно.
=======
В документации к нашему продукту содержится изрядное количество технической информации совершенно новой для пользователей, т.к. мы работаем над новыми технологиями, которые только через год-два появляются, например, в сотовых телефонах. Зачастую, для использования наших продуктов требуется сложный процесс конфигурирования, причем не только самого продукта, но и environment-а (например создание IPv6 сети). Иногда, пользователям необходимо самим реализовать необходимые компоненты, которые мы просто не можем сделать за них. А как их сделать тоже описывается в доке.
В общем все не просто. Сделать скриншот, описать последовательность действий по какой-нибудь схеме и тому подобное, док-райтеры спокойно могут сделать сами. Но описать процесс создания каких-нибудь нативных библиотек в зависимости от операционки или описать организацию пользовательского канала связи они очевидно не могут.

Получается, что на неподготовленного человека сваливается информация, которую он не может переварить, он ее как-то там компилирует на абзацы, а потом вся команда, так же стихийно, пытается выправить результат? Может стоит привлечь нормального технического специалиста, чтобы разработчики не занимались задачами техрайтера (для меня техрайтер это не только переводчик и наборщик текста) :)
И еще можно попробовать тестировать описание от разработчика, довести его до ума, а потом уже отдать техрайтеру... т.к. он выглядит лишним звеном на данном этапе, да и делает двойную работу.

И если девелопер, зная кучу подробностей, описал его кратко, то мне, чтобы понять его описание надо потратить несколько дней на изучение деталей. Поэтому я пытаюсь добиться того, чтобы процесс, который придется проходить пользователю был описан подробнее. Но иногда, есть альтернатива - не описывать вообще ничего, а сослаться на сторонние документы, детально объясняющие суть происходящего. Случаи разные бывают.

Тут надо внести ясность с целями, содержанием документа, целевой аудиторией и т.п и распространить эти постулаты на всю команду. Они и служат критериями для выбора. Например(!!!), если с этими технологиями будут работать спецы уровня заслуженный senior developer какого-нить Intel, то боюсь ему будет очень неудобно вытаскивать из 10 страниц три действительно полезных предложения, т.к. IPv6 сеть он может развернуть с закрытыми глазами без подсказок => оставляем только особенности настроек и ссылку на документацию.
Документация должна писаться для пользователя, а не для Васи Пупкина, который вчера узнал что такое С. Как-то так. :)

[LeshaL]

Извините, я тут отвлекся от нашего диалога :)
Если честно, вполне вероятно, что вы правы - со стороны, описанная мною ситуация может выглядеть так, как вы говорите. Особенно, учитывая специфику наших продуктов и очень узкий круг пользователей.
Поэтому, предлагаю больше не обсуждать правильность-неправильность нашего процесса работы по составлению документации и особенности наших док-райтеров. И процесс и док-райтеры работают уже 10+ лет, критических проблем не было. Выпущено, примерно пара десятков продуктов, некоторые по несколько версий. Так что не все у нас так плохо, как кажется.

И еще можно попробовать тестировать описание от разработчика, довести его до ума, а потом уже отдать техрайтеру... т.к. он выглядит лишним звеном на данном этапе, да и делает двойную работу.

Вот это реально хороший совет! Спасибо. Странно, почему это мне самому не пришло в голову. У нас процесс кросс-ревью практически обязателен для кода, можно что-то подобное для документации ввести.

И, не могу не удержаться, док-райтеры - они не лишние. Очень даже не лишние. Я даже не могу представить, во что превратится документация, если у нее не будет одного owner-a, где каждый будет писать текст, как хочет; стилизовать как придется и прочие вещи. Плюс к этому, не весь текст наших User's Guide-ов требует вмешательства девелоперов. А требуют те куски, в которых только человек занимавшейся этим - специалист.
Вот вам, для примеру, документация одного из компонентов, который включен в каждый наш релиз, каждого нашего продукта:
http://java.sun.com/...k_dev_guide.pdf
Вот документация для второго неотъемлемого компонента:
http://java.sun.com/..._usersguide.pdf
Благо оба этих компонента (на самом деле они сами по себе не хилые продукты) выложены в опен соурсе, что дает мне возможность продемонстрировать разнообразность описаных в доках вещей.
Кстати, все опен-соурсные веб-странички - тоже наши док-райтеры делают.
А еще, кто будет выполнять тербования по 508 compliance для документации? Русскоязычные девелоперы?
А если учесть, что док-райтеров всегда было мало, а последнее время и еще меньше стало (чего нельзя сказать про кол-во продуктов) - то могу утверждать, что они много чего делают.

Тут надо внести ясность с целями, содержанием документа, целевой аудиторией и т.п и распространить эти постулаты на всю команду. Они и служат критериями для выбора. Например(!!!), если с этими технологиями будут работать спецы уровня заслуженный senior developer какого-нить Intel, то боюсь ему будет очень неудобно вытаскивать из 10 страниц три действительно полезных предложения, т.к. IPv6 сеть он может развернуть с закрытыми глазами без подсказок => оставляем только особенности настроек и ссылку на документацию.
Документация должна писаться для пользователя, а не для Васи Пупкина, который вчера узнал что такое С. Как-то так. :)

Да вы правы, скорее всего будут работать люди из компаний, типа той, про которую вы написали. Если интересно - вот тут их всех можно найти. Заходите по ссылкам, где Sun - spec lead и смотрите кто входит в Expert Group. Ну и другие подобные конторы, которые в экспертную группу не входят. А вот уровень людей - не известен заранее. Да и любому человеку, какой-бы он професионал не был, при работе с чужим ПО, намного более приятно получить четкие, лаконичные и исчерпывающие инструкции, правда ведь?

[Mila]

И, не могу не удержаться, док-райтеры - они не лишние. Очень даже не лишние. ...

Я это писала по отношению только к отдельному этапу, а не в принципе :)

А вот уровень людей - не известен заранее. Да и любому человеку, какой-бы он професионал не был, при работе с чужим ПО, намного более приятно получить четкие, лаконичные и исчерпывающие инструкции, правда ведь?

Правда, но к сожалению не всегда угадывают, что именно писать.
Я бы одним из критериев взяла бы гугл: если на запрос есть куча ссылок, то можно и не особо разливаться мыслью по древу - программеры сами все найдут и прочтут во всех подробностях :)
Если брать API, то часто забывают описывать переменные связанные именно с простыми типами, типами а-ля Object или List. Например:
GetObjectWithType(string ObjType), где ObjType - тип объекта или его свойство.
Вроде и ежу понятно, но потом в коде приходится долго и упорно подбирать эту несчастную строку, перебирая малые и заглавные буквы и прочие фантазии.
Как-то так :)

[Arkady]

>> - пользуетесь ли дефект-трэкером. Если да, то в каких случаях. Если нет - то почему и что взамен.<<
иногда да, чаще нет

>> как разрешаются конфликты по предлагаемым исправлениям - например, когда два человека просят исправить доку противоположным образом.<<
Оцени по 10 бальной шкале чьи предложения более обоснованы и логичны. Тот вариант и выбирай.

>> как тестируются случаи, когда продукт содержит одно и тоже руководство пользователя в разных ипостасях; у нас например обычное дело когда их три - PDF, HTML и online-help(неконтекстный) - зачитаться можно!<<
если они идентичны то тестируешь один вариант, правят во всех. Если разные то тестировать придется каждый вариант.

[LeshaL]

>> как разрешаются конфликты по предлагаемым исправлениям - например, когда два человека просят исправить доку противоположным образом.<<
Оцени по 10 бальной шкале чьи предложения более обоснованы и логичны. Тот вариант и выбирай.

Не выйдет. Правки письмом в параллель прилетают докрайтеру. Другие их тоже видят, но если их много, то можно пропустить коллизии.

>> как тестируются случаи, когда продукт содержит одно и тоже руководство пользователя в разных ипостасях; у нас например обычное дело когда их три - PDF, HTML и online-help(неконтекстный) - зачитаться можно!<<
если они идентичны то тестируешь один вариант, правят во всех. Если разные то тестировать придется каждый вариант.

Это не ответ. Т.е. это ответ, но бесполезный, т.к. это и так понятно. Самое сложное во всем этом то, что надо понять, что написано одно и тоже. Да источник один, но есть два преобразования. Причем я встречал ситуации, что в PDF ссылки не работали, а в HTML работали, хотя PDF как бы первичен.
PS: онлайн-хелп наконец-то отменили. Так что осталось только два варианта доки.

[Vasiliy]

А как это происходит у вас? Хотелось бы прояснить следующие вопросы(и не только):
- пользуетесь ли дефект-трэкером. Если да, то в каких случаях. Если нет - то почему и что взамен.

Не всегда. Последний раз вычитывали документацию - в трекере была только задача, что надо провести проверку.
Физически документация печаталась небольшими порциями, они правились на бумаге и передавались техписам. Те вносили корректировки и отмечали в задаче, что документы такие-то поправлены.

- как разрешаются конфликты по предлагаемым исправлениям - например, когда два человека просят исправить доку противоположным образом.

А как такое возможно? И часто ли бывают такие ситуации? Из своей практики могу вспомнить только когда сам писатель не соглашался с исправлениями и новыми добавлениями в документацию. Тогда привлекали менеджера проектов в качестве судьи.

- как трэкаются и трэкаются ли изменения в продукте, сделаные в последнюю минуту.

В последнюю минуту - это за час до релиза?:)

Если я правильно понял, то у нас такое исправление войдет в следующую версию в документации.

[LeshaL]

- как разрешаются конфликты по предлагаемым исправлениям - например, когда два человека просят исправить доку противоположным образом.

А как такое возможно? И часто ли бывают такие ситуации? Из своей практики могу вспомнить только когда сам писатель не соглашался с исправлениями и новыми добавлениями в документацию. Тогда привлекали менеджера проектов в качестве судьи.

Бывают. Вопрос не в спорах, а в том, что докрайтер может либо удивиться и задать вопрос, а может вставить одну из правок или скомпилировать из нескольких что-то несусветное. Все это затянет процесс: потом найдем, ещё раз перечитаем изменения итд.

- как трэкаются и трэкаются ли изменения в продукте, сделаные в последнюю минуту.

В последнюю минуту - это за час до релиза?:)

Если я правильно понял, то у нас такое исправление войдет в следующую версию в документации.

У нас следующая версия может быть через несколько лет. А может и не быть. Если в документации написаны абсолютно неверные вещи в важных местах (есть главы регламентирующие некоторые вопросы), тогда да - будем патч для доки делать. Но эти вещи не меняются часто и тестируются внимательно.
Бывает же, что было как-то сделано, так и задокументировали, а потом, после того как задокументировали - переделали по каким-то причинам (баг чинили, например). Как не упустить такие изменнеия?

[Vasiliy]

Бывает же, что было как-то сделано, так и задокументировали, а потом, после того как задокументировали - переделали по каким-то причинам (баг чинили, например). Как не упустить такие изменнеия?

У нас для этого ЖЦ бага или задачи заканчивается у техписов. То есть описали -> сделали -> проверили -> отдали техписам и пусть они смотрят, что надо править в документации.