Услышал тут про интересную практику: когда бизнес-аналитики сопровождают разработку какой-то фичи до конца.

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

Когда я услышал всё это, сразу сказал — это уже не бизнес-аналитики, это фича-оунеры (feature owners). Я, честно говоря, просто из головы этот термин выдумал, но тут же решил проверить — и что вы думаете? Всё уже давно придумано, есть эти самые фича-оунеры, и даже есть статья 'Are feature analysts the new business analysts?'

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

Получается плавный вход в роль продакта — ответственность ещё не за весь продукт, можно попробовать на небольшом кусочке. Но тут нужно и про бизнес-метрики думать — какую пользу приносит эта фича, какой вклад она дает в бизнес, на какую бизнес-метрику влияет? — и про продуктовые: сколько пользователей начало этой фичей пользоваться, есть ли рост MAU/DAU фичи или наоборот отток (попробовали и бросили), что с удовлетворенностью и т.п.

Звучит очень круто — для тех, кто стремится охватить весь процесс целиком, всё контролировать и связывать — от бизнес-целей до технических деталей.

Смежная роль, про которую даже чаще пишут — Feature Lead. Но это заход с другого конца: фича-лид это обычно кто-то из разработчиков, способных и готовых осмыслить бизнес-потребности, метрики, требования и сопровождать команду в разработке фичи. Фича-лиды именно из разработчиков есть, например, в Яндексе (как мы знаем, аналитиков там нет, зато вот) и в 2GIS.

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

Вот на ЛАФе в прошлом году Илья Бравин рассказывал о превращении аналитика в фича-лида (он там, правда, очень быстро переходит от фича-лида дальше к проджект-лиду).

Сложность здесь вот в чём: появляется Accountability, в отличие от простой Responsibility. На русский их обоих переводят как "ответственность". Иногда чтобы отличить первый термин переводят как "Подотчетность" (второй остается "Ответственностью"), мол — у команды есть ответственность, а у фича-лида/оунера ещё и подотчетность. Ты член команды — ты обязался сделать то, что нужно для выполнения задачи и поставки результата. Ты владелец (фичи, продукта, проекта) — ты обязался лично отвечать за результат.

Как пишут на scrum.org:
Ответственность — обязательство выполнить задачу. Ответственность часто заключается в выполнении работы и создании ее результата.
Подотчетность — принятие на себя ответственности за результаты или итог работы. Готовность нести последствия и отвечать за сделанный выбор.
Ну и когда у тебя есть эта самая Accountability — ты не просто отмахиваешься "на моем участке всё сделано, это дальше разработчики всё не так поняли", а идёшь и добиваешься значимого результата. Не всем нужно, не все могут. Но в этом и рост.

Безопасно и точка!

Открываем регистрацию на третий Arch.Meetup by Sber.
Главная тема вечера – ген безопасности в ДНК архитектуры

Вместе со спикерами из Сбера, Positive Technologies и Solar обсудим:

- принципы безопасной архитектуры;
- Zero Trust: от API Security до безопасности AI native ландшафта;
- доверенный ИИ.

29 апреля, 18:30, Офис Сбера (Москва, Кутузовский пр-т, 32)
Регистрируйся по ссылке!  👌

Она же в виде картинки, только телеграм её пережимает до неразличимости, поэтому выше есть pdf.

А за что минусы-то?

Вот эту схему вам ещё, кажется, не показывал. Все области знаний по архитектуре! От сообщества DNA, это какие-то польские ребята, случайно наткнулся.

Люблю обобщающие схемы! Вы уже, наверное, поняли.

Про разбивку, конечно, можно спорить, но давайте посмотрим, что мы тут видим.

Во-первых, 4 области:
* Системы
* Решение
* Инфраструктура
* Приложение

Давайте начнем с решения. Тут у нас 4 раздела:
* Область проблемы
* Визуализация
* Принятие решений
* Область решения

(Опять проблемы с русским языком — не отличаем solution от decision)

Что тут интересно: область проблемы — это сразу DDD, выделение доменов и поддоменов (ядро бизнеса, поддерживающие, общие), и Event Storming. Всё, нету никаких требований и функций, есть только домены. В принципе, для архитектора этого может быть и достаточно — ему же нужно разбить систему на части, так чтобы они не были сцеплены и изменения были изолированы, и на этом всё.

Хороший блок про принятие решений. OODA, надо же. Это нужно подробнее разобрать, надо бы пост отдельный сделать.

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

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

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

Область систем — это в основном про распределенные системы. Тут мне особенно нравится раздел 'Invalid assumptions during system distribution' — ложные представления при проектировании распределенных систем (нулевая задержка передачи, надежные сети, бесконечная пропускная способность, защищенные сети, топология не меняется, есть только один администратор, стоимость передачи данных равна нулю, сеть гомогенна — тут всё прекрасно!)

И 'Reasons for system distribution' — основания для распределения. Почему вы хотите распределенную систему, а не монолит? Это всё совсем не бесплатно. Вы решаете организационную проблему или техническую?

Большой кусок про микросервисы, с перечислением "за" и "против", и раздел про коммуникации, где живут наши интеграции (ну ещё захватывая раздел "шины").

В общем, козырная схема. Даже не знаю, что добавить. Сначала хотел придраться к структуре команд и обратному закону Конвея — но он упомянут в области решений и в микросервисах. Потом — к схемам и контрактам, но про них есть в коммуникациях. Про брокеры сообщений есть в разделе Fire-and-Forget. Вот фитнесс-функции куда-то потерялись, в явном виде не упомянуты.

Разбор всей схемы тянет на хорошую такую учебную программу месяцев на 8. Или на 6 отдельных курсов 😉

Как минимум, можно проверить себя: что из этого я знаю и использовал, о чем знаю только теоретически, и про что не знаю ничего. и составить план по изучению в режиме self paced learning.

Забираем, пользуемся!

Про что ещё хотел вам рассказать: мероприятие, к проектированию которого я лично приложил руку — это весенняя конференция Flow — Flow Spring 2025.

Она будет 26 апреля, в субботу, бесплатно и только онлайн. Так сказать, как разогрев к осенней, которая уже оффлайн и на пару дней.

Вместе с ПК запланировали два трека: смыслы и фейлы.

• Смыслы — о глубоком понимании профессии и про мотивацию.

• Фейлы — честно о провалах. О [не]принятых решениях и их последствиях, о забытых требованиях, о поиске ответов без готовых рецептов. Ошибки, на которых можно научиться.

Набор спикеров шикарный:
Бураков, Бесков, Лобзов, Чернухин, Сатин, Максимов, Безуглый — просто все, кого в любом случае интересно послушать. (Я сам пока коплю силы на осень).

Александра Клименко про коммуникации — у неё был один из самых посещаемых докладов на прошлом Flow с интерактивом, вот тут про него писал.

Полная программа тут

В общем, если вы разогреетесь в пятницу у ребят в Ви.Tech, можно продолжить в субботу на Flow. Целый весенний аналитический уикенд!

Регистрируемся тут

Открытие дня — оказывается, провал коллективного принятия проектировочных решений, то, что называется "Design by Committee" — имеет строгое математическое доказательство и называется "Теорема Эрроу о диктатуре".

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

Универсальность означает, что итоговое решение существует для любых частных выборов участников.

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

Эффективность по Парето — эффективность какого-то показателя системы не может быть улучшена без ухудшения других показателей.

Отсутствие диктатора — ни у кого из голосующих нет права последовательно продавливать своё решение, игнорируя остальные голоса.

И вот математически доказано, что невозможно обеспечить все 4 свойства. Либо у вас вообще не сходится итоговый результат, либо вы забыли какую-то важную фичу, либо ваш проект неоптимальный (неэффективный по Парето), либо у вас есть диктатор.

Теорема работает, начиная с двух голосующих и трёх вариантов выбора. Под выбором имеется в виду упорядочивание без количественной оценки — как приоритеты в бэклоге и карточная сортировка.

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

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

Хуже того: недавно появилась статья https://arxiv.org/abs/2504.06589 (пока в виде препринта), в которой авторы показывают, что задача, сформулированная в теореме Эрроу, эквивалентна проблеме остановки, и, соответственно, не может быть вычислена. Это доказал ещё Гёдель. Точнее, три первых свойства являются невычислимыми без диктатора. То есть, мы принципиально можем их рассчитать только при наличии единственного лица, принимающего итоговое решение.

В общем, у нас теперь есть научное обоснование необходимости единственного человека, управляющего развитием системы (системного аналитика, архитектора) или продукта (продакта).

Всем привет! Хочу напомнить, что уже в эту пятницу в Москве и онлайн пройдет митап от Ви.Tech с офигенным составом спикеров и крутой тусовкой для аналитиков.

Писал о нём вот тут https://t.me/systemswing/707

Кто ещё не зарегистрировался — срочно бегите, отличный план на вечер пятницы!

Организаторы — Ви.Tech, команда инженеров из ВсеИнструменты.ру

📍 Место — Москва, Лесная 9, в одной из высоток на Белой площади.
⏰ Время — 18:30

👉 Регистрация тут

Я обязан промаркировать этот пост, как рекламу, но поверьте — рекомендую от души!

Реклама. ООО "ВИ.ТЕХ"
ИНН 9723147227

Пятничная загадка про управление на основе данных:

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

На этих совещаниях нужно требовать, чтобы каждый работник выступал с определенной критикой, все время подкрепляемой какими-нибудь ссылками. Если он не хочет ссылаться на диаграммы, то пусть он ссылается на собственные расчеты, расчеты цифровые, расчеты фактические. То бичевание, которое прежде было так популярно, когда каждый должен был уязвить, это бичевание должно быть изменено. Нужно в организации создать такую атмосферу, чтобы не было беспредметных обличений и чтобы все было построено на цифрах, на товаре, на определенных расходах.[...]

Техника собраний — доклад с непременными графическими изображениями, критика с фактическими и цифровыми указаниями.

Вопросы: кто автор цитаты и какой это год?

Чур не гуглить!

Upd: Ответ на загадку: это Гастев, "Профессиональные союзы и организация труда", 1924 год (!)

Довольно быстро правильный ответ появился, кстати, продвинутые у нас подписчики!

Вайб-кодинг в ChatGPT — одно удовольствие! Он в последних обновлениях такой человечный стал, можно с ним болтать, как с живым программистом, только без опасений получить в ответ какое-нибудь хамство.

Для одноразовых скриптов — что-нибудь откуда-нибудь вытащить, что-то где-то подправить в пакетном режиме — просто супер.

Вот, например, понадобилось мне переименовать около сотни файлов у себя на Яндекс.Диске по определенному шаблону. Вручную это делать ну совсем неправильно. Смотрим API диска, получаем авторизационный токен, расчехляем python — и вперёд!

Как обычно, после нескольких итераций разнообразных ошибок, всё получилось.

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

Тут на простом примере нужно было понять — какое именно API использовать (WebDAV или HTTP), нужные методы, разницу между POST, PUT и PATCH (в API Диска есть все, и все разное делают), способ авторизации, лимиты, обработку ошибок.

