ITMINE: о бизнес-анализе

Салют причастным! Чутка интересностей на почитать за последнее время: 📌 How to Build BA Processes: Part 1 (рассуждения общего плана) и Part 2 (конкретно про настройку процессов) — от Art of BA. В целом, интересный очерк, но я лично высмотрел не так много понятных практических рекомендаций. Кстати, я ранее схожую тему описывал: что входит в планирование бизнес-анализа и как это кушать. 📌 Чем занимаются и сколько зарабатывают аналитики в IT. Обзорная статья, описывающая, какими бывают аналитики и сколько бабосиков могут загрести (по статистике Хабра). Первая часть, очевидно, для новичков. 📌 Нужна ли проектная документация в 26 году и что если ты пришел на новый проект, а там хаос и пустота? Легко читаемая статья о вечном вопросе аналитиков с классной аргументацией и рядом полезных советов (в частности по тому, как есть слона по кусочкам). 📌 Карточный LI-пост про БА: https://www.linkedin.com/posts/matthewthomasholliday_but-i-dont-have-a-technical-background-share-7492079699427217408-bSHW/. Я такие обычно либо игнорю, либо репорчу как ИИ-слоп 😈, но иногда попадаются толковые советы. Тут речь про некоторые иррациональные страхи аналитиков, и местами весьма в точку.

Наткнулся на книжку “Прайм-эра аналитика: для тех, кто в теме, и тех, кто только заходит”. Автор пока делится ей бесплатно, если плюсик ему отгрузить: https://www.linkedin.com/posts/kan1y_прайм-эра-аналитика-ugcPost-7482694941278638080-XOQH - Главное — подача: легко и интересно читать, плюс живые примеры из практики. Поймал себя на том, что сложно оторваться и хочется проштудировать все до конца (не помню, когда в последний раз такое ощущал от книги на тему БА). - Лаконично и круто описаны нужные для СА (ну или не лишние для БА) технические и смежные области: тестирование, БД/SQL, интеграции, архитектура, среды. - Много полезных второстепенных тем: продуктивность, вайб-прототипы, векторы развития, собеседования и т. п. - Печалька, но мало или нет базы по ряду ключевых моментов для БА: виды требований (сильно упрощено и неполно), извлечение требований (мало техник, советов, хитростей), документирование (имхо не позволяет построить непротиворечивую картинку подходов в голове), моделирование (выборка автора у меня не сильно отзывается), discovery (очень мало), работа с НФТ (аналогично). Надо понимать, что это не Вигерс в плане глубины и системности погружения в важные для БА темы. Если подытожить, то вряд ли из книжки новички получат полную базу по БА и работе с требованиями. С другой стороны, для вас это отличный вариант почитать что-то, что не задушит через пять минут, а для опытных — огонь вариант закрыть случайные пробелы и просто приятное чтиво на ночь.

