View source for Управление требованиями : Анализ проблем

= Анализ проблем =
== Цель ==
Проблема это отличие реального положения вещей от желаемого. 

Цели анализа проблем:
* получить понимание реальных проблем заказчика, которые являются причиной разработки;
* выявить корневые проблемы (те, которые являются реальной причиной озвученных проблем);
* помочь найти наиболее приемлемое решение;
* минимизировать работы;

Почему важно понимание реальных проблем заказчика, хотя, казалось бы, заказчик уже сказал, что он хочет?
* Двусмысленность. Мы не управляем заказчиком, поэтому мы не может требовать от него выражения своих пожеланий так, как необходимо нам. Мы может просто понять не правильно. Понимание ПОЧЕМУ заказчик попросил это позволяет снизить риск неверного понимания.
* Невольные умолчания. Частая ситуация когда заказчик ожидал что-либо в заказанном продукте, поскольку это было ОЧЕВИДНО для него. Но, так как мы не являемся экспертами в его области, это вполне может быть не очевидно для нас.
* Проверка качества проекта требует проверки не только needs (сделали ли мы то, что просили) но и expectations (решена ли проблема заказчика). Но для того, что бы это выяснить – просто необходимо знать саму проблему.

[[File:rqm-problemanalysis.png|600px]]

== Шаги ==
* Выявление заинтересованных лиц;
* Понимание проблем и причин;
* Согласование определения проблем;
* Выявление ограничений проектирования;
* Поиск и проверка решения на основе выявленных проблем;
=== Выявление заинтересованных лиц ===
Итак, заинтересованное лицо или stakeholder это любое лицо которого непосредственно затрагивают результаты проекта. Важно: stakeholder может и не быть инициатором проекта, но учет его требований тем не менее так же важен. Такими stakeholder’ами являются будущие пользователи системы и обслуживающий персонал. Выявить таких stakeholder’ов можно:
* Из исходных требований к проекту (вопрос: “кто будет этим пользоваться”);
* Из знания реальных бизнес-процессов заказчика и места где будет применятся продукт;

Stakeholder’ы могут быть сгруппированы, как правило по принципу сходной работы с продуктом. Часто это совпадает с должностью и/или местом в бизнес процессе. 

Очень важно, что бы представители от каждой группы stakeholder’ов были вовлечены в выявление проблем, формирование и согласование требований и в определение границ проекта. Если этого не сделано, то:
* Возникает недовольство результатами проекта у реальных заказчиком, ибо не опрошенные, а, следовательно, не удовлетворенные пользователи ближе к спонсору проекта, чем разработчики.
* Возникает сопротивление внедрению проекта, поскольку вместо понимания, пришедшего из участия в проекте, stakeholder получает принуждение.

Описание stakeholder’а может включать в себя:
* Название группы (роль по отношению к системе);
* Имя и координаты представителя;
* Описание stakeholder’а (какую роль он играет в процессах, которые будут затронуты в проектах (его ответственности), описание его характеристик, имеющих значение с точки зрения проекта (например, режим работы, квалификация…);
* Как он может быть вовлечен в разработку проекта (источник требований, каких, ревьювер);
=== Понимание проблем и причин === 
Процесс понимания проблем и причин должен ответить на два вопроса:
* Почему заказчик захотел инициировать проект;
* Что на самом деле является причиной проблем;

Как было сказано раньше, проблема это отличие реального положения вещей от желаемого. Именно в таком виде для человека естественно высказывать своё пожелание. “Мне не нравится это, хочу то”. Однако реальной проблемой часто являются скрытые проблемы. Задачей на данном этапе является ответ вопрос “а почему, собственно, не нравится”? 

Есть различные методики, например, fishbone.

[[File:rqm-fishbone.png|600px]]

Выявление корневых причин очень важно, поскольку иногда самое простое решение не всегда очевидно. Так же, существует так называемый закон Парето. Сам закон звучит так: “20% клиентов приносят 80% прибыли”. Однако сходные принципы, как правило, применимы и в других случаях, например: “Решение 80% пользователей используют 20% возможностей” или “80% проблем возникают из 20% причин”. Это, безусловно, не догма, а всего лишь напоминание о том, что всегда следует помнить о наличии простого и общего решения для множества проблем.

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

Так же, анализ проблем и причин может позволить ответить на следующие вопросы:
* Имеется ли в проблеме административная (организационная) составляющая;
* А понимают ли разработчики весь контекст в котором находится проблема (проверка полноты словаря);

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

1) Описание проблемы. В каком месте процесса проявляется проблема, что именно не устраивает?
2) Кого из stakeholder’ов и каким образом затрагивает проблема?
3) Важность решения проблемы.
4) Что является причиной проблемы?
5) Что будет считаться успешным решением проблемы?

=== Согласование видения проблемы ===
Безусловно, процесс создания видения проблем является итеративным. 
* Заказчик высказывает свое видение проблемы. 
* Аналитик проводит выявление stakeholders и поиск причин проблем, формулирует проблемы, ищет характеристики, которые можно было бы использовать для проверки, решена ли проблема.
* Заказчик просматривает и утверждает или не утверждает такую формулировку проблемы. Важно, что утверждение должно быть однозначным. Самое опасное, если заказчик отвечает “в целом да, но вот…”. Согласование проблемы можно считать законченным, только если заказчик целиком и полностью согласен с формулировкой проблемы, её причин и условий, при которых проблема будет считаться решенной.
=== Выявление ограничений проектирования ===
В ходе анализа проблем (а так же из словаря) так же могут быть выявлены ограничения, которые следует учитывать при разработки системы.
Основные виды ограничений это:
* Системные ограничения. Определяются уже существующей инфраструктурой IT у заказчика и уже существующими (т.н. legacy, унаследованными) системами, которые не могут быть заменены или модифицированы.
* Организационные и административные ограничения. Такие ограничения связанны с организацией процессов заказчика и наличием ключевых сотрудников, имеющих собственное мнение, которое должно быть учтено при создании системы.
* Политические и законодательные ограничения.
* Экономические ограничения.
* Технические ограничения (например, соблюдение обязательных стандартов).
Ограничения должны быть задокументированы и согласованы с заказчиком. 
Выявление ограничение позволяет максимально адаптировать продукт к реальным процессам заказчика. 
=== Поиск решения ===
В тот момент, когда определены и согласованы проблемы и их причины, следует провести анализ изначально принятых решений с точки зрения:
* Учитывает ли решение истинные причины проблем;
* Позволит ли решение достигнуть решения проблемы;
* Является ли решение оптимальным;
** С точки зрения простоты, скорости и стоимости разработки;
** Соответствия ограничениям проектирования;
** С точки зрения тех, кто будет пользоваться этим решением;
** С точки зрения эффективности решения в эксплуатации;
** С точки зрения целей бизнес-целей заказчика;
Имея формальное описание проблемы и критерии её решения можно провести поиск аналогичных решений и оценить их. 
Решение так же может быть как техническим, так и организационным. При кажущейся бессмысленности отказа от работы (например, в случае, если мы убеждаем заказчика изменить процесс, а не делать новую систему), важно сохранение доверительных и партнерских отношений с заказчиком, а не сиюминутная выгода. 


[[Category:Управление требованиями (Курс)]]