Вполне интересные рассуждения на тему скрама: https://habr.com/ru/companies/ruvds/articles/772618/
А есть те, у кого скрам прямо вот огненно работает и приносит только кайф от работы? 😁

Всем привет! Наш первый публичный блин 🙈: https://www.youtube.com/watch?v=Xfmid0muueo
Надеемся, что это познавательно и интересно, но очень открыты к комментариям и советам 🤗

Донт агри.

Начнем с того, что выше не так:
То, как подавать требования внутри отдельно взятого UC или US - на практике на выбор автора (на что, кстати, намекает наш недавний опрос в группе). Сценарий внутри UC можно описать как "техническим" языком (например, ответы системы описать в терминах UI и включить туда все мельчайшие шаги алгоритмов системы в ответ на действия пользователя), так и "пользовательским" ("простым языком", описывающим только внешне видимый результат для юзера, а не детальные действия системы), причем последнее даже рекомендуется в большинстве теорий (дальше буду называть это "классиками").

Но: вне зависимости от языка внутри UC, они (UC) РОВНО АНАЛОГИЧНО US сфокусированы на потребностях пользователей - это техники взгляда на систему с позиции того, что пользователи могут сделать с системой и какую свою цель закрыть. В отличие, например, от взгляда со стороны features (которые системоцентричны).

Теперь о действительных ключевых различиях между техниками:

1) UC крупнее. UC описывают обособленную полезную операцию (достаточно обособленную, чтобы о ней можно было сказать "я пошёл в систему ради этой операции - сделал действо - ушёл, оставшись довольным"). Позвонить контакту - UC для мобильного телефона. Выбрать контакт из списка контактов - не UC, потому что только ради этого никто в телефон не пойдёт. Это всего-лишь шаг в рамках какого-то UC. Use case slices (UC 2.0) как подход пытался снять эти ограничения, но не прижился.
US такие ограничения не навязывает. Если что-то можно назвать полезным инкрементом системы, это кандидат в US. И в целом, есть такой посыл, что US нужно распиливать и распиливать, пока в принципе пилится (SPIDR), ибо так с ними удобнее работать в плане трэкинга и контроля в плане девелопмента. Выбрать контакт из списка контактов - вполне себе US, если об этом кусочке можно сказать "Раньше этого не было в системе для звонка, а теперь вот, в рамках очередной итерации, добавляем, делая тем самым процесс звонка более удобным".

2) UC имеет меньше свободы в плане детализации. Если отбросить постулат "Аналитик художник, он может творить с любыми техниками все, что угодно", то "классики" рекомендуют определённый формат для UC: предусловия сценария  -сценарии по шагам - постусловия/результаты.
Для US классики ничего не рекомендуют: хоть пишите сценарии внутри, хоть описывайте критерии приемки (что я вижу и получаю - на это, кстати, упор в рекомендациях большинства "классиков"), хоть куски спецификаций внутрь пихайте, хоть ничего не пишите - оставляйте все на устные беседы.

3) US имеет меньше свободы в плане описания. НЕ детализации, а описания. Для US есть такой параметр, как крайне рекомендуемый user story title/statement/description. As a... I want to.. So that... Попросту говоря, практически все "классики" говорят, что, мол, ни в коем случае не забудьте действующее лицо, операцию и ценность, причём объедините это все в такое вот предложение.
UC тут недалеко ушли (актёров и название UC пропускать также нельзя), однако явную формулировку ценности и такой формат склейки "классики" не навязывают (НО рекомендуют где-то в UC это осмысливать и указывать).

4) Последнее и ключевое отличие. Если судить по большинству "классиков" (и у этого есть практическое логичное обоснование), то UC - это целевое состояние системы, набор требований, досконально описывающий то, как операция работает здесь и сейчас. Позвонить контакту - всегда в вашей спецификации требований будет полностью описывать то, как идёт звонок контакту в текущий момент, на 235-ю итерацию разработки. UC - это база знаний. Если в следующей итерации заказчик захочет изменить UC (добавить шаги, поменять название операции и пр.), то в документации UC АКТУАЛИЗИРУЕТСЯ, т. е. МЕНЯЕТСЯ под стать соответствующим новым требованиям.
US -  это постановка задачи, а не целевое состояние или база знаний. Если вкратце, то это связано с тем, что agile - не о красивой документации, а о том, чтобы успешно сделать систему в моменте.

Если в итерации один была US Позвонить контакту, а в итерации 235 заказчик хочет звонить теперь с новыми шагами, то старая US НЕ ТРОГАЕТСЯ (in fact, она вообще забыта после приемки и релиза).  На новые шаги СОЗДАЁТСЯ новая US, которая фактически по своей сути является постановкой задачи команде на ближайшее время: команда, запили теперь вот такие новые шаги.

