Гуманный аналитик

🧠 ARC42 Quality Model: почти 200 атрибутов качества в одном месте

Открыл для себя интересный ресурс — ARC42 Quality Model.

На момент написания этого поста там собрано:

🔶 189 атрибутов качества
🔶 147 примеров формулировок
🔶 31 архитектурный подход для обеспечения качества

🕸️ В чём главная фишка?
Все эти элементы семантически связаны между собой, образуя разветвлённый граф. Такая структура отлично отражает реальность: у понятий не всегда есть строго один предок или одна причина. Это гораздо ближе к жизни, чем строгая иерархия.

Центральными узлами этого графа служат 9 так называемых измерений (в некотором смысле они пересекаются со стандартом ISO/IEC 25010):

🎯 Suitable (Пригодность)
🔒 Secure (Защищённость)
⚠️ Safe (Безопасность)
💪 Reliable (Надёжность)
🧩 Flexible (Гибкость)
⚡ Efficient (Эффективность)
🛠️ Maintainable (Ремонтопригодность)
⚙️ Operable (Эксплуатационная пригодность)
👤 Usable (Удобство использования)

Все остальные понятия модели так или иначе связаны с ними рёбрами.

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

P.S. В скобках выше я для удобства восприятия указал свой вольный перевод.

#требования #архитектура #проектирование #майндмап

⚡️ Запись к нам приходит

В комментариях к одному из постов меня спрашивали, когда будет доступна запись моего доклада на CodeFest🎙 этого года.

Глобально в моём ответе ничего не меняется: организаторы конференции будут выкладывать всё в публичный доступ в соответствии со своими планами. Однако у моих подписчиков есть возможность посмотреть выступление уже сейчас 💙.

Ссылки:
🛑Выступление 📹: здесь.
🛑Презентация 🥩: здесь.
🛑Доп.чек-лист 🎆: здесь.

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

#события #выступления #codefestru #CodeFest #требования #видео #таблицы

Здравствуй, офис! Или утренняя бухтелка 🤦‍♂️

Хотите прикол? Неделю назад на дейлике нам объявили, что мы возвращаемся в офис. Сколько дней оставят на удалёнке, было загадкой до последнего момента. В итоге остановились на гибриде 4/1 или 3/2 (кому как повезло).

Так вот, сегодня я вышел в офис спустя более чем 6 лет! За это время я успел поработать в трёх компаниях. Причём на текущей работе я был в офисе только на онбординге (менее двух недель буткемпа) и пару раз в командировках. За 4 года и месяца не наберётся! 📅

Поймите правильно, я не социофоб и не прячусь от людей и офисной кофемашины. Но терять по 2-3 часа в день на дорогу — это же невосполнимая потеря времени! А тут ещё и бонусный уровень: найди, где припарковаться в центре Новосибирска. 🚗💨

Было ли у вас нечто подобное? Напишите, пожалуйста, в комментариях! 👇

🔒 Дилемма заключённого из IT

В теории игр 🎲 есть знаменитая задача: "дилемма заключённого". Её суть проста: когда каждый участник действует только в своих интересах, не доверяя другим, результат для всех оказывается хуже, чем если бы они договорились.

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

Иллюстрацию этой мысли предлагаю рассмотреть на примере стриминговой платформы (вроде Netflix). Итак, у нас есть:

🧠 "Мозг" — единая система рекомендаций с ML-моделью внутри. Она знает, что вам предложить, но может обработать только 1000 запросов в секунду.
📺 "Лента" — главная страница с подборками фильмов.
🔎 "Поиск" — сервис, который находит фильмы по вашему запросу и заодно показывает "похожие".

За каждую из этих частей отвечает своя команда разработчиков.

В обычное время всё идёт по плану: "Лента" и "Поиск" вместе отправляют меньше 1000 запросов, и "Мозг" справляется.

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

⚖️ В чём подвох?

Команды "Поиска" и "Ленты" смотрят на свои графики и видят проблему: их сервисы тормозят, потому что ждут ответа от "Мозга". У команд есть два пути:

1⃣ Подождать. Продолжать действовать по правилу: если ответ не пришёл сразу, повторную попытку выполнить с некоторой задержкой. Этот вариант поможет снизить нагрузку, но точно не решит вопрос здесь и сейчас.
2⃣ Поторопиться. Начать повторять запросы быстрее, не откладывая повторы на потом. Это не очень честно по отношению к остальным, но так их собственный сервис будет работать шустрее и потенциально покажет результат пользователю первым.

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

