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

В свое время все доработки снеговика вел только в хранилище там и писал всякие примечания к версиям.
Потом надоело, в коде только коментю.

(0) мне хватает вордовского файла

лень

ну и чтобы враги недогадались чего я там на г0внокодил..

(3) вычисляется на раз, это не клюшки

(4) вот по этому и не документирую :)

(0)собираюсь вести. Уже года два как((( Но лень сильнее

а что есть такие продукты!? ТЗ в ворде + Визио

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

(0) 5 лет назад, еще во время работы в Рарусе, была самописка на клюшках, без нее учитывать изменения во всех конфах было бы нереально. Сейчас самописка на УФ.

Стараюсь вести учет по тикетам в Jire, при помещении в хранилище в комментах ставлю № и наименование тикета, + html описание изменений в юзер-режиме, для оповещения пользователей.

Была бы полноценная работа с хранилищем, цены бы не было.
Сделали бы бранчи, тикеты прям в конфигураторе - цены бы не было. Я б даже купил.

Пардон за повторение.

(10)а картинки вы в html  пихаете?

(9)Интересно в чем клюшки? Получалось ли перехватывать изменения, которые внесены в конфигураторе?

(13) Делал на основе http://infostart.ru/public/100636/
Выглядит примерно так:
http://s1.ipicture.ru/uploads/20120924/cSTMS5jo.png
и
http://s1.ipicture.ru/uploads/20120924/XTzK33lT.png

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

дока нужна

А) чтобы замылить глаза потенциальным потребителям при тираже продукта
Б) чтобы некий босс поставил галку в документообороте конторы

(15) формы то не управляемые.
неинтересно..

Хех, сложно html поле перенести на управляемую форму? :))
Ну, мы работаем в тоооолстом клиенте, нам пофиг на плюшки)

(16)Какая то мелка доработка не нуждается. но если вы пишете некую подсистему, пересекающуюся с типовым функционалом, то еще как надо.

Ибо через полгода уже забудешь что там наворотил

жгу камменты в коде

Для левых конфигураций использую ОбщийМакет, где по порядку нумеруются задачи выполненны (без планов и пожеланий,  только то что сделанно). В комментариях пишу номер задачи типа #123.

Дайте ссылку где почитать про документирование изменений при разработке ПО.

(14) Нет, все руками вносили

Комменты в коде по конкретным изменениям, табличка в общем макете с общим описанием изменений, заявителями, датами исполнения. Аналогично в доп. обработках/отчетах.

подниму ветку

(22) +1 и к тому же объекты, не подверженные изменению полностью на поддержке, дополнительный функционал "старается" быть описанным в обход типовой конфигурации

(27)дополнительный функционал "старается" быть описанным в обход типовой конфигурации - а доп функционал как документируете?

просто коммент вставляем со своим ником и датой.

(29) см п (22) - специально же указал. Составляется карта изменений и хранится в виде отдельного макета