Приложил к посту переписку с ИИ (не всю, самое интересное). Ну правда же он милашка?

Канал уверенно преодолел отметку 9k подписчиков, и это очень круто!

Кто-нибудь другой на моем месте уже создал бы курс по раскрутке телеграм-канала без бюджета (я дважды заплатил за премиум-аккаунт, это пока всё, что я потратил на развитие канала. Ну ещё ЭДО для обмена документами с рекламодателями).

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

— Рассказывать о чем-то новом, про что мало кто говорит. Серьёзно, я вас сильно уважаю, дорогие подписчики, чтобы тупо постить что-нибудь вроде "Основные методы HTTP и какие из них идемпотентны". А если я вдруг про это и напишу, то с какого-нибудь редкого угла рассмотрения — например, должен ли идемпотентный метод всегда возвращать один и тот же результат при одинаковых значениях параметров. Хотя и это слишком просто. Вот связь идемпотентности с функциональным программированием, абстрактными алгебрами и геометрическими проекциями — это уже интересно!

— Давать не просто интересную информацию, но и полезную, применимую сразу.

— Рассказывать максимально просто (но не проще!)

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

Но что мы всё обо мне. У меня же есть традиция (хорошо, когда есть традиции!) — на круглых числах рассказывать о своих подписчиках и их каналах. Вот в прошлый раз у нас были такие каналы:

Аналитик маминой подруги — канал Валентина Заботина. Что беспокоит всех — зарплаты, собеседования, прохождение испытательного срока, инструменты, ну и просто реальная жизнь системного аналитика.

Быть продактом (быть, а не казаться!) — от Антона Куликова, действующего CPO — про научный подход, рациональность и продуктивные конфликты. И про работу CPO, конечно.

V{IT}A ZAEBYMBA | Путь корпората (извините, из названия слова не выкинешь) — канал офигенно развивается, Вита, как ты это делаешь, поделись инсайтами! Вовлеченность подписчиков нереальная. Очень авторский контент про системный анализ и про жизнь ИТшника в большой компании.

IT АНАЛитика (ещё раз извините) Виктора Вильда — много разборов важных для аналитика понятий на простом языке.

https://t.me/systemny_analiz_prosto — к сожалению, на паузе. Был разбор задачек с собеседований.

https://t.me/itsysdes_events — Cобытия для аналитиков и проектировщиков ИТ-систем, новости, статьи.

https://t.me/sysanaly — мемы и наблюдения за жизнью системного аналитика. С интересом прочел отзыв на тренинг, который я вел, а автор канала посетил :)

Eye of the Tigress \🐯/ Системный анализ — живой авторский канал, вдумчивые посты.

Продукт и рост | Яна Доценко — канал от настоящего продакта с настоящими классными приемами и как продакту работать и искать работу в Европе.

https://t.me/mialinist — Заметки об управлении школой @systems_education и исследовательские статьи о финансах, бизнесе и анализе. Самый внутренний внутрячок про школу системного анализа!

Анка Аналитик — длинные посты про системный и бизнес-анализ. Автономный транспорт! Биотех! Крутые предметные области.

Самореализация и публичность IT-специалистов — канал Smart Effect Натальи Семеновой — про подготовку к выступлениям на конференциях.

Финансовый сыч — для разнообразия, канал не про системный анализ, а про финансовый. Автор делится своим личным опытом и ценными советами по управлению финансами и личными инвестициями.

Вот такие у нас классные каналы! Все, как на подбор. Почти готовая папка получилась.
Ну а в комментариях к этому посту можете писать о своих каналах! Даешь переопыление подписчиками!

Яндекс открывает набор в Летнюю школу аналитиков-разработчиков

В этом году впервые можно выбрать направление для углубленного изучения — Data Engineering или Data Science. В течение всего лета вы сможете изучать инструменты анализа данных и научитесь применять их на практике.

Что нужно знать?

- Основы программирования на Python
- Как решать прикладные задачи с использованием любого диалекта SQL или Pandas
- Базу теории вероятностей и математической статистики

Кстати, посмотрите рекомендованные материалы (по ссылке на странице регистрации -> Аналитика). Там хорошее введение в Pyhton, ссылки на курсы по статистике, математике и тренажер по SQL — само по себе полезно.

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

Не откладывайте — регистрация открыта до 27 апреля. Подать заявку можно здесь.

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

И они, конечно, не знают таких методик, как Impact mapping, или её развития — Карты гипотез от Александра Бындю, или Business Decision Records, или какого-нибудь Business Model Canvas/Value Proposition Canvas, или например Digital Policy Model Canvas, если речь идёт о госполитике в некоммерческих областях типа культуры или образования.

Зато они изобрели свой вариант. Это не канва, это просто таблица. Но, мне кажется, она может быть очень полезна для бизнес-аналитиков (в меньшей степени для системных), поэтому приведу её здесь. Вот смотрите, из чего она состоит:

1. Проблема (формулируется как конфликт: с одной стороны это, но с другой стороны вот то, и одно другому противоречит)
2. Данные, подтверждающие наличие проблемы: количественные (мы что-то измерили, это статистически значимо и репрезентативно) и качественные (конкретные вопиющие кейсы)
3. Причины или гипотезы об источниках проблемы
4. Данные, нужные для подтверждения или опровержения гипотез о причинах.
5. Источники данных (для каждой причины)

Это аналитическая часть. Теперь решенческая:

6. Меры по преодолению/устранению причин.
7. Риски
9. Ресурсы для осуществления мер:
— имеющиеся
— необходимые
10. Показатели для оценки:
— процесса (это про меры — что реально делается?)
— результатов (это про проблему — происходят ли улучшение?)
— эффективности (это про соотношение результатов и ресурсов — сколько нам стоит улучшение на N пунктов?)
— эффектов (что ещё улучшается/изменяется в результате? Улучшается ли общая картина, что-то, что выше проблемы? Не выходят ли из под контроля риски? Эффекты могут быть отложенными по времени)

Вот такие две простые таблицы, но, кажется, очень полезные на ранних этапах, для оценки инициатив. Есть ли реально проблема? Откуда знаем? Как будем решать? Как узнаем, что решили?

Дальше добавляем время: сроки реализации мер и периодичность измерений — и получаем готовый план!

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

Вы, наверное, уже читали внутреннюю памятку для сотрудников Shopify про ИИ, которая сначала утекла в сеть, а потом уже и CEO Тоби Лютке у себя в X опубликовал.

Там 6 пунктов:

1. Использование ИИ теперь — фундаментальное ожидание от каждого сотрудника Shopify.

2. ИИ обязательно использовать на стадии прототипирования GSD. Get Shit Done — это у них такая методология и инструмент ведения проектов.

3. Вопросы про использование ИИ включаются в оценку перформанса и взаимного оценивания. В том числе — кто кому помогал осваивать ИИ.

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

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

6. Это относится к каждому сотруднику, включая CEO и высшее руководство.


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

А ещё — хороший пример управленческого воздействия. Всего-то 6 пунктов, а принципы заданы основополагающие. Я похожие принципы пытался внедрить в одном фонде, когда был CTO — но не для ИИ, а для прототипирования продуктов своими силами, без привлечения разработчиков и сбора данных — основатель фонда очень хотел цифровую трансформацию. Но я тогда не дожал, а вот это выглядит как решение (но исходить должно не от CTO, конечно, а от CEO). Предполагаю, кстати, что скоро появится хайп на тему "ИИ-трансформации", какую-нибудь должность "Директор по ИИ" придумают и множество программ на эту тему от бизнес-школ.

А как у вас? Собираетесь вводить в штатное расписание ИИ-агентов?

Я везде стараюсь подмечать идеи, которые могут помочь в работе. Попадаются они в самых разных местах. Например — в Третьяковской галерее, на выставке "Передвижники". К этой выставке выпущен альбом на Ясном языке. Пример текста на слайде.

Я вообще очень внимательно отношусь к текстам и языку. Возможно, вы слышали моё выступление про тексты (преза, статья).
А про проверку сложности языка я писал вот тут.

Ясный язык — это адаптированный национальный язык для людей с ментальными особенностями или другими трудностями восприятия информации. Он подходит для иностранцев, пожилых, или наоборот юных. И знаете, что? Он, кажется, отлично подходит для технических документов и требований.

Не потому, что разработчики и заказчики имеют ментальную инвалидность (хотя иногда закрадываются сомнения). А для снижения когнитивной нагрузки. Разработчики держат в голове структуру из 7-10 последовательно состыкованных модулей/классов и 3-7 уровней абстракции (а то и 10-15). Им есть, о чем подумать. У заказчиков из бизнеса тоже, я вас уверяю. И лишний раз забивать им головы и заставлять продираться через сложные тексты — просто непродуктивно.

Поэтому тексты нужно делать максимально простыми и четкими — без неоднозначностей и запутанных фраз. Ясными.

Ясным языком занимаются банки, операторы сотовой связи и — в некоторых странах — государство (не в РФ). Есть инструкция от Сбера и предварительный стандарт от фонда «Наш Солнечный Мир».

Принципы Ясного языка (про предстандарту):

* использовать ограниченный набор слов естественного языка. Для русского есть списки первых 100 и первых 1000 самых частотных слов, они покрывают 60% всех текстов.
* не заменять существительные на местоимения (он, она, этот, который)
* не использовать синонимы (одно понятие — одно название)
* избегать многозначных слов, или использовать их всегда в одном и том же смысле ("сервер" — компьютер и "сервер" — программа на компьютере)
* использовать слова только в прямом значении (плохо: "поле ввода подсвечивается", "отчет должен отражать информацию")
* избегайте специальных терминов, либо выносите их в словарь
* избегайте жаргона
* используйте одни и те же слова и конструкции, не боясь повторов и тавтологий
* не используйте отрицания
* подавайте информацию порционно: одно предложение — одна фраза
* стройте предложение от известного к новому
* используйте простые предложения
* избегайте причастных и деепричастных оборотов. Разбивайте предложения на несколько.

Практически те же рекомендации содержатся и в руководствах по написанию требований!

Но предстандарт написан лингвистами, поэтому там есть инструкции именно по языку. В частности, приемы упрощения информации:

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

В результате получается что-то в таком духе (перевод юридического документа на Ясный язык):

Статья 26. Банковская тайна
Кредитная организация, Банк России, организация, осуществляющая функции по обязательному страхованию вкладов, гарантируют тайну об операциях, о счетах и вкладах своих клиентов и корреспондентов. Все служащие кредитной организации обязаны хранить тайну об операциях, о счетах и вкладах ее клиентов и корреспондентов, а также об иных сведениях, устанавливаемых кредитной организацией, если это не противоречит федеральному закону.

На Ясном языке:

