#анализ #манагерское

Почему системный аналитик в компании - это bad smell?

https://youtu.be/__CS7ogpMks
Конспект писать не буду, но пару мыслей из обсуждения хочу вынести:

⁃ Системным аналитиком называем роль, которая занимается техническим дизайном (проектированием API, БД, UI, внутренней логики приложений), проработкой пользовательских требований (user story, пользовательские сценарии и т.п.) и выполняет кучу других функций, которые получится на него повесить.
⁃ Залезать в техдизайн СА не стоит, т.к. для этого нужны технические компетенции уровня разработчика с 5-10 годами опыта.
⁃ Работа с пользовательскими требованиями - это функции product owner/manager’а. Можно похоливарить на тему, почему относим эти функции продукту, но сейчас это распространенная трактовка.
⁃ При этом работа СА на интеграционных задачах вполне допустима, т.к. здесь аналитик выступает как архитектор решений на минималках, что не требует глубокого погружения в технику.
⁃ Если в разработки продукта есть выделенный СА, то это указывает на проблемы в процессах команды или компании. В частности, в коммуникациях между разработкой и бизнесом. При этом налаживать процессы может оказаться сложнее или дороже, чем привлечь СА.
⁃ По опыту Филиппа 2/3 разработчиков способны и готовы коммуницировать с бизнесом и погружаться в предметную область, если у них есть возможность.

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

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

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

Монументальная подборка материалов от архитектора для будущих архитекторов

https://t.me/bpmn2ru/668

#интеграция #очереди

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

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

Здесь рассматривают реализацию с помощью кафки, в начале статьи общее описание идеи со схемками:
https://callistaenterprise.se/blogg/teknik/2018/10/26/synchronous-request-reply-over-kafka/

Может пора доклад запилить на тему?

#интеграция #очереди
Две статьи, чтобы сформировать общее понимание, что такое Kafka, и чем она отличается от других брокеров.

Совсем просто с картинками и выдрами:
https://habr.com/ru/post/563582/

Чуть глубже уже на техническом языке:
https://habr.com/ru/company/vivid_money/blog/534858

#хантинг
Минутка хантинга на нашем канале.

Ищу в команду сильного бизнес аналитика, который хочет решать проблемы бизнеса. Мы FoodTech проект, который занимается быстрой доставкой продуктов для американского рынка. Это как Вкусвилл, Я.Лавка и Самокат, только на другой стороне океана.

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

Наши пожелания:
⁃ Самое важное - это стремление находить и предлагать решения бизнес-задач, а не записывать под диктовку со слов бизнеса
⁃ Мы используем Camunda для автоматизации процессов, поэтому полезно знать BPMN, либо быть готовым подружиться с ним

Если интересно, пишите в личку @and_burakov, расскажу все, что интересно.

#архитектура
Александр Поломодов из Тинькова начал публиковать вводный курс по архитектуре.
https://apolomodov.medium.com/essential-arch-course-intro-693682064cd6

На данные момент доступны 2/5 статей:
• Лекция про архитектуру и архитектора
• Лекция про код
• Лекция про данные
• Лекция про архитектурные стили и распределенные системы
• Лекция про распределенный архитектурный процесс и роль архитектора в нем

#интеграция #REST #API

Завершил священный поход на тему REST. Что в итоге получилось:
https://t.me/another_sa/57 - небольшая заметка, с которой все началось
https://youtu.be/DB2SER51mcU - запись вебинара на тему
https://systems.education/what-is-rest - конспект на основе вебинара

#API #интеграция

OpenRPC
При работе с JSON-RPC API становится больно, когда нужно его как-то задокументировать. В сваггере это делать жутко неудобно, ибо приходится засовывать все методы API под один эндпоинт и использовать вложенные anyOf. Резко теряется информативность и польза от визуализации. Да и не всегда мы используем http как транспорт. Как альтернатива неплохо заходит JSON-Schema, но она позволяет определить только структуру сообщений, а не методы API.

В поисках счастья нашел OpenRPC - детище ребят из эфира, которые решили запилить аналог сваггера для JSON-RPC.
Что внутри:
⁃ https://spec.open-rpc.org - схема для описания JSON-RPC API, предельно похожа на сваггер, только проще. Если писать ручками, то перейти будет довольно просто.
⁃ https://playground.open-rpc.org - удобный редактор, который красиво визуализирует схем и позволяет вызывать реальные сервисы.

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

#API #интеграция

JSON-RPC
Раз уж в комментах спрашивают, то пусть будет и здесь.
Статья для быстрого знакомства с JSON-RPC, плюс его сравнение с REST-like подходом:
https://habr.com/en/post/441854/

Официальное описание стандарта: https://www.jsonrpc.org

#анализ

Наконец-то, кто-то написал, кем является бизнес-аналитик на самом деле, и чем он занимается:
“Таким образом аналитик в такой компании-подрядчике анализирует не бизнес, и даже не процессы, а запросы клиента на автоматизацию отдельных участков бизнеса”.

