Читать «Путешествие по системному ландшафту» онлайн - страница 50

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

Нахождение первопричин

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

Сенге и др. [1994] описывают метод, основанный на текстовом представлении, который оказался полезным и для отдельных лиц и для групп, работающих вместе над выявлением первопричин, вызывающих проблемы. Этот метод, называемый «Пять почему», представляет собой полезную отправную точку в процессе размышления о первопричинах (что, на что и почему влияет). По существу, данный метод рекомендует смотреть все дальше и дальше за пределы проблемы, считающейся источником возникновения затруднения.

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

Для иллюстрации метода «Пять почему» мы разберем некоторые выводы, сделанные Маргаретой Эрикссон [2006]. В проекте, который она разрабатывала как слушатель данного курса, изучались первопричины того, почему клиентская информация о продукте (ИПК) для некоторого вида программного обеспечения является неадекватной, несвоевременной и дорогой в разработке. Следующие два примера представляют собой результат изучения связанных с документацией проблем хорошо известной телекоммуникационной компании.

1. Почему ИПК опаздывает?

Те, кто пишет ИПК, ждут спецификацию функций (СФ) от разработчика.

2. Почему те, кто пишет ИПК, ждут спецификацию функций?

Разработчик, который должен написать СФ, задерживается.

3. Почему разработчик, который должен написать СФ, задерживается?

Разработчик занят написанием программного кода для системных функций СФ.

4. Почему разработчик пишет код для системных функций?

Разработчик отвечает за программный код.

5. Тогда почему разработчик не пишет СФ?

Разработчик описывает системные функции в СФ после кодирования и тестирования.

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