Осенью на Infostart Tech Event меня попросили рассказать про уровни требований: все эти BRS, SRS и так далее.

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

1) Если вы их разрабатываете последовательно, и перед переходом к более детальному документу принимаете решение: идём дальше или нет? А ещё, по-хорошему, рассматриваете несколько вариантов, и выбираете из них. Тогда вам нужен предыдущий документ, чтобы вернуться к нему — начать заново или проверить соответствие.

2) Если команда между документами меняется. Это не очень хорошая история, но бывает. И документ тут — не самый лучший вариант, но уж какой есть, иногда только так.

И, уж если вы всё-таки разрабатываете эти документы, как бы они не назывались, смысл их такой:
👉🏻 Что нужно?
👉🏻 Как делать будем?
👉🏻 Что в итоге сделали?
👉🏻 Как этим пользоваться?

И — как и почему в каждом случае принимали решения. А то иногда смотришь, и думаешь — wtf?! А у людей ведь мысль какая-то была.

В общем, держите всю презентацию, может пригодится.

Если вам нравится идея нарезки требований (решений) на уровни, то в Archimate есть, пожалуй, самая детальная нарезка в Layered Viewpoint, многослойном представлении архитектуры:

🟡 внешние акторы (клиенты, организации)
🟡 услуги, которые мы им предоставляем (бизнес-сервисы)
🟡 бизнес-процессы, при помощи которых предоставляются услуги
🔵 ИТ-сервисы, которые поддерживают процессы
🔵 прикладные ИТ-системы, которые предоставляют сервисы
🟢 Инфраструктурные сервисы, обеспечивающие работу ИТ-системы
🟢 Инфраструктура (оборудование, базовые ИТ-системы)

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

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

Удобно это всё зафиксировать на диаграмме, чтобы все понимали свой маневр.

Я уже тут как-то ссылался на Григория Добрякова, архитектора и ИТ-менеджера, очень люблю его посты про индустрию. Вот и опять:

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

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

Disclaimer: сразу обозначу, что мы сначала уделяем много времени смолл-толку, разбалтываем кандидата, и я всегда вежливо уточняю «будет ли тебе комфортно сейчас поговорить о...»

Но тем не менее! Половина кандидатов, даже с тимлидским опытом за плечами, вообще не слышат условий и начинают рассказ с выбора способа авторизации в админку. Что? А вот.

Другие начинают рассказывать о том, что они сделают таблицу с заказами и положат туда информацию о покупках. Каких блин покупках?? А вот. Это же у нас покупатели, верно? Значит у них покупки... (никакие покупки в задаче не звучали)
Абсолютное большинство в упор не может ответить на вопрос «давай всё же перечислим, какие у нас будут столбцы?».. Вести человека к варианту ответа «давайте для начала сделаем одну табличку на три столбца для фамилии, имени и отчества» приходится за ручку.

И ради бога не стоит задавать вопрос «а как вы эту табличку назовёте». Я раньше задавал.

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

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

Люди с 15 годами опыта Senior System Analyst. Люди с опытом тимлидства и проектирования архитектуры в резюме. Ноль сомнений.

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

А потом я их добиваю вопросом как к этому всему приделать REST API. Например, какие методы нужны для удаления информации о том, что некий Вася Пупкин жил в Москве с 2010 по 2012 год.

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

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

Но с остальными то что не так?

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

Логическую цепочку «Domain model — ERD — модели — реляции — ресурсы — CRUD API — унифицированные интеграции — низкие косты» не видит в принципе никто.
Зато поп*здеть на тему REST vs GraphQL готов каждый второй, ага.

Когда всё поломалось в этом мире?
Что программируют эти программисты? Что проектируют эти блин системные аналитики? Ребята, а если у меня проект на 200+ классов предметной области (бывало), а мы тут с вами в двух путаемся, то что дальше будет?

Что блин не так то?

Не понимаю, откуда берётся вопрос "куда развиваться дальше сеньор-аналитику?". Причем с ответами типа "идти в продакты / архитекторы / лиды аналитики".

Очевидно же, что после сеньора нужно идти в стафф-аналитики, потом — в сеньор-стафф, потом — в принципал, и, наконец, в феллоу аналитика.

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

Нет после сеньора выбора: архитектор или управленческий трек. Это у вас в компании что-то неправильно поняли. Сеньор — это старший аналитик на одном проекте. Стафф — аналитик, курирующий несколько проектов. Принципал — это тот, кто закладывает принципы работы всех системных аналитиков в компании (опыт — 8+ лет). Феллоу — советник CTO или директора по системному анализу и проектированию систем (10+).

