Аналитик бизнес-процессов — это специалист с глубокими знаниями в области управления, финансов и экономического развития. Аналитик ищет точки роста, строит гипотезы о потенциальном развитии, занимается оптимизацией и составляет требования и задания для достижения лучшего результата. Именно БА занимается исследованием на тему расширения бизнеса, на спрос продукции или услуги перед запуском кампании — он выяснит, насколько прибыльной является идея и что нужно сделать для достижения цели.
- Чем занимается бизнес-аналитик
- С кем взаимодействует в процессе работы
- Бизнес-аналитик в IT — основные отличия сферы
- Какое участие принимает в проектах
- Результат работы бизнес-аналитика
- Какие навыки необходимы для аналитика бизнес-процессов
- Личные качества, необходимые для бизнес-аналитика
- Сколько зарабатывает бизнес-аналитик
- Как стать бизнес-аналитиком
- Перспективы развития в области бизнес-аналитики IT
Чем занимается бизнес-аналитик
Как я НЕ стал ИТ Бизнес-аналитиком после курсов
Анализ бизнеса предполагает определение потребностей, на основе которых формируются предложения для получения практической пользы и развития бизнеса. Специалист должен не только сформулировать решение, но и обосновать его. При этом важно понимание структуры устройства самого бизнеса и знание инструментов регулирования процессов. Взаимодействовать необходимо не только с руководством компании, но и с пользователями продукта.
С кем взаимодействует в процессе работы
Бизнес-аналитик является неотъемлемой частью большой команды. Он выполняет работу личного помощника руководителя, предлагая точки роста и пути развития компании. Он работает в связке менеджером проекта, предоставляя четкое ТЗ, в какую сторону двигаться для достижения цели. БА чаще других общается с заказчиками — он должен понять, насколько приемлемо развивать продукт, как добиться хорошего роста, какие подводные камни ожидают на пути развития.
Другими словами, бизнес-аналитик — это связующее звено, без которого не получится полноценный диалог между другими участниками команды.
Бизнес-аналитик в IT — основные отличия сферы
В команде по разработке ПО аналитик бизнеса является голосом заказчика. Учитывая IT-направленность продуктов, он должен понимать специфику отрасли, что именно нужно клиенту, а также суметь профессионально изложить это для группы разработчиков. Поэтому необходимо общаться не только на языке бизнеса, но и на языке программирования. К тому же зачастую именно на этого специалиста ложится задача по тестированию готовой разработки. Под каждый заказ могут прорабатываться различные перечни того, чем занимается бизнес-аналитик в IT-компании.
Какое участие принимает в проектах
Аналитика бизнес-процессов подразумевает не только сбор сведений и оформление их в задачу, но и контроль ее разрешения. Поэтому присутствие специалиста на всем протяжении реализации проекта является обязательным.
Как работают бизнес-аналитики в США?
Предпроектный анализ
Предпроектная аналитика включает в себя все действия, которые совершает специалист до момента утверждения бюджета и полного согласия сторон на начало разработки:
- выявление проблемы и возможностей ее решения;
- прогнозирование пользы;
- оформление концепции;
- расчет бюджета;
- составление перечня требуемых ресурсов;
- проработка условий, по которым проект будет считаться принятым.
Каждый пункт оформляется документально с учетом технической составляющей работы.
Анализ в рамках проекта
В процессе выполнения заказа бизнес-аналитику в IT, как и в любой другой сфере, нужно вести переговоры с заказчиком и исполнителем, оформить текущую документацию, в том числе по внесению изменений в проект по запросу клиента. Также это непрерывное взаимодействие с командой, разъяснение требований заказчика, составление планов и заданий конкретным специалистам.
Постпроектный анализ
Оценка выполненной работы на первом этапе осуществляется по факту достижения результата. Возможно проведение контрольного тестирования и изучения функционала готового продукта. Разрабатываются инструкции и демонстрационные материалы для заказчика. Повторная диагностика проводится спустя обозначенное в технических условиях время.
Результат работы бизнес-аналитика
Условно можно выстроить схематическую цепочку оценочных состояний деятельности компании-заказчика: как было – как должно быть – как стало. В итоге анализа выстраивается модель «как должно быть», основанная на потребностях клиента и ведущая к росту продуктивности бизнес-процессов. Если в итоге «как стало» оправдало ожидания и способствовало развитию, значит, специалист достиг желаемого результата.
Какие навыки необходимы для аналитика бизнес-процессов
Hard skills основаны на знаниях о функционировании различных видов коммерческой деятельности, а также технических навыках. Поговорим о них подробнее.
Сбор данных
Специалисту нужно собирать и анализировать множество данных: о продукте, о потребителе, о заказчике, о ситуации на рынке. Проводит опросы, составляет анкеты, изучает технические документы — на основе этих данных делаются выводы и строится модель развития.
Составление технического задания
Документ служит в качестве оформленных на бумаге определенных требований к результату проекта. Для этих целей могут использоваться шаблоны, в том числе по стандартам ГОСТ или ISO. Перед составлением важно убедиться, что взаимопонимание с заказчиком налажено и есть четкое видение конечного продукта, согласованное всеми сторонами.
Работа с технической документацией
К техническим относятся документы следующего характера:
- письменное предложение заказчику;
- общее описание системы;
- техническое задание;
- активное участие в описании архитектуры будущей системы;
- инструкция для пользователей.
В работе может возникать необходимость в написании текущих дополнительных бумаг.
Знания бизнес-анализа
Анализ бизнеса строится на профессиональных методах: мозговой штурм, интервью, моделирование данных и процессов, метрики, сценарии. Знание этих инструментов позволяет выстраивать результативную и быструю работу.
Работа с SQL
Для оценки внутренних параметров ПО, используемого в компании, аналитики используют язык SQL — он является удобным именно для этого направления. Путем структурированных запросов можно описать сведения о трафике, действиях пользователей, отклике системы и других параметрах, необходимых для составления общей аналитической картины.
Личные качества, необходимые для бизнес-аналитика
В аналитической сфере смогут работать люди только с определенным характером. Например, в связи с обширной переговорной деятельностью некомфортно на этой должности будут чувствовать себя интроверты, а рассеянным творческим натурам покажется сложной требуемая концентрация и различные методы типа мозгового штурма. Расскажем о главных soft skills для БА.
Умение анализировать
Системный подход к изучаемым процессам, умение видеть детали, искать причинно-следственные связи и описывать все объекты в перспективе характерны для аналитического склада ума.
Мыслить критически
Способность ставить под сомнение любую информацию, перепроверять мнения, в том числе собственные, делать обоснованные выводы присуща людям с критическим мышлением. Для аналитической работы навык окажется полезным.
Работать с большими потоками информации
Деятельность компании сопровождается огромным пластом данных. Кто их обрабатывает — конечно же это аналитик бизнес-процессов. С помощью облачных хранилищ, редакторов для создания визуализаций, аналитических программ типа Talend БА систематизирует данные и делает выводы о будущем проекте.
Быстрая обучаемость
Целеустремленный аналитик не ограничивается тезисами настольной книги многих профессионалов ВАВОК. Расширение знаний способствует расширению и сфер деятельности, охвату новых направлений бизнеса. От того, как быстро специалист будет усваивать новую информацию, в том числе из области разработок, зависит эффективность его взаимодействия с участниками процесса создания продукта.
Быть решительным
У аналитического специалиста нет времени разбираться с мотивами. Все его решения должны приниматься быстро на основе взвешенных ответственных выводов. Волевое усилие может понадобиться и при формировании потребности у заказчика. Решительность во многом влияет на саму возможность начала сотрудничества клиента и команды разработчиков.
Сколько зарабатывает бизнес-аналитик
Зарплата напрямую связана с наличием опыта, сферой деятельности, набором должностных функций. В среднем, новичок в статусе junior может рассчитывать на сумму 40000-70000 рублей. Middle-специалист зарабатывает больше – до 120000. Опытная категория senior получает до 250000. Аналитики с отличным портфолио и рекомендациями иногда оцениваются значительно выше.
Как стать бизнес-аналитиком
Для входа в профессию можно пройти длинный путь с азов, обучаясь в экономическом ВУЗе на протяжении 5-6 лет. Если вы не имеете профильного образования, но горите идеей развития бизнеса, то возможно переквалифицироваться с помощью курсов от известных образовательных онлайн-платформ, которые также имеют лицензию и выдают по окончании обучения документ об образовании.
Аналитик данных от SkillFactory
SkillFactory предлагает пользователям обучиться бизнес-анализу с нуля. На курсе предоставят все необходимые для старта инструменты, научат пользоваться как самыми простыми типа Google-таблиц, так и сложными – Python и Power BI. Ученики самостоятельно выполнят 14 проектов. Программа рассчитана на 10 месяцев освоения в онлайн-формате.
Профессия Бизнес-аналитик от Skillbox
Skillbox на курсе по бизнес-аналитике дает плотную нагрузку за счет интенсивной практики и важной теории. За 6 месяцев ученик получит всю необходимую для начала работы информацию. Отличительная черта предложения – гарантированное трудоустройство. HR-менеджеры школы помогают выпускникам связаться с работодателями и устроится на стажировку для закрепления полученных знаний.
Бизнес-аналитик от SF Education
Курс от SF Education наполовину состоит из практики. Это значит, что за 4 месяца обучения студенты смогут наработать первый самостоятельный опыт, научатся решать реальные задачи. В программу включен подарочный блок, где можно получить дополнительную актуальную информацию – финансовое право, английский для бизнеса, работа с Excel и Google формами и другое.
Факультет бизнес-аналитики от GeekBrains
GeekBrains обучает профессии бизнес-аналитик в течение года. Дополнительно необходимы еще три месяца для изучения общеобразовательных блоков. Программа обширная, включает знания о бизнес-процессах и изучение IT-специфики направления. Групповые потоки набираются каждые 2 недели. Ближайшее начало обучения указано на сайте школы.
Бизнес-аналитик от Нетологии
На курсе от Нетологии будущие бизнес-аналитики будут заниматься дважды в неделю в течение 5,5 месяцев. После теоретической части выполняются практические задания, которые проверяет куратор и дает развернутые комментарии. При этом практики почти в три раза больше, чем теории, а на выполнение выпускного проекта дается месяц.
Перспективы развития в области бизнес-аналитики IT
Несмотря на популярность профессии, спрос в нише не превышает предложение. Потребность в услугах бизнес-анализа в ИТ есть, особенно в крупных корпорациях из банковской сферы, ретейла, телекоммуникационных компаниях. Ценятся действительно грамотные аналитики, способные приносить реальную пользу.
Профессия предполагает непрерывный процесс обучения и саморазвития, чтобы иметь возможность находить нестандартные, прогрессивные решения для бизнеса. По данным HeadHunter, на апрель 2022 года только в Москве представлено почти 2000 вакансий, некоторые из которых с зарплатой до 400000 рублей. При этом компании предъявляют строгий набор требований, и в большинстве случаев необходимо совмещение бизнес-аналитики с системной. И связано это с гибкостью специализации, позволяющей совмещать, менять квалификацию и увеличивать свой потенциал в карьере.
Источник: coursator.online
Частые ошибки бизнес-аналитика
Всем привет! Я уже года 3 сижу на vc в качестве читателя. Думаю, пришло время опубликовать свою первую статью, к тому же мне есть, о чем вам рассказать.
Меня зовут Виктор Дмитриев. Я родился и вырос в Липецке, последние 8 лет живу в Москве, переехав сюда в 2012-м, когда поступил в НИУ ВШЭ, но сейчас речь пойдет не об этом
Что важнее для нас сегодня, я последние 5-6 лет работаю в ИТ на должностях бизнес-аналитик / старший бизнес-аналитик / lead бизнес-аналитик. Кроме того, занимался проектным и продуктовым управлением, управлял ИТ-командами до 15-20 человек, запускал достаточно крупные корпоративные продукты на десятки тысяч пользователей, сейчас работаю в B2C продукте (финтех).
Но все-таки бОльшая часть моего профессионального опыта связана с бизнес-/системной аналитикой.
Работал в следующих компаниях:
- BCG
- Норникель
- Inframine
- KPMG
- Paybis
Итак, сегодня я хочу рассказать про типичные ошибки (они же факапы), с которыми я или мои коллеги сталкивались как бизнес-аналитики в своей карьере.
Чем занимается бизнес-аналитик
Понятия системный аналитик и бизнес-аналитик
Но перед тем как говорить про типичные ошибки, стоит сказать, чем в принципе занимается бизнес-аналитик.
Сразу отмечу, что в мире принято различать понятия бизнес-аналитик (business analyst) и системный аналитик (system analyst).
Подразумевается, что бизнес-аналитик (тезисно):
- анализирует текущие бизнес-процессы заказчика (as is);
- взаимодействует с заказчиком, чтобы понять его болевые точки;
- моделирует бизнес-процессы заказчика «после» автоматизации (to be).
Системный аналитик, в свою очередь (тезисно):
- взаимодействует с бизнес-аналитиком, чтобы понять какой бизнес-процесс to-be необходим;
- описывает сценарии использования системы (use cases), требования к системе (функциональные и нефункциональные) и другие документы;
- проводит сессии с разработчиками и тестировщиками;
Таким образом, бизнес-аналитик больше взаимодействует с представителями заказчика, системный аналитик — с разработчиками.
Однако, в России эти понятия очень похожи, и часто бизнес-аналитик выполняет также и роль системного аналитика. Поэтому дальше я буду говорить про роль универсального бизнес-аналитика (для простоты буду также называть его просто аналитик).
Теперь, наконец, про ошибки)
Ошибка 1. Принимаем требования заказчика без уточнения его реальных потребностей
Ситуация: к вам приходит заказчик (например, металлургический завод) и говорит: «я хочу, чтобы вы настроили нам интеграцию нашей системы управления готовой продукции с системой отчетности, чтобы мы могли проводить ежемесячную инвентаризацию». Аналитик берет это требование как данность, уточняет детали по шаблону требований к интеграции и передаёт их в разработку. В результате, мы получаем не оптимальное решение с точки зрения потребностей заказчика и ресурсов разработки. Главная проблема, и вы должны ее запомнить — заказчик далеко не всегда знает, чего он хочет на самом деле.
Рекомендуемый подход: вы должны понимать, что ваш заказчик работает не в ИТ (чаще всего), у него нет понимания всего набора технических опций, более того, он может не обладать таким системным мышлением как вы.
Всегда старайтесь докопаться до сути, задавая вопросы «зачем» и «почему». Задав эти вопросы, вы, возможно, узнаете, что инвентаризацию можно (и нужно, но заказчик об этом не думал) проводить чаще, чтобы сразу же находить пропавшую продукцию. Например, лучше будет сделать некоторое автоматизированное решение внутри системы готовой продукции, которое будет проводить мониторинг и присылать мгновенное сообщения в случае расхождения плана и факта.
Это лишь пример, ключевая мысль в том, что вам как аналитику нужно научиться «челленджить» вашего заказчика. Заказчику это, вероятно, будет вначале не нравиться, но, когда на выходе он получит желаемый результат, он будет доволен.
Ошибка 2. Создали и продолжаем поддерживать систему-франкенштейн
Ситуация: в вашей компании на поддержке находится самописная система, которая выступает в роли и ERP, и CRM, и CMS системы. Такая монолитная система-франкенштейн (назовём ее система X). В очередной раз к вам приходит заказчик и говорит: «давайте добавим в систему X возможность создавать B2B заявки с новым набором полей.» Вы, конечно, можете взять это требование, оформить в виде ТЗ, передать разработчикам, а ваш заказчик получит результат. Но является ли это оптимальным решением?
Рекомендуемый подход:
- Соберите требование к желаемой функциональности как можно детальнее. Про то, как собирать требование, мы поговорим с вами в отдельной статье.
- Теперь у вас есть понимание того, что, действительно, нужно заказчику — его потребность (business need/requirement).
- Обратитесь к вашему корпоративному архитектору (в его отсутствие — к руководителю разработки), опишите ему ситуацию и попробуйте вместе найти решение.
- Возможно, в процессе анализа вы поймёте, что такая функциональность уже реализована в другой системе или ее стоит реализовать в другой системе.
Ошибка 3. Забыли обработать исторические данные
Ситуация: как мы уже привыкли, к вам приходит заказчик (тот же металлургический завод) и просит: «я хочу добавить новый статус в заявке на отгрузку готовой продукции — «заморожена», чтобы отслеживать отгрузки, которые больше 3-х дней находятся в процессе сбора на складе».
Заказчик этого явно не подразумевает, а вы забываете спросить, но после внедрения нового статуса в продакшн, оказывается, что исторические заявки на отгрузку готовой продукции, которые уже сейчас находятся более 3-х дней в процессе сбора, так и не перейдут в новый статус. Проблема в том, что вы забыли обработать исторические данные. Если бы вы подумали об этом раньше, в процессе сбора требований, вы бы указали это в ТЗ, а разработчик написал бы скрипт и все были бы довольны.
Рекомендуемый подход: на самом деле это ошибка может быть более глубокой — аналитик не продумал часть нового функционала, но часто я встречал ее именно в таком виде. Правило простое — если это имеет место быть, сразу уточняйте (и прописывайте), что внедряемая фича не повлияет/повлияет на исторические данные.
Ошибка 4. Принимаем слова руководителей за «чистую монету»
Ситуация: обратимся к нашему кейсу с металлургическим заводом. К вам приходит начальник отдела Сбыта и просит разработать модуль создания заявок на отгрузку продукции. Он утверждает, что очень давно работает в компании и знает все процессы своего отдела. Вы верите ему на слово, проводите сессии интервьюирований с ним, формируете ТЗ на основе этих знаний, отдаете в разработку, на выходе есть продукт, которым начинают пользоваться сотрудники отдела Сбыта. В результате, оказывается, что часть сотрудников не способны выполнять свои функции в новой системе, потому что почти всегда есть какие-то исключительные случаи (corner cases), которые одному человеку не продумать.
Рекомендуемый подход: тут могу дать два совета:
1. Проводите демонстрации будущим пользователям как можно раньше и чаще (про это мы поговорим в отдельной статье);
2. Всегда старайтесь проинтервьюировать как можно больше сотрудников. Именно так у вас сформируется наиболее полная картина окружающего мира. Важно выбирать сотрудников, выполняющих разные функции.
Более того, даже пообщавшись с большим количеством людей, вы можете многое упустить, т.к. часто люди не всё смогут вам сказать сами (в силу своей забывчивости, смещенного контекста в данный момент и т.д.). Лучше, если будет возможность приехать на место работы ваших будущих пользователей и попробовать в течение дня понаблюдать за их действиями. Так вы сможете понять как действия сотрудников, так и их мотивацию к этим действиям.
Оставшиеся ошибки я оставлю для второй части статьи.
Что дальше
Мне очень многое хочется вам рассказать. Конечно, если вам это будет интересно.
Потенциальные темы для обсуждения:
- Типичные ошибки бизнес-аналитика. Часть 2
- Прохождение собеседования на позицию аналитика
- Курсы для прокачки скиллов аналитика
- Hard и sofl скиллы аналитика
- Опыт прохождения Go Practice Simulator
- Как собирать и описывать требования
- Методологии моделирования бизнес-процессов
- Структуры вопросов для интервьирования заказчика
- Зарплаты аналитиков
- Опыт работы аналитиком в Европе
и многое другое.
Интересна для вас тема бизнес-аналитики?
Показать результаты
Переголосовать
Проголосовать
Мои контакты
Вы всегда можете связаться со мной в tg.
Я также являюсь ментором. Ко мне можно обратиться с техническими вопросами, интересными кейсами, поиском карьерных возможностей и помощью в подготовке к собеседованиям. Конечно же, в сфере бизнес-/системной аналитики. Если вам интересно, пишите также в tg.
Показать ещё
26 комментариев
Написать комментарий.
Статья крутая, спасибо!
И непонимание границы ролей бизнес и системных аналитиков это прям боль. Причем работающая в обе стороны, с одной стороны, раз аналитик работает в ИТ команде, то от него принято требовать быть «тру» айтишником. То есть не только бизнес опросить, но и API запросы раскурить.
С другой стороны, увидел допущение и в обратную сторону. В первых двух описанных ошибках от аналитика вроде как требуется побыть в роли Product/Project Manager и не просто повысить уровень условной автоматизации выделенных процессов, а подумать и выйти на уровень ценности ИТ решения.
Это не укладывается в тезисные описания обязанностей бизнес-аналитика в самой статье.
ИМХО. Нет ничего плохого в том, что бизнес-аналитик разбирает проблемы Заказчика и докапывается до ценности, которую хочет клиент. Но его ли это главная работа?
Обычно так случается, когда PM номинален и работает как администратор, бегая с бумажками. Если в такой команде будет сильный аналитик, он может взять на себя провисающие роли. Но хорошо ли это, вопрос.
Развернуть ветку
Тимур, спасибо)
Согласен, что поиск и понимание ценности и истинных желаний бизнеса выходит за рамки канонических обязанностей аналитика. Но на практике, как вы и сказали, часто оказывается, что именно бизнес-аналитик глубже всех погружен в боли заказчика (банально потому, что он больше всех с заказчиком общается).
Если бизнес-аналитик об этом не подумает, то, вероятно, все так и остановятся на решении, которое предложил заказчик. Поэтому я и рекомендую стараться находить и предлагать разные альтернативы для вашего заказчика.
Источник: vc.ru
С кем и как взаимодействует аналитик
В ходе проекта аналитику приходится взаимодействовать с самыми различными людьми, как по уровню компетенции, так и по уровню позиции, как со стороны заказчика, так и со стороны проектной команды. Естественно, что различные категории заинтересованных лиц требуют различных подходов в общении в зависимости от того, какие вопросы с ними обсуждаются.
У различных сторон различное видение создаваемого продукта, поэтому одной из основных задач аналитика является формирование единого взгляда на продукт, за счет согласования требований с каждой категорией заинтересованных лиц. Подписываясь под требованиями к системе, заказчик подтверждает, что это именно то, что ему нужно и за что он готов платить, разработчик – что понимает, что требуется реализовать и может это сделать, тестировщик – что может обеспечить требуемое качество.
Давайте коротко рассмотрим, с кем в основном взаимодействует аналитик в ходе проекта (см. схему 4). Со стороны заказчика. Это, прежде всего, пользователи будущей системы. С ними происходит основная работа. Поскольку это люди, которым предстоит работать с тем решением, которое создаст проектная команда, то они являются главным источником требований.
Они объясняют специфику деятельности, формулируют свои ожидания и пожелания, рассматривают и согласовывают построенные модели и спецификации требований. Как правило, эта категория работает с так называемыми уровнями пользовательских и детальных требований к системе. С этими людьми обсуждаются сценарии работы системы.
Схема 4. Лица, с которыми взаимодействует аналитик в рамках проекта С руководителями со стороны заказчика (если, конечно, они не являются пользователями системы) обсуждаются бизнес-требования. Это достаточно высокоуровневые пожелания, которые показывают, что именно требуется от системы, чтобы она принесла пользу бизнесу в целом.
Фактически требования такого рода задают границы и масштаб системы. Все требования, которые лежат ниже этого уровня (пользовательские и детальные), должны укладываться в рамки, заданные бизнес-требованиями. IT-специалисты заказчика определяют место будущей системы в существующей информационной структуре, а также способы интеграции в эту структуру.
Наряду с пользователями системы они также формулируют требования, однако в отличие от пользовательских требований, которые являются функциональными, эти, в основном, носят характер нефункциональных. Несмотря на то, что все три группы можно охарактеризовать термином «Заказчик», от аналитика потребуется применение различных навыков и различных подходов при коммуникациях.
В частности, руководящие сотрудники со стороны Заказчика часто заняты, и аналитику необходимо максимально точно планировать встречи с ними, начиная со времени и заканчивая кругом обсуждаемых вопросов. То, что можно выяснить на более низком уровне, должно быть выяснено именно на нем.
В свою очередь, общение и круг обсуждаемых вопросов с представителями IT-отдела Заказчика может проходить более интенсивно и на более техническом уровне, что может потребовать от аналитика специальных знаний. Со стороны проектной команды. Руководитель проекта – это лицо, которому аналитик непосредственно подчиняется.
С ним согласовываются планы, определяются задачи, обсуждаются проектные риски. Из всей команды аналитик – это человек, находящийся ближе всех к руководителю проекта. Прежде всего, потому, что он по роду деятельности наиболее тесно общается с заказчиком, а также его знания и навыки позволяют говорить с проектным менеджером на одном языке и понимать проектные проблемы.
Разработчики (технические специалисты) являются основными потребителями результатов работы аналитика. В основном для них аналитик и готовит свои документы. Термин «технические специалисты» приведен не просто так.
Помимо непосредственно разработчиков (программистов) в команде может быть выделены роли, например, архитектора системы и архитектор базы данных, которые непосредственно разработчиками не являясь, закладывают фундамент того решения, которое и будет в итоге выстроено. Технические специалисты не вникают в нюансы бизнеса, который требуется автоматизировать.
Они работают с требованиями. Логичность и взаимосвязанность требований, как и результат, к которому приведет их совокупность, здесь не рассматриваются. Конечно, при реализации требований в виде кода, разработчики могут натолкнуться на какие-то ситуации, которые заставят их сформулировать к аналитику вопросы, а того, в свою очередь, пересмотреть спецификации.
Тестировщики — не менее важные потребители документов, порождаемых аналитиком. В частности, ими формируются тестовые сценарии для проверки работоспособности системы. Вот как раз на этом этапе важны не только точечные требования, но и сценарии работы системы, описанные аналитиком.
Если аналитик описал сценарий работы с каким-то конкретным документом, например, накладной, то на основе спецификации требований тестировщики напишут тест-кейс, который позволит проверить корректную реализацию этого сценария непосредственно в системе. И в случае, если реализованное решение не будет соответствовать требованиям, будет зарегистрирована ошибка, которую разработчикам придется исправлять.
Естественно, что изучая только лишь созданные требования, ни разработчики ни тестировщики часто не получают необходимой им информации. Поэтому, уже после завершения аналитической фазы проекта, аналитик все равно остается на проекте и тратит значительное время на консультации.
Если на проекте выделяется отдельная роль – дизайнер пользовательского интерфейса, то такой специалист также плотно взаимодействует с аналитиком. На основе созданных спецификаций он разрабатывает детальный пользовательский интерфейс, который будет профессионально и органично смотреться в рамках всей системы целиком, и отвечать заявленной функциональности.
В некоторых случаях, пользовательский интерфейс, подготовленный дизайнером, передается аналитику для согласования с заказчиком. Важно отметить, что, несмотря на то, что аналитик находится ближе всех членов команды к менеджеру проекта, этот факт не ставит его выше других членов команды, таких как разработчики или тестировщики. Так, коммуникации между тестировщиками, разработчиками и аналитиками рассматриваются как одноуровневые, то есть происходящие на одном уровне иерархии. И тот факт, что аналитик раньше других членов команды погружается в проект и впоследствии консультирует их по требованиям к системе, дает ему только одно преимущество – большую осведомленность (но, также, и большую ответственность).
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net