Сегодняшним миром правят технологии. С того момента, как мы просыпаемся утром, до того момента, когда мы ложимся спать ночью, нами в некотором смысле правят технологии. Роль бизнес-аналитика в некотором смысле лучше ценится, когда речь идет о технологиях. Как упоминалось ранее в моих сообщениях, в любом месте в этом мире, где сочетаются люди, процессы и технологии, возникнет проблема.
Если есть бизнес-аналитик, который работает исключительно над процессом без какого-либо воздействия на технологии или без какого-либо аспекта технологии, я хотел бы встретиться с ним или с ней. Итак, переходя к нашей теме - давайте попробуем понять с точки зрения бизнес-аналитика и консультанта простым способом различные фазы функционального бизнес-проекта, который включает в себя технологии.
Активно ли бизнес-аналитик участвует в подэтапах проекта?
Бизнес-проект, связанный с технологиями, в мире консалтинга часто делится на 2 больших этапа. Первый этап называется «Определение объема работ», а второй этап - «Доставка». Обе эти фазы состоят из нескольких подфаз, в которых бизнес-аналитик играет жизненно важную роль. Мы рассмотрим их подробнее.
Подфазы этапа определения объема консультационного проекта обычно делятся на определение объема, анализ и функциональное проектирование.
Подэтапы поставки в консультационном задании включают техническое проектирование, строительство / сборку, этап тестирования, который включает в себя тестирование системной интеграции (SIT) и приемочное тестирование пользователей.
Определение объема. По моему опыту, я заметил, что часто определение объема проекта выполняется до того, как бизнес-аналитик будет назначен для проекта. В некоторых случаях бизнес-аналитику может повезти, и он может быть включен в определение объема проекта. Но обычно на этом этапе главную роль играют руководитель проекта / функциональный менеджер, руководитель программы и предметные эксперты. В некоторых случаях этот этап также называют синей печатью.
В некоторых случаях этап содержания включает процесс сбора требований, а в некоторых случаях он переносится на этап анализа проекта.
Фаза анализа - опять же, хотя термин «анализ» строго относится к анализу собранных бизнес-требований, чаще процесс сбора требований начинается на этом этапе. На этапе анализа проекта бизнес-аналитик активно взаимодействует с заинтересованной стороной, собирает бизнес-требования и анализирует требования, чтобы лучше понять, какие требования соответствуют определенной области, а какие нет.
Это большая проблема, потому что в некоторых случаях бизнес-требования часто выходят за рамки заданного объема проекта и, возможно, потребуется определить бизнес-аналитик и определить объем. Напротив, в некоторых случаях наблюдается смещение объема работ, и многие бизнес-требования упускаются из-за того, что документируются. Фаза анализа, безусловно, является областью, в которой бизнес-аналитик играет решающую роль.
Функциональный дизайн - в мире консалтинга этап проектирования делится на функциональный дизайн и технический дизайн. Функциональный дизайн - это этап, на котором будут задокументированы элементы дизайна в отношении потоков данных, отображение требований в потоки данных, функции требований, которые могут быть выполнены посредством дизайна и т. Д.
Технический дизайн - Технический дизайн, как следует из названия, представляет собой проектный документ, который предоставляет технологию, которая определяет системы, которые будут специально использоваться для удовлетворения функциональных бизнес-требований, задокументированных бизнес-аналитиком. В то время как в документе функционального дизайна подробно описываются функции, которые будут выполнены в рамках реализации проекта, технический дизайн привязан к используемой технологии, типу используемого сервера (Windows или Linux), типу используемой базы данных и т. Д.
Часто в организациях эти два документа объединяются в единый проектный документ. Полезность всеобъемлющего проектного документа полностью зависит от методологии, которой придерживается организация. В некоторых случаях, когда бизнес-аналитик более функциональный, некоторые части всеобъемлющего проектного документа становятся трудными для понимания.
Бизнес-аналитик на этапе проектирования играет роль эксперта по решениям. Бизнес-аналитик должен подтвердить, что проектный документ и предлагаемое решение соответствуют целям проекта и конкретным бизнес-требованиям, которые были зафиксированы.
Сборка / строительство. Хотя в строгом смысле роль функционального бизнес-аналитика будет ограничиваться планированием требований, сбором требований и документацией до передачи их ИТ-командам, сегодня организации имеют целостное представление о функции бизнес-аналитика. Бизнес-аналитик может не играть очень активную роль на этапе строительства проекта. Это, конечно, не означает, что бизнес-аналитик переходит к другому проекту на этом этапе или расслабляется. В то время как ИТ-команда работает на этапе строительства проекта, бизнес-аналитик может потребоваться для поддержки подготовки к тестированию вместе с менеджером проекта.
Помимо потенциально поддерживающих результатов управления изменениями, бизнес-аналитик может потребоваться для помощи в проведении анализа стратегии тестирования, планов тестирования, сценариев тестирования, кейсов и сценариев.
В справочнике CBAP особо указывается, что создание проектной документации, стратегии тестирования, планов тестирования или выполнение тестовых примеров не считается соответствующим опытом работы для сертификации CBAP. Я уверен, что большинство из нас согласятся с тем, что независимо от наших симпатий и антипатий и того, что написано в руководстве, по всем практическим причинам бизнес-аналитик обычно в конечном итоге берет на себя эти результаты.
На мой взгляд, очень хорошо запачкать руки этими результатами, так как вы больше не ограничиваете себя ролью бизнес-аналитика, а расширяетесь до консультанта по вопросам управления.
Фаза тестирования - я не хочу рассказывать вам об этом, но тестирование делится на подкомпоненты.
Бизнес-аналитик знает, что тест системной интеграции чаще всего является ключом к решению большинства вопросов и проблем в технологическом проекте. На этапе сборки ИТ-команда должна гарантировать, что они проведут выбранное базовое тестирование того, что они создали, но чаще всего роль бизнес-аналитика заключается в поддержке интеграционного тестирования. Тестирование системной интеграции включает в себя передачу данных через исходную и последующую системы, чтобы часто тестировать интерфейс / поток данных между системами с помощью заранее определенных тестовых случаев / сценария, имеющих конкретный результат теста.
Пользовательский приемочный тест (UAT) успешно проходит тест системной интеграции. На этом этапе тестирование выполняется с точки зрения конечного пользователя / клиента. Ожидается, что тестирование системной интеграции выявит несколько проблем и ошибок, которые необходимо будет устранить до перехода к UAT. Во время UAT конечному пользователю или заказчику предоставляется возможность выбора бизнес-сценариев, которые они хотели бы протестировать. Ожидаемые результаты (которые должны соответствовать ожиданиям пользователя) часто передаются пользователю, чтобы повысить его уверенность и выйти на этап тестирования.
Тестирование всегда проводится в серверной среде вне производственной среды реального времени. Так что, если вы находитесь на собрании и слышите, как люди обсуждают среду тестирования, не расстраивайтесь. Это просто серверная среда, которая часто копирует производственную среду, но позволяет вам делать ошибки и исправлять их.
Внедрение / запуск - этап реализации проекта - это когда коды и решение, опробованные и протестированные на других этапах проекта, переносятся в производственную среду. После того, как коды переведены в производственную среду и системы готовы к запуску, одним щелчком переключателя изменения вносятся в производственную среду и становятся доступными для отражения.
Как вы могли заметить, роль бизнес-аналитика чаще всего проявляется на начальных этапах проекта. На начальных этапах проекта бизнес-аналитику все больше необходимо взаимодействовать с заинтересованными сторонами, собирать требования, документировать их, анализировать требования и т. Д. Таким образом, BA становится мостом между заинтересованными сторонами бизнеса и ИТ-командами, выполняющими роль чрезвычайно важна. В то же время для BA также важно понимать влияние своей роли и своей работы на другие области проекта.