Там ещё могут быть промежуточные уровни вроде "бизнес-партнер" (слышали же про HR BP? вот то же самое, только по технологиям) и distinguished (это перед fellow). И это всё должности специалистов! Людьми руководить не нужно, не менеджерский трек!
Вопросов, как повысить зарплату очень ценному чуваку, не делая его начальником, не возникает — сделай ещё грейдов, бери, повышай.

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

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

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

Жаль, что не все компании (и руководители) понимают всю полезность такой роли. Вопросов было бы сильно меньше.

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

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

Ну, все точно слышали про PMBoK и BABoK.
Но есть ещё куча интересных сводов знаний, в которых собраны по кусочкам разные знания, которые вообще-то нужны продвинутым аналитикам! Поехали:

SWEBoK — Software Engineering, он же — ISO/IEC TR 19759:2015. Свод знаний по программной инженерии, ни много, ни мало! Современные программисты про него и не слышали. Тут нас могут интересовать разделы про требования, software architecture, software design и software construction (это всё разные понятия!), а ещё софт-скиллы и экономика разработки (это 11 и 12 главы).

SEBoK — Systems Engineering, а это уже по системной инженерии в целом. Кстати, более-менее свежие идеи про работе с требованиями приходят именно из системной инженерии, это у них одна из основных практик. Тут всё начинается с самого начала: что такое система, что такое системное мышление, что такое модель и т.д.

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

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

EABoK — Enterprise Architecture, тут всё понятно. Непонятен только статус: на сайте MITRE лежит черновик от 2004 года (pdf), есть ли что новее, я не понял. В черновике, судя по всему, авторы пытаются не заблудиться между TOGAF, DODAF, Zachman Framework и другими способами описания EA, но у них не получается.

BIZBoK — Business Architecture, свод знаний по бизнес-архитектуре. Стратегия, бизнес-возможности, структура организации, бизнес-инициативы, ценности, продукты, нормативка — всё тут. А также референсные модели бизнес-архитектуры для разных индустрий.

BTABoK — Business Technology Architecture, это про цифровую трансформацию. Хотя сами авторы оплёвывают этот термин, заявляя, что это только чтобы у вас деньги выманить, а говорить нужно про цифровое превосходство (Digital Advantage). Дальше они также оплёвывают TOGAF, SAFe, BABoK и так далее. В целом, замах тут "как говорить с бизнесом про ИТ". Дико интересно, но местами неокончено.

BPMCBOK — тут всё понятно, управление бизнес-процессами. Есть русский перевод, и даже довольно активное российское отделение соответствующей международной ассоциации.

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

DMBoK — Data Management, свод знаний по управлению данными. Всё, что вы хотели узнать про данные в любом виде (в том числе — про качество данных и интеграцию данных). Есть перевод и открытый конспект на русском, но при случае рекомендую обзавестись оригиналом, если вы много работаете с данными в каком-либо аспекте.

Знаете ли вы ещё какие-нибудь своды знаний? А пользу в них видите?

Про REST слышали наверняка все.
Некоторые даже слышали про RESTful. Единицы вспомнят модель зрелости REST Леонарда Ричардсона и её уровни.

Между тем, есть отличная статья Guy Levin, перевода которой я почему-то не нашел. Нужно это срочно исправить! Здесь дам короткий вольный пересказ.

Уровень 0: The swamp of POX (Plain old XML) — Болото старого доброго XML.
Это нам напоминает, с чем боролся Рой Филдинг: XML, SOAP и вызовы разных функций из одного эндпоинта методом POST.

Даже тут есть правила:
1. В названиях эндпоинтов слова нужно разделять дефисом: "-", это spinal case или kebab-case, "шашлычный стиль" — слова как бы нанизываются на шампур.
2. Подчеркивания в названиях эндпоинтов лучше не использовать. Почему так: потому что ссылки в тексте подчеркиваются, и символы "_" могут визуально потеряться, в отличие от "-".
3. Все ссылки должны быть в нижнем регистре. Это всё рекомендации RFC3986.
4. Расширения (то есть точку) лучше не использовать, формат ответа задаётся заголовком Content-Type.
Пример: http://api.example.com/blogs/guy-levin/posts/this-is-my-first-post

