Встречал ли кто на практике случаи, когда разработка на 1с, группой программистов, сопровождается документацией для более быстрого вникания в разработку?

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

Если у кого-то такое было, выложите скриншот хотя-бы одной страницы.

Сппр вроде как

(1) работал с этим?

Когда-то копался для себя, мне показался сильно громоздким. Мне тоже тема интересна. Кто, как и чем проектирует.

Встречал. СППР. Скриншот не могу - я от туда уволился.

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

А уж, когда собираются в одной переговорке те, кто не соображает, что рисует с теми, кто не соображает, как это читать, начинается феерия.

+(4) И еще один момент - докуменосятину в сспре надо разводить в два три этапа:
1. Концептуально нашвыряь квадратиков, чтобы договориться о количестве, качестве и взаимосваязей функций ПО на СТАРТЕ проекта, когда еще ни чего не разработано
2. Разработать профили где-то посередине, когда уже всё вроде работает, но только под админом
3. Описать детально все операции и справку после приемки заказчиком. До приемки справку и операции описывать - тлен и пустота, т.к. после любого раунда тестирования ландшафт может поменяться.

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

(0) Для 1С все эти новомодные понты на фиг никому не нужны. Если вы не франч, занимающийся разработкой тиражных решений.

(7) +100500 для фикси, которые сопровождают внедренное решение, это всё тлен. Потому, что все эти штуки нужны, чтобы зафиксировать и не продолбать требования к тому, что будет, и договориться о том, каким оно должно быть.
Когда у тебя тут в оборотке красным не встает, а там - черным не ложится, это все не помогает ни как