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

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

Вот из недавнего: чуть ли не в каждой статье про важность soft-skills (особенно от HR-ов или edTech-ов) встречается фраза, причём дословно:
"Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%."

Её, кажется, первым запустил РБК, а потом все стали друг у друга перепечатывать.

Интересно, что такое исследование действительно существует! Но есть нюанс — это исследование 1918 года! Не опечатка — 1918, более 100 лет назад. В исследовании американским инженерам задавали вопрос: что им больше всего помогает при выполнении проектов? И они отвечали, что твердость характера. Такой вот софт-скилл. Другие упоминаемые качества: ясность суждений, производительность, понимание людей и широта знаний. Такой набор, а не то, что сейчас под софт-скиллами понимается — типа, быть милым, эмпатичным и поддерживать нетворкинг.

То есть, с одной стороны, любопытно, что исследования эти ведутся ещё с XIX века (в том журнале есть ссылки и на исследования 1880-х годов), но неужели нет более свежих работ? И правда ли мы сейчас собираемся опираться на опыт американских инженеров времён Первой мировой? Впрочем, качества-то перечислены полезные.

Немного об интеграциях:

— У нас на проекте Кафка.
— Для маршрутизации сообщений?
— ...
— Для маршрутизации сообщений, верно ведь?..

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

🔥 Подборка материалов от телеграм-канала Системный Аналитик

📚 20 лучших книг для развития аналитика — можно скачать бесплатно

📨 Брокеры сообщений: Kafka и RabbitMQ, сравнение Kafka vs Rabbit

🏭 PlantUML с нуля

📌 Подброка бесплатных материалов базам данных и SQL

▶️ Подборка бесплатных вебинаров по основам интеграции систем

📎 Подборка материалов по изучению REST

🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений

🌐 HTTP. Что нужно знать аналитику

⚙️ Интеграция через API. Кратко

🤓 Задачник для системных аналитиков от Тинькофф

🧿 Виртуализация, контейнеризация и оркестрация

💪 Карта навыков системного аналитика

🧮 Про нефункциональные требования

🆚 Сравнение REST vs SOAP, gRPC vs REST, GraphQL vs REST

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

И уже есть запись: https://www.youtube.com/live/uRQuVT1xxMY?si=Xfnojsa0GGl05kHx

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

А потом, с 2:18:50 — наш круглый стол.

Сформулировал в одной дискуссии положения про метрики API:

1⃣ Есть три уровня метрик: инфраструктурные (что с железом и каналами) , прикладные (что с запросами и ответами, токенами и т.д)
и продуктовые/бизнесовые (что с качеством данных, бизнес-процессами, клиентами).

2⃣ С точки зрения измерений, что меряем:
- производительность/ресурсы (CPU/память/IO/сеть), RPS;
- скорость/задержки (latency: среднее, максимальное, 95 перцентиль, 99 перцентиль),
- число ошибок (4xx, 5xx);
- консистентность ответов (соответствие структуры, полнота, отсутствие дублей, соответствие размера/распределения ответа ожидаемому).

Если есть кеш — число попаданий/промахов.
Если есть требования к безопасности — число [неудачных] попыток авторизации, ошибки шифрования, ошибки сертификата, число выданных токенов;
Если есть есть требования по гарантированной доставке — число перепосылок, счетчики успешных/неуспешных перепосылок.

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

Вот неплохая статья про метрики открытого API: https://www.moesif.com/blog/technical/api-metrics/API-Metrics-That-Every-Platform-Team-Should-be-Tracking/

А вот ещё одна, более техническая: https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring (не смотрите, что про Azure, там метрики универсальные).

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

Делюсь с вами алгоритмом, по которому я обычно думаю, когда сталкиваюсь с интеграциями:

