Пять этапов анализа проблемы

Основные Положения

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

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

Чтобы выявить причины (или проблемы, стоящие за проблемой), необ­ходимо опросить людей, которых непосредственно затрагивает данная проблема.

Выявление акторов системы является ключевым шагом в анализе проблемы.

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

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

В некотором смысле проблемы и возможности — это две стороны одной медали; ваша проблема является моей возможностью. Все зависит от точки зрения. Но поскольку большинство систем действительно предназначено для решения существующих проблем, можно упростить обсуждение и, не вдаваясь в путаницу проблема/возможность, заняться только проблемной стороной. В конце концов, нам нравится представлять себя в роли "решателей проблем".

Анализ проблемы - это процесс осознания реальных проблем и потребностей пользователя и предложения решений для удовлетворения этих потребностей.

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

Чтобы иметь возможность провести анализ проблемы, полезно определить, что же собой представляет проблема. По определению Гауса и Вайнберга (Gause, Weinberg, 1989)

проблема - это разница между желаемым и воспринимаемым.

Это определение достаточно разумно, по крайней мере, оно устранит часто встре­чающееся среди разработчиков заблуждение, что подлинная проблема заключается в том, что пользователь не понимает, в чем состоит проблема! Согласно данному опреде­лению, если пользователь ощущает нечто как проблему, это и есть настоящая проблема, и она достойна внимания.

Иногда самым простым решением является изменение бизнес-процесса, а не создание новой системы.

Опираясь на приведенное выше определение, наш коллега Элмер Мэгэзинер (Elmer Magazine) заметил, что существует множество путей решения проблемы. Например, из­менение желаний или восприятия пользователей может быть наиболее эффективным (в плане затрат) подходом. Это может осуществляться путем формирования ожиданий и управления ими, внесения предложений по организации работы или частичному улуч­шению существующих систем, предложения альтернативных решений, не требующих разработки новой системы, или проведения дополнительного обучения. Практика знает много примеров, когда именно изменение восприятия приводило к наилучшим, наиско­рейшим и самым дешевым из возможных решений! Если мы взялись решать проблемы, то на нас возложена обязанность исследовать эти альтернативные решения прежде, чем приступать к решению с помощью новой системы.

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

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

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

1. Достигнуть соглашения об определении проблемы.

2. Выделить основные причины — проблемы, стоящие за проблемой.

3. Выявить заинтересованных лиц и пользователей.

4. Определить границу системы решения.

5. Выявить ограничения, которые необходимо наложить на решение.

Давайте подробно рассмотрим каждый их этих этапов.

Этап 1. Достижение соглашения об определении проблемы

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

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

Постановка проблемы

Часто бывает полезно записать проблему в стандартной форме (табл. 4.1). Создание подобной таблицы является простым, но действенным средством, чтобы удостовериться в том, что все участники проекта работают вместе над осуществлением общей цели.

Таблица 4.1. Стандартная форма постановки проблемы

Элемент	Описание
Проблема	[Описание проблемы]
воздействует на	[Указание лиц, на которых оказывает влияние данная проблема]
результатом чего является	[Описание воздействия данной проблемы на заинтересованных лиц и бизнес-деятельность]
выигрыш от	[Указание предлагаемого решения]
может состоять в следующем	[Список основных предоставляемых решением преимуществ]

Может показаться, что достижение согласия относительно определения решаемой проблемы — шаг небольшой и малозначащий, и чаще всего так оно и есть. Но не всегда. Например, один из наших клиентов, производитель оборудования, занялся усовершенствованием своей IS/IТ-системы, обеспечивающей пересылку счетов и финансовых отчетов между компанией и ее дилерами. Задачей новой программы было "улучшить средства коммуникации дилеров". В свете этого команда приготовилась разрабатывать новую масштабную систему. Данный пример достижения соглашения о решаемой проблеме весьма показателен. Предложенное командой определение решения предполагало создание мощной новой системы, предусматривающей улучшенную финансовую отчетность, усовершенствованные формы счетов и отчетов, возможность заказа запчастей в интерактивном режиме и электронную почту. Помимо этого, команда надеялась (если получится) обеспечить возможность электронного перевода средств между компанией и дилером.

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