Что такое банковская тайна?
Вы подписываете разные документы в банке.
В этих документах есть Ваша личная информация.
Личная информация – это:
- Ваше имя,
- Ваш адрес,
- номер Вашего телефона,
- номер Вашего паспорта,
- номер Вашего счета в банке,
- другая информация о Вас.
Банк должен хранить эту информацию о Вас.
Сотрудники банка могут читать эту информацию о Вас.
Банк не должен показывать эту информацию о Вас другим людям.
Банк может показать информацию о Вас полиции.
Банк может показать информацию о Вас налоговой службе.
Чтобы посмотреть информацию о Вас, полиция должна иметь разрешение.

Апрель — самое время для конференций и митапов. События идут почти сплошным потоком, многие прямо одновременно. Но некоторые выделяются особенно!

Ребятам из Ви.Tech (ВсеИнструменты) удалось собрать какой-то феерический состав спикеров, получилась серьезная мини-конференция: и доклады мощные, и движуха, и нетворкинг — обычно на таких мероприятиях действительно получается пообщаться и познакомиться. Был бы я в это время в Москве — обязательно бы пошел.

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

В общем, сам жалею, что в этот раз не попадаю. А вы обязательно сходите! Ну или посмотрите трансляцию, если вы не в Москве.
_____
🗓 25 апреля, 18:30 мск, Пятница
📍Офлайн | 💻 Онлайн

🔧 Инструменты для тех, кто проектирует системы

Поговорим о системном мышлении через архитектурные ката, превращении документации в то, чем реально хочется пользоваться, генеративном ИИ как новом мультитуле аналитика, и JBTD как подходе, который помогает фокусироваться на задачах, а не хотелках.

🎤 В конце ребята из ХАП проведут PowerPoint-караоке,
— команды, случайные слайды и импровизация на максималках.
И конечно же, "база": нетворкинг, закуски

Про инструменты расскажут:
🪛 Глеб Гончаров — придёт с инструментом архитектурных ката
🧲 Денис Бесков — принесёт ИИ-мультитул аналитика
🔩 Дмитрий Безгулый — JBTD-фреймворк для аналитиков и проектировщиков
🛠 Максим Чернухин — раскроет принцип проектирования против легаси
🧰 Дарья Мороз — придёт с UX-набором для документации

Организаторы — Ви.Tech, команда инженеров из ВсеИнструменты.ру
Спецгости и движ — Холиварные аналитические посиделки

→ Тут регистрация.

Реклама. ООО "ВИ.ТЕХ"
ИНН 9723147227

Апрель — самое время для конференций и митапов. События идут почти сплошным потоком, многие прямо одновременно. Но некоторые выделяются особенно!

Ребятам из Ви.Tech (ВсеИнструменты) удалось собрать какой-то феерический состав спикеров, получилась серьезная мини-конференция: и доклады мощные, и движуха, и нетворкинг — обычно на таких мероприятиях действительно получается пообщаться и познакомиться. Был бы я в это время в Москве — обязательно бы пошел.

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

В общем, сам жалею, что в этот раз не попадаю. А вы обязательно сходите! Ну или посмотрите трансляцию, если вы не в Москве.
_____
🗓 25 апреля, 18:30 мск, Пятница
📍Офлайн | 💻 Онлайн

🔧 Инструменты для тех, кто проектирует системы

Поговорим о системном мышлении через архитектурные ката, превращении документации в то, чем реально хочется пользоваться, генеративном ИИ как новом мультитуле аналитика, и JBTD как подходе, который помогает фокусироваться на задачах, а не хотелках.

🎤 В конце ребята из ХАП проведут PowerPoint-караоке,
— команды, случайные слайды и импровизация на максималках.
И конечно же, "база": нетворкинг, закуски

Про инструменты расскажут:
🪛 Глеб Гончаров — придёт с инструментом архитектурных ката
🧲 Денис Бесков — принесёт ИИ-мультитул аналитика
🔩 Дмитрий Безгулый — JBTD-фреймворк для аналитиков и проектировщиков
🛠 Максим Чернухин — раскроет принцип проектирования против легаси
🧰 Дарья Мороз — придёт с UX-набором для документации

Организаторы — Ви.Tech, команда инженеров из ВсеИнструменты.ру
Спецгости и движ — Холиварные аналитические посиделки

→ Тут регистрация.

Реклама. ООО "ВИ.ТЕХ"
ИНН 9723147227

Как работают вызовы API внутри сервера.

Когда рассказывают про интеграции и про API, обычно сервер рисуют как черный ящик. Вот в него входят HTTP-запросы, дальше говорим про URI, параметры, схемы данных.

Но для новичков иногда непонятно, чем отличаются разные технологии. Однажды на тренинге по интеграциям мне задали вопрос: про Кафку мы поняли, её нужно ставить как дополнительное ПО. А вот gRPC — он тоже ставится на отдельный сервер?..

Тут, кажется, стоит вернуться к основам, попробовал нарисовать.

Клиент обращается к серверу (1). Сервер — это компьютер, у него есть сетевая карта (или даже несколько), у карты есть IP-адрес. На него из сети приходит запрос. В запросе указан порт.

Операционная система смотрит по своей таблице портов, в какой из запущенных сервисов отправить этот запрос (2). На одном порту отвечает только один сервис. Всего TCP-портов может быть 65535, то есть один сервер может отвечать по-разному на разных портах. Связь порта и сервиса называется биндинг, приложение при запуске пытается этот биндинг создать и дальше "слушать" порт, то есть ждать из него сообщений.

Стандартные порты — HTTP:80, HTTPS:443. То есть, всё, что приходит на 443, будет отправлено в HTTP-сервер, если он запущен. HTTP-сервер может быть встроен в приложение бекэнда, а может быть отдельным сервисом. Как правило, из соображений безопасности и производительности, в промышленном контуре HTTP-сервер отдельный. HTTP-сервер устанавливает зашифрованное соединение, проверяет корректность запроса и доступы.

Дальше он пытается выполнить запрос. Есть три основных варианта:

— просто отдать файл, лежащий на диске (3.1). Это называется "статика" — обычно это картинки или другие медиа, документы, HTML-страницы, стили, JS-скрипты. Статика отдается очень быстро (зависит от размера, конечно). Структура URL при этом не должна повторять структуру реальных папок на диске — мэппинг настраивается на HTTP-сервере.

— выполнить скрипт, лежащий на диске (3.2). Эта технология называется CGI. Веб-сервер запускает скрипт, и отдает клиенту результат выполнения. Скрипт при этом может обращаться к БД или ещё что-то делать — это обычная программа. Так работают многие PHP-фреймворки. У HTTP-сервера должен быть установлен мод для запуска скриптов на конкретном языке (Perl, PHP и т.д.). На каждый запрос запускается свой отдельный экземпляр скрипта в отельном потоке.

— передать запрос запущенному в памяти сервису (3.3) — приложению бэкенда (в UNIX-подобных системах он ждет запросов тоже по TCP, на каком-нибудь порту. Поэтому легко разнести HTTP-сервер и сервер приложений на разные машины, если понадобится). В сервере приложений в ответ на входящий запрос запускается функция роутинга всех входящих запросов, которая парсит заголовок запроса и вызывает соответствующую функцию (метод) у себя внутри (4). Эта функция уже делает всё, что нужно, чтобы обработать запрос и выдать ответ: обращается к БД (5) или к внешним сервисам (6) — тогда ваш сервер приложений работает частично как шлюз API.

Всё это может работать на одной машине, а когда нагрузка растет — мы разносим их по разным: HTTP-сервер, сервер приложений, СУБД.

Теперь, где работает GraphQL? GraphQL — это замена вашему фреймворку для обработки вызовов на сервере приложений. Есть три варианта: встроить в ваш фреймворк — тогда ваш сервер приложений по одному из эндпоинтов будет отвечать как GraphQL; поставить отдельно в параллель вашему серверу приложений; поставить перед ним, как API-шлюз.

Где gRPC? gRPC работает вместо вашего фреймворка, занимающегося парсингом входящих сообщений. HTTP-сервер, если он есть, будет проксировать TCP-трафик на ваш сервер, где его ловит gRPC и вызывает нужные процедуры.

Если судить по текстам вакансий и публикаций, самая распространенная форма фиксации пользовательских требований сейчас — Jobs To Be Done (в западных компаниях). Другие варианты гораздо реже встречаются.

Напоминаю, идея в том, что пользователь "нанимает" ваш продукт для выполнения определенной работы ("job").

Записывается похоже на User Story, но фокус не на том, кем является пользователь, а в какой ситуации он находится:

Когда <описание ситуации, которая требует выполнения какой-то работы>
Я хочу <описание работы, которая должна быть выполнена>
Чтобы я мог <описание ценного для пользователя результата>

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

Но вот про что нечасто рассказывают — кроме функциональной работы есть ещё эмоциональный и социальный компоненты.

Это добавления формулируются так:

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

Никогда не видел, чтобы эти части появлялись в технических спецификациях.

А между тем одну и ту же функциональность можно сделать такой, что пользователь будет чувствовать себя как оплеванный или такой, что он будет испытывать сплошное удовольствие. Такие продукты есть, мой любимый пример — Superhuman, в котором создатели год вылизывали интерфейс, чтобы добиться максимально быстрой реакции. А это ведь всего лишь почтовый клиент! Miro по этому же пути идёт — поэтому все его клоны, которых так быстро настрогали, плохо выдерживают сравнение — так многого там нет из привычного, такой плохой зачастую UX — именно опыт использования.

Если эмоциональный компонент — это про чувства, социальный — про взаимодействие или про свой образ в глазах других.
Что другие подумают обо мне? Как я хочу, чтобы они думали? (Или как не хочу, тоже мощный мотиватор). Как постоянно говорят в фильмах про мафию: "Подумай, какой сигнал мы подаем этим другим семьям? Все на улице будут считать, что мы ..."
Это и про видимость, и про социальные взаимодействия в продукте (посмотрите Duolingo, это просто живая энциклопедия всевозможных взаимодействий).

Рассмотрение этих двух добавлений сразу отвечает на вопросы, которые не берутся обычными методами CustDev. Во ФРИИ я работал с проектами заочки, туда попадают ребята, которые почему-то не дотягивают до очного акселератора, то есть им чего-то не хватает. Обычно не сформулирована и не подтверждена проблема. И в этом проблема: методика CustDev пытается смотреть на всё, как на проблему, даже боль. Когда у вас возникала эта проблема? Насколько часто она возникает? Как сильно у вас болит, что вы теряете, в деньгах? Пытались ли вы её решать за деньги? Это всё про функциональную работу.

Когда мы берем просветительские проекты (а ко мне такие как и попадали, по профилю — edTech), то жгучая проблема там только одна — ЕГЭ. Ну и ещё пара связанных, типа высоких способностей, которым не отвечает школа, или учебы в условиях постоянных переездов, или других специальных потребностей, но это не массовые истории. Так что болит у подписчиков Арзамаса или покупателей курсов Страдариума? Ничего, это чисто эмоциональная и социальная работа. Зачем туристы таскаются за большие деньги по древним развалинам по жаре, а не лежат у бассейна с коктейлями? Эмоции и социальные эффекты. И тогда всё становится на свои места, и понятно, что именно они покупают.

