Всем салют!

Итак, опросы показали такое:
- Confluence - наше всё (75%), на втором месте с грандиозным недобором - гуглодоки. Казалось бы, неудобненькая во многих аспектах работы система, но кушаем кактус (видно, из-за отсутствия достойных альтернатив).
- Figma крайне уверенно доминирует над Axure. Эх... ладно 🙈
- Большинство любят User Stories. Юз кейсы практически покинули чат, но спецификации как явление ещё весьма популярны (30%). Рады за них и за те 30%, кто много стучат по клавишам 🙂

Вполне интересные рассуждения на тему скрама: 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.