AI ускоряет инженера и команду, но не гарантирует ускорения бизнеса.
Посмотрел на собственных данных, как подход AI-first повлиял на количество выполненных продуктовых задач. Рост есть, но пока умеренный, около 10%. При этом большую часть кода у нас пишет AI, а первичное code review проводят AI-боты. За людьми остаются финальный апрув и ответственность.
Сравнение одной команды до и после перехода на AI-first
Если взять среднее по двум командам и сравнить с приростом за прошлый год, чтобы частично исключить естественный рост, тренд всё равно останется положительным, но будет уже не таким заметным.
Сравнение прироста за два года на более широкой выборке
Ещё одно наблюдение: кода в целом стало больше, потому что подешевели вещи, на которых раньше часто экономили время: тесты на пограничные сценарии, обработка редких случаев и более универсальные реализации.
Сравнение прироста LOC за два года, рассчитанного как Additions − Deletions. Видно, что в последние месяцы прирост ускорился.
Команды стали чаще браться за сложные фичи. Раньше большой объём реализации сам по себе мог остановить задачу: делать долго, а ожидаемая польза не всегда оправдывала затраты. Сейчас этот барьер ниже. Решение чаще упирается в архитектуру и риски, а не в количество кода, которое придётся написать руками.
В любом случае сравнивать разработчиков сегодня и два года назад сложно. Изменились инструменты, процессы и сам подход к работе, поэтому прежние метрики продуктивности всё хуже отражают реальный результат. Состав команд за это время тоже изменился, поэтому прямое сравнение не вполне корректно.
Для себя пока сделал такой вывод: значимого влияния на продуктовые метрики пока не вижу, но производительность команды в среднем выросла примерно на 10%. При этом эффект сильно зависит от уровня разработчика и отличается у джунов, мидлов и сеньоров.
За последние полгода агентная разработка заметно шагнула вперёд. Самое важное изменение в том, что сложные задачи, которые раньше откладывали из-за риска долгой и дорогой реализации, теперь чаще попадают в спринты.
Поэтому оценивать эффект только по количеству закрытых задач не совсем корректно. AI влияет не только на скорость работы, но и на выбор задач.
AI-First - это когда решаем задачу, в первую очередь пытаются решить с применением AI.
AI-Native - это когда без AI этот продукт или бизнес в принципе не существовал бы.
Но вообще, мне кажется, эти термины описывают разные вещи. AI First это подход к работе: сначала проверяем, можно ли решить задачу с помощью AI. AI Native это свойство продукта: он изначально построен вокруг AI и без него теряет смысл.
Поэтому, одна компания может быть одновременно и AI-First и AI-Native.
Статья звучит как “мы за всё хорошее, против всего плохого”. Измерять влияние фич - это правильная идея. Разумно сравнивать прогноз с фактом. Но дьявол в деталях.
Не каждая компания может позволить себе такие эксперименты. Для небольших проектов с ограниченным рынком стоимость построения этой системы измерений просто не окупится. В реальности небольшой продукт - это серия выстрелов: набрасываем фичи, смотрим что выстрелит, замечаем когда выстрелило. Без PMO, без impact-сетей, без proximate-эффектов.
И это нормально.
Описанный процесс влияет только на то, насколько верифицирован опыт команды. Но верификация опыта редко является узким местом. Узкое место в умении выбирать гипотезы. Опытный продакт и так посмотрит на результат: ему не нужен специально построенный процесс. А у начинающего продакта проблема не в отсутствии фреймворка для измерений, а в отсутствии чутья.
Если уж говорить про практику, которая реально работает, я бы поставил на JTBD и AJTBD. Это не про то, как красиво измерить то, что уже сделал. Это про то, чтобы не делать лишнего с самого начала.
В статье возводится доказательность в карго-культ. Можно построить идеальную систему метрик и при этом методично делать продукт, который никому не нужен. Если продукт находит свою аудиторию и зарабатывает деньги - это заслуга того, кто его делает. Не заслуга системы измерений или Impact Intelligence.
Но это работает как способ "обучить" начинающих продАктов смотреть на последствия своих решений. Узкоспециализированный инструмент для конкретной задачи.
После статьи у меня бы возникла путаница в ролях. Кажется, что CTO, CIO, CISO и COO здесь местами слишком близко поставлены друг к другу, хотя в реальной компании у них разные углы зрения.
CTO: как технология даст продукту и бизнесу преимущество.
CIO: как внутренние технологии сделают компанию управляемой.
CISO: как не потерять данные, доверие, деньги и право работать.
COO: как превратить стратегию в ежедневно измеряемый результат.
Я бы не говорил, что есть одна правильная схема. Она зависит от истории компании, стадии роста и "силы" текущего руководителя. Если компания еще маленькая, роли неизбежно совмещаются. Если компания растет, роли начинают расходиться.
CIO отвечает за то, как технологии работают внутри компании. Это корпоративные системы, рабочие места, доступы, ERP, CRM, почта, сети, ноутбуки, интеграции, внутренние сервисы, поддержка, бюджеты на ИТ инфраструктуру. Например, если в компании растет отдел продаж, CIO думает, какую CRM внедрить, как связать ее с биллингом, как обеспечить доступы, как не утонуть в ручных операциях и хаосе в данных.
CTO отвечает за то, как технология помогает продукту и бизнесу расти. Это архитектура продукта, инженерная команда, платформа, скорость разработки, надежность, выбор технологий, качество инженерной культуры. Например, если компания делает облачный сервис, CTO думает, выдержит ли архитектура рост в десять раз, как быстрее выпускать фичи, где опасный техдолг, какие команды нужны, какие технологические решения дадут преимущество на рынке.
COO отвечает не за технологии как таковые, а за работающую операционную модель компании. Его зона это регулярность, предсказуемость и согласованность. Чтобы продажи продавали то, что продукт может поставить. Чтобы поддержка знала, что делать после релиза. Чтобы внедрение не ломалось на каждом клиенте. Чтобы финансы, юристы, саппорт, продукт и разработка работали не отдельными островами, а как одна система.
Интересный взгляд. Статья хорошо описывает взросление инженера до CTO. Особенно близки тезисы про расширение кругозора и фокуса: сначала человек отвечает за код и команду, затем за продукт, компанию, рынок и последствия своих решений.
В этом смысле роль CTO больше про бизнес партнерство. Не только построить сильную инженерную функцию, но и помочь компании выбрать технологическую стратегию под ее стадию, цели и конкурентное положение на рынке.
Если смотреть на задачи CTO через стадии роста компании, роль CIO перестают быть загадкой: становится понятно когда они появляются и зачем. Разбирал это здесь: https://habr.com/ru/articles/907800/
Водораздел верный: CIO смотрит за операционными процессами внутри компании, CTO смотрит на рынок и продукт. Это правда.
Но картинка статичная. Роль CTO меняется от стадии к стадии. На этапе идеи одни задачи. На масштабировании другие. На due diligence третьи. Один человек в разные периоды делает принципиально разную работу. Про это в статье ничего нет.
Ещё не хватает ответа на вопрос: откуда вообще берутся CIO и CISO. В реальности это следствие роста. CTO не успевает закрывать весь фронт, и тогда сам CTO или C-level команда выделяет отдельные роли. CIO забирает внутренние системы. CISO берёт безопасность.
И сразу появляются конфликты: CTO хочет выкатить фичу к дедлайну, CISO блокирует релиз из-за рисков безопасности. CTO хочет больше телеметрии, CIO режет бюджет на облако. Это типичные примеры конфликтов.
Не читать про стратегию, не ходить на конференции, не менеджерить команду. А взять и сделать что-то, где ты сам принимаешь решения и видишь результат: не в пулл-реквестах, а клиентах.
Если совсем технарь, то начни с опенсорса. Сделайте библиотеку, которой будут пользоваться. Это тоже продукт. Там тоже пользователи. Уже обратная связь, которую не придумал менеджер.
Ещё лучше взять пет-проект или сделать небольшой стартап с друзьями.
Я в студенчестве начинал карьеру с создания студии разработки, примерно десять человек, каждый со своей экспертизой. Были клиенты, продажи. Это был опыт про бизнес, продукт и людей, а не про код и архитектуру. Потом были стартапы. Из десяти идей до чего-то интересного доживала одна. Но каждый такой проект давал опыт, чего не даёт ни одна книга: хороший технический проект сам по себе никому не нужен. Его нужно донести до людей/рынка.
Хотите стать CTO, идите получать нетехнический опыт. Продукт, продажи, клиенты, смежные функции. Просто менеджерить команду и ходить на собеседования недостаточно.
Расширяйте нетворк. Общайтесь с реальными CTO, они покажут, что роль устроена совсем не так, как может казаться снаружи.
Близкий мне опыт. Во многом совпадает с тем, что я наблюдаю на практике.
Отдельно раскрыл бы источник этой разносторонности задач. Сначала цели компании, стратегия и рынок. Потом уже из этого вырастают продуктовые, инженерные, организационные и кадровые решения. У меня на эту тему есть близкая по духу статья: рынок, стратегия, инженерная культура.
Молодые CTO могут воспринимать архитектуру, найм, бюджеты, коммуникации с C-level, R&D как цель. Но всё это только инструменты для достижения целей/стратегии компании. Важно не перепутать инструмент с целью.
Хороший обзор, спасибо. Мне хочется в него добавить enterprise CRUD админки. Я бы упомянул там Refine и Ant Design Pro. Они закрывают типовые вещи: лэйаут, списки, формы, права, работу с данными.
Да, дистрибуция всегда была слабым местом разработчика. Она не сложнее разработки, просто разработчик годами тренирует производство и почти не тренирует продажу.
Инди разработчики игр начали зарабатывать не тогда, когда стало проще писать игры. Они начали зарабатывать, когда появились Steam и App Store. Там уже были люди, карты, доверие, быстрая доставка до клиента.
Когда у вайбкод проектов появится своя полка с покупателями, станет проще.
Я как CTO, читаю эту статью как короткое объяснение для фаундеров и рекрутеров: автор нормально показывает, что CTO — стратегическая роль, которая не лезет в операционку и не превращается в «сеньора, который всё тянет сам».
В целом, я согласен со всеми пунктами, если не учитывать контекст.
В реальности, эта роль и ее фокусы меняются в зависимости от стадии компании и ситуации на рынке. Мне самому ближе роль CTO как бизнес-партнера. Работа над бизнес-стратегией тоже часть его работы: https://habr.com/ru/articles/907800/
Часть сам, часть с АИ. Уж очень много там связей. Больше 200. И надо бы еще добавить. Если кто-то найдет полезным, то покручу побольше. Там можно еще добавить описание того, как именно влияет пункт чек-листа на проблему.
Хороший разбор плохих кейсов. Я попробовал взять свою статью с чек-листом CTO и наложить на 36 проблем из статьи. Подумал, что может получиться что-то интересное.
29 пунктов чек-листа CTO vx 36 проблем в организации
С первой попытки, получилось не очень информативно. Потом добавил клик по пунктам и вроде можно посмотреть какие проблемы могут быть.
Влияние "структуры команд" на проблемы
Но, самым наглядным получился вариант с двудольным графом.
Лично меня бесит, что все заявления компаний про высокие SLA / UPTIME это всегда маркетинг. Это значит, что если тебе нужно что-то сравнить, то ты будешь опираться на свой опыт, либо на опыт знакомых. Реально измерять никто не будет.
Крупные продукты всегда говорят о высоких SLA, но в реальности, такие сервисы состоят из большого числа компонентов/сервисов и когда один из них не работает, это не считается простоем. А когда таких компонентов десятки или сотни, то ты как пользователь постоянно ощущаешь как у тебя что-то вечно отваливается, но SLA будет 5 девяток. И вот с этой проблемой вообще ничего не сделать ...
Поэтому, вывод один: не читайте советских газет заявления сервисов касательно их SLA, это маркетинг.
Open source для автора это всегда маленький продукт. Если это библиотека, то это оценка других разработчиков (комьюнити), кто готов ее использовать. Это прежде всего бесценный опыт.
AI ускоряет инженера и команду, но не гарантирует ускорения бизнеса.
Посмотрел на собственных данных, как подход AI-first повлиял на количество выполненных продуктовых задач. Рост есть, но пока умеренный, около 10%. При этом большую часть кода у нас пишет AI, а первичное code review проводят AI-боты. За людьми остаются финальный апрув и ответственность.
Если взять среднее по двум командам и сравнить с приростом за прошлый год, чтобы частично исключить естественный рост, тренд всё равно останется положительным, но будет уже не таким заметным.
Ещё одно наблюдение: кода в целом стало больше, потому что подешевели вещи, на которых раньше часто экономили время: тесты на пограничные сценарии, обработка редких случаев и более универсальные реализации.
Команды стали чаще браться за сложные фичи. Раньше большой объём реализации сам по себе мог остановить задачу: делать долго, а ожидаемая польза не всегда оправдывала затраты. Сейчас этот барьер ниже. Решение чаще упирается в архитектуру и риски, а не в количество кода, которое придётся написать руками.
В любом случае сравнивать разработчиков сегодня и два года назад сложно. Изменились инструменты, процессы и сам подход к работе, поэтому прежние метрики продуктивности всё хуже отражают реальный результат. Состав команд за это время тоже изменился, поэтому прямое сравнение не вполне корректно.
Для себя пока сделал такой вывод: значимого влияния на продуктовые метрики пока не вижу, но производительность команды в среднем выросла примерно на 10%. При этом эффект сильно зависит от уровня разработчика и отличается у джунов, мидлов и сеньоров.
За последние полгода агентная разработка заметно шагнула вперёд. Самое важное изменение в том, что сложные задачи, которые раньше откладывали из-за риска долгой и дорогой реализации, теперь чаще попадают в спринты.
Поэтому оценивать эффект только по количеству закрытых задач не совсем корректно. AI влияет не только на скорость работы, но и на выбор задач.
AI-First - это когда решаем задачу, в первую очередь пытаются решить с применением AI.
AI-Native - это когда без AI этот продукт или бизнес в принципе не существовал бы.
Но вообще, мне кажется, эти термины описывают разные вещи. AI First это подход к работе: сначала проверяем, можно ли решить задачу с помощью AI. AI Native это свойство продукта: он изначально построен вокруг AI и без него теряет смысл.
Поэтому, одна компания может быть одновременно и AI-First и AI-Native.
Статья звучит как “мы за всё хорошее, против всего плохого”. Измерять влияние фич - это правильная идея. Разумно сравнивать прогноз с фактом. Но дьявол в деталях.
Не каждая компания может позволить себе такие эксперименты. Для небольших проектов с ограниченным рынком стоимость построения этой системы измерений просто не окупится. В реальности небольшой продукт - это серия выстрелов: набрасываем фичи, смотрим что выстрелит, замечаем когда выстрелило. Без PMO, без impact-сетей, без proximate-эффектов.
И это нормально.
Описанный процесс влияет только на то, насколько верифицирован опыт команды. Но верификация опыта редко является узким местом. Узкое место в умении выбирать гипотезы. Опытный продакт и так посмотрит на результат: ему не нужен специально построенный процесс. А у начинающего продакта проблема не в отсутствии фреймворка для измерений, а в отсутствии чутья.
Если уж говорить про практику, которая реально работает, я бы поставил на JTBD и AJTBD. Это не про то, как красиво измерить то, что уже сделал. Это про то, чтобы не делать лишнего с самого начала.
В статье возводится доказательность в карго-культ. Можно построить идеальную систему метрик и при этом методично делать продукт, который никому не нужен. Если продукт находит свою аудиторию и зарабатывает деньги - это заслуга того, кто его делает. Не заслуга системы измерений или Impact Intelligence.
Но это работает как способ "обучить" начинающих продАктов смотреть на последствия своих решений. Узкоспециализированный инструмент для конкретной задачи.
После статьи у меня бы возникла путаница в ролях. Кажется, что CTO, CIO, CISO и COO здесь местами слишком близко поставлены друг к другу, хотя в реальной компании у них разные углы зрения.
CTO: как технология даст продукту и бизнесу преимущество.
CIO: как внутренние технологии сделают компанию управляемой.
CISO: как не потерять данные, доверие, деньги и право работать.
COO: как превратить стратегию в ежедневно измеряемый результат.
Я бы не говорил, что есть одна правильная схема. Она зависит от истории компании, стадии роста и "силы" текущего руководителя. Если компания еще маленькая, роли неизбежно совмещаются. Если компания растет, роли начинают расходиться.
CIO отвечает за то, как технологии работают внутри компании. Это корпоративные системы, рабочие места, доступы, ERP, CRM, почта, сети, ноутбуки, интеграции, внутренние сервисы, поддержка, бюджеты на ИТ инфраструктуру. Например, если в компании растет отдел продаж, CIO думает, какую CRM внедрить, как связать ее с биллингом, как обеспечить доступы, как не утонуть в ручных операциях и хаосе в данных.
CTO отвечает за то, как технология помогает продукту и бизнесу расти. Это архитектура продукта, инженерная команда, платформа, скорость разработки, надежность, выбор технологий, качество инженерной культуры. Например, если компания делает облачный сервис, CTO думает, выдержит ли архитектура рост в десять раз, как быстрее выпускать фичи, где опасный техдолг, какие команды нужны, какие технологические решения дадут преимущество на рынке.
COO отвечает не за технологии как таковые, а за работающую операционную модель компании. Его зона это регулярность, предсказуемость и согласованность. Чтобы продажи продавали то, что продукт может поставить. Чтобы поддержка знала, что делать после релиза. Чтобы внедрение не ломалось на каждом клиенте. Чтобы финансы, юристы, саппорт, продукт и разработка работали не отдельными островами, а как одна система.
Интересный взгляд. Статья хорошо описывает взросление инженера до CTO. Особенно близки тезисы про расширение кругозора и фокуса: сначала человек отвечает за код и команду, затем за продукт, компанию, рынок и последствия своих решений.
Мне не хватило бизнесово-предпринимательской составляющей. CTO это не просто следующий уровень инженерного менеджмента. Как и любой C-level, он должен понимать рынок, риски, конкурентное положение компании, текущие возможности команды и ограничения бизнеса.
В этом смысле роль CTO больше про бизнес партнерство. Не только построить сильную инженерную функцию, но и помочь компании выбрать технологическую стратегию под ее стадию, цели и конкурентное положение на рынке.
Если смотреть на задачи CTO через стадии роста компании, роль CIO перестают быть загадкой: становится понятно когда они появляются и зачем. Разбирал это здесь: https://habr.com/ru/articles/907800/
Водораздел верный: CIO смотрит за операционными процессами внутри компании, CTO смотрит на рынок и продукт. Это правда.
Но картинка статичная. Роль CTO меняется от стадии к стадии. На этапе идеи одни задачи. На масштабировании другие. На due diligence третьи. Один человек в разные периоды делает принципиально разную работу. Про это в статье ничего нет.
Ещё не хватает ответа на вопрос: откуда вообще берутся CIO и CISO. В реальности это следствие роста. CTO не успевает закрывать весь фронт, и тогда сам CTO или C-level команда выделяет отдельные роли. CIO забирает внутренние системы. CISO берёт безопасность.
И сразу появляются конфликты: CTO хочет выкатить фичу к дедлайну, CISO блокирует релиз из-за рисков безопасности. CTO хочет больше телеметрии, CIO режет бюджет на облако. Это типичные примеры конфликтов.
Самый короткий путь в CTO — сделай свой продукт.
Не читать про стратегию, не ходить на конференции, не менеджерить команду. А взять и сделать что-то, где ты сам принимаешь решения и видишь результат: не в пулл-реквестах, а клиентах.
Если совсем технарь, то начни с опенсорса. Сделайте библиотеку, которой будут пользоваться. Это тоже продукт. Там тоже пользователи. Уже обратная связь, которую не придумал менеджер.
Ещё лучше взять пет-проект или сделать небольшой стартап с друзьями.
Я в студенчестве начинал карьеру с создания студии разработки, примерно десять человек, каждый со своей экспертизой. Были клиенты, продажи. Это был опыт про бизнес, продукт и людей, а не про код и архитектуру. Потом были стартапы. Из десяти идей до чего-то интересного доживала одна. Но каждый такой проект давал опыт, чего не даёт ни одна книга: хороший технический проект сам по себе никому не нужен. Его нужно донести до людей/рынка.
Хотите стать CTO, идите получать нетехнический опыт. Продукт, продажи, клиенты, смежные функции. Просто менеджерить команду и ходить на собеседования недостаточно.
Расширяйте нетворк. Общайтесь с реальными CTO, они покажут, что роль устроена совсем не так, как может казаться снаружи.
Близкий мне опыт. Во многом совпадает с тем, что я наблюдаю на практике.
Отдельно раскрыл бы источник этой разносторонности задач. Сначала цели компании, стратегия и рынок. Потом уже из этого вырастают продуктовые, инженерные, организационные и кадровые решения. У меня на эту тему есть близкая по духу статья: рынок, стратегия, инженерная культура.
Молодые CTO могут воспринимать архитектуру, найм, бюджеты, коммуникации с C-level, R&D как цель. Но всё это только инструменты для достижения целей/стратегии компании. Важно не перепутать инструмент с целью.
Хороший обзор, спасибо. Мне хочется в него добавить enterprise CRUD админки. Я бы упомянул там Refine и Ant Design Pro. Они закрывают типовые вещи: лэйаут, списки, формы, права, работу с данными.
Да, дистрибуция всегда была слабым местом разработчика. Она не сложнее разработки, просто разработчик годами тренирует производство и почти не тренирует продажу.
Инди разработчики игр начали зарабатывать не тогда, когда стало проще писать игры. Они начали зарабатывать, когда появились Steam и App Store. Там уже были люди, карты, доверие, быстрая доставка до клиента.
Когда у вайбкод проектов появится своя полка с покупателями, станет проще.
Добавил ссылку на перевод: chief technology officer strategy and engineering culture
Я как CTO, читаю эту статью как короткое объяснение для фаундеров и рекрутеров: автор нормально показывает, что CTO — стратегическая роль, которая не лезет в операционку и не превращается в «сеньора, который всё тянет сам».
В целом, я согласен со всеми пунктами, если не учитывать контекст.
В реальности, эта роль и ее фокусы меняются в зависимости от стадии компании и ситуации на рынке. Мне самому ближе роль CTO как бизнес-партнера. Работа над бизнес-стратегией тоже часть его работы: https://habr.com/ru/articles/907800/
Часть сам, часть с АИ. Уж очень много там связей. Больше 200. И надо бы еще добавить. Если кто-то найдет полезным, то покручу побольше. Там можно еще добавить описание того, как именно влияет пункт чек-листа на проблему.
Можно тут посмотреть связи и код: https://github.com/pahaz/pahaz.8iq.dev/blob/main/public/cto-checklist-vs-problem-ru.html#L469
Хороший разбор плохих кейсов. Я попробовал взять свою статью с чек-листом CTO и наложить на 36 проблем из статьи. Подумал, что может получиться что-то интересное.
С первой попытки, получилось не очень информативно. Потом добавил клик по пунктам и вроде можно посмотреть какие проблемы могут быть.
Но, самым наглядным получился вариант с двудольным графом.
Залил сюда: https://pahaz.8iq.dev/cto-checklist-vs-problem-ru.html если кому-то интересно пощелкать на связь задача CTO - проблемаы.
Может быть полезно, чтобы учесть возможные проблемы до момента их наступления.
Ссылки
Чеклист: https://habr.com/ru/articles/907800/
Проблемы: https://habr.com/ru/articles/965750/
Итог: https://pahaz.8iq.dev/cto-checklist-vs-problem-ru.html
Лично меня бесит, что все заявления компаний про высокие SLA / UPTIME это всегда маркетинг. Это значит, что если тебе нужно что-то сравнить, то ты будешь опираться на свой опыт, либо на опыт знакомых. Реально измерять никто не будет.
Крупные продукты всегда говорят о высоких SLA, но в реальности, такие сервисы состоят из большого числа компонентов/сервисов и когда один из них не работает, это не считается простоем. А когда таких компонентов десятки или сотни, то ты как пользователь постоянно ощущаешь как у тебя что-то вечно отваливается, но SLA будет 5 девяток. И вот с этой проблемой вообще ничего не сделать ...
Поэтому, вывод один: не читайте
советских газетзаявления сервисов касательно их SLA, это маркетинг.Мы разрабатываем open source продукт с MIT лицензией. У нас есть блок для работы с клиентами, если будет желание, то можем сделать коллаб. Код на гитхабе: https://github.com/open-condo-software/condo
Расскажу историю своей опенсорс платформы. Может кому-то будет полезно.
Я ожидал где-то тут увидеть ссылку на GitHub. С примером или чем-то подробным.
Open source для автора это всегда маленький продукт. Если это библиотека, то это оценка других разработчиков (комьюнити), кто готов ее использовать. Это прежде всего бесценный опыт.