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

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

Поэтому перед тем, кто занимается постановкой задачи, стоит две задачи:

1. Понять, как люди, с которыми он работает (представители-заказчика, заказчик), воспринимают эту проблему.
2. Восстановить (при взаимодействии с заказчиком), какие проблемы на самом деле скрываются в воспринимаемой ситуации.

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

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

Самая худшая ситуация в разработке ПО – когда система разработана и готова к внедрению, но заказчик нам говорит: «Да, это соответствует тем требованиям, которые мы собрали, но не решает мою проблему».

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

Мы используем два языка, на которых можно обсуждать то, что будет делать система:

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

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

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

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

Аналитики знают, что мир такой, какой он есть, потому что таким стал. У каждой сложившейся ситуации есть свои причины. И возникает вопрос: «Можем ли мы в единицу времени определить все факторы, влияющие на какую-либо ситуацию, так, чтобы предсказать, что будет дальше?»

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

Мало кто знаком со второй частью закона причинно-следственных ограничений: причинно-следственные связи не гарантируют стопроцентную предсказуемость системы.

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

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

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

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

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

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

Задача бизнес-аналитика в процессе анализа первичных требований на основе запросов пользователей – понять, для чего с точки зрения бизнес-потребностей необходима та или иная функциональность.

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

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

Каждый раз, когда пользователь говорит нам о требовании или проблеме, начинаем задавать вопрос: «Почему это происходит?» или «Как мы сможем использовать этот результат?». Так мы получаем ответ на первый уровень – почему это произошло? Задавая следующий вопрос «Для чего это необходимо», переходим к более глубокому пониманию.

Техника «Пяти «почему?» так называется, потому что, как правило, пять – это максимальное количество вопросов, необходимых для того, чтобы докопаться до первопричины или до вопроса с мотивацией: «Зачем мне это необходимо?».

Если сопоставить контексты системы с техникой «Пяти «почему?», можно увидеть, что те или иные требования, которые относятся к функционированию ПО, связаны с определенными требованиями на уровне бизнес-системы – там, где действуют пользователи.

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

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

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

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

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

Если мы выделим некоторую цепочку причинно-следственных связей:

1. Пользователю необходима некоторая функциональность, потому что это будет использовано некоторым образом пользователем системы.
2. Пользователям системы необходимо это сделать, потому что есть определенный бизнес-процесс, задачи которого необходимо автоматизировать.
3. Бизнес-процесс нужен, потому что существует некоторое внешнее требование с точки зрения организационной среды (или того контекста, который мы рассматриваем), которое и является причиной того, почему должен быть такой бизнес процесс.
4. Можно продолжить анализировать и выяснить, что еще какое-то явление во внешней среде является причиной того, что у нас появляется такой вызов перед организацией или такое изменение.

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

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

В процессе бизнес-анализа нужно стараться решать проблемы, которые у нас есть, в соответствии с тем уровнем проекта, на котором мы находимся. Безусловно, можно отнести проблемы к некоторым факторам и сказать: "Если бы наши пользователи никогда не забывали сохранять документы (или никогда не забывали что-то), тогда решать эту проблему и не потребовалось бы". Но мы не можем влиять на внешнюю среду, и поэтому наша задача – сфокусироваться на том уровне, на котором мы можем решать проблемы: либо уровень бизнес-процессов, либо уровень взаимодействия пользователей и системы, либо уровень программного обеспечения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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