Кстати, это одна из причин, почему я стараюсь избегать разделения системных и бизнес аналитиков в работе.
https://beskov.medium.com/lies-statistics-and-ba-in-it-1bd10484a706

#анализ

Обычно рассказы о НФТ повествуют нам о 100500 видов требований, но редко отвечают на вопрос, как добыть конкретные значения. Да еще чтобы они были связаны с реальностью, а не спустились с потолка.

В докладе Сергей предлагает несколько практических способов расчета НФТ:
⁃ что можно добыть в гугле
⁃ как оценить требования к производительности системы
⁃ элементарная статистика, и чем она полезна при расчетах

Имхо, один из лучших докладов на эту тему
https://youtu.be/x0E0DrE5Fmo

#интеграция #API

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

⁃ версионирование апи и согласование релизов
⁃ разделение логики между бэкендом и мобильным фронтом
⁃ влияние качества связи на логику взаимодействий
⁃ передача чувствительных данных по открытым каналам

https://habr.com/ru/company/yandex/blog/583332/

#анализ #манагерское

Интересный подкаст о проблемах разработки. Редко можно услышать, как представители итшечки критикуют позицию своих собратьев в битве IT vs Бизнес
https://open.spotify.com/episode/6zJuQT6xCEYB7ggNYl1MGx?si=8_Q4fkzgT_C09v-4NVfpuA

Особенно откликнулась мысль о типичной позиции разработчика по отношению к бизнесу: “Я умный, а они все там идиоты, зачем с ними разговаривать?” Часто это сопровождается убежденностью в том, что “вот мы бы маркетинг-продукт-процессы сделали нормально, если б только захотели-могли”.

В этом году удалось пообщаться с четырьмя командами/компаниями, где решили создать выделенную роль системного аналитика. В трех из них мотивация была в духе: “Хотим как-то оградить разработчиков от того бреда, который несет бизнес, когда просит запилить очередную хрень”. Не буду гдадать, на сколько силный антагонизм между ит и бизнесом у этих ребят, но история вполне обыденная.

Думаю, это тот самый кейс, когда системные аналитики - это костыль, которым пытаются полечить проблемы процессов и коммуникаций в компании. Нечто подобное обсуждали с Филиппом в эфире Почему системный аналитик в компании - это bad smell?
Возможно, именно это пытались лечить скрамы и прочие аджайлы, вводя в единую команду разрабов, продуктов и бизнес-экспертов.

К чему все это? Аналитик, если ты связываешь бизнес и разработку, помогая им понять друг друга - далеко не всегда это повод для гордости.
*Не относится к заказной разработке.

#процессы #нотации
Я не очень большой фанат bpmn, поэтому не мог пропустить статью о границах его применимости.

https://bpmn2.ru/blog/5-nepravilnix-sposobov-ispolzovat-bpmn

#процессы #нотации
После прошлого поста случилась небольшая дискуссия на тему: “Если не BPMN, то что?”

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

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

Про очереди: https://mcs.mail.ru/blog/zachem-nuzhny-ocheredi-soobshcheniy-v-mikroservisnoy-arkhitekture
Про Rabbit и Kafka: https://mcs.mail.ru/blog/rabbitmq-ili-apache-kafka

Тут в среду что-то новогоднее архитектурное dddшное намечается. Даже шанс есть вживую попасть.

https://t.me/dddevotion/234

#интеграция
Попытка разработать простой алгоритм выбора между:
- REST API
- GraphQL
- gRPC
- JSON-RPC

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

https://levelup.gitconnected.com/rest-and-the-future-of-apis-ef9cf4e1706b

#манагерское
Мне тут поведали, что у Филиппа вышла статья о bad smell в процессах. Не буду ничего цитировать, имхо мастрид для лидов, манагеров и всех сочувствующих. Там же ссыль на видео доклада.

https://habr.com/ru/company/oleg-bunin/blog/598925/

Мой год только начинается, надеюсь, и вас салатики уже отпустили. Нам повезло работать в крайне неоднозначной, быстроизменяющейся и востребованной индустрии. Желаю всем нам в этом году:

⁃ иметь работу, в ценность и значимость которой мы искренне верим

⁃ работать с людьми, которые останутся с нами много лет после смены компании

⁃ критически относиться к существующим подходам и убеждениям, особенно своим

⁃ быть открытыми для новых идей и изменений, пробовать и экспериментировать

⁃ забыть о существовании work-life balance и выкрутить его на life = 100, work = 100

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

#коммуникации #мышление
Гипотеза от Дорофеева. Возможно, люди собирают 100500 встреч потому, что им некогда (или не могут) осмыслять задачи и проблемы. А когда человек говорит, он вынужден думать. Поэтому нет смысла отправлять его в почту или чат - так он увеличит количество инфопотоков, которые не сможет осмыслить без встреч.
https://youtu.be/ScU1ymhjbxQ

На счет чатов соглашусь
https://t.me/another_sa/37

А вот мышление письмом все еще считаю одним из величайших изобретений человечества
https://t.me/another_sa/42