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

Гугл, яндекс,  плюс общение показали примерно следующие подходы.

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

Кто-то просто в самой конфигурации в общем модуле или макете пишет, все что в конфе делали.

Кто-то использует СППР.  

Кто-то использует Git репозитарии для 1С кода, или 1C:EDT (Enterprise Development Tools).

Кто-то использует решения, делающие выгрузку из хранилища с историей всех изменений объектов /ConfigurationRepositoryReport

Кто-то просто пишет максимально читаемый код, плюс плюс описание экспортных методов которое потом можно превратить в документацию к ним плюс автотесты, которые генерируют документацию (vanessa-behavior, например).

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

Также вижу что используют сторонние разработки управления проектами, GitLab, Asana, Jira, Redmine.
Также фиксируют доработки в Evernote, Google Docs и т.д. и т.п.

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

Таск-трекер с обсуждением и фиксацией решения.
В коде - номер задания и краткое (на 1-2 строки) описание.

(1) > В коде - номер задания и краткое (на 1-2 строки) описание.

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

(2) всё-таки лучше в коде. Иначе замучаешься листать версии чтобы выяснить, кто же последний изменял одну из ста процедур "популярного" общего модуля. GIT вроде бы умеет отловить историю изменения конкретного куска кода, а 1сное хранилище не умеет

(3) Умеет, только показывает очень неудобно - как набор коммитов, а для получения диффа надо еще кнопки жать...

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

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

(4) к сказанному добавлю, что изменения не модулей получится комментить только в коммите

В конфигураторе не хватает режима просмотра модуля без комментариев.
Много доработок одной-двух типовых строк плохо смотрится.

(6) Прикрути свою любимую диффалку, указав ее в настройках, и будет тебе и без комментариев, и без пробельных символов, и без учета регистра - все что пожелаешь!

Собственного опыта нет, но из стороннего опыта сложилось следующее впечатление про оптимальный вариант: интеграция таск-трекера с гитом (когда коммит имеет ссылку на номер задачи и наоборот, тогда при нормальной интеграции можно сразу из таск-трекера перейти к просмотру коммита).
Разработку при этом можно вести в хранилище, а в гит просто зеркалировать известной утилитой. Код при этом чистый - без комментариев "кто/когда/почему".

(2) И в коде, и в хранилище.

(8) + А у меня просто хранилище и комментарии коммитов, номер задачи из таск-трекера пишется в поле "метка". Т.е. когда прижмет - все "ходы" можно найти. Но так как команда маленькая и прижимает редко, то рука пока не поднимается на построение более человечной системы. Если бы приходилось чаще - пришлось бы задуматься и о гите и о более продвинутом таск-трекере.

Только это все касается протоколирования доработок, а не написания документации к ним. Это же абсолютно разные вещи, ИМХО.
Ведение пользовательской документации - это совершенно отдельная тема.

Документирование API (в т.ч. автодокументирование) - это тоже немного сбоку.

в такс трекере - номер задачи, заказчик, постановка решение.
в коде - номер задачи, заказчик, дата, пояснения к изменениям.

(13) А размер ноги заказчика в коде почему не указваете?

(14) подрастешь, расскажу почему. если сам не поймешь к тому времени.

(14) Для этого нужно разрешение на хранение и обработку персональных данных.