...

Как оценить зрелость процессов управления анализом: чек-лист для самопроверки

управление бизнес-анализом, курсы для тимлидов аналитиков, зрелость бизнес-анализа, обучение руководителей аналитиков, обучение бизнес-анализу, курсы по бизнес-анализу, уровни CMMI, процессный подход к управлению, бизнес-процессы, модели управленческой зрелости, курсы для бизнес-аналитиков, Школа прикладного бизнес-анализа Учебный центр Коммерсант

Чтобы системные и/или бизнес-аналитики работали эффективно, поставляя качественные результаты за меньшее время, процессы анализа должны иметь достаточную степень зрелости. Для ее оценки я составила небольшой чек-лист, который поможет понять, насколько аналитические процессы определены и, соответственно, управляемы, а также определить направления для их улучшения.

Насколько спелы наши яблочки аналитики: 4 ключевых вопроса самооценки зрелости процессов анализа

С одной стороны, процессы системного и бизнес-анализа вполне можно рассматривать по CMMI-модели оценки управленческой зрелости, о которой я рассказывала здесь. Даже в очень гибких, молодежных и бюризовых ИТ-стартапах после примерно месяца совместной работы команда определяет комфортные для себя способы взаимодействия, формируя из них повторяемые рабочие процедуры, формы представления информации и зоны ответственности. Например, еженедельные созвоны по статусу проекта, формулирование пользовательских требований на разработку в форме User Story, коллегиальное рассмотрение запросов на изменение продукта. Даже если эти процедуры в явном виде не документированы, по своей сути они отвечают 2-му уровню управленческой зрелости по модели CMMI.

Оценка управленческой зрелости, уровни бизнес-процессов по модели CMMI, CMMI, бизнес-процессы
Уровни управленческой зрелости бизнес-процессов по модели CMMI

Чтобы понять, на каком уровне управленческой зрелости находится ваша команда аналитиков, ответьте на следующие вопросы:

  1. Определены ли процессы системного и бизнес-анализа? Выделены ли в явном виде границы, результаты и участники этих процессов? Например, результатом процесса сбора требований может быть документ бизнес-требований (BRD, Business Requirments Document), который описывает бизнес-контекст, потребность в изменениях, ожидаемую ценность, вовлеченных стейкхолдеров и их исходные пожелания, ключевые сущности домена, а также потенциальные риски реализации проекта. Кто составляет этот документ, кто и как его проверяет, отвечая за валидность представленных в нем данных?
  2. Существуют ли переиспользуемые формы и шаблоны содержания аналитических артефактов? Например, для всех ИТ-проектов есть шаблон спецификации требований, который должен включать обязательный набор пунктов. Предположим, нефункциональные требования к производительности системы в этом шаблоне спецификации должны быть описаны в количестве обрабатываемых запросов в секунду, а функциональные требования представлены в виде Use Case.
  3. Возникают ли проблемы с продуктом и/или случаются в команде конфликты из-за размывания зон ответственности между участниками процессов? К примеру, кто отвечает за одобрение или отклонение запроса на изменение, который был выражен пользователем продукта в виде неформального отзыва? Кто решает, в каких случаях подобный запрос может быть проигнорирован, а в каких – нет, и за кем последнее слово?
  4. Есть ли в команде база знаний лучших практик и унифицированных техник решения рабочих задач? Наличие такой базы знаний позволяет команде говорить на одном языке, быстрее понимать друг друга и получать результаты. Особенно это заметно в ситуациях с высокой вариативностью. Например, весьма обширный алфавит нотации BPMN, где только одних событий 13 видов, может привести к непониманию смысла диаграммы ее читателями. Или один и тот же бизнес-процесс получается смоделирован по-разному. Аналогичные случаи встречаются в разработке программного кода, когда каждый разработчик использует свои собственные шаблоны именования переменных, таблиц базы данных и формирования программных конструкций. Избежать подобных случаев помогут соглашения о моделировании, именовании, структурах и форматах данных и т.д., с которыми ознакомлены и согласны все участники процессов.
  5. Насколько подробно регламентированы и автоматизированы процедуры взаимодействия участников команды? Наличие регламентов и их воплощения в виде workflow-процессов в системах управления задачами позволяют исключить ситуацию, когда работа выполняется каждый раз как в первый раз, т.е. неповторимо (и это не комплимент)).