Уровень 1. Ресурсы.
Идея: разные эндпоинты для разных ресурсов. Названия эндпоинтов - существительные.
Правила:
1. Слэш ("/") в конце названия эндпоинта не нужен. Каждый ресурс имеет один адрес (URI). Разные URI указывают на разные ресурсы.
2. Слэш употребляется для указания иерархии ресурсов:
http://api.canvas.com/shapes/polygons/quadrilaterals/squares,
http://api.college.com/students/3248234/courses/2020/fall
3. Существительные в единственном или во множественном числе? Тут у автора сомнения, но большинство фреймворков поддерживают названия ресурсов во множественном числе. Мне лично тоже больше нравится во множественном.

Уровень 2. Методы.
Используем для операций с ресурсами стандартные методы http, соответствующие CRUD: POST, GET, PUT, DELETE, PATCH + дополнительные HEAD и OPTIONS. Если вам не хватает операций CRUD, автор рекомендует сделать подчиненный ресурс /actions, и делать к нему POST с указанием типа операции и дополнительных параметров. Такой небольшой кусочек RPC-like style, когда RESTful не одобряет, но очень хочется.

2.1. Заголовки HTTP
Используйте заголовки! Тема тут обширная, но в основном заголовки используются для безопасности, переговоров клиента и сервера о форматах и кодировках контента, о кэшировании, версиях и обновлениях ресурсов, их размерах. Собственно, запрос HEAD возвращает заголовки без самого тела ресурса, чтобы клиент мог понять — нужно ли запрашивать ресурс вообще.