🚀 Коллеги из Systems.Education 12-13 апреля проведут Третью онлайн-конференцию Systems Design Online, посвящённую проектированию современных информационных систем для бизнеса.

Главная тема конференции в этом году — «Компромиссы проектирования — баланс между атрибутами качества, финансированием и сроками»
🗓 Systems Design Online пройдёт в два дня:
12 апреля (сб) — день докладов
13 апреля (вс) — день мастер-классов и воркшопов

Вас будут ждать:
— Более 20 докладов от опытных архитекторов, аналитиков и технических лидеров
— 3 воркшопа и 2 мастер-класса с акцентом на практику
— 3 тематические секции: Архитектура, Искусственный интеллект и ML и Data Engineering
— Неограниченный доступ к записям всех докладов
— Постоянный чат в Telegram

Каждая из 3 секций раскрывает тему конференции с разных сторон:

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

Секция «Искусственный интеллект и Машинное обучение» освещает современные методы и практики, позволяющие использовать потенциал данных и интеллектуальных систем в бизнесе. Участники узнают, как построить эффективный процесс обработки и анализа данных, какие подходы наиболее результативны, а также как масштабировать и проектировать решения ИИ в условиях растущей нагрузки и разнообразия бизнес-требований.

В фокусе секции «Data Engineering» — комплексные аспекты работы с данными: от сбора и хранения до обработки, анализа и предоставления в удобном виде конечным пользователям и системам. Участники рассмотрят практические вопросы создания надёжных дата-инфраструктур, организации потоков данных (ETL/ELT), обеспечения качества и управления метаданными, а также построения аналитических платформ.

👥 Конференция Systems Design Online будет интересна:
— разработчикам и аналитикам
— архитекторам и руководителям ИТ-проектов

Подробнее о конференции здесь

Следить за новостями конференции можно в Telegram-канале @systems_design_online

#конференция@systems_education

Реклама. ИП Бесков Денис Николаевич.
ИНН 312803354703. erid: 2VtzqvtjJed

Про (не)простые типы данных или что в имени тебе моем?

Вы, наверное, заметили, что я очень люблю стандарты. Ещё я люблю изучать разные стандарты и подходы из разных предметных областей — это тренирует насмотренность и можно подглядеть решения типовых проблем и как с ними справляются. Например, почти у всех есть задачи назначения и контроля полномочий, управления пользователями, какие-то инфраструктурные вещи (синхронизация времени для ведения журналов, например, из PCI DSS).

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

В медицине есть такой стандарт — HL7, Health Level 7, он ещё в 80-х разрабатывался, до XML, в общем, старинная история. Ну и за это время много кейсов в себя вобрал. Я не знаю, насколько он в России сейчас распространен, но официальный перевод существует (ГОСТ Р ИСО/HL7 27931-2015) и некоторые системы точно его поддерживают.

И вот в этом HL7 есть поле для хранения имени пациента. Ну, что тут можно изобрести? ФИО в одну строку или ФИО в трех полях, какие ещё варианты, казалось бы? В HL7 под имя заведено 15 полей. Ну ладно, под расширенное имя. Поля там такие:
XPN.1 Семейное имя. Это сложный тип, у которого в свою очередь следующие поля:
FN.1 Фамилия
FN.2 Префикс собственной фамилии ("де", "фон")
FN.3 Собственная фамилия (девичья фамилия)
FN.4 Префикс фамилии партнера/супруга
FN.5 Фамилия партнера/супруга

Префикс тут выделяется не просто так, а по прагматичным соображениям: он не участвует в сортировке (иначе все "фоны" были бы на "ф").

XPN.2 Личное имя.
XPN.3 Последующие личные имена, отчество, инициалы (через пробел)
XPN.4 Суффикс ("мл." или "III")
XPN.5 Префикс ("д-р")
XPN.6 Ученая степень / сертификат (раньше тут был справочник степеней, типа "MD" или "PHD", по нашему будет "к.т.н."; с версии 2.5 не используется, см. XPN.14)
XPN.7 Код типа имени (ссылка на справочник типов имен, он достоин быть приведенным целиком:
"псевдоним",
"имя при рождении",
"имя при усыновлении",
"для отображения на экране",
"указанное в лицензии",
"юридически признаваемое",
"девичье",
"кличка, прозвище",
"зарегистрированная кличка (для животных)",
"кодированный псевдоним для анонимизации",
"племенное имя",
"религиозное",
"имя новорожденного до получения документов",
"более неиспользуемое, деднейм",
"временное",
"неправильное",
"неизвестное")

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

XPN.8 Код представления имени (это для иероглифических языков: алфавитное, идеографическое, фонетическое)
XPN.9 Контекст использования имени (ссылка на пользовательский справочник; я не нашел примеров, говорят, это актуально для австралийских аборигенов, которые называют себя разными именами в разных больницах)
XPN.10 Период действия имени (с версии 2.5 не используется, заменен на XPN.12 и XPN.13)
XPN.11 Порядок сборки имени (ссылка на справочник со значениями типа "Prefix Family Middle Given Suffix")
XPN.12 Дата начала действия (да, это ещё и темпоральная таблица!)
XPN.13 Срок действия (последняя дата использования)
XPN.14 Профессиональный суффикс (просто строка, используется только для отображения)
XPN.15 Как обращаться (например, по всем документам человек Владимир, а предпочитает, чтобы его звали Дима. Или у священнослужителей — "отец Иоанн").

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

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

Я вообще редко делаю репосты, но иногда контент того стоит. Вот, например, отличные карточки (и док, пройдите по ссылке, скопируйте себе) про именование топиков в Кафке.

Тема типичная для bikeshedding'а (как это по-русски? Долгое обсуждение мелких малозначительных деталей). Нужно один раз договориться, и придерживаться правил.

Вот тут есть ещё парочка вариантов: https://cnr.sh/posts/2017-08-29-how-paint-bike-shed-kafka-topic-naming-conventions/ , https://www.kadeck.com/blog/kafka-topic-naming-conventions-5-recommendations-with-examples , все сходятся на следующих правилах:
1. маленькими буквами, через точку.
2. использовать названия бизнес-доменов, сущностей и событий, а не названия продюсеров, консьюмеров, схем данных и команд разработки (они могут меняться).
3. выделять внешние (public) и внутренние (private) топики

Про номер версии мнения расходятся, некоторые рекомендуют складывать не в название, а в header, ну это как с версионированием в HTTP: хотите ли вы до конца сохранять обратную совместимость, или хотите, чтобы старые клиенты побыстрее отвалились и перешли на новую версию?

А у вас какие правила именования топиков?

Как называть очереди в брокерах

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

Неповторимый, так сказать оригинал вот он: Правила именования топиков

Создавайте правила

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

#брокеры

