Ладно, что мы всё о работе. Вот почитайте стихи про требования от ИИ:

>Write a poem about software requirements

In fields of code and screens so bright
Lies a land of endless possibilities
Where software requirements lay in wait
To guide the way and pave the path

With clear and concise language they speak
Outlining all that must be done
From the smallest of details to the grand design
Software requirements make it all real

They lay the groundwork for what's to come
Guiding developers on their way
Ensuring that the end result will be
A product that works without a glitch

So here's to the unsung heroes of the digital age
The software requirements that guide us all
May they continue to help us build
The future that we can't yet see.

Довольно часто поднимается тема собеседования системных аналитиков. Ну вот как понять, что человек соображает? Программисту можно прямо на собеседовании дать небольшую задачку, какой-нибудь fizz-buzz или сортировку, или ещё что-то бесполезное, что потом в работе никогда не встретится :) С аналитиками ещё хуже — ну что кандидату такое дать, чтобы быстро понять, как он думает? Не просить же написать ТЗ, это долго (можно дать такое тестовое заранее, если, конечно, человек готов делать тестовое. В результирующем документе нужно, в первую очередь, проверить — есть ли заголовок, дата составления и версия; а потом — есть ли структура и заголовки разделов. Ну, то есть, если человек не соблюдает базовую гигиену, это уже звоночек). Но вот чтобы прямо на собеседовании проверить — таких методов нанимающие обычно не знают. Отсюда разные приемы, когда просят порассуждать о понятиях: а что такое требование, а что такое модель, а как выглядит процесс сбора требований... Ну, это как нанимать жонглёра в цирк, и попросить его порассуждать о техниках жонглирования и биомеханике. Вам методист-теоретик нужен? Вы посмотреть не хотите на то, как он жонглирует?..
Я собеседовал не меньше сотни аналитиков на разных проектах, и вывел для себя отличное задание: вот вам текст (1-2 абзаца), оформите его, как таблицу. Это очень простое задание, его можно быстро сделать, и оно очень показательное — сразу многое понятно про кандидата. Удивительно, но многие люди в принципе не способны его выполнить! То есть, простая категоризация и структуризация текста не выходит. Можно и другие варианты вопросов задать: построить модель объектов предметной области, которую описывает этот текст. Или модель процесса. Выписать действующих лиц, их основные действия и результаты этих действий. Очень просто.
Сложность у меня обычно возникает с подбором заданий: чтобы и текст был коротким, и хватало материала для работы. Но вот в группе Анализ и проектирование ИТ-систем (не реклама!) Алексей Краснов сформулировал очень классный текст, который подходит по всем критериям: короткий и содержит много информации. Текст про процесс выработки требований к информационной безопасности, как раз на один абзац:
"Первым шагом надо определить перечень информации, конфиденциальность которой вы хотите (или вам надо) обеспечить. Затем надо построить контекстную диаграмму системы (DFD), затем отметить те элементы, где передаётся, хранится или обрабатывается информацию, конфиденциальность которой вы хотите обеспечить. Далее для каждого элемента контекстной диаграммы, где хранится, обрабатывается или передаётся конфиденциальная информация, необходимо рассмотреть все угрозы, относящиеся к раскрытию информации и за счёт каких уязвимостей. Затем вам необходимо описать требования для закрытия выявленных уязвимостей. Иногда до описания требований ко всем уязвимостям оценивают риски по каждой паре угроза-уязвимость. Для этого надо оценить простоту реализации уязвимости, степень влияния на бизнес, возможности предполагаемых нарушителей, их мотивация, и исходя из всего этого получите оценку риска по каждой угрозе и уязвимости."
Это текст отличный — в нём есть описание процесса, описание понятий и артефактов. Можно вполне оформлять это в таблицу, даже в несколько разных. Тут я, кстати, обычно не подсказываю сначала кандидату — пусть сам попробует понять, про что текст и что в нём можно подчеркнуть при помощи структурирования. Следующий шаг — составить таблицу, в которой есть пропуски, чтобы можно задать дополнительные вопросы. Это — идеальный результат работы, на самом деле. Аналитик на то и нужен, чтобы задавать вопросы и прояснять неясное.

Всех с наступившими праздниками! 🎄Позитивных сдвигов в новом году!
В качестве небольшого новогоднего подарка коллеги из школы Systems.Education подготовили подборку ссылок на материалы по интеграциям информационных систем, curated content :) Ссылок много, получилась целая wiki. Enjoy! 🎅

Мы с коллегами-добровольцами подготовили для вас
Базу ссылок на полезные материалы по системной интеграции
для аналитиков и проектировщиков.

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

Что в неё сейчас вошло:

Основы интеграции информационных систем
- Постановка задачи и общий обзор
- Способы классификации интеграций

Форматы представления данных
- Форматы JSON и YAML
- Форматы XML и XSD

Сетевые протоколы и транспорт
- Протоколы HTTP, HTTPS
- Протокол WebSocket

Сценарии взаимодействия, Sequence, Plant UML

Web Serviсes / RPC
- Проектирование API
- REST-like сервисы. Стиль REST
- Протокол SOAP и форматы XML, XSD, WSDL
- Технология GraphQL
- Технология gRPC

Обмен сообщениями
- Паттерны обмена сообщениями
- Apache Kafka
- Брокер Rabbit MQ

Файловый обмен

Интеграция через общую БД

Архитектурные паттерны интеграции систем
- Интеграционные шины, Enterprise Service Bus (ESB)
- API Gateway, Backend For Frontend
- Оркестрация и хореография
- Circuit breaker

Дальше готовим другие подборки по темам:

- Базы данных и анализ данных
- Бизнес-анализ и моделирование
- Архитектура программного обеспечения и Systems Design