1. Анализ бизнес-потребности. Зачем нам интеграция? Какие бизнес-процессы или юскейсы она будет поддерживать?
2. Какие системы участвуют в интеграции? В каких системах есть данные, и в каких системах они в результате интеграции должны оказаться?
3. Детализированные функциональные требования: какая система в какой ситуации должна показать или использовать данные из другой системы; сделать запрос; передать данные по своей инициативе. Тут мы предварительно можем прикинуть, ну или хотя бы обсудить: кто является инициатором обмена? Синхронный или асинхронный обмен? Какой стиль интеграции мы можем использовать? (Передача файлов, общую БД, синхронные вызовы/веб-хуки/сокеты, асинхронный обмен через промежуточную среду/очередь). Какой паттерн управления обменом используем: оркестрацию или хореографию?
4. Регламент обмена данными в виде таблицы: | система источник | система приёмник | расписание или событие, по которому стартует передача | что именно передается: один объект, набор объектов, по какому признаку отфильтрованы? Какие поля объектов: все; явно перечисленные; только изменившиеся?.. Нужна ли агрегация или расчеты? | — это стараемся писать точки зрения бизнеса.
5. Количественные показатели интеграции: ожидаемая интенсивность (частота передач), ожидаемый объем (одной порции данных), это разовая передача или потоковая, перспективы роста интенсивности и объемов, число систем-клиентов - тут мы пытаемся понять, есть у нас где-то хайлоад, или всё так просто. Если какой-то показатель вылезает за миллионы или тысячи/сек., то дальше уже всё проектируем гораздо аккуратнее. Результат можно зафиксировать в виде НФТ или показателей качества, добавив требования к доступности, настраиваемости и безопасности.
6. Детальная спецификация данных. Тут нужно выявить — в каких системах в каком виде данные лежат, кто является мастер-источником для каких данных, что именно нужно передавать, какие использовать идентификаторы(!), откуда берем и как синхронизируем справочники.
7. Преобразования и мэппинги. Поняв структуры данных, описываем их преобразования и как они друг на друга маппируются. (Часто всё проектирование интеграций только к этому пункту сводится, а остальные аспекты игнорируются и реализуются как придётся, без анализа).
8. Способы взаимодействия: синхронное/асинхронное, прямое/через промежуточную очередь, оркестрация/хореография, что вообще интегрируемые системы могут, а то может там только файловый обмен возможен. Как обеспечиваем требования безопасности, нужно ли шифрование/хэширование/маскирование/обезличивание, как устроена аутентификация и проверка полномочий.
9. Детальный сценарий обмена (диаграмма последовательности + текстовый сценарий).
10. Общие требования к обработке ошибок, журналированию, мониторингу. Где-то тут, когда начинаем думать про ошибки, возникают вопросы про гарантию доставки, идемпотентность и хранение переданных ранее данных. По обработке ошибок по сути у нас два решения: а) система, обнаружившая ошибку (кстати, кто может обнаружить ошибку?), пытается её исправить; б) система оповещает людей, которые уже сами пытаются решить проблему. Эти решения не взаимоисключающие. Кроме того, нужно зафиксировать ошибку в журнале (в каком? что именно записать? и т.п.).
11. Выбираем уже окончательно стиль интеграции и конкретную технологию или решение.
12. Проходим пункты 7-10 ещё раз, фиксируя конкретные и детальные решения, связанные с выбранной технологией. Дальше уже проект интеграции дробится на требования к каждой отдельной системе, участвующей в интеграции.

Вот, кстати, отличная статья Анны Овзяк про проектирование интеграций: https://habr.com/ru/companies/alfa/articles/770184/

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

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

И вот какая там мысль проскочила (в связи с ИИ, куда же без него): формула образования — KSA, knowledge-skills-attitudes, знания-навыки-отношение (чувства, эмоции, убеждения, ценности). Причем attitude — это не soft-skills, это вообще не skills. Это то, что мотивирует человека применять тот или иной skill. (Поэтому я не очень люблю разговоры про софт-скиллы, они замещают разговор о ценностях и выборе поведения). Я про эту тройку уже как-то писал в канале — какие качества нужны аналитику.

Так вот в связи с ИИ высказывалось предположение, что знания человек может получить опосредовано — например, из книг или видео. Навык может быт натренирован частым повторением (тут дело быстрее идёт, когда тебя корректируют, но корректировать необязательно должен человек — если вам знакома зелёная сова, то она отлично с этим справляется при изучении языков), а вот сформировать ценности и убеждения в нас могут только другие люди: родители, друзья, среда, наставники в профессии. И вот эту среду ни ИИ, ни цифровые технологии нам организовать пока не могут. Поэтому цифровое обучение вполне эффективно при формировании knowledge и skills и почти не способно сформировать attitudes (т.к. не образует среды и образца поведения).

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

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

Давно не писал про ChatGPT. Но и новостей особо нет, работает привычно-штатно. Бросить в него алгоритм взаимодействия, построить диаграмму последовательности — уже на автомате. Кстати, он теперь сам начал подсказывать, куда её вставить (почему-то рекомендует PlantText.com)

