где там у нас беклог мироздания... у кого-нибудь есть ссылка?

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

Посмотри Visio или аналоги, удобно создавать блок-схемы. Нарисовать все флоу
Можно и в Figma, если командой работать нужно, но там каструбатенько выходит :)

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

короче, стоит ли делать сложно?)

Часто делают wiki проектов с описанием того как что устроено

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

bpmn bizagi modeler пользовал

достаточно просто и бесплатно на определенном уровне
при желании учится стандарт нотаций и чтение с рисованием становится элементарным

да, Bizagi - конструктор nocode приложений, когда это еще не было модным ))

По моему опыту инструментарий вторичен.

Для начала важно обеспечить скорость документирования и скорость обновления старой документации (вот как раз на этапах обновления и возникает большинство проблем).

1) Определите рабочие сценарии: кто/когда из сотрудников должен порождать/обновлять артефакты документации и встройте это в текучку. Но выбирайте сотрудников правильно: например, если в вашем случае необходимо документировать именно бизнес-логику, то не совсем логично это доверять программистам.
2) Дайте этим сотрудникам самим выбрать удобный для них формат документации. Для одних это будет самодокументирующийся код, для других Миро/Фигма/пр.
3) Проконтролируйте ретроспективно качество обновления документации.

Опробуйте подход на одном продукте/проекте в течение полугода-года, а потом уже масштабируйте.

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

Друзья, привет! Есть среди вас ребята, кто ведёт блог про свою профессию?)

Телеграмм канал веду

Сергей, я тебе написал в лс, так что жду там:)

Коллеги, привет! Кто может поделиться опытом организации продуктовой аналитики и мониторинга для сложных, высоконагруженных веб продуктов? Интересуют инструменты, какую связку выбрать.

Вы лучше к девопсам своим сходите, у них уже есть стопудов

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

Га и метрика чем не устраивает? Амплитуда для воронок? Киссметрикс есть. Да много чего готового

Полностью своё можете так же пилить по аналогии как девопсв с ними. Писать хиты, сеансы, свойства, строить отчеты. Тот же механизм, только руками и долго

Ну вот я и хочу про реальный опыт узнать, спросить какие-то вопросы, подводные камни, советы. Написано в интернете много, все выглядит круто)

Вы с чем-то вообще работали?