#оффтоп

- У нас в компании Event Driven Architecture
- Помойка сообщений в одной очереди?
- Все так

#продуктовое
Пока копал тему хорошего UX для чекаутов и форм оплат, нашел ресурс с кучей классных гайдов по построению UX в ecommerce и около.

Утащил себе несколько для работы:
• Проблемы и лучшие практики для формы оплаты картой
• Обзор форм оплаты маркетплейсов на мобилках
• Пейволлы в мобильных приложениях: часть 1 и часть 2
• Офрмление доставки на чекауте

#конференции
Во понедельник-вторник пройдет оффлайн часть FlowConf, где буду вещать про кафку и ее устройство. Действо в формате воркшопа, будем говорить, рисовать и думать, почему оно все так устроено. Приходите, говорящей головы будет минимум.
Ах да, записи не будет.

И вообще, кто еще пойдет на Flow?

Не люблю все эти блохерские истории с партнерскими постами, но тут не могу пройти мимо. Тем более, сам читаю периодически.

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

Плюс регулярно появляются приятные полезняшки. Например, я себе утащил:

• Классная подборка открытых API на любой вкус и цвет: REST-like, GraphQL, WebSockets, JSON-RPC, etc.

• Материалы по нефункциональным требованиям - как бы аналитики не сопротивлялись

• Интересно и просто о балансировке

• Подборка по БД и SQL - от первого знакомства до глубокого погружения

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

#архитектура

Много букв про НФТ
Глубокая статья Евгения Скорикова о нефункциональных требованиях атрибутах качества системы.
Автор предлагает методику проработки и обеспечения качества системы с большим набором примеров. Но интересно другое, через всю статью проходит две важные мысли:

1. Реальные значения технических метрик, которые мы ждем от системы, исходят из нужд бизнеса/продукт

2. Сами по себе нефункциональные требования не имеют смысла, если мы не понимаем, как они будет обеспечены на уровне системы

Если проще, то выявление и обеспечение НФТ - это непрерывный поиск компромиссов между “продуктом” и “техникой”.

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

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

И это все еще нужно уметь оценить по сложности разработки и стоимости.

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

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

Становится понятно, почему аналитики так неохотно думают про НФТ.
У подавляющего большинства нет кругозора и практического опыта работы с “глубокой техникой”. Редкий аналитик погружается дальше вопросов интеграции и хранилищ данных. При этом оценка и обоснование НФТ с бизнесовой точки зрения - это исследовательский и трудноформализуемый процесс, который не слишком укладывается в массовый интерес к архитектуре. Мне он во многом напоминает процесс исследования рынка - такой же неопределенный и творческий.

Морали здесь не будет. Рекомендую медленно и вдумчиво прочитать статью.
А еще видосик про оценку некоторых технических метрик.

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

Less is more

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

Гораздо проще добавить на проект человека, чем найти проблему в коммуникации и, наоборот, удалить парочку лишних. К тому же не придётся принимать дополнительную ответственность — попробуй объяснить бизнесу, что команда из 5 человек работает быстрее, чем команда из 8.

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

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

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

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

Есть кто на TeamLead Conf?
Заглядывайте на чаек

#ненависть #оффтоп
Величайшее изобретение человечества в IT - это годовые премии.
Под конец каждого отчетного периода просыпаются манагеры и бросаются усиленно изучать свои OKR и KPI, чтобы на хлебушек было что намазать. И начинается безудержное новогоднее веселье: здесь нужно срезать скоуп и запилить невнятный MVP на 10 человек, там напихать костылей в надежде когда-нибудь это отрефакторить, запустить сервис без мониторинга и адекватной инфры, а критичные процессы оставить на ручном приводе. Пей, релизь, молись.

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

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

Прекрасное про стили организации работы и времени.

- У вас есть планы на 5, 10 лет? Кем вы видите себя через это время?
- Идите нафиг со своим планированием. Оно мне всю радость жизни портит.

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

И это нормально, Карл!

Нужно сделать лишь одну вещь:

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

2. Представителям хаоса принять свою природу, и перестать себя мучать успехосоветами и магиями утра, максимально делегировать рутину и создать вокруг себя подходящую среду для работы.

Познай себя, “человек-иррационал”.

Я несколько раз писал, что аналитик не может всерьез выбирать технологии интеграции, в том числе из-за нехватки знаний о сетях.

Поэтому держите небольшую шпаргалку-введение в работу и устройство сетей. Если интересно занырнуть глубже HTTP, но не готовы к Таненбауму.

Еще у подолдки интересные подкасты были:
https://podlodka.io/239 - часть 1, про интернет
https://podlodka.io/249 - часть 2, больше про железо

#манагерское

О вечном противостоянии «бизнеса» и «техники»

За счет того, что в каждом из отделов совершенно разная культура, люди начинают самоидентифицироваться не как сотрудники всей компании, а как сотрудники «последнего оплота „нормальности”» в компании — в то время как «эти раздолбаи из соседнего отдела» неделями двигают свои маленькие задачки / вкидывают в бэклог какой-то непоследовательный бред (ненужное зачеркнуть)

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

