Курс молодого БА: Кто такой бизнес-аналитик? Бизнес аналитик – самая востребованная должность, в области управления бизнес процессами.

Хотите узнать секреты самой многогранной профессии, испытать себя на практике и найти применение своим аналитическим способностям? Наши эксперты бизнес-анализа точно знают, что вам для этого нужно. Подробный рассказ о курсе Business Analysis Education в NIX Solutions, “жизненное” описание профессии, полезные советы и отзывы студентов в нашей статье.

История обучающего курса для бизнес-аналитиков в NIX Solutions началась в 2012 году - именно тогда был проведен первый набор. С тех пор каждый год курс открывает свои двери для новых желающих стать БА, а программа обучения дополняется и обновляется.

Кто такой бизнес-аналитик?

Прежде чем рассказать о курсе, давайте разберемся, кто же такой бизнес-аналитик. Классическое определение из BABOK Guide v3, своду знаний по БА от IIBA , звучит так:

бизнес-аналитик - это лицо, внедряющее изменения (changes) в бизнесе путем определения потребностей (needs) и рекомендации решений (solutions), которые обеспечивают ценность (value) для заинтересованных лиц (stakeholders).

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

Бизнес-анализ для меня - самая интересная специальность в айти.

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

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

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

Евгений, BA эксперт NIX Solutions

Для кого предназначен этот курс?

Курс Business Analysis Education рассчитан на тех, кто всерьёз интересуется бизнес-анализом, но еще не имеет практического опыта в данном направлении. Зато почитал Вигерса, представляет процессы разработки ПО по RUP, Scrum, Kanban, знает в общих чертах, как работает интернет и вебсайты, мобильные приложения и облачные сервисы и, конечно же, уверенно говорит и грамотно пишет на английском языке.

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

Программа курса объемна и требует глубокого вовлечения в процесс обучения, потому занятия проходят в формате 40 часов в неделю в офисе компании и длятся 2 месяца. Такой формат подойдет:

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

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

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

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

Света, выпускница Business Analysis Education и Junior BA NIX Solutions

Чему обучают на курсе?

На курсе вас научат всем необходимым навыкам для работы по вакансии, начиная с высокоуровневого бизнес-анализа идей клиентов, постепенно проходя этапы составления видения проекта, feature-листов, моделей структур данных и процессов, проектирования интерфейсов, и заканчивая полноценным оформлением технического задания в вики-системе. Практика деловой переписки, устных интервью и командной работы.

Каждая тема содержит блок теории (статьи, видео, лекции) и практическое задание со своими сроками и критериями качества. Сдав задание, стажёр получает доступ к следующему модулю или занимается обработкой фидбеков по предыдущему.

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

По выполнению каждого задания стажёр получает оценки, которые и сформируют его итоговую успеваемость. С самыми успешными проводится собеседование на вакансию в компании.

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

Стажировка превзошла все мои ожидания, так как помимо написания документации нас ещё научили выявлять стейкхолдеров, выстраивать дружественный мобильный и web интерфейс, задавать правильные вопросы заказчику, и делать это ПРАВИЛЬНО (тут отсылка к soft skills), и ещё много безумно интересных штук. Я настолько прокачалась, притом в разных направлениях, что в голове не сразу укладывается, что за два месяца можно столько узнать. Нам дали обучающий проект, и мы выясняли всевозможные требования, чтобы написать качественную спецификацию. Это было почти как боевое крещение. Также очень понравилось, что курс проводили аналитики, которые уже были на реальных проектах и знают, зачем нам те или иные знания.

Марина, выпускница Business Analysis Education и Junior BA NIX Solutions

Чему учатся наши студенты

• проводить первичный анализ бизнес-идеи клиента;
• формулировать Vision проекта и составлять Vision and Scope документ;
• проводить интервью и задавать правильные вопросы клиентам;
• проектировать программное решение идеи клиента в нотациях UML, BPMN;
• определять необходимый и достаточный перечень функций будущей системы;
• продумывать удобные и функциональные пользовательские интерфейсы сайтов и мобильных приложений, создавать динамические прототипы;
• подбирать оптимальный способ описания требований в зависимости от типа функционала и оформлять SRS в вики-системах;
• работать с нефункциональными требованиями.

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

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

Приятным сюрпризом оказалось приглашение на новогоднюю вечеринку NIX Solutions, о которой можно написать отдельную статью.

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

Даня, выпускник Business Analysis Education и Junior BA NIX Solutions

Что нужно, чтобы попасть на обучение

