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

Пошел искать источник цитаты "Architecture is a stuff that's hard to change" ("Архитектура — это всякие штуки, которые потом трудно изменить", приписываемой Мартину Фаулеру, обнаружил, что, как это часто бывает, во-первых, и фраза не его, а Ральфа Джонсона (паттерны проектирования и XP), а, во-вторых, полностью звучит так: "One of the differences between building architecture and software architecture is that a lot of decisions about a building are hard to change.", то есть:

"Одно из различий между архитектурой зданий и архитектурой программных систем в том, что множество решений в случае зданий трудно изменить"

— в общем, как обычно, исходная цитата имеет совершенно противоположный смысл! (отсюда: https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf)

Сам Мартин Фаулер топит за то, что хорошая архитектура как раз допускает широкий диапазон изменений и хороший архитектор уменьшает архитектуру на проекте (по-английски звучит красивее: a good architect reduces architecture).

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

Провёл несколько сессий Event Storming, добавил себе в арсенал ещё оно возможное задание для собеседования аналитика (в том числе — для проверки диаграмм процессов): перечислить — а лучше нарисовать — последовательность событий в каком-то процессе.

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

В общем, и угол рассмотрения интересный, и ошибки новые, свежие :)

Коллеги собрали папку каналов по системному анализу, как это сейчас модно. А вы какие каналы читаете по нашей теме?

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

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

Собрали для вас подборку каналов и групп, посвященных системному и бизнес-анализу от практиков и школ.

Можно подписаться сразу на все или выборочно. Каналы сложатся в отдельную папку SA. Потом можно отменить подписку или размьютить, как и с другими каналами, но мы рекомендуем следить за актуальными темами отрасли!

Папка с нашей подборкой классных каналов про системный и бизнес-анализ.

У Григория Добрякова классный (и очень холиварный, ух как у многих от него пригорело!) пост про шины и брокеры: как вы их используете — как шину данных, или как шину сообщений? Процитирую самую суть:

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

1. Событийный брокер (кафка, раббит) с честным потоком событий.

2. Событийный брокер, в который все ходят как в БД (клиенты работают выборкой по хранящимся сообщениям в произвольном доступе).

3. Симбиоз событийного брокера и БД с трансформациями, когда вы кладёте в шину данные в одном виде, а достаёте их в другом (например, в денормализованном или наоборот в компактифицированном).

4. Просто тупо одна большая БД, в которой хранится абсолютно каждый объект в его последнем состоянии. То есть shared state, который все читают и все меняют, ага.

5. Некий http-шлюз, в который ты посылаешь данные post-запросом, а он проксирует этот запрос в целевую систему. Ну или наоборот get-ом так же получаешь данные.

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

7. Всевозможные мостики-трансляторы из http в хранимую процедуру в БД.

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

Предназначение событийной шины — пересылать события о данных, А НЕ сами данные. Если у вас, например, заказ перешёл в статус «оплачен», то это событие, ценной информации в котором фактически только два поля — это id заказа и наименование статуса.

[...]

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

Поэтому передают объекты целиком. "

Пост, как я уже говорил, максимально провокационный (на самом деле там даже три поста и куча обсуждений). Но заставляет много о чем задуматься. В первую очередь — о трезво принятых решениях и о решениях, которые просто так появились, без анализа и оценки. У архитекторов есть такая практика — ADR, Architecture Decision Records, журнал принятых архитектурных решений, с обоснованиями, развилками и компромиссами, или Trade-Offs — что мы выигрываем, а что теряем при каждом решении. Аналитики обычно такие записи не ведут, а очень зря — так принятые решения проходят мимо анализа, "ну потому что всегда так делается же", и приводят иногда к неожиданным отдаленным последствиям.

Вот как в случае с Кафкой — ну поставили, а как вы её дальше используете? По какому из описанных выше паттернов? Какие trade offs были при этом учтены, и к чему всё это может привести? (Отдельно замечу, что вопрос "как правильно" вообще не имеет смысла в этом случае. Правильно так, как максимально полезно в имеющихся и возможных в будущем условиях).

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

