9. Чрезмерная детализация на старте. Спорный момент, на который сильно влияет то, как у вас построены процессы, поэтому трактуйте это как одну из best practices, которые стоит рассмотреть и оценить полезность в контексте именно ваших процессов. Agile свойственна постепенная проработка требований — в первую очередь, чтобы не делать лишнюю работу с риском ее бесполезности.
Пример: вы как истинный перфекционист сели и описали КП для всех US в вашей карте историй на 5 баллов: каждый негативный сценарий; сообщения и проверки во всех ситуациях; то, как система должна реагировать на юзера в полнолуние в високосные годы. Это то, чему нас учили в контексте написания спек, не так ли? Но есть нюанс: agile открыт к изменениям и построен, в целом, на этом. Представьте такие (абсолютно нормальные, стоит заметить) ситуации: через пару дней история выброшена на помойку по инициативе заказчика; после приоритизации история опустилась на дно бэклога aka сделаем через пару лет (что = не сделаем никогда); команда на refinement предложила иные решения или вообще похерила то поведение, которое вы описывали, ибо не юзабельно, дорого или технически невозможно. Все это мало того, что не есть эффективное использование вашего времени, так еще и затронет ваше эго и приведет к ненужным страданиям.

Как избегать: найти точку, в которой ваши эффорты будут just enough исходя из контекста. Есть agile-команды, в которых именно так и поставлен акцент и исходя из этого продуманы процессы постепенной проработки требований. Например, 1) вы быстро на глаз накидываете ключевые КП для всех историй в обозримые пару месяцев разработки, чтобы было что обсуждать с заказчиком и на что получать его первичный фидбэк, 2) вы дорабатываете КП на плюс условные 30% качества для историй в верхней части бэклога и несете их на refinement, 3) вы дорабатываете истории после refinement на базе выработанных решений, 4) вы дорабатываете истории еще на 20% после планнинга, 5) остатки вы дописываете в процессе реализации US, по мере обращения к вам исполнителей. Процесс не должен быть именно таким, но примерьте эту концепцию на свою ситуацию — вероятно, увидите возможность более рационального использования своего и стейкхолдеров времени.

10. База знаний вместо постановки задачи. Не раз уже упомянутая тема в канале, и я еще раз отошлю к замечательному докладу (на мой взгляд, must see для всех, дабы понимать упомянутые концепции, даже если вы с US не работаете): https://www.youtube.com/watch?v=qpwcE1rsBNg
Этот пункт, как и предыдущий, сильно зависит от ваших процессов — я лишь упомяну его в контексте «классического» взгляда на US по умолчанию.

В чем роль US на проекте? US — это ценный инкремент продукта (дополнение/изменение в продукте), плюс механизм планирования и контроля проекта и его итераций ("в спринт пойдут вот эти вот US, вот как мы их оценим, вот кто будет каждой заниматься" и пр.).

Что такое ведение базы знаний (спецификации) в виде US? Вы делаете US «Отправить письмо», отдаете в разработку, но в новом спринте заказчик хочет добавить сюда аттачмент файлов. Как вы поступаете, трактуя US как спецификацию/базу знаний? Обновляете историю до версии, условно, 2, дополняя КП требованиями к тому, как должен происходить аттачмент.
Что тут не так? Все так, если вы хотите вести актуализируемую базу знаний по системе. Однако, а в чем полезный инкремент для системы? В кусочке истории, который явным образом не выделен? Как выполнить оценить историю, как отдать US на разработку и тестирование? Как описать DoD (definition of done) для US, если US — это не сделанный в рамках спринта кусок, а актуализированная и усложненная US из прошлого? Вам придется дополнять это костылями, которые все равно введут новый термин и будут служить постановкой задачи вместо US — например, это привязанные к US задачи, которые в описанных процессах займут место US.

Что такое трактовка US в виде постановки задачи? Была US «Создание письма». Спринт закончился, US принята, DoD выполнен — US «выброшена» (осталась в анналах системы документации). Заказчик хочет теперь аттачменты? Ок, это новая US («Аттачменты файлов») и именно она фигурирует в верхушке бэклога как полезный инкремент продукта, именно ее будут планировать в спринты, оценивать, обсуждать, брать члены команды в работу и закрывать по DoD. И в этом и есть best practice по работе с историями.