🌪️ Шторм запросов

В итоге мы получаем равновесие Нэша происходит катастрофа. Вместо того чтобы успокоиться, система входит в штопор. Лавина повторных запросов от обеих команд окончательно добивает "Мозг". Он начинает массово отклонять обращения. В результате пользователи видят пустые экраны: ни в ленте, ни в поиске рекомендаций больше нет. Система легла целиком 🌟 из-за того, что её части пытались спасти себя поодиночке.

🤔 Мысли и выводы

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

Вывод: не стоит полагаться на добрую волю и координацию причастных команд, а необходимо встраивать защиту от таких сценариев в саму архитектуру. В первую очередь речь про Rate Limiter с отдельными лимитами по API-ключу. А далее уже можно смотреть в сторону приоритезации потребителей, обратного давление (Back pressure), предохранителя (Circuit Breaker) и других штуковин. 

#архитектура #проектирование #интеграции #сервисы #кейсы

😱 Про нечитаемый сиквенс

Хочу поделиться с вами историей из релизного ада ⚙️🔥.

Есть у нас система со строгим процессом: для каждого релиза нужно готовить мега-артефакт. Один из ключевых разделов — описание логики через UML-диаграмму последовательностей. Без неё никуда.

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

А главным героем нашей истории выступает согласующий эксперт. Его запрос — нужно больше золота полнота отображения всех задействованных систем и вариативности логики. Каждый раз его комментарии звучат примерно так:

А если пользователь откажется? Где эта ветка?

А почему не показан поход в сервис... за...?

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

Так мы дошли до 4-го релиза. Эксперт открывает эту огромную простыню и сокрушается, что не понимает, где посмотреть произошедшие изменения относительно прошлой версии...😵‍💫

Наш аналитик глубоко задумался и распилил всё на две отдельные диаграммы: "Существующие сценарии" и "Новые сценарии". Значительно легче не стало, но это лишь отсрочка решения.

Я вангую, что когда в 5-м или 6-м релизе изменения будут точечными (новая ветка, дополнительный вызов микросервиса и пр.), вопрос вернётся бумерангом. Ведь к тому моменту уже всё окажется внутри "Существующих сценариев", а новые правки уже будут разбросаны 🌪️ по всей диаграмме.

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

Вы сталкивались с подобным? Как разрешали противоречие между требованиями эксперта? 👇

#визуализация #uml

💡 CodeFest завершился: о чём подумалось

Основные итоги мероприятия:
🛑Торт съеден, кофе выпит
🛑Лут мерч собран
🛑Фоточки сделаны
🛑Круг общения расширен
🛑Бесконечный список книг к прочтению пополнился 

Вроде, ничего не забыл... 

А если без шуток (но мы-то знаем, что в каждой шутке есть доля шутки), то на минувших выходных ушёл на CodeFest🎙 с головой. И только сейчас выдалась возможность поделиться общими впечатлениями.


🤩 Про технологии 🤖
В какой бы области мы ни оказались — роботы, автопилоты, медицина или новые конструкции двигателей — сейчас везде важную роль играет ИИ. Он добрался и до нашей сферы: анализа и разработки. Поэтому немудрено, что ряд выступлений касался именно этой сферы. Но не ИИ единым жив человек, и приятно, что организаторы сохранили определённый баланс в программе 👍. Ведь по моим наблюдениям, некоторые организаторы конференций, следуя за модой, отталкивают часть аудитории, которой интересны традиционные вопросы архитектуры, тестирования, управления командами и т.п. 


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

Именно поэтому я не могу согласиться с мнением, что конференции себя изжили. Сидеть дома перед условным Zoom'ом, слушая доклады, конечно, удобно, но это сводит всё к механизму передачи информации по канонам "лектор-студент" (кстати, о проблеме формальной начитки,  часто не переходящей в знания, отлично говорил Максим Дорофеев 💪). Живой формат даёт энергию, эмоции и возможность просто подойти к другому участнику в перерыве, чтобы лично обсудить наболевшее. 

#события #codefestru #CodeFest

🚀 CodeFest 16: выступил! 

Недавно завершил своё выступление на тему "AS IS → TO BE: минимизируем риски перехода". 

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

Теперь делюсь впечатлениями.

