Обзор ТРИЗ для системных и бизнес аналитиков. Часть 2.

И снова здравствуйте!
Мы продолжаем знакомство с Теорией Решения Изобретательских Задач (ТРИЗ) для аналитиков. В первой статье была представлена схема работы аналитика. В частности, было показано, что при выборе решений аналитик может столкнуться с ситуацией, когда известное решение не удовлетворяет требованиям.

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

Нежелательный эффект

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

Ситуация 1

Решение есть, оно удовлетворяет требованиям, но порождает нежелательные эффекты. Эти нежелательные эффекты мешают (или могут помешать) системе правильно выполнять ее функции.

Пример: Для того, чтобы профинансировать 6-часовую конференцию по бизнес-анализу, необходимо привлечь спонсоров. Компания ХХХ согласна выступить спонсором. Но она выдвигает дополнительное условие: ее представитель выступит с 2-часовым докладом, рекламирующим продукты компании. Решение (привлечение спонсора, получение финансирования) порождает нежелательный эффект (1/3 времени конференции будет использована спонсором в своих целях).

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

Ситуация 2

Примечание. Сложность, трудоемкость и высокую стоимость решения следует рассматривать как недостатки, т.е. как «нежелательные эффекты».

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

Для упрощения решения используется Адаптер.
Ситуация 3

Решение удовлетворяет требованиям, но его нужно улучшить, чтобы, например, иметь «запас прочности» этого решения в будущем.

Примечание. В этой ситуации нет явного нежелательного эффекта. Тем не менее, отсутствие «запаса прочности» у решения можно рассматривать в качестве потенциального недостатка. Как минимум, такая ситуация требует от аналитика уточнения требований у заказчика.

Примеры:
1. В соответствии с требованиями заказчика необходимо обеспечить одновременный доступ к СУБД 10 пользователей. Но через год количество одновременных пользователей может увеличиться до 100.
2. Cегодня система должна обрабатывать 100 документов в день, а завтра – 1000 документов в день.
И т.д.

Для анализа подобных ситуаций в ТРИЗ применяется такой мыслительный прием, как обострение требования.
Если в исходных требованиях заказчика указано, что таких дочерних элементов будет 20-30, то традиционный древовидный браузер является хорошим решением. Если выясняется, что в будущем количество элементов будет расти, то со временем (количество элементов составит несколько сотен) такой браузер перестанет удовлетворять пользователей.

Для навигации по структурам данных часто используется браузер в виде раскрывающегося дерева: каждая вершина в браузере может быть скрыта или раскрыта. Такой браузер хорошо работает в тех случаях, когда дочерних элементов мало и они все помещаются на экране. Когда дочерних элементов становится много, они перестают помещаться на экране; соответственно, удобство использования такого браузера ухудшается.
Аналитик может уже  на стадии проектирования обострить требования: браузер должен удобно работать с сотнями элементов.  Для нового требования аналитик будет искать альтернативные решения, например, решение в виде гиперболического браузера.

Ситуация 4

Решение удовлетворяет части требований, но непонятно, как с его помощью «закрыть» остальные требования.
Другой вариант: есть решение А, которое закрывает одну часть требований; и есть решение Б, которое закрывает другую часть требований. Непонятно, как интегрировать решения А и Б.

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


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

На самом деле, существует такое решение, как спутниковый телефон. Однако, это решение даже не рассматривается, так как является слишком дорогим.

Противоречие

Рассмотренные выше ситуации обладают общими свойствами:

1. Мы рассматривали ситуации выбора решения, удовлетворяющего требованиям. Решение – это носитель пользы (value) или положительного эффекта (ПЭ);
2. Во всех ситуациях присутствует явный или скрытый нежелательный эффект (НЭ), который мешает нам получить пользу.

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

В примере с привлечением спонсора (Ситуация 1) для финансирования конференции по бизнес-анализу противоречие выглядит следующим образом:
Если привлечь спонсора, то мы получим финансирование для конференции, но 1/3 времени конференции будет использована спонсором для собственного доклада.

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

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

Хороший вопрос по этому поводу был сформулирован в книге [Викентьев И.Л., Кайков И.К. Лестница идей. Основы ТРИЗ в примерах и задачах. Новосибирск, 1992]:

«При постройке бани между мудрецами города Глупова из произведения М.Е. Салтыкова-Щедрина возник спор: строгать доски пола или нет? Если острогать, говорили одни, будет скользко, а не острогать, говорили другие, можно ноги занозить. И решили вопрос по-глуповски: доски острогать, но стелить строганной стороной вниз… 

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

Для иллюстрации мы предлагаем подумать вам над решением учебной задачи из курса ТРИЗ.
Антенна радиотелескопа расположена в местности, где часто бывают грозы. Для защиты от молний вокруг антенны необходимо поставить молниеотводы (металлические стержни). Но молниеотводы задерживают радиоволны, создавая радиотень. Установить молниеотводы на самой антенне в данном случае невозможно. Как быть?

Изобретательская задача

Вот как Г.С. Альтшуллер определил понятие «изобретательская задача»:

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

Необходимость в изобретении возникает в тех случаях, когда задача содержит дополнительное требование: «выиграть»… и ничего не «проиграть». Например, подъемное устройство должно быть достаточно мощным и в то же время не должно утяжелять самолет. Решить эту задачу известными приемами невозможно; даже лучшие передвижные краны имеют немалый вес. Здесь нужен какой-то новый подход, иначе говоря — нужно изобретение.

Таким образом, обычная задача переходит в разряд изобретательских, когда необходимым условием ее решения является устранение технического противоречия.
У машин и механизмов (вообще у технических объектов) есть несколько важнейших показателей, характеризующих степень их совершенства, например, вес, габариты, мощность, надежность. Между этими показателями существует определенное соответствие. Скажем, на одну единицу мощности требуется определенный вес конструкции. Чтобы увеличить уже известными в данной отрасли техники путями один из показателей, приходится «платить» ухудшением другого. Изобретательское творчество состоит в том, чтобы найти такой путь, при котором «платы» не требуется (или она непропорционально мала по сравнению с получаемым результатом)».

Источник: Альтшуллер Г.С., Основы изобретательства, Воронеж, «Центрально-черноземное книжное издательство», 1964 г., с. 48-49.

Приведенный выше текст появился «на свет» более 50 лет назад; он относится к конструированию технических систем. В информационных системах мы практически не сталкиваемся с весом, габаритами, или энергетической мощностью. Тем не менее, описанная ситуация является сегодня актуальной для аналитиков, занимающихся созданием информационных систем. Отличие в том, что аналитики «расплачиваются» другими параметрами своих систем: количество функций, удобство использования, расширяемость, надежность, безопасность и т.д.; общее – это тот же принцип «платы».

Заключение

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

Хозяин одного канадского ресторана (г. Данда) решил установить бильярдный стол в своём заведении. Но в Канаде установлены высокие налоги на азартные игры. Как, не платя налогов, радовать клиентов бильярдом?

Примечание: по ссылке можно подсмотреть подсказки и варианты решений. Но это ведь будет неспортивно!

Обсуждение на форуме: http://analyst.by/forum/materialy-saita/triz-sistemnym-i-biznes-analitikam

Ссылки

Предыдущие статьи по теме

1. Обзор ТРИЗ для системных и бизнес аналитиков. Часть 1