Yet Another Burakov

Год 2020 — ржу над Левенчуком и Бесковым, когда они настаивают, что аналитиков нужно называть инженерами или проектировщиками. Да кому какое дело, вам ехать или шашечки?

Год 2026 — мечтаю, чтобы в дивном пост иишечном мире название Системный Аналитик было стерто из памяти людей. Вместе с экзистенциальным нытьем, можно ли без него пилить успешные продукты и системы, и что же он (не) должен делать.

Верните софтвер инженеров, софтвер дизайнеров, ну или еще кого придумайте.

#архитектура #анализ #AI

Други-подруги, хочу поделиться yet another проектом.

Мы год жили с идеей клуба аналитиков и ВНЕЗАПНО решились сделать это.

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

Поэтому запускаем Tech Analyst Club — клуб для опытных аналистов, которым интересно качаться в архитектуре и покорять иишечку. Фокус на практике, раз в неделю собираемся на воркшопах.

Сейчас можно посмотреть лендосик, а в понедельник в 18:00 мск проведем презентацию клуба. Приходите, будем рады.

Дада, все собрано на коленке за вечер, вы еще эквайринг не видели

Spec Driven Development

В комментах просили ссылок, накидаю сюда.
После того, как появился вайбкодинг, энтузиасты обнаружили, что просто промпт “сделай хорошо” для сложных задач не работает. А если после первой версии попросить модельку что-то доработать или поправить, то она начинает ломать старый код.

Так родилась идея, что на вход нужно давать более конкретные описания, а после контролировать действия агента. В итоге пришли к флоу:

Описываем хотелки —> Проектируем —> Декомпозируем —> Реализуем

Что-то знакомое? Почти как с людьми, только с агентами. Назвали подход Spec Driven Development.
Пока это лишь общая концепция, а не что-то конкретное. Нет единой терминологии, общих правил, принятых практик.

Наиболее популярные инструменты:
• SpecKit — от гитхаба
• Kiro — от амазона
• OpenSpec — опенсорс

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

Про реализацию SDD в SpecKit: часть 1, часть 2.

#вайбкодинг

#оффтоп

Сегодня день бэкапа, завтра день смеха.
Совпадение?

Уже в эту пятницу, 3-го апреля - очередное открытое мероприятие Devhands, “Введение в системный дизайн”.

Будет трех-часовое погружение в тему:
• что такое системный дизайн, программа для самопроверки и самостоятельного изучения системного дизайна: от сбора функциональных и нефункциональных требований до масштабирования, надежности, наблюдаемости
• наш фреймворк системного дизайна, другие фреймфорки и отличия
• демо-проект
• Q&A-сессия

🤩 Регистрация тут: https://devhands.ru/system_design_basics

Число зарегистрирванных уже трехзначное, и мы готовы :) Большое спасибо всем за проявленный интерес!

Этим ребятам доверяю, постараюсь дойти. Обещают авторский взгляд на сисдизайн.

#оффтоп

Читаю новости законотворчества и понимаю, что точно никакой AI нас не заменит.

#вайбкодинг

Как-то сел пилить относительно сложный проект в n8n и решил сделать это с гпт. В чатике спроектировали архитектуру, базу, нарезали логику на флоу. Получилось красивенько.

Увидел, что в нейтоне есть свой AI-агент. Тупенький, но неплохо делает каркас воркфлоу и дает инструкцию, что где нужно настроить. Потому что обучен на тоннах роднных доков и шаблонов.

Сначала ак и шел, но вспомнил: workflow в n8n — это обычный json с нодами, настройками и кодом внутри. А что это значит? Правильно, копируем сгенеренный драфт с инструкциям из нейтона в гпт, и просим перегенерить правильно. Ошибки так же отлаживаем. Получается нудно, но значительно быстрее.

Но нашлись люди, которые сделали открытый плагин и скилл под VS Code / Cursor.

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

Лютая дичь. Пошел тестить.

https://github.com/Etiennelescot/n8n-as-code

#AI #манагерское

Пока я философствовал, Александр Поломодов выпустил две статьи на эту тему:

От классического PDLC к AI-native разработке — как AI меняет процессы разработки

От AI-native разработки к AI-native организации (с примерами из опыта бигтехов) — как перестраивать организации вокруг AI-процессов

С иишечкой все будет бешено ускоряться, поэтому для выживания будут критичны изменения:

• процесс поставки должен стать короче, количество ролей уменьшиться

• структура управления будет более плоской, соотношение инженер-менеджер вырастет

Понятно, что это прогнозы, но выглядит логично и правдоподобно.

Вас не заменит AI, вас заменят процессы

Есть такой опенсоурс продукт для аналитиков AI IDE BAS — плагин для VS Code, в котором можно разрабатывать требования, делать техдизайн, генерить спеки.

Ребята молодцы, круто что у нас занимаются такими проектами, но я так и не понял, зачем генерить классические артефакты и передавать их разрабам, если я могу вооружиться курсором/кодексом/коворком и сразу получить код на их основе. Нужны ли код-агентам артефакты в том же виде, что и мясным разрабам? Вряд ли, намного эффективнее выглядит связка SDD + TDD.

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

Пока народ вокруг пытается только ускориться с помощью иишечки, можете не беспокоиться. Следите за процессами. Ну или меняйте(сь) сами.

Про интеграцию в дикой природе

Сам рассказывал про базовый алгоритм работы с интеграцией на крупных задачах:

0) Выявляем требования и собираем процесс в BPMN, EPC, CJM, Use Case или в любом другом удобном формате

1) Маппим его на существующие роли и системы с помощью контекстной диаграммы, на которой показываем отношения использования (взаимодействия). Уже здесь можем увидеть, что не хватает каких-то систем и функций

2) Показываем потоки данных на Data Flow Diagram. Здесь проверяем, везде ли есть нужные данные, кто мастер-система, что с актуальностью и частотой использования данных

3) Разворачиваем каждую стрелочку контекстной диаграммы в сценарий взаимодействия с помощью диаграммы последовательности. Проверяем, все ли методы есть для реализации сценариев, чего не хватает

4) Проектируем / дорабатываем API на основе п.3, прописываем структуру методов. Проверяем полноту по CRUDL+Search+Archive+Clone

5) Делаем трассировку: каждое взаимодействие из п.1 должно быть покрыто сценариями из п.3, объекты из п.2 должны появиться на уровне п.4. Если что-то где-то возникает из воздуха, то ищем, где мы продолбались

Выбор паттернов, специфику технологий и НФТ не рассматривали, ибо не впихнуть.

Перешлите знакомым, если будет полезно.

P.S. А еще постарайтесь не забыть по дороге, что вы аналитик.

#конференции #интеграция

Немного впечатлений с ИнфоСтарта

Если не обращать внимание, что код местами написан на русском, то особых отличий от “нашей” итшечки незаметно.

Роль аналиста 1С как будто моложе обычных сисаналистов, поэтому слышал много разговор про зоны ответственности, на сколько аналитик должен погружаться в харды, как работать с интеграцией и т.п. Примерно как 5-7 лет назад на AD, но по-другому.

Отдельно запомнился доклад Романа Данилова про сисдизайн для аналитика, к которому он приложил кучу полезных ссылок — перешлите знакомым джунам и вкатунам.

И особо ламповые пати спикеров. Хочу тперь сделать пару стримов, чтобы лучше познакомиться с этим миром.

#конференции

#интеграция #конференции

Завтра на ИнфоСтарте буду вещать аналитикам 1С про системный подход к интеграции.
Если будете там завтра, приходите заходите на чай знакомиться, если есть друзья из 1С — киньте им ссылку.

Это не кризис, это пиздец (с)

Кажется, SE были первой независимой школой по сисанализу. Когда делали NextWay, регулярно оглядывались на них. Для меня это одни из немногих фанатиков, кто исповедует no bullshit policy, а не рубит бабло на хайпе. И кроме нас с SE полностью живые программы сейчас никто не ведет, на сколько знаю.

Держитесь, ждем с новыми проектами.

#оффтоп

Похоже перплексити всерьез решил потягаться с гуглом. А что создал ты, юзернейм?

Ваш проект умрёт не из-за разработки

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

И ни разу я не видел проекта, который не запустился из-за медленной разработки.

Конечно, в долине смерти много бизнесов, где код говно, а программисты нарушают обещания. Но причина их смерти — не в программистах, а всё в той же просранной продуктовой работе: нулевой product-market-fit, несходящаяся экономика, неумение нанимать людей и тестировать гипотезы. Плохой код — скорее следствие общих проблем, а не причина.

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

#манагерское

Выводы, которые большинство сделает из поста:

— Вот видите, никому не нужна ваша чистая архитектура, профессиональный инженер говорит!

— Мы же говорили, во всех проблемах, включая разработку, виноват тупой бизнес!

Зато в комментах вспомнят: “Главная проблема музыки в России — это лично ты”.

#вайбкодинг

Чет подумал, что между аналитиком-проектировщиком и разработчиком лежит пропасть в плане фидбека от реальности.

Разраб каждый день что-то собирает, тестит, запускает. Результат, который можно пощупать руками, виден постоянно. Каждый день ощущаешь какой-то акт творения, который подкидывает простого дофамина. Ну как простого.

Аналист днями-неделями-месяцами пытается понять, что тут нахрен происходит, как со всеми договориться, и как бы все это собрать, чтобы оно работало. Результат — спеки и таски, которые однажды (возможно) кто-то запилит и выкатит. Акт творения почувствовать сложнее, нередко приходится добывать дофаминку из социальных поглаживаний. А я ж социопат

Интересно, каким было бы распределение по уровню счастья и депрессий?

Но вайбкодинг меняет игру.

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

Как аналист я счастлив: проектирую всякие штуки, могу пощупать и оценить результат без команды и всех этих кожаных. Ожидание и ревью — лишь небольшие издержки.

А чему ты радуешься на работе, юзернейм?

Товарищи продакты, смотрите, что тинек выкатил. Оно бесплатное, правда с экзаменом:

https://education.tbank.ru/experience-in-it/ml-product/

Тут трехдневная конфа про ИИ-разработку от стратоплана стартовала, пока интересно

https://entropy-x-stratoplan.com