У меня сейчас вот эта роль +роль аналитика и следователя. Маплюсь хорошо, но не полностью:) И целей чуть больше. Как продакт выстраиваю процессы так, чтобы TTM продуктового эксперимента был часы, а не месяц+, протаскиваю новые для компании технологии через MVP фичи, провожу семинары по ним, как могу влияю на delivery процесс, но с этим туго пока.
Есть вторая активность как и следователя. Она отчасти маппится на первую. Например, делаешь небольшой продукт, у которого TTM по мелким фичам 15 минут. С другой стороны фронт мобильного приложения, который релизится раз в 2 недели с долгим дорогим регрессом и сборкой фич от нескольких команд. Челендж - выпускать небольшие фичи связанные с фронтом за часы вместо месяца.
Может пора менять работу? Продукт есть и стабильно развивается. Зоопарк тот ещё. Найдя новый проект принесёшь больше пользы и научишься чему-то новому. Команда большая, стоите дорого, фичи пилите медленно.
Вот я как десктоп ставлю раз в несколько лет и довольно быстро сношу или просто перестаю использовать. Часто встречаются: 1. Проблемы с драйверами. Видео, звук, блютуз колонка. Без экзотики.
2.Лаги. В том числе на достаточно мощном железе.
3.Много действий при установке софта. В том числе распространённого
4. Отсутствие GUI под часть продуктов. Тот же Яндекс диск, например
5. Софт часто не оптимизирован под Linux. В последнее время такое встречается реже
6. Часть приложений просто отсутствует или существуют лишь номинально. Попробуйте ЭЦП в РФ использовать и получите куче приключений.
Сейчас оставил графический интерфейс только на одной из виртуалок, но подключаюсь через него не часто. Ну и вишенка это то, что есть просто привычка. Руки сами нажимают хоткеи в Винде и без них совсем тоскливо в Linux.
Да вот наоборот с возрастом больше удовольствия и меньше тревожности получаешь. На волне быть легче за счёт широты. Многие молодые коллеги боятся, что LLM их без работы оставит, а мне приходилось 3 раза фактически перезапускать карьеру после 5-15 лет глубокого погружения в какую-нибудь технологию.
Фантастические нормы прибыли и пустой рынок во многих нишах конечно привлекателен для бизнеса. Как только санкции снимут, а политические риски снизятся многие вернуться. Первыми будут глобальные компании из разных областей. Но пока никаких предпосылок не видно. Хороший пример что будет дальше - Иран.
Попробуйте MCP + примеры типовых запросов с джойнами с комментарием к каждому. МCP сам выдирает нужную часть структуры БД и строит запрос. На Postgre пишет прекрасно и локанично. В том числе со сложными структурами.
Проводил коллегам воркшоп как раз на эту тему и во время него аналитик, у которого с SQL лучше, чем у 80% разрабов, предложил один вариант, а Sonet 3,7 более локаничный и красивый с учётом не очевидных условий, подсмотренный в примерах. В качестве инструмента был Cursor.
Когда-то я был прямо фанат ООП. Страуструп был вычитан до дыр, С++ победили паскаль и стал любимым языком. Ведь там есть перегрузка операций и множественное наследование! Позже меня затянуло сначала в 1С, а потом и вовсе в PL/SQL лет на 15 (считай паскаль для БД Oracle). В 1С я поругивался на отсутствие нормального SQL и ООП, при работе с Oracle ERP подбешивала денормалищация.
Потом были весёлые истории с асинхронностью, облаками и т. д.
Итог простой. Пользуйся с умом. Если надо быстро и качественно фигачить, используй ООП по минимуму. В догонку к ООП распределеные транзакции, нормализацию в БД, разноцветные книжки для архитекторов и много чего ещё.
Отсутствует важная часть про НФТ. Раз сейчас Excel, то предположу, что речь идёт о не более, чем нескольких миллионах записей. Я не архитектор, а просто аналитик. Здесь точно нужны распределеные транзакции?
Есть ощущение, что наши архитекторы думают, что надо делать как описано вот в таких статьях и книжках известных цветов. В итоге показываешь бизнесу MVP сделанный по фану за выходные, а архитекторы приносят что-то с TTM 7-9 месяцев для целой команды.
По возможности избегайте глобальных транзакций - вот прямо в точку. Современные БД шустры. Можно разделять чтение и запись, шардировать, кэшировать данные на стороне сервисов, переносить аналитическую нагрузку, чистить старые транзакции и ещё 1001 способ. Не надо лишний раз делить то, что отлично работает вместе. Исключение - внешние сервисы. Классический пример - оплата заказа.
Я бы ещё про качество данных добавил. Как только есть распрелеленная транзакция или простой пайплайн в одну сторону сразу подумайте как будете сверять данные с учётом того, что в моменте они не консистентны.
Outbox хорош, но гарантированно хорош только на уровне тригера БД. Это гарантирует генерации события по каждому изменению нужной сущности и не потребует переписывания всех интеграцмй.
Вот что то у меня куча других примеров, когда делали всё как сказали архитекторы. В итоге TTM, X8, раздутый штат и убежавшие далеко вперёд конкуренты. Такие проекты закрывают или признают неудачными.
Если технически влезает в одину команлу и БД на старте, то нельзя раздувать и делать "правильно' 5 микросервисов с 6-ю интеграциями. Будет эффект - появятся ресурсы на рефакторинг. Большие монополисты могут позволить себе иные подходы. Видел изнутри, к сожалению.
Ну вот прямо сейчас пытаюсь с LLM новые фичи делать практически в одного. Что приходится изменять: 1. Подход к архитектуре. ТТМ надо сокращать до 30-ти минут с 2-х недель. Это возможно только с минимальным количеством интеграций. Универсальное решение на нижнем уровне - общая БД. В моём случае это стэндбай на чтение + DWH. В противном случае будете заблочены соседними командами. 2. Заточенность на тесты в полях. Моделирование на ретро данных часто дольше и менее правдиво, чем проверка в поле. 3. Постепенная раскатка новых версий. Не отдельных фич под фича флагами, а прямо существенных изменений. Раскатил на одного, собрал обратную связь и метрики, если терпимо, на 10 или 100 пользователей и так далее. Пользователь при этом не должен ничего делать на своём устройстве (у меня мобильно приложение). 4. Выделение отдельных компонентов, которые создаются и развиваются при активном использовании LLM. Изменять старый код кратно сложнее, чем нагенерить новый и потом с помощью LLM поддерживать. 5. Vibe-codinng не работает. Даже с кучей тестов. Рано или поздно придётся посмотреть в код и разобраться. Лучше рано. И надо знать алгоритмы, структуры данных, системный дизайн, уметь работать с данными, декомпозировать задачи и пр. Руками пишу мало (обычно SQL), чаще прошу что-то поправить или переделать, но это далеко не Vibe-coding. 6. Язык важен. На Python или JS LLM пишет отлично, на GO терпимо, на Java уже так себе.
Ну я сейчас так и использую. Создаю именно прототипы, которые проверяю на отдельных пользователей. В части ML историй заходит отлично. Например, показать партнёрам, которые строят нам маршруты для курьеров, что на время вручения следующего заказа существенно влияет этаж на точке старта и в точке финиша. Модель, которая считает перемещения курьера и пострренная за несколько дней "на коленке" даёт погрешность в 3.2 раза меньше, чем маршрутизатор от яндекс. Без всякого знания карт. На выходе идеи с цифрами и прототипами. Это смело отдаётся в разработку командам.
Или сделать "волшебный" стеллаж. Когда курьер или покупатель подходит к стеоажам, то полка с его заказом подсвечивается + система проверяет корректность взятия заказа.
Это те кейсы, в корорых LLM зашла идеально замаоследние 5 месяцев. Но где то не работает совсем. Например, использование mqtt для прокидывания событий с бэка на фронт мобильного приложения. Основные риски с авторизацией и CD LLM никак не пояснила, а только ввела в заблуждение.
В общем, применение LLM заходит примерно для 20% продуктовых гипотез, агенты позволяют быстрее анализировать данные, но пока не согласованы с безопасниками. И да, такой продакт должен уметь и в ML и в пролаинутый SQL и в JS и в архитектуру. И быстро разбираться в том, с чем раньше не сталкивался.
И вайпкодинг не работает. Приходится читать и просить переписывать. Изменять структуры двнных и алгоритмы, грамотно управлять котекстом. Дли меня это просто большой ускоритель по созданию MVP и прототипов.
Natural language → MCP → SQL пройдёт по безопасности в большинстве компаний только для тестовых сред с обезличенными данными. Конечно, возможны хитрые варианты ограничений, но они обычно крайне дрявые и пускать в DWH внешнюю систему мало кто согласится. Хорошая альтернатива - сгенерировать доку по структуре + описание с помощью MCP, добавить в неё примеры популярных запросов. Обычно она влазит в контекстное окно. Дальше LLM генерит SQL, который запускается автоматом и показывается продактам.
Спасибо. Отличная статья с отличными ссылками. Мне не хватило про работу в полях для понимания физических и бизнес процессов при построении модели. Несоответствие метрики задаче мой личный топ. Текущий пример - сколько стоит опоздание курьера к клиенту для компании. Продакты хотят, чтобы опозданий было просто меньше, но когда идёшь в нюансы, то клиенты терпимо относятся к опозданию до 5 минут, сильно расстроены после 15, а после 20-ти начинают активно отказываться от заказанной еды, приходится сдабривать их бонусам.
Круто. Математика за месяц, работа с данными и Python ещё полтора. Вы берете таких аналитиков на работу? Просто регулярно вижу попытки скормить всё что есть нейронке, а потом попытаться её подкрутить с вполне понятным результатом. Или составить отчёт для продактов в формате который они просят без уточнений ценности и источников данных с точки зрения бизнеса.
А почему зависимость от Open AI? У них модель по умолчанию для платной версии Sonet 3.7 и МСP для агентских фич. А вот o3mini-hight в платную подписку не входит.
А статья отличная. Пишите ещё. И курсор также хорош. Каждый день что то новое в нем для себя открываю.
У меня сейчас вот эта роль +роль аналитика и следователя. Маплюсь хорошо, но не полностью:) И целей чуть больше. Как продакт выстраиваю процессы так, чтобы TTM продуктового эксперимента был часы, а не месяц+, протаскиваю новые для компании технологии через MVP фичи, провожу семинары по ним, как могу влияю на delivery процесс, но с этим туго пока.
Есть вторая активность как и следователя. Она отчасти маппится на первую. Например, делаешь небольшой продукт, у которого TTM по мелким фичам 15 минут. С другой стороны фронт мобильного приложения, который релизится раз в 2 недели с долгим дорогим регрессом и сборкой фич от нескольких команд. Челендж - выпускать небольшие фичи связанные с фронтом за часы вместо месяца.
Может пора менять работу? Продукт есть и стабильно развивается. Зоопарк тот ещё. Найдя новый проект принесёшь больше пользы и научишься чему-то новому.
Команда большая, стоите дорого, фичи пилите медленно.
Вот я как десктоп ставлю раз в несколько лет и довольно быстро сношу или просто перестаю использовать. Часто встречаются:
1. Проблемы с драйверами. Видео, звук, блютуз колонка. Без экзотики.
2.Лаги. В том числе на достаточно мощном железе.
3.Много действий при установке софта. В том числе распространённого
4. Отсутствие GUI под часть продуктов. Тот же Яндекс диск, например
5. Софт часто не оптимизирован под Linux. В последнее время такое встречается реже
6. Часть приложений просто отсутствует или существуют лишь номинально. Попробуйте ЭЦП в РФ использовать и получите куче приключений.
Сейчас оставил графический интерфейс только на одной из виртуалок, но подключаюсь через него не часто.
Ну и вишенка это то, что есть просто привычка. Руки сами нажимают хоткеи в Винде и без них совсем тоскливо в Linux.
Да вот наоборот с возрастом больше удовольствия и меньше тревожности получаешь. На волне быть легче за счёт широты. Многие молодые коллеги боятся, что LLM их без работы оставит, а мне приходилось 3 раза фактически перезапускать карьеру после 5-15 лет глубокого погружения в какую-нибудь технологию.
Да это главное, за что я его полюбил! Сперва бы паскаль с begin end, потом С, С++ с {}. А тут чистота и красота!
Фантастические нормы прибыли и пустой рынок во многих нишах конечно привлекателен для бизнеса. Как только санкции снимут, а политические риски снизятся многие вернуться. Первыми будут глобальные компании из разных областей. Но пока никаких предпосылок не видно. Хороший пример что будет дальше - Иран.
Попробуйте MCP + примеры типовых запросов с джойнами с комментарием к каждому. МCP сам выдирает нужную часть структуры БД и строит запрос. На Postgre пишет прекрасно и локанично. В том числе со сложными структурами.
Проводил коллегам воркшоп как раз на эту тему и во время него аналитик, у которого с SQL лучше, чем у 80% разрабов, предложил один вариант, а Sonet 3,7 более локаничный и красивый с учётом не очевидных условий, подсмотренный в примерах. В качестве инструмента был Cursor.
Когда-то я был прямо фанат ООП. Страуструп был вычитан до дыр, С++ победили паскаль и стал любимым языком. Ведь там есть перегрузка операций и множественное наследование! Позже меня затянуло сначала в 1С, а потом и вовсе в PL/SQL лет на 15 (считай паскаль для БД Oracle). В 1С я поругивался на отсутствие нормального SQL и ООП, при работе с Oracle ERP подбешивала денормалищация.
Потом были весёлые истории с асинхронностью, облаками и т. д.
Итог простой. Пользуйся с умом. Если надо быстро и качественно фигачить, используй ООП по минимуму. В догонку к ООП распределеные транзакции, нормализацию в БД, разноцветные книжки для архитекторов и много чего ещё.
Хмм... Из FIGMA прототип курсор использовали с MCP? Я совсем не гуру во фронте, но MCP для БД и FIGMA must have для агентского режима.
Отсутствует важная часть про НФТ. Раз сейчас Excel, то предположу, что речь идёт о не более, чем нескольких миллионах записей. Я не архитектор, а просто аналитик. Здесь точно нужны распределеные транзакции?
Есть ощущение, что наши архитекторы думают, что надо делать как описано вот в таких статьях и книжках известных цветов. В итоге показываешь бизнесу MVP сделанный по фану за выходные, а архитекторы приносят что-то с TTM 7-9 месяцев для целой команды.
По возможности избегайте глобальных транзакций - вот прямо в точку. Современные БД шустры. Можно разделять чтение и запись, шардировать, кэшировать данные на стороне сервисов, переносить аналитическую нагрузку, чистить старые транзакции и ещё 1001 способ. Не надо лишний раз делить то, что отлично работает вместе. Исключение - внешние сервисы. Классический пример - оплата заказа.
Я бы ещё про качество данных добавил. Как только есть распрелеленная транзакция или простой пайплайн в одну сторону сразу подумайте как будете сверять данные с учётом того, что в моменте они не консистентны.
Outbox хорош, но гарантированно хорош только на уровне тригера БД. Это гарантирует генерации события по каждому изменению нужной сущности и не потребует переписывания всех интеграцмй.
Вот что то у меня куча других примеров, когда делали всё как сказали архитекторы. В итоге TTM, X8, раздутый штат и убежавшие далеко вперёд конкуренты. Такие проекты закрывают или признают неудачными.
Если технически влезает в одину команлу и БД на старте, то нельзя раздувать и делать "правильно' 5 микросервисов с 6-ю интеграциями. Будет эффект - появятся ресурсы на рефакторинг. Большие монополисты могут позволить себе иные подходы. Видел изнутри, к сожалению.
Ну вот прямо сейчас пытаюсь с LLM новые фичи делать практически в одного.
Что приходится изменять:
1. Подход к архитектуре. ТТМ надо сокращать до 30-ти минут с 2-х недель. Это возможно только с минимальным количеством интеграций. Универсальное решение на нижнем уровне - общая БД. В моём случае это стэндбай на чтение + DWH. В противном случае будете заблочены соседними командами.
2. Заточенность на тесты в полях. Моделирование на ретро данных часто дольше и менее правдиво, чем проверка в поле.
3. Постепенная раскатка новых версий. Не отдельных фич под фича флагами, а прямо существенных изменений. Раскатил на одного, собрал обратную связь и метрики, если терпимо, на 10 или 100 пользователей и так далее. Пользователь при этом не должен ничего делать на своём устройстве (у меня мобильно приложение).
4. Выделение отдельных компонентов, которые создаются и развиваются при активном использовании LLM. Изменять старый код кратно сложнее, чем нагенерить новый и потом с помощью LLM поддерживать.
5. Vibe-codinng не работает. Даже с кучей тестов. Рано или поздно придётся посмотреть в код и разобраться. Лучше рано. И надо знать алгоритмы, структуры данных, системный дизайн, уметь работать с данными, декомпозировать задачи и пр. Руками пишу мало (обычно SQL), чаще прошу что-то поправить или переделать, но это далеко не Vibe-coding.
6. Язык важен. На Python или JS LLM пишет отлично, на GO терпимо, на Java уже так себе.
Ну я сейчас так и использую. Создаю именно прототипы, которые проверяю на отдельных пользователей. В части ML историй заходит отлично. Например, показать партнёрам, которые строят нам маршруты для курьеров, что на время вручения следующего заказа существенно влияет этаж на точке старта и в точке финиша. Модель, которая считает перемещения курьера и пострренная за несколько дней "на коленке" даёт погрешность в 3.2 раза меньше, чем маршрутизатор от яндекс. Без всякого знания карт. На выходе идеи с цифрами и прототипами. Это смело отдаётся в разработку командам.
Или сделать "волшебный" стеллаж. Когда курьер или покупатель подходит к стеоажам, то полка с его заказом подсвечивается + система проверяет корректность взятия заказа.
Это те кейсы, в корорых LLM зашла идеально замаоследние 5 месяцев. Но где то не работает совсем. Например, использование mqtt для прокидывания событий с бэка на фронт мобильного приложения. Основные риски с авторизацией и CD LLM никак не пояснила, а только ввела в заблуждение.
В общем, применение LLM заходит примерно для 20% продуктовых гипотез, агенты позволяют быстрее анализировать данные, но пока не согласованы с безопасниками. И да, такой продакт должен уметь и в ML и в пролаинутый SQL и в JS и в архитектуру. И быстро разбираться в том, с чем раньше не сталкивался.
И вайпкодинг не работает. Приходится читать и просить переписывать. Изменять структуры двнных и алгоритмы, грамотно управлять котекстом. Дли меня это просто большой ускоритель по созданию MVP и прототипов.
Странно, что выложена не автором. Статья отличная, с хорошим фрейимворком по внедрению изменений и рекомендациями в части AI.
Последние годы принесли настоящий бум автономных ИИ-агентовПрямо годы?Natural language → MCP → SQL пройдёт по безопасности в большинстве компаний только для тестовых сред с обезличенными данными. Конечно, возможны хитрые варианты ограничений, но они обычно крайне дрявые и пускать в DWH внешнюю систему мало кто согласится.
Хорошая альтернатива - сгенерировать доку по структуре + описание с помощью MCP, добавить в неё примеры популярных запросов. Обычно она влазит в контекстное окно. Дальше LLM генерит SQL, который запускается автоматом и показывается продактам.
Спасибо. Отличная статья с отличными ссылками. Мне не хватило про работу в полях для понимания физических и бизнес процессов при построении модели. Несоответствие метрики задаче мой личный топ. Текущий пример - сколько стоит опоздание курьера к клиенту для компании. Продакты хотят, чтобы опозданий было просто меньше, но когда идёшь в нюансы, то клиенты терпимо относятся к опозданию до 5 минут, сильно расстроены после 15, а после 20-ти начинают активно отказываться от заказанной еды, приходится сдабривать их бонусам.
Круто. Математика за месяц, работа с данными и Python ещё полтора. Вы берете таких аналитиков на работу? Просто регулярно вижу попытки скормить всё что есть нейронке, а потом попытаться её подкрутить с вполне понятным результатом. Или составить отчёт для продактов в формате который они просят без уточнений ценности и источников данных с точки зрения бизнеса.
А почему зависимость от Open AI? У них модель по умолчанию для платной версии Sonet 3.7 и МСP для агентских фич. А вот o3mini-hight в платную подписку не входит.
А статья отличная. Пишите ещё. И курсор также хорош. Каждый день что то новое в нем для себя открываю.