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

Заметка на полях. Статья подъехала. Ребята нашли достаточно сильное статистическое подтверждение тому, что неоднородность вселенной и наблюдаемое расширение - следствие гравитационного взаимодействия и не требует введения "тёмной энергии". И вообще, расширение вселенной может быть иллюзией наблюдателя) В самой статье они заявили достаточно громко, что требуется некоторый пересмотр стандартной Фридмановской модели. Так что, покупаем попкорн и ждём шуток про физиков в тёмной комнате, которой нет.

Для меня примечателен оказался и метод исследования в т.ч. Обрабатывались исходные данные Байесовскими статистическими методами. Генеративная АИшечка в таких вопросах, кстати, должна давать достаточно серьёзные преимущества в построении предсказаний на моделях с достаточно большим количеством весов. Если кто-то думает в эту сторону (обработка данных наблюдений всякими корелляционными методами и построение предсказаний LLMами) попрошу ещё прокомментировать это предположение. Что там есть перспективного нынче.

Заметки на полях, как фиксация некоторых размышлений на тему.

В профильных чатах разработчиков всяких ИТшненьких систем пронеслись несколько мыслей, которые стоит для себя зафиксировать:
1. Современная разработка скорее строится на народных приметах вида: "Скрам-мастер без татух - к беде"
2. В итоговом ИТ-продукте будут реализованы только те качества, за каждый из которых есть выгодополучатель.

Если ещё плюсом немного подытожить наблюдения, то можно построить типовую модель качества ИТ-системы примерно так:

- Функциональное качество (а-ля UX)
- Инфраструктурная доступность сервиса
- Стоимость вывода в пром.применение "следующей версии"

Что интересно, есть ещё один значимый, но конфликтогенный параметр - это Стоимость подержки (оно же управление инцидентами, исправление ошибок эксплуатации и т.п.). Конфликтогенный он потому, что за разработку и поддержку отвечают разные организационные единицы, чаще всего, и разработанный исходный код передаётся "как есть" тем, кто его будет дальше эксплуатировать, и "забор" проходит по приёмке "отелом девопсов".

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

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

Т.е. если пользователей продукта в моменте достаточно для его поддержания, то качество продукта - ПРИЕМЛЕМО. И для владельца актива по производству продукта важно защитить основных поставщиков качества. А в нашем случае это: Кодописатели, админы инфраструктуры, менеджеры с палками, которые штрафуют ФОТ.

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

Заметки на полях. Про промпты. Кажется, в ближайшее время с нейросетями будет успешно работать тот кто сможет:

1. Концептуализировать процессы, и их алгоритмы
2. Концептуализировать предметную область
3. Ставить корректно задачи

Т.е. генеративные нейросетки не отменят компетентности. Они упростят распознавание лексики. Если с нейросеткой будет работать некомпетентный специалист, его результат ИИ не особо улучшит.

С другой стороны, очевидно, что будет запрос на такие нейросетки, которые смогут учить их пользователя пользоваться нейросетками =)

Отсюда для себя сделаю вывод чему стоит учиться:

1. Разрабатывать целостные, непротиворечивые описания мира
2. Описывать процессы (алгоритмизация)
3. Соблюдать контекст ведения рассуждения
4. Формулировать цели,
5 Декомпозировать цели на задачи

Заметки на инженерных полях. Был в 2023-м году на конференции "Стачка" и делал там доклад про то, какие инструменты есть и должны быть у архитектора. С тех пор значительно продвинулся в понимании этого вопроса, и на основании недавно прочитанного для себя заметочка:

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

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

Заметки на полях. Сегодня имел беседу про то, что такое управление конфигурацией. Как всегда. Две поляны между собой перекидываются какахами, кто более прав, а кто Лев...

1. Управление конфигурацией продукта (мутная тема достаточно, и крутится вокруг маркетинговых понятий в основном. Что-то типа "фича", "сторя","бизнес-ценность"... В русском понятийном пространстве это вообще заклинания, так-то).

2. Управление конфигурацией системы. А это про тяжёлые методологические абстракции высокого уровня вложенности.