Ооо, IETF вчера выпустило RFC 9759 Unified Time Scaling for Temporal Coordination Frameworks (https://datatracker.ietf.org/doc/html/rfc9759) — фреймворк для оценивания сроков различных работ. Вот этого нам давно не хватало! Привожу таблицу для округления оценок оттуда. Теперь заживем, все эстимейты будут точнее — есть стандарт!

Сегодня 1 апреля, и IETF традиционно в этот день выпускает шуточные стандарты. Когда-то так появились стандарты на передачу IP-пакетов почтовыми голубями (RFC 1149, RFC 2549) и протокол Hyper Text Coffee Pot Control Protocol (RFC 2324), из которого пришла знаменитая ошибка HTTP 418 I'm a teapot. В 2022 вышел стандарт, запрещающий внесение багов в программный код (RFC 9225), в 2024 — предложения по протоколу FLIP (Faster Than Light Speed Protocol) — предлагающий передавать пакеты быстрее скорости света за счет их предугадывания на стороне приемника при помощи ИИ (RFC 9564).

Российские стандартизаторы тоже склонны к юмору, хотя и более тонкому. Например, у нас есть ГОСТ Р 43.0.21—2020 Информационное обеспечение техники и операторской деятельности. Сознание и самосознание.

Введен он, правда, не 1 апреля, а 1 февраля 2021.

Очень полезный ГОСТ! Цитирую область применения:

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

43 серия ГОСТов вообще вся прекрасна. Кроме сознания и самосознания там стандартизированы такие понятия, как деятельность (ГОСТ 43.0.20—2019), научение (ГОСТ 43.0.24—2021), системность (ГОСТ 43.0.30—2021), а на 2025 по Программе национальной стандартизации запланирована разработка ГОСТов на самоактуализацию и просветление. Номеров у стандартов пока нет, да и саму программу найти не так просто, но есть шифры темы: 1.0.487-1.015.23 и 1.0.487-1.016.23. То есть запланированы они были ещё в 23 году, работы велись в 23-24, к 01.04.2025 должны быть окончательные версии, а через год, в апреле 2026 нужно ждать утверждения.

Всего ГОСТов из этой серии уже 68 (!) штук на текущий момент.

Все они про информационное обеспечение техники и операторской деятельности, то есть это по сути про UI, UX, информационную архитектуру. Правда, внутри они основаны на "ноон-технологии" — это какая-то псевдонаука "нооника", следов которой нигде, кроме этих ГОСТов, не обнаруживается.

Все разработаны неким "Центром НООН-исследований", директором которого является человек, одновременно возглавляющий технический комитет по разработке этих стандартов — ТК 379 Росстандарта, а разрабатываются они за счет бюджетного финансирования. То есть, обычный бизнес — сам утверждает план разработки стандартов, сам же выигрывает конкурсы на их разработку, и так уже больше 20 лет. Вот такой юмор.

Впрочем, зато у нас теперь есть "ГОСТовское" определение системного анализа (из того же ГОСТ 43.0.30—2021):

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

А основная идея системного анализа, сводится, цитирую:

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

Чеканные формулировки! Пользуемся! Всё по ГОСТу!

System Analysis Meetup SberHealth❤️

Когда: 3 апреля в 18:00
Где: Москва офлайн/онлайн трансляция

В программе доклады от ведущих экспертов SH:
🔘Как описывать требования для мобильных приложений
🔘Как создать сообщество для обмена знаниями

⭐️Севостьянова Анастасия,
Ведущий системный аналитик в Альфа-Банке,
расскажет про мидл слой без хаоса: как сделать документацию понятной и живой

Присоединяйтесь, чтобы прокачать свои навыки и задать вопросы экспертам ⭐️

🔜 Узнать подробности и зарегистрироваться

Реклама. ООО "Инновационные сервисы". ИНН 7725317248
erid: 2VtzqwaYcrU

ByteByteGo в рассылке подогнал роадмэп развития архитектора ПО.

Посмотрим, какие есть пересечения с системными аналитиками.

1. Языки. Выучить парочку языков программирования для бэкенда. Java, Python, Go, JS. Ну, тут мимо.

2. Инструменты. GitHub, Jenkins, Jira, ELK, Sonar. Аналитик из этого знает обычно Jira и может быть GitHub. GitHub — это хранение исходников и версий (тут, думаю, в первую очередь имеется в виду сама идея работы с git: все эти пуллы, пуши, коммиты, ветки и PR. Кстати, если хотите разобраться и потренироваться — есть вот такой клёвый симулятор: https://learngitbranching.js.org/). Jenkins — это конструктор пайплана CI/CD, Sonar (видимо, всё же SonarQube) — анализатор качества кода. ELK — это типовое решение для сбора и анализа логов, состоящее из трех open source решений: Elasticsearch, Logstash и Kibana. Logstash собирает и парсит логи и складывает их в БД Elasticsearch, а Kibana строит визуализации. Elasticsearch — NoSQL база данных и поисковый движок. Если у вас есть интеграции, скорее всего, у вас уже развернут ELK. Что интересно, аналитик практически никогда не пишет требования к сбору логов. Оно само как-то.

3. Принципы проектирования: ООП и паттерны ООП (называются GoF — Gang of Four, Банда Четырех, по четырем авторам); TDD — разработка через тестирование; Clean Code; это всё про программирование и конструкции внутри программы, аналитикам наверное не особо нужно. А вот о чем аналитик должен иметь представление: DDD, ACID, MVC, CAP-теорема. Если вы работаете с интеграциями — вам важнее ACID и CAP (а может и PACELC), если с вебом — MVC хотя бы на уровне концепции. Ну а DDD в любом случае.

4. Архитектурные паттерны: слоистая архитектура, микросервисы, публикация/подписка, клиент-сервер, EDA (событийно-ориентированная), гексагональная архитектура. Тут лучше всё изучить, особенно если вы занимаетесь интеграциями. Кроме, разве что, гексагональной архитектуры. Почему вообще гексагональная и MVC в разные разделы попали, я не очень понимаю. И куда дели Clean Architecture. Кажется, в 3 разделе больше про внутреннюю архитектуру, а тут больше про распределенные. Ну да ладно. Про разные виды архитектур в Systems.Education вот даже книгу перевели: https://systems.education/software-architecture-patterns

5. Платформенные знания. Контейнеры, оркестрация, облака, бессерверная архитектура, CDN, шлюзы, распределенные системы, CI/CD. Хотя бы понимать на уровне названий — что это такое, когда и для чего используется. API-шлюзы и оркестрация — это практически про интеграцию, CDN — про веб.

6. Данные и аналитика. Это тоже очень часто попадает в задачи аналитика. SQL, NoSQL, Kafkа — это всё знакомые слова. Data Streaming, OLAP, Object Storage, Data Migration — менее знакомые, но про миграции я регулярно слышу доклады, кажется это тоже попадает к аналитику.

7. Сети и безопасность. Уровень ниже, чем обычно смотрит аналитик, но, опять же, базовые понятия нужно знать, если вы работаете с интеграциями — например, разные виды обеспечения безопасности и аутентификации. А если вам критичная скорость, то можно и в TCP/IP занырнуть.

8. Дополнительные навыки: технологии, принятие решений, управление стейкхолдерами, коммуникация, оценки, лидерство. Тут, кажется, больше половины про аналитика, а то и все.

В целом получается, что системный аналитик — это как будто уже наполовину архитектор. Без знания программирования, без заглядывания в код и без конкретных инфраструктурных инструментов.

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

Есть такой клёвый инструмент — Tech Radar, радар используемых технологий в компании.

Придумали его thoughtworks — компания, в которой, например, работает Мартин Фаулер в классной должности Chief Scientist (я бы тоже таким работал!)

Это такое графическое представление разных технологий, которые использует или к которым присматривается компания. В оригинале он разбит на четыре сектора: техники/подходы, инструменты, платформы, языки/фреймворки. В каждом секторе есть 4 кольца:

Adopt — то, что в компании активно используется и является практически стандартом.
Trial — то, что готово к использованию, даже где-то применяется в исследовательских целях, но в этом мы не так уверены, как в предыдущих технологиях.
Assess — то, к чему мы присматриваемся, но пока даже не проводим исследования
Hold — то, что уже не должно применяться в новых проектах, но может ещё оставаться в легаси

Для крупных компаний с десятками и сотнями команд это хороший ориентир для разработчиков при старте новых проектов — а что у нас есть, на чем делать будем. Так же это и для привлечения специалистов работает — смотрите, какой у нас стек модный! — поэтому многие их публикуют в открытом доступе.

Вот, например, Т-Банк: https://radar.tinkoff.ru/
Мы тут видим в Adopt: OpenAPI, Scrum/Kanban, Feature Toggle, а вот DDD — только в Trial.

Нас интересует, понятно, сектор "Техники", может быть — "Инструменты" (хотя часто их не очень-то различают).

Вот Авито: https://techradar.avito.ru/
Swagger 2.0 — в Adopt, OpenAPI 3.0 — в Assess

МТС: https://mts-digital.ru/technology/techradar/
В Adopt есть Archi(!), а в Hold — Figma(!). Зато в фреймворках есть gRPC.

HH: https://hh.ru/article/techradar

В общем, практически ни у кого ничего по системному анализу! А очень зря, между прочим.
Если у вас хоть сколько-нибудь аналитиков в компании есть — имеет смысл такую карту составить.
Там будут, конечно, только техники, подходы и инструменты, но уже это само по себе полезно.

Что мы сейчас применяем — юзер-стори или юскейсы? А диаграммы мы рисуем где — в draw.io или в plantuml?
И для себя полезно понимать, и новички не будут сомневаться. Такая ситуационная инженерия метода работы на минималках.

У самих thoughtworks на радаре совсем другое, там сплошной ИИ:
В Adopt: RAG, в Trial: Small language models, генерация синтетических данных для тестов, LLM для реверс-инженеринга, вызовы функций из LLM и всякое такое. А ещё — Domain Storytelling! Как облегченная версия Event Storming'a. При этом DDD даже нет на радаре, это у них вообще "фундаментальный подход к созданию ПО". А Event Storming у них вошел в Adopt ещё в 2018 году.

В Assess — тоже сплошной LLM, но ещё, например, GraphQL как инструмент talk-to-data: когда LLM-ка для ответа на вопрос формирует запрос GraphQL, вызывает его, парсит и отвечает по-человечески.

В общем, прямо разительные отличия: в наших-то радарах вообще про ИИ мало. И это октябрь прошлого года! Новый техрадар от thoughtworks выходит буквально сейчас: ещё не опубликован, пока только представлен в вебинарах, буквально позавчера.

Опубликуют — посмотрим, какой там прогресс. Сами они называют ситуацию с LLM "кембрийским взрывом". Кто не запрыгнет — останется вендобионтом 😂

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

А может быть, вы занимали какую-то другую роль, и теперь вам нужно требования писать. Ну и в принципе часто оказывается, что люди не особо понимают, как документы составлять. Для документов, в которых нужно кого-нибудь в чем-нибудь убедить, есть книга "Принцип пирамиды Минто", авторства Барбары Минто.

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

Итак, принципы пирамиды Куприянова:

1. Документ строится от общего к частному (от бизнес-понятий и целей к деталям реализации) и от знакомого к новому (от того, что уже есть, к тому, что будет). Что знакомо вашим заказчикам? Они сами и их задачи. Поэтому в начале приводим цели создания системы — на языке бизнеса, перечисляем роли пользователей и их задачи (они должны себя узнать). Можно привести обобщенную модель бизнес-процесса — на этом уровне без деталей.

2. Где-то через 1-2 страницы от начала документа должна быть БОЛЬШАЯ КАРТИНКА. Книжки без картинок читать скучно. Это должна быть картинка, иллюстрирующая знакомую заказчику обстановку, но с нового ракурса. Типичный пример — контекстная диаграмма. Окружение системы знакомо, роли знакомы, потоки данных знакомы — из нового появляется система, которая это всё объединит. В детали устройства системы вдаваться не нужно, но иногда стоит, если нужно подчеркнуть, насколько она сложная.

3. Общее правило: любая картинка требует текстовой расшифровки. Обычно это таблица, в которой перечислено всё, что изображено на картинке + новые подробности. Для контекстной диаграммы это перечисление ролей, смежных систем, входов и выходов.

4. От контекстной диаграммы легко перейти к требованиям пользователей: хотим, чтобы в систему можно было ввести то-то и то-то, а она нам сама считала/генерировала/обобщала ... и показывала. Тут отлично могут подойти юзер-стори и джоб-стори. Из нового: добавляются тригеры и контекст: когда мы этого хотим? Зачем? Как? (С какими показателями/ограничениями). Скорее всего, мы тут фиксируем то, что нам пользователи ранее рассказали в интервью, и им это должно быть знакомо. Если что, можно предоставить запись, когда именно и кто про это говорил.

5. Добавляем деталей: модель объектов предметной области + их состояния + что с ними можно делать (юскейсы). Пока только названия и цели. Проверка: системы нет, а юскейс имеет смысл (как-то же они сейчас это делают?)

На этом заканчивается описание того, что уже существует в мире — даже если нашей системы нет, это всё равно есть. Есть цели, есть объекты, есть роли, есть юскейсы. Закончили рассказывать про известное. Возможно, что-то из этого известного заказчикам ранее не было известно, или не было систематизировано — мы уже принесли пользу. Сюда же можно добавить ограничения, бизнес-правила и показатели назначения: сколько объектов/пользователей/операций должна поддерживать система, с какой частотой
/интенсивностью/надежностью — это всё тоже объективно следует из потребностей и планов бизнеса.

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

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

Сохраняйте формулировку для сообщения руководителю:

Прошу отпустить меня 26 марта с работы пораньше для участия в митапе Сбера IT Talk для архитекторов. Знания обязуюсь применить в работе.

А также формулировку для сообщения коллегам:

Давайте отпросимся пораньше и поедем в технохаб Сбера — обещают две классные лекции, дискуссию, фуршет и нетворкинг. Огонь!

С сообщениями разобрались, не забудьте зарегистрироваться — встретимся в последнюю среду марта!

📍 26 марта, 18:30, Технохаб Сбера (Санкт-Петербург, Уральская, 1Ч)

Отличный подгон от Андрея Буракова — репозиторий со ссылками на тему интеграций: https://github.com/stn1slv/awesome-integration

Там много ссылок на конкретные продукты для разных кейсов:
API Management
API Design
API Documentation
API Gateway
API Testing
BPM
Data Mapping Solution и т.д.,
а ещё ссылки на разные паттерны, нужно будет тоже собрать каталог с переводом.

Ну и вообще рекомендую канал Андрея Yet Another Analyst — он сам много пишет про интеграции, очень часто провокационные посты, но это взгляд реального практика.

Вот про шины: Страх и ненависть в шиномонтаже

А вот про гарантии доставки: часть 1 и часть 2 (спойлер: это не гарантии доставки, это гарантии обработки!)

Или про разные цели инженера, продакта и предпринимателя (can relate, всё так и есть, это я вам как человек, побывавший во всех трех позициях могу сказать. А при попытке совместить — то ещё расщепление личности начинается).

В общем, держите канал "ещё одного аналитика". А на самом деле — ещё и архитектора, и предпринимателя 👀

В вебинаре про карту интеграций был вопрос про первую версию, которая с кружочками. Точнее, про инструмент, в котором я её визуализировал.

Для системного аналитика задача наверное не совсем типовая — обычно мы не занимаемся визуализацией данных, это больше прерогатива дата-аналитиков или BI. Но вдруг кому-то понадобится. Я вообще когда-то вел занятия по разным цифровым сервисам в магистратуре "Мультимедийная журналистика" НИУ ВШЭ, даже как-то раз был выбран там лучшим преподавателем. Собрал себе библиотечку мультимедийных сервисов — где инфографику можно накидать, где визуализацию данных, где таймлайн, где мультик, где игру, а где проект на карте. Многие сервисы с того времени уже закрылись, а те, что остались — недоступны в РФ.

Но вот этот сервис визуализации — RawGraphs — от Миланского политехнического института ещё существует и доступен.
Там у них в примерах много красоты — она делается дизайнерами уже после выгрузки визуализации в SVG и доведения в графическом редакторе. Получается нарядно: https://www.rawgraphs.io/gallery

В отличие от обычных графиков, доступных, например, в Excel, в этих средах визуализации есть штуки типа sankey diagram (когда что-то перетекает во что-то, можно потоки пользователей так визуализировать, есть есть ветвление), круговые дендрограммы (иерархические структуры с кластерами), или тот же circle packing, который показывает вложенность объектов.

А если вас вообще интересует тема визуализаций, посмотрите вот этот каталог: https://datavizproject.com/

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

🎓29 марта состоится NextConf - онлайн конференция о System Design в реальной жизни.

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

Вас ждет 10 докладов и 3 воркшопа в секциях:

Бизнес и архитектура
Проектируем системы с учетом меняющихся потребностей бизнеса, и узнаем, чем нам будут полезны Event Storming и Domain Driven Design.

Технический дизайн
Выявляем архитектурно значимые НФТ, рассчитываем нагрузку и необходимые ресурсы, декомпозируем систему на (микро)сервисы, выбираем подходящие технологии и паттерны.

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

😎 Кому будет полезна конференция
  • системным и бизнес-аналитикам
  • разработчикам и архитекторам
  • менеджерам продуктов и проектов

🔗 Регистрация тут

erid: 2W5zFHex9cC Реклама. ИП Белянина А.Е. ИНН 701713716662

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

Называется "воронка неопределенности Боэма" (Barry Boehm).

Вообще Барри Боэм первым поднял тему экономической эффективности разработки софта ещё в 1970-х, а в 1981 издал книгу "Экономика программной инженерии" (Software Engineering Economics). Там он и привел эту картинку, а позже уточнил коэффициенты: на стадии идеи ошибка в оценках может быть от -75% до +300%, т.е. от 0.25x до 4x. Это уровень промаха — можно и в 4 раза промахнуться. Ну а когда проект закончен, мы достоверно знаем, сколько он занял, и ошибка равна 0.

Книгу на русский так и не перевели (UPD: перевели в 1985 г.! Назвали "Инженерное проектирование программного обеспечения")

На картинке видны интервенции системных аналитиков (и ещё несколько из разных источников):
— Уточнение определения рамок продукта
— Разработка концепции функционирования (Concept of operation)
— Разработка требований
— Разработка пользовательских интерфейсов
— Разработка детализированных постановок

При хорошей работе они снижают разброс оценок сначала до 2x, а потом и до 0.5x. Достойный результат! (Как правило, сама оценка при этом увеличивается тоже в 1.5-3 раза).

Следующая книга на эту тему написана в 2006 Стивом МакКоннеллом: Software Estimation: Demystifying the Black Art (Оценки разработки ПО: демистификация Темного Искусства). На русском называется скромно "Сколько стоит программный проект" и не так известна, как другие его книги. Никого не интересуют оценки. Всех интересует совершенный код.

У МакКоннелла картина более мрачная: совершенно не факт, что оценка сходится. Может, там не воронка, а облако, и так до конца и неясно, когда же конец.

В общем, если у вас вообще стоит задача оценивать сроки, тут явно нужны аналитики (и можно даже пробовать показывать эту картинку заказчикам аккуратно, продавая "предпроектное обследование"). Но уж если вы согласились на аналитиков, они должны понимать, что именно они должны делать — всеми способами выявлять и раскрывать неопределенность, а то так и останется электронное облако до конца проекта.

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

Вот, например, вопрос про лучшие практики построения админок. На удивление, толковых публикаций на эту тему мало, в основном либо пустые SEO-тексты, либо реклама своих фреймворков/шаблонов. И пишут чаще всего про дизайн, а не про функции.

К хорошим (но очень коротким!) относятся рекомендации от дизайнеров британских правительственных сервисов:
https://designnotes.blog.gov.uk/2015/09/25/design-principles-for-admin-interfaces/ , но это редкость, да и мало там инсайтов.

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

Итак, что я узнал про админки за 25 лет:

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

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

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

— Журналирование всех действий админа (в том числе на просмотр, фильтры и поиск; в том числе — с оповещениями более старшего админа о подозрительных действиях);

— Поиск, фильтры и сортировка (в админке бывают большие объемы данных);

— Серьезные подтверждения для опасных необратимых действий (не кнопка "Да, продожить", а в виде ручного ввода длинной строки текста, "Я понимаю, что я собираюсь удалить бэкап базы данных, и это действие невозможно отменить" или согласия старшего админа);

— Возможность отменить действия. Вообще сохранение истории и возможность просмотра предыдущих состояний (и связей!) объекта.

— "Мягкое удаление" везде, где возможно (если это не противоречит регуляторным требованиям). Следите также за каскадным удалением, оно опасно!

— Функции для пакетных операций! Когда можно выделить несколько элементов и с ними что-то сделать одним действием.

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

— Связки всего со всем и переходы — когда можно легко из одного объекта в другой связанный провалиться, или перейти от общего к деталям (drill down) и вернуться обратно.

— Подсветка тревожных и подозрительных событий (когда они ещё не стали сбоем и проблемой). Например,

— Принцип "один экран — одно действие" в админках не работает. Там наоборот — лучше побольше контекстных действий уместить на экране.

— Ширина экрана и плотность информации. Используйте экран по полной! В админках не очень нужен дизайнерский "воздух", чаще важнее число отображаемых элементов.

— Адрес админки. Должен быть неочевидным! Никаких /admin и тому подобного. Ещё можно ограничить IP-адреса, с которых можно заходить в админку.

Как-то так, что сходу вспомнилось. Если есть ещё идеи, или вы сами с чем-то сталкивались — пишите в комментарии!

— Адрес админки. Должен быть неочевидным! Никаких /admin и тому подобного. Ещё можно ограничить IP-адреса, с которых можно заходить в админку.

Как-то так, что сходу вспомнилось. Если есть ещё идеи, или вы сами с чем-то сталкивались — пишите в комментарии!

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

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

Я не понимаю всех этих разговоров про неопределенность понятия цифровой трансформации. Вероятно, их ведут те, кто ни разу в глаза не видел трансформированной организации. Мне повезло, я видел (я и ускорение поставки софта в 6-10 раз видел, как обещает Сазерленд, мне вообще повезло).

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

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

Конечно, это требует определенной инфраструктуры.

Во-первых, организация должна работать на основе ИТ-системы. Ну без этого никак, к сожалению. Можно установить тонны компьютеров, но если нет единой системы, в которую они объединены - нет носителя деятельности.

Во-вторых, эта ИТ-система должна быть легко модернизируема, расширяема и перестраиваема. Поэтому agile (быстрая поставка), ИИ (программирование без программирования) и открытые системы.

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

Да, есть проблемы - где же нам взять столько программистов, да чтобы они работали не программистами. Это разговоры в пользу бедных. Это примерно соответствует вопросу 100-130-летней давности - а где же нам взять столько грамотных людей. Ну академик Ершов ещё в 1981 сказал, что программирование - это вторая грамотность. Вот. Ищите и нанимайте грамотных людей. Без этого никак.

Всем ли нужна цифровая трансформация? Наверное, нет, издержки довольно высоки. Но тогда и не надо делать вид, что вы её хотите, и в стратегические программы вписывать под видом ЦТ закупку новых компьютеров.

#видеозаписи

Сегодня открываем запись, где первый интересный тезис звучит ещё до начала доклада: «Интроверту полезно обучаться коммуникации, потому что эффективнее общаешься, тем быстрее сможешь закончить разговор перейти к работе».

YouTube | VK Видео

Скачать презентацию с сайта Flow

О, вот это самое крутое выступление за последние несколько лет, которое я слышал на конференциях! Зал был битком, там видно. И ещё это интерактив!

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

В видео даны очень простые (а главное — точно работающие!) техники. Вот только применить их сложно, нужно специально регулярно тренироваться. Шпаргалку что ли себе написать 😂

Я иногда просматриваю программы конференций по инженерии требований, чтобы понять, о чем сейчас говорят, какие темы актуальны.

Их две топовых:
RE (собственно, Requirements Engineering) от IEEE и
REFSQ (Requirements Engineering: Foundation for Software Quality), с участием IREB и Springer.

В 2025 обе проходят в Испании: REFSQ вот сейчас в апреле в Барселоне, RE в сентябре в Валенсии.

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

Программы SE пока нет, а в REFSQ, ожидаемо, чуть ли не треть докладов про ИИ и LLM.

Но удивила меня тема конференции. Фокус, так сказать. Пока мы тут, на WAW например, ИИ выносим на флаг, в западном мире людей совсем другое интересует.

Знаете, что?

Социальная ответственность!
(Social REsponsibility)

Это круто, и я про это тоже часто думаю.

То, что мы делаем, то, какие системы создаем, какие функции в них реализуем — как это влияет на жизнь людей?
Осознаем ли мы это влияние и свою ответственность?

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

А, какая формулировка!

Соответственно, вопросы, которые они выносят на обсуждение:
➡️ Как наше сообщество инженеров по требованиям (читай — системных аналитиков) может внести вклад в «общественное благо»?
➡️ Как поддержать «ответственное проектирование» (Responsible Design) посредством разработки требований?
➡️ Как активно вовлекать общество (крупные/разнородные группы заинтересованных сторон) в разработку требований (например, совместное создание/совместное проектирование)?
➡️ Как систематически извлекать, проектировать и оценивать социальные ценности и воздействия?
➡️ Как согласовать социальные потребности и эволюцию «интеллектуальных» систем?

А вам как кажется, актуальные темы для нашего сообщества? Хотели бы вы их обсудить на какой-нибудь конференции?

36 лет назад в этот день, а может быть в предыдущий, инженер Европейского центра ядерных исследований Тим Бернерс-Ли, занимавшийся высокоскоростной шиной FASTBUS для сбора информации с датчиков микрочастиц и разработкой технологий RPC для неё, представил своему руководителю Майку Сендаллу "Предложение по управлению информацией".

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

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

Примеры типичных вопросов, которые постоянно возникали:
- Где используется этот модуль?
- Кто написал этот код? Где он работает?
- Какие документы есть по этой концепции?
- Какие лаборатории участвуют в этом проекте?
- Какие системы зависят от этого сервиса?
- Какие документы ссылаются на этот?

Предлагалось сделать перелинкованную информационную систему, в которой бы хранилась информация о:
- Людях
- Программных модулях
- Группах людей
- Проектах
- Концепциях
- Документах
- Типах оборудования
- Конкретные экземпляры оборудования

а связи имели бы типы:
- A "зависит от" B
- A "часть" B
- A "сделал" B
- A "ссылается на" B
- A "использует" B
- A "является примером" B
и т.п.

Вся система должна обладать следующими свойствами:
- поддерживать удаленный доступ
- поддерживать разные типы клиентов
- быть децентрализованной
- предоставлять доступ к информации из существующих БД в виде перелинкованных данных
- разделять общедоступные и частные ссылки
- показывать текст (в первой версии)
- иметь встроенные средства анализа данных (разных срезов данных и ссылок, поиск пропусков и т.п.)
- поддерживать "живые" ссылки, данные по которым могут меняться

Это всё должно было помочь хранить актуальную информацию по проектам, быстро извлекать нужные документы и вести учет личных навыков людей (по привязкам людей к проектам, софту и оборудованию, с которым они работали или которое создавали).

По оценкам Тима Бернерса-Ли, первая версия такой системы могла бы быть создана двумя людьми примерно за 6-12 месяцев. Заодно можно было бы попробовать новый способ разработки — объектно-ориентированный.

Майк Сендалл поставил резолюцию "Расплывчато, но любопытно" и дал добро на эксперимент. Они взяли свежий компьютер NeXT Cube, только что выпущенный новой компанией Стива Джобса, которого выгнали из Apple, и через год правда сделали эту систему. Что из этого вышло, вы знаете — мы в эту систему каждый день заходим, посмотреть на котиков.

Ну а у меня вчера тоже был день рождения, буду считать себя астральным близнецом Веба, правда у нас разница в 10 лет 😹

Всех уволят. А аналитиков — нет

По данным Всемирного экономического форума, 41% компаний планируют массовые сокращения к 2030 году, и все из-за ИИ. Искусственный интеллект уже заменяет почтовых служащих, секретарей и даже специалистов по расчету зарплат.

Кого ИИ не заменит? Аналитиков данных. Почему?

• Они понимают контекст: ИИ может обрабатывать цифры, но только человек знает, как связать данные с бизнес-целями.
• Они адаптируются: Аналитик подстраивает подходы под задачи компании, а ИИ работает по шаблону.
• Они контролируют ИИ: Кто будет обучать машины и анализировать результаты их работы? Всё те же аналитики.

За это с 3-4 годами опыта можно претендовать уже на 200 000 рублей и выше.

Как освоить профессию аналитика и укрепить позиции на рынке труда? На курсе «Аналитик PRO» от онлайн-школы Changellenge >> Education.

Что там будет:
✔️ Практика от реальных компаний: за 12 месяцев вы решите кейсы от Tinkoff, OZON и других крупных брендов;
✔️ Ключевые инструменты: Excel, Python, SQL, BI-системы, финмодели и все то, что указывают в списках работодатели;
✔️ Карьерная поддержка: помощь с резюме, подготовка к собеседованиям и консультации по развитию;
✔️ Готовое портфолио: ваши кейсы впечатлят эйчаров и помогут выделиться среди кандидатов.

Результаты курса:
83% студентов находят работу в течение первых месяцев, а многие переходят в аналитику еще во время учебы. Выпускники работают в Яндекс, VK, Газпроме, Mars и других лидирующих компаниях.

Уже скоро стартует новый поток. Успейте получить дополнительную скидку 25 000 руб. на курс "Аналитик PRO"  по промокоду SWING25 до 17 марта.

👉🏻Оставить заявку на консультацию по программе.

erid: 2Vtzqx6jBEo. Реклама. ООО «ВЫСШАЯ ШКОЛА АНАЛИТИКИ И СТРАТЕГИИ». ИНН 7716917009

Про математику в системном анализе и проектировании.

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

Рассмотрим такую задачу: мы проектируем интеграцию или API бэкенда, и хотим оценить пиковую нагрузку. Допустим, у нас есть 1000 пользователей, и сценарий их работы такой, что каждый из них за час делает примерно 10 запросов к системе в случайное время. Какой RPS (число запросов в секунду) должен выдерживать сервер?

Если просто 1000*10/(60*60) — число пользователей на число операций деленое на число секунд в одном часе — получится 2.78 запросов/сек.

Но, очевидно, запросы от разных пользователей могут совпадать по времени. Для моделирования такой ситуации нужно использовать пуассоновский процесс, а точнее — распределение Пуассона.

Оно задается жутковатой формулой вероятности:

P(k)=λˆk*eˆ-λ/k!

(да, лямбда в степени k, умноженное на e в степени -λ, деленое на k факториал),

где λ — среднее количество событий за промежуток времени, k — интересующее нас количество событий, P(k) — вероятность того, что k событий произойдут в одну секунду.

В нашем примере λ = 2.78, а k можно разные подставлять:
P(5) = 0.086
P(6) = 0.04
P(7) = 0.016

Для нашего количества событий (10000) эти вероятности очень велики, например, RPS=7 у нас будет 57 раз за час!

А вот P(13) = 0.00001, то есть 1 раз в час. Значит, можно рассчитывать на RPS=13.

Формулу Пуассона можно использовать только для случайных обращений! Если у вас процесс устроен как-то регулярно — нужно использовать анализ сценариев. Например, когда все побежали в сервис после получения оповещения. Или когда в конце часа/дня обязательно нужно что-то сделать (отметиться, отправить коммит), или например все побежали сдавать домашку за 5 минут до дедлайна — тогда процесс не случайный, и нужно анализировать именно эти пики.

Ну а вероятности по формуле Пуассона можно посчитать в одном из калькуляторов, например: https://stattrek.com/online-calculator/poisson (здесь x это k, а λ названа μ), или в Экселе через функцию POISSON.

Применяйте инженерные методы в системном анализе!

Или вот хардкорный пост.

В языках С и С++ есть такой тип данных — указатель. Это тип переменной, которая хранит типизированный адрес — ссылку на какое-то место в памяти, где _на самом_ деле находится значение. Например, int* хранит ссылку на какую-то область памяти, содержимое которой программа интерпретирует как целое число. Бывают ситуации посложнее — указатели на экземпляры классов или указатели на функции. В C и C++ указатели используются повсеместно, есть специальная арифметика указателей, и с ними же связаны основные ошибки времени исполнения, эксплойты и утечки памяти.

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

Долгое время считалось, что указатели как концепт придумал в 1964 Гарольд "Бад" Лоусон (у нас известен как автор книги "Путешествие по системному ландшафту" — введения в системную инженерию).

На самом деле, первой идею указателя придумала советская и украинская программистка Катерина Ющенко: ещё в 1955 году она создала "Адресный язык программирования" — один из самых первых языков высокого уровня. В Фортране и Алголе 60 ничего похожего не было. Язык был известен только в СССР, поэтому Лоусон "переизобрел" указатели для PL/I.

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

И вот что я хочу сказать, и говорю каждый год (2024, 2023) — вклад женщин в нашу индустрию неоценим! Без вас никакого ИТ бы не было, вот что! Самые крутые штуки — первые программы вообще, компиляторы, указатели, оболочку командной строки, электронные почтовые ящики, технологии сетевого роутинга, DNS и так далее. Всё это очень хардкорные вещи, и глупо считать, что в нашей профессии может быть какая-то разница по гендерному признаку. Кстати, среди бизнес- и системных аналитиков дисбаланс минимален, судя по аудитории конференций и тренингов.

В общем, спасибо вам за всё, и с праздником равноправия! Ну и весны, конечно. 💐🌸🌷

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

Поэтому ловите комикс про Agile: https://www.comicagile.net/ (с подзаголовком "когда agile сталкивается с реальностью").

Перевел несколько стрипов специально для вас!

Как разобраться с JSON?

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

Если вы можете представить свои данные в таблице — в JSON их перенести просто: названия колонок становятся ключами, а значения полей — значениями в JSON. Была таблица с полями 'Id', 'Name', 'Surname', 'BirthDate', стал JSON:
{ "id": 12345,
"name": "Константин",
"surname": "Константинопольский",
"birthdate": "1990-04-14"
}
Это для одной строки. Несколько строк превращаются в массив объектов. Записи из подчиненных таблиц становятся вложенными объектами или массивами. В целом, это выглядит как преобразование таблицы в набор вертикальных списков.

Но всё становится сложнее, если мы берём несколько связанных таблиц. Часто просят уточнить: ведь структуры данных, которые мы передаём в API, не должны 1:1 соответствовать структуре БД? Правильный ответ — конечно нет, ведь мы можем задавать к этим данным разные вопросы! API — даже если это просто get — это про вопрос, который мы задаем серверу и на который получаем ответ.

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

К этим данным мы можем задавать разные вопросы:
— дай информацию по одному студенту;
— дай список студентов;
— дай список всех курсов;
— дай список студентов, записанных на определенный курс;
— на какие курсы записаны студенты из одной группы и т.д.

Для каждого ответа может быть свой JSON, за какую ниточку потянем — то и вытянем. Про что спрашиваем, что будет корнем? Идём от студентов, от их записей на курсы, или от самих курсов. Структура JSON в разных ответах будет разной.

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

Например, HATEOAS. HATEOAS — Hypermedia As The Engine Of Application State — без которого REST не настоящий. В случае HATEOAS ответ должен содержать ссылки на связанные понятия, и размер JSON растет.

Тут есть несколько соглашений — как именно эти ссылки передавать. На карточке показан один из вариантов.

Есть несколько попыток привести элементы HATEOAS к единой структуре:
🔸HAL (Hypertext application language, c 2016 существует в виде драфта стандарта, но некоторыми используется);
🔹HAL-FORMS от Майка Амундсена, добавляющий "шаблоны" — в каждом ответе мы будем получать кроме ссылок ещё и полную модель переходов между состояниями, ссылки для переходов и даже схемы ответов;
🔸JSON-LD (JSON Linked Data, JSON для связанных данных);
🔹JSON:API — наверное, самый навороченный формат, включающий в себя данные, связанные ссылки, встроенные данные связанных объектов, пагинацию, метаданные и массив ошибок.

Эти форматы — не такая уж экзотика. HAL-FORMS поддерживает популярный java-фреймворк Spring. Ссылки в формате HAL возвращает API Яндекс.Диска. JSON:API встроен в ядро CMS Drupal.

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

Больше видео хороших и разных про ИИ!

Я стараюсь мониторить широкую картину в части ИИ — а что в мире вообще происходит, где есть реальные прорывы, куда идут деньги и как устроены бизнес-модели. Вот тут отличное видео от MTS StartUp Hub — они вообще активно развивают стартапную тему, ну а какой сейчас стартап без ИИ.

Что я для себя использую как критерий адекватности: отсутствие разговоров, как ИИ всё перевернёт и на сколько десятков процентов увеличит мировой ВВП. Если реально на вещи смотреть — пока радикальных изменений не наблюдается. И вот у ребят из MTS StartUp Hub звучат оценки 1.1—1.8% — значит, можно дальше слушать 😏

Обратите внимание — в середине видео мелькает слайд от Tracxn со стартапами и бизнес-моделями, он свежий, от января 2025, что тоже интересно.

ИИ-инструменты разработки и создания ПО там среди уже подтвержденных бизнес-моделей, а меня это интересует лично, есть у меня замысел усиления системных аналитиков и проектировщиков софта при помощи ИИ (с применением методик, которым я учу 😎 ), поэтому тут внимательно смотрю на решения и инвестиции. С ними же связано управление знаниями об архитектуре и проектах, и интеллектуальном ИИ-поиске по этим базам. Тут тоже есть инвестиции, значит — верное направление.

В общем, за какие-то 17 минут клёвый срез актуальной ситуации, полезно. Ну и основные мысли на карточках.

Очень много событий, совсем забыл написать про Analyst Marathon, а там было, что посмотреть.

Небольшой обзор, что успел посмотреть:

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

Руслан Сафин "Принцип каскадного снижения связанности"
Руслан так же глубоко разбирает темы связанности и сцепленности (coupling and cohesion). И показывает на примере разбивку системы -- уменьшение связности. Кстати, впервые услышал перевод cohesion как "прочности". Кажется, это должно быть связано с робастностью, нужно подумать эту мысль. Ну и когда тепреь слышу про coupling, не могу выбросить из головы фразу Роя Филдинга: "в архитектуре системы было так много связей, что на диаграмму нужно ставить пометку 18+".

Алексей Краснов "Использование Abuse cases и Attacker stories для анализа требований по безопасности"
Очень интересная мысль в докладе -- как аналитику понять безопасность. Напишите юскейсы злоумышленника! Как настоящие, с целями и успешными результатами, только вредные для системы. Очень крутая идея, и понятная. Потом, конечно, можно ввести требования, которые рушат все вредные юскейсы и на допускают их успешного окончания. Очень практичные требования к безопасности, не какая-то абстракция.

Валерий Разномазов, "Математический аппарат для системного и бизнес-анализа". Многообещающее название, но внутри очень спорный. Я сам топлю за использование математических методов и моделей в системном анализе, по пока мало что могу предложить. Ждал инсайтов, но тут не совсем та математика, которую я ожидал. В основном здесь про теорию множеств, графы и матрицы. Кажется, это лично моя проблема, потому что множества и операции с ними, графы и матрицы у меня настолько вросли в базовую картину мира, что я их уже не воспринимаю, как что-то особенное. Это просто повседневный язык мышления. Если у вас не было этого в школе или в институте -- посмотрите доклад, это база.

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

Ну и доклад Николая Лебедева просто огненный, с разными кейсами применения ИИ -- особенно любопытно, как сразу в процессе созвона по ключевым словам ИИ автоматически ставит таски -- это какая-то фантастика.

В общем, очень интересный набор докладов, рекомендую. Если вы конференцию пропустили, у Analyst Marathon записи прошедших конференций есть (за деньги), ссылка та же.

⚡⚡⚡⚡ Готовьтесь к тотальному апгрейду…

Хотите расти и развивать проект? Вы по адресу! Специально для вас мы создали уникальный курс «Микросервисная архитектура»!

Что это такое? Это не просто обучение, а полноценный курс по проектированию распределенных систем, где вы сами выполните задание по проектированию системы "Интернет-магазин с собственным производством", что станет отличным проектом для вашего портфолио.

Что вы освоите? ✅ Декомпозицию системы отталкиваясь от бизнес-домена ✅ Определение оптимальных границ и размеров микросервисов
✅ Методологию Event Storming ✅ Эффективные способы интеграции
✅ Более 20 паттернов микросервисной архитектуры ✅ Более 15 антипаттернов микросервисной архитектуры

Полная программа курса здесь 👉https://microarch.ru/courses/microservices?utm_source=posev&utm_medium=erid:2Vtzqx7gFqQ&utm_campaign=6

📈 Какой итог? Сертификат об участии по итогам прохождения курса. А самое главное — реальные знания, которые помогут строить гибкие системы, которые легко поддерживать и адаптировать под задачи бизнеса.

Также:
— Проверка домашних заданий
— Поддержка в чате
— Живые разборы
— Ответы на все вопросы

🏆 Уже занята половина мест на курсе. Если хотите избавиться от монолита и вырасти, как спец, то самое время записаться к нам.

Повысить грейд в 2025 году »> https://microarch.ru/courses/microservices?utm_source=posev&utm_medium=erid:2Vtzqx7gFqQ&utm_campaign=6

Реклама. ИП Ветчинкин К.Е. ИНН: 773376451099 Erid: 2Vtzqx7gFqQ

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

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

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

Но вообще задача на 100% для ML! Нужно взять разные параметры проектов и их реальные сроки. Закинуть в нейросетку, тут даже никакая LLM не нужна, RNN вполне справится — и пусть учится! У нейросетки предсказания должны лучше получаться, потому что не будет человеческих искажений "а что, если мы объявим реальный срок, а менеджер разозлится и начнет нас продавливать?". Тут бесчувственный компьютер — хоть ругай его, хоть не ругай.

LLM может понадобиться, если вы хотите какие-то параметры вытаскивать из текста, например ТЗ. Тут он может помочь, но я бы использовал его хитро — например, сначала попросил вытащить разные параметры — что-нибудь вроде числа функциональных точек.

Неплохо упомянуть конкретные методики: COCOMO, FiSMA, Nesma, AFP — ну, во что вы верите 🤷‍♂️

Хорошо обученный LLM вытащит из своих глубин знания о конкретном методе, прикинет из общих соображений сроки, и вы получите конкретный результат. При включенных рассуждениях можно даже посмотреть, как она "думает". Вот, например, на карточках видно, как рассуждает DeepSeek.

В целом, не сильно отличается от человека, вот что.

Ну а людей такими запросами мучать не нужно, максимум — согласовать с ними оценку. На предмет увеличения :)
И никаких стандартов и взаимных претензий.

Ну а если хотите поиграться, вот несколько статей про оценку сроков нейросетями, просто для примера:

На RNN:
[1] https://www.researchgate.net/publication/321102199_Recurrent_Neural_Network_based_Prediction_of_Software_Effort
[2] https://www.mdpi.com/2073-431X/13/12/335

На LLM:
[3] https://arxiv.org/abs/2402.07158
[4] https://arxiv.org/html/2409.09617v1

По запросу 'RNN software effort estimation' много статей гуглится.

UPD: DeepSeek анализировал концепт системы по планированию и оформлению путешествий. Его первоначальная оценка:
Для системы средней сложности с базовым функционалом: 8-12 месяцев. При наличии готовых модулей (например, аутентификации) срок может сократиться до 6-9 месяцев.
После уточнения вводных накинул ещё 30%:
Этап Длительность Комментарий
Проектирование 5-8 недель Учёт новых интеграций (визы, календари)
Бэкенд-разработка 6-9 месяцев Особое внимание интеграциям с высокорисковыми системами
Фронтенд 4-6 месяцев Сложные интерфейсы для конструктора маршрутов и планировщика
Тестирование 10-12 недель Проверка сценариев мультивалютных операций и модерации

Общий срок: 12-16 месяцев
(увеличение на 30-40% к первоначальной оценке)

На WAW был очень жаркий круглый стол, "Стандарты в процессах разработки в эпоху ИИ".

Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)

Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.

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

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

Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.

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

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

