Подходы к ведению проекта. Анализ и выявление бизнес-проблем, а также причин их возникновения

Подходы к проведению этапа бизнес-анализа и проекта в целом

Достаточно часто начиная новый проект компания принимает решение о методологии его ведения часто не думая. «Наша компания все проекты ведет по методологии Agile и точка» — говорят менеджеры компании. А насколько эта методология подойдет именно в этом проекте — об этом мало кто задумывается. Если такое происходит — то это пример ситуации когда навязывается решение, без какого-либо его обоснования.

Как в такой ситуации поступать бизнес-аналитикам? К сожалению от бизнес-аналитика тут мало что зависит и его мнение мало на что не влияет. Бизнес-аналитик может провести анализ, чтобы понять насколько выбранный подход к проекту будет соответствовать его содержанию. Что необходимо для этого проанализировать? В первую очередь атрибуты проекта, для того чтобы понять какой подход будет максимально приемлемым именно для этого проекта. А что такое приемлемость, какой ее критерий?  Приемлемость определяется критерием риска — какой подход создает меньше всего рисков (всем участникам проекта), такой подход и нужно применять к этому проекту.

Анализ заказчика

Вообще начиная новый проект в первую очередь нужно посмотреть на заказчика, оценить его готовность к новому проекту и дать ответ на вопрос: «Насколько сложно будет успешно завершить этот проект для этой компании?». Часто ответ будет негативным — в большей своей массе заказчики не готовы с головой погружаться в новый проект и прикладывать там какие-то усилия.

Анализ текущих возможностей заказчика является для нас точкой As is — точкой для проведения изменений, также мы должны понять какие цели хочет достичь компании начиная новый проект, то есть мы должны определить точку To be — конечную точку проведения изменений. Весь наш проект — это путь из точки As is к точке To be.

Это делается для понимания того разрыва который существует между двумя точками и оценке тех усилий, которые нужно будет приложить для его преодоления. Тут может быть две крайние ситуации:

• Цель очень близка —  в таком случае шанс успешного завершения проекта максимальный и для него нужно минимальное количество ресурсов;
• Цель очень далека — в таком случае есть большие риски того, что проект закончится неудачей — для такого проекта нужно выделение большого количества ресурсов.

Такой анализ позволяет определить:

• Объем и сложность работ
• Объем необходимых ресурсов
• Набор и уровень требуемых квалификаций
• Количество и серьезность рисков

Выбор подхода

Выбираемый подход как правило будет в себе содержать:

• Жизненный цикл программного обеспечения (SDLC)
• Описание этапов проекта
• Описание ролей
• Описание действий
• Описание типов документов и их шаблонов и др.

Какие бывают подходы (методологии)?

1. Microsoft Solution Framework (MSF) — методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.
2. Семейство frameworks Agile — обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе. К гибким методологиям, в частности, относят экстремальное программирование, DSDM, Scrum, FDD, BDD и другие.
3. Macroscope
4. Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software

Это все чистые методологии — на практике же применяется их смесь в разных пропорциях.

Типы методологий

IT сфера предприняла попытку сделать классификацию этих методологий опираясь на:

• Сроки проведения этапа анализа
• Возможности долгсрочного планирования
• Отношения к изменениям в требованиях

В результате были выделены два типа методологий:

1. Plan Driven, Predictive (предиктивные) — методологии, основанные на долгосрочном планировании — RUP и MSF
2. Change Driven, Adaptive (адаптивные) — методологии, основанные на изменениях 

Анализ атрибутов проекта и выбор методологии

Время проведения этапа анализа

Нужно определить когда будет оптимальней всего провести этап бизнес-анализа, в том числе и с точки зрения клиента (то есть проведение процедуры сбора и оформления бизнес-требований).

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

Если же требования планируется прорабатывать на протяжении всего проекта, то это аргумент для Change Driven подходов. В таком случае на начальном этапе требования собираются верхнеуровнево и призваны просто наметить объем проекта (Backlog). Потом они постоянно добавляются, уточняются и обновляются.

Уровень формальности и детализации документов требований

Всегда ли нужно разрабатывать гору документации под проект или этого можно избежать? Этого не нужно делать если:

• Заказчик интенсивно вовлечен в процесс работы проекта — общение с заказчиков происходит оперативно.
• Разработчики задействованые на проекте хорошо знают бизнес заказчика (его специфику и потребности) — в таком случае мы должны описать только ту бизнес-функцию, которую необходимо разработать.
• Заказчик хочет получить первый результат как можно скорее.
• Заказчик готова мириться с рисками: весьма приблизительной оценке трудозатрат (такие проекты как правило идут по схеме ‘time and material»), получение продукта который не совсем соответствует ожиданиям заказчика.
• Если проект проводится небольшой централизированной, квалифицированной командой.

