У меня нет ощущения, что нужен ещё один «-изм» поверх PMBoK, PRINCE2, ISO и всего остального. Если агент - это просто экзоскелет существующего участника проекта, который по команде помогает писать, считать, напоминать и структурировать, то вы правы, никаких специальных правил тут почти не нужно. Это просто хороший инструмент.
Давайте на примере кодинг-агентов. Если взять самый простой уровень (автодополнение, подсказку по функции и т.п.) тогда да, это скорее экзоскелет. Такой усилитель разработчика. Он помогает писать быстрее, но сам не становится участником процесса разработки. Никаких особых правил тут действительно не нужно, кроме обычной инженерной гигиены.
Но кодинг-агент в современном смысле - это ведь уже не совсем «умная клавиатура». Он читает репозиторий, сам ищет, где менять код, сам предлагает архитектурный ход, пишет тесты, чинит пайплайн, открывает PR, иногда ещё и комментирует, почему сделал именно так. То есть он влияет не только на скорость рук разработчика. Он начинает влиять на саму логику изменений в системе. И вот в этот момент почти никто уже не говорит: «Да это просто экзоскелет, какие тут могут быть правила». Наоборот, сразу возникают вполне взрослые вопросы.
Что агенту вообще разрешено трогать? Что он может менять автоматически, а что только через review? Кто отвечает за уязвимость, если агент написал код убедительно, но плохо? Достаточно ли того, что тесты зелёные? Можно ли ему доверять миграции, рефакторинг, изменения в критических для безопасности местах? Нужен ли лог его действий? Нужен ли rollback по умолчанию?
То есть как только агент начинает не подсказывать, а действовать внутри процесса, правила почему-то становятся совершенно естественной темой. С управлением проектами, на мой взгляд, происходит ровно то же самое. Если агент просто помогает РП оформить протокол, собрать статус, напомнить о дедлайне и делает это всегда по одной и той же цепочке - это действительно экзоскелет. Но если он уже сам мониторит коммуникации, сам выделяет «важное», сам формирует сводную картину проекта, сам предлагает, что эскалировать, а что считать рабочим отклонением - это уже не просто усилитель. Это участник контура управления, пусть и без формальной ответственности.
А раз так, то и правила нужны примерно того же класса, что и у кодинг-агента. Не абстрактная бюрократия ради бюрократии, а довольно приземлённые вещи. Об этом концепция выше.
Поэтому мой тезис здесь довольно простой: не всякий агент требует новых правил. Но и сводить любого агента к «экзоскелету» уже не получается. С кодинг-агентами это стало видно раньше и нагляднее. С агентами в управлении проектами мы, похоже, подходим к той же точке.
Это, собственно, один из главных вопросов.
У меня нет ощущения, что нужен ещё один «-изм» поверх PMBoK, PRINCE2, ISO и всего остального. Если агент - это просто экзоскелет существующего участника проекта, который по команде помогает писать, считать, напоминать и структурировать, то вы правы, никаких специальных правил тут почти не нужно. Это просто хороший инструмент.
Давайте на примере кодинг-агентов. Если взять самый простой уровень (автодополнение, подсказку по функции и т.п.) тогда да, это скорее экзоскелет. Такой усилитель разработчика. Он помогает писать быстрее, но сам не становится участником процесса разработки. Никаких особых правил тут действительно не нужно, кроме обычной инженерной гигиены.
Но кодинг-агент в современном смысле - это ведь уже не совсем «умная клавиатура». Он читает репозиторий, сам ищет, где менять код, сам предлагает архитектурный ход, пишет тесты, чинит пайплайн, открывает PR, иногда ещё и комментирует, почему сделал именно так. То есть он влияет не только на скорость рук разработчика. Он начинает влиять на саму логику изменений в системе. И вот в этот момент почти никто уже не говорит: «Да это просто экзоскелет, какие тут могут быть правила». Наоборот, сразу возникают вполне взрослые вопросы.
Что агенту вообще разрешено трогать? Что он может менять автоматически, а что только через review? Кто отвечает за уязвимость, если агент написал код убедительно, но плохо? Достаточно ли того, что тесты зелёные? Можно ли ему доверять миграции, рефакторинг, изменения в критических для безопасности местах? Нужен ли лог его действий? Нужен ли rollback по умолчанию?
То есть как только агент начинает не подсказывать, а действовать внутри процесса, правила почему-то становятся совершенно естественной темой. С управлением проектами, на мой взгляд, происходит ровно то же самое. Если агент просто помогает РП оформить протокол, собрать статус, напомнить о дедлайне и делает это всегда по одной и той же цепочке - это действительно экзоскелет. Но если он уже сам мониторит коммуникации, сам выделяет «важное», сам формирует сводную картину проекта, сам предлагает, что эскалировать, а что считать рабочим отклонением - это уже не просто усилитель. Это участник контура управления, пусть и без формальной ответственности.
А раз так, то и правила нужны примерно того же класса, что и у кодинг-агента. Не абстрактная бюрократия ради бюрократии, а довольно приземлённые вещи. Об этом концепция выше.
Поэтому мой тезис здесь довольно простой: не всякий агент требует новых правил. Но и сводить любого агента к «экзоскелету» уже не получается. С кодинг-агентами это стало видно раньше и нагляднее. С агентами в управлении проектами мы, похоже, подходим к той же точке.
Спасибо, посмотрю! С первого взгляда - в бОльшей степени для ИТ сферы. Есть чем воодушевиться. Подходы очень близкие.
В проектном управлении немного сложнее с описанием уровней зрелости - много неформализованных вещей.