Вполне интересные рассуждения на тему скрама: 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 (заменив продуктовые секции на бизнес-цели, бизнес-риски и зависимости).
Основательно: серия интервью или воркшопов с проработкой бизнес-целей, критериев успеха, бизнес-рисков, зависимостей, категорий пользователей, вариантов и образа решения.