Большое количество изменений требований в проекте, в особенности, возникающих на поздних стадиях проекта, очень часто рассматривается как плохая работа аналитика. И хотя причины возникновения изменений не всегда зависят от качества работы аналитика, но «осадочек остается». Знакомая ситуация, не так ли?
В статье рассматривается метод, предназначенный для снижения количества изменений требований в проектах. Данный метод основывается на законах и линиях развития систем, представленных в Теории Решения Изобретательских Задач (ТРИЗ) Г.С. Альтшуллера (подробнее о ТРИЗ можно узнать также на сайте нашего сообщества в библиотеке в рубрике «статьи о ТРИЗ»). Суть метода состоит в прогнозировании возможных изменений требований на ранних стадиях работы с требованиями и соответствующее уточнение требований.
Применение данного метода позволит частично или полностью предотвратить причины, приводящие к появлению изменений. Звучит заманчиво, не так ли? Автор лично в этом убедился на нескольких своих проектах.
Причины появления изменений требований
Изменения требований являются часто встречающейся практикой проекта по созданию информационной системы или сервиса. Объяснение этого феномена следует искать в источниках и причинах появления изменений. Не секрет, что основными источниками непредвиденных изменений требований в проекте являются заказчики и пользователи. Среди причин, приводящих к изменениям, принято выделять:
1) У заказчика меняется понимание системы (сервиса), которое влечет за собой изменение требований
2) Заказчик нашел решение какой-либо бизнес-проблемы, которое предполагает изменение требований к системе (сервису)
3) Заказчик узнал о появлении на рынке нового ИТ-сервиса; это обстоятельство может привести к необходимости пересмотреть требования к системе
4) У Заказчика произошли какие-либо изменения (фин кризис, орг изменения в компании, изменения в составе учредителей и т.д.)
5) Во внешней среде произошли какие-либо изменения (новый законопроект; политический, экономический, финансовый кризис или просто изменения)
6) У исполнителя произошли какие-либо изменения (персонал, используемые инструменты и технологии, фин кризис, орг изменения в компании)
Недостаток традиционного подхода к работе с требованиями
Приступая к работе на новом проекте, аналитик первым делом определяет рамки будущей системы. После этого основное внимание аналитика сфокусировано внутри установленных рамок системы. При этом аналитик работает с требованиями, которые заказчики и пользователи системы могут сформулировать на данный момент времени, т.е., с представлениями заказчиков и пользователей «здесь и сейчас».
Как правило (но не всегда), аналитик не тратит время на анализ того, как рассматриваемая система будет меняться в будущем; он не работает с будущими требованиями. Соответственно, в таких случаях аналитик не может знать, когда именно эти будущие требования начнут проявляться, в том числе, по причинам, описанным выше.
Можно ли с этим что-то сделать?
Краткие сведения о ЗРТС и ТРИЗ
Помочь в работе с неожиданными изменениями требований может ТРИЗ (Теория Решения Изобретательских Задач), которая была разработана советским инженером Г.С. Альтшуллером в период с 1956 по 1998 годы.
Один из принципов ТРИЗ гласит: системы развиваются по объективным законам. «Знание законов развития ТС (технических систем, прим. автора) позволяет решать не только имеющиеся изобретательские задачи, но и прогнозировать появление новых задач. Результаты такого прогнозирования значительно точнее, чем полученные с помощью субъективных методов, например, экспертными оценками.» [Г.С. Альтшуллер. Справка ТРИЗ-88]
Дальнейшие разработки в ТРИЗ доказывают, что этот принцип верен не только для технических систем, но также выполняется и для других искусственных систем.
По сути, уже известные в ТРИЗ на сегодняшний день закономерности и линии развития систем описывают, каким образом меняются структура и поведение системы при увеличении требований к ней (подробнее о законах и линиях развития технических систем можно посмотреть в Википедии). В частности, в соответствии с ТРИЗ структура и поведение системы будут меняться не случайным образом, а в виде последовательных ответов на возникающие в системе противоречия.
Интересные примеры прогнозов на основе законов и линий развития систем представлены в книге
Н. Шпаковского Деревья Эволюции. Анализ технической информации и генерации новых идей.
Метод прогнозирования
Метод прогнозирования на основе законов и линий развития систем может быть применен аналитиком при работе с требованиями.
Метод основан на выявлении и решении возможных проблем и противоречий, которые будут возникать в системе при увеличении требований к ней.
Кратко метод можно представить в виде следующей последовательности действий:
1) Усилить существующие и/или добавить новые требования
2) Определить проблемы, которые возникают при реализации усиленных и/или новых требований
3) Определить противоречия, которые лежат внутри обнаруженных проблем
4) Разрешить найденные противоречия, используя методы ТРИЗ
Усиление требования означает, что аналитик должен спрогнозировать, что с требованием может произойти в будущем.
Если речь идет о количестве объектов системы или количестве субъектов, работающих с системой, то прогноз может состоять в том, что в будущем это количество может увеличиться в разы или даже на несколько порядков.
Если бизнес-требование устанавливает какие-то параметры, то усиление требования состоит в соответствующем увеличении или уменьшении значения такого параметра. Например, если бизнес-требование сформулировано как «уменьшить затраты на поддержку на 10% в год», то усиленное требование может быть сформулировано как «уменьшить затраты на поддержку на 50% (100%) в год», или даже как «полностью исключить затраты на поддержку».
Усиление требований позволяет вывить в системе так называемые компромиссные решения, т.е. те решения, которые применяются как компромисс для достижения противоречащих друг другу требований. Например, при локализации приложений часто возникает ситуация, когда локальный перевод команд меню приводит к искажению интерфейса. Использование сокращений слов или синонимов ухудшает понятность интерфейса.
Пример 1. При сборе требований к системе управления грузоперевозками заказчик указал, что помимо грузоперевозки клиентам в отдельных случаях компания может предоставлять дополнительный сервис по оформлению документов. Стоимость сервиса может учитываться как в рамках стоимости грузоперевозки, так и отдельно. В процессе анализа требований выяснилось, что в качестве дополнительного сервиса может также предоставляться страхование груза. Анализ отрасли позволил выявить, что количество дополнительных сервисов в грузоперевозках постоянно растет. Так, например, в последнее время появились такие виды сервисов, как конвой грузов, информирование клиента о местоположении и состоянии груза и т.п. На основании этих данных было сделано предположение, что в будущем компания будет расширять свое предложение клиентам, добавляя в него все новые виды дополнительных сервисов. Соответственно, будущая система управления грузоперевозками должна уметь работать с произвольным количеством дополнительных сервисов; при этом по мере внедрения в компании новых видов дополнительных сервисов система должна легко адаптироваться.
Для реализации данного требования было предложено решение, состоящее в том, что заявка заказчика будет включать список сервисов, в котором собственно грузоперевозка является одним из сервисов. Другими словами, решение предполагает переход от продажи грузоперевозки и фиксированного набора дополнительных сервисов к продаже набора (пакета) произвольного количества сервисов. По мере внедрения новых сервисов будет меняться состав пакета сервисов, но не будут меняться процессы работы с пакетом сервисов.
Результатом применения метода является образ будущей системы с учетом полученных решений. Используя этот образ, аналитик может сформировать новый перечень требований к системе и предложить его заказчику. В отношении прогноза требований заказчик может дать один из двух ответов: 1) Да, мне нравится прогноз требования и предлагаемое решение; 2) Нет, мы не собираемся усиливать это требование.
Очевидно, что оба ответа заказчика являются полезными (ситуация win-win) для проекта:
- Положительный ответ означает, что заказчику будут предложены решения, которые превышают его первоначальные ожидания. Маркетологи и продавцы говорят, что в таких ситуациях у заказчика возникает чувство восхищения, что весьма положительно сказывается на проекте.
- Отрицательный ответ заказчика означает, что проект защищен от неожиданных изменений этих требований со стороны заказчика в будущем. По идее, данное обстоятельство должно (может быть, а вдруг) вызывать чувство восхищения у менеджера проекта. В крайнем случае, аналитик может указать на то обстоятельство, что он понизил риски проекта.
Пример 2. При анализе требований по интеграции системы управления автотранспортом с системой спутникового мониторинга было установлено, что заказчик на основании данных мониторинга предполагает контролировать местонахождение транспортного средства. Изучение системы спутникового мониторинга позволило выяснить, что данная система может предоставлять данные не только о местонахождении транспортного средства, но также другие данные: скоростной режим, текущие запасы топлива и т.п. Заказчику было предложено добавить новые требования, касающиеся обработки дополнительных данных. Заказчик отказался от данных предложений, что позволило менеджеру проекта вычеркнуть риски изменения данных требований.
Заключение
Отличие рассматриваемого метода от традиционных подходов к прогнозированию состоит в том, что прогноз строится не для требований, а для проблем, которые неизбежно возникают в системе при увеличении требований к ней.
Подобно тому, как сложный сигнал можно представить в виде спектра, предлагаемый метод прогнозирования на базе ТРИЗ позволяет представить образ будущей системы в виде решений, возникающих в системе проблем. Подобно тому, как по спектру мы можем восстановить исходную форму сигнала, по образу будущего состояния системы мы можем восстановить требования, которые могут быть в такой системе реализованы.
А что вы думаете по поводу использования данного метода? Может быть, вы уже используете его. Может быть, вы отказались от его использования. Я буду рад услышать ваши комментарии и вопросы по поводу метода прогнозирования, а также пожелания по поводу других статей.
Автор выражает благодарности Роману Бакановичу и Юрию Веденину за их ценные замечания при рецензировании статьи.
Автор:
КУРЬЯН Андрей Георгиевич
бизнес-аналитик, специалист по ТРИЗ
Отличная статья.
Добрый день. Спасибо за хорошую статью.
А вы сами можете назвать проблемные моменты (ограничения) использования данного подхода исходя из своего опыта?
Заказчики действиительно любят когда им предлагают опции.
Правда бывают и такие, которые на предложеные опции отвечают «Why do you care! I was very specific what should be implemented.»
Также надо понимать, что для прогнозирования надо обладать серьезными знаниями в предметной области, что к сожалению очень часто невозможно (ну или приобретение знаний не оплачивается заказчиком). На мой взгляд это тоже ограничивает использование подхода.
Но всегдя хочется стремится к лучшему.
Спасибо, ppa.
При общении с заказчиками, отрицательно реагирующими на опции, я бы предложил сделать упор на управление рисками. Ну, в том духе, что мы не ставим под сомнение компетенции и качество требований заказчика. Мы проводим анализ и оценку рисков проекта. Еще лучше, если заказчик будет заранее, еще на стадии pre-sale, проинформирован о том, что вы проводите в своих проектах такую работу.
Что касается необходимости глубоких знаний в предметной области, то тут мы имеем дело с интересным противоречием: нужно приобрести знания в предметной области, чтобы сделать прогноз; и не нужно приобретать знания, чтобы не тратить время и не увеличивать затраты на проекте.
ИМХО, это противоречие может быть устранено с помощью знаний ТРИЗ. Например, что такое линии развития систем? Это знания о том, как происходит развитие систем в совершенно разных предметных областях. Изучив линии развития систем, аналитик сможет применять эти знания для любой системы, а не только для системы в данной конкретной предметной области. Следовательно, такие знания уже нельзя рассматривать, как часть проекта, которые после закрытия проекта станут бесполезными. Такие знания становятся важной частью компетенций аналитика и компании, в которой он работает.
Здесь есть еще один важный аспект. Когда аналитик находит в предметной области заказчика противоречие, то часто заказчик тоже не знает, как это противоречие можно разрешить. (Если знал, то почему не разрешил?) Часто наличие такого противоречия означает, что знаний предметной области уже недостаточно, чтобы разрешить противоречие. В такие моменты с точки зрения знаний предметной области заказчик и аналитик находятся в равных условиях. Точнее, у аналитика есть преимущество: он умеет работать с противоречиями.
Что касается проблемных моментов, то как же без них?
1. Аналитик должен знать ТРИЗ. Процесс обучения ТРИЗ предполагает, что аналитик изучит большое количество решений из совершенно разных предметных областей. А еще нужна практика применения этих знаний. На все это требуется время. На вопрос: «Сколько времени требуется для освоения ТРИЗ?» правильный ответ — «Вся жизнь.»
2. В ТРИЗ, как и в любой другой науке, нет ответов на любые вопросы. Например, линии развития или приемы устранения противоречий были выявлены на основании анализа большого количества известных решений. Очевидно, что уже имеющиеся знания будут уточняться, а также будут появляться новые знания.
Спасибо за статью!
Работая с требованиями к новой версии системы, я спрогнозировал возможные желания заказчика в виде дополнительного функционала и отразил всё это в документе Vision & Scope. Ожидания того, что заказчик отклонит доп. функционал как ненужный и тем самым сократит риски для менеджера проекта, не оправдались. Вместо этого заказчик взял таймаут на переосмысление своих требований. Похоже, что это win :)
Спасибо, Евгений.
Евгений,
если у вас будет такая возможность, то поделитесь с участниками сообщества своим опытом, например, в виде короткой заметки.
Спасибо за статью, Андрей!
Пара комментариев:
1) Если мы говорим о предварительном обсуждении расширения границ проекта с заказчиком, то, на мой взгляд, далеко не всегда обоснованными являются трудозатраты аналитиков/менеджера на прогнозирование и изучение возможных требований к системе. Да, это есть борьба с определенным риском, но зачастую проще этот самый риск принять либо переложить на плечи клиента, чем тратить время на непонятную и слабо продаваемую для заказчика активность. Имхо, как говорится, it depends:). Затраты на анализ всегда должны быть минимально достаточными, и не более. В своей практике я как-то больше сталкивался с нехваткой времени и бюджета на требования, чем с запасом на прогнозирование, детальный анализ бизнеса, нефункциональные требования а-ля «расширяемость» и другие подобные красивые активности.
2) Если речь идет о закладывании соответствующих запасов в архитектуру, код и т.п., то тот же самый XP, например, очень активно призывает не делать того, что не является жизненно необходимым в данный момент. Это минимизирует дефекты, сокращает суммарные эффорты и т.п. И в целом, общий эффект, с учетом риска изменения требований, заявлен как положительный. И я согласен с этим, так как не раз уже видел системы, которые спроектированы «на будущее» — это печалька, начиная с некоторого момента времени.
Спасибо, Герман!
1) Я уже писал в статье (http://analyst.by/articles/crowsourcing-in-business-analysis) о том, что аналитики в ИТ-проектах были не всегда. Роли системного и бизнес-аналитика появились в проектах сравнительно недавно, где-то в последние 5-7 лет. И причиной их появления является как раз потребность в снижении рисков проекта, в первую очередь, рисков, связанных с требованиями и управлением их изменениями. Как мы видим, управление рисками вовсе не пошло по пути перекладывания рисков на заказчика. И есть логичное объяснение этому: совокупные затраты, т.е., затраты разработчика + затраты заказчика, будут меньше, если риски не будут перекладываться только на заказчика, а будут распределяться между заказчиком и разработчиком. Таким образом, отрасль уже развивается по пути, на котором именно аналитики отвечают за снижение рисков изменений требований. А для этого им нужны знания и инструменты. Собственно, статья именно об этом.
2) Да, закладывание запасов в архитектуру и код — это известные в литературе примеры ошибок разработки. Я не могу припомнить источник, в котором такой пример появился впервые. Но потом этот пример начал тиражироваться достаточно широко.
В связи с этим примером у меняя возникают закономерные вопросы: а кто принимал решение о создании запаса по архитектуре и коду? Согласовывались ли эти запасы с требованиями заказчика? Подозреваю, что такие запасы создавались по инициативе разработчика, в силу его разумения о том, как будут меняться требования заказчика. Подозреваю также, что этот разработчик вряд ли в с своих предположениях опирался на понимание трендов развития системы заказчика; скорее, опирался на ЧСВ. Другими словами, ситуация с запасами архитектуры и кода была в неуправляемых условиях.
Но дело даже не в том, что прогноз требований позволяет проектировать систему «на будущее». Речь ведь идет не только и не столько о требованиях, сколько о выявлении и решении проблем, возникающих при прогнозировании требований. Я в заключении к статье обратил особое внимание именно на это обстоятельство.
Андрей, спасибо за хорошую статью и ценные комментарии. У меня есть два вопроса:
Спасибо, Вадим,
1) Для ответа на 1-й вопрос приведу такую аналогию. Мы предлагаем заказчику пушку, из которой можно стрелять на 10 км. Для правильного прицеливания мы также даем артиллерийские таблицы, которые разработаны на основании законов баллистики. Делая выстрел с использованием таких таблиц, заказчик ожидает, что снаряд попадет в цель. Должны ли мы возместить заказчику издержки, если он не попал в цель? Или в том месте, куда стрелял заказчик, вообще не было никакой цели?
Подобно тому, как артиллерийские таблицы, опираясь на законы баллистики, определяют, куда попадет снаряд после выстрела, прогнозирование требований, опираясь на законы развития систем, определяет, как будет выглядеть система при усилении требований к ней. При этом мы не можем за заказчика решить, правильно ли он выбрал цель для выстрела.
2) Я не думаю, что использование прогнозирования требований каким-то образом изменит технологию разработки продукта. Другое дело, что прогнозирование приведет к росту доли проектов, в которых создаются действительно новые продукты. Соответственно, степень вовлеченности заказчика в такие проекты должна только увеличиться.
Хорошо, давайте тогда и я приведу аналогию. Предположим, мы разрабатываем не программный продукт, а корпоративный праздник. Заказчик дал нам все полномочия для того, чтобы организовать самое эффектное мероприятие за всю историю компании, но сам склонялся к классическому вечеру в шикарном ресторане. Мы долго сомневались, какой же формат встречи выбрать, пока наш штатный синоптик (a.k.a. аналитик) не убедил нас, что в тот день, на который намечен корпоратив, будет самая прекрасная погода за всё лето, и проводить встречу в закрытом помещении – это крайне неудачное решение. Он лично строил прогноз на базе показателей самой современной техники и точнейших данных международных метеорологических организаций. Не первое столетие ведь анализируем!
Мы организовали ошеломляющее шоу под отрытым небом, но в самый разгар праздника на гостей обрушился страшнейший ливень. «Ошеломление» было настолько сильным, что несколько сотрудников сразу уволилось из компании, а остальные подали на неё в суд.
В какую цель не попал заказчик, и почему нам следовало переубедить его, базируясь лишь на собственном прогнозе, который может не оправдаться (и не оправдался)? Даже у СКПП (сверхкраткосрочного прогноза погоды) вероятность 95-96 %. А у СДПП – всего лишь 50. При этом метеорологи используют в своей работе весь существующий технологический максимум, в том числе искусственные спутники Земли и сложнейшие информационные системы.
Как Вы думаете, насколько современная предпринимательская деятельность уступает в своей непредсказуемости земной погоде?
Вадим, спасибо!
Прогноз в ТРИЗ отличается от прогноза погоды тем, что основан на выявлении и решении проблем, возникающих в системе.
Если использовать твою аналогию с организацией праздника, то неожиданный ливень можно рассматривать как проблему, решение которой может состоять, например, в том, чтобы сделать ливень частью сценария праздника (прием «обратить вред в пользу»), а на случай, если ливня не будет, то подготовить в кустах пожарную машину, с помощью которой можно создать ливень искусственно.
Андрей, спасибо, что продолжаете рассказывать о применении ТРИЗ в работе аналитика.
По статье мне не понятно, в чём именно заключается роль ТРИЗ при работе с требованиями. Вы привели метод из 4 шагов, где, собственно, о требованиях говорится только в первых 2. Но последующие 2 шага, где как раз идёт речь об обнаружении и разрешении противоречий, уже относятся к области решений, а не требований.
Спасибо, Виктор!
Попробую объяснить в терминах процессов.
ИМХО, требования нельзя рассматривать в отрыве от реализующих их решений. Собственно, процесс управления требованиями не заканчивается спецификациями, переданными разработчику. Формальным результатом процесса управления требованиями является решение заказчика (или владельца продукта) о том, что разработанный продукт в заданных мерах соответствует требованиям.
Как и любой управленческий процесс, процесс управления требованиями в своей структуре содержит обратные связи. Для того, чтобы этот процесс работал, необходимо, чтобы требования и решения были одного порядка. В следствие этого участники проекта (аналитик, заказчик, разработчик) рассматривают только такие требования, в отношении которых они знают подходящие решения. И наоборот, они не могут хотеть того, о чем они пока даже не задумывались: о том, что требования и удовлетворяющие их решения могут быть другими. Как вы понимаете, это обобщенная схема.
ТРИЗ знает о том, что системы развиваются по определенным законам развития. Если система сегодня такая, то завтра она будет изменяться определенным образом. Одним из основных драйверов развития системы являются противоречия, которые как раз и объединяют нашу парочку «требование — решение». Найдите в системе противоречие, найдите новое решение, которое устраняет противоречие, и вот вы получили новую устойчивую парочку «требование — решение».
Если что-то непонятно, то готов подробнее ответить на ваши вопросы.
Спасибо за пояснение. Действительно, обратная информационная связь от образа системы в будущем должна позволить определить и требования к ней. К сожалению, в Вашей статье меньше всего говорится о том, как применить ТРИЗ для составления такого прогноза. Понимаю, что это слишком большая тема, но, полагаю, было бы полезно привести несколько более развёрнутых примеров.
Виктор,
кстати, вы в курсе, что в середине мая в Санкт-Петербурге пройде конференция Analyst Days?
Да, разумеется. Собираюсь на неё.
Прогнозирование одна из самых сложных задач.
Стоит ли учитывать риски ошибочного прогнозирования?
Но покомбинировать и поусилять (я бы назвал поварить:) требования в диалоге с заказчиком может оказаться очень полезным,
поскольку часто заказчик использует первую пришедшую в голову или поверхностную формулировку требований и вы можете помочь ему выкристализовать идею.
Спасибо, Николай!
Обратите внимание, в своей деятельности мы все постоянно сталкиваемся с ситуацией, когда на начальной стадии проекта заказчики формулируют требования достаточно поверхностно.
Современные технологии разработки продукта, например, agile, решают эту проблему «втягиванием» заказчика в процесс разработки. По сути, мы принуждаем заказчика каждые 1-2-3 недели задумываться о том, правильный ли продукт мы делаем. Прогнозирование позволяет втянуть заказчика в глубокое переосмысление продукта уже на стадии первоначальной формулировки требований. Это уже само по себе позволит получить более осмысленные требования как можно раньше.
С рисками ситуация получается интересная. Если мы не делаем прогноза, то все риски того, что продукт получится неправильным, несет на себе заказчик. Мы даже не рассматриваем эти риски в проекте — делаем то, что сказал заказчик.
При этом мы также понимаем, что, как правило, заказчик сам никаких прогнозов не делает. Т.е., риск, что заказчик сформулирует требования неправильно, достаточно высок. Соответственно, риск неправильного продукта все равно существует.
Прогноз позволяет снизить общий риск. А распределение рисков между заказчиком и аналитиком, делающим прогноз, — это предмет для отдельных переговоров :)
Хороший заказчик в гибкой разработке постоянно делает предположения (a.k.a. прогнозы), но и так же постоянно их проверяет (тестирует). Кроме того, максимально возможно практикуется коллективное принятие решений. Хорошие команды не делают беспрекословно то, что говорит заказчик. То же Руководство по Скраму предписывает уважать решения заказчика, но не исполнять их слепо. Хороший заказчик не продавливает свои решения. Решения ищутся совместно в непрерывном процессе развития продукта. В том числе для обеспечения этих условий команду сопровождает фасилитатор – скрам-мастер/аджайл коуч.
Вадим,
ИМХО, Хорошему заказчику и Хорошей команде разработчиков во главе с Хорошим скрам-мастером будут весьма полезными знания законов развития систем и инструменты, специально заточенные для делания прогнозов. Прогнозы — дело тонкое; тут ведь манифеста недостаточно.
Абсолютно согласен в том, что любые релевантные знания и инструменты лишь усиливают команду. Самое главное, чтобы вовлечение в них существенно не снижало вовлечение во взаимодействие для достижения целей итерации/этапа/продукта. На мой взгляд, проблема ТРИЗ и его техник в высоком пороге вхождения. Я всегда испытывал живой интерес к этой теории, но мне элементарно не хватает времени, чтобы по-человечески с ней познакомиться.
Вы считаете, что материала Википедии достаточно для первого знакомства? Мне кажется, было бы чрезвычайно полезно разбирать в статьях хотя бы три-четыре примера из разных контекстов. А то концептуально всё понятно, а на практике попробовать нечего.
Вадим, вы правы, ТРИЗ имеет высокий порог вхождения. Естественно, материала в Википедии недостаточно даже для первого знакомства.
Я не считаю эти сложности недостатком ТРИЗ. Ведь совершенно не важно, по какой причине кто-то не изучает ТРИЗ: по недостатку времени, из-за неверия в то, что изобретать можно по науке или по какой-либо другой причине. Вот, например, тему этой статьи я заявил в качестве доклада на Analyst Days-2013. Один из членов программного комитета — Дмитрий Безуглый — при обсуждении этой темы заявил, что «триз не очень хороший инструмент» для бизнес-анализа. Чем не причина, чтобы не изучать ТРИЗ?
Я имел в виду проблему в контексте применения в гибкой разработке. Агилисты склонны выбирать наиболее простые и надёжные инструменты, всё остальное компенсируя личными навыками/качествами и командной синергией. Ну, и, конечно, автоматизацией всей рутинной однотипной работы.
Однако во мне есть внутреннее убеждение, что техники ТРИЗ, интегрированные в легковесный процесс, могут дать командам очень серьёзные преимущества. Я не оставляю идеи рано или поздно основательно с ними познакомиться. Надеюсь, в этом-следующем году такая возможность представится.
Здесь скорее дело в том, что пока не доказано (не показано), что ТРИЗ является эффективным инструментом в работе аналитика. ТРИЗ в том виде, в котором её разработал Альтшуллер, очевидно, имеет огромные возможности, но её адаптация к другим (не техническим) областям требует большого времени. В области разработки ПО мне не приходилось сталкиваться со значительными успехами ТРИЗ.
В конце 80-х, когда я впервые познакомился с ТРИЗ, эта тема не считалась эффективным инструментом даже в среде инженеров. Потребовалось 20 лет (90-ые и 0-ые), чтобы классический ТРИЗ распространился по миру, где и нашел свое признание. См. http://www.forbes.com/sites/haydnshaughnessy/2013/03/07/why-is-samsung-such-an-innovative-company/2/
Ситуация с применением ТРИЗ в бизнес-анализе и ИТ очень напоминает мне историю 20-летней давности. Применение уже началось. Уже выполняются успешные работы с применением ТРИЗ. Многие результаты составляют коммерческую тайну и не подлежат публикации. Если вас интересуют истории успеха применения ТРИЗ в БА или ИТ, то подождите лет десять и они появятся. Ну, или принимайте участие в их создании уже сегодня.
Спасибо за ссылку на статью — почитаю на досуге.
Что касается применения ТРИЗ в БА и ИТ, то это ещё вопрос, узнаем ли мы о том, что стояло за тем или иным «изобретением». Редко публикуются статьи, где акцент ставится именно на методе, а не результате работы (быть может, я просто не ищу такие).
К вопросу об историях успеха ТРИЗ: http://cpi.paris.ensam.fr/document-online/TRIZ-success-stories.pdf?goback=%2Egde_4485435_member_241393872