Dmitriy Amelin

"обратите", конечно) не исправить комментарий уже)

Игорь, спасибо. Да, всё очень похоже.
По поводу того, что инструмент не должен быть тяжелее.
Мои попытки внедрить инструменты типа "Битрикс" или "Яндекс.Трекер" на творческих проектах для творческих команд потерпели фиаско: все эти инструменты не очень органичны для творческой индустрии. А вот Планфикс зашёл сразу, так как решил главную боль — хаос в коммуникациях. Обрати внимание на него — очень интересная платформа и тоже no-code, во многом.
Подробнее кейс внедрения описан здесь - https://planfix.ru/blog/kak-planfiks-pomog-prodyuseru-naladit-prodazhi/

Игорь, спасибо. А в Вашей практике для аналогичных задач какой инструментарий используете?

Егор, спасибо.
Если в целом про управление проектами, то главная засада не в том, что реальность фактического хода проекта отличается от канонической модели управления проектами (допустим, по каскадной модели), а в том, что молодые (и даже уже и не очень) менеджеры и продюсеры, порой, совсем не знают этой канонической модели и сразу организовывают процесс имея в базе хаотическое представление о порядке работ. И вместо того, чтобы на предлагаемые заказчиком изначально не нормальные условия проведения работ торговаться с ним от базы и соглашаться на эту "ненормальность" в обмен на изменения связанных условий (сроки, бюджеты, качество), сразу принимают эти условия как базовые и изначально весь проектный процесс организовыввают как высокорискованный, стрессовый и не комфортный для всех его участников. Что для творческих проектов особенно губительно. Вот это и правда — "засада".

@id721080
Кстати, по поводу Notion — вполне хороший инструмент для создания прототипа такой системы или для небольших проектов и команд. Точно лучше условного excel.
Правда совсем не масштабируется, ограничения по глубине связей, и крайне простой функционал работы с правами. В общем, для больших проектов и команд не потянет совсем. А уж тем более, что бы через него вести все проекты команды. В общем, он, всё-таки, для создания вкусной документации в режиме быстро и просто.

3. Кто оунеры системы.
Если оставаясь в примере разработки экспозиционного проекта:

Тут мы ничего не придумываем, на архитектурных проектах при использовании BIM проектирования есть роль "BIM координатор" — он заводит новый проект в систему и в целом проверяет, что она отвечает потребностям конкретного проекта. Но не он один — к нему приходит информация из двух главных естественных за ведение конкретного проекта в системе:
а) Менеджер проекта — отвечает за то, что в системе есть все необходимые служебные и административные смысловые единицы и функции для обеспечения административного управления и контроля. Собственно далее сам или посредством линейных менеджеров пользуется этим контуром, от них же и принимает информацию, что в системе чего-то не хватает. Он измеряет эффективность менеджерского контура.
б) Шеф-редактор — отвечает за то, что в системе есть весь смысловой контур: смысловые объекты и смысловые единицы по ним. В случае необходимости, сообщает координатору о потребностях. ОН измеряет эффективность смыслового контура.

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

И всё это работает, потому что все смысловые, служебные и административные функции вводятся в систему в течение минут или часов (или дольше если их пул большой, но когда система уже "устаканивается" для конкретной команды объём таких потребностей невелик) — ибо nocode платформа такое позволяет.

2) За счёт чего информация всей командой будет вноситься в систему.

Важное отличие, что это уже не столько инструмент, сколько среда разработки. Ровно также, как условный Фотошоп или Фигма уже не инструменты, а среда разработки. Тогда:
а) Основной объём промежуточных и итоговых результатов смысловой команды в процессе смысловой работы (тексты, буквы и числа) над смысловыми объектами и смысловыми единицами сразу создаются в системе, а не копиистом переносят из каких-то иных документов, в которых создаются прежде.
б) В итоге, не только смысловая информация, но и служебная, административная (и так является результатом труда каждого специалиста) теперь фиксируется не в разных информационных средах и инструментах, а в одной системе и один раз. Для примера, если кратко:
— редакторы: тексты, смыслы, описания, гипотезы, информационные артефакты
— художники: результаты своей работы, иллюстрации, худ. объекты,
— менеджеры: статусы и комментарии к ним по необходимости, смысловую документацию и определение адресатов
— эксперты: статусы и комментарии к ним по необходимости
и т.п.

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

Главной мотивацией для всей команды является то, что во многом работать становиться проще (если система корректно собрана сразу). На каждом этапе каждый специалист видит по своей зоне ответственности свой личный воркфлоу:
1) Состав смысловой информации, который он должен разработать по конкретному смысловому объекту. И сам набор смысловых объектов, который он должен решить.
2) Контекст связанной информации по ним ( в том числе и ТЗ в декомпозированом виде).
3) Всё остальная информация тут же под рукой и по необходимости

Т.е. на стадии "Концепция" карточка экспоната или зала для редактора содержит лишь 3-4 поля, которые он должен описать; для архитектора 1-2; для арт-директора пара-тройка своих. На стадии "Проект" таких полей уже больше, но у каждого снова свои — т.е. не надо думать, а что надо делать и с чего начать: рабочая среда уже сформирована.

При условии конечно, что у команды есть стандарты всей основной смысловой документации: тематический план, концепция, проект экспозиции и проч.

@id721080 Спасибо за вопросы. Постараюсь на них дать внятный ответ.
1) Как понять, что пора переходить на аналогичную систему.

Если быстро — то понимание приходит творческой команде ровно также, как и команде продавцов или сервиса, что без CRM дальше уже никак, или IT команде, что дальше всё вести в условном Trello уже просто не реально.

Если, всё-таки, попытаться определить триггеры, то тут всё сложнее и дольше по объяснениям, и всё очень субъективно для каждого конкретного уровня специалистов и его уровня толерантности к рутине и "бестолковой" работе: руководство, менеджмент, линейная команда.
Лишь уточню, что главная фича системы не ведение документации (хотя и это тоже), а контроль творческого процесса на уровне смыслового объекта и смысловой единицы.

А ответ — вот когда затраты на обслуживание этих смысловых сущностей всей командой становятся субъективно "не разумными", а на творчество "объективно" не остаётся времени, и команде в целом просто уже дико не комфортно, то вот система уже нужна была бы за 1-2 проекта до такого осознания ситуации.

Всегда приятно, когда находишь подтверждение методике среди коллег) Спасибо!

⁣Пожалуйста. А какие проекты?