Как вы уже догадались, если у вас выполняются данные условия, то вы можете применять Change Driven подход к проекту.

Детальная документация должна составляться если:

• разработка отдается на аутсорс.
• задействуется распределенная команда (в т.ч. в разных часовых поясах)
• нужна точная оценка ресурсов

Ну а тут уже нужно применять Plan Driven подход.

Отношение заказчика к изменениям требований

Для Plan Driven подходов принято считать, что изменение требований может появляться только на этапе разработки требований. Если требование утверждено заказчиком, то изменять их нежелательно. В случае поступления запроса на изменение требования, такие запросы обрабатываются особым образом и процесс такой обработки является по сути мини-проектом, со своими этапами:

1. Анализ последствий
2. Разработка вариантов изменения требования
3. Выбор заказчиком варианта изменения требования
4. Изменение требования
5. Повторное утверждение требования

Почему все так сложно? Такие проекты как правило работают по моделе fixed cost, то есть заказчику после оценки требований говорится точный бюджет и сроки проекта. Любое изменение требований может привести к срыву сроков и изменению бюджетов как правило не в меньшую сторону.

Если же заказчик толком не знает чего он хочет или хочет масимально быстро получить результат и готов мириться со связанными с этим рисками, то нужно применять Change Driven подход.

Сложность проекта

Сложность проекта влияет на объем работ и на объем рисков. Какие факторы увеличивают сложность проекта? Вот такие:

• Количество заинтересованных лиц на стороне заказчика — чем их больше, тем более сложно выработать консолидированное решение со стороны заказчика.
• Количество бизнес-областей затрагиваемых проектом — чем их больше, тем больше требований нам нужно обработать и тем больше надо учитывать взаимодействие между этими бизнес-областями. Кроме того они начинают бороться за ресурсы проекта и возникает необходимость приоретизации требований
• Количество систем затрагиваемых проектом — уникальность требований(интеграционные требования)
• Уникальность требований — нельзя сказать с какими сложностями мы можем столкнуться при реализации таких требований.

Чем более сложный проект, тем больше нужно смотреть в сторону Plan Driven подходов.

Хороший бизнес-аналитик должен владеть несколькими подходами к управлению проектом. Мастерство аналитика состоит не столько в хорошем знании и умении использовать чистые методологии, сколько в умении проанализировать свойство проекта и выбрать некий симбиоз чистых методологий для конкретного проекта.

Анализ и выявление бизнес-проблем

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

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

Механизм возникновения бизнес-проблем

По среднестатистическим данным исследования Standish Group:

• 29% IT-проектов завершились успехом;
• 52% завершились с превышением бюджета, не в срок или с реализацией меньшего функционала, чем ранее было запланировано;
• 19% IT-проектов закончились провалом.

Также Standish Group проанализировала, насколько часто используется функционал после внедрения разработанного программного обеспечения. Результаты шокирующие:

С целью повышения удовлетворенности разработанным ПО все больше и больше руководителей проектов принимают управленческие решения, опираясь на потребности и ценности, которые заинтересованные лица ожидают получить после внедрения ПО. Именно поэтому все больше и больше проектных команд используют подходы и принципы гибких методологий (Agile) — Change driven подходы и нацелены доставить максимальную ценность в наиболее короткий период.

Как ценность взаимодействует с другими проектными сущностями?

Модель состоит из шести ключевых концепций, которые приведены ниже в таблице.

Изменения (Changes)	Для того, чтобы достигать поставленных целей, удовлетворять потребности заинтересованных лиц, необходимо проводить изменения.
Потребности (Needs)	проблемы и возможности, которые вызывают изменения, являются стимулом действовать для заинтересованных лиц; требуют решения; разрушают или повышают ценности.
Заинтересованные лица (Stakeholder)	Группа или человек с учетом их: потребностей; воздействия и влияния на изменения; отношений к решению.
Решение (Solutions)	Выбор способа действовать, который: должен удовлетворять потребности; учитывать сложившийся контекст (ситуацию); соответствовать заинтересованным сторонам.
Контекст (Contexts)	Обстоятельства, оказывающие влияние, на которые оказывается влияние и которые обеспечивают понимание изменения.
Ценность (Value)	Потенциальная или реализованная стоимость, значимость или полезность чего-либо: для заинтересованных сторон; в конкретной ситуации (контексте); для удовлетворения потребностей.

Решение тем более ценно, чем лучше оно удовлетворяет бизнес-потребность.

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

Возникновение новых потребностей приводит к тому, что бизнес нуждается в новых решениях для удовлетворения новых потребностей, или закрытия возникших проблем.

Существующее решение может со временем терять свою ценность. Деградация решения также влияет на контекст и изменяет его в худшую сторону