• заполнить на сайте;
• получить приглашение на тестирование и успешно его пройти;
• в ходе устной беседы продемонстрировать нашим экспертам знания теории разработки требований к ПО, хороший английский, аналитические способности и желание стать бизнес-аналитиком;
• и получить приглашение на курс Business Analysis Education в NIX Solutions!

Часть 1

Настольный справочник аналитика

Пронеси эту книгу, через поколения, Сынок...

Напоминание

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

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

Так же хочется дополнительно вспомнить о том, что в официальных документах IIBA (организация - автор) присутствует призыв к постоянному совершенствованию «Babok» со стороны аналитиков, за счет применения в своей деятельности новых инновационных подходов и идей. Дерзайте, изучайте, применяйте и делитесь своими эффективными наработками.

О главе первой «Введение»

1.1. Что такое «Babok»?

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

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

Эта глава обеспечивает введение основных концептов в области бизнес - анализа и описывает структуру «Babok». С 2 по 7 главы определяются задачи, которые должны быть выполнены в результате бизнес - анализа. Глава 8 описывает компетенции, которые эффективно поддерживают уровень знаний и навыков бизнес – аналитика в его деятельности. Глава 9 описывает основной инструментарий для практики бизнес - анализа.

1.2 Что такое бизнес - анализ?

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

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

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

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

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

1.3 Ключевые понятия

1.3.1 Домены

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

1.3.2 Решения

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

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

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

1.3.3 Требования

Требование это (по IEEE 610.12-1990):

1. Условие или возможность, необходимая для стэйкхолдерам, для решения проблемы или достижения цели.
2. Условие или возможность, которая должна быть преодолена или выполнена решением или компонентами решения для удовлетворения контракта, стандарта, спецификации или другого формального зафиксированного документа.
3. Задокументированное представление состояния или возможности, как в (1), так и в (2).

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

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

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

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

1.3.3.1 Схема классификации требований

Для целей «Babok» представлена следующая схема классификации требований, используемая для их описания:

• Бизнес – требования это высокоуровневое представление целей, задач или потребностей предприятия. Они описывают причины, почему проект был инициирован, цели, которые проект должен достичь, и метрики, которые будут использоваться для измерения его успеха. Бизнес требования описывают потребности организации в целом, а не отдельной группы или стэйкхолдеров. Они разработаны и определены благодаря анализу предприятия
• Требования стэйкхолдеров это состояние потребностей конкретных стэйкхолдеров или группы стэйкхолдеров. Они описывают потребности, которые имеют стэйкхолдеры и то, как стэйкхолдеры будут взаимодействовать с решением. Требования стэйкхолдеров выполняют роль моста между бизнес требованиями и различными группами требований решения. Они разработаны и определены с помощью анализа требований.
• Требования решения описывают характеристики решения, которые удовлетворяют бизнес требованиям и требованиям решения. Они разработаны и определены с помощью анализа требований. Они часто подразделяются на подкатегории, особенно, когда требования описывают решение к программному обеспечению
• Функциональные требования это требования, которые описывают поведение и информацию, которая будет управлять решением. Они описывают возможности системы, которые будет возможно выполнить в условиях поведения системы или операций – действия определенного информационного приложения или его ответной реакции.
• Не функциональные требования это установленные условия, не оказывающие непосредственного влияния на поведение или функциональность решения, но описывающие условия окружения, которое оказывает влияние на эффективность решения или качество, которое должна иметь система. Они также известны, как добавочные требования или требования к качеству. Они могут включать в себя требования к мощности, скорости, безопасности, доступности, информационной архитектуре, представлению пользовательского интерфейса.
• Переходные требования описывают возможности, которые решение должно иметь для того, чтобы облегчить переход от текущего состояния к желаемому будущему состоянию. Переходные требования не понадобятся после того, как переход осуществлен. Они отличаются от других типов требований, по причине того, что в реальной ситуации они временны и поэтому не могут быть разработаны пока оба, существующее и новое решение, не определены. Данный тип требований полностью «перекрывает» необходимые для перехода из текущего, в желаемое состояния данные, «пробелы» навыков, которые должны быть восполнены, и другие связанные изменения, необходимые для достижения конечного состояния. Они разработаны и определены с помощью оценки и проверки решения.

1.4 Области знаний

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

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

Планирование бизнес - анализа и мониторинг (Глава 2) это область знаний, в которой раскрывается то, как бизнес – аналитик определяет, какую деятельность и в каком порядке необходимо выполнять для достижения результатов. Она охватывает идентификацию стэйкхолдеров, выбор методов бизнес – анализа, процесс, который будет использоваться для управления требованиями, и как оценивать ход работы. Задачи из этой области знания определяют выполнение всех других задач бизнес - анализа.

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

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

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

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