Например, я несколько раз просил оценить сроки проекта — получалось очень близко к экспертной оценке. Я решил проверить, и взял методику оценки от московского ДИТа — она публично доступна. Методика использует метод функциональных точек с весами и поправочными коэффициентами. Она довольно сложная, и я не стал рассчитывать коэффициент совмещения для должностей, то есть взял максимальную оценку сверху — получилось 38 человеко-месяцев. ChatGPT по описанию проекта дал оценку 6 человек и 4-6 месяцев, то есть 36 человеко-месяцев.

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

В случае же с оценками сроков — тут можно объяснить точность самим принципом работы языковой модели — она ведь подставляет статистически вероятный токен, ну вот на базе собранных публикаций эти сроки и есть наиболее вероятные! :)

Свежая статистика по зарплатам в вакансиях. Вчера как раз зарубились на эту тему на круглом столе на конференции "Анализ & Управление в ИТ проектах" – специализированная конференция 1С-аналитиков, куда меня позвали рассказать про ChatGPT. У 1С сейчас бум – во-первых, проекты стали сложнее, и запросов от бизнеса больше – и на интеграции, и на анализ данных, и на более дружелюбные интерфейсы; во-вторых – многие компании ищут замену SAP. При этом раньше массово такой роли, как аналитик, в 1С не было, а сейчас это очень горячая тема, и ребята активно осваивают все методы, существующие в других областях.

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

( Отдельно зафиксирую, что планка в 400 тыс. – это что-то новое, раньше такого вроде не было. Такие суммы обычно готовы платить архитекторам, а не аналитикам. Видимо, спрос на квалифицированные кадры продолжает расти)

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

При этом разговор про качество модели почему-то идёт туго, сбиваясь на "описание системы соответствует системе", то есть где-то тут есть неразличение описания и модели. Соответственно, возникает непонимание способов оценки качества работы аналитика. Количественно, по строкам документов? Так их должно быть наоборот меньше — чем выше соотношение "объяснительная сила модели" / "размер модели" — тем лучше. По отзывам от потребителей — чем меньше уточняющих вопросов от программистов / тестировщиков — тем лучше? Хорошая характеристика, но лукавая — может, программист вообще эти постановки не читает, тогда и вопросов не будет :)

Вообще, с точки зрения бизнеса, мне кажется, основная ответственность аналитика — уменьшение двух рисков: 1) что мы сделаем не то, что нужно; 2) что мы не сделаем того, что нужно. Я об этом уже когда-то писал. И метрикой тут становится почти шуточное "количество раз, когда заказчик или архитектор воскликнули: О! Об этом мы как-то не подумали!..". Если, конечно, вы оцениваете этот риск, как высокий, и вообще собираетесь что-то с ним делать. Правда, такой анализ влечет увеличение объема проекта (от 30% до 300% иногда!), но лучше об этом узнать заранее.

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

Так-то за 130 лет ничего и не изменилось 😁 "Слушайте слова мудрости, которые несёт вам ChatGPT фонограф!"

И даже сравнение с попугаем точно такое же :)

Оказывается, сервис, который я проектировал в Московской электронной школе — портфолио учащегося — получил Премию Рунета 2022. Это прямо признание. Теперь у меня один проект в 2016 в шортлисте — "Открытое образование", и один — лауреат. Приятно.

На конфе "Анализ & Управление в ИТ-проектах" от Infostart мне очень понравился мастер-класс по ТРИЗ. ТРИЗ часто вспоминают в связи с ИТ, но толком мало кто может рассказать, как его системно применять. Тут тоже не было особо сильной привязки к ИТ, но зато наглядно показано, как сама техника работает, и почему очень важно найти и правильно сформулировать противоречие.

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

И ТРИЗ, вместо избегания противоречий или проектирования слабых компромиссных решений предлагает стремиться к такому решению, которое выполняет оба противоречащих условия! Только такие решения становятся прорывными. На мастер-классе предлагалось несколько вариантов рассуждений для выработки таких решений. Например, мне очень понравилась техника "обострение конфликта": вывод значения какого-то показателя далеко за рамки обычного диапазона. Например, противоречие: при торговле на фондовом рынке трейдер должен проанализировать риск сделки, и одновременно должен как можно быстрее сделать сделку, чтобы не упустить выгодные условия. Уведем значение "принятие решения о сделке" в запредельный диапазон, например - миллисекунды. Пусть трейдер принимает решение о сделке за микросекунды, и передает приказ о покупке или продаже за миллисекунды. Понятно, что при такой скорости трейдер не может быть человеком, а объем каждой сделки должен быть крайне небольшим, чтобы снизить риск (в идеале, сделки должны быть вообще безрисковые). Решение называется "высокочастотный трейдинг" (HFT), и сейчас до 40% объема торгов генерируется именно таким методом. Не уверен, что при изобретении HFT применяли ТРИЗ, но решение хорошо иллюстрирует пример рассуждения :)