В чем недостаток такого подхода? Если пользоваться только US как контейнерами требований, то вы остаетесь без базы знаний. Хорошая новость: она не всегда и нужна. Вам может казаться, что без нее не обойтись, но это только на первый взгляд. Большое количество проектов не требуют базы знаний в виде документации или же вполне допускают, что эффорты, которые будут сэкономлены на ее отсутствии с лихвой покроют ситуации, когда надо раскопать, как там сейчас работает какой-либо кусок. А иногда и комменты к коде или грамотная структура US в Confluence или ином месте (не в Jira, нет 😊) облегчат закрытие задач, стоящих перед актуализируемой базой знаний.
Плохая новость: иногда она таки нужна (часто меняются люди в команде, сложная логика системы, большие длительность и объемы проекта). И в таком случае нужно искать подход к тому, как сделать и то, и другое: и базу знаний вести, и задачи ставить команде. Ну или же думать, какими словами обозвать и в каких единицах выполнять оба эти процесса.

Привет всем!

Заметка о такой огненной штуке, как Impact Map, с примером, разбором и советами: https://shesterov.by/tpost/fzh1lezxp1-impact-map-i-user-story-map-kak-bistro-i

Ещё несколько занимательных статей на почитать:

Want to Communicate Effectively at Work? Eliminate These 5 Cognitive Distortions (https://betterprogramming.pub/want-to-communicate-effectively-at-work-eliminate-these-5-cognitive-distortions-679caa76cd2a): в продолжение темы о когнитивных искажениях, на этот раз в контексте коммуникаций. Интересно, полезно и познавательно.

Про OKR и Гарри Поттера (https://www.linkedin.com/posts/kirakuzmenko_%D0%B3%D0%B0%D1%80%D1%80%D0%B8-%D0%BF%D0%BE%D1%82%D1%82%D0%B5%D1%80-%D0%B8-okr-ugcPost-7196081864183341056-s_--): совсем не уверен насчёт полезности, плюс заметки со словом OKR заставляют мой глаз истерически дёргаться, но кайф тут именно в примере.

Top 10 Phrases To Include In Your Elevator Pitch (https://english4it.medium.com/top-10-phrases-to-include-in-your-elevator-pitch-8e177bcad5a3): от все того же классного канала про фразы, которые помогут звучать более модно. Огонь, как обычно.

Салют!

Подъехала вторая часть — о User Story Map и том, каким может быть процесс её проработки: https://shesterov.by/tpost/c447fei0c1-impact-map-i-user-story-map-kak-bistro-i

Пятничное чтиво-рассуждалка о стереотипах в бизнес-анализе (https://shesterov.by/tpost/3dgtau3211-stereotipi-v-biznes-analize).
Если появится желание доказать несостоятельность доводов — не сдерживайтесь, буду рад обсудить 😊

Салют!
Еще одна подборка статей для нескучных вечеров:

- В очередной раз можно освежить в памяти SPIDR — на этот раз в подаче от Дениса Гобова: https://www.artofba.com/post/spidr-how-t-decompose-user-story. Активно читающие канал вряд ли найдут что-то новое для себя, а для еще не знакомых с этой техникой — отличный повод изучить эту штуку в огненной обертке.

- О том, как проводить Скрам-ретроспективы полезно: https://medium.com/beyond-agile-leadership/3-essential-practices-in-sprint-retrospective-to-unleash-agile-teams-potential-a0e2963c70d9. Так-то об очевидных вещах, но кратко и систематизировано.

И немного о технике (осторожно, внутри статей много букв):

- Understanding the Top 10 Software Architecture Patterns (https://www.designgurus.io/blog/understanding-top-10-software-architecture-patterns): отличный гайд для новичков — рекомендую проштудировать, если принципы построения программных систем совсем в новинку.

- Гайд постарше, но от этого не менее замечательный — What is code (кстати, один из материалов, которые мы рекомендуем в качестве технической подготовки к курсу): https://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/. Для тех, кто в IT недавно или как раз планирует путешествие, must read.

Всем привет!

Компания Lesta Games ищет Business Analyst в команду Platform в Минске. Выпускники ITMINE очень приветствуются 😊
Подразделение Platform занимается разработкой и оперированием общих сервисов для игр компании. BA будет работать в отдельном стриме с группой сервисов двух направлений и внутренними заказчиками.
Требуемый опыт работы: от 2-х лет.
Формат работы: офисный 5/2 (удаленки и гибрида нет).

Подробнее о вакансии здесь: https://hh.ru/vacancy/98162200

Приветы!

Снова на почитать:

1. Как работают API-методы на пальцах (отличный материал для тех, кто с API едва сталкивался до этого): https://productcoalition.com/endpoints-inputs-and-outputs-the-essentials-of-api-structure-37fe6228146c

2. Заметка годом постарше о том, для чего нужны аналитики и с чем аналитики сталкиваются в работе. По уровню погружения это также для новичков, если тут таковые имеются. Заметка классно акцентирует внимание как на то, чем полезен БА в команде, так и на ключевых “сложностях”, с которыми они сталкиваются: https://habr.com/ru/companies/surfstudio/articles/594199/

3. О том, как решать конфликты между девелоперами и дизайнерами. Саму тему статья не сказать, что раскрывает, но как описалочка “хорошего” agile-процесса интересно читается: https://medium.com/beyond-agile-leadership/how-to-solve-conflicts-between-developers-and-designers-in-software-projects-da12d2021ccc

И лютая полезняшка на закуску: тут автор огненно собрал разные алгоритмы проектирования UI, однако материала для раскопок там многовато. Сделал это, чтобы вам не пришлось😊 Вот лучшие гайды оттуда в копилку:

- Поля ввода/выбора: https://oxygen.doctolib.design/60b411768/p/70925f-choosing-form-components

- Контролы действия:
https://oxygen.doctolib.design/60b411768/p/7334c9-choosing-actions
https://web.archive.org/web/20240118144311/https://canvas.workday.com/patterns/calls-to-action/#tab=usage

- Ошибки: https://oxygen.doctolib.design/60b411768/p/8918c1-designing-better-errors

- Хелпы: https://oxygen.doctolib.design/60b411768/p/704279-choosing-a-help-component

- Уведомляшки: https://web.archive.org/web/20240118144833/https://canvas.workday.com/patterns/notifications/#tab=usage

- Индикаторы загрузки: https://web.archive.org/web/20240118144613/https://canvas.workday.com/patterns/loading/#tab=usage

Может, кого-то заинтересует вакансия, включающая работу с требованиями помимо прочего:

GP Solutions is looking for an Operational Analyst for our Product project!
Location: Belarus, remotely or in the Minsk office
Type: Full-time with shifted work schedule, starting between 10.00-12.00 Minsk time.

https://docs.google.com/document/d/1a1vHkuWocGm66JxWLaK0WT9marrUOZtp6bCyG3EGbsE/edit?usp=sharing

Key Responsibilities:
- Continuously monitor the dashboard for accurate performance metrics.
- Identify and analyze any problems, including data inaccuracies, bugs, and UI/UX issues.
- Collaborate with the development and audit teams to investigate and document the root causes of dashboard issues, examining log files thoroughly when needed.

We look forward to your application! You can contact me on Telegram - https://t.me/HRDaryaK

Может кому актуально 😉

Плагин https://chatgpt.com/g/g-J0FYgDhN5-software-architect-gpt помогает быстро ответить на ключевые вопросы по программе и получить черновик-описание решения

Фактически это тот самый «генератор ТЗ», святой грааль аналитиков и философский камень)

Архитектуру всё ещё нельзя нагуглить, но можно уже получить черновик за 2 минуты.

Пример того, что можно получить

Салют!

Новая неделя — новая подборка для коротания вечеров:

1. Дядюшка Карл, видимо, почитывает наш канал и чатик, а потому решил также высказаться на тему ведения базы знаний: To Document or Not to Document? That Is the Question. Рекомендуется в виде мотивашки сторонникам чаще забивать на ведение спецификаций, чем нет.

2. Факапы аналитиков: где они обитают? Кейсы Mad Brains. Интересная подборка кейсов, но есть ощущение, что выработанным решениям недостает понимания «хороших» процессов бизнес-анализа (правда, не все эти кейсы связаны с бизнес-анализом в нашем понимании). Можем потренироваться в решении подобных проблем — если кому-нибудь интересно, пишите в комментарии, что предложили бы вы в качестве процессного фикса по факту этих ситуаций.

3. NFR Checklist With Their Testing Approaches. Нефункциональные требования — одна из наиболее сложных областей в работе БА, и либо аналитиками игнорируется, либо вызывает попоболь. По ссылке — неплохой чеклист НФТ, который можно взять себе в копилку. Круто, если бы он был более полон и проработан вглубь, с примерами и метриками, но и так весьма полезно. Может, когда-нибудь руки и мотивация дойдут скомпилировать собственный чеклист из своего и чужого опыта 😊

4-5. 2-Page Login Pattern, And How To Fix It — интересные рассуждения на тему разнесения логина и пароля на две страницы. Новички наберутся умных слов и концепций, а старички смогут почерпнуть идеи для проектирования входа в систему.
И от того же автора: Hidden vs. Disabled In UX. О том, когда контролы скрывать, а когда — дизейблить. Выпускники нашего курса и так должны знать общие рекомендации, а для незнакомых с темой — must read.

Кстати, любимый пример на тему процессных фиксов: https://youtu.be/VPDJXngp2bM?t=882 (рекомендую посмотреть полностью, но сабж именно с 14:42 по 17:20)

Если кому-то интересен уклон в работу с процессами, Syberry предлагает выпускникам ITMINE возможность получить практический опыт. Они организуют недельную стажировку для начинающих ВА, по результатам которой заявлена возможность получить оффер:
https://www.syberry.com/careers/vacancy/?id=pe935

И (не)много о требованиях и том, как они могут помочь в определении границ работ БА: https://shesterov.by/tpost/8m01i21o31-trebovaniya-vs-ne-trebovaniya-ili-gde-ko

Что еще интересного найдено на просторах сети:

Максим Дорофеев. Прокрастинация саморазвития, или Что я понял, обучая взрослых людей (https://www.youtube.com/watch?v=JvkHYJlI14w) — пригодится тем, кто уже обучается чему-либо, планирует себе подобное или просто не прочь кайфануть от харизматичного крутого выступления.

Свод рекомендаций по BPMN от рабочей группы Дениса Котова: https://www.linkedin.com/posts/daryakravets_%D1%8D%D1%82%D0%BE-%D1%81%D0%BB%D1%83%D1%87%D0%B8%D0%BB%D0%BE%D1%81%D1%8C-%D0%B2%D0%BE%D1%82-%D0%BE%D0%BD-%D0%B4%D0%BE%D0%BB%D0%B3%D0%BE%D0%B6%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D0%B9-%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82-activity-7210002516082651136-AcsD
С BPMN я сталкиваюсь нечасто, но на первый взгляд это крутая работа, т. к. чего-то подобного для BPMN ранее не видел (вероятно, просто не копал) и мне лично это бы сильно пригодилось для погружения в нотацию.

Дизайн-система внутренних продуктов для Figma от EPAM: https://www.linkedin.com/posts/artyom-lezhnyuk-299a6188_epam-uui-v57-figma-activity-7208469224988524548--G_I
Нраицца!

Полезное для тех, кто прокачивает техническую базу: A basic question in a security Interview: How do you store passwords in the database? (https://iorilan.medium.com/a-basic-question-in-security-interview-how-do-you-store-passwords-in-the-database-676c125cff64)

Вот на такую подборку технических заметок наткнулся (автору поста, кстати, можно респектных лайков накидать): https://www.linkedin.com/posts/alexandra-murash_system-design-activity-7211751256954949632-YTrC

Тех. часть в масштабе кругозора сильно актуальна, особенно для начинающих БА. Только вот в гайде хватает кмк ненужного шума (наравне с реально полезными заметками), поэтому читать от корки до корки может статься сложным и даже не очень продуктивным занятием. Если кто начнёт и в комментах будет выкладывать выборку полезного, тоже присоединюсь.

Ещё вакансия (скорее, даже несколько), где выпускники ITMINE очень приветствуются (стажировка с дальнейшим устройством):

a1qa company's Business Analysis team is expanding, and we are actively seeking new team members to join us.

What you will do:
- Create different types of project documentation.
- Identify and document requirements using various formats based on product implementation methodologies.
- Analyze and model customer business processes.
- Communicate directly with customers and collaborate with the project team.

Who We're Looking For:
- SDLC understanding.
- Knowledge of the theoretical foundations of business analysis with the ability to apply theory to practical situations.
- Communication skills with strong analytical abilities.
- High independence at work, willingness to take responsibility for results.
- Proficient in English at an Upper-Intermediate level.

How to Apply:
Please send your resume in English, mentioning your relevant knowledge or courses in business analysis and English proficiency level: o2.mihaylova@a1qa.com

Тут я кидал чеклист НФТ — он неплох, но показался сильно неполным и урезанным для практического применения.

Составил свой вариант на англ., прошерстив любимые источники и добавив из своего опыта: https://docs.google.com/spreadsheets/d/1mx1FobkNHhR1cqL764cE694LiZzlDC4EYRj24UpD-aM/edit?usp=sharing

Сделан так, как на мой взгляд пригодится на проектах в виде чеклиста идей и для минимизации упущений.
Файл доступен для комментирования, поэтому указания на ошибки, вопросные моменты и в особенности дополнения из своего опыта и знаний highly appreciated.
Плюс фидбэк о том, насколько это помогает и что стоит сделать лучше, весьма бы пригодился.