На VTORNIK.Вечер#9 послушала Сергея Рассудительнова из Альфа-Банка. 15+ лет в банках, опыт в аналитике, стратегии, ИИ. Говорил не про технологии, а про то, что происходит вокруг них.

Мысли, которые зацепили:

1. Разработка — только треть пути. По оценке спикера, 30% усилий уходит на код, 70% — на внедрение. «Запустили в прод» — это не финальная точка проекта. Нужно еще добиться реального использования, изменения бизнес-процесса и измеримого эффекта.

2. Зависимости убивают проекты. Legacy-системы, неготовый бизнес-процесс, чужие приоритеты — всё это нужно честно оценивать до защиты бюджета, а не после. Стоимость организационных зависимостей часто больше стоимости разработки.

3. Деньги дают не за хорошую проработку. Учитывать бюджетный цикл, политическая поддержка, социализация идеи до комитета. Если у первого лица есть интерес — у проекта есть шанс. Если нет — бесконечные круги согласований с ИБ, HR и тд. Полезно упаковать несколько идей в один крупный проект: им проще управлять и легче получить ресурсы.

4. Руководитель должен погружаться в архитектуру, а не только слушать статусы. Первые три месяца — погружение в детали, минимум на 2–3 уровня ниже: как устроен RAG-пайплайн, откуда берутся данные, где критическая зависимость. Внимание не на демо, а на системный дизайн: бизнес-заказчик отвечает за требования, ИТ/ИИ — за архитектуру. «Скорость хорошая, направление не то» — это понимают слишком поздно, когда исправить уже нельзя.

5. Коммуникация — часть внедрения, а не финальный PR. Рассказывать о проекте нужно с самого старта: старт → демо → кейс → внедрение → результат → масштабирование. Тихий проект, который внезапно отменили, не наносит репутационный ущерб, по сравнению с открытой историей с распиаренными промежуточными итогами.

6. Важно понимать, где процессы не детерминированы и ИИ принесет больше эффекта, отличия по инфре и новым ролям вроде разметчиков. В остальном ИИ проекты не отличаются от обычных ИТ решений.

Для меня это откровенное выступление откликнулось, оргвопросы действительно убивают проект чаще, чем разработка. И продакту надо над ними работать.