Мне говорили это годами, и каждый раз это удивляло не потому, что я не знал, что такое ТРИЗ. Знал, и знал давно. Удивляло другое: почему это вдруг всплывает не там, где я применяю его сознательно, а в разговоре про продукт или на бизнес-консультации, где я ни разу не открывал теорию решения изобретательских задач специально для этого случая.

Чем чаще это повторялось, тем очевиднее становилось: я не переключался между двумя разными способами думать. Работа с ТРИЗ в инженерных задачах настолько плотно встроилась в мою привычку разбирать любую задачу, что я стал применять тот же подход к продуктовым и бизнес-противоречиям на автомате, даже не называя это методологией вслух. Со стороны это выглядело как отдельное чутьё. На деле это было одно и то же мышление, которое я просто до этого момента не потрудился развести по полочкам и явно соединить.

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

Одно и то же движение под разными именами Ядро ТРИЗ — не перебор вариантов и не компромисс между двумя сторонами одного качества, оно в другом: если задача выглядит как выбор, каким концом пожертвовать, значит, настоящее решение ещё не найдено. Оно не выбирает сторону — оно снимает само противоречие.

Ровно этим устроено и хорошее продуктовое решение. Просто в инженерии это называют работой с техническим противоречием, а в продукте — почему-то до сих пор чаще называют «поиском баланса», хотя ход мысли один и тот же.

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

Как это переносится на бизнес шире продукта Тот же ход работает не только на экране приложения. «Дешевле» и «выше качеством», «быстрее» и «надёжнее», «больше контроля» и «быстрее принятие решений» — это всё та же форма ложного выбора. За каждой такой парой обычно прячется скрытое условие, при котором обе стороны перестают друг друга исключать. Найти это условие — и есть работа, а не выбор одной из двух плохих сторон.

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

Из этого объединения и родился Trizly — френдли ТРИЗ, как я его назвал. Это сервис, который проводит через тот же метод любого, у кого есть противоречие в продукте или бизнесе, а не только инженера с чертежом в руках.

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