Буду рад обсудить, ибо между "классиками" и практикой иногда бывает огромный разрыв, плюс надеюсь, что кому-то это позволит не по-детски отжечь на собеседовании 😉

Всем привет! На фоне недавнего обсуждения в чатике analyst.by: а что вы вот прям с радостью почитываете/посматриваете по БА и смежным областям? За любые отклики по любимым каналам на YouTube, ТГ-каналам/чатам и пр. будем благодарны, а то с хорошими материалами стало как-то грустновато.

Привет всем! А вдруг кому-нибудь подойдёт:

Компания a1qa ищет в команду Junior BA. Ключевые требования: оконченные курсы по БА, английский от уровня Upper-Intermediate и выше, локация – Казахстан (Астана), но релевантно также для Узбекистана и Грузии.
Подробности: https://astana.hh.kz/vacancy/89509607

Если соскучились по BA-related чтиву, вот очерк о трендах в бизнес-анализе в 2024: https://passionateba.pro/2024-trends-for-business-analysis/
Конкретики немного, и многое выглядит словно копипаст трендов последних лет, но нахвататься умных слов вполне можно :)

А дядюшка Карл жжёт конкретикой. Правда, как обычно - компиляцией из своих книжек, но мы их любим и с теплом вспоминаем. О трассировке всего на вся (полезно освежить в памяти): https://medium.com/analysts-corner/links-in-the-requirements-chain-b00d30f900b3

Классное видео о типовых ошибках в ERD-моделях (актуально и для доменных моделей, и для данных):
https://www.linkedin.com/posts/yulia-kosarenko_common-beginners-erd-mistakes-activity-7151994815704879104-3JrP?utm_source=share&utm_medium=member_android

Занятное чтиво об общих UX-трендах: https://blog.prototypr.io/ux-ui-design-trends-going-into-2024-ca43a839b541

Сегодня - классное чтиво про API для новичков. Если слабо с этим сталкивались, то рекомендуем к прочтению: https://bootcamp.uxdesign.cc/apis-a-breakdown-for-non-technical-product-managers-6c3d7051107d

Всем пламенный привет!

Чтобы разбавить немного ленту ссылей, начнем новую рубрику заметок: типовые ошибки IT-аналитика и как не грустить из-за них попробовать их не совершать. Постараемся по существу и на личных примерах, которые оставляли и оставляют шишки разной степени болючести. Ваши примеры и комменты, as always, much appreciated.

Сегодня начнём с главной, думается, проблемы (ошибка #1) — полный игнор бизнес-требований. Как из логики, так и из опыта, по масштабу потенциальных последствий равных ей нет. Все (ранее) или большинство (нынче) отечественные и не только IT-компании благополучно скипают эту часть на проектах. Как следствие, многие проекты приводят к грустным заказчикам, которым итоговую убервафлю некуда присунуть. И компания наша такая, соответственно: "Ой, а что случилось? :( Неси ещё бабла, мы готовы код пилить вечно".

Раньше мы не владели модными терминами "стратегический анализ" и "дискавери". Аналитик для нас был человеком, которому нужно уметь участливо слушать заказчика, чтобы пересказать это потом бородатым и нелюдимым разрабам. Соответственно, аналитики работали только с требованиями к решению (и даже не с требованиями ЗЛ в контексте языка).
Потом к нам начали просачиваться модные книги и тренинги, и стало понятно, что сферический аналитик вначале пытается понять, зачем система, что за она и в каком скоупе. И если что за она и в каком скоупе мы выясняли и раньше — само собой как-то получалось, по наитию — то "зачем она нужна" и до сих пор не особо нашло отклик ("ну куда я, дрожащий аналитик, полезу…"). Достаточно сказать, что примерно половина проектов, в которых я участвовал, итогом поимели грустных клиентов, уныло машущих ручками пачкам денег. Половину из них, оглядываясь назад, можно было спасти адекватным стратегическим анализом. Продукт для масс-потребителя, который вообще не нашел свою нишу; бизнес-система для продажи, которая не имела никаких преимуществ над топовыми игроками рынка; мобильное приложение, которое просто шло "в довесок" к сайту, при этом не будучи вообще никому нужным — вот несколько примеров "выгодных для исполнителя" проектов. С другой стороны, не могу нарадоваться, когда поползновения в сторону анализа стратегии встречаются заказчиками с приятным удивлением и хвалебными одами. А если это еще приводит и к внезапным инсайтам с их стороны ("блин, да, не подумал о "зачем", вот тут спасибо") — совсем зачетно.

Как не допустить ошибку: всегда хотя бы чуточку работайте с требованиями уровня "Зачем" (бизнес-требованиями).
Варианты:
1) Ваша компания/подразделение/команда и так это делает в ногу с заветами BABOK или крайне открыта к изменениям в этом плане. Отлично, тогда просто идите по главам из типового Vision and Scope: письмами, беседами и прочими коммуникациями несите в мир счастье.
2) Вы не работаете с такими требованиями — поставленная задача ограничивается только распилом досок:
2.1) "Диа кастома, мы понимаем, что ты хочешь напилить как можно больше досок асап, но не мог бы ты уделить хотя бы одну встречу обсуждению стратегии и концепции системы. Наш преомегалютый опыт намекает, что это сильно поможет нам сфокусироваться в дальнейшем на проекте, не терять корневые цели и принесёт сплошные бенефиты".
2.2) Дальше смотрите по временной доступности и эмоциональной реакции на подобную идею.
Дешево и сердито: Lean canvas для продуктов ("диа кастома, а давай на встрече заполним совместно вот такую клевую табличку. Покумекаем и впишем в процессе обсуждения. Мы возьмем с собой ключевых членов команды, а ты бери тех, кто может дать ценный инпут в стратегию и позиционирование") или же кастомно сделанный Lean canvas (заменив продуктовые секции на бизнес-цели, бизнес-риски и зависимости).
Основательно: серия интервью или воркшопов с проработкой бизнес-целей, критериев успеха, бизнес-рисков, зависимостей, категорий пользователей, вариантов и образа решения.