Вы уже догадались, кто и чем может управлять? Правильно! Кто что в руках держит, тот и управляет. Если программист щупает код - то для него вся эта история про "бизнес-ценность" - это про подписанный акт приёмки. Точка. Если акт подписали, морду не разбили, руки не отрубили - бизнес ценность есть! Доказывать, что то, что я делаю сейчас соответствует ожиданиям "бизнеса"? Так код напишу, он сам себя и докажет! Это ж математика! Если работает и акт подписан - значит всё ок, ничего никому доказывать не надо! (Л - Логика ушла поспать на определении транзитивности отношений. Это второй курс. Дискретная математика. Разделы логика предикатов. Если что.)

А на уровне "Продуктовых аналитиков" есть что угодно, затем трактуемое как угодно. Зачем формализовывать потребности? Достаточно же написать "должна быть безопасная фича". И "квалифицированная, мотивированная команда экспертов".... У нас же все кто в ИТ высококвалифицированные, мотивированные команды профессионалов, да?)
В итоге имеем "аналитиков", которые сидят за плечами у "программистов" и говорят:

- А тут кароч кнопку такую, филолетовенькую, нарисуй, Василич просил, у него жена будет на показе, а она в таких туфлях ходить любит.

И когда Василич после показа софта с кнопкой подписывает акт, а потом спрашивает: - Куда бабки дели, ироды!? - то зовут сначала аналитика, который зовёт программиста, который говорит: - Василич, ну чо ты начинаешь, акт же подписали! И вроде все довольны, но что-то говной воняет...

Поэтому пока впечатление такое:

Искусственный интеллект не сможет победить естественный. То, что не существует, не сможет победить то, что стремится исчезнуть)

#идейное #управление_конфигурацией

Заметки на инженерных полях. После длительного перерыва пора открывать всякое. Тут в т.ч. мысли и лабораторный журнал.

Сегодня наконец-то попробовал написать приложение при помощи агента в Windsurf. Писал простенький RAG-сервис для локального контекста, чтобы можно было подкидывать себе в контекст всякое хранящееся в Markdown-ах. Хочу попробовать разработку требований организовать на этой теме.

Написал:

1. Функционал
2. Тесты
3. Доку
4. Руководства по кодированию.
5. Описание типовых процессов разработки и команд управления проектом
6. make-файлы

Впечатления:

1. Правильно заданный контекст в самом начале - решает очень много.
2. Энтропия действительно накапливается.
3. Продакшен решение получить можно. Но очень сложно.

На всё про всё - 3 тыщи рублей и токенов ещё осталось.

Ну и да, нужно очень хорошо понимать, что разработчик хочет сделать.

Заметки на полях. Образовательное.

Сегодня со ScrumTrek провёл мастер-класс по автоматизации при помощи LLM-ок некоторых простых действий в процессе разработки софта.

Даже доволен результатом по большей части.

Я для себя сейчас занимаюсь автоматизацией разработки образовательного контента. Что очень похоже. В принципе ничего сложного, но пара инсайтов:

1. Промпты можно компилировать в к-промпты. Компактные промпты. Это вообще огромный буст к качеству. И более того, скорее всего часть промптов нужно хранить эмбеддингами.

2. Можно говорить о новой специальности: инженер-конструктор контекста БЯМ. Со своей спецификой

3. Работа с генеративными моделями на данный момент - мета-навык. Даже пачка мета-навыков. Что незаурядной подготовки, образованности и дисциплины.

4. Есть гипотеза, что как продукт может потребоваться библиотека к-промптов в формате RAG-сервиса.

#аишечка #архитектура #образование

Заметки на полях. Обратил внимание, что:

1. Роль дневниковых форм рефлексии возрастает чуть ли не по экспоненте. Особенно с учётом всяких агентов.

Кажется, что наставничество принимает новые формы, и в этом есть возможность создать дополнительную ценность.

2. Лично у меня повысилась значимость способности БЫСТРО переключаться между контекстами.

При внедрении всяких агентов и необходимости контроля за ними роль навыка : "Переключить контекст мышления" - становится основной. Принцип "всё, что вам нужно - это внимание" выходит на первый план в вопросах любой эффективности.

#аишечка #образование #трудоспособность

Заметки на полях. Инженерное ИИшное. Сейчас активно перерабатываю своё рабочее пространство. Какие вещи сразу бросаются в глаза:

1. Один из ключевых современных продуктов, которые сразу хочется делать - это MCP-серверы для интеграции с различными средами. Промпты это конечно интересно, но наборы тулов в MCP - это инфраструктура. Она - основа всего.

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

