Русский
Конференции для профессионалов индустрии информационных технологий

Леонова Наталья

Бизнес-аналитик
Devexperts
Россия
Санкт-Петербург

Биография:

Тестировщик, перешедший на сторону бизнес-анализа. Люблю коммуникации во всех их проявлениях, новые предметные области и понятную документацию.

Доклады

Поэтом можешь ты не быть, а инженером быть обязан (или почему аналитики-мастера слова)

15.11.2020

Размышления о развитии аналитика в профессии наталкивают нас на разные пути - иногда это ведёт в менеджмент, дизайн, иногда в развитие технических навыков и концентрацию на "обратной" стороне работы с требованиями. Но то, что остаётся неизменным - это коммуникация и построение правильных контактов со всеми заинтересованными лицами, да и просто с людьми, которые нас окружают. Меняются методологии разработки, тренды индустрии, но взаимодействие и построение правильных каналов коммуникации становится всё более важным. Каждый месяц появляются новые инструменты - возьмём хотя бы Zoom, Google Hangouts, Slack (и это только часть). Но это движение иногда идёт вразрез с инженерной культурой и классической моделью развития аналитика. В докладе мы поговорим о теории коммуникации, когнитивных моделях, а также о том, почему гуманитарные знания могут дать нам тайные инсайты. Рассмотрим несколько живых примеров и увидим, как на самом деле это живёт в нашей ежедневной работе.

Уровень сложности
Блиц доклад (20 мин)

Сколько осталось жить ТЗ ?

15.12.2019

С одной стороны, Техническое задание умереть не может. Спецификация требований есть прямое выражение сути системного подхода и мышления. Чем сложнее система тем больше аккуратности и внимательности требуется при внесении любых изменений. И создаваемые системы проще не становятся...
С другой стороны, Факты упрямая вещь - честная процессная/архитектурная работа с каскадом сформированных спецификаций, классические переходы As-Is To-be попадаются гораздо реже, из стартапов рождаются единороги, и там точно не было и не ожидается никаких спецификаций...

Приглашаем к обсуждению на круглом столе:

  • Влияние на Бизнес и Системный анализ двух парадигм: проектной и продуктовой.
  • Как переходить от одной парадигмы к другой с минимальными личными и организационными потерями.

Уровень сложности
Круглый стол

Особые требования - описать и проанализировать!

22.01.2018

Требования - основа основ для аналитика. Не имеет значения, в какой предметной области работает аналитик, какой проект он ведёт и какая методология разработки ПО используется  - каждый раз главной задачей аналитика является выявление, анализ и описание требований. Но требования бывают разные, и иногда аналитикам и всей остальной проектной команде приходится сталкиваться с новым уровнем сложности - "особыми" требованиями, которые несколько выходят за рамки стандартного мира IT.

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

Уровень сложности
Блиц доклад (20 мин)

Коммуникативные неудачи и их друзья

14.12.2016

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

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

Рассмотрим ряд терминов и понятий, которые помогут легче справляться с трудностями коммуникации и помогут начать "называть вещи своими именами". На примере мультилингвального проекта проверим, что это действительно работает. 

Уровень сложности
Блиц доклад (20 мин)

Как мы специфицировали проект с помощью UML

04.12.2015

Бизнес-аналитикам приходится писать документацию в разных условиях – не всегда понятно сразу, что хочет заказчик. Бывают ситуации, когда требования и спецификация пишутся уже после «магии» разработки.


В докладе мы рассмотрим проект, к которому аналитики подобрались после разработчиков, а основной задачей было найти удобный вариант документации, который бы устраивал всех членов проекта.


Ситуация усложнялась интернациональным коллективом - разработка и часть анализа из Петербурга, а заказчики - из Германии.  Выяснилось, что с обычными спецификациями не всё проходит гладко и документы слишком быстро устаревают. Мы попытались решить эту проблему с помощью языка моделирования UML, и описывали требования с помощью диаграмм, используя инструментарий Enterprise Architect.


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

Уровень сложности
Секционный доклад (40 мин)

Эффективное взаимодействие тестировщика и аналитика

11.09.2015

В процессе разработки программного обеспечения коммуникация между командами тестирования и аналитики неизбежна. Чтобы тестировщик имел в руках понятную и качественную документацию, а аналитик понимал, что ему следует изменить / переформулировать / подробнее описать, требуется диалог и взаимодействие. Также все члены команды должны четко понимать, с чем и с кем имеют дело - аналитики бывают разные и иногда говорят на непонятном другим языке. Все мы знаем, что правильное (вотерфольное) тестирование должно начинаться как можно раньше, а именно - с документации. Соответственно, вопросы тестировщиков к аналитикам возникают уже на ранних стадиях создания / написания документации, да и в целом общение между двумя лагерями идет гораздо активнее, чем кажется. Поэтому, а также по ряду других причин аналитик со всех ног бежит трясти тестировщика - всё ради качества ПО! Ярким примером также являются многочисленные тулзы для синхронизациии тестов и требований, например, Polarion или QC.

Уровень сложности
Блиц доклад (20 мин)