Путешествие по системному ландшафту - Гарольд Лоусон

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

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

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

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

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

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

Рис. 2.1. Где проблема, а где возможность?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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