По складывающейся уже традиции снова увеселительное чтиво для пятничного семейного релакса — UML Class Diagram: https://shesterov.by/tpost/pgu0yucas1-uml-class-diagram

Это третья заметка из цикла про UML (первая и вторая).

Салют!

Любопытное видео для тех, кто в раздумье: Reasons NOT to become a business analyst (от Юрия Гомона):
https://passionateba.pro/reasons-not-to-become-a-business-analyst-top-5/

Имхо все пункты в точку (только надо иметь в виду, что рассуждение про бабосики в конце ориентировано на западный рынок, и подкатать губу), и осмыслить стоит каждый. Чекать все не обязательно: например, из моего опыта работы с аналитиками “любить” работу с документами часто противоречит “любви” к работе с людьми: вполне можно кайфовать от одного и смиренно грызть кактус в другом аспекте.

Кстати, Юра Веденин когда-то давно писал интересную заметку для analyst.by: 5 признаков того, что вы не готовы стать бизнес-аналитиком в ИТ: http://analyst.by/articles/5-priznakov-togo-chto-vyi-ne-gotovyi-stat-biznes-analitikom-v-it
Некоторые вещи дискуссионны, но в целом это хорошее дополнение к теме.

Хоть и не в пятницу вечером, но продолжаем: https://shesterov.by/tpost/s30fpt0j11-uml-activity-diagram
А еще, напоминаю, есть про UML в целом, про Use Case Diagram и Class Diagram.

Салют!

Лидфактор (IT-интегратор; проекты по внедрению amoCRM со сложными интеграциями и доработками; внедрение процессов на базе BPM платформы) в поисках начинающего бизнес-аналитика, "который готов развиваться в сильного специалиста в нашей команде":

"- работа на интересных проектах в паре с аналитиком уровня middle;
- обучению использованию сервисов для работы с проектами (asana, miro, slack, google);

Новым сотрудником нашей команды ты можешь стать, если:
• Закончил курсы по специальности Бизнес-аналитик;
• Обладаешь высокой самостоятельностью - способен разобраться в незнакомой задаче и решить ее;
• Умеешь ясно и структурировано излагать свои мысли как устно, так и письменно;
• Умеешь задавать правильные вопросы для выявления ключевых задач клиентов;
• Умеешь работать с проектной документацией;
• Получил высшее образование;
• Владеешь нотацией BPMN 2.0;
• Знаком с технологиями web-разработки."

Полное описание тут: https://docs.google.com/document/d/1G7dDf-P7HT82X1tF134mwokdVutftPb_21u4B0PIxgA/edit?usp=sharing

Идеальное чтиво для нескучных выходных — диаграмма состояний в UML: https://shesterov.by/tpost/n26iurdac1-uml-state-machine-diagram

Салют!

Немного интересного контента из сети:

1. Про прототипирование (Сила прототипирования: что сработало, а чего следует избегать): https://www.artofba.com/post/power-of-prototyping-in-examples-ru. Интересные кейсы и личный опыт.

2. BA Interview Guide: https://t.me/BAunity/687. Большинство пунктов показались очевидными и пережеванными десятки раз, но подсвечу интересные моменты:

Begin by thoroughly researching the company — не уверен насчет thoroughly, но хотя бы слегка понимать, с кем идет общение, и показать, что вы подошли к беседе с кастомной подготовкой (это в принципе рекомендация к любому телодвижению в процессе поиска работы — избавляться от generic-рассылок, фраз и подходов — такое бесит интервьюеров) — огонь тактика, не раз проверено.

Про STAR сейчас пишет каждый второй эксперт в Линке, но если не знакомы, то советую обратить внимание. Для аналитика это особенно полезно, ибо все, что демонстрирует в нас адского структуризатора — во благо.

Секция с вопросами от собеседуемого реально полезна. Тут два зайца: 1) мы заранее обдумываем, что важно узнать (на ходу в стрессе тяжко подобное рожать), 2) показывает, что мы подготовились, искусны в извлечении информации, системно подходим к задаче и вообще молодцы.

