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

С 12 мая 2014 года международный институт бизнес-анализа IIBA проводит публичное обсуждение следующей версии свода знаний по бизнес-анализу BABOK Guide v3.  Одним из отличий этой версии от предыдущих является появления раздела «Perspectives», обсуждающего использование общих практик и методик анализа для частных дисциплин, востребованных в той или иной области деятельности организации. В текущей редакции документа список перспектив включает:

• Agile,
• Business Intelligence,
• Information Technology,
• Business Architecture, and
• Business Process Management

Тем самым дисциплина бизнес-анализа выходит за пределы практики управления требованиями в рамках ИТ-проекта и становится полноценнвм инструментом управления изменениями в организации.  Похожая трансформация в свое время произошла с ИТ архитектурой, выросшей из практики проектирования ИТ-решений в инструмент управления продуктами, процессами, структурой и стратегией организации.

Дискуссионный стол будет посвящен обсуждению перечисленных выше перспектив.

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

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

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

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

• Предпосылках появления методики.
• Решаемых задачах и используемом инструментарии.
• Областях применения методики.

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

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

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

Наш мозг имеет определенные особенности. Сами того не осознавая мы воспринимаем мир не таким, каков он есть.

Вот например, одно из изображений воспринимаемых неправильно: 

Часть беых точек мы не воспринимаем. Глаза видят, но постобработка мозга дает нам неверную картину. Это один из вариантов "ложной слепоты".

Кроме "ложной слепоты" существует множество других особенностей мозга, препятствующих объективному восприятию мира. Для того, чтобы воспринимать мир более объективно требуется во первых знать об особенностях нашего мышления, во вторых знать приемы нивелирования искажений.

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

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

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

Вакансии врут. Компании ищут аналитиков с навыками, которые им потом не требуются. Аналитики продают компаниям опыт, который потом не пригодится в проектах. Кто кого обманывает понять уже невозможно.

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

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

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

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

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

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

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

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

• Как максимально быстро  и глубоко собрать полезные требования к системе? Без этого недовольство заказчика и демотивация участников проекта обеспечены.
• Как максимально точно и быстро отсечь "мусорные" требования к системе? Это позволит не делать лишнюю работу и не затягивать проект.

Есть способ решить эти вопросы методично и с низкой себестоимостью – с помощью специализированной проектной коммуникационной системы.