Что при этом стоит помнить:
- SMART для целей не обязателен. Предпочтителен, но не жизненно необходим, если у всех туго идет. Понимать бизнес-эффект от разработки решения даже без циферок — уже благое дело. А если еще будет четенькая трассировочка всех требований сверху-вниз (или же попросту Impact Map), то вообще огонек-огненный.
- Цели нужно помогать выработать, а не выспрашивать. Многие на вопрос "Дай нам сюда бизнес-цели по SMART" уйдут в астрал на несколько дней — на этом можно и похерить энтузиазм стейкхолдеров. "Вот, что такое БЦ; вот, как они помогут проекту и нашему участию; вот, чем круто хотя бы попытаться их засмартовать… А давай попробуем, м? Мы поможем наводящими вопросами и генерацией идей."
- Не нанесите несчастье своей компании в погоне за счастьем для заказчика. Помните, что итогом идеального стратегического анализа может быть отказ от разработки решения в принципе или выбор более подходящего решения, которое будет ни разу не оптимальным с точки зрения доходов вашего работодателя. Лавируйте тут аккуратно, с консультациями с вашим ПМом, БА и прочими высокими дядьками.
- Держите выработанные цели ("зачем") всегда в фокусе вашей деятельности в дальнейшем. Очевидно, что просто их сформулировать и забросить в Confluence тухнуть — так себе идея. Старайтесь всегда отражать всю вашу деятельность и выработанные единицы скоупа/требования от "Как это поможет в достижении целей заказчика". И не стесняйтесь говорить о таком заказчику, когда будет найдена нестыковка.

Ошибка #2 (дабы не было скучно, они не будут структурированы по тематикам — системности вам и так на работе хватает :)) — пропуск непрямых пользователей и их требований.
Это то, чем запросто страдают аналитики, когда не имеют какой-либо теоретико-практической базы за плечами. Непрямые пользователи — это те, кто потребляют результаты системы, но не пользуясь ей, а опосредовано. К нашему счастью или несчастью, зачастую именно они являются источниками ключевых пользовательских требований и диктуют наполнение системы.

Пример из личной практики: система для экспорта отчетной информации о кредитах. Прибежал, значит, заказчик и говорит такой: нужна система, которая из баз данных А и Б объединит информацию в один отчет формата X и позволит его экспортнуть в PDF. "Не базар, заказчик, какой отчет нужен?" Огненным сигналом на этом этапе уже служит полное отсутствие вопросов вида "А на кой ляд тебе все это надо?" — об этом говорили в ошибке #1. В общем, заказчик, как оно часто и бывает, послужил эрзац-заменителем пользователей (что в целом отдельная тема для разбора полетов) и надиктовал мегасуперформат, который благополучно и был запилен. Внезапно, через пару месяцев заказчик прилетает вновь и плачет, что систему нужно полностью переделать, ибо планеты криво выстроились, подножку по жизни поставили и вообще у него все вокруг редиски, а он Д'Артаньян. По факту разбора беды поняли следующее:
а) Пользователи с его стороны систему вообще не пользуют. И именно на этом этапе внезапно уразумели к тому же, а кто они вообще (сотрудники кредитного отдела) и зачем она им (предоставлять отчеты в государственный контролирующий орган).
б) Почему они ее не пользуют: стороннему органу отчеты надобны в совершенно ином формате, чем тот, который надиктовал заказчик. А потому труженикам проще, как и раньше, ручками их колбасить.
в) И заказчик, и аналитики — те еще градостроители.

