ТРИЗ в бизнес-анализе

Теория решения изобретательских задач как инструмент для бизнес-анализа

Прогнозирование как способ уменьшения количества изменений требований

29.04.2013
New_preview_9(umbr)-1_new

Большое количество изменений требований в проекте, в особенности, возникающих на поздних стадиях проекта, очень часто рассматривается как плохая работа аналитика. И хотя причины возникновения изменений не всегда зависят от качества работы аналитика, но «осадочек остается». Знакомая ситуация, не так ли?

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

Применение данного метода позволит частично или полностью предотвратить причины, приводящие к появлению изменений. Звучит заманчиво, не так ли? Автор лично в этом убедился на нескольких своих проектах.

Причины появления изменений требований

Изменения требований являются часто встречающейся практикой проекта по созданию информационной системы или сервиса. Объяснение этого феномена следует искать в источниках и причинах появления изменений. Не секрет, что основными источниками непредвиденных изменений требований в проекте являются заказчики и пользователи. Среди причин, приводящих к изменениям, принято выделять:

  1. У заказчика меняется понимание системы (сервиса), которое влечет за собой изменение требований
  2. Заказчик нашел решение какой-либо бизнес-проблемы, которое предполагает изменение требований к системе (сервису)
  3. Заказчик узнал о появлении на рынке нового ИТ-сервиса; это обстоятельство может привести к необходимости пересмотреть требования к системе
  4. У Заказчика произошли какие-либо изменения (фин кризис, орг изменения в компании, изменения в составе учредителей и т.д.)
  5. Во внешней среде произошли какие-либо изменения (новый законопроект; политический, экономический, финансовый кризис или просто изменения)
  6. У исполнителя произошли какие-либо изменения (персонал, используемые инструменты и технологии, фин кризис, орг изменения в компании)

Недостаток традиционного подхода к работе с требованиями

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

Как правило (но не всегда), аналитик не тратит время на анализ того, как рассматриваемая система будет меняться в будущем; он не работает с будущими требованиями. Соответственно, в таких случаях аналитик не может знать, когда именно эти будущие требования начнут проявляться, в том числе, по причинам, описанным выше.

Можно ли с этим что-то сделать?

Краткие сведения о ЗРТС и ТРИЗ

Помочь в работе с неожиданными изменениями требований может ТРИЗ (Теория Решения Изобретательских Задач), которая была разработана советским инженером Г.С. Альтшуллером в период с 1956 по 1998 годы.

Один из принципов ТРИЗ гласит: системы развиваются по объективным законам.

Знание законов развития ТС (технических систем – прим. автора) позволяет решать не только имеющиеся изобретательские задачи, но и прогнозировать появление новых задач. Результаты такого прогнозирования значительно точнее, чем полученные с помощью субъективных методов, например, экспертными оценками.

Г.С. Альтшуллер. Справка ТРИЗ-88

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

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

Интересные примеры прогнозов на основе законов и линий развития систем представлены в книге
Н. Шпаковского “Деревья Эволюции. Анализ технической информации и генерации новых идей”.

Метод прогнозирования

Метод прогнозирования на основе законов и линий развития систем может быть применен аналитиком при работе с требованиями.

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

  1. Усилить существующие и/или добавить новые требования
  2. Определить проблемы, которые возникают при реализации усиленных и/или новых требований
  3. Определить противоречия, которые лежат внутри обнаруженных проблем
  4. Разрешить найденные противоречия, используя методы ТРИЗ

Усиление требования означает, что аналитик должен спрогнозировать, что с требованием может произойти в будущем.

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

Если бизнес-требование устанавливает какие-то параметры, то усиление требования состоит в соответствующем увеличении или уменьшении значения такого параметра. Например, если бизнес-требование сформулировано как «уменьшить затраты на поддержку на 10% в год», то усиленное требование может быть сформулировано как «уменьшить затраты на поддержку на 50% (100%) в год», или даже как «полностью исключить затраты на поддержку».

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

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

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

Требования заказчика

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

  1. Да, мне нравится прогноз требования и предлагаемое решение;
  2. Нет, мы не собираемся усиливать это требование.

Очевидно, что оба ответа заказчика являются полезными (ситуация win-win) для проекта:

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

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

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

Заключение

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

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

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

Автор выражает благодарности Роману Бакановичу и Юрию Веденину за их ценные замечания при рецензировании статьи.

Комментарии:  0

Добавить комментарий

Подписаться без комментирования