Чтобы системные и/или бизнес-аналитики работали эффективно, поставляя качественные результаты за меньшее время, процессы анализа должны иметь достаточную степень зрелости. Для ее оценки я составила небольшой чек-лист, который поможет понять, насколько аналитические процессы определены и, соответственно, управляемы, а также определить направления для их улучшения.
Насколько спелы наши яблочки аналитики: 4 ключевых вопроса самооценки зрелости процессов анализа
С одной стороны, процессы системного и бизнес-анализа вполне можно рассматривать по CMMI-модели оценки управленческой зрелости, о которой я рассказывала здесь. Даже в очень гибких, молодежных и бюризовых ИТ-стартапах после примерно месяца совместной работы команда определяет комфортные для себя способы взаимодействия, формируя из них повторяемые рабочие процедуры, формы представления информации и зоны ответственности. Например, еженедельные созвоны по статусу проекта, формулирование пользовательских требований на разработку в форме User Story, коллегиальное рассмотрение запросов на изменение продукта. Даже если эти процедуры в явном виде не документированы, по своей сути они отвечают 2-му уровню управленческой зрелости по модели CMMI.
Чтобы понять, на каком уровне управленческой зрелости находится ваша команда аналитиков, ответьте на следующие вопросы:
- Определены ли процессы системного и бизнес-анализа? Выделены ли в явном виде границы, результаты и участники этих процессов? Например, результатом процесса сбора требований может быть документ бизнес-требований (BRD, Business Requirments Document), который описывает бизнес-контекст, потребность в изменениях, ожидаемую ценность, вовлеченных стейкхолдеров и их исходные пожелания, ключевые сущности домена, а также потенциальные риски реализации проекта. Кто составляет этот документ, кто и как его проверяет, отвечая за валидность представленных в нем данных?
- Существуют ли переиспользуемые формы и шаблоны содержания аналитических артефактов? Например, для всех ИТ-проектов есть шаблон спецификации требований, который должен включать обязательный набор пунктов. Предположим, нефункциональные требования к производительности системы в этом шаблоне спецификации должны быть описаны в количестве обрабатываемых запросов в секунду, а функциональные требования представлены в виде Use Case.
- Возникают ли проблемы с продуктом и/или случаются в команде конфликты из-за размывания зон ответственности между участниками процессов? К примеру, кто отвечает за одобрение или отклонение запроса на изменение, который был выражен пользователем продукта в виде неформального отзыва? Кто решает, в каких случаях подобный запрос может быть проигнорирован, а в каких – нет, и за кем последнее слово?
- Есть ли в команде база знаний лучших практик и унифицированных техник решения рабочих задач? Наличие такой базы знаний позволяет команде говорить на одном языке, быстрее понимать друг друга и получать результаты. Особенно это заметно в ситуациях с высокой вариативностью. Например, весьма обширный алфавит нотации BPMN, где только одних событий 13 видов, может привести к непониманию смысла диаграммы ее читателями. Или один и тот же бизнес-процесс получается смоделирован по-разному. Аналогичные случаи встречаются в разработке программного кода, когда каждый разработчик использует свои собственные шаблоны именования переменных, таблиц базы данных и формирования программных конструкций. Избежать подобных случаев помогут соглашения о моделировании, именовании, структурах и форматах данных и т.д., с которыми ознакомлены и согласны все участники процессов.
- Насколько подробно регламентированы и автоматизированы процедуры взаимодействия участников команды? Наличие регламентов и их воплощения в виде workflow-процессов в системах управления задачами позволяют исключить ситуацию, когда работа выполняется каждый раз как в первый раз, т.е. неповторимо (и это не комплимент)).
Для маленькой и самоорганизующейся команды потребность в регламентации правил работы и коммуникации может отсутствовать. Однако, по мере увеличения числа проектов и роста команды, управление с ручным приводом перестает работать и возникает необходимость в документировании сложившихся в компании практик решения рабочих задач, а также выработке новых решений, соразмерных текущему масштабу бизнеса. Сделать это помогут следующие действия, которые мы рассмотрим далее.
Управление бизнес-анализом - курс для руководителей
Код курса
BAMP
Ближайшая дата курса
23 мая, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Как улучшить процессы системного и бизнес-анализа: рекомендации
Чтобы сделать процессы системного и бизнес-анализа повторяемыми и управляемыми тимлиду аналитиков, т.е. руководителю команды, следует осознать и задокументировать следующие компоненты этих работ:
- Определить набор процессов работы с требованиями в ваших проектах. Составьте матрицу ответственности. Оцените степень регламентированности и автоматизации этих процессов. Там, где эта степень низкая (например, нет регламентов, каждый раз делается все по-разному), составьте план работы по исправлению ситуации;
- Определите набор техник, которые будете использовать в своих проектах и для каких задач. Составьте таблицу сопоставления задача/техника. Убедитесь в том, что аналитики и другие участники процессов умеют пользоваться этими техниками;
- Определите предпочтительные формы представления требований, составьте шаблоны, которые будут понятны всем участникам процессов работы с требованиями;
- Опишите жизненный цикл требования в ваших проектах в виде диаграммы состояний с расшифровкой смысла каждого состояния;
- Опишите набор атрибутов требований в ваших проектах с расшифровкой смысла каждого атрибута;
- Определите правила приоритизации требований, регламентирующие выбор базиса, модели и подхода к приоритизации. Задокументируйте эти правила в виде таблицы принятия решений и/или DMN-диаграммы;
- Определите процедуры одобрения (утверждения) требований в текстовом и графическом виде, например, в виде BPMN- и DMN-диаграмм;
- Опишите процедуру работы с запросами на изменения требований, составьте матрицу ответственности;
- Организуйте логирование случаев конфликтов требований между собой, неправильной расстановки приоритетов и других реализовавшихся рисков в ваших проектах;
- Опишите регулярную процедуру анализа логов для выработки корректирующих и предупреждающих мероприятия.
Задокументировав рабочие процедуры процессов системного и бизнес-анализа, включая зоны ответственности и шаблоны результирующих артефактов в виде регламентирующих документов, важно заставить эту документацию работать. Для этого необходимо выполнить следующий набор действий:
- Ознакомьте участников процесса работы с требованиями с регламентами тех процессов и процедур, где они участвуют;
- Убедитесь, что изложенные правила понимаются и интерпретируются верно;
- Внедрите принцип единства в управление:
- один источник истины;
- один центр управления;
- RACI-матрица на все процессы и процедуры;
- одно лицо, принимающее решение (ЛПР) в конфликтных случаях с четкой инструкцией принятия ответственности и действий;
- единое хранилище проектной документации;
- только последняя версия артефакта считается единственно верной;
- единый глоссарий используемых терминов;
- единый набор используемых шаблонов и техник;
- Внедрите принцип PDCA в управление требованиями (Plan, Do, Check, Act)
- определите плановые показатели процессов работы с требованиями;
- отслеживайте фактические показатели процессов работы с требованиями;
- организуйте логирование случаев несоответствия плана и факта;
- организуйте регулярный аудит всех процессов и анализ логов для выработки корректирующих и предупреждающих мероприятия.
В заключение еще раз напомню, что придется насильно железной рукой гнать человечество к счастью, не привлекая внимания санитаров, воплощая в жизнь все задокументированные практики. Для внедрения улучшений придется создать такие условия, чтобы сотрудники просто НЕ МОГЛИ выполнять свою работу ИНАЧЕ, чем в соответствии с регламентами работы. Как это сделать, я рассматривала в прошлой статье. Впрочем, аналитики достаточно быстро адаптируются к изменениям, поскольку в силу своих профессиональных обязанностей стремятся оптимизировать все и вся, включая собственную работу. Поэтому в большинстве случаев инициативы тимлида аналитиков по повышению управляемости рабочих процессов активно поддерживаются.
Управление бизнес-анализом - курс для руководителей
Код курса
BAMP
Ближайшая дата курса
23 мая, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Узнайте больше про лучшие практики управления системным и бизнес-анализом на курсах нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