Рисунок 1.1. Взаимосвязи между областями знаний

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

Основополагающие Компетенции (Глава 8) описывают поведение, знания и другие характеристики, которые поддерживают эффективное выполнение бизнес-анализа.

1.5 Задачи

Каждая область знаний описывает задачи, выполняемые бизнес - аналитиками для достижения цели этой области знаний. Каждая задача в «Babok» представлена в следующем формате:

1.5.1 Цель

Каждая задача имеет цель. Цель - это краткое описание причины выполнения задачи для бизнес – аналитика. Цель включает в себя ценность, которая может быть достигнута после того, как задача будет выполнена.

1.5.2 Описание

Задача - это важнейшая часть работы, которая должна быть выполнена как часть бизнес – анализа. Каждую задачу следует выполнять после выполнения большинства инициатив бизнес – анализа. Любая задача может быть выполнена любое количество раз.

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

Задача имеет следующие характеристики:

• С помощью выполнения задачи достигается результат, который создает ценность для спонсирования организации – то есть, если задача выполнена, то это должно производить какой-то явный полезный эффект, который должен быть определенным, видимым и измеряемым;
• Выполнение задачи – в принципе, «выходом» задачи должен быть результат, который может быть использован отдельным работником или группой;
• Задача – это необходимая часть области знаний, с которой она ассоциируется.

«Babok» не предписывает процесс или порядок, в котором задачи должны выполнятся. Некоторое упорядочивание задач неизбежно, так как выполнение определенных задач, дают результаты, которые требуются для выполнения других задач. Однако, важно иметь в виду, что «Babok» предписывает только то, что должно быть выполнено обязательно. Результат может быть неполным или задача может быть изменена и пересмотрена, что может повлиять на то, что её потребуется выполнять несколько раз. Итеративный или гибкий жизненный цикл может требовать того, чтобы задачи во всех областях знаний были выполнены одновременно. Жизненные циклы с ясными определенными фазами так же будут требовать выполнения задач из разных областей знаний, в каждой фазе. Задачи могут выполняться в разном порядке, при условии, что для выполнения задачи есть все необходимые ресурсы.

Описание задачи объясняет более подробно:

• Почему задача выполняется?
• Что такое задача?
• Какие результаты должны быть достигнуты при её выполнении?

1.5.3 Вход

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

• Ясно сформированное, вне рамок бизнес анализа
• Задача, сформированная в ходе бизнес анализа

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

Рис. 1.2 Схемы входа/выхода задач

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

Классификация Требования [состояние или состояния] . Если указанные требования не классифицированы или не имеют определенного состояния, любое из всех требований может быть использовано в качестве входа или выхода. К примеру, «Требования [Состояния]» значит, что требование может иметь любую классификацию, тогда как «Бизнес требования», должно обозначать, что бизнес требования могут быть в любом возможном состоянии (верифицированное, приоритезированное, и т.д.).

Требования также могут комбинироваться в некоторых случаях. К примеру, Требования [Приоритезированные и Верифицированные] следует понимать, как требования и приоритезированные, и верифицированные одновременно. Требования [Приоритезированные или Верифицированные] значит, что требования могут быть приоритезированы или верифицированы, или одновременно находится в обоих состояниях.

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

Вместо прощания

Ну что же, глубоковажаемые Аналитики и Аналитикессы! :)

Соблюдая рамки приличий и ранее предложенный формат создания статей данной серии, мы говорим Вам «До свидания!».

На этот раз наше прощание будет недолгим. У нас уже заготовлены черновики следующего очерка о «Babok», в котором будет продолжен рассказ первой главы.

Всего доброго, профессиональных свершений и развития!

В данной статье рассматриваются вопросы:

1. Заблуждения обывателей.
2. Так чем, все-таки, занимается аналитик в IT?
3. Секреты успешной работы (какими качествами должен обладать аналитик).
4. Инструменты аналитика.
5. Куда идти дальше?

Также в нашем блоге есть статья « », которая дополняет текущую.

Заблуждения обывателей

Системный аналитик - профессия, появившаяся относительно недавно на Российском рынке вакансий в IT-сфере. Понимание, кто же такой системный аналитик, возникает у кандидатов на эту должность или из требований, описанных в вакансии, или же из собственных домыслов. Давайте рассмотрим часто встречающиеся заблуждения кандидатов. Данная вакансия не для всех, кто ранее был кем-то «системным». Наша компания часто получает отклики на данную вакансию, например, от системных администраторов.

