Цитаты из книг автора «Вадим Миронов»

Итак, мы поняли, что протоколы совещаний – один из важнейших источников для пополнения базы знаний проекта. Что же такое протокол совещания? Протокол – документ, фиксирующий результаты совещания, принятые решения и обязательства сторон по выполнению задач. Он может существовать в самых разных форматах: текстовый файл, таблица Excel, письмо по электронной почте, сообщение в Telegram-чате команды или статья в Confluence.

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

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

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

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

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

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

Дело в том, что карта «как есть» позволяет избежать узкого, субъективного взгляда на текущую деятельность. Вероятность выявить существенные детали при описании процесса «как есть» намного выше

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

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