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

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

Достаточно редко получается фидбек хоть в каком-то виде. Неважно, коммент к статье, чатик, звонок. Любой способ приемлем, если придёт тот самый фидбек

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

А в чем проблема? На обсуждении каждая часть проговаривается с поясняющими рисунками на флипчарте и спрашивается насколько все понятно разработчикам, предложения, дополнения, выясняется трудоемкость и т.д.

Проблема в том, что на обсуждении приходит РО, без учёта аналитика и его мнения, с этого и начался вопрос, в нужности и не нужности аналитика в продукте и как обстоят дела у других. Во вторых, в том что обсудив все и хлопнув по рукам, что все понятно, в момент реализации, разработчики с круглыми глазами говорят, что впервые слышат о проблеме и никогда такое не обсуждали ранее.

О, тогда вопрос к масштабированию - как скейлили? Если нет синков - значит проблема не в наличии/отсутсвии аналитика, а в плохо отмасштабированном agile

"Разработчики с круглыми глазами говорят, что впервые слышат о проблеме и никогда такое не обсуждали ранее" - это вполне ожидаемо.  После обсуждения с PM должны идти декомпозиция, планирование и оценка времени, зачастую после дополнительного исследования кода. Аналитик в этом участвует?

На тему прочитать статью есть доклад с хорошими мыслями на тему
https://youtu.be/zVtTrXcHH2M

Для обмена инфой статья - не всегда эффективно

А кто-нибудь может подкинуть статьи или видео на тему: “Почему системный аналитик не нужен”?

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

При этом, по моим наблюдениям, в западной модели разработки наличие выделенного проектирования слабо наблюдается. Обычно в команде БА/РО и разрабы. БА в работу СА (то, что у нас делают СА) особо не заглядывают. Но это не точно, возможно, мне такие команды попадались.

Коллеги, исследую как в продуктовых командах принято описывать нефункциональные требования и какие ошибки совершались. Расскажите, пожалуйста, у вас есть в командах требования по написанию нфт? Кто их описывает обычно и как они тестируются? Были ли в вашей практике случаи, когда неправильно разработанные нфт (или их отсутствие) приводило к каким-нибудь издержкам? Есть ли у вас примеры успешных кейсов, когда наоборот все быстро, легко и точно описывалось и не было никаких проблем? За счет чего, на ваш взгляд, у вас нет проблем с нфт?

"Таки вы насчет быстродействия? Это не к нам, это к админам, они сервер настраивают" (с) какой-то тим-лид )))

Во мне живёт надежда, что где-то процесс формирования нфт регулярен, точен и отлажен )

https://www.outsystems.com/blog/posts/non-functional-requirements/
Наверное тут можно почитать

https://habr.com/ru/post/231961/ - вот здесь более подробно описано о том, что такое НФТ, какие они бывают и как их определять

мне нравится описание по furps+, то есть то, что входит в "urps+"

Бизнес-правила могут быть как нефункциональными, так и функциональными требованиями