Любая проблема может быть представлена в виде причинно-следственной связи.
А и В в этой схеме — некоторые множества значений. Для того, чтобы не запутаться в этих множествах, необходимы инструменты, которые позволят сузить контекст проблемы. Частично мы уже сделали это (используя схему №9, мы составили таблицу №7), определили группу задачедателей, совершаемые действия и интересующий результат.
Пример №1. Айтишники берутся за проект и в большинстве случаев не доводят его до конца.
Пример №2. Женщины, которым, в силу их профессиональной деятельности, приходится выступать публично, «проваливают» свой доклад.
Пример №3. Родители не справляются с плохим поведением ребенка.
Обратим внимание на следующее: в каждом из этих примеров проведено сужение рассматриваемой группы, но насколько оно оптимально?
Кто такие «айтишники»? Есть программисты-разработчики, а есть менеджеры, функция которых заключается именно в управлении проектом. Соответственно, решение задачи при такой постановке проблемы можно рассматривать как на уровне менеджмента, так и на уровне кода программы.
Во втором примере, говоря о «женщине», мы подразумеваем, что разрабатываемое решение с определенной долей вероятности не будет работать на мужчинах. Тем не менее, проведенное сужение — не максимальное. «Женщина» — она взрослая или молодая? «Выступление» — это музыкальный концерт или презентация международного финансового проекта? В каждом из этих аспектов заложены свои особенности решения проблемы.
В примере №3 мы наблюдаем обратную ситуацию, когда понятие «родители» — это излишняя конкретизация. Что если членом исследуемой группы будет также бабушка ребенка или его воспитатель в детском саду? Разве решение будет отличаться?
До начала исследования ответов на все эти вопросы мы не знаем. Но в зависимости от того, какую формулировку мы возьмем за основу, ход работы будет отличаться.
Итак, определим группу задачедателей следующим образом:
- Пример №1: «Программист в коммерческой компании».
- Пример №2: «Женщина, которая регулярно выступает с коммерческими презентациями».
- Пример №3: «Человек, который воспитывает ребенка».
Далее нам остается зафиксировать наблюдаемую проблему относительно выбранной группы:
- Пример №1: «Программист в коммерческой компании, которые не справляется с выполнением проекта».
- Пример №2: «Женщина, которая регулярно выступает с коммерческими презентациями и «проваливает» свое выступление».
- Пример №3: «Человек, который воспитывает ребенка и у которого не получается справиться с его шалостями».
ВАЖНО: смысл последних формулировок определяет именно группа, перед которой стоит проблема.
Так, нам удалось сформулировать следствие: то есть, проблему, как ее видим мы. Теперь мы переходим к определению классов причин.
ДЕТАЛЬНЫЙ РАЗБОР И УТОЧНЕНИЕ ПРОБЛЕМ
Чтобы определить, какие решения для нас наиболее перспективны, мы должны посмотреть на нашу проблему как на систему, отследив взаимосвязи между ее элементами на разных уровнях.
1 — Проблема развивается во времени. Поэтому мы обязательно фиксируем точку ее рассмотрения — этап «во время»; период, предшествующий ей — этап «до»; и период, следующий за ней — этап «после».
Относительно публичных выступлений, эта схема будет выглядеть так:
Подготовка к публичному выступлению —> Публичное выступление —> Его последствия или эффект.
2 — В центре рассмотрения находится сама проблема — это тот системный уровень, на котором мы ее и рассматриваем. Соответственно, на этом же уровне находится ряд других систем, аналогичных нашей и взаимодействующих с ней.
Если мы рассматриваем коммерческую фирму, то на одном уровне с ней будут также находится фирмы-поставщики и фирмы-клиенты.
3 — Подсистемы — составные части нашей проблемы. В организации — это ее подразделения: например, отдел продаж, отдел закупок и т.д.
4 — Надсистемы — это влияние внешних объективных факторов. В сфере IT в качестве надсистем могут выступать уже существующие среды и языки программирования.
С помощью данной схемы мы должны проанализировать проблему в попытке установить примерные классы ее причин. Для большей понятности, продолжим разбор примера об айтишниках: в чем же причина невыполнения проектов?
Таблица 8. Системный анализ проблемы.
(Условные обозначения: НС — надсистема; С — система; ПС — подсистема.)
Системный анализ позволяет рассматривать проблему с разных точек зрения. В идеале, каждый из «этажей» этой таблицы должен быть заполнен. Затем остается лишь выбрать наиболее перспективную (в том числе, и в коммерческом плане) тему для изучения.
На пересечениях таблицы №8 мы получаем различные варианты исследовательской задачи, например:
- Пересечение С-До: Как оценивать программистов при приеме на работу?
- Пересечение НС-До: Каким образом подросток должен обучаться и развиваться, чтобы в будущем стать хорошим программистом?
- Пересечение С-После: Список типовых ошибок при выполнении проектов в сфере IT.
Для вас должно быть уже очевидно, что каждая из этих исследовательских тем требует сбора разных данных. ТО ЕСТЬ: при разной постановке проблемы возникают и разные стратегии исследования. Конечно, они будут пересекаться и взаимодополнять друг друга. Тем не менее, на начальном этапе я советую выбирать один контекст, с которым вы и будете работать. В дальнейшем вы будете приходить к новым исследовательским темам естественным путем.
Рыжачков А.А., Матвеев Д.А. Как написать умную книгу? [Электронный ресурс] Обн. 1.1. / А.А. Рыжачков, Д.А. Матвеев. // LIVREZON.RU: Издательство концентрированных знаний «LIVREZON». – LIVREZON.RU – 2019. – Режим доступа: livrezonpublisher.com/shop/product/kak-napisat-umnuyu-knigu. — Глава 5.