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

Более того, даже если сохранить требования «на тогда» и посмотреть на них через два года, то возникнет куча вопросов «а почему они именно такие», потому что контекст принятия требований тоже утерян и его, как раз, восстановить уже на порядок сложнее. А спеки, написанные с комментариями по каждому пункту «почему именно так» я видел вообще пару раз в жизни. Ну, за пределами всяких митингов с целью обоснования того или иного решения.

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

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

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

шарь шаблон

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

И шаблон, да:)

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

https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/

(я раз в год примерно эту ссылку в чат приношу, наверное :))

угу примерно так

там есть образцы для конкретных команд, мы обходимся метой (статус/продукт/приоритет) и сильно меньшим количеством разделов

- аппруверы
- что решаем (бизнес-задача и критерии готовности)
- как решаем (краткое описание реализации)
- детали реализации
- Q&A (сюда двигаются важные вопросы из комментариев или дописываются напрямую)
- справочная информация (ссылки, кросслинки)

т.к. эта история про эпик, а не про изолированную техническую задачу или одну юзерстори, то верхнеуровневый контекст можно оперативно восстановить.
а джировские таски у нас скорее аккумуляторы PRов и заполняются довольно поверхностно (DoD и всё) - их наличие это требование безопасников

а написать нормальный коммит месадж можно? ну пожалуйста! и подробное описание тестов в PR

так он нормальный, но в него ты можешь вместить только this much

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

ADR кажется незнакомой аббревиатурой, разверни, пожалуйста :)

Architecture Decision Record

а кто решает важный ADR или нет?

я 😀 ну, команда конечно. кто ж еще?

общее правило такое, это контекст для людей не в теме, "почему тут сделано так, вы дураки чтоле" - вот ADR - аа, тогда понятно