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