Для руководителей разработки

ИИ уже есть. А времени всё нет.

Разбираюсь, почему новые инструменты пока не экономят время. Вместе с командой меняем один рабочий процесс и сравниваем результаты на ваших задачах.

Четыре ситуации

Что сейчас происходит в вашей команде?

В каждом направлении разбираем, что перестало работать, за что никто не отвечает и с какого решения начать.

Стабильный выпуск продукта

Что видно
Планы меняются, а релизы стоят на месте.
За что никто не отвечает
Кто принимает решения на стыке продукта и разработки.
Первое решение
Уточнить зону ответственности, порядок работы или роль и снова измерить результат.

ИИ в разработке

Что видно
Пилотов с ИИ всё больше, а выпускать продукт быстрее и надёжнее не получается.
За что никто не отвечает
Кто задаёт требования, проверяет качество и отвечает за источники данных.
Первое решение
Выбрать один рабочий процесс и договориться, как проверять результат.

Безопасность ИИ-продуктов

Что видно
ИИ-функция может незаметно навредить пользователю в работающем продукте.
За что никто не отвечает
Кто определяет допустимый риск и когда решение принимает человек.
Первое решение
Договориться, в каких случаях проверка человеком обязательна.

Надёжность и безопасность

Что видно
Система, от которой зависит выручка, не выдерживает атаку или нагрузку.
За что никто не отвечает
Кто разбирает причины сбоев, настраивает защиту и следит за системой.
Первое решение
Выбрать первую меру защиты от сбоя и назначить ответственного.

Кейсы из практики

Что изменилось и за счёт какого решения.

В каждом кейсе описаны исходная ситуация, принятое решение и результат с его ограничениями. Моя роль указана отдельно.

Как наладили выпуск новых функций

Наладить выпуск продукта

После смены CTO не было общей картины, как устроена платформа.

Решение
Заново определить, что делает каждый сервис и как они связаны.
Результат
У команды появилась общая схема системы: кто за что отвечает и как изменения доходят до релиза.
Роль
CTO
Читать кейс
Наладить выпуск продукта

Как разобраться в системе без документации

ИИ в разработке

Платформа большая, документации почти нет. Изучить всё вручную в срок не получалось.

Решение
Описать систему по коду. ИИ-агентам выдавать нужные части описания по мере работы.
Результат
У команды осталось описание системы, по которому можно проверять инженерные решения.
Роль
CTO
Читать кейс
ИИ в разработке

Уязвимость в Redis нашли до запуска

Безопасность ИИ-продуктов

Перед запуском своего ИИ-продукта проверил, какие данные злоумышленник мог забрать из хранилища сессий.

Решение
Убрать из Redis токены доступа (bearer-токены). Добавить проверку при каждой сборке.
Результат
Токены убрали. Теперь сборка останавливается, если в Redis снова находится строка, похожая на токен доступа.
Роль
Основатель и архитектор ИИ-продукта
Читать кейс
Безопасность ИИ-продуктов

DDoS: когда атака похожа на обычных пользователей

Надёжность и безопасность

Платформу заваливали запросами. Часть атак имитировала действия обычных пользователей.

Решение
Оставить Cloudflare для большого потока запросов. За ним добавить проверку поведения в приложении.
Результат
Cloudflare принимал на себя поток запросов, а отдельный слой защиты проверял поведение внутри приложения.
Роль
CTO
Читать кейс
Надёжность и безопасность
Посмотреть все кейсы

Activation Sprint

Меняем один участок работы и решаем, что дальше.

Платный Activation Sprint обычно занимает 7–10 рабочих дней. Объём работы фиксирован: сначала проверяем, подходит ли задача, затем согласуем цену.

За это время вносим одно изменение в работающую систему и измеряем эффект. В команде остаётся ответственный за дальнейшую работу, а у нас есть основания решить, продолжать ли. Одним отчётом дело не ограничивается.

Как работаем и кому это подходит

Проверить изменение и передать работу команде.

  1. СигналРазобраться, что именно происходит.
  2. ОграничениеПолучить доступ к данным и зафиксировать исходные показатели. Если прямого измерения нет, согласовать косвенное.
  3. РешениеВыбрать небольшое изменение и договориться, какие риски недопустимы.
  4. РезультатИзмерить эффект и передать дальнейшую работу конкретному человеку в команде.

Подходит

  • Доступ к данным и людям, принимающим решения
  • Исходные показатели или согласованный косвенный показатель
  • Человек в команде, который примет дальнейшую работу

Не подходит

  • Бесплатный аудит
  • Найм отдельных специалистов в вашу команду
  • Внедрение инноваций ради самого внедрения

Заметки и об авторе

Как я разбираю задачи и принимаю решения.

В заметках разбираю решения из практики. На странице об авторе можно посмотреть, какой опыт за ними стоит.

Риски и надёжность

Когда системе нужно остановиться или передать решение человеку? Как отказать безопасно?

Заметки о рисках продукта
Об Олеге

Начать с контекста

Необязательно сразу точно знать, что сломалось.

Расскажите, что происходит. Можно без готового брифа и выбранного формата работы: по описанию я пойму, смогу ли помочь.

Написать в Telegram

Отвечаю в течение одного рабочего дня.