Вдогонку к посту про неопределенность. Кажется, я понял. Это же не неопределенность. Это неизвестность!

Это не неуверенность, не неоднозначность, не нечеткость. Это просто неизвестность.

Аналитик уменьшает неизвестность. Когда неизвестно, что делать. И это сразу нас приводит к фреймворку Cynefin, помните — про какую проблему идёт речь — понятную, сложную, комплексную или хаотичную. Там в середине как раз "неопределенная".

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

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

Так вот Cynefin Framework — он весь про знания, и сначала "понятные" и "сложные" назывались "известными" и "познаваемыми".

Мне всегда хочется чего-то более сложного, чем матрица 2х2, и вот [специально для таких, как я] Сноуден год назад опубликовал расширенную версию, "матрицу неопределенности", чисто про знания. Теперь всё понятно — тут две шкалы: эпистемологическая, то есть — что нам известно про проблему, и онтологическая, то есть — какова сама проблема по сути.

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

Вот это уже больше похоже на истинную картину.

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

Команда ЛАФ, оказывается, выложила запись моего доклада про историю и использование UML: https://rutube.ru/video/17ecbc3498379f11ab1c1ddacd8b6762/

С одной стороны, там результаты исследования современного применения UML (теперь мы документально знаем, что Sequence Diagram на первом месте, но и кроме неё кое-что применяется).

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

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

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

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

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

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


С точки зрения инструментов визуализации (и проектирования через визуализацию) — обещанные в фантастических фильмах и книгах 3D-модели как-то не прижились. Хотя вот Fanсade выглядит интересно, детям после Майнкрафта хорошо заходит, лучше чем Scratch.

В общем, пока у меня не складывается картинка, что может прийти на смену UML (или C4) в качестве "чертежей" для программных систем, и нужно ли это. Но, по ощущениям, что-то зреет — между SADT и UML прошло примерно 25-30 лет, от создания UML — 30, пора чему-то новому появиться.

Заманили меня поговорить про карьеру, в четверг вечером, если интересно — присоединяйтесь к трансляции!

Ну а если не хотите ждать — можно прямо тут о чём-нибудь спросить, в комментариях к этому посту.

Кем мы станем когда вырастем? С Юрием Куприяновым

Долгожданный гость в нашей рубрике Юра Куприянов - автор канала Системный сдвиг, лучших докладов на Analyst days, ЛАФ, Flow.

С Юрой поговорим о профессии системного аналитика: его прошлом, настоящем и будущем.

📒 Какие навыки и знания нужны, чтобы быть системным аналитиком?

💸 Зачем компаниям нужны системные аналитики? И что это за компании?

💻 Реально ли системному аналитику стать разработчиком, архитектором? И что для этого нужно?

Наконец, мы узнаем, а кем станет сам Юра, когда вырастет?

📅 Когда: 6 февраля в 18:30
🔗 Где: онлайн, ссылка на регистрацию

Стоит ли оно того?

Прекрасную картинку нашел и перевел для вас! https://xkcd.com/1205/

Каждому автоматизатору процессов нужно повесить над столом — сколько времени вы можете потратить на оптимизацию/автоматизацию задачи, чтобы это оправдало себя хотя бы за пять лет?

Если вы выполняете задачу раз в неделю, а ускорить её сможете на 6 часов — то целых 2 месяца! А если раз в месяц, а ускорить получится только на час — не больше двух дней.

Что выбирать для автоматизации? Задачи, лежащие слева внизу: частые и которые получится ускорить на минуты и часы.

UPD.: В реальности, правда, скорее выйдет так: https://xkcd.ru/1319/

Сделал шпаргалку по структуре HTTP-запроса:

Что где может находиться и что куда помещать при проектировании API?

Куда положить версию API? Как сконструировать путь? Какие предусмотреть параметры запроса? Для чего использовать заголовки?

Вопросы спорные, потому что в разных API и стайл-гайдах их решают очень по-разному, и единства мнений нет (а есть, наоборот, священные войны за то, как правильно и что соответствует RESTу!)