Аналитик - это тот, кто анализирует

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

Аналитик не должен уметь программировать

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

Аналитик ни за что не отвечает

На самом деле, это далеко не так, и кандидаты, желающие занять место системного аналитика в IT-компании, думают, что им не придется отвечать за работу. Ошибки аналитика в проекте являются самыми дорогими и даже могут быть фатальными для проекта.

Так чем, всё-таки, занимается аналитик?

Выявление требований

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

Управление требованиями

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

Внедрение проекта

По окончании разработки любого IT-проекта наступает этап внедрения разработанного проекта в бизнес-процесс заказчика. Данный этап лежит также на плечах аналитика, он должен подготовить необходимую для пользователей документацию, провести демонстрацию работы проекта, а также обучить сотрудников заказчика. Для того, чтобы данный этап был выполнен на должном уровне, аналитик должен знать работу всего проекта от «А» до «Я», а также ориентироваться в возможных ошибках, которые будут устранены в последующих релизах. Перед этапом внедрения аналитик должен принять участие в тестировании проекта для того, чтобы убедиться в том, что все функциональные требования, указанные в ТЗ, выполняются корректно.

Секреты успешной работы

Хотелось бы затронуть тему о личностных качествах аналитика в IT-сфере. Личностные качества аналитика дают 60 % его результата. Работа аналитика связана с непосредственным общением с заказчиком, поэтому у аналитика должна быть хорошо поставленная речь, чтобы заказчик видел в собеседнике грамотного специалиста и приятного человека. В умении общаться заложен большой успех в работе. Итак, первое качество аналитика это коммуникабельность. Следующее качество аналитика, позволяющее качественно выполнять свои обязанности, это аналитический склад ума . Он позволяет «отфильтровывать» лишнюю информацию, которую доносит заказчик до исполнителя, и на основе полученной информации проводить анализ деятельности заказчика и формализовать требования. Пожалуй, это главное качество аналитика, потому что оно непосредственно влияет на качество разрабатываемых проектов. Аналитик должен обладать способностью держать большой объем информации по всему проекту, а иногда и не по одному, у себя в голове и уметь быстро просчитывать влияние тех или иных изменений, требуемых заказчику или команде разработчиков на систему в целом, чтобы своевременно согласовывать эти изменения и их последствия со всеми заинтересованными лицами. Для построения бизнес-моделей процессов заказчика аналитику необходимо обладать высокой обучаемостью . Данное качество необходимо для быстрого изучения предметной области, в которой работает заказчик. Аналитик должен стать «специалистом» в каждой из предметных областей, которые меняются с работой над каждым новым проектом. На этапе формирования требований аналитиком составляется техническое задание (ТЗ) на разработку проекта, которое необходимо согласовать с заказчиком и которое будут изучать разработчики.

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

При проектировании больших проектов для крупных заказчиков у аналитиков возникает немало сложностей, связанных с разработкой ТЗ. Эти сложности могут возникать из-за постоянно меняющихся требований, большого числа пользователей и прочих факторов. Все это приводит к частым изменениям в ТЗ. Аналитику порой приходится переписывать до 30-40 % технического задания по несколько раз. Естественно, это сказывается на его нервной системе, поэтому аналитику необходимо обладать немалой терпеливостью и стрессоустойчивостью. Стрессоустойчивость также пригодится и при обучении пользователей новых проектов, так как большинству пользователей навязывают работу в новом проекте организаторы бизнеса (заказчики), чему они сильно сопротивляются. Аналитику приходится выслушивать множество нелестных слов в свой адрес, но он должен спокойно реагировать на критику пользователей и выполнить свою задачу.

Инструменты аналитика

Главными инструментами системного аналитика является ручка, бумага и карандаш. Хорошему аналитику этого вполне достаточно для того, чтобы сформулировать требования и составить бизнес-модель. На практике аналитики применяют различные средства моделирования, поддерживающие нотации IDEFx, UML, BPMN. Такие средства позволяют сократить время на построение моделей и диаграмм, а также получить результат в графическом виде и в виде текстовых отчетов. Подобные инструменты оказывают помощь и в контроле над требованиями к проекту, и в поддержании их в актуальном состоянии. Примером средств моделирования являются такие приложения как: Enterprise Architect (EA), Rational Rose, RUP и др. Также аналитику приходят на помощь и офисные пакеты, такие как MS Office, iWork, Open Office.

