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

В докладе я покажу и расскажу:

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

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

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

Мой доклад посвящен третьей позиции. Я хочу поделится своими соображениями и шишками, которые я набил, выстраивая учебный центр в нашей компании. Особое внимание хочу уделить практическим соображениям. Обзору (краткому) продуктов, в частности Viewlet Builder и moodle, как средствам или среде построения образовательного контента и образовательной системы, центрилизирущей процесс цивилизованного общения с пользователями клиентов.

Опыт небольшой, потому одна из задач получить добрую обратную связь.

Позиция бизнес аналитика (БА) в проекте - это позиция особая. БА - это представитель заказчика в проектной команде и представитель технической команды в глазах заказчика. Мы знаем, что научиться говорить на языке бизнеса - это одна из главных задач БА. Но, при этом мы зачастую забываем, что БА, это еще и технический специалист, это IT специалист. 

В то время, когда весь IT-шный мир, т.е. разработчики, специалисты по контролю качества (QA, тестировщики), свободно "говорят" на языке UML и используют объектно -ориентированнный подход, аналитики имеют достаточно слабое представление в этих областях. Как результат: собственно процесс бизнес-анализа проводится спонтанно и непоследовательно, достаточно большие области знаний о бизнесе остаются "за бортом" внимания аналитика, не покрываются и не описываются, разработанные аналитиком документы скорее похожи на документ исследование бизнеса, чем на документацию, написанную для технических потребителей, т.е. требуют проведения достаточно болшой работы на стороне разработки для "перевода" на технический язык, что приводит к неоднозначности или неверной трактовке требований.

В данном докладе, я расскажу об опыте использования объектно-ориентированного подхода в бизнес анализе. В рамках использованного подхода, шаг за шагом, последовательно переходя от дного этапа (модели) к другой, были проведены работы по бизнес анализу и, какрезультат, разработке требований. При использовании данного последовательного и ясного подхода, мы были гарантированны от "белых" пятен в проведенном этапе бизнес-анализа, и разработанные требования не требовали дополнительного "перевода" на язык разработки.    

Я хочу рассказать о своём опыте проведения 4-хмесячного онлайн-курса «Разработка требований к ПО».

1. Какие цели я для себя ставил.
2. Как была устроена программа и формат обучения.
3. Кто учился на курсе.
4. Что у нас получилось хорошо.
5. С какими мы столкнулись трудностями.
6. К каким выводам я пришёл, что могу порекомендовать будущим ведущим и участникам онлайн-курсов.

Заявка на второй день. Ориентировочное время 30 минут.

Во многом повторяет выступление Ашманова в августе 2011 http://vimeo.com/26868924 , но кризис роста организации рассматривается с точки зрения теории ограницений, известных когниктивных искажений и теории Адизеса. 

PS. Мои доклады зачастую рассчитаны подготовку выше среднего. Возможно, для лучшего понимания и более полного участия в диалоге стоит посмотреть дополнительные материалы указанные тут: http://softwarepeople.ru/2013/docs/11_2_05_SergeY_Martynenko_Vlijanie_variacij_na_hod_proekta_i_metody_protivodejstvija_uvelicheniju_sroka.pdf

Я бы хотел поговорить  о разных стилях общения с клиентом на этапе сбора и обсуждения требований.

БОКС
Метод простой и прямолинейный. Вы - профи,  клиент не специалист. Вы – авторитет, он, в лучшем случае, любитель. В конце концов, он к вам пришел за советом и помощью, так пусть слушает, что ему говорят!

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

О том, какие вопросы бывают, и как их лучше использовать, я бы и хотел поговорить.

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

В докладе будет рассказано о практике применения методологии ARIS на стадиях документирования и верификации требований в сложившихся условиях.
Доклад будет содержать:
- характеристику методов оптимизации бизнес-процессов ARIS;
- примеры использования методов ARIS для моделирования и реализации бизнес-процессов;
- обзор моделей VAD и eEPC;
- примеры использования ARIS для формирования границ проекта, согласования верхнеуровневых требований с заинтересованными лицами;
- характеристику взаимосвязей моделей ARIS и аналитических артефактов проектов;
- преимущества и недостатки использования методов ARIS.

Доклад рассчитан на специалистов, которым будет интересно узнать новое о методологии ARIS и сравнить с другими известными методологиями.

Как говорит ТРИЗ "в случае, если сложно произвести необходимое действие с объектом, производят противоположное действие: например, сделать движущуюся часть объекта или среды неподвижной, а неподвижную движущейся или повернуть объект "вверх ногами", вывернуть его.". Сложно у нас в работе аналитика бывает не всегда, но я предлагаю не ждать сложностей и попробовать вместе повыворачивать бизнес-анализ наизнанку заблаговременно (:

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