Системный сдвиг

На конфе "Анализ & Управление в ИТ-проектах" от Infostart мне очень понравился мастер-класс по ТРИЗ. ТРИЗ часто вспоминают в связи с ИТ, но толком мало кто может рассказать, как его системно применять. Тут тоже не было особо сильной привязки к ИТ, но зато наглядно показано, как сама техника работает, и почему очень важно найти и правильно сформулировать противоречие.

У нас в системном анализе есть фетиш: непротиворечивые требования. Так и в книгах, и в стандартах написано: требования к системе должны быть непротиворечивы. Если они противоречивы, то аналитик плохо выполнил работу. А в ТРИЗе другой подход, вообще противоположный: если вы не нашли противоречивых требований, то вы плохо сделали анализ! Не выявили ключевую проблему.

И ТРИЗ, вместо избегания противоречий или проектирования слабых компромиссных решений предлагает стремиться к такому решению, которое выполняет оба противоречащих условия! Только такие решения становятся прорывными. На мастер-классе предлагалось несколько вариантов рассуждений для выработки таких решений. Например, мне очень понравилась техника "обострение конфликта": вывод значения какого-то показателя далеко за рамки обычного диапазона. Например, противоречие: при торговле на фондовом рынке трейдер должен проанализировать риск сделки, и одновременно должен как можно быстрее сделать сделку, чтобы не упустить выгодные условия. Уведем значение "принятие решения о сделке" в запредельный диапазон, например - миллисекунды. Пусть трейдер принимает решение о сделке за микросекунды, и передает приказ о покупке или продаже за миллисекунды. Понятно, что при такой скорости трейдер не может быть человеком, а объем каждой сделки должен быть крайне небольшим, чтобы снизить риск (в идеале, сделки должны быть вообще безрисковые). Решение называется "высокочастотный трейдинг" (HFT), и сейчас до 40% объема торгов генерируется именно таким методом. Не уверен, что при изобретении HFT применяли ТРИЗ, но решение хорошо иллюстрирует пример рассуждения :)

Тут использованы несколько приемов ТРИЗ:
🔸 разделение конфликта по условию (используем не для всех сделок, а только для безрисковых)
🔸 новый принцип действия (человека заменяем алгоритмом, прошитым на FPGA)
🔸 переход в надсистему (HFT требует организации инфраструктуры со стороны биржи и не имеет смысла для одного трейдера, это услуга сразу для многих)
🔸 разделение конфликта во времени (трейдер заранее продумывает алгоритм принятия решения, а не в момент сделки)
🔸 разделение в пространстве (трейдер сидит в банке, а плата с FPGA устанавливается прямо в сервер биржи, иначе задержки передачи пакетов съедят всё время на принятие решения)

Другие приемы, упомянутые на МК:
🔸 разделение конфликтующих элементов в структуре системы (вот тут я сразу вспомнил DDD - ограничил контексты, и часть конфликтов уже ушла, а микросервисами можно регулировать противоречащие требования к надежности, скорости и безопасности)
🔸 объединение с антисистемой (вот тут не очень придумывается пример из ИТ, если у вас есть - пишите в комментариях)

Говорят, у Альтшуллера - создателя ТРИЗ - была таблица с типовыми техническими противоречиями. Вот бы такую таблицу для ИТ-систем составить. С типовыми же решениями. Чтобы деятельность архитектора из искусства превратить в инженерную практику.

www.tgoop.com/systemswing/132

2.0K viewsedited  Jun 5, 2023 at 16:57

На конфе "Анализ & Управление в ИТ-проектах" от Infostart мне очень понравился мастер-класс по ТРИЗ. ТРИЗ часто вспоминают в связи с ИТ, но толком мало кто может рассказать, как его системно применять. Тут тоже не было особо сильной привязки к ИТ, но зато наглядно показано, как сама техника работает, и почему очень важно найти и правильно сформулировать противоречие.

У нас в системном анализе есть фетиш: непротиворечивые требования. Так и в книгах, и в стандартах написано: требования к системе должны быть непротиворечивы. Если они противоречивы, то аналитик плохо выполнил работу. А в ТРИЗе другой подход, вообще противоположный: если вы не нашли противоречивых требований, то вы плохо сделали анализ! Не выявили ключевую проблему.

И ТРИЗ, вместо избегания противоречий или проектирования слабых компромиссных решений предлагает стремиться к такому решению, которое выполняет оба противоречащих условия! Только такие решения становятся прорывными. На мастер-классе предлагалось несколько вариантов рассуждений для выработки таких решений. Например, мне очень понравилась техника "обострение конфликта": вывод значения какого-то показателя далеко за рамки обычного диапазона. Например, противоречие: при торговле на фондовом рынке трейдер должен проанализировать риск сделки, и одновременно должен как можно быстрее сделать сделку, чтобы не упустить выгодные условия. Уведем значение "принятие решения о сделке" в запредельный диапазон, например - миллисекунды. Пусть трейдер принимает решение о сделке за микросекунды, и передает приказ о покупке или продаже за миллисекунды. Понятно, что при такой скорости трейдер не может быть человеком, а объем каждой сделки должен быть крайне небольшим, чтобы снизить риск (в идеале, сделки должны быть вообще безрисковые). Решение называется "высокочастотный трейдинг" (HFT), и сейчас до 40% объема торгов генерируется именно таким методом. Не уверен, что при изобретении HFT применяли ТРИЗ, но решение хорошо иллюстрирует пример рассуждения :)

Тут использованы несколько приемов ТРИЗ:
🔸 разделение конфликта по условию (используем не для всех сделок, а только для безрисковых)
🔸 новый принцип действия (человека заменяем алгоритмом, прошитым на FPGA)
🔸 переход в надсистему (HFT требует организации инфраструктуры со стороны биржи и не имеет смысла для одного трейдера, это услуга сразу для многих)
🔸 разделение конфликта во времени (трейдер заранее продумывает алгоритм принятия решения, а не в момент сделки)
🔸 разделение в пространстве (трейдер сидит в банке, а плата с FPGA устанавливается прямо в сервер биржи, иначе задержки передачи пакетов съедят всё время на принятие решения)

Другие приемы, упомянутые на МК:
🔸 разделение конфликтующих элементов в структуре системы (вот тут я сразу вспомнил DDD - ограничил контексты, и часть конфликтов уже ушла, а микросервисами можно регулировать противоречащие требования к надежности, скорости и безопасности)
🔸 объединение с антисистемой (вот тут не очень придумывается пример из ИТ, если у вас есть - пишите в комментариях)

Говорят, у Альтшуллера - создателя ТРИЗ - была таблица с типовыми техническими противоречиями. Вот бы такую таблицу для ИТ-систем составить. С типовыми же решениями. Чтобы деятельность архитектора из искусства превратить в инженерную практику.

BY Системный сдвиг