И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.

Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.

Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?

Второй по счету WAW — Зимний аналитический уикенд — прошел. Я, честно говоря, очень переживал — такую высокую планку с точки зрения атмосферы и нетворкинга задал первый WAW. Когда в любое время проходишь по лобби отеля, и видишь, что везде тут и там сидят группками люди и общаются — это кайф! 💖 То есть, в основном же все на докладах и мастер-классах, но всегда кто-то активно тусит в кулуарах — огонь! 🔥 Кажется, это то, чего хотят все организаторы всех конференций.

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

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

Ну и отзывы. Отзывы всегда приятно читать — значит, все нервы и споры в ПК, все горящие дедлайны и общение со спикерами (не всегда простое) — всё было не зря!

Теперь нужно в третий раз затащить, и это будет уже точно не случайность, а закономерность!

Как джуну в системном анализе использовать ИИ и не спалиться? 🔵

Поделился Юрий Куприянов - независимый эксперт и консультант в области системного анализа и архитектуры, ведущий тренер школы Systems.Education, автор канала "Системный сдвиг", программный директор конференции Winter Analytical Weekend.

Юрий больше 25 лет проектирует и создает программные системы в разных ролях — разработчика, аналитика, архитектора и продакта. Создавал системы для крупнейших банков и в области образования (EdTech).