На курсе по микросервисной архитектуре встретил чеканную формулировку: микросервисная архитектура нужна для снижения lead time в крупных системах. Lead time — время прохождения через цепочку производства отдельной новой функции. Можно сказать, снижение Time-to-market отдельной фичи. И если после перехода на микросервисы — а на микросервисы почему-то всегда переходят, никто не начинает с микросервисов :)) — эта метрика должна упасть. Если растет, в не падает — значит, вы делаете что-то не так. Это очень простое объяснение, ценное для бизнеса.

Agile, кстати, обещает то же самое. Джефф Сазерленд вообще так и назвал свою книгу: как делать вдвое больше работы за половину времени. То есть, пообещал ускорение аж в 4 раза. Это название даже на русский испугались перевести. И всё, у всех теперь SCRUM :) Ну ещё бы, кто же не захочет ускорить работу программистов в 4 раза.

И я задумался: есть ли такое же объяснение для практики системного анализа? Какую одну главную метрику, очевидно ценную для бизнеса, улучшает системный анализ? TTM он как раз скорее снижает — ведь в процесс добавляются дополнительные действия. А вот что улучшает? Как системный анализ продать бизнесу?

К вопросу про ускорение или замедление работ. Часто ТЗ по ГОСТу воспринимают, как waste — потери, что-то излишне формальное и то, что делать совсем не нужно, а нужно только для формального закрытия контракта. Как говорил один мой знакомый — это чтобы нам деньги доехали, к работе это не имеет отношения. Я очень не люблю такие фанерные декорации, хотя на определенном уровне и особенно в госконтрактах это почти повсеместная практика, к сожалению. По сравнению с другими схемами эта ещё выглядит совсем невинно.
Но мне-то ГОСТ 34 нравится (после того, как я в нём разобрался :) практически, как я перестал бояться и полюбил ГОСТы :) )) Мне комфортно с ГОСТом, я могу засунуть туда практически всё, что мне нужно в проекте. А однажды один из пунктов ТЗ по ГОСТу спас меня от очень больших расходов — тот пункт, который обычно относят к "воде": про гарантию работоспособности на конкретных версиях операционных систем.
В общем, я всегда стараюсь приспособить ГОСТ к реальной работе, и не делать дважды в разных видах одно и то же. А на завтра у нас в школе запланирован бесплатный вебинар, на котором как раз про ГОСТ и его осмысленное применение расскажет эксперт, который разделяет со мной это отношение!

‍26 января в 18:00 пройдет бесплатный открытый вебинар, который развеет мифы о ГОСТ 34 и поможет взглянуть на него по-новому. Спикер — Василий Баракин, применяет ГОСТ 34 более 15 лет и в роли архитектора ПО участвовал в проектах Enterprise уровня.

Этот вебинар для вас, если вы:
• аналитик
• руководитель проекта
• технический писатель
• ведущий разработчик
• представитель заказчика
• сотрудник ИТ-компании, работающей с госзаказчиками

Даже если вы не работали по ГОСТ-ам, наверняка вы слышали о них. Стоит ли приходить просто для расширения кругозора? Однозначно, да!

Наш гость:

— Развеет заблуждения о ГОСТ 34 и поможет взглянуть на ГОСТ по-новому
— Покажет ТЗ во взаимосвязи с документами других стадий создания АС
— Раскроет важность пунктов ТЗ, которые либо упускают, либо копируют из Интернета

О спикере:

Василий Баракин:

• Архитектор проектов по информационной безопасности
• Опыт применения ГОСТ серии 34 более 15 лет
• Участвовал в создании автоматизированных систем федерального уровня

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

Регистрируйтесь по ссылке, участие бесплатное!

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

Риски же тут огромны: Chaos Report дает оценку около 17-20% вероятности полного провала проекта, и 40-50% вероятности значимого выхода проекта за границы сроков или бюджета. Конечно, любому менеджеру хочется снизить такие огромные вероятности. Что интересно, эти вероятности практически не зависят от квалификации команды (если только вы не набрали совсем неподходящих людей — тогда вероятность примерно на 10% выше. Что интересно — связь с высокой квалификацией менеджмента вообще отрицательная — менеджеры с высокой квалификацией с большей вероятностью ведут проект к провалу).

Так вот практики agile или микросервисов подходят к этой задаче с другой стороны — они снижают ущерб. Работа короткими итерациями с частыми поставками (а значит — с частым получением обратной связи) разделяет большую систему на маленькие инкременты, потеря или переделка каждого из которых не несет большого ущерба. Даже если вероятность накосячить очень высока. Кроме того, в процессе этого путешествия команда постепенно узнает предметную область и задачу всё лучше и лучше, а значит — может предложить лучшее решение (см. Paul Ralph, Is Requirements Engineering Inherently Counterproductive?), то есть и вероятность тоже со временем снижается.

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

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

А вы знали, что, если попросить ChatGPT вывести результаты в таблицу, эту таблицу потом можно скопировать и вставить в Miro как отдельные карточки? И потом уже на доске располагать их, как угодно? Например, так можно вытаскивать на доску User Story, идеи для мозговых штурмов, события для Event Storming (шучу, их должны предметные эксперты генерировать) или, например, модули и их API. #chatGPT

А вы читали "Алмазный век, или Букварь для благородных девиц" Нила Стивенсона? Это такая фантастика, одним из центральных элементов в сюжете которой служит "Алмазный букварь" — такой интерактивный, или даже иммерсивный учебник, подстраивающийся под ученика. В принципе, с #chatGPT мы уже очень близки к этому. Вот, например, сказочка про системного аналитика (упоминание Алмазного букваря явно сбило с толку ИИ, потому что в книге Букварь был для маленькой девочки, поэтому и сказка):

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

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

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

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

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

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

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

Конец.

Упражнения и проекты для учащихся:

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