Тут использованы несколько приемов ТРИЗ:
🔸 разделение конфликта по условию (используем не для всех сделок, а только для безрисковых)
🔸 новый принцип действия (человека заменяем алгоритмом, прошитым на FPGA)
🔸 переход в надсистему (HFT требует организации инфраструктуры со стороны биржи и не имеет смысла для одного трейдера, это услуга сразу для многих)
🔸 разделение конфликта во времени (трейдер заранее продумывает алгоритм принятия решения, а не в момент сделки)
🔸 разделение в пространстве (трейдер сидит в банке, а плата с FPGA устанавливается прямо в сервер биржи, иначе задержки передачи пакетов съедят всё время на принятие решения)

Другие приемы, упомянутые на МК:
🔸 разделение конфликтующих элементов в структуре системы (вот тут я сразу вспомнил DDD - ограничил контексты, и часть конфликтов уже ушла, а микросервисами можно регулировать противоречащие требования к надежности, скорости и безопасности)
🔸 объединение с антисистемой (вот тут не очень придумывается пример из ИТ, если у вас есть - пишите в комментариях)

Говорят, у Альтшуллера - создателя ТРИЗ - была таблица с типовыми техническими противоречиями. Вот бы такую таблицу для ИТ-систем составить. С типовыми же решениями. Чтобы деятельность архитектора из искусства превратить в инженерную практику.

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

Я к объявлению добавлю, что мы развиваем направление интеграций, проектирования и архитектуры (systems design, UX), так что если вы чувствуете себя уверенно в этих областях — приходите делать новые курсы! Писать можно мне или Денису (по ссылке в объявлении).

Ищем тренеров по системному анализу и проектированию
на дистанционную работу

Ищем в команду школы опытных системных аналитиков, которым интересно собственное развитие через обучение других:
— проведение контактных групповых онлайн-занятий в малых группах (до 12-15 человек)
— проверка домашних работ
— разработка учебных материалов (по желанию)

Мы ждём, что вы хорошо знакомы c 3-4 профессиональными темами из:
— классическая инженерия требований
— проектирование взаимодействия в форматах use case и user story
— современные фасилитационные практики Event Storming, Impact Mapping, Story Mapping
— моделирование структур данных и применение SQL
— интеграция информационных систем и проектирование API
— проектирование пользовательских интерфейсов

учебные курсы, которые надо вести:
— Системный анализ и Разработка требований в ИТ-проектах
— Systems Analyst Bootcamp
— Проектирование интеграций через брокеры сообщений

основное время проведения занятий
— суббота и воскресенье с 10 до 14 мск

загрузка от 8 до 24 часов в месяц по договорённости

пишите о себе Денису @beskov

По поводу одного из предыдущих постов возникла дискуссия про зрелость программной архитектуры, как инженерной дисциплины. Тема крайне дискуссионная и требует более подробного анализа, но вот что я вспомнил. Сейчас общее место для архитектуры - стили и паттерны. Мы говорим про тактические паттерны DDD, паттерны интеграций приложений, паттерны объектно-ориентированных языков. Даже популярная тема systems design обсуждается в виде типовых решений и шаблонов. Обычно разговор про паттерны возводят к книге Кристофера Александера "Язык шаблонов", но ещё немного раньше - в конце XVII - начале XVIII века - жил в Швеции гениальный механик и преподаватель Кристофер Полхем. Он для своего времени был пионером - например, спроектировал и построил фабрику, автоматически производившую несколько (!) видов товаров (это ещё до паровых двигателей, на воде, как мельница!). Его называли "северным Дедалом".

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

А "Механический алфавит" можно увидеть в Национальном музее науки и технологий в Швеции, ну или на сайте: https://digitaltmuseum.se/search/?q=mekaniskt+alfabet
Это вам не книжка, это настоящие физические деревянные модели!