Как не допустить ошибку: 1) не забывать в явном виде заниматься процессом с умным названием "Идентификация и анализ ЗЛ", 2) идти при этом по чеклисту, в котором в том числе будет указано, что пользователи могут быть прямыми и непрямыми, а заодно человеками и нет (тут тоже можно пропустить ряд важных требований), 3) как бы невероятно ни звучало, но если есть все-таки непрямые пользователи, их требования нужно попытаться извлечь напрямую у них или хотя бы через заказчика. Если тяжко идет, то совсем не лишним будет согласовать с заказчиком результаты анализа ЗЛ, задавая при этом нужные вопросы.
Как оно могло бы быть в альтернативной вселенной в примере выше: "Заказчик, вот категория юзеров "Сотрудники кредитного отдела", ага? —> Нафига им система вообще? —> А, для передачи другим? А есть требования от этих других? Может, если это гос. орган, то где-то необходимый им шаблон отчетов описан? Или, может, можно с ними согласовать финальный вариант?"

Пара отличных заметок о коммуникации на английском для тех, кому актуально:
https://blog.english4it.online/12-phrases-that-will-make-your-emails-more-professional-5baf7b2afcd7
https://blog.english4it.online/5-things-that-make-you-sound-rude-in-english-and-what-to-do-about-it-cf4fc7655f9f

Продолжаем разбор типовых ошибок, и сегодня ошибка #3 — недостаток коммуникации с командой по поводу структуры и пользования документацией (постановок задач и баз знаний).

Тут можно выделить две абсолютно типовые подпроблемы:
1) Навязывание документации без учёта фидбэка.
Как не стоит делать:
На курсе нас научили / на проекте так исторически сложилось, что мы делаем вот такие убернавороченные срски, сторьки и юз кейсики в лучших традициях предков. А потому, узри, команда, мой гений!
Проблема в том, не всякая команда поднимет бунт, если им что-то не нравится или не работает так, как могло бы в идеальном мире. Классно, если есть ретроспективы, где кто-то под общий шумок может и заметить, что с документацией что-то не так. Но может быть и так, что половину ваших трудов люди не читают, ибо непонятно/сложно/много-бесполезно.
Как стоит сделать: как только вы оказываетесь на новом для себя проекте, соберите фидбэк команды по поводу шаблонов документации, которые вы планируете использовать. Покажите им пример описания требований в виде стори, вертикальных кусков спеки, прототипов, диаграмм, после чего устройте воркшоп / вышлите опросник / подойдите к каждому лично и пообщайтесь — в общем, соберите честный фидбэк насчёт того, хватает ли информации для выполнения работы, нет ли лишнего и понятен ли язык и контент. Естественно, после этого обработайте результаты и в частности те моменты, где на базе фидбеков начинает прослеживаться подобие системной проблемы. Адаптированная под проект и команду документация всегда лучше универсального шаблона на все времена.

2) Отсутствие обучения команды пользованием артефактами.
Хороша ли ситуация, когда ваша модель данных на безукоризненном UML выглядит для джуна Васи как что-то, прилетевшее из космоса? И потому он благополучно скипает это (или, что ещё хуже, интерпретирует по-своему)?
Ваша задача, как вы понимаете, прокоммуницировать информацию. Важно постараться не путать её с задачей "показать всем, какие я высокоинтеллектуальные артефакты писать умею". Тут также могут помочь опросы и получение фидбэка всякими иными способами. И если адресатам вашей документации что-то не очень ясно, то, с одной стороны, вы можете пойти по пути в пункте 1 выше, а с другой — не стесняйтесь сделать мини-тренинг:
- Вот, как читать и в какой последовательности идти по документу, когда вам поступает задача на реализацию/тестирование фичи
- Вот, как интерпретировать мои UML-модели, прототипы, юз кейсы и пр.
- Вот, где у вас есть свобода действий ("могу сам придумать"), а вот где её нет
- Вот, что делать, если что-то неясно или есть подозрения в неполноте и прочих проблемах ("идти ко мне :)" )