А вот примеры нарушения ряда пунктов и того, как это стоило бы переделать.

Кстати, в рамках курса мы эту часть практикуем, причем с индивидуальным фидбэком 😉

Привет всем!

Можно попробовать для начала стартануть тему с заданиями. Давайте базовые правила очертим:

- Фидбэк буду давать как минимум я, но а) надеюсь, что другие будут подключаться, причем можно в виде дискуссий (я буду только рад), и б) далеко не факт, что на все работы — зависит от активности (минимум на две работы по каждой задаче меня точно хватит).
- Делая задания, вы соглашаетесь на их публичную выкладку и обратную связь. Можно анонимизировать, если важно: кидайте работу мне в личку (@g.shesterov), а я уже выложу в Google-док от себя.
- Предлагаю работы давать в доступном для публичного комментирования Google-документе или ином софте (Miro, Figma etc.) — главное, чтобы комментирование было доступно всем без SMS и регистрации. Кидайте их в комменты, либо, как выше писал, мне в личку.
Прочие условия и наворачивание инфраструктуры будем добавлять по мере итераций и ретро по ним.

Вот для начала вариантик (вдохновлено тестовым из пары компаний) 😊:

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

Что предлагаю сделать вначале:

Сформировать скоуп в виде User Story Map (и/или Use Case Diagram и списка фич с описанием).

Следующим шагом двинемся к детализации элементов (user stories, use cases, требования к данным, требования к UI, макеты). Если кто-нибудь хочет, можно и бизнес-требования с бизнес-контекстом в бонус очертить.

Пока попробуем без дедлайнов: будем ревьюить по мере появления работ и времени, но где-то через пару неделек двинемся, думаю, к следующим задачам.

Те, кто готов был активничать: ваши комменты и предложения к задаче или условиям тоже велкам🙏

А вот и первые работы. Тем, кто еще делает задание, не стоит смотреть, дабы спойлеров не нахвататься 😊

https://docs.google.com/document/d/1VQQxkMTHQt9lrMNjGUFsN6SsIN2IB5yqDQyj4ZyqbaM

https://docs.google.com/document/d/15oOBmZlEc9u9pX1DXV4HRnK8Zjj-UzqmIPqJQvEZMF8

Cвои комменты добавил. “Положительного” фидбэка по конкретным кускам там нет (чтобы не тратить время, так как суть задания не в этом), но в целом: все что не откомменчено, сделано круто, а потому "авторы жжёте, молодцы и флюиды респекта вам" 😊
Сделал доступ всем на комментирование. Обратная связь от других или иные комментарии, естественно, приветствуются.

Будущие работы, если будут, буду уже в комментарии к этому посту выкладывать (или выкладывайте туда сами).

Ещё одна подборка всякого-разного на почитать на досуге:

10 Reasons To Have a Professional Portfolio (https://medium.com/business-architected/10-reasons-to-have-a-professional-portfolio-26bf6f7e8efa): о том, что аналитикам круто иметь портфолио и как к нему подойти. Мне всегда нравился этот подход, причем будучи на обеих сторонах, а потому рекомендую к осмыслению.

Интересный небольшой (пока) канал по комбинации бизнес-анализа и безопасности IT-систем: https://t.me/AppSecBP. Постов там пока немного, но мне круто зашли в плане расширения кругозора.

Вредные советы начинающему аналитику (https://habr.com/ru/companies/rostelecom/articles/873452/): очередной очерк из рубрики очевидных типовых ошибок, но читается легко и интересно.

Hearing the Customer’s Voice: The Product Champion Approach (https://medium.com/analysts-corner/hearing-the-customers-voice-the-product-champion-approach-55a99e556ad5): дядюшка Карл со своей известной темой про product champions. Полезно вспомнить красивый процесс в вакууме, если труды его читали давно.

Варианты использования (use cases) — не самая популярная нынче техника, но огненно работающая, если пользовать в подходящих ситуациях и под правильным углом. Ниже — несколько не самых очевидных советов (будут разбиты на несколько заметок), которые могут добавить юз кейсам ценности:

1. Все мы понимаем, что юз кейс, как и user story, должен нести ценность для пользователя. Но этого мало, дабы их правильно применять. Юз кейс — это обособленный (дискретный, самостоятельный) кусок взаимодействия, и именно в этом контексте стоит осмысливать его ценность. Что это значит? Я трактую для себя это в виде подхода “подошел к решению -> выполнил юз кейс -> ушёл, получив ценность”. И это важный момент, позволяющий лучше осмыслить даже само название: один из вариантов того, как юзер может воспользоваться решением полезным для себя образом.

Возьмем смартфон. Просто “полезная” операция без учета описанного выше — включить экран. Кто скажет, что это для юзера не ценно? Юзер делает это, чтобы впоследствии что-то нужное ему замутить. По аналогии: напечатать символ, перелистнуть страницу, нажать кнопку “Назад”. Разве не ценны для него все эти действия? Ценны, но тут ломается упомянутая выше цепочка, и с точки зрения самой сути техники это опасный (своей бесполезностью) подход. Ну то есть “А давай подумаем, что там юзерам нужно будет? -> Ну… экран включить, страницы листать… -> А зачем? -> Да какая разница? Мало ли зачем он будет страницы листать?” И вот мы скатываемся в то, что нам лень понимать, зачем решение необходимо юзерам, и тупо клепаем фичи.

Включив экран, юзер не может уйти из системы довольным тем, что он совершил законченное полезное для себя действие (если только он не фанат включения/выключения экранов). Чтобы завершить цепочку, нам нужно довести это до того конца, когда ценность будет осознаваема и юзер сможет отложить смартфон в сторону: например, отправить сообщение, включить фонарик или совершить звонок. Именно для этих операций мы создаём смартфон как решение, а не для включения экранов и листания страниц. И именно в таком преломлении юз кейсы становятся эмпатией пользователям и ориентированным на них подходом. Оно же помогает определять ценные инкременты по заветам отцов: вполне может статься, что вам не стоит включать в очередной релиз продукта просмотр списка каких-нибудь товаров (L по CRUDL), если по итогам общения с юзерами вы видите, что ценности в самой этой операции (без возможности просмотреть детали каждого товара — R по CRUDL) нет.

Но есть исключения. Сходу могу выделить два:
а) Как и с любыми правилами: когда вы осознанно нарушаете это во имя некой благой цели. Например, мне не стыдно будет за юз кейс “Залогиниться в систему”, если а) на этапе осмысления ценных операций его не было (и я не проектировал решение как что-то, что должно обязательно включать логин — юзерам он сам по себе нафиг не сдался), б) я добавил его позже для иных целей: например, юз кейсы были выбраны основной техникой структуризации требований, и скоуп без логина, вынесенного явно, выглядит для стейкхолдеров неполным и не наглядным.
б) Если вы используете отношения extend или include между юз кейсами — на диаграмме или просто в рамках их документации. Суть расширения и включения как раз в том, что включаемые и расширяющие юз кейсы могут и не быть самостоятельно ценными.

2. Предусловия. Все мы понимаем, что предусловия (preconditions) — это что-то, что должно быть истиной в контексте юз кейса на старте. Многие на этом останавливаются, а потому для входа в систему выделяют такие предусловия, как “У юзера на руках корректные логин и пароль” или “Юзер хочет войти”.

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

а) Предусловия — это состояния чего-либо в рамках решения (а не юзера или контекста). Нам нет смысла продумывать условия вида “У юзера не сломаны руки”, “Юзер имеет логин/пароль на руках” или “За окном — благоприятствующая юз кейсу погода”. Так как внутри юз кейса мы документируем требования к решению (и даём инструкции разработчикам, тестировщикам и прочей исполнительской братии), то все это лишняя не несущая целевой аудитории ценности писанина. Какая разработчику разница, есть у юзера на руках или в мозгу корректные логин и пароль перед стартом юз кейса? Разработчик никак не может проверить это в коде. Нам важно дать разработчику знать, при каких условиях (в истинности которых система может убедиться, т. е. разработчик может вложить эту проверку в систему) надо давать юзеру возможность стартовать юз кейс: например, показывать юзеру страницу логина нужно только тогда, когда у него нет активной сессии; сделать недоступной кнопку редактирования записи, если нет ни одной созданной записи; не давать возможность просмотра своего профиля, если не выполнен вход в систему.