Аудитория встретила выступление доброжелательно. Время на сцене для меня пролетело довольно быстро. После самой речи вопросы аудитории плавно перетекли в кулуары и ещё минут 15 обсуждали рабочие кейсы. И это здорово, значит тема нашла отклик, "зашла"! 

P.S. Пишу эти строки, уже на следующем выступлении. Решил не пропускать мастер-класс по лидерству. Ну а что, надо расти😉

#события #выступления #требования #codefestru

🔥 CodeFest 16: начало

Всем доброго сибирского утра! На площадке Экспоцентра стартовала конференция CodeFest.

В этом году, как и ранее, на CodeFest открыты двери 8 параллельно действующих залов. Однако в этот раз организаторы решили отойти от привычного деления на секции. Программа свëрстана, как говорится на официальном сайте, "вокруг инженерных и продуктово-управленческих дициплин, а также сквозных тем" 🤔

На практике это означает, что все доклады, квартирки и выступления в других форматах можно отнести к тому или иному довольно объëмному треку: "Горизонты технологий", "Технологии и фреймворки", "Базы данных", "Дизайн и пользовательский опыт" и т.д.

Моё выступление будет проходить в рамках трека "Архитектура и анализ". Этот трек оказался таким ëмким, что порою относящиеся к нему доклады, будут проходить в двух разных залах параллельно.

Второй день тоже обещает быть насыщенным. Но это будет завтра. А пока я осмотрелся на местности и занял место поудобнее на открывающем докладе первого дня конференции. Тема интригует: "Электрические автомобили: на пороге технологической сингулярности".

#события #выступления #анонсы #требования #codefestru

🌭 Иллюзии, или Как я дважды наступил на одни и те же грабли за одну неделю

На прошлой неделе на работе я решил, что мне не хватает адреналина, и дважды подряд наступил на одни и те же грабли🧹

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

И вот в процессе возникает красивое требование переводить пользователя на то или иное место в системе, если он кликнет на описание продукта. Критерий — вид продукта. Звучит просто, да? Да и верхнеуровнево всё выглядит пристойно. Смежники тоже настраивают на оптимистичный лад: тип продукта есть, мы работаем в одном домене, говорим на одном языке  🌐

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

Выяснилось:
1⃣в зависимости от кейса экраны с продуктами, по которым предполагаем клики, разные. Всего возможно 2 варианта (и на том спасибо);
2⃣данные для них надо тянуть из двух разных сервисов;
3⃣у каждого из сервисов своя, уникальная и неповторимая классификация продуктов.

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

Стадии принятия неизбежного прошли по классике: гнев ("Как так?!"), отрицание ("Этого не может быть, у нас же есть стандартизованная типизация...") и торг ("А может, всё-таки можно как-то..?").

Торг, кстати, провалился с треском. Пришлось выкручиваться самому и придумывать варианты 🛠️ на своей стороне.


🧐 Мораль

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

А раз так, то пока вы не докопались до сути и не подтвердили всё сами, заверения смежников о том, что "это есть" — это лишь иллюзия.

👉 Кстати, на тему иллюзий могу порекомендовать статью на Хабре. Букв много, но интересно.

#статьи #психология #мозг

☠ История про 12000 часов, или как угробить компанию

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

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

Заинтриговал? Тогда рекомендую обратиться к отрезвляющей 👉 статье

#методыуправления #статьи

🔂 Границы системы: иллюзия покоя и нескончаемый поток работ

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

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

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

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

☝️ Отсюда мораль: заморозка функциональности вовсе не означает статику, а границы системы — это не предел, а источник постоянных задач.

Знакомо? Если да, поделитесь в комментариях своим опытом и впечатлениями.

#системныйподход

Ⓜ M-shaped: расширяем словарный запас

Наверняка многие из вас слышали, что нужно стремиться стать T-shaped специалистом. Сам я тоже часто сталкивался с этой идеей и считал её вполне обоснованной. Но буквально сегодня услышал, что теперь гораздо правильнее быть M-shaped 🙈

Что это вообще означает? Думаю, пересказывать саму концепцию не лучший выход. Проще сразу поделиться полезными ресурсами👇

🙂Если хотите быстро познакомиться с этой новой моделью, почитайте вот эту статью: https://www.rbc.ru/education/07/11/2025/6905df819a7947dd6c6fb913

🙂Но если интересуетесь деталями и личным опытом, рекомендую посмотреть это видео: https://youtu.be/ExvUFrHuBHM?si=xP4QCkSW01oVG2dG
Мне оно очень понравилось, многое стало понятно, и точно есть над чем поразмыслить.