Куда идти дальше?

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

Другие материалы блога по теме «Аналитик в IT».

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

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

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

1. Заниматься усовершенствованием продуктов компании — в случае, если она разрабатывает собственные решения. Чаще всего являются очень компетентными специалистами, но в наших краях (СНГ) встречаются намного реже, чем вторые.
2. Бизнес-аналитики в аутсорс и аутстаф компаниях — те люди, которых бросают на передовую работы с клиентами. Занимаются сбором требований, составлением ТЗ и многим другим. Далее речь пойдет именно о них.

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

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

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

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

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

• Быть хорошим переговорщиком (коммуникатором). Он должен уметь понять собеседника, объяснить ему сложные вещи из мира IT, убедить и переубедить клиента в эффективности разного рода решений, при необходимости — сгладить конфликтные ситуации;
• Разбираться в технической стороне разработки ПО;
• Обладать хотя бы базовой, но основательной экспертизой в юзабилити и проектировании интерфейсов;
• Понимать принципы движения денежного потока и работы с финансами — чтобы иметь возможность до конца точно соблюсти интересы клиента относительно продукта, если разрабатывается коммерческое ПО;
• Иметь прикладные навыки из области системного анализа: составление технической документации, специфических диаграмм и схем.

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

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

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

1. Бизнес-аналитик в сфере ИТ

Бизнес-аналитик - это разносторонний специалист, который должен уметь:

• коммуницировать с различными заинтересованными сторонами (это может быть топ-менеджмент компании, либо мидл-менеджмент)
• коммуницировать с бизнес-пользователями
• коммуницировать с членами команды (разработчики, аналитики, менеджеры проектов)
• использовать различные инструменты для систематизации требований (именно инструменты - почти всегда Excel)
• знать и уметь предвидеть какие требования нужны для каждого конкретного проекта и кому задавать вопросы
• уметь правильно формулировать вопросы и «выковыривать» информацию из людей (это очень сложный процесс, особенно когда начинается скрытое сопротивление)
• проводить интервью по выявлению требований
• понимать «политику игры» различных заинтересованных сторон и влияние этого процесса на исход проекта
• видеть влиятельных людей и уметь убеждать их
• уметь исключать мешающих членов рабочей группы из проекта (того, кто постоянно тратит время команды, либо уводит проект не в ту сторону, желательно перевести на другую деятельность внутри компании и обращаться только за отдельными консультациями)
• уметь четко формулировать тезисы, делать четкие выводы
• уметь проводить воркшопы для уточнения требований
• уметь проводить общие конструктивные собрания (цель собрания, проблема, возможные решения должны описываться до собрания, чтобы исключить лишние бла-бла-бла)
• понимать принципы построения систем, уметь трансформировать цели проекта в бизнес-требования, а бизнес-требования в функциональные и нефункциональные требования (т.е. трассировка должна быть в таком порядке)
• быть способным генерировать новые решения
• знать sql, принципы построения моделей данных, бизнес-процессов
• знать и уметь использовать визуальные инструменты для представления информации

1. Всегда пишите документацию для непосвященных людей в концепцию и внутреннее содержание системы, поэтому:

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

2. Как документировать скрипты системы:

• В документе должно находиться общее концептуальное описание последовательности запусков тех или иных скриптов
• Можно представить карту вызова скриптов из компонентов системы, можно сделать некую «карту» по скриптам (mindmap)
• Сами скрипты в документе описывать не надо. Скрипты должны быть самодокументируемыми, т.е. в коде должны быть комментарии, которые заполняются разработчиками (в том числе для разъяснения бизнес-смысла скрипта)

3. Всегда стремитесь к балансу между картинками и текстом. Отсутствие или избыток картинок - не самые лучшие варианты оформления документации

Отношения с подчиненными

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

Как устроиться работать бизнес-аналитиком

1. Открываем HeadHunter;
2. Находим 20 вакансий по бизнес-анализу;
3. Выписываем из них главные пункты, которых ожидают от бизнес-аналитиков;
4. Составляем список 7 наиболее важных (общих для всех вакансий), которыми Вы не владеете;
5. Изучаем быстро за неделю;
6. Идем на собеседование (получаем обратную связь);
7. Учим дальше;
8. Повторяем цикл пунктов 6-7-6-7-… до тех пор, пока не устроитесь;
9. Сначала идите на совеседование в те компании, устроиться в которые Вы не хотите (чтобы не потерять шанс устроиться в хорошие компании при плохом исходе собеседования).