В любом случае — все эти вопросы должны быть поставлены, по ним приняты решения и всё это внесено в документацию к API!

Планы на февраль и март. На повестке — два (или даже три) мощных мероприятия:

Во-первых, в этом году мы уже во второй раз проводим WAW — Winter Analytical Weekend (и я там опять председатель программного комитета). Темы конференции этого года — искусственный интеллект (и его практическое применение в системном и бизнес-анализе), люди — потому что не ИИ единым, всё-таки, пока мы работаем людьми и с людьми, и практики системного анализа — а как, собственно, работать лучше.

Мы хотим сделать это событие не просто конференцией, а скорее серией мастер-классов (хотя доклады тоже будут), а главное, как и в прошлом году — самой ламповой тусовкой для всех системных и бизнес-аналитиков, как это было на первых ЛАФ-ах.

В общем, если у вас есть время 22-23 февраля и вы можете приехать в Подмосковье — буду рад вас всех видеть! Ну и приходите в личку за промокодом (10%).

Во-вторых, 27 стартует первый в этом году очный тренинг по интеграции систем — "Интеграция систем. Разработка требований и основы проектирования". Если вы хотите за три дня интенсивно погрузиться в тему интеграций (и разобрать всё, что нарисовано на этом плакате и ещё примерно столько же) — приходите, будет круто и практично.

Ну а потом уже в марте (20-22) будет курс про разработку требований, там прокапываем основы, самую суть системного анализа.

Такие планы.

Про RPS и стоимость ресурсов.

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

Я нашел у Gitlab хорошую табличку с разными вариантами нагрузки и разной стоимостью. (Gitlab — это сервер для системы управления версиями git, типа Github — но ваш персональный).

Итак, во-первых — какая нагрузка? RPS — requests per second, число запросов в секунду. У Gitlab она измерена эмпирически, на этапе требований можно предположить её из понимания частоты выполнения процессов. Минимальная конфигурация — 20 RPS, до 1000 пользователей. Считаются и автоматические вызовы, и пользовательские: 20 вызовов API/сек, 2 RPS через web, 2 git push, 2 git pull. Как можно посчитать — ну сколько программисты делают пуллов и пушей? Штук 20 макс.? Значит, 20000/8 (рабочих часов)/60 — где-то 40 в минуту получаем, с запасом, в пике (например, в конце рабочего дня, когда все побежали пушить изменения за день) — как раз можно рассчитывать на 120 в минут, или 2 RPS.

Впрочем, нас здесь интересует ограничение сверху, т.к. это минимальная конфигурация, которая может жить на одной виртуальной машине. Это, правда, довольно здоровенная машина: 8 vCPU, 16 GB memory, но всё-таки одна. То есть это — верхний предел вертикального масштабирования. Туда помещается все элементы архитектуры Gitlab — приложение на Ruby on Rails, Sidekiq — сервис для фоновых задач, Redis для кэширования, PostgreSQL, Gitaly — RPC сервис для выполнения команд git, и, собственно, локальное хранилище текстов программ.

Следующие конфигурации уже используют размещение всех компонент на отдельных машинах, этим объясняется резкий скачок стоимости. Ну и дальше наращивается просто количество единиц одинаковых компонент:
— при росте до 40RPS и 2000 пользователей — два экземпляра веб-приложения + балансировщик;
— при 60RPS и 3000 пользователях — три веб-приложения, два Sidekiq, три Redis, три Gitaly, кластер из трёх PostgreSQL. Соответственно, всё это требует обвзяки из внешних и внутренних балансировщиков, мониторинга и service discovery. На этом этапе также можно обеспечить High Availability, то есть вы можете заявлять доступность выше 99%. Можно оценить, во сколько это выражается в деньгах.

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

Поэтому, на практике, мы, как аналитики, должны сделать две вещи:

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