Для маленькой и самоорганизующейся команды потребность в регламентации правил работы и коммуникации может отсутствовать. Однако, по мере увеличения числа проектов и роста команды, управление с ручным приводом перестает работать и возникает необходимость в документировании сложившихся в компании практик решения рабочих задач, а также выработке новых решений, соразмерных текущему масштабу бизнеса. Сделать это помогут следующие действия, которые мы рассмотрим далее.

Управление бизнес-анализом - курс для руководителей

Код курса
BAMP
Ближайшая дата курса
29 августа, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.

Как улучшить процессы системного и бизнес-анализа: рекомендации

Чтобы сделать процессы системного и бизнес-анализа повторяемыми и управляемыми тимлиду аналитиков, т.е. руководителю команды, следует осознать и задокументировать следующие компоненты этих работ:

  1. Определить набор процессов работы с требованиями в ваших проектах. Составьте матрицу ответственности. Оцените степень регламентированности и автоматизации этих процессов. Там, где эта степень низкая (например, нет регламентов, каждый раз делается все по-разному), составьте план работы по исправлению ситуации;
  2. Определите набор техник, которые будете использовать в своих проектах и для каких задач. Составьте таблицу сопоставления задача/техника. Убедитесь в том, что аналитики и другие участники процессов умеют пользоваться этими техниками;
  3. Определите предпочтительные формы представления требований, составьте шаблоны, которые будут понятны всем участникам процессов работы с требованиями;
  4. Опишите жизненный цикл требования в ваших проектах в виде диаграммы состояний с расшифровкой смысла каждого состояния;
  5. Опишите набор атрибутов требований в ваших проектах с расшифровкой смысла каждого атрибута;
  6. Определите правила приоритизации требований, регламентирующие выбор базиса, модели и подхода к приоритизации. Задокументируйте эти правила в виде таблицы принятия решений и/или DMN-диаграммы;
  7. Определите процедуры одобрения (утверждения) требований в текстовом и графическом виде, например, в виде BPMN- и DMN-диаграмм;
  8. Опишите процедуру работы с запросами на изменения требований, составьте матрицу ответственности;
  9. Организуйте логирование случаев конфликтов требований между собой, неправильной расстановки приоритетов и других  реализовавшихся рисков в ваших проектах;
  10. Опишите регулярную процедуру анализа логов для выработки корректирующих и предупреждающих мероприятия.

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

  • Ознакомьте участников процесса работы с требованиями с регламентами тех процессов и процедур, где они участвуют;
  • Убедитесь, что изложенные правила понимаются и интерпретируются верно;
  • Внедрите принцип единства в управление:
    • один источник истины;
    • один центр управления;
    • RACI-матрица на все процессы и процедуры;
    • одно лицо, принимающее решение (ЛПР) в конфликтных случаях с четкой инструкцией принятия ответственности и действий;
    • единое хранилище проектной документации;
    • только последняя версия артефакта считается единственно верной;
    • единый глоссарий используемых терминов;
    • единый набор используемых шаблонов и техник;
  • Внедрите принцип PDCA в управление требованиями (Plan, Do, Check, Act)
    • определите плановые показатели процессов работы с требованиями;
    • отслеживайте фактические показатели процессов работы с требованиями;
    • организуйте логирование случаев несоответствия плана и факта;
    • организуйте регулярный аудит всех процессов и анализ логов для выработки корректирующих и предупреждающих мероприятия.

В заключение еще раз напомню, что придется насильно железной рукой гнать человечество к счастью, не привлекая внимания санитаров, воплощая в жизнь все задокументированные практики. Для внедрения улучшений придется создать такие условия, чтобы сотрудники просто НЕ МОГЛИ выполнять свою работу ИНАЧЕ, чем в соответствии с регламентами работы. Как это сделать, я рассматривала в прошлой статье. Впрочем, аналитики достаточно быстро адаптируются к изменениям, поскольку в силу своих профессиональных обязанностей стремятся оптимизировать все и вся, включая собственную работу. Поэтому в большинстве случаев инициативы тимлида аналитиков по повышению управляемости рабочих процессов активно поддерживаются.

Управление бизнес-анализом - курс для руководителей

Код курса
BAMP
Ближайшая дата курса
29 августа, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.

Узнайте больше про лучшие практики управления системным и бизнес-анализом на курсах нашей Школы прикладного бизнес-анализа в лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Добавить комментарий

Поиск по сайту

Напишите нам, мы онлайн!