#карьера #статьи #видео

🧮 Алгоритмы, структуры данных и пельмени

Когда-то давно, на одном из первых уроков УПК (про такой школьный предмет помнят разве что только олды), нам дали определение термина "алгоритм". Я до сих пор помню его наизусть.

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

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

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

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

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

#статьи #термины #данные #алгоритмы

Оказывается, месяц назад обо мне выходил пост у Hackathon Raptors 🦖 И как я это пропустил?🤔

#достижения #события #судейства

https://www.linkedin.com/feed/update/urn:li:ugcPost:7442297239508615168/

Как говорится, в каждой шутке...

#юмор #uxui

🤖 Схематрон: что это и зачем

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

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

Не берусь утверждать, что Schematron своими возможностями превосходит популярную JSON Schema для JSON, но всё же благодаря ему становится возможным выполнение комплексных проверок, зависящих от контекста данных внутри XML.

Позволю себе процитировать Википедию.

Schematron — язык разметки, предназначенный для проверки правильности содержимого XML документов, основанный на правилах, использует XPath и генерацию XSLT. Стандарт ISO/IEC 19757-3:2006.

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

Если заинтересовало, то советую посмотреть эту коротенькую статью на Хабре. А далее уже можно углубляться и идти на официальный сайт (правда без посторонних инструментов с доступом к нему из РФ могут быть проблемы).

#форматы #интеграции #сервисы

🤸‍♀️ "Бесполезные" слова JSON Schema

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


✅ multipleOf
Позволяет ограничивать кратность числовых значений заданному числу. Если по-простому: проверяемое значение должно без остатка делиться указанное вами. Примеры:

🔘Бронирование переговорных комнат доступно на любую продолжительность в минутах с шагом в 15 минут (15 мин, 30 мин и т.д.).

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "minutes" : {
      "type": "integer",
       "multipleOf": 15
    }    
  }
}

😀Общая площадь квартиры должна иметь точность до 1 знака после запятой.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "area" : {
      "type": "number",
      "multipleOf": 0.1
    }    
  }
}

🔘Цена должна иметь точность до 2 знаков после запятой. Дополнительно явно учтём, что величина должна быть строго положительной.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "price" : {
      "type": "number",
      "multipleOf": 0.01,
      "minimum": 0,
      "exclusiveMinimum": true
    }   
  }
}

🔘Заказ на производство ПЭТ-бутылок ограничен ассортиментом тары с ёмкостью в 0.5л, 1.0л, 1.5л, и 2.л. Значит значение должно делиться на 0.5 с дополнительными ограничениями на диапазон.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "capacity" : {
      "type": "number",
      "minimum": 0,
      "exclusiveMinimum": true,
      "maximum": 2.5,
      "exclusiveMaximum": true,
      "multipleOf": 0.5
    }
  }
}

😫 const
Ограничивает значение поля единственным значением. Формально использование const эквивалентно использованию enum с одним единственным значением, но const позволяет выстраивать более гибкие условия. Пример:

🔘Роль пользователя должна строго соответствовать значению "seller" либо "cashier", хотя ролевая модель может предусматривать больше доступных вариантов.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "role" : {
      "type": "string",
      "oneOf": [
        {"const": "seller"},
        {"const": "cashier"}
      ]
    }
  }
}

✅ if-then-else
Позволяет задать условия проверки полей. Например, мы можем проверить значение и в зависимости от результата проверки потребовать выполнение других условий. Пример:

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

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    
    "order_status": { "enum": ["pending", "processing", "paid"] },
    "payment_details": {
      "type": "object",
      "properties": {
        "account_number": { "type": "string" },
        "amount_paid": { "type": "number" }
      },
      "required": ["account_number", "amount_paid"]
    }
  },
  "if": {
    "properties": { "order_status": { "const": "paid" } }
  },
  "then": {
    "required": ["payment_details"]
  },
  "else": {}
}

✅ not
Позволяет запретить использование конкретных значений или целых групп значений. Использование not полезно, когда проще описать исключение, чем правило. Примеры:

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

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name" : {
      "type": "string",
      "not": { "enum": ["admin", "root", "guest"] }
    }
  }
}

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

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "minLength": 1,
      "not": { "pattern": "^\\s*$" }
    }
  }
}

#проектирование #интеграции #сервисы #форматы