Привет всем! Пост-напоминалка о самых полезных материалах в канале/на сайте. Интересного нынче на горизонте маловато, поэтому вдруг да пригодится. ✔️ Типовые ошибки аналитика (практические советы в формате небольших заметок): https://docs.google.com/spreadsheets/d/1R4yYvW9WC-cD21JgThQCg3So0SK1os2xkAOWd-rTZlw/ ✔️ Что такое требования и какими они бывают (большой лонгрид с примерами): https://t.me/itmineba/178 Пробные видосы на ту же тему: https://www.youtube.com/watch?v=Xfmid0muueo, https://youtu.be/4hU3CAkFJsQ?si=nag13XWVSIl-Awxn ✔️ “Всякие полезные советы”: 📌 Требования к внешним интерфейсам: https://t.me/itmineba/180 и вниз 📌 User Stories: https://t.me/itmineba/183 и вниз 📌 Cкоуп: https://t.me/itmineba/191 и вниз 📌 Письма: https://t.me/itmineba/195 и вниз 📌 Юз кейсы: https://t.me/itmineba/201 и вниз, https://t.me/itmineba/204 и вниз, https://t.me/itmineba/207 и вниз ✔️ Чеклист и примеры нефункциональных требований: https://t.me/itmineba/141 ✔️ Гайд по юз кейсам: 📌 https://itmine.by/articles/tpost/dmdp3z0rk1-use-cases-yuz-keisi-varianti-ispolzovani 📌 https://itmine.by/articles/tpost/fpvuzdk8r1-use-cases-yuz-keisi-varianti-ispolzovani ✔️ Impact Map: https://t.me/itmineba/123 ✔️ User Story Map: https://t.me/itmineba/125 ✔️ CRUDL: https://itmine.by/articles/tpost/d5vyk97az1-crudl-tehniki-ba ✔️ Планирование бизнес-анализа (на пальцах о сложном): https://t.me/itmineba/224 ✔️ Работа с AS IS: https://t.me/itmineba/168 ✔️ Определение TO BE: https://t.me/itmineba/171 ✔️ Стратегический анализ / discovery (+ Vision and Scope): https://t.me/itmineba/142 ✔️ Описание функциональных требований через UI: https://itmine.by/articles/tpost/8tch99upd1-funktsionalnie-trebovaniya-cherez-trebov ✔️ Про всякие там рисуночки: 📌 Про UML в целом: https://t.me/itmineba/151 📌 Use Case Diagram: https://t.me/itmineba/152 📌 Class Diagram: https://t.me/itmineba/153 📌 Модель предметной области и логическая модель данных: https://itmine.by/articles/tpost/j9acle3jd1-model-predmetnoi-oblasti-i-logicheskaya 📌 Activity Diagram: https://t.me/itmineba/155 📌 State Machine Diagram: https://t.me/itmineba/157 📌 Sequence Diagram: https://t.me/itmineba/159 📌 Всякие разные диаграммы: https://t.me/itmineba/215 ✔️ Грани аналитика: 📌 IT БA — это… IT: http://itmine.by/articles/tpost/k90kjs6sa1-it-ba-eto-it 📌 IT БА — это… анализ: https://itmine.by/articles/tpost/xkapfmlyu1-it-ba-eto-analiz ✔️ Agile VS Waterfall для БА: https://itmine.by/articles/tpost/rmx55e63k1-agile-vs-waterfall-spetsifiki-raboti-ana

Вот тут я ныл о том , как не нужно читать BABOK: https://t.me/itmineba/320. Автор жжет дальше, и теперь уже я неиллюзорно пугаюсь, что в глаза долблюсь: https://habr.com/ru/companies/bcs_company/articles/1042548/ Подсобите, где та самая версия BABOK, рожающая такое? Может, аддон какой выходил? Согласно глоссарию BABOK v3.0: «Потребность — это проблема, возможность или ограничение, представляющие потенциальную ценность для заинтересованной стороны». Важная деталь, которую легко упустить: BABOK намеренно использует три равнозначных варианта — проблема, возможность, ограничение. Ну вот же глоссарий, не? need: A problem or opportunity to be addressed business need: A problem or opportunity of strategic or tactical importance to be addressed. И дальше: Чтобы не заблудиться в лабиринте «желаний» заказчика, BABOK предлагает разделять потребности на 4 уровня. Бизнес-потребность (Business Need): Глобальная цель компании (???) Потребность заинтересованной стороны (Stakeholder Need): Что нужно конкретным группам (ЗСт), чтобы бизнес-цель была достигнута. Потребность в решении (Solution Need): Функциональные и нефункциональные требования к системе. Переходная потребность (Transition Need): То, о чем забывают в 80% случаев! Что нужно, чтобы перейти от старого к новому? Так все смешано в кучку, что ахтунг. Переходная потребность, потребность в решении. Это какой-то п...ц, товарищи, не? Либо автор вообще не делает разницы между потребностями и требованиями, либо где-то живет такой вот вольный перевод, либо (что сильно вероятно) — это то, как ИИ прочел БАБОК. А может я не дочитал — коллеги, нужна помощь разбирающихся 🙊

