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

Регулярно наблюдаем следующую картину: приходит человек устраиваться на работу. Ты его спрашиваешь - ну хорошо, хочешь быть аналитиком. А что дальше? Что после того, как станешь крутым аналитиком? Ответ стандартный: дорастем - увидим.

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

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

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

Компьютер и программное обеспечение – лишь средство автоматизации информационного обмена. Они могут существенно ускорить и упростить его там, где он есть. Но технические средства не могут создавать информационного обмена.

• Как быстро и технологично создавать единое терминологическое и информационное пространство в компании?
• Как организовать информационный обмен в рамках этого пространства?
• Что разрушает информационный обмен и препятствует его восстановлению?
• Как превратить развитие единого информационного пространства в развитие компании?

В рамках круглого стола будет представлена методика, которую участники смогут опробовать на нескольких примерах.

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

Чтобы все это увязать и управлять придумано много фреймворков - Zachman, TOGAF, FEA и т.д. И везде требования ставятся во главу угла. Но нужны ли все практики и такие сложные фреймвоки? В каких российских компаниях они внедрены? Мне кажется, что можно взять из этих фреймворков все самое лучше и необходимо и построить свой подход по управлению корпоративной архитектурой.

В докладе будет представлены основные проблемы связанные с изменениями в больших компаниях, подход по управлению требованиями и изменениями в них. 

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

Увеличилось и количество проблем в коммуникациях между аналитиками:

• Если раньше ты примерно понимал сферы компетенции своих коллег и гораздо проще было воспользоваться их опытом в каком-то вопросе, чем тратить время на поиски, то с ростом численности отдела появилась большая неопределенность.
• Возникли проблемы с передачей знаний. Беседы за чашкой чая уже не спасали.
• Стало сложнее уследить за вектором развития каждого отдельного сотрудника. Интересны ли ему проекты, предметная область? Чем еще он хотел бы заниматься? 

В результате анализа возникших проблем было принято решение о создании сообщества аналитиков внутри компании.

В своем докладе я хочу рассказать об опыте создания такого сообщества, включая:

• Эволюцию идеи и реализации от создания простой группы рассылки до полноценного сайта сообщества.
• Выбор инструментов для реализации сайта сообщества: из чего выбирали, почему выбрали конкретный инструмент, какие были плюсы работы в нем и какие проблемы.
• Способы вовлечения сотрудников в работу сообщества. Какими плюшками мы замотивировали людей создавать контент, проводить семинары и отвечать на вопросы новичков.
• Разделы сообщества: что сделано, что в проекте, что пользуется максимальной популярностью.
• Какие плоды принесло это дерево. 

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

При создании программного обеспечения нередко возникает непонимание между различными группами заинтересованных лиц (заказчиками, аналитиками, разработчиками и другими). Это неизбежно вызывает расхождение между пожеланиями заказчика и готовым продуктом. Особенно много недоразумений обычно связано с реализацией, т.к. для участников проекта, не являющихся программистами, код представляет собой ‘чёрный ящик’ и почти не поддаётся контролю.

Что системному аналитику делать с чёрным ящиком? В докладе рассматриваются некоторые приёмы, способствующие организации эффективного взаимодействия с разработчиками.

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

Вопросы:

1) постановка задачи: какие же проблемы мы хотим решить?

2) варианты реализации управления изменениями: в рамках одной версии, в рамках нескольких версий

3) цикл жизни артефактов проекта - а за всеми ли изменениями нужно следить?

В целом доклад базируется на моем вебинаре https://www.webursitet.ru/article/versionirovanie-trebovanii--zapis-vebinara.html , поэтому буду рада вопросам, которые покажут, в какую сторону надо развить тему.

Основные тезисы доклада:

1. Проблема: заказчик не всегда осмысленно участвует в сборе требований.
2. Почему так получается?
3. Как убедиться, что все хорошо и заказчик понимает о чем вы написали?
4. Зачем добиваться понимания требований заказчиком

• В чем выгода исполнителя.
• Чем такой подход лучше заказчику.
• Дополнительные бонусы.

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

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

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

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

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

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

Заявка на второй день. Ориентировочное время 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

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

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