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

Вообще состав работ (читай доков) РП должен с вами прописывать.

Вообще состав работ (читай доков) РП должен с вами прописывать.

Вообще состав работ (читай доков) РП должен с вами прописывать.

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

С определённого момента (обычно хорошо видно в банках), сложность возрастает сильно из-за ограничений сервисов (скорость выполнения запросов, качество данных, отказоустойчивость, прочая нефункциональщина). И сам сервис становится тяжеловесным с кучей юз-кейсов и сложной логикой. Вот тут появляется НЕОБХОДИМОСТЬ нового уровня абстракции над документацией в виде Archimate, который ужесточает правила ведения документации, дополняет и объединяет её.

Документ не самоцель. По моему тут ошибка в уровне. Документ это подтверждение проведения работ. Исследование? Документ исследования, изменеия в процессе? Документ фиксации изменений. Я склоняюсь к этому. Если не было проведено обследование но "выплевывается" документ ТЗ потому что так надо, то грошь цена этому документу.

Не только подтверждение работ. Как на счет фиксации намерений? Как на счет общего понимания задач? В одном из исследований показали, что 60% всех проблем с ПО вызвано некорректным пониманием требований. Как быть если требования не зафиксированы?

Кстати, у меня давно в голове сидит вопрос - как определить степень формализованности (жесткости правил ведения документации) для конкретного проекта. В том числе при различиях продуктового и проектного подхода. На что ориентироваться? На текущий уровень зрелости? И как определить, если текущий уровень явно "слабоват"

Ориентироваться надо на людей, которым вы пишите. Всегда.

И да, и нет. Иногда приходится сделать им неудобнее, чтобы снять какие-то другие риски.