Из нового: попробовал составлять руководство пользователя. Отлично получается.
Что можно делать:
➡️ преобразовывать в ГОСТовскую структуру неформальное описание (например, разработчик, как смог, описал; или из требований сделать руководство).
➡️ составлять руководство на основе кода или скриншотов(!) — а вот это новое, правда, доступно только в 4 версии.

Запрос:

Я создал интернет-сайт на тему <...>. На сайте размещены статьи по разным аспектам этой темы, пользователи могут регистрироваться, проходить опросы и добавлять комментарии под статьями.

Мне нужно составить руководство модератора по следующей структуре:
1 Введение
1.1 Область применения
1.2 Краткое описание возможностей
1.3 Уровень подготовки пользователя
1.4 Перечень эксплуатационной документации
2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
2.1 Виды деятельности, функции
2.2 Программные и аппаратные требования к системе
3 ПОДГОТОВКА К РАБОТЕ
3.1 Запуск системы
4 ОПИСАНИЕ ВЫПОЛНЕНИЯ ОТДЕЛЬНЫХ ОПЕРАЦИЙ
4.1. Наименование операции
4.2 Условия выполнения операции
4.3 Подготовительные действия
4.4 Основные действия
5 АВАРИЙНЫЕ СИТУАЦИИ

Ответь мне на это сообщение словом "Понял". В следующем сообщении я дам тебе неформальное описание функций модератора (или: описание требований к функциям модератора) - приведи их к указанной выше структуре.

Генерация руководства по коду страницы:

На странице сайта есть комментарии. Вот код страницы с комментариями: <html-код, сколько влезет в промпт>
Напиши инструкцию модератора для работы с комментариями.

Результат:

4.4.9. Управление комментариями

4.4.9.1 Наименование операции: Управление комментариями.

4.4.9.2 Условия выполнения операции: Модератор имеет доступ к административной зоне сайта.

4.4.9.3 Подготовительные действия: Модератор переходит на страницу с комментариями.

4.4.9.4 Основные действия:
- Просмотр комментариев:
Модератор просматривает все комментарии на странице, обратив внимание на текст, авторов, дату и рейтинг комментариев.

- Редактирование комментариев:
Если необходимо внести изменения в комментарий, модератор выбирает соответствующий комментарий и нажимает на кнопку "Редактировать." Затем модератор вносит необходимые изменения в текст комментария и сохраняет изменения.

- Удаление комментариев:
Если какой-либо комментарий нарушает правила сайта или несет в себе ненадежную информацию, модератор выбирает этот комментарий и нажимает на кнопку "Удалить." Комментарий будет удален.

- Ответ на комментарии:
Модератор может отвечать на комментарии, нажав на ссылку "Ответить" под комментарием. После этого модератор может написать ответ в текстовом поле, и ответ будет опубликован после сохранения.

4.4.9.5 Описание блока комментариев
Блок комментариев представляет собой прямоугольную область на странице под статьей или записью.
Верхняя часть блока содержит заголовок "Комментарии" и количество комментариев (например, "2" в данном случае).

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

Каждый комментарий имеет следующие элементы:
- Аватар (изображение пользователя).
- Имя пользователя.
- Текст комментария.
- Дата и время добавления комментария.
- Действия с комментарием (ответить, редактировать, удалить).
- Рейтинг комментария (положительный и отрицательный).

Ниже списка комментариев расположена форма для добавления нового комментария. Форма включает следующие элементы:
- Поля для ввода имени пользователя и email (возможно скрыты).
- Текстовое поле для написания нового комментария.
- Кнопки "Сохранить" и "Отменить" для отправки или отмены добавления комментария.

А вот это уже интересно: составление описания и инструкции пользователя по скриншоту экрана! Доступно только в платной подписке GPT 4, но зацените уровень "чтения" картинки.

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

А вот генерация интерактивных прототипов из... да из всего генерация! хоть из мокапа, хоть из диаграммы состояний

Коллеги из Systems.Education перевели одну из провокационных статей Пола Ральфа: "Иллюзия требований при разработке программного обеспечения". В свое время немало споров она вызвала.

Ральф там высказывает две философские проблемы, связанные с понятием "требование":
1) онтологическую, проблему существования: а существуют ли вообще требования в смысле "неотъемлемые свойства решения, каким бы оно ни было", то есть то, что должно быть в любом случае реализовано, при любом выбранном способе решения. Из чего следует вторая проблема:
2) эпистемологическая, познавательная: а можем ли мы быть уверены, что мы рассмотрели все возможные варианты решения? А вдруг есть решение, которое мы не учли, и в котором вообще не будет нужды в тех свойствах, которые мы зафиксировали как требования?

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

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