б) Предусловия — это про “начать”, а не “успешно выполнить”. Проще переформулировать так: это условия, при которых актер сможет выполнить первый шаг юз кейса. Сможет или не сможет актер успешно выполнить сам юз кейс до конца — это иной вопрос. Конечно, нам нужно предусмотреть, что может на каждом шаге пойти не так, и вложить в систему дружелюбные реакции на это — это будут наши исключительные сценарии, но это не имеет никакого отношения к предусловиям. Любой, кто умеет читать юз кейсы, будет трактовать предусловия как что-то, что актуально только для старта юз кейса. Например, “Актер помнит свои логин и пароль” (такая формулировка, кстати, в принципе не может быть проверена нами — см. пункт выше) намекает читателю на то, что в самом юз кейсе обрабатывать ситуацию, когда он не их знает, не нужно, а это едва ли верно.

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

Коллеги, ну что, двинем практику дальше? 😊

Предлагаю описать требования к данным - штука полезная и интересная. То есть LDM (Логическая модель данных), плюс словарь данных. В идеале круто, если эти требования будут в ногу с описанным вами или кем-то другим ранее скоупом (и вы его там рядом приведете).

Ресурсы в тему:
https://shesterov.by/tpost/pgu0yucas1-uml-class-diagram
https://shesterov.by/tpost/j9acle3jd1-model-predmetnoi-oblasti-i-logicheskaya

Продолжение темы с не самыми очевидными советами по юз кейсам. Сегодня — про постусловия и исключения.

3. Постусловия. Мы часто трактуем это как результат выполнения юз кейса, но чтобы сделать этот компонент практически полезным, стоит добавить пару уточнений. Вначале сформулируем: постусловия — это состояния решения после выполнения юз кейса.

По пунктам:

1) “… решения”. Как и с предусловиями, акцент нужно сделать на решении, а не на юзере или ином контексте. Напоминаю, что юз кейс — это инструкции команде разработки, т. е. требования к решению. Постусловие вида “Актер просмотрел список товаров” бессмысленно, т. к. мы не можем в этом убедиться, не реализовав трэкинг его очей. В чем мы можем убедиться, так это в том, что “Список товаров в системе отображен на экране”.

2) “СостояниЯ…” Это не просто результат выполнения юз кейса, а всякие-разные состояния, которые нам важно подчеркнуть, чтобы разработчики, тестировщики и прочие убедились в том, что это реализовано. Например, для логина это может быть такой список: “Актер аутентифицирован в системе; актер находится на домашней странице; запись об успешном входе добавлена в логи.” Все это должно быть прослеживаемо по шагам в сценариях, но здесь мы собираем воедино все те выходные состояния, которые считаем важными для итоговой наглядной суммаризации: “Бойцы, убедитесь, что по результатам выполнения юз кейса вот эти вещи — истина”.

3) Есть разные взгляды на то, актуальны постусловия только для успешного выполнения юз кейса (основной и альтернативные сценарии) или и для неуспешных тоже (исключительные сценарии). Тут просто имейте в виду, что никто не мешает делать так, как лучше работает для коммуникации требований команде. Мне вполне нравится подход подчеркнуть и те постусловия, которые я хочу явно вынести для читателей в контексте ряда исключительных сценариев. Например, для логина постусловием в случае неуспешного входа может быть “Запись о попытке логина добавлена в логи”. Важно только наглядно подчеркнуть, для каких сценариев какой набор постусловий актуален.


4. Исключительные сценарии:

Как искать исключения (т. е. то, что не приводит к успешному завершению юз кейса в отличие от основного и альтернативных)?

Понятно, что это важная штука в функциональных требованиях. Без них требования сформулировать весьма просто; исключительные же сценарии начинают напрягать нашу думалку. Если мы структурированно подали шаги всех успешных сценариев, то поиск исключений не должен вызвать проблем. Подход прост: смотрим на каждый шаг успешных сценариев и начинаем брейнстормить: “Что тут может пойти не так?” При этом важно помнить две штуки:

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

- Исключения — это не только “что-то пошло не так”. Это ещё и когда актер сам направил юз кейс в неуспешную сторону (типовой пример — отмена операции).

Пример: Войти в систему

1) Актер открывает страницу входа. Тут может упасть Интернет, в сервер может вдарить метеорит или в мире поднимется зомби-восстание (и актеру будет уже не до входа). Нас такие исключения волнуют? Нет, ибо мы не хотим / не можем обработать подобное реакцией системы.

2) Система отображает эту страницу. Аналогично. Едва ли тут что-то может пойти не так, не считая каких-то багов (система лежит и не может отдать страницу). Баги нас также не волнуют, т. к. это не требования, которые мы хотим вложить в поведение системы. Бонусом, правда, можно обдумать те редкие ситуации, когда мы костыльным образом вкладываем реакции системы на внутренние баги: например, зная, что в бизнес-логике часто происходят незначительные ошибки, мы вместо того, чтобы это пофиксить, добавляем сообщение вида “Операцию сделать не удалось — внутренняя ошибка”. При этом контекст таков, что пока такое сделать проще и дружелюбнее, чем оставить падения системы и упорно фиксить все эти баги до лучших времен.

3) Актер вводит логин и пароль и подтверждает вход (объединю это все для упрощения). Какие ситуации вы бы тут хотели обработать?

Например, актер ничего не вводит, и мы хотим подсветить обязательность полей; актер вводит логин в неверном формате, и мы хотим ему об этом сказать; актер два раза нажимает на кнопку вместо одного (не знаю, что тут плохого именно в данной операции, но вдруг вы захотите, чтобы система на такое отреагировала). Все это тогда исключительные сценарии. Разные ли? А это зависит от того, будет ли уникальным набор шагов в них. Если в каждом из них будет одна и та же реакция системы (Система отображает “Что-то пошло не так”), то нет, не разные. Но это явно не рекомендуемый вариант в плане понятности реакций для пользователя.

4) Система проверяет валидность указанных параметров. Аналогично шагу 2 тут вряд ли что-то пойдет не так, не считая внутренних дефектов, если проверка идет по внутренним данным. А что, если проверка идет по внешнему источнику, например, по сторонней (вне текущего решения) БД или через обращение в сторонний сервис? Такое однозначно надо обрабатывать, т. к. внешние интерфейсы — вне зоны нашего контроля. И нам стоит предусмотреть ситуации, когда они недоступны, возвращают ошибки, плюс реакцию нашей системы на такое — едва ли мы хотим, чтобы у юзера на экране была вечная загрузка или система свалилась.

5) Система перенаправляет актера на его домашнюю страницу. Тут в комбинации с предыдущим шагом может быть очевидная неверность связки логина и пароля. Естественно, это то исключение, которое надо очертить. Или не связки, а по отдельности (логина в списке нет; пароль для существующего логина неверный) — тогда, если реакции разные, это два исключения.

6) Что еще? Если выйти за рамки UI для конкретно данного процесса, можно повертеть в голове такие варианты, как актер закрывает окно браузера, нажимает на лого на странице входа и прочие подобные моменты, когда актер может прервать операцию. Хотим ли мы, чтобы система в данном юз кейсе уникально на это реагировала (см. совет в п. 1 выше)? Вряд ли, но если вдруг вы хотите, чтобы при закрытии браузера система показала попапчик *“Вы точно уверены в том, что хотите прекратить вход?”*, то да, такое тоже добавляем в исключения для юз кейса входа.

