Шрифт
Source Sans Pro
Размер шрифта
18
Цвет фона
Нахождение первопричин
Нахождение источников проблем, разумеется, является необходимой предпосылкой моделирования. Часто проблемы неочевидны и могут быть результатом какой-либо парадоксальной ситуации.
Сенге и др. [1994] описывают метод, основанный на текстовом представлении, который оказался полезным и для отдельных лиц и для групп, работающих вместе над выявлением первопричин, вызывающих проблемы. Этот метод, называемый «Пять почему», представляет собой полезную отправную точку в процессе размышления о первопричинах (что, на что и почему влияет). По существу, данный метод рекомендует смотреть все дальше и дальше за пределы проблемы, считающейся источником возникновения затруднения.
Указанный метод удобнее всего применять, используя флипчарт, бумагу и маркеры и назначив кого-нибудь, чтобы все записывать. Выбрав первое «Почему» (обычно являющееся результатом трех-четырех исходных предпосылок), задаются вопросом: «Почему происходит то-то и то-то?»
Для иллюстрации метода «Пять почему» мы разберем некоторые выводы, сделанные Маргаретой Эрикссон [2006]. В проекте, который она разрабатывала как слушатель данного курса, изучались первопричины того, почему клиентская информация о продукте (ИПК) для некоторого вида программного обеспечения является неадекватной, несвоевременной и дорогой в разработке. Следующие два примера представляют собой результат изучения связанных с документацией проблем хорошо известной телекоммуникационной компании.
1. Почему ИПК опаздывает?
Те, кто пишет ИПК, ждут спецификацию функций (СФ) от разработчика.
2. Почему те, кто пишет ИПК, ждут спецификацию функций?
Разработчик, который должен написать СФ, задерживается.
3. Почему разработчик, который должен написать СФ, задерживается?
Разработчик занят написанием программного кода для системных функций СФ.
4. Почему разработчик пишет код для системных функций?
Разработчик отвечает за программный код.
5. Тогда почему разработчик не пишет СФ?
Разработчик описывает системные функции в СФ после кодирования и тестирования.
Разумеется, в данном примере можно заметить парадокс программного обеспечения, когда планирование и нужно и не нужно для того, чтобы способствовать творческим способностям. Теперь, давайте рассмотрим смежную проблему, которая в значительной степени является следствием предыдущей ситуации.
1. Почему работа по составлению ИПК требует много времени (и становится дорогой)?
ИПК содержит много документов и страниц.
2. Почему она содержит много документов и страниц?
ИПК не имеет заранее определенной структуры, и ее объем увеличивается по мере увеличения системы.
3. Почему объем ИПК увеличивается по мере увеличения системы?
Ни у кого в проекте не было ни времени, ни полномочий для структурирования информации.
4. Почему информация не структурирована?
Ни один человек не владеет полной картиной потребностей пользователя (клиента) и целевой системы.
5. Почему отсутствует понимание потребностей пользователя (клиента)?
Нет обратной связи от пользователей (клиентов).
Этот метод, основанный на структурированном тексте, предоставляет полезную отправную точку для анализа различных сложных ситуаций. Теперь рассмотрим различные формы графических и наглядных представлений системных ситуаций.
