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

ну то есть в любом случае это тех писатель. Даже для описания функционала продукта, а не внутренней тех составляющей

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

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

спасибо за пояснение

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

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

Документацию как работает продукт) Где какие промокоды применяются (или должны применяться) а где не должны. Как происходят различные покупки/апгрейды (много условий заложено в эти процессы) и вот это все.
В дальнейшем надо влезть глубже скорее всего и описать как работа/должна работаь интеграция с каким-нибудь АмоСРМ и тд

Менеджеры, разработчики, продажники, все сотрудники компании. Каждый свое, но в целом проблема в том что часто теряется понимание как оно сейчас работает и почему именно так

Так не бывает, разработчикам и продажникам, как правило, разная документация нужна

Так не бывает, разработчикам и продажникам, как правило, разная документация нужна

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

Так не бывает, разработчикам и продажникам, как правило, разная документация нужна

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

Т.е. ТЗ и Руководство пользователя - это просто разные способы абстракции?! 😳