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

Когда я занимался строительством у меня было все просто

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

2 входящие документы на почте и отправленные (я из ни как не сортировал

3 на компе все файлы были разбиты по тематическим папочкам

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

А в it дале на 10 человек все меняется с утроенной скоростью...

Тут сложно, мне на последний проект не выбили среду общую с заказчиком, каждый обходится чем есть. Как гибкая тема посмотрите wrike на небольшой объем человек, вполне можно как угодно настроить. А вообще всю эту тему с года три назад у всех решал slack. сейчас что то поутих, хотя странно что утих, на волне то должен был пандемийной стрелять

Я со слаком ещё не работал, он больше возможностей даёт чем  тереграмм?

битрикс имеет движек БП, задачи, файловое хранилище, чатом, пользователей, и станицы-вики, но все это настроить будет вам сложно. Но если настроите, будет работать. А вот как настраивать — это все решает каждый сам. Типовые там есть, но они под CRM, вам же настраивать на то ка ку вас заведено.

Для управления/разделения/структурного хранения — да. Только я вот не помню что там в последнее время вырезали из бесплатной версии по админке

Посмотрю, спасибо.

Первоначально Иван про управление в нескольких БП писал. А б24 есть понятия и проекта, и канбан доски. Их можно связать, тогда видно и состояние проекта, и пул задач в разрезе исполнителя/руководителя/подразделения. Что мне нравится в б24, так это несколько ролей на задачу (постановщик, проверяющий, исполнитель, информируемый) и на канбан доске отдельные потоки с напоминалками: задача близка к просрочке, находится у вас на согласовании и т.п.

Здрасьте приехали. Канбан - это способ управления потоком, по нему ещё как можно работать.
Как раз если в потоке постоянные изменения то канбан неприменим

Пустая папка Входящее - это не про РП, это вообще про персональную эффективность в рамках методологии GTD, она ко всем относится, не только к РП.

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

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

it очень даже материальное производство. Но в ней в отличие от стройки замер выполненных объемов делать сложнее.

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

Вообще-то изначально Jira, это система управления инцидентами, предназначенная для треканья инцидентов. Для задач ее тоже удобно использовать, но тоже для треканья.

А ну тогда понятно в чем проблема. Scrum и прочие гибкие подходы подразумевают - 1 команда, это 1 продукт/проект. Если у вас исполнители работ разделяются между разными параллельно исполняемыми проектами/продуктами, то решить свои проблемы вы можете только имея сетевой график. Гантт, где вы выставляете по датам планируемое выполнение задач, с процентом доступности исполнителя на задачу в указанную дату. И этот Гантт необходимо увязать с Ганттами всех остальных проектов.
Держать это все в уме здоровья не хватит. И исполнители сами не смогут распределиться между разными задачами разных проектов.
Использовать для этого Jira невозможно.

+

+

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

В аджайл при зрелости вытягивание а не выталкивание, задачи тянут исполнители, самостоятельно. И кстати "многопроектность" зло не только в канбане/аджайле, но и вообще в разработке, типа "счас по другому задачку запилю, потом вернусь" приводит к завалу и первого и второго. Так как исполнитель не может в голове держать его влияние на общую выработку всего проекта на его ключевых вехах. И часто его субъективное ощущение вообще не совпадает с реальностью в этом вопросе, и не обязано, это не его задача думать еше и над этим.

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