Интересная идея: follow-up with a thank you note or email to express your gratitude for the opportunity to interview. Такой кандидат выделился бы для меня из массы — при условии, конечно, что сообщение было бы честным и убедительным (как писал выше, индивидуализированным, а не копипастой для всех).

Что еще можно добавить в плане рандомных советов из личного опыта по обе стороны баррикад:

- Многие интервьюеры (наиболее крутые, имхо) любят кейсовые ситуации, а не вопросы в лоб по теории. Что бы вы сделали, если бы такая вот попа наступила? Стоит немного потренироваться в том, как вы будете показывать свои рассуждения на подобное.

- Ряд интервьюеров любят проверять софт скиллы на отстраненных вопросах: например, как бы вы посчитали вес нашего здания в полевых условиях (без Интернета, например). В большинстве случаев правильного ответа на подобное нет и он не нужен. Это попытка прощупать софт скиллы анализа и problem solving — то, что щупается тяжелее всего. Ну типа разобьем это на подзадачи: измерить длину, ширину, высоту, предположить толщину стен, учесть окна и т. п. Важно, как идет рассуждение — как вы оперируете информацией, выдвигаете и подмечаете ассампшны, области с неизвестной для вас информацией и выстраиваете какой-никакой план стуктурированного решения, а не тыкаете в небо со словами “хз, ну миллион тонн, наверное.”

- Слышал когда-то совет не допускать пауз в ответах. Вероятно, для кого-то это важный маркер, но я в корне не согласен, и большинство интервьюеров будут солидарны. Часто в ногу с этим советом кандидат начинает нести чушь, чтобы заполнить паузы. Советую не стесняться умолкать на подумать (”Прошу прощения, обдумаю ответ/формулировку”). И если после этого вы отожжете взвешенной мыслью, где почти каждое слово в нужном месте — огонь огненный. Сами подумайте, если бы вы собеседовали аналитика, вам это зашло бы как показатель скилла человека или хаотичный сбивчивый ответ, зато моментально? Или, что еще хуже, реакция "Ну да, не подумал как-то” после того, как интервьюер укажет на косяки в ответе. Не злоупотребляйте уходом в астрал в каждом вопросе, но в трудных случаях стоит.

Последняя заметка из цикла графомании про UML — UML Sequence Diagram: https://shesterov.by/tpost/g4n39inn91-uml-sequence-diagram

Немного об ограничениях: https://shesterov.by/tpost/rxt85xd1h1-ogranicheniya-design-and-implementation
Что это такое и как их правильно кушать.

Приветос, амигос!

Снова подборка интересных чтив:

https://habr.com/ru/articles/839900/ (Общие принципы интеграций систем. SA для самых маленьких) - полезные базовые знания из области “качаем техническую базу”.

https://medium.com/analysts-corner/requirements-development-demands-iteration-065a1c6e621c (Requirements Development Demands Iteration) - Карл снова на связи и рассуждает об итеративности разработки требований. Для начинающих, т. к. опытные уже в курсе, что Карл пишет на одни и те же темы, просто чуть разными словами.

https://habr.com/ru/articles/838716/ (<Не>Страшное слово эстимация, или Как я впервые оценивала время на тестирование и перебрала) - частный кейс об оценке работ, который интересно просто почитать и либо сравнить со своим опытом, либо хватануть базу для первого раза.

Помнится, я уже делился этим материалом где-то в анналах комментариев, но скину явно сюда еще раз — как минимум для тех, кто не видел ранее:

https://www.youtube.com/watch?v=qpwcE1rsBNg

По ощущениям это закрывает процентов тридцать вопросов и проблем, которые есть у людей as is в работе с требованиями. Ну или как минимум дает направление, в котором копать — дальше уже выбор правильных лопат. В общем, оч крутой доклад — строго рекомендасьон.

И где-то рядом также советую глянуть такое еще от Дениса на тему Use Cases vs User Stories: https://www.youtube.com/watch?v=9dOFSY5PoNo

Классное описание сферически идеального получения/выполнения задач. По личному опыту — работа над такими навыками даст значительно больше роста, чем прокачка точечных хард-скиллов для БА, т. к. проактивность — редкий и ценный зверь.

Мы в systems.education при отборе людей в команду опираемся на концепцию Ответственного Исполнителя