Выявление бизнес-проблем с помощью измеримых показателей бизнеса

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

С точки зрения проведения изменений можно выделить 4 основных этапа жизненного цикла бизнеса.

Методика основанная на измеримых показателях бизнеса применяется на этапе нормального функционирования.

Как вы уже поняли измеримые показатели — это метрики, по которым собирается информация о состоянии бизнеса. Но делать только замеры и фиксировать значение метрики — недостаточно. Например, прирост/потеря 50 клиентов в месяц — это много или мало? Бизнес-аналитики должны еще разработать набор правил для интерпретации полученных значений. Аналитики оценивают не эффективность бизнеса в целом, а эффективность существующих решений в бизнесе.

Анализ клиентов компании-заказчика

Неудовлетворенность клиентов компании ведет к возникновению бизнес-проблем. Поэтому первым направлением за которое нужно взяться бизнес-аналитику — это анализ бизнес-потребностей клиентов.

Бизнес-аналитик при таком анализе будет очень тесно сотрудничать с отделом маркетинга. Основными направлениями анализа в этой области будут:

1. Выявление основных потребностей, которые могут быть удовлетворены определенным набором продуктов(услуг) — для этого надо проанализировать какие продукты (услуги) компания может предоставить покупателю, о каких продуктах (услугах) потребитель знает и на какие из них ориентируется; также надо проанализировать ожидания потребителей от продукта (от этого зависит лояльность клиента)
2. Исследование покупательских ожиданий — какое качество товара ожидает потребитель, стандарты обслуживания.
3. Анализ удовлетворенности клиентов. Основной показатель — индекс удовлетворенности клиента
4. Анализ лояльности клиентов

Анализ деятельности конкурентов

Конкуренты — это одна из составных частей окружения бизнеса. Действия конкурентов могут вызывать бизнес-проблемы, а также потребность в новых решениях.

Что нужно анализировать?

1. Анализ целей и стратегий конкурента (в т.ч. SWOT анализ)
2. Анализ доступных конкуренту ресурсов
3. Выявление слабых сторон конкурента

Анализ потенциальных внутренних причин возникновения проблем

Тут нужно проанализировать:

• Анализ бизнес-модели организации;
• Анализ оргструктуры
• Анализ бизнес-процессов
• Оптимальность технических (информационных) решений
• Анализ бизнес-архитектуры

Анализ бизнес-процессов

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

• Насколько эффективен данный процесс качественно и количественно
• Насколько этот процесс своевременен и актуален
• Насколько оптимально определены зоны ответственности в рамках данного процесса — RACI-матрица
• Насколько процесс понятен исполнителям и поддерживается ими
• Каким образом этот процесс взаимодействует с другими процессами
• Насколько важен этот процесс (нужен ли он вообще?)

Анализ оргструктуры

В рамках этого анализа бизнес-аналитик должен определить какие подразделения будут иметь отношение к проекту (либо нашим решением либо проводимыми изменениями).

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

• Проблемы определения бизнес-подразделений (недостаток концепции, объема, целей…)
• Проблемы управления бизнес-подразделениями (несовпадение с корпоративной концепцией…)
• Проблемы структуры бизнес-подразделений (неэффективная/неподходящая структура…)
• Проблемы размера бизнес-подразделений (слишком большое / маленькое…)
• Проблемы структуры бизнес-подразделений (соотношение временных и постоянных
  сотрудников…)
• Проблемы исполнительности бизнес-подразделений (недостаток исполнительности
  сервисных подразделений…)
• Проблемы стоимости бизнес-подразделений (стоимость постоянно превышает бюджет…)

Расположение бизнеса

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

Можно выделить следующие проблемы связанные с расположением бизнеса:

• Проблемы безопасности расположения бизнеса (локальные конфликты, экологически опасные зоны, зоны с повышенной опасностью природных катаклизмов…)
• Проблемы размера расположения бизнеса (слишком большой / маленький…)
• Проблемы важности расположения бизнеса (не вписывается в корпоративный имидж…)
• Финансовые проблемы расположения бизнеса (слишком дорого…)
• Физические проблемы расположения бизнеса (износ…)

Бизнес-данные

В рамках этого анализа бизнес-аналитик должен задокументировать основные типы бизнес-данных, которые использует компания (платежи, контракты, клиенты…), то есть те данные которые компания использует в своих бизнес-процессах. Далее необходимо задокументировать источники этих данных. Это информацию можно изобразить графически с помощью Data Flow Diagram (DFD — UML).

Проблемы которые могут быть у бизнес-данных:

• Проблемы качества бизнес-данных — данные разрознены, несвязаны, неполные и т.д.
• Проблемы управления бизнес-данными — кто создает данные, в каком количестве, для чего и кто отвечает за управлени данными.
• Проблемы владения (ответственности за) бизнес- данными
• Проблемы обслуживания (поддержания, сохранения) бизнес-данных
• Проблемы адекватности бизнес-данных
• Проблемы связности бизнес-данных
• Проблемы надежности бизнес-данных

