На встречи нашего Сообщества регулярно приходят аналитики, тестировщики, технические писатели, которые недовольны непредсказуемостью работы в проекте и спрашивают: "Как продать бизнес-анализ своему текущему руководителю".
Признаюсь, что сама неоднократно занималась этим неблагодарным делом. И ни разу мои усилия не увенчались успехом, т.е. ни результаты бизнес-анализа не были в сколько-нибудь серьезном объеме взяты в работу, и процессы работы в команде не перестраивались в обозримом будущем.
Почему же это не получилось не смотря на то, что я была уверена в целесообразности и качестве моей работы? На мой взгляд, по причине того, что я "продавала" бизнес-анализ не тем людям, не понимала интересов руководителей.
Расскажу, что говорят про это сами руководители, критерии выбора "продавать/не продавать", которые я выбрала для себя.
Для большинства сервисов, как правило, существует ограниченный набор вариантов пользовательского взаимодействия. Главенствующую роль здесь играют нефункциональные требования. Именно от их соблюдения и зависит качество работы сервиса. А можете ли вы с уверенностью сказать, что, например, производительность вашей системы, соответствует требуемой? На чем основана ваша уверенность? Когда у вас нет средств контроля, эксплуатация такой системы подобна езде по скоростной автостраде с закрытыми гразами. В своем докладе, я хочу рассказать о том, как мы "открывали глаза" создавая систему контроля нефункциональных требований, с какими проблемами нам пришлось столкнуться и какие мы из всего этого сделали выводы.
Представьте себе, что вы как аналитик попали в проект со сложившейся историей разработки и взаимоотношений с Заказчиком. Какие сюрпризы поджидают аналитика на таких проектах, чего ждать и к чему готовиться? Что нужно будет делать и с чем смириться, а что лучше не делать? Об этом я расскажу в своем докладе.
Доклад ориентирован на начинающих аналитиков.
Цель доклада - сформировать представление об основных ситуациях, с которыми аналитик может столкнуться на проектах с историей, а также вариантах решений для выхода из них.
Разрабатывая новую информационную систему или внедряя уже существующую, вы неизбежно сталкиваетесь с необходимостью определить нефункциональные требования к вашей системе.
Выступление о том, какими бывают нефункциональные требования, как их определять и как с ними работать.
Многие годы практически применимые описания решений (англ. decision) и бизнес-правил (англ. business rule, BR) строились на основе математических формул, естественных языков и имели вид слабо формализованных матриц и каталогов. Ситуация решительным образом изменилась в сентябре прошлого года, с выходом в свет спецификации Object Management Group, представившей принципиально новую нотацию и подход к моделированию Decision Model and Notation (DMN™).
Отличительными чертами DMN являются компактность и простота, а также возможность эффективно использовать DMN совместно с нотацией и подходом к моделированию бизнес-процессов BPMN. Кроме того, владение DMN как передовым стандартом бизнес-моделирования постепенно и неуклонно становится одной из базовых компетенций современного аналитика.
В рамках предстоящего мероприятия, — которое скорее будет похоже на мастер-класс, а не классический «круглый стол», — мы не только познакомимся с нотацией DMN 1.0, но и решим несколько практических задач по моделированию решений и бизнес-правил, в том числе в контексте совместного применения DMN и BPMN 2.0.
Докладчик Рахимова Гузель, компания “Центр Высоких Технологий”
Вопросы:
Пользовательские аспекты
Технологические и технические аспекты
Тезисы:
В своем докладе я хочу раскрыть вопросы, связанные с анализом требований для мобильных приложений. На что следует обратить внимание в первую очередь при проектировании пользовательского поведения, какие бывают технологические ограничения и каким образом лучше проводить согласование работ.
Кратко о себе:
Рахимова Гузель, https://www.facebook.com/r.guzelle
Руководитель проектов, ведущий аналитик
1. Какие методики проектирования приняты на веб-разработке - и почему они работают через пень-колоду;
2. Что такое продукт - и почему понимать проектирование продукта в 100 раз важнее, чем проектирование интерфейсов;
3. Проектирование продукта по методу "тупо в лоб": плюсы, минусы, адские моменты;
4. Проектирование продукта по гибкой методологии: противостояние хаосу методом хаоса;
5. Почему вам нужно забыть про ТЗ, прототипы и прочие артефакты - и что нужно помнить взамен.