Кто это такой?
Если коротко, то это коллега, которому можно поставить задачу и забыть. Но она будет сделана вовремя и качественно.

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

2. При выполнении задачи
- коллега самостоятельно изучает дополнительные источники по задаче
- коллега не пытается выполнить большую задачу за один присест, а разбивает её на части
- коллега тем более не откладывает большую задачу ближе к дедлайну, понимая, что это накапливает риски
- коллега обоснованно прикидывает™ когда и как он будет выполнять задачу
- коллега понимает, что если задача нового для него типа, то ему нужно как можно быстрее получить фидбек на первые результаты, чтобы не проделать кучу работы зря
- коллега пытается сделать небольшой фрагмент как можно быстрее, чтобы выяснить, какие сложности возникают и отдать её на проверку
- коллега САМ предлагает время, когда он вернётся с первыми результатами (обычно это от завтрашнего дня до через неделю, но не позже)
- коллега стремится к высокому качеству результата
- коллега не делает элементарные ошибки в работе
- коллега не делает повторяющие ошибки в работе
- если коллега встречает в работе сложности, он назначает созвон с автором задачи чтобы обсудить их и найти способы преодоления, но не злоупотребляет этой возможностью

С позиции автора задачи это выглядит как управление в Делегирующем стиле Ситуационного лидерства:
- не надо напоминать коллеге про задачу
- не надо заново объяснять задачу
- не надо делать много замечаний
- не надо переделывать работу самому

Салют!

А вот напоминаю / делюсь с новоприбывшими, что есть система навигации по каналу и материалам в нем (как авторским, так и просто рекомендованным): https://gerych.notion.site/bf26ef9770d64637a401a33d086c58a9?v=56b48289ae3d48dc9725059553dbc414

Говорят, довольно удобно 😊

Есть ощущение, что в канале я уже графоманил по всем аспектам работы БА, и наступил творческий кризис 🙂 В попытках осмысления, что ещё могло бы быть интересно-полезным, надумалось, что мы ещё не смотрели на БА как на сквозной процесс. В общем, какая-никакая попытка этого (пока что в общих чертах):

https://shesterov.by/tpost/2po262c8v1-it-biznes-analiz-obschii-protsess

Немного про переходные требования и наводящие вопросы: https://www.batimes.com/articles/transition-requirements-the-key-to-adoption/

Букв по ссылке много, но, надеюсь, они полезны 😊
https://shesterov.by/tpost/vfyu7vu3f1-biznes-analiz-analiz-tekuschei-situatsii

Интересная заметка на тему точек роста: https://medium.com/business-architected/5-reasons-you-are-not-getting-promoted-as-a-business-analyst-4159010763b4
Я бы добавил, что на мой взгляд две ключевые вещи, которые определяют рост специалиста, это базовые софт скиллы (прокачка ответственности, проактивности, самоорганизации, коммуникативных навыков, аналитичности) и опыт, и обе важны. Есть, например, курсы, которые обещают сделать mid-аналитика с нуля за три-четыре месяца, что как бы бред - продакшн-опыт в контексте учёбы практически нереально получить.

Пара интересных заметок:

A Fool with a Tool Is an Amplified Fool (https://medium.com/analysts-corner/a-fool-with-a-tool-is-an-amplified-fool-140cd9124ad4) — дядюшка Карл рефлексирует на тему осмысленного применения инструментов и техник.

How To Manage Dangerous Actions In User Interfaces (https://www.smashingmagazine.com/2024/09/how-manage-dangerous-actions-user-interfaces/) — отличная подборка подходов для UI по оформлению важных действий.

Снова буквы подъехали 🙂

https://shesterov.by/tpost/9spcjb2mm1-biznes-analiz-opredelenie-buduschego-sos

В заметке затрагиваются Lean Canvas, Business Objectives Model, бизнес-требования, критерии успеха и бизнес-риски, плюс в целом то, на кой это все нужно и чем может нанести непоправимую пользу.

Любопытный конспект. Чтобы булки не подгорели, подсвечу сразу конец: автор утверждает, что это шутка 🤷‍♂

Написал супер-краткий конспект книги Вигерса. А то тут ходит конспект на 70 страниц, и люди просят краткое изложение краткого конспекта. Итак, специально для тех, у кого нет времени читать ни 700, ни 70 страниц, циничный конспект:

Часть I. Требования к ПО
* Схема на стр. 7. Уровни требований. В реальности вы будете разрабатывать только функциональные требования. Можно почитать стр. 8 и 9, там расшифровка текстом (8 — бизнес-требования и юзер-стори, 9 — функциональные).
Рис. 1-4 на стр. 16 — показано, какие есть этапы в работе над требованиями. Перевод диаграммы очень плохой, приведу свой:

Инженерия требований состоит из разработки требований и управления требованиями. Разработка требований состоит из этапов выявления, анализа, спецификации и валидации.

Прочтите расшифровку диаграммы на стр. 17, если что-то непонятно.

Стр. 42-46 — плач о согласовании требований. Совет Вигерса про участников, которые морозятся, на стр. 45, оцените его применимость:

В позитивном ключе упомяните, что вы в курсе, что они пока не одобрили требования, но проект движется вперед с этими требованиями в качестве базовых, чтобы не задерживать работу. Сообщите им, что если они хотят что-то изменить, для этого есть соответствующий процесс. В сущности, вы действуете так, как будто заинтересованное лицо согласилось с требованиями, but you’re managing the communications closely.

Схема на стр.51 показывает главную идею: не ждите, что все действия по разработке требований удастся выполнить последовательно и за один проход. Выявление, анализ, спецификация и валидация будут происходить одновременно.

Часть II. Разработка требований.
* Бизнес-цели, концепция продукта — никого не интересует, почти никто не пишет.
* Границы проекта. У проекта должны быть границы. Есть что-то, чего мы делать точно не будем. Контекстную диаграмму на стр. 104 никогда не рисуют.
* Классы пользователей — скорее всего, у вашей системы один класс пользователей — ваши пользователи. Или ваш продакт оунер.
* Методы выявления требований — реально вы будете делать только интервью. Стр. 138, цитирую: установите контакт, следите за границами проекта, заранее подготовьте вопросы и предварительные модели, предлагайте идеи, слушайте активно.
* Поиск упущенных требований — стр. 136.
* Варианты использования — разве их где-то ещё пишут? Если не пишете — пропускаете. Или читаете стр. 171-193.
* Бизнес-правила — разве их когда-то вообще писали? И вы не будете. Пропускаете. Ну или читаете главу 9.

Шаблон SRS — единственное, что вам нужно из этой части. стр. 223-234.

* Критерии качественных требований — забейте, это никого не волнует и никто не проверяет.

Формулирование и проверка полноты требований, стр. 243-254. Ну тоже полезно.

* Моделирование, гл. 12. Много разных диаграмм. Реально вам нужна только Sequence Diagram. Но у Вигерса она не описана, ищите где-то ещё.
* Требования к данным, гл. 13 — вам это не нужно. Максимум, нужно понимать, как составлять JSONы, но этого у Вигерса тоже нет.
* Атрибуты качества ПО — гл. 14. Это "нефункциональные требования". Если вы их не пишете — можно пропустить.
* Прототипирование — скорее всего, его у вас нет. Пропускаете.
* Приоритеты, гл. 16. Любопытно, но скорее всего у вас приоритеты требований назначаются по принципу "кто ближе к руководству" и "кто громче всех кричит на совещаниях".
* Рецензирование, в гл. 17 — ну, почитайте, если оно у вас есть. Это скорее для лидов.
* Повторное использование требований, гл. 18. Не бывает.

ЧАСТЬ III. Всё то же самое, но для отдельных видов проектов. Найдите свой.

Часть IV. Управление требованиями . Вы реально ведёте учет разных версий требований, отслеживаете изменения, состояния и связи требований? Или просто пишете один раз документ, отдаете его, и потом никогда его не переделываете? Если так — можно пропустить.

Часть V — забейте. Риски вообще никто никогда не анализирует и не управляет.

Итого, нужно просмотреть несколько страниц из первой части, потом шаблон SRS и раздел про тексты.

Вот и всё, не благодарите.

(Если что, это шутка. Но в каждой шутке, как мы знаем, есть доля истины...)