2.2. Параметры запроса
Используйте параметры запроса! (та часть, которая после @?"). Не забывайте про такие операции, как фильтрация, поиск, сортировка и пагинация. Для фильтров добавляем названия полей ресурса, по которым можно отфильтровать результат, указав значения или диапазон:

https://example.com/api/products?category=electronics&price=50-100

Для поиска — параметр ?q={строка поиска}.
Для сортировки: ?sort={поле, по которому сортируем}&order={ASC|DESC}. Как вариант, для сортировки по нескольким полям: ?sort=name,-price (сортируем по названию в прямом порядке, по цене — в обратном).
Для пагинации указываем число элементов на странице и номер страницы:
?limit=10&offset=20.

2.3. Коды ошибок
Используйте коды ошибок HTTP.

Уровень 3. Управление гипермедиа.
Тут два аспекта: обсуждение формата и HATEOAS.

3.1. Обсуждение формата — это про заголовки. Клиент и сервер договариваются, в каком формате сервер вернет ресурс. Может, в json, может в XML, а может просто в виде текста. В теории должно работать, и серверы должны отдавать ресурс в удобном для клиента представлении. На практике реализация встречается очень редко, но во внутренних гетерогенных системах может быть полезным. Запрос OPTIONS как раз про это: какие действия допускает сервер над ресурсом и в каких форматах готов его отдавать.

3.2. HATEOAS. Hypermedia As Transfer Engine Of Application State. Не бывает. Хотя идея в целом хорошая: к ответу сервер должен цеплять перечень эндпоинтов, связанных с запрашиваемым ресурсом, показывая всю иерархию подчиненных ресурсов. В теории, если вы обращаетесь к корню API, сервер должен отдать всю структуру API, фактически -- документацию. Но реализации такого почти не встречается.

3.3. Версионирование. Тут понятно: у вас может быть несколько версий API, и клиент может пользоваться только какой-то конкретной. Варианта два — добавляем версию в URL: /v2/user или в кастомный заголовок типа X-API-VERSION или похожий.

Вот такие уровни зрелости и правила REST. И цитата из Роя Филдинга:

A REST API should be entered with no prior knowledge beyond the initial URI and set of standardized media types that are appropriate for the intended audience. [...]
In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.

К вопросу про развитие "после senior": обнаружилась забавная история — некоторые работодатели, когда хотят написать "опытный аналитик", пишут "Бизнес-архитектор"; особенно такое название любят интеграторы.

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

Или вот:

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

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

В общем, хотите стать архитектором — просто назовите себя архитектором! Делов-то.

Придумал игру "Снежинки среди нас": новогодняя ИТ-мафия. Позволяет и развлечься, и прокачать софт-скиллы, и украсить офис к Новому году.

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

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

Заказчики (и Снежинки) побеждают, когда Команда полностью разобрана (результат работы им достаётся бесплатно + неустойка).

Пока на практике играть не пробовал, но должно быть весело!

Практически на каждом Летнем аналитическом фестивале умудрённые опытом аналитики жаловалась, что для них мало докладов, а всё в основном для начинающих и миддлов. И вот, наконец, организаторы решили сделать отдельное событие для опытных системных аналитиков! Причём зимой. Меня пригласили в качестве председателя программного комитета, что очень лестно. Я ещё помню, как 10 лет назад выступал на ЛАФ, и это было чуть ли не первое выступление моё на отраслевой конференции вообще.

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

🎙 Итак, идея Зимних аналитических выходных 2024 — настоящее и будущее индустрии системного анализа. Кроме традиционных докладов и мастер-классов мы запланировали сессии совместного выявления основных трендов и требований к самим задачам системного анализа, к людям, которые работают в этой сфере, и к подразделениям, выполняющим эту роль в компании.
В течение 2 дней на площадках мероприятия пройдет более 20 докладов, мастер-классов, круглых столов и деловых игр от топовых экспертов, основателей сообществ аналитиков, авторов профессиональных стандартов и карт компетенций, руководителей направлений СА.

📆 Даты: 17-18 февраля 2024 года.

🏨 По традиции ЛАФ, это загородный отель, проживание по системе "все включено", зимние развлечения, бассейн, скалодром и всё такое. И afterparty с музыкой и общением 🎉.

Мы уже собрали звездный пул спикеров, но программа ещё будет пополняться. Регистрация уже открыта: участвуйте в самом ярком аналитическом событии зимы! 🚀❄️

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

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

Одновременно в системах ещё и слои абстракций дырявые: представление данных для пользователя не отделено от способов хранения данных, а логика вообще размазана по всем слоям.

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

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

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

Ergo, если мы имеем чистую архитектуру, low coupling high cohesion, да ещё и единый язык бизнеса и разработки, то системные аналитики становятся ненужными. Хм, кажется, я только что сформулировал основные принципы DDD.

Аналитики! Сопротивляйтесь внедрению в своих компаниях DDD! Запутывайте архитектуру! Ломайте станки! Храните документацию в Ворде!

В крупных организациях, опять же, по моему опыту (он достаточно обширный) системный аналитик занимается тремя основными вещами:
1. Проводит сбор требований со стейкхолдеров
2. Пытается определить в каких ИС и какие изменения необходимо реализовать (это следствие бесконечно огромных протечек моделей предметных областей друг в друга, высокой привнесенной сложности)
3. Фиксирует требования и какие ИС затрагиваются в документах

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

И там на первом месте Devops (214 тыс.) , на втором — дата саентисты (202), а вот на третьем — системные аналитики (150). С чем всех коллег и поздравляю!

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

Но в целом вы теперь знаете, на что в среднем ориентироваться.

А вот ещё интересный взгляд на роль аналитика (и архитектора) с точки зрения Теории ограничений (TOC) Голдратта. Если у вас разработка является ограничением, логично перед ней ставить звено предобработки, чтобы на вход подавать не сырье, а заготовку. (Помним, что Голдратт в основном анализировал материальные производства).

Как вам кажется, похоже это на работу аналитика? Не постановка задачи, а предобработка, подготовка материала для работы, создание заготовок.

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

Про Винcтона Ройса, Agile и разработку программного обеспечения.

На заре индустрии разработки программного обеспечения был хороший доклад Винстона Ройса (Winston Royce 1970) про то, как БЫСТРЕЕ выводить программный продукт в эксплуатацию. Так, как основная проблема отрасли это... ОШИБКИ!

Ключевая мысль доклада: Пиши БОЛЬШЕ документов, чтобы БЫСТРЕЕ выводить программный продукт в эксплуатацию.

И тут стоит понимать, что в 1970 году, время от Идеи до осязаемого Результата - минимум 1 неделя, просто потому что технологии такие.

И тут на курсе (который сейчас провожу), при разборе применения Теории Ограничений коллеги заметили что, на самом деле Ройс решал проблему ЗАЩИТЫ ОГРАНИЧЕНИЯ!

То есть:

Пиши много документов для того, чтобы..... ЗАЩИТИТЬ ОГРАНИЧЕНИЕ!
Где Ограничение - машинное время ЭВМ.

Другими словами, это шаг "три" из пяти фокусирующих шагов ТОС.

Отсюда вывод:

Если у вас разработчики - это Ограничение, то им нужны Аналитики и Архитекторы, как "цех заготовки". Чтобы разработчики делали то, что нужно сделать и не делали то, что не нужно делать. И была "полная комплектация" перед началом работы по задаче.

#ответы_на_вопросы #TOC