Неоднократно возвращаюсь к этому видео, мне как начинающему BA невероятно полезно. Елене громадное спасибо 🙏

@elenagoropeka4786

4 жыл бұрын

Хорошо, что полезно!)

@user-bl6mv4nv9h

11 ай бұрын

​Здравствуйте Елена, хочу задать вам как практикующему БА несколько вопросов. Насколько изменился функционал БА за прошедшее время? Каковы в данный момент основные тренды бизнес-анализа? Как уход из РФ западных компаний и в принципе разрыв отразился на бизнес-анализе?

Девочка огонь!) так живо и интересно всё рассказала. Отдельное спасибо за конкретный пример, который мы увидели своими глазами, а не просто сухую непонятную теорию.

Как же в тему для меня это видео! Я методом перебора пришла к ведению документации в Jira+Wiki, Елена подтвердила верность моей стратегии. Другие фишки ещё подсмотрю и применю. Спасибо огромное 🙏

Это просто кладезь информации для начинающего специалиста!!!!

Спасибо большое, Елена! Очень полезно и наглядно

Очень полезное видео, спасибо большое!

самый крутой подход! проверено неоднократно! Только я бы назвала не Confluence+Jira, а просто Confluence. Фактически все требования там, а джира ссылается лишь туда.

Там где про ветки на 7 минуте рассказываешь нужно поменять на другую структуру, используя User Story Mapping. Такая работа проделывается с продактом. US ориентировать лучше на заказчика, а не на разработчика. Разработчику как не описывай, всегда будет мало :) Тут главное критерии приемки. А вот заказчику такого уровня описаний US должно хватать. И еще такая карта нужна для планирования ресурсом аналитика. И еще: US я бы писал сплошным списком в одной ветке. А вот с помощью макроса вытаскивал Acceptance Criteria в отдельную доку по управлению требованиями. Для этого необходимо разделять Критерии приемки, нумеровать их и тегировать. Так можно отслеживать изменения в конкретной, например, сущности на отдельной страничке.

Девочка огонь!

2:20 Agile это не о том, что требования не пишутся в user story , а о том, что меняются бизнес приоритеты и стратегия. Если вы не написали требования в стори, а потом хотите чтобы команда сидела ночью и дописывала/меняла функционал, который вы не спланировали на начале спринта, то это завтык только того, кто пишет требований, а не разработчик без Agile философии.

Я один не понимаю зачем все НАСТОЛЬКО усложнять?

@user-vr1nl4ml4l

2 жыл бұрын

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