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

ПОРЯДОК – ПЕРВЫЙ ЗАКОН ДЕЛОВОЙ ДЕЯТЕЛЬНОСТИ.

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

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

Если помните, в самом начале мы говорили о «знании» как о практически применимой информации, отвечающей на вопрос «что делать?»

Наиболее ценная часть в протоколе совещания – достигнутые договоренности, то есть те самые записи с пометкой [Р]. Грамотно зафиксированная договоренность отвечает на три вопроса: 1. Кто делает?2. Что делает?3. В какие сроки? Если договоренность не отвечает хотя бы на один из этих вопросов – решение не является решением.

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

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

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

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

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