Еще одна подборочка годного — сегодня с фокусом на Хабр. Рекап прошедшего ЛАФа от Максима Цепкова (https://habr.com/ru/articles/1048838/) — чтобы понять, о чем говорят аналитики на конфах. Читать местами больно, ибо не до конца переваренный поток сознания, но интересно. Акцент, естественно, на ИИ. Как я использую AI в работе продакт-оунера в EXANTE: от ресёрча до релиза (https://habr.com/ru/articles/1046443/) — интересная сборка личного опыта для дискавери и работы с требованиями с помощью Скайнета. Порядок против хаоса: как не проиграть в битве за понятную документацию? (https://habr.com/ru/companies/rtlabs/articles/1048270/) — хороший опус о том, как делать юзабельную документацию. Если продраться через долгое вступление и закрыть глаза на ГОСТы, есть классные советы, полезные любому аналитику. P. S. Кейс настройки личного ИИ-помощника на десктопе (https://t.me/psyreq/268) — возможно, наведет на мысли поиграться. От себя вкину, что это весело и местами действительно творится магия, но бесплатная игра заканчивается слишком уж быстро. Плюс будьте аккуратны с разрешениями — нужно быть морально готовым переустанавливать поломанный Джарвисом софт и искать удаленные данные. Кстати, есть у кого успешные кейсы долгого активного юзания подобного умного помощника? Поделитесь?

Салют! Давненько у нас не было на почитать. Кстати, не знаю, как вы, а у меня уже глаз дергается от нейросетевого булшита, через который приходится продираться. В общем, подобрал интересное за последнее время. И да, напоминаю, что это не туева хуча рандомных ссылок — каждый пункт с любовью признан достойным прекрасной аудитории канала. Из разработчика в системные аналитики: практический путь в профессию (https://habr.com/ru/articles/1040758/) — статья для начинающих о том, кто такие аналитики. Не обращаем внимание на бизнес vs системный анализ — все равно их усердно смешивают в кашу. Ящик с AI-инструментами на май 2026 (https://t.me/psyreq/238) — собственно, описание такого ящика для аналитика. Можно ведрами черпать опыт автора и брать за основу. Story Splitting: How To Split User Stories So Teams Can Finish (https://www.mountaingoatsoftware.com/agile/user-stories/story-splitting-how-to-split-user-stories-so-teams-can-finish) — Mike Cohn о декомпозиции историй (если не знаете, это серьезный известный дядька и не последний человек в теме аджайла и скрама). Ничего внезапного вы тут не найдете, но в кучу собрано много классных советов. Читать, если вы все еще делите US на бэкенд и фронтенд. Кстати, skill для AI от него же для проверки US: https://www.mountaingoatsoftware.com/blog/story-critic-skill-better-backlog-items Пара любопытных кейсов об “очевидных” требованиях (https://t.me/ba_and_sa/2703, https://t.me/ba_and_sa/2713). Имхо тут тема не соответствует наполнению — например, в первом случае это банальный фейл не-проработки требований. Второе же — отличный пример того, насколько полезно получать доступ к телу реальных юзеров.

Art of BA провели исследование аналитиков Украины и Польши: https://www.artofba.com/ba-survey-2026. Очень интересный и детальный ресерч. Ключевые полезные моменты, если лень изучать оригинал: - 470 респондентов (375 - Украина, 95 - Польша, остальные непонятно). - Agile, хоть и доминирует, но занимает не настолько крупную часть, как ожидалось: 18% - тру аджайл, 31% - типа аджайл, 36% - непонятная фигня, где все намешано. - В 31% случаев в компаниях приняты стандарты БА, которым участники следуют. Это радует, т. к. казалось, что должно быть печальнее. В 39% в компаниях есть шаблоны артефактов, в 52% - свои собственные шаблоны у аналитиков. - Тайтлы: 45% - БА, 17% - БА + СА, 11% - БА + PO. Неясно, среди кого проводился опрос, но если по всем, у кого есть слово “аналитик”, то это подкрепление релевантности БА (no matter сколько ни кричали бы некоторые, что БА вымерли и кроме СА нет пути в счастье… хотя от рынка, конечно, зависит). - БА с опытом < 1 года - 2.6 %. Это печально. Интересно, как они дальше будут появляться. Вероятно, сразу рождаться в миддлы, хотя это априори недостижимо. - 83% не имеют сертификаций. - 57% так или иначе участвуют в стратегическом анализе. Это безмерно радует - отходим от бездумных сториписаний (если предполагать, что участники верно эту область трактуют). - Какие виды требований документируют: 84% - ФТ, 77% - БТ (огонь!), 62% - НФТ (тоже огонь!), 47% - UI, 47% - бизнес-правила, 31% - модели данных (маловато, но на это может влиять наличие систем без данных). - Техники: 82% - User Stories, 76% - прототипы UI, 66% - юз кейсы (они еще очень даже живы!). - Ключевые НФТ, с которыми работают те, кто трогает: security (82%), performance (79%), usability (71%). - Сложности с обеспечением качеств требований: 35% - атомарность (в чем тут сложность? 🙂), 35% - полнота, 29% - краткость/точность - AI: 44% пользуют регулярно, 36% - иногда. 42% считают, что это относительно полезно (именно с таким оттенком), 36% - нейтральны к эффекту от AI. 5% считают, что AI заменит аналитиков в будущем. 45% активно осваивают AI для работы. Gemini - у 50%, Copilot - 34%, прочие - небольшие доли (что интересно, Claude нет в списке). - Для чего используется AI: черновики документации (67%), поиск информации (66%), подготовка к коммуникации (письма, протоколы) (58%), анализ документов (52%). - Что не нравится в AI: глюки (74%), вопросы конфиденциальности (59%). - Актуальные проектные проблемы: меняющиеся цели/требования - 52%, скрытые/неполные требования - 44%, времени не хватает - 40%, недостаточная валидация требований со стороны заказчика - 38%. - На что они влияют: неверные проектные оценки (47%), превышения бюджетов/эффортов (41%), переделки (31%), разрыв между потребностями юзеров и функционалом (23%).

Видео с разбором вакансий jun, mid и senior: https://youtu.be/Gh5667GJnM0?si=RHGd_IegxsO1cA7e. В деталях я бы там по отдельным вещам подискутировал, но в целом рекомендую глянуть, если планируете путь в БА.

Кстати, еще из статьи, но уже вопрос на обсуждение: там пример RACI, и в ней Product Owner / Заказчик (да, два в одном) стоит как A для задач “Сбор и уточнение требований” и “Проектирование”. Как считаете, это ок и верна ли трактовка буквочки A?

Вот тут вышла статья для новичков: Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» В целом, она неплоха, хоть и просто копипастит BABOK. Однако копипастит местами как-то странно. Вкину субъективную критику — пригодится и для лучшего понимания теории (например, при подготовке к получению IIBA-регалий), и местами даже для работы. 📍Вот так автор описывает контекст (как одно из шести понятий модели BACCM из BABOK): Как новое решение повлияет на дальнейшую работу? Ок, это упрощение, но оно нехило искажает смысл. BABOK гласит так (тут и далее будет собственный перевод, ибо, простите, не доверяю “официальным”): Обстоятельства, которые влияют на изменение или на которые оно влияет, либо которые углубляют понимание изменения. Т. е.: детали процессов и участников AS IS, часовые пояса и коммуникационные предпочтения стейкхолдеров, погода, законы — все это примеры контекста. Сравниваем с определением выше 🤷🏼 Но пока это сугубо теория, т. к. мы с вами не ведем отдельный документ под названием Контекст. Далее автор говорит, мол, давайте разберем понятие Stakeholder, потому что все остальные понятия начинаются с него. Например, Контекст — это кто сейчас влияет и кто будет влиять на процесс? Не понимаю, как это работает, ибо выше автор давал иное определение, но whatever. 📍Автор дает определение Stakeholder: Согласно BABOK 3.0: «Заинтересованная сторона (часто используется сокращенное значение — ЗСт) — это физическое лицо или группа лиц, с которыми бизнес-аналитик, вероятно, будет взаимодействовать прямо или косвенно. Любая заинтересованная сторона может быть источником требований, допущений или ограничений». Не знаю, откуда это взято, причем в кавычках как цитата. BABOK значительно более абстрактен: Группа или человек, имеющие отношение к изменению, потребности или решению. И это так-то важно. Как мы как БА определим, с кем будем прямо или косвенно взаимодействовать, когда занимаемся идентификацией стейкхолдеров? Нам вначале бы их как-то определить вообще, а потом уже думать, кто достоин с нами общаться. Я рекомендую брать такое понимание (и это уже не из BABOK, а смесь понятий PMBOK и BABOK): Те (группа, человек, организация), кто могут повлиять на или на кого может повлиять изменение/решение/потребность. Кстати, что интересно, PMBOK еще добавляет сюда “или думают, что на них повлияет…” Тут же я периодически привожу такой пример: Мы внедряем робот-пылесос в компанию и понимаем, что по итогу компания уволит текущую уборщицу. Она стейкхолдер? Конечно, ведь на нее повлияет изменение. Мы с ней будем взаимодействовать, как автор пишет выше? Аналитик вполне может такое сразу отмести, ибо а зачем — утешать ее как-то? 😢 Но это неверно. Ее нужно учесть, осмыслить влияние изменения на нее и лишь затем уже уделить хоть немного внимания вместе с заказчиком тому, какие работы с ней стоит провести кому бы то ни было из ЗЛ (вероятно, очертить ей перспективы заранее, продумать плюшки и пр.) 📍Мы в компании… разработали и поддерживаем матрицу коммуникаций — это матрица, в которой отражаются подразделения и заинтересованные стороны для выявления/обсуждения/согласования требований и ограничений при разработке, описании и автоматизации бизнес процессов. На всякий случай: не стоит путать табличку, отражающую стейкхолдеров и их анализ (отношение, влияние и прочие детали), и матрицу коммуникаций. Матрица коммуникаций (хотя я чаще слышал и использую “план коммуникаций”) показывает то, какую информацию кому из ЗЛ когда и каким способом нужно доносить. Уборщица в такой матрице, например, едва ли будет. Если только вы не делаете эту матрицу для себя в контексте проекта, а готовите ее для всего изменения и с учетом коммуникаций всех ЗЛ между собой, но давайте спустимся на землю. Кстати, с удивлением не нашел такую технику в BABOK v3 (только ее упоминание). Знатоки, подскажите — плохо искал? В общем, штука эта временами довольно полезна, поэтому ниже скину пример в виде скрина от того же IIBA.

ITMINE: о бизнес-анализе pinned «Друзья! А у нас в планах старт новой группы (Бизнес-анализ в IT, онлайн, с 28 апреля) 🧑‍🎓 Тренером буду все так же я (Герман Шестеров). Общая комплектация полезняшек остается той же: ✅ Тренинги с фокусом на практику. ✅ Теория в видео-формате с тестами…»

Друзья! А у нас в планах старт новой группы (Бизнес-анализ в IT, онлайн, с 28 апреля) 🧑‍🎓 Тренером буду все так же я (Герман Шестеров). Общая комплектация полезняшек остается той же: ✅ Тренинги с фокусом на практику. ✅ Теория в видео-формате с тестами и заданиями для закрепления (изучаем в удобное время и обстановке) ✅ Много самостоятельной работы, которую я проверю и разберу. ✅ Беседа на старте с обсуждением целей и ответами на вопросы; выходная беседа с проверкой и рекомендациями. ✅ Шаблоны работ, списки типовых ошибок, плюс конспект курса для заметок. ✅ Для самых мотивированных: авторская подборка материалов на углубленное изучение по каждой теме. ✅~4.5 мес. основного курса. Формат: по будним дням, 1 или 2 дня в неделю, с 19 до 22, со свободными неделями для самостоятельной работы. Плюс мы в очередной раз дорабатываем курс, чтобы он стал круче: 🤩 Приоритет тем: поменялась структура тренингов. По ряду тем тренингов стало меньше, по другим - больше. Общее количество тренинговых часов немного увеличилось. 🤩 Понятность и структура материалов: по некоторым темам контента стало меньше (с прицелом на опциональное изучение вне курса), зато его стало больше по темам “Discovery” и “Работа с требованиями к решению”. 🤩 Закрытие пробелов: в темы и практику добавлены UML Sequence и BPMN. 🤩 Добавлены и будут постоянно улучшаться опциональные материалы по использованию AI для ускорения работы (общие рекомендации, настройка, промпты). ✏️ Узнать больше, а также оставить заявку можно тут: https://itmine.by/course/business-analysis-online/. Или просто напишите нам на info@itmine.by или в Телеграм (https://t.me/itmineby) – с радостью пообщаемся 😊

Удивительно, но на русском языке нет инструкции по Event Storming. Кажется, даже книга Брандолини не переведена (буду рад ошибиться). Мне понадобилось для одного проекта описание техники на русском, и я не смог его найти. Пришлось сделать самому. Ну как сделать, я перевел описание с сайта https://www.qlerify.com/post/event-storming-the-complete-guide Мне показалось, это может быть полезно для сообщества, поэтому поделюсь с вами. Надеюсь, я не очень сильно нарушаю авторские права, будем считать, что это всё в учебных целях. Пользуйтесь!

На всякий случай вот - если интересно изучить эту технику. Сам я пару раз в теорию заглянул, но как-то не возбудило, хотя в СА-каналах она часто фигурирует. А есть тут БА, кто на практике пользовал Event Storming, получал профит и может от души порекомендовать?

Всем привет! Есть вакансия для jun-уровня, которую не удалось закрыть нашими свежими выпускниками. Не нужна нынче работа на этом тяжелом рынке 😊 Кидаю сюда, описание вынес в отдельный документ. Возможно, еще пару аналогичных вакансий докину в ближайшее время…

Всем привет! Есть вакансия для jun-уровня, которую не удалось закрыть нашими свежими выпускниками. Не нужна нынче работа на этом тяжелом рынке 😊 Кидаю сюда, описание вынес в отдельный документ. Возможно, еще пару аналогичных вакансий докину в ближайшее время, т. к. там ситуация аналогичная. Вот это, кстати, компания закрыла огненными людьми из этого канала, что очень радует. При этом к заявкам еще открыты. Кстати, интересный момент: если в вакансии вдруг специально указано, что выпускникам ITMINE очень рады (а такие бывают, ага), то это = “тем, кто прошел онлайн-курс” (который с тренингами). Почитывать канал - это несомненно +100 к мощи, но все же совсем не равно качественному прохождению обучения. Имейте в виду, что работодатели все равно обратятся к нам за фидбэком 😉

😛 Локализация. Спец знает, что это не только перевести «Submit» на «Послать». Важно помнить про культурный код: в некоторых странах иконка «Удалить» в форме корзины считается плохой приметой, поэтому там должен быть текст «Отпустить в добрый путь». Или, как пример, гравитационный рендеринг. В Австралии из-за разницы в магнитном поле пиксели на экранах текут вверх, а не вниз. Поэтому для австралийской локализации интерфейс должен быть инвертирован. Если не заложим бюджет на закупку «перевернутых шрифтов», австралийцы нас возненавидят. 📍 Операционная среда. Если не пропишем, что система должна работать в мобильном Хроме, наш UI на смартфоне будет выглядеть как инвентарь в Скайриме с сотней модов: всё наложится и Боб не найдет кнопку «Оплатить». Если не укажем целевое разрешение, UI на 4K-мониторе может быть размером с почтовую марку, а на ноуте пацана из Африки не влезет в экран, и тому придется скроллить до посинения. 🚫 Ограничения (Design Constraints) - внешние рамки, которые разрабы ненавидят. Например: «система должна быть написана на COBOL, потому что дед заказчика так привык, а ему потом это в гараже дописывать». Это невидимые стены для наших разрабов, за которые они не могут выйти, даже если они Кодзима. Плюс помимо прихотей заказчика нам порой еще нужно соответствовать законам, ГОСТам и прочим регуляциям - данные нельзя хранить в открытом виде, даже если сильно хочется; бесплатные библиотеки могут быть запрещены на уровне скрижалей домена и т. п. А еще наш новый крутой сервис, вероятно, должен бесшовно работать с древним злом, которое написали до нашего рождения. В общем, гайз, нефункциональные требования - это костыли, на которых держится поведение системы. Велика вероятность, что если наше ТЗ состоит только из «кнопочек», на выходе получим не вылизанный продукт, а демку уровня early access. И да, Боба, вероятно заставят этим пользоваться палкой-мотивалкой, но Боба жалко. Если хочется еще апрельских мудростей, вот тут они есть: Про коммуникации: https://t.me/itmineba/102 Про инструменты: https://t.me/itmineba/220

По следам недавнего обсуждения накидал на досуге заметку для новичков про НФТ. Причем, как нынче модно, с элементами геймификации (хотя, может, я не так понял это слово). Все знают НФТ, все игнорят НФТ и большинству от этого неловко. И правильно, что неловко. Погнали по пунктам, почему ваш проект - не стройная эльфийка, а хромой гоблин на костылях. Атрибуты качества. Функционал - это геймплей, ради которого юзер Боб пойдет в продукт. Нефункциональные требования - это фреймрейт, пинг и раскладка клавы. Если не подумаем сюда, неиллюзорна вероятность, что Боб не раз подумает про наших родителей. Есть классическое разделение на внешние и внутренние атрибуты качества. Внешние - это как тачка блестит и едет (важно для нас), а внутренние - сможет ли механик дядя Вася починить движок без ритуального жертвоприношения (важно для дяди Васи). Некоторые примеры внешних: 🤓 Удобство использования (Usability): сколько лишних движений совершит Боб - в панике или трезвом рассудке. Если Бобу нужна инструкция на 40 страниц, чтобы найти кнопку «Выход», Боб вряд ли захочет потом искать вход. Кстати, если в требованиях написано «система должна быть удобной» - гоним этого аналитика влажными тряпками. 👛 Безопасность (Security): это про то, чтобы хакер Джон не скачал базу клиентов Боба, подставив кавычку в строке поиска. Или когда система должна автоматически блокировать Боба, если он вводит пароль слишком быстро (подозрение на киборга) или слишком медленно (на слоупока). 💻 Легкость установки (Installability): насколько Бобу легко развернуть софт на железе. «Установите Python 3.9, но не 3.10, обновите драйверы видюхи от 2012 года и принесите в жертву сисадмина». Если наш инсталлятор требует от Боба много IQ - Боб проиграл, да и мы не выиграем. Таких атрибутов вагон и тележка. Бобу также может быть важен перфоманс (60 FPS на его древней аки мамонтовы фекалии видюхе), безопасность для тела, ума и железа (у Боба не вытекут глаза от цветовой гаммы, а комп не расплавится в пиковые моменты) и пр. Внутренние атрибуты качества (радость мазохиста): 💪 Масштабируемость (Scalability): это про то, не ляжет ли сервер, когда вместо трех калек зайдет миллион человек. Хорошая масштабируемость - когда мы подкидываем еще серверов, и всё летит. Плохая - когда код написан так, что второй процессор в системе мешает первому, потому что они спорят, чья очередь обрабатывать запрос. ⚡️ Эффективность (Efficiency): это про то, как наш вкуснокод ест ресурсы. Если билд требует охлаждения жидким азотом, пора заняться оптимизацией. 💩 Повторное использование (Reusability): мечта ленивых разрабов. Это возможность наклепать ассетов, чтобы потом собрать еще с десяток игруль. Миядзаки подтвердит, что именно таков путь самурая. Требования к внешним интерфейсам. Это то, через какие двери наша поделка общается с остальным миром. Если двери заклинит, наш проект превратится в бункер с сокровищами, до которых никто не может добраться. Разберем три кита, на которых держится адекватная документация требований такого вида: 🚪Точки взаимодействия (Endpoints). Каждый эндпойнт - как NPC. Нам нужно четко знать, когда мы к нему пойдем, какой квест у него возьмем и какие ништяки он будет от нас ждать, чтобы завершить квест. 🗺 Маппинг данных. Ништяки недостаточно принести в сыром виде. Их нужно скрафтить в четкий лут, который NPC закодирован принимать. У нас в системе поле называется User_id и это число, а API ждет на вход GUID и, внезапно, строку. Без крафта нужных вещей хороший API нас отфутболит, а плохой - крашнется. 🤬 И тут мы приходим к обработке ошибок. Плохой аналитик описывает только изи режим - когда все работает, как надо. Хороший аналитик - он как фанат солслайков: знает, что разраб будет всячески пытаться испортить ему кашку, а потому подходит к каждому мобу с планом на любую хрень, которую тот может сотворить.

Небольшая пятничная рассуждалка на тему НФТ. Вчера с коллегой их обсуждали, и встал интересный вопрос: кому ими заниматься? В моей картине мира ответ прост - раз это требования, то это аналитик (или любой иной зверь, отвечающий за работу с требованиями). Главное, постараться не перейти в их формулировке в плоскость технических решений. Видел, кстати, также мнение, что в контексте разделения БА и СА НФТ стоит оставить СА. В целом, все это натолкнуло на мысль, что НФТ - крайне пробельная тема в работе БА. Если быть точным, то речь именно про атрибуты качества, а не про все НФТ поголовно. Пробельная в том плане, что есть лютый разрыв между “все понятно в теории” и “а че теперь со всем этим делать?”. Вот вроде и есть куча статей и даже книжки на это (Quest for Software Requirements, например - рекомендую), но с чем храброму аналитику идти к целевому стейкхолдеру? Почти все источники, которые я видел, приводят классные примеры, кричат о проверяемости и том, как красиво лепить туда циферки, дают крутые чеклисты того, в какую сторону думать. И это все нужно и важно. А как теперь (плюс всегда ли надо и в каком объеме) выстроить диалог с заказчиком/юзерами/командой, чтобы подобную магию провернуть? Везде как будто бы одно и то же: вот целевое состояние - бери бубен и танцуй, когда хочешь и как хочешь. Оттого многие и пишут требования вида “удобно” и “расширяемо” или тупо забивают на это (макетики рисовать всяко проще и интереснее). Если нелениво отписаться, интересно узнать: - Вы работаете с атрибутами качества? - Если нет, попадали ли в косяки из-за этого и насколько часто? У меня был такой опыт (ничего уникального: заказчик прибегал с посылом “камон, это неудобно/медленно”, плюс вскрывались проблемы с секьюрностью и иными аспектами в продакшне). - Если работаете или умеете, есть ли рекомендации, книги, курсы, дающие понятный и концептуально несложный алгоритм по их готовке? Полезняшки из комментов: Quality attribute workshop: https://apps.dtic.mil/sti/tr/pdf/ADA418428.pdf Книжка по НФТ: https://drive.google.com/file/d/1z59TXykLA2JA4vv1bD0QenvjPQZP_fGY/view?usp=drivesdk