https://systemdesign.one/consistency-patterns/

#архитектура
System Design. Основы проектирования высоконагруженных систем
Два года назад мы попробовали запустить большой курс по архитектуре, но звезды оказались против. В этот раз решили двигаться мелкими шагами и подготовили двухдневный тренинг по проектированию системной архитектуры или System Design, как это модно сейчас называть.

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

Как это будет:
⁃ Делимся на три команды, каждая из которых проектирует свой микросеврис
⁃ Определяем требования к системе и ключевые метрики
⁃ Проектируем API, модель данных, выбираем тип хранилища, способы масштабирования, инфраструктурные элементы
⁃ Интегрируем сервисы команд, чтобы получить цельную систему

Соотношение теории и практики примерно 50/50.

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

Кого ждем:
⁃ Опытных системных аналитиков
⁃ Разработчкиов
⁃ Технических менеджеров

📆 Встречаемся 3 и 4 февраля в 10:00 - 14:00 мск

🔗 Регаемся тут

Don't worry about what is or isn't REST; focus on building pragmatic, useful APIs.

Статья о практических нюансах проектирования REST-like API. Есть моменты, где можно похоливарить, но всяко лучше чем очередная дискуссия “Как правильно делать REST API”.

Например, почему:
• не стоит везде использовать вложенные ресурсы
• не стоит использовать map-структуры
• не стоит возвращать 404, если ресурс не найден - интересный кейс внутри, посмотрите обязательно
• id лучше дополнять префиксом-указателем на тип сущности и представлять в виде стрингов

#API

Архитектурная подборка для тех, кто еще умеет читать книги.

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

#архитектура

Архитектурная зарисовка на тему проектирования процесса обработки платежей для абстрактного цифрового сервиса. Нужен VPN

#архитектура

Верните анализ в аналитиков

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

Спроектировать API или схему БД - это пожалуйста, порассуждать о выборе способа интеграции и особенностях NoSQL хранилищ - с удовольствием, поговорить про Rabbit vs Kafka - тоже можно.

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

Допустим, каждый сисаналитик мечтает стать архитектором. Посмотрим, какие темы регулярно обсуждают в архитектурном комьюнити: моделирование предметной области, business needs, event storming, атрибуты качества и не только. Т.е. в среде архитекторов и техлидов есть четкое понимание, что проектировать системы без понимания бизнес контекста невозможно.

Что называю бизнес-контекстом:
1. Общий контекст системы: с какими внутренними и внешними сервисами взаимодействуем, какие пользователи работают с системой. Поможет контекстная диаграмма или первый уровень C4

2. Процессы, в которых участвует система. Без понимания не сможем спроектировать адекватный UX, схему интеграций и внутреннюю архитектуру. Формат особого значения не имеет: классические BPMN-eEPC-UML, CJM и Service Blueprints, продукты Event Storming’а или стрелочки-квадратики.

3. Модель предметной области, чтобы понимать, какими бизнес-сущностями мы оперируем, и какие связи между ними существуют. Здесь на вкус и цвет: концептуальная ERD, вариации на тему контекстов DDD или декомпозиция в стиле ООП. Я обычно использую концептуальную ERD дополненную отношениями использования.

4. Ключевые бизнес-метрики, продуктовые метрики, атрибуты качества, внешние и внутренние ограничения - все что принято называть НФТ.

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

Как видят BPMN начинающие аналитики

#конфа

Flow. Spring 2024
Во вторник провел на воркшоп о влиянии НФТ на выбор технологий интеграции. Судя по отзывам участников, получилось хорошо, но совсем не так, как планировал.

Дополнительные материалы, которые обещал
Модель зрелости REST-сервисов https://martinfowler.com/articles/richardsonMaturityModel.html

Спецификация JSON-RPC 2.0 https://www.jsonrpc.org
Инструмент для документирования JSON-RPC https://news.1rj.ru/str/another_sa/78

Краткий обзор GraphQL с хорошими ссылками: https://habr.com/ru/post/326986/
Стрим об особенностях использования GraphQL: https://youtu.be/gfSYKLo0P5E?si=4OluWLZVg61ACAA1

Просто о Websockets: https://mcs.mail.ru/blog/websocket-kogda-sleduet-ispolzovat-i-preimushhestva
Сравнение WebSockets и gRPC: https://dev.by/blogs/godel-technologies-europe/articles/skaz-o-tom-kak-razbiralsya-v-grpc-i-websocket

Большая база материалов по интеграции систем: https://systems.wiki/integration

Сравнение REST и RPC стилей API
В защиту REST: https://habr.com/ru/post/476576
В защиту JSON-RPC: https://habr.com/en/post/441854
Стрим REST vs RPC https://youtu.be/JS96oEB4bWc?si=6TaOXjq1K96r3P-z