Сходил на очный трёхдневный курс Системный анализ. Разработка требований в ИТ-проектах с мыслью "ща сверю часы с крутанами — всё ли я правильно делаю".

Проходит в офисе CUSTIS (ЗИС, хе-хе) на Белорусской.

Курс устроен так: теория > практика > обратная связь.

Разбиваетесь на команды по четыре человека и придумываете cистему, к которой будете разрабатывать требования, и создаёте несколько артефактов:
- Карточка продукта
- Контекстная диаграмма
- Модель данных
- Диаграмма юзкейсов
- Сами юзкейсы
- ещё несколько, если успеете

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

Наполнение курса — далёкое от моей реальности.

Если ты не начинающий, то и так используешь артефакты избирательно и меняешь их под задачу. Но в уровне курса и написано "Junior+" — сам виноват.

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

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

Лектор прикольный-приятный, классно иллюстрирует во всех смыслах, понятно отвечает на вопросы. Ведёт канал @systemswing
Сама по себе структура курса — хорошая. Вот подробнее о создании: https://beskov.substack.com/p/designing-online-course-for-it-analysts-8d5b6d0e8413

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

Diagram — a simple plan that represents a machine, system, or idea, etc., often drawn to explain how it works.

У Диаграммы более узкое значение, чем у Diagram. Обычно диаграмма используется для наглядного представления чисел и делания выводов на основе этих представлений.

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

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

@momzille возродила великий формат для встречи-знакомства аналитиков

Владимир Пропп «Морфология волшебной сказки»

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

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

В подкасте хорошо рассказали о второй книжке, в которой Пропп объяснил причины одинаковости сказок у народов, которые не могли пересекаться: https://music.yandex.ru/album/18954362/track/110522161
Спойлер: потому что обряды

Фанфакт: сказки старше мифов древней Греции; мифы — это доработанные сказки.

Двойка + точка показались знаком вопроса².

² — для ссылок нужен другой шрифт².?