Бизнес-приложения

В рамках этого анализа бизнес-аналитик должен посмотреть существующие IT решения в компании и дать ответы на вопросы:

1. Насколько существующие решения покрывают потребности бизнеса
2. Насколько они надежны
3. Насколько они масштабируемы

С бизнес-приложениями могут быть следующие проблемы:

• Проблемы надежности бизнес-приложений
• Проблемы масштабирования бизнес-приложений
• Проблемы важности бизнес-приложений (например, соответствие корпоративным целям)
• Проблемы производительности бизнес-приложений
• Проблемы архитектуры бизнес-приложений
• Проблемы размеров бизнес-приложений

Техники выявления проблем в бизнесе

Сейчас мы расмотрим некоторые методики Root Cause Analysis — Анализа корневых причин

Root Cause Analysis (RCA) — поиск ключевой причины возникновения проблемы, ее анализ  и создание плана по ее разрешению. Если проблема воспроизводится снова, значит, настоящая причина не была найдена.

В BABOK Guide V3.0 указаны только две техники выявление проблем и причин их возникновения: техника 5 WHY и техника Ishikava Diagram

5 Why (5 Почему)

Идея исследования причинно-следственных связей была выдвинута ещё Сократом. Но сам метод, получивший название «5 почему», был разработан основателем Toyota Сакити Тоёдой. Первоначально техника предназначалась для решения производственных задач компании.

Первым делом формулируется исходная проблема. Затем исследователь задаёт вопрос: «Почему это произошло (происходит)?» Получив ответ, он снова спрашивает: «Почему это произошло?» — выясняя таким образом причину причины.

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

Шаг 1. Почему это происходит? Потому что муж постоянно на работе и совсем не уделяет время семье.

Шаг 2. Почему он так много времени проводит на работе? Из-за множества дел, требующих его внимания.

Шаг 3. Почему так много дел требуют его внимания? Потому что никто не может их сделать.

Шаг 4. Почему никто не может их сделать? Потому что нет сотрудников, которые были бы компетентны в этих вопросах.

Шаг 5. Почему нет таких сотрудников? Их никто не нанимал.

В этом примере мы пришли от неудовлетворённости семейными отношениями к недостаточной численности управленцев среднего звена.

Не обязательно задавать именно пять вопросов. Это число выбрано эмпирически и является средним. Некоторые проблемы можно рассмотреть и за меньшее (или большее) число шагов.

Техника «рыбьей кости» или «диаграмма Исикавы»

Японский метод, разработанный в 1952 году, который поможет вам чётко увидеть проблему и понять, что делать дальше.

Диаграмма Исикавы (ещё её называют «рыбья кость») — это график, на котором представлены все факторы, которые могли повлиять на возникновение проблемы.

Построение диаграмы

Первое: перед тем как приступать к построению графика, необходимо четко определиться с формулировкой рассматриваемой проблемы. Если, например, участников обсуждения вопроса несколько, то все они должны прийти к одному мнению, и только после этого начинать строить диаграмму.

Второе: рассматриваемую проблему для удобства восприятия лучше всего расположить (записать) в правой части доски или листа бумаги, а влево от нее уже горизонтально проводить «хребет рыбы».

Третье: основные влияющие на проблему причины представляют собой «большие кости рыбьего скелета». Их нужно заключить в рамки и соединить с «хребтом» наклонными стрелками.

Четвёртое: затем на диаграмму наносятся второстепенные причины, которые оказывают влияние на главные, являющиеся их следствием. Это уже «средние кости», которые примыкают к «большим костям».

Пятое: наносятся «мелкие кости», примыкающие к «средним», – это третьестепенные причины, которые воздействуют на второстепенные. Если какие-либо из причин не выявлены, то «кость» остается пустой, т.е. причина не фиксируется, однако место для нее следует оставить.

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

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

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

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

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

Однако у метода Исикавы есть и свои недостатки, которые также необходимо учитывать в своей работе. Первым недостатком является то, что не существует каких-либо правил проверки диаграммы в обратном направлении от первопричины к результатам, т.е. логическую цепочку причин и факторов, ведущих к первопричине, рассмотреть не представляется возможным. Второй же недостаток заключается в том, что составленная, в конечном счете, диаграмма может выразиться в очень сложной схеме и не иметь четкой структуры, что значительно затрудняет объективный анализ и исключает возможность сделать максимально правильные выводы.

Применение данных техник не должно быть механическим четко по инструкции. Бизнес-аналитик должен быть изобретательным и адаптировать эти техники под ситуацию и чувствовать настроение заказчика.