3. Отслеживание качества контекста, его замусоренность и релевантность контекста - это топ метрика для контроля производительности. Осталось понять, как её считать. И высказывание Attention is all you need - это не только, и не столько сказано в отношении моделей. Это в принципе новый принцип жизни. Поэтому заведу себе рубрику про контроль внимания. На что оно направлено, какими свойствами обладает и всякое такое. Человечество наверняка накопало достаточно много.

#аишечка #внимание #инженерия

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

1. Состояние потока - это такое состояние, когда внимание полностью захвачено решаемой задачей.
2. Самая дорогая операция - переключение между задачами в разных контекстах.
3. Незавершённые задачи жрут внимание. Буквально. Техдолг жрёт внимание команды.
4. Мессенджеры и прочая электронная коммуникация жрёт внимание. И переключает контексты.
5. Люди в окружении либо требуют переключения контекста внимания, либо поддерживают решаемую здесь и сейчас задачу.

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

А вот отрефлексировав своё распределение внимания можно понять кто ему хозяин и кто им управляет.

#внимание

Заметки на полях. АИшное. В данный момент как некоторые мои коллеги отмечают, существует кризис инженерной культуры. Например известное DDD в англоязычной интерпретации для русскоязычных девопсов звучит как:
- DAVAI DAVAI DEPLOY (ссылка не на оригинал, но тож пойдёт).

С приходом штук типа Claude code, Windsurf, OpenClaw и подобных, на этом фоне достаточно оперативно, можно считать, что появилась "специальность" Машинист(ка) LLM. Сергей Баранов сформулировал это так:

Почему «Машинист LLM» — метко
Аналогия с машинистом или оператором ПТУ-шного толка на самом деле очень точная по нескольким причинам:
• Машинист управляет мощной машиной, но не проектирует её — он знает кнопки, рычаги и протоколы. Ровно то же самое делает промпт-инженер с LLM[skillfactory]
• Оператор — ещё честнее: в официальных реестрах профессий в России уже есть “оператор ЭВМ”, и “Оператор LLM” органично встаёт в этот ряд[sberbusiness]
• Низкий порог входа (3–9 месяцев обучения)  как раз соответствует ПТУ-шному формату, а не полноценному инженерному образованию

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

- Чем круче джип, тем дальше идти за трактором.

* Сервис twitter.com (ныне x.com - заблокирован на территории РФ по требованию генпрокуратуры как неисполняющий требования законодательства РФ)

#аишечка #инженерия #образование

Заметки на полях. Аишечное.
Приехал тут ко мне на днях Halo Strix-мини ПК. Я накатил не него бету убунты 26.04 и начал эксперименты по запуску домашнего сервера моделей.
Конфиг показывает 128 ГБ GPU RAM (Да, это не совсем честные GPU RAM, и на самые быстрые, но работает).

1. Модели запускаются =) Уже хорошо. Производительность на средних квантованных (Q6,Q8) моделях показывает порядка 10-20 токенов в секунду.
2. Потребление в 300 Ватт в час при активной нагрузке - это вполне годно.
3. Шумит приемлемо, примерно как фен в ванной когда там волосы сушат за дверью, если рядом стоять. Но спать под него нельзя конечно.
4. Работает через вайфай. Буквально висит на одной розетке, и доступен дома как сервис.

Какие работы на нём планирую выстроить:

1. Агентный фреймворк для решения всякой повседневщины.
2. Частично автоматизировать свои рабочие процессы.

Какие первичные выводы:

1. Если планируем учиться использовать ИИшку - такой инструмент дома обязателен.
2. Компетенций для установки сейчас достаточно почти у всех. Внешняя поддержка от Perplexity-Google - вполне решает вопрос "Я не умею". Но голову конечно надо прикладывать.
3. Нужно понимать как будет окупать себя эта штука. Какие конкретно проблемы она будет помогать решать.

#инженерия #аишечка

Ещё немного заметок на полях про организацию рабочего пространства.