2. Узнать — как бизнес (и система вслед за ним) собирается расти. При этом страшнее не планы бизнеса "привлечь 100500 новых клиентов", они обычно не сбываются; страшнее слова "мы хотим распространить этот сервис" — на всех клиентов, на все регионы, на другие операции и т.п., то есть туда, где эти пользователи или эти операции в таком объеме уже сейчас есть. Вот это можно включить в требования, чтобы архитекторы смогли заложить в архитектуру.

Отличная картинка в начале рабочей недели — как архитектура выглядит на самом деле, и как в неё реально вмещается бизнес-логика.

Автор явно хорошо знает предмет и проблематику:

— от безопасности сразу отрезали треть — потому что с ней никакая бизнес-логика нормально не работает;

— зато на место безопасности приехали данные, и теперь они размазаны по системе;

— туда же въехал кусок UX, а весь UX повернули набок (чтобы не сказать "повертели");

— ну и API треснуло и готово развалиться, и стык с бизнес-логикой не очень-то гладкий (то же можно сказать и про стык данных и UX, там вообще рваное взаимодействие).

Ну и всё это не помогает, конечно же.

Валидация в системном анализе.

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

С таким разбросом тем нужно обязательно смотреть в смежные области, для которых этот объект является основным.

Например, психология. Мы обшаемся с людьми, и нам хорошо бы знать, как люди устроены. А часто бывает, что мы общаемся с людьми, испытывающими какие-то проблемы (обычно — рабочие, но бывает по-разному).

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

В психологии валидация — это про другое. Это про признание опыта другого человека как валидного, имеющего право на существование.

К сожалению, в процессе интервью и обсуждений я очень часто вижу, как одни люди отрицают опыт и ощущения других людей. Вы не можете так себя чувствовать, это с вами что-то не так! [а не с нашими процессами или системами]

Вы не можете так оценивать свой опыт или иметь такие суждения, потому что вы ошибаетесь! [потому что я считаю по-другому].

Обратите внимание — речь не про обсуждение ошибки, а про запрет думать то, что ты думаешь и чувствовать то, что чувствуешь.

Не надо так. У человека есть повод думать и чувствовать. Сначала дайте ему это чувствовать, провалидируйте, разрешите ему так думать и так считать. Признайте, что это нормально. Ошибки будете потом исправлять.

У психологов есть инструкции с несколькими шагами валидации, они могут быть полезны при интервью с заказчиками и пользователями:
1. Присутствие. Будьте здесь на 100%. Не в телефоне, не в блокноте с записями, не за экраном.
2. Отражение. Я могу понять и не осуждаю.
3. Догадка. Мне не все равно, я пытаюсь понять, что происходит.
4. Контекст. Я признаю, что действительно есть повод так думать или так действовать.
5. Нормализация. Это нормально (хотя я, возможно, не согласен, но не отрицаю, что такая позиция в принципе может быть).
6. Уважение. Я не смотрю сверху-вниз и помогаю, а не пинаю и критикую.

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

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

Коллеги выложили запись интервью. На самом деле, мы потом ещё полчаса сидели не под запись. Нужно уже к форматам Дудя переходить: есть о чем поговорить на 3-4 часа 😂

🎞Делимся записью карьерного диалога с Юрием Куприяновым.

С Юрой порассуждали о профессии системного аналитика:
▪️зачем нужны аналитики и как объяснить их необходимость руководству,
▪️как можно в себе развить системность и абстрактное мышление,
▪️как развитие ИИ влияет на ИТ и нашу профессию,
▪️почему аналитики хотят в архитекторы,
▪️в какие стороны можно еще посмотреть.

Очень хочется продолжить в формате дискуссии, а не интервью, т.к.вопросов осталось еще на пару-тройку встреч.

На встрече не спросили, но в чате Юра написал о 3-х книгах, которые на него повлияли:
✅Мифический человеко-месяц Брукса
✅Руководство по UI дизайну для программистов Спольски
✅Современные методы описания функциональных требований к системам Коберна про юзкейсы. Перевод названия неудачный, на самом деле она называется Writing Effective Use Cases