Вот к этому посту в комменты можно добавлять работы (LDM, словарь данных), разборы, вопросы, комментарии и т. п. Напоминаю, что исходное условие проекта тут: https://t.me/itmineba/198

Последние пара советов по юз кейсам (ВИ, варианты использования) из области не очень очевидных — на этот раз даже с картинками 🙂

5. Осознанная “игра” UI в сценариях юз кейсов. Периодически вижу безапелляционную рекомендацию не затрагивать UI в формулировке шагов юз кейсов. Мне это кажется слишком ограничивающим, и больше по душе два варианта: “интерфейсозависимые” (это когда мы оперируем нашим UI в шагах и иных параметрах ВИ) и “интерфейсонезависимые” (когда сознательно абстрагируемся от UI) юз кейсы. Термины, если что, собственные. По аналогии с User Stories это один из способов сделать юз кейсы negotiable, т. е. сознательно пожертвовать детализацией во имя благих целей.

Два ключевых фактора, которые влияют на выбор подхода: задачи, которые мы решаем с помощью ВИ, и зона ответственности аналитика (проще говоря, входит ли проработка UI в работу аналитика или нет). Обе эти вещи часто варьируются от проекта к проекту, в особенности при смене заказчика и команд. Примеры ситуаций:

1) Юз кейсы прорабатываются уже на этапе общения с пользователями, и мы хотим вначале постичь полную картину user requirements. В этом случае, дабы не привязываться ментально к на ходу спроектированному UI, а сфокусироваться на user flows, я использовал бы интерфейсонезависимые юз кейсы.

2) Юз кейсы — техника спецификации требований, и функциональные требования не описаны где-либо еще. В таком случае, добавив макеты, я однозначно пользовал бы UI в шагах таких юз кейсов. В комбинации получается вполне себе рабочий способ подачи требований.

3) Вариант, аналогичный предыдущему, но представим, что помимо юз кейсов мы документируем UI где-то еще — например, описываем контролы где-то отдельно. Тут я бы не использовал UI внутри юз кейсов, т. к. мы придем к дублированию информации и усложнению поддержки требований. Т. е. ВИ тут служили бы описанием user flows для понимания контекста, а описание UI — детальной спецификацией для команды.

4) Вариант, аналогичный предыдущим двум, но с дополнительным контекстом: UI — не на плечах аналитика, т. е. есть дизайнер, юиксер и иже с ними, чьи руки заточены под эту задачу. В этом случае во всех своих требованиях я осознанно абстрагировался бы от UI, чтобы не лезть не в свое дело и не налагать лишних ограничений на работу экспертов.

На картинке — пример одного и того же ВИ в обоих форматах.

6. А вы знали, что extend, include и generalization полезны не только как связи на диаграммах упоротого по UML аналитика? Это отношения между ВИ, которые могут оказаться полезными и в их детализации (при условии, что мы пришли к точке, где наша ЦА понимает смысл этих связей).

Include — это когда один ВИ обязательно включает в себя другой в каком-либо из сценариев. Весь включаемый ВИ становится шагом включающего.

Extend — это когда один ВИ опционально дополняет собой другой. В какой-либо точке сценария расширяемого ВИ поток (по желанию актера или иным условиям) может перейти на выполнение расширяющего ВИ, чтобы затем вернуться обратно.

Generalization — реализация механизма наследования из ООП: это когда один юз кейс является абстракцией нескольких более конкретных. За счет этого у родительского ВИ есть какие-либо общие для дочерних ВИ параметры.

Чем сие хорошо:

- Не-дублирование требований (повторяющиеся подпроцессы мы можем вынести во включаемые и расширяющие юз кейсы, плюс можем объединить схожие юз кейсы через обобщение и не-дублировать пред-, постусловия, шаги и прочие параметры).

- Помогает добавить смысла в наши юз кейсы в плане того, как некоторые ВИ связаны между собой. Это даст больше понимания о сценариях использования решения, нежели кучка изолированных ВИ.