Постоянный докладчик на конференциях по системному анализу, автор лучших докладов на Analyst Days, ЛАФ и Flow.

⏩Он также первым в России использовал ИИ для работы системных аналитиков и рассказал об этом на Хабре :)

▶️ Продолжает развивать эту тему в своем канале, где публикует также полезные материалы для аналитиков по проектированию интеграций и разработке требований.

Подписывайтесь, если хотите узнавать больше

На канале Solvery поделился небольшой инструкцией по написанию документов требований с помощью ИИ.

В двух словах: не стоит ждать, что ИИ напишет сходу всё ТЗ или PRD. То есть, он конечно напишет, но результат может быть не совсем целостным. Поэтому нужно, во-первых, действовать последовательно — идти от верхнеуровнего описания или модели к деталям. Я начинаю с выявления ролей пользователей, основных юскейсов и контекстной диаграммы. Потом прошу выявить объекты и составить модель данных. А потом уже можно требования и интерфейсы описывать (всё — отдельными запросами).

Во-вторых, нужно проверить полноту документа через связи. Мы описываем одну систему с разных точек зрения, так ничего не должно "провисать" -- все части описания со всеми связаны. Это тоже может проверить ИИ.

В общем, смотрите карточки!

У ребят из Solvery на канале вообще интересный формат — многие эксперты делятся своим опытом. В основном про поиск работы и вход в ИТ — в разные профессии, не только в СА. Но есть и посты конкретно про аналитиков:
👉прохождение собеса на аналитика в Т-банк
👉подкаст про то, как джунам выжить на перегретом рынке IT
👉и как упаковать профессиональный опыт, чтобы стартовать в системном анализе

Сегодня на WAW. Конфа проходит на 5, а у меня лапки.