Как читать этот срез
Это срез обсуждения, а не рецепт.
- Руководители разделились на рабочие группы, каждая взяла свой вопрос. Группы работали параллельно, выводы между собой почти не сверяли. Отсюда расхождения, местами доходящие до прямого спора. Участники сознательно сохранили это как есть.
Одни тезисы поддержал почти весь зал, с другими многие спорили.
- Перед вами срез обсуждения, без претензии на единую позицию клуба: к каким выводам пришли группы, где они не согласились и что осталось открытым. Разногласия здесь важны не меньше выводов, они показывают, где отрасль ещё ищет ответ.
Устоявшегося пути в AI-native пока нет ни у кого.
- Этот вывод, пожалуй, единственное, с чем на сессии согласились все. Как заметил один из участников, записи этих обсуждений можно загрузить в модель, и она найдёт с десяток разных вариантов прохода. Единственно правильного среди них не видно.
Здесь мнения разошлись сильнее всего. Единого ответа, что и как считать, на встрече не нашлось, но набор рабочих принципов проступил довольно чётко.
- Считать в деньгах. Единственная честная метрика для C-level это маржа в P&L. Эффект приходит либо через рост выпуска, либо через снижение издержек, вплоть до сокращения людей.
- Но срабатывает такой подсчёт не везде. Для короткого цикла деньги посчитать можно. Для большого бизнеса между инструментом и деньгами слишком много факторов. Там, где ИИ используют сами разработчики, денежная метрика вообще перестаёт подходить. Это сильная позиция, но до общего вывода она не дотянула.
- Внедрение ИИ ведёт себя как инвестиция. Компания меняет токены на деньги через неизвестное время и без гарантии, как при покупке дорогого станка. Поэтому логика «внедрили, посчитали, порадовались» не срабатывает.
- Обманчивые метрики. С этим согласились все: токены, token-maxing, строки кода, закрытые тикеты, число багов растут легко и ничего не значат. На них лучше не смотреть.
- Тест на честность. Смотреть на time-to-market и бюджет токенов вместе. Если они движутся независимо, то есть токены жгут, а поставка не ускоряется, инструмент не работает.
Учитывать ли отложенный эффект. Одни считают, что брать нужно только то, что видно за квартал, иначе не понять, помогло ли. Другие возражают: обучение и распространение практик окупаются гарантированно, пусть и не сразу.
Тут выводы сошлись почти без разногласий. Главное: внедрение не приживётся само, у него должен быть хозяин и понятные правила игры.
- Один ответственный. С именем и фамилией, уровня CTO, CIO или COO. Плюс комитет из лидеров направлений: инструменты, финансы и токеномика, стандарты, реорганизация команд, метрики. Речь идёт о процессах и одновременно о культурном сдвиге.
- Внедрять как управляемую программу. С понятным ритмом: чуть больше сверху вниз, но с амбассадорами внутри команд.
- Что стандартизировать. Описанный процесс и контракты между этапами, сборку контекста, гардрейлы и evals, среду исполнения, финопс. Governance и безопасность идут сквозным слоем. Библиотеку знаний держать версионируемой и машиночитаемой.
- Что оставить командам. Прототипы на чём угодно, локальный контекст под продукт, выбор инструментов по зрелости.
- Как переводить пилот в стандарт. Определить метрики до старта, добиться повторяемости, вести фидбэк-клуб, растить чемпионов и пересаживать их в другие команды.
Самое живое возражение сессии: убери слово «ИИ», и перед нами обычное управление изменениями, знакомое годами. Что здесь нового? Доля истины в этом есть. Но всплыл и обратный сюжет: иногда стандарт задаёт вендор, минуя компанию. Бывает, команды собирают снизу десятки разных агентов, а потом платформа закрепляет свой де-факто стандарт, один основной агент и набор навыков, и все перестраиваются под него. И тут возникает открытый вопрос: если все работают по одинаковым шаблонам, чем компании будут друг от друга отличаться.
Когда код пишет агент, узкое место смещается от написания кода к внятной постановке задачи и приёмке результата. Требования выходят на первый план.
- Спеки доступны агенту. Держать их в отдельном хранилище с доступом ко всей картине.
- Закреплять то, где нельзя допустить дрифта. В первую очередь требования бизнеса к системе, плюс информационная безопасность по домену. Там, где домыслить безопасно, агенту оставляют свободу.
- Новая роль: владелец спецификаций. Отвечает за единый формат и за то, что в спеку обязательно входит. Это функция, которую можно совмещать с существующей должностью.
- Новый шаг: ревью спеки. Агент прогоняет её и показывает, где она неполная. На этом дотачивают и спеку, и правила её написания.
- Сквозная трассировка. Хранить цепочку от идеи до приёмки, чтобы по строчке кода видеть, из какого плана и спеки она выросла.
Первый вопрос: не переизобретает ли клуб обычного аналитика? Ответ группы: владелец спецификаций отвечает за единый формат и процесс, простым переименованием человека здесь не обойтись. Более неудобным оказался второй вопрос: если сегодня спеки пишут плохо, ИИ размножит проблему вместо лечения. Прямого ответа на него не нашлось.
Этапы разработки остаются прежними, но перестают быть отдельными людьми. Меняется состав участников каждого шага, сам список шагов сохраняется.
- Роли схлопываются в мультискилл. Один человек ведёт задачу целиком и управляет агентами вместо людей. Исполнитель становится менеджером агентов, и это новые навыки.
- Процесс становится параллельным. Водопад с передачей от должности к должности уходит. Сам код занимает малую часть времени, остальное съедают согласования и бэклог. Развести их в потоки значит расширить узкое место.
- Два решения человек не отдаёт. Что делать (выбор гипотезы) и принять результат (проверка). Отсюда две несхлопываемые роли: замысел до запуска и приёмка.
- Эксплуатация идёт отдельно. Если продукт надо внедрить в людей, например объяснить на производстве, это ещё одно решение за человеком.
А была ли это вообще перестройка? Часть зала считала, что внутри одной задачи процесс остаётся линейным, параллелить можно лишь разные задачи. В ответ уточнили: речь о том, что ответы на некоторых этапах появляются раньше обычного, без перепрыгивания самих этапов. И более глубокий спор: человечество веками шло к разделению труда, а теперь роли собираются обратно в одном человеке. Откат или новая парадигма? Похоже, второе: разделение труда всегда оплачивалось коммуникацией между людьми, а когда роли сходятся в одном человеке, эта коммуникация просто исчезает.