- Сохраняем связи из диаграммы ВИ в тексте спеки, если диаграмму мы также рисуем. А когда разные формы подачи требований между собой синхронизированы, это всегда хорошо — помогает не допустить глупых ошибок и сохранить однозначность требований.

Больше деталей и примеры — на картинках.

Снова подборка недушных материалов, чтобы стать чуточку умнее:

How Much Scope Does a Project Need? (https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/6686/How-Much-Scope-Does-a-Project-Need.aspx): заметка без откровений, но на любопытном примере освежает в памяти ряд азов БА и бенефиты от них.

20 Useful Phrases for Online Meetings (https://blog.english4it.online/20-useful-phrases-for-online-meetings-0a086b3d0958): Опять пытаемся выйти за рамки лет ми спик фром май харт. Как обычно от этих авторов, крутая практическая применимость: реальные рабочие выражения, которые полезно вспомнить или добавить себе.

Манифест аналитика (https://habr.com/ru/articles/882966/) — советы для начинающих на базе набитых шишек.

Пять болей аналитиков и как с ними справляться (https://habr.com/ru/companies/korus_consulting/articles/882146/) — то же самое, только советы другие, да примеры подетальнее.

И парочка интересных постов:

https://t.me/AppSecBP/20 — про attacker stories и требования к безопасности.
https://t.me/systemswing/583 — вроде раньше не кидал сюда, но мощная штука от мощного автора: типы интеграций в одной картинке. Вдруг тут обитают и системные аналитики. Для БА же это, скорее, открыть, попытаться вчитаться и закрыть с чувством, что мы теперь немножко архитекторы.

Ещё в копилку:

Шпаргалка тестировщика (https://www.linkedin.com/posts/evgeny-gusinets_шпаргалка-тестировщика-activity-7299477370451759104-6K4t) - несмотря на название, это в целом шпаргалка для начинающего айтишника. Интересно поданный и довольно комплексный IT-конспект. Рекомендую полистать. И даже тестирование на том уровне, который аналитику будет совсем не лишним.

Про понять/объяснить сложные вещи (https://youtu.be/cSc8Cz2CUg4?si=S5gDo-VYKTnRbu8e) - ламповое видео с рядом полезных техник для аналитиков.

Салют!

Поделюсь интересным чтивом, но сначала ответ на периодический вопрос о том, куда подписаться.
Вы, вероятно, заметили, что мы тут редко делимся каналами или, упаси боже, их подборками, кочующими туда-сюда для нагона аудитории. Серьёзно, я раз 10 уже отказывался от предложений в стиле “делаем общую подборку про нас и дружно постим заготовку для взаимного пиара”. Мне интересно наносить непоправимую пользу условным десяти человекам и совсем неинтересен дженерик-булшит для массовости. К сожалению, на тему БА/СА у меня таких процентов 90 в подписках: пятикратно переваренная теория, подборки в стиле “100 книг для БА” (такое кому-то пригодилось когда-нибудь?), реклама, а недавно ещё и новый тренд - файлообменник для книжек (монетизируемых авторами и издательствами, Карл).

В общем, если ссылки, то только точечные - осадок после фильтрации, который зашел (последний канал, кстати, довольно часто радует крутым авторским контентом, и это не реклама):

https://t.me/apiaryanalyst/46 - любопытный кейс собеседований.

https://t.me/tosibosiba/160 - хорошая подборка вопросов работодателю на собесе или где-то около.

https://t.me/systemswing/637 - карточки про AI и аналитика. Кратко, но интересно.

https://t.me/systemswing/666 - комикс про agile, местами очень жизненный.

Привет всем! Если помните, когда-то мы обсуждали идею стримов-собеседований (тестовые открытые собеседования для jun BA или где-то около того в онлайне: анализ резюме, беседа, фидбэк) - наподобие того, что раньше были от analyst.by. Давайте вернёмся к этой идее. Напишите мне в личку (@g.shesterov), если хотели бы в таком поучаствовать в качестве испытуемого.