Новая проблема для менеджеров программных продуктов: AI ускоряет рост числа фич
Менеджерам продуктов раньше приходилось упрашивать организацию добавить еще одну функцию. Теперь AI заставит их чаще удерживать команды от лишних фич.
Когда-то Microsoft Word был самым распространенным ПО в мире. Файл .doc был lingua franca вычислительного мира, а фраза «пришли мне документ Word» стала частью делового словаря. Word победил WordPerfect, который так и не сумел перейти в мир Windows.
Однако эта победа над WordPerfect могла оказаться пирровой. Word в итоге стал совсем не тем, чего, вероятно, ожидал его первоначальный менеджер продукта. Побеждая конкурента количеством функций, MS Word превратился в раздутый и громоздкий продукт, набитый слишком многим. Он попал в ловушку принципа «только потому, что вы можете это сделать, не значит, что вы должны». Каждый новый релиз добавлял все более редкие и малоиспользуемые функции, которые хорошо смотрелись на маркетинговом листе, но лишь сильнее запутывали пользователей.
И все это происходило в мире, где новые функции нужно было писать вручную, а на их создание уходили недели или месяцы. Что произойдет с ПО теперь, когда функции можно добавлять с помощью AI за один день?
Дорога к «фичеизму»
У менеджеров программных продуктов сложная работа. Одна из главных трудностей — центральная для их роли: какие функции добавлять следующими? На внедрение функций обычно нужно время, поэтому накапливается backlog. Это дает менеджеру продукта время, чтобы проверить функции, изучить их, понять, насколько они подходят продукту, и в итоге решить, стоит ли игра свеч. Задачи в backlog постоянно оцениваются и переоцениваются, чтобы понять, сделают ли они продукт привлекательнее для клиентов.
Иначе говоря, сам backlog дает менеджеру продукта время для полноценной due diligence. Но с появлением agentic AI дни функций, которые месяцами лежат в backlog, подходят к концу. Agentic coding позволит придумать функцию утром, а выпустить ее днем. Наши build- и test-пайплайны уже позволяют исправлять баги и выкатывать их за часы. Теперь мы увидим ту же скорость и в случае продуктовых функций.
А это создает для менеджеров продуктов новую проблему. Вместо того чтобы решать, какую хорошо проверенную функцию строить следующей, им придется быстро решать, стоит ли вообще делать конкретную функцию.
Соблазн, конечно, будет в том, чтобы добавлять как можно больше функций, потому что конкуренты наверняка делают это так же быстро. И это возвращает нас к ситуации, где «featuritis», или feature creep, угрожает раздуть и усложнить продукт — а этого хорошие менеджеры продуктов стараются избегать.
Раскрепощенное кодирование
Проблема усугубляется тем, что разработчики смогут добавлять функции настолько быстро, что смогут — и, вероятно, будут — обходить обычные процессы и просто встраивать функцию, не дожидаясь, пока кто-нибудь спросит, ценна ли она, нужна ли она и вообще полезна ли. Эти процессы — с учетом вопросов безопасности, юридических факторов и рыночных сил — существуют не просто так. Их обход может иметь серьезные последствия. Задача смещается: уже не «у нас недостаточно времени, чтобы построить то, что хочется», а «у нас недостаточно времени, чтобы решить, чего не строить».
Это потребует культурного сдвига в организациях. Менеджерам продукта придется перейти от попыток убедить компанию впихнуть еще одну функцию в продуктовый цикл к попыткам удерживать лишние функции за бортом. Вместо давления сверху с требованием добавить больше функций начнут формироваться силы, ограничивающие возможность команд добавлять функции ради самого процесса, чтобы все оставалось под контролем.
Раньше сложнее всего было втиснуть еще одну функцию. Теперь? Сложнее всего будет не пустить ее в продукт.
Материал — перевод статьи с английского.