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

Вторая скучная тема — НФТ, нефункциональные требования. Они связаны и понятным образом опираются на физические ограничения. Но это такая техника, не хочется с этим разбираться. Ещё традиционно нелюбимые темы — безопасность и мониторинг. Зато самая востребованная тема среди аналитиков — архитектура и микросервисы! Очень все хотят про это знать. Вот ведь парадокс.

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

1) Сеть и её компоненты никогда не падают
2) Задержек при передачи по сети не существует
3) Ширина канала бесконечна
4) Сеть абсолютно безопасна
5) Топология сети никогда не меняется
6) Есть только один администратор
7) Расходов на передачу информации не существует
8) Сеть гомогенна (все устройства в сети одинаковы)

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

Продолжая тему про распределенные системы: очень частый запрос — распил монолита на микросервисы. Все занимаются распилом! Коллеги по школе организуют вебинар с разбором распила монолита с точки зрения организации БД.

Еее! 2000 подписчиков на канале! Спасибо, друзья! 🎉🍾🏅


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

В опросе многие отметили, что хотят больше материалов по архитектуре. Принял к сведению!

А вот вам пока воркшоп сразу по трем темам, имеющим отношение к архитектуре: проектирование структур данных в реляционных и нереляционных БД, языки запросов у ним и микросервисы!

Давно искал такую шпаргалку. И для себя, и участникам тренингов показывать. Например, после выделения сервисов в Event Storming, чтобы принять предварительные архитектурные решения. Правда, говорят, правую часть можно смело заменить на Postgres, Postgres, Postgres,..., Mongo, Elastic, FileStorage, и на этом успокоиться :)

Завершил сегодня очередной поток курса "Основы проектирования интеграций ИТ-систем", понял, что одно из самых важных умений, которым мы учим — способность аналитика понимать фразы типа:

"Решение на основе семантики «at most once» с использованием мультипроцессингового пула в условиях неидемпотентности запросов и возможности организации обратной связи между консюмером и продюсером даёт следующие возможности: <...>“

— и не просто понимать, а уметь эти решения обсуждать и оценивать. То есть, фактически, переходить от systems analysis к systems design.

Очень интересно, насколько часто возникает вопрос про сравнение REST, SOAP, GraphQL, gRPC и лучший выбор одного или другого в конкретных условиях. При этом REST — это архитектурный стиль или набор принципов, SOAP — стандартизированный протокол, GraphQL — язык запросов, а gRPC — программный фреймворк :))

Вопрос получается типа: "что лучше выбрать для работы: Agile Manifesto, ГОСТ 34, Jira или UML?" 🤦🏼‍♂️

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

Интересная картинка сравнения возможностей проприетарных и открытых моделей. По кодингу и умениям делать выводы GPT-4 пока впереди, а вот по написанию "просто текстов" и по гуманитарным вопросам Викуна уже практически сравнялась.

Ну и собственно самое главное.

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

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

Ну и минорное - авторы выпустили новые модели Vicuna v1.3 размерами от 7 до 33 миллиардов параметров. Веса забирать здесь.

ProductSense и Нетология выпустили очередное исследование про менеджеров продуктов, а так как я как раз он, любопытно было взглянуть на коллег и настроения в отрасли. Из интересного: 37 человек (из 1121) таки назвали себя Technical Product Manager, я уж думал их в РФ совсем нет. Вместе с Platform PM (11%) — это интересная смежная роль, куда могут переходить системные аналитики, если хотят больше влиять на развитие своих систем (в принципе, это похоже на мой карьерный путь).

Интересно, что 221 человек (20%!) сказали, что работают продактами в B2G. Не очень понимаю, они продакты сервисов для государства? То есть, их пользователи — это госслужащие и бюджетники? Или это разработчики гос.сервисов для граждан, типа, B2G2C? В любом случае, интересный процент, думал, это скорее экзотика. Мало того - чем "сеньорнее" продакт, тем больше вероятность, что он работает именно с B2G или с платформой. Типа, раз уж начали в это играть, то возьмем сразу крутых чуваков.

Интересный показатель -- размер компании. Почти половина всех продактов работает в крупных компаниях (от 1000 сотрудников, 28% — от 5000 сотрудников). Выглядит так, что в управление продуктом играют только те, кто может себе это позволить, а остальные как-то так обходятся. При этом в маленьких компаниях легче получить должность Head of Product или CPO (ну да, я в своё время просто попросил, чтобы должность называлась директор по продуктам, и так стал CPO 🤷🏼‍♂️).

По индустриям: банки, edTech, доставка еды и маркетплейсы. Именно в таком порядке! Даже не знаю, какой из этого сделать вывод. Как говорила Алиса у Кэрролла, наводит на мысли, только неясно, на какие. Ну, кроме того, что я классно выбираю отрасли: 10 лет в финтехе, и вот скоро будет 10 лет как в эдтехе, самый топ. Ну и можно представить себе, как человек берет кредит, тратит его на обучение, заказывает еду, чтобы не отрываться от просмотра видео, а потом распродает вещи, чтобы этот кредит вернуть. И идёт работать продактом, очевидно.

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

В общем, если нанимаете продактов или хотите стать продактом — рекомендую, любопытное чтение!

Если вы затрудняетесь в оценке полезности вашего документа и его уровня JBGE (Just Barely Good Enough) — воспользуйтесь формулой CRUFT[1]:

Полезность документа = C*R*U*F*T,

где
C — correct — доля корректной информации в документе,
R — read — вероятность того, что документ вообще будут читать,
U — understood — %% информации в документе, которую поймут его читатели,
F — followed — шанс, что требованиям и указаниям, содержащиеся в документе, будут следовать,
T — trusted — вероятность того, что документу будут доверять.

Если по формуле у вас получаются низкие значения, то выходит не документ, а CRUFT, то есть "хлам" в переводе.

Обратите внимание, что в формуле перемножаются вероятности, то есть ценность документа падает очень быстро (снижение каждого показателя на 20% приводит к итоговой общей ценности документа в районе 32%).

Для оценки корректности и полноты требований в случае применения BRUF-подхода (Big Requirements Up Front, попытки разработки всех требований в начале проекта) можно взять 45% — средний показатель доли начальных требований, действительно реализованных в итоговом продукте (по данным Chaos Report).

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

[1] https://www.drdobbs.com/architecture-and-design/dr-dobbs-agile-modeling-newsletter/201001273

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

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

Почему-то аналитики раньше были обделены митапами. У программистов они были, у UX-еров, у тестировщиков, а у аналитиков как-то не особо.

А теперь — и сообщество созрело, и аналитиков стало больше, и задачи сложнее, и компании наконец поняли, в чем польза от аналитиков (это сейчас самая востребованная ИТ-профессия после программистов).

Ну и после пандемийного безальтернативного онлайна пошёл откат — люди хотят встречаться вживую. И начались аналитические митапы! В Москве, а теперь и в Питере — можно прийти, посмотреть на коллег, задать вопросы и обменяться опытом 🙂

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

Попробовал на одной картинке показать — на каком уровне работают разные методы групповой работы по выявлению требований и идей — Impact mapping, User story mapping, Event Storming.

Получилось похоже на водопад, но это не он. Тут скорее как в JBGE — максимум пара недель на начальное моделирование, а потом уже в цикле по итерациям, корректируя более высокие уровни. IM и ES как раз по несколько часов занимают.