1. Создание собственного рабочего пространства занимает теперь часы, а не дни изучения документации на инструменты. Если вы знаете как они работают - это ускоряет вас ещё в пару раз.
2. Рабочее место любого специалиста в ближайшие три-пять лет - это что-то вроде собираемого под заказ обвеса нескольких конкретных моделей. Например вы - агроном/слесарь/водопроводчик/водитель... У вас есть конкретная работа. Вот уже сейчас выделяя 2-3 часа в день на модернизацию своего рабочего окружения можно через год уделать на порядок всех, кто этим НЕ будет заниматься. Потому что цикл принятия решений у вас будет быстрее точнее на порядки чем у тех, к ого этого не будет. Так что на это, если хотим просто выжить, придётся выделить время. (Иначе нас всех убьют нахуй-)
3. Есть практическая задача: конкретным предметникам давать в руки рабочие инструменты на базе ИИшек.
4. Локальный инференс - понятен, работа в оффлайне и чебурнете - это наше всё на ближайшую жизнь. Придётся выстраивать это дело, как ни уклоняйся.
4. Первое, что нужно фиксировать и на что обращать внимание - это агенты помогающие личной эффективности. Которые помогут выйти из состояния пожара.
5. Всему этому благоденствию жутко мешает состояние вечного "пожара" и гонки за "мне тут срочно надо". А это война за контроль внимания между кусками нашего мозга.

Движение по агентному фреймворку:

1. Стало понятно, что набор спек "напиши мне MCP сервер для ..." - это то, что будут просить завтра.
2. Автоматизация рабочих процессов пошла. Хорошими промптами и переключением между моделями получилось выстроить чась пайплайна разработки презентаций для бауманки.
3. OpenClaw - это не выход. Стоит посмотреть на такие среды разработки как Codeium, Codex, Claude Code и всё это встроить в MS VS Code. Несколько агентных среды над одним репозиторием - это вполне рабочая тема.
4. Написал MCP-сервер для локальной генерации эскизов слайдов. Буду думаь как это довести до ума, чтоб оно само рисовалось по большей части.

#аишечка #инженерия #внимание

Заметки на полях. ИИшное.

Продолжаю разбираться с темой организации рабочего пространства. Для решения практических задач приходится делать примерно следующее:

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

При этом чтобы среда "более-менее" работала понадобится:

1. Операционный каркас. Набор промптов описывающих ролевую деятельность.
2. Соглашения о правилах документирования проекта
3. Набор типовых вызовов skills/workflows
4. Набор настроек среды разработки
5. Настроенная инфраструктура CiCd. Сразу.

За это время сделал себе домашний генератор кастомных картинок на stable-diffusion. Генератор работает по api и будет встроен в MCP-сервер для создания слайдов для презентаций.

На что обращать внимание:

1. Проект всегда будет деградировать со временем. Это неизбежно. Необходимо делать пайплайны очистки устаревшего кода. Агенты плохо понимают и удаляют легаси и депрекейты.
2. Размер пакета задач - критически важен. Можно подключить и нужно подключать внешнюю систему планирования для контроля задач и хранения описаний. На ОЧЕНЬ маленьких проектах работают MD-шки. Так что трекеры задач похоже преобразуются, но не умрут). 1-2 задачи за пакет - это максимум. Более того, dev-qa-archreview-ops-uat по одной таске на разработку - это 5 диалогов в среде разработки.

Пока всё достаточно тривиально.
#инженерия #аишечка

Заметки на полях. Инженерно-образовательное.

В ближайшее время буду пилить небольшой кластер АЛЬТ Виртуализации на 750+ ядер и 8 ТБ оперативы. Посмотрим как сможет завестись и что будет с сетями (что особо интересно). Площадка - МГТУ им. Баумана. (Да, я в курсе, что это Proxmox в базе).

- Пока на площадке собрал железо, подвели питание и выполнил основную коммутацию оптики и меди.
- Техпроект у меня готов, и Базальт достаточно дружелюбно отнёсся к просьбе проконсультировать по технической части, поскольку есть контракты и контакты. Обещают 3 месяца регулярно отвечать на вопросы в рамках "тех.пресейла".
- А ещё разработчики Базальта оказывается делают вебинары по средам на тему поддержки своего продукта и, говорят, что там можно позадавать вопросов. Вебинары вроде бы даже открытые, или по договорённости. Схожу к ним на следующей неделе, поспрошаю.

Ну и заодно проверим как эта штука интегрируется во всякое современное SSO, как там с Terraform-провайдерами и их функциями, что с пулами ресурсов, QoS-ом сетей и подобной мультитенантностью. Что там можно, что не стоит делать и вот вот это всё.

Для сравнения рядом стоит подобный кластер BASIS от РТК. Будет занятно сравнить эти два продукта в нашем случае.

Периодически буду накидывать тут всякого по теме)

#инженерия #цод #proxmox #альтвиртуализация