
Комментарии 13
А Вам не кажется, что ТРИЗ - это продукт советской инженерной мысли заточенный не на практическую эффективность, а на получение премии за рац.предложение. + еще секта свидетелей Альтшулера, которые этот ТРИЗ продвигают.
Не ожидал в первой публикации получить такой отзыв… но попробую на него кратко ответить.
ТРИЗ вырос из советской инженерной школы, но сегодня это вполне прикладной международный инструментарий, которым пользуются компании от машиностроения до фармы, сервиса и ИТ. Отличный доклад с реальными кейсами в 2022 году на HighLoad++ представил технический директор ВКонтакте Александр Тоболь «Техстратегия и архитектура highload-проекта на примере ВКонтакте».
Исторически Гентрих Альтшуллер (автор ТРИЗ) анализировал сотни тысяч патентов, а не охотился за премиями за рацпредложения, и за критику советской системы инноваций был сослан в лагерь, где серьезно подорвал здоровье. Это точно не бонус и не премия, а испытание.
Вокруг любого рабочего метода со временем формируется сообщество и у ТРИЗ есть независимые ассоциации, конференции, университетские курсы и рецензируемые публикации, в том числе по бизнес темам. Никто не кричит, что Agile, Scrum, Kanban, Lean – это секта, но при этом многие себя считают ИТ-евангелистами (https://ru.ruwiki.ru/wiki/ИТ-евангелист). Сейчас бум ИИ и уже есть тысячи сообществ по AI со своими амбассадорами промт-инжиниринга и AI-евангелистов. Это разве плохо? Обвинять любую методику в неэффективности корректно только там, где понятны критерии: что меряем, на каком горизонте и с чем сравниваем.
К слову сказать, в этом году моя статья на английском языке вошла в сборник XX-конференции международной конференции TRIZfest https://trizfest.org/ (Yogyakarta, Indonesia). Значит есть интерес у международного сообщества. Уже в 2026 году 21-я конференция пройдет в Китае, и организаторы планируют масштабно отметить 100-летие со дня рождения автора ТРИЗ – Генриха Альтшуллера.
Кстати, о Китае… грустно и печально становится от того, что, имея такую методологию, созданную внутри нашей страны, мы проигрываем Китаю.
Приведу несколько ссылок на документы:
«A Structured Representation Framework for TRIZ-Based Chinese Patent Classification via Reinforcement Learning» https://ieeexplore.ieee.org/document/9137486
«History of TRIZ development in China» https://r1.nubex.ru/s138756-b25/f374_ae/01_14Oct_History%20and%20future%20trends%20of%20China's%20TRIZ%20development_Li.pdf
«Undergraduate independent innovation capability teaching method based on TRIZ» https://patents.google.com/patent/CN104282190A/en
Как и в любой профессии, встречаются фанаты, но репутацию метода определяют реальные кейсы и результаты, а не стиль отдельных его промоутеров. Соглашусь, что часть тризовцев ведёт себя чересчур миссионерски. Но стиль продвижения и эффективность инструмента — разные вещи, тут важно не путать метод и его самых громких фанатов.
Не очень кратко, но постарался заранее избежать длительной переписки с аргументами и возражениями.
Рацпредложения можно и без триза делать, даже проще получается
Гештальт - закрыт !
любопытен список задач ит-проблем которые были решены через ТРИЗ. Пусть хотя бы три - последних и/или самых ярких. - Они станут хорошим анонсом будущих статей и поводом подписаться
Спасибо за поддержку! Именно для этого и сделал этот непростой шаг с попыткой выстроить диалог с IT-сообществом. Общаясь на ИТ-конференциях, был и интерес, и удивление, и запрос, и интересные дискуссии... Пока вывод один - нужно начинать применять ТРИЗ к своим задачам, и тогда станет понятен какой пласт ит-проблем внутри своей компании эффективнее всего решать с помощью ТРИЗ. Ну, а если, следовать пословице лучше один раз увидеть, чем сто раз услышать, то начните с просмотра этого выступления "Перепроектирование систем с использованием ТРИЗ" https://vk.com/video-65336816_456239638 (Codefest, 2024)
Прослушал сейчас доклад: Сергей Хованов. ТРИЗ как «помощь на дороге» при проектировании информационных систем. https://www.youtube.com/watch?v=Nrayz2cG694
И честно скажу, что пока всё очень слабо. ТРИЗ создавался для развития творческих и изобретательских способностей у людей, поэтому он получил широкое применение в инженерии, т.к. в СССР нужно было создавать то, чего ранее не существовало, т.е. создавать изделия для которых в мире "аналогов нет". Сюда относятся не только оригинальные технические изделия, способные пролететь полмира и устроить апокалипсис, но и мегапроекты электростанций, железных дорог и т.д. Иными словами, ТРИЗ хорош для изобретателей, исследователей и им подобных личностей, которые создают что-то новое. Например, ТРИЗ должен хорошо себя показать в R&D (Research and Development).
Но в IT большая часть работ - это стандартные задачи, т.е. процент R&D там очень мал, поэтому область применения ТРИЗ также ничтожно мала.
Второй момент заключается в том, что ТРИЗ был создан для заводов и фабрик, т.е. для промышленности, поэтому напрямую принципы ТРИЗ не получится использовать в сфере услуг (IT) и современных информационных системах (IT), т.е. нужна специальная адаптация ТРИЗ для IT. Как например, произошло с Agile, который является адаптацией бережливого производства (lean production) для IT. И честно говоря, я пока не уверен, что вы и десяток таких же фанатов ТРИЗ сможете предложить какой-нибудь фреймворк наподобие Agile, а без него ТРИЗ в IT будет как пятое колесо, т.е. бесполезная нашлёпка.
Чтобы популяризировать ТРИЗ в IT необходимо:
1. Cоздать новый формат терминов, адаптированных специально для IT.
2. Разобрать большое количество кейсов, где будет показана реальная проблема (а не шляпа с чаем из видео), конкретные решения и правила ТРИЗ, а также итоговый результат использования ТРИЗ.
3. Показать на примера, чем ТРИЗ лучше других методологий, которые уже существуют и решают реальные боли. В общем, чётко очертить область применения ТРИЗ в IT.
4. На основе всего описанного выше необходимо будет создать новый фреймворк наподобие Agile, но для ТРИЗ, где будет показана польза его применение для IT.
В общем - это огромный пласт работы и многие годы, пока новый подход не получит популярность и славу в IT.
Очень конструктивная обратная связь. Спасибо большое.
Вы совершенно правы - нужен фреймворк, а для этого нужны задачи, чтобы обкатывать его.
Доклад на который сослались - 2022 года, и он как раз и послужил триггером, чтобы внутри компании приступить к адаптации ТРИЗ для IT. В 2023 году мы сделали несколько проектов внутри и о самом масштабном мы рассказали в 2024 году на Codefest (о нём есть упоминание в публикации). На внутригрупповом групповом конкурсе проектов он занял 2 место.
Полностью разделяю позицию, что должна появиться область применения ТРИЗ для IT. Мы с коллегами из отдела работаем над этим. К сожалению, не обо всём можно публично рассказывать, но лично я продолжаю думать о том, как инструментарий сделать понятным и удобным для IT.
Некоторые инструменты (современной ТРИЗ) уже релевантны IT. Это работа с требованиями стейкхолдеров: от сбора до моделирования и выявления противоречивых. Далее включается сценарий по устранению противоречий, где мы пока выступаем менторами/наставниками/трекерами, ведущими команды за руку. Часто на этапе проработке задач упускаются из вида противоречивые требования или они умышленно укрываются аналитиками. Неустраненные конфликты в будущем превращается в костыли. Как всегда будет вопрос выбора: или делаем быстро и без глубокого анализа, но потом платим за доработки и исправления, или сперва проводим анализ, выявляем ключевые конфликты, устраняем их и потом тратим меньше ресурсов на разработку.
На текущий момент для коллег из продуктового направления IT сделали вот такой чек-лист https://4qz.ru/q0p83c2, который позволяет им с нашей поддержкой подумать над стратегией развития продукта. Команда или product owner ответил на вопросы, мы проанализировали, а потом вместе встретились и обсудили возможные стратегии развития продукта. Системы, а IT-решения - это искусственно созданные системы, развиваются закономерно, а, следовательно, закономерности можно учитывать и развивать продукт по более успешным траекториям.
Поэтому мы всё больше склоняемся к тому, что инструментарий ТРИЗ хорош на старте проекта, когда нужно понять что делать, разобраться с ситуацией, смоделировать несколько возможных сценариев, определить риски и поставить задачи, а дальше начинается обычная работа команды. Вероятность избежать ошибок в этом случае гораздо меньше.
Словами сложно описать возможные варианты применения ТРИЗ для IT, поэтому выбираю форматы конференций, где вживую можно пообщаться с IT-сообществом и нащупать чуть шире границы применения ТРИЗ в IT.
Ещё раз спасибо за обратную связь. Готов и открыт к взаимодействию.
Вот что меня триггернуло в статье
1) Agile - это разве фреймворк? Со скрамом /kanban нет смешения здесь? Для меня agile это прежде всего agile manifesto и подход быть , а не казаться.
2) для применения в it необходимо - вот здесь очень не хватает приписки "по моему мнению". Если конкретный Системный Аналитик или Ит архитектор в конкретной компании с помощью того же видоизменённого АРИЗ или даже в режиме "не по вкусу ТРИЗ, но по сути ТРИЗ" убедит заказчика или продукт оунера не делать какую то лютую свистоперделку или разрулит какой то структурный конфликт - это будет считаться применением в ИТ?
На мой взгляд - да, будет. согласен, что нужно заходить от архитектуры и проектирования систем, из архитекторов на мой взгляд немалое количество с ТРИЗ знакомы.
3) не является необходимым, но может быть полезным набор паттернов/антипаттернов вдохновлённых ТРИЗ по аналогии с каноническими паттернами проектирования от Gang of Four.
4)Не соглашусь, что только r&d задачи требуют ТРИЗ.Также немаловажно, что в ИТ имхо почти всегда есть способ неоптимально решить задачу, и не всегда обоснованно искать оптимальный способ. Но когда удаётся что то соптимизировать, то это красиво и есть чувство что паззл сошёлся. Ради этого и есть весь движ. Как вариант сделать ИИ проверку архитектуры (и артефактов анализа) с промптами/RAG вдохновлёнными паттернами ТРИЗ
Закрыть гештальт: запустить первую публикацию на Хабре до Нового года