разверни, плз, идею про "оповещения - плохой механизм"? Что ты под оповещениями обозначаешь?

Затем что чаты и оповещения выдергивают человека. Можно провести в них весь день.

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

вы неправильно используете чаты и оповещения)

Тут, скорее, вопрос уменьшения шума, а не полного отказа от них, разве нет?

Это очень примитивный ответ, но дело в том, что вряд ли ты сможешь сформулировать, как же правильно

Дело не в полном отказе, а в том, чтобы процесс работал, если человек пропустил оповещение

Человек же сам решает какой чат ему мешает а какой нет

Это похоже на code owners

в чатах-оповещениях надо гибко настраивать уровень verbosity и давать людям понятную схему как к этому адаптироваться.

Как минимум:
- схема деления каналов, чтобы люди могли подписываться под узкие темы/виды информации. Пусть будет 200 каналов на 20 человек — это ок.
- есть разные уровни дёргания людей: меншн человека лично, меншн команды, вообще сообщение без меншна. Могут быть замьюченные каналы, которые разбираются по соглашению раз в какой-то промежуток времени.

Это первый уровень погружения в проблему потока шума.

Если процесс может работать без человека, то и оповещение не нужно, а если оповещения есть, значит и человек требуется. Следовательно, изменение процессов таким образом, чтобы процесс работал и без человека == автоматизация. Но это слабо относится к проблеме оповещений. Или я что-то не так понял?

По схожей причине заглядывался на этот продукт
https://twist.com/

Рассматривали софт вида чат-без-уведомлений?

Я думаю, скорее имелось в виду что-то про push vs. pull communication

Человек нужен, но лучше его не отвлекать, а подкидывать ему аккуратно задач в план, чтобы он в своём ритме их расхватывал (например)

Есть время реакции.

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

Угу. Верно. Вот push может быть для удобства, но не должен быть единственным механизмом

Так, стопэ

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

Дело в том, что ты рассказываешь о том, какими техническими средствами улучшить push коммуникации.

Они дорогие, потому снижают пропускную способность команды, а растет она именно при pull.

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

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

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

поясни, плз. Гугл выдаёт неоднозначную инфу на этот термин)