Пояснение принципа прослеживания требований

Сбор и анализ требований

Сбор и анализ требований

Первые 90% работы отнимают
10% времени, а последние 10%
— оставшиеся 90% времени.
Правило 90/90

Все требования к проектируемой системе предлагается размещать на нескольких иерархических уровнях. На самом нижнем уровне располагаются требования, которые одинаково подходят для автоматизации технологических процессов в целом без учета особенностей конкретной прикладной области. Здесь необходимо обратиться к ГОСТам и другим нормативным документам. Далее следует уровень требований к автоматизированной системе определенного (заданного) класса с учетом соответствующих нормативных документов, определяющих порядок и описание заданного технологического процесса. И наконец, третий уровень составляют требования к конкретной системе. Кроме того, в стандарте IEEE 830-1993 Спецификация требований к ПО (Software Requirements Specification – SRS) проведено деление всех требований на две группы. Первая группа документирует потребности заказчика и записывается на языке, понятном заказчику – это т.н. С-требования. Вторая группа документирует требования в специальной, структурированной форме. Этот документ называют требованиями разработчика, или D-требованиями.

В ГОСТ 24.103-84 «Автоматизированные системы управления. Основные положения» перечислены общесистемные принципы, которые необходимо соблюдать при создании АСОИУ:

  1. системность – заключается в том, что при создании, функционировании и развитии АСУ должны быть установлены и сохранены связи между структурными элементами, обеспечивающие ее целостность;
  2. развитие – заключается в том, что АСУ должна создаваться с учетом возможности пополнения и обновления функций и видов ее обеспечения путем доработки программных и (или) технических средств или настройкой имеющихся средств;
  3. совместимость – заключается в обеспечении способности взаимодействия АСУ различных видов и уровней в процессе их совместного функционирования;
  4. стандартизация и унификация – заключается в рациональном применении типовых, унифицированных и стандартизованных элементов при создании и развитии АСУ;
  5. эффективность – заключается в достижении рационального соотношения между затратами на создание АСУ и целевыми эффектами, получаемыми при ее функционировании.

Кроме того, в п.3.4. ГОСТ 24.103-84 при создании АСУ рекомендуется максимально использовать типовые проектные решения, пакеты прикладных программ, унифицированные пакеты а также применять для новых объектов управления ранее созданные проекты АСУ. Это положение полностью соответствует принципам инженерии ПО, в особенности, концепции повторного использования компонентов.
ГОСТ 24.104-85 «Автоматизированные системы управления. Общие требования» устанавливает требования к каждому виду обеспечения отдельно. Перечислим те из них, на которые нужно обратить внимание.

Требования к программному обеспечению:

  1. В АСУ должны быть преимущественно использованы системы управления базами данных (СУБД), зарегистрированные в установленном порядке.
  2. Программное обеспечения АСУ должно иметь средства диагностики технических средств АСУ и контроля на достоверность входной информации.
  3. В программном обеспечении АСУ должны быть реализованы меры по защите от ошибок при вводе и обработке информации, обеспечивающие заданное качество выполнения функций АСУ.

Требования к информационному обеспечения АСУ

  1. Форма представления выходной информации АСУ должна быть согласована с заказчиком (пользователем) системы.
  2. В АСУ должны быть предусмотрены необходимые меры по контролю и обновлению данных в информационных массивах АСУ, восстановлению массивов после отказа каких-либо технических средств АСУ, а также контролю идентичности одноименной информации в базах данных.

Требования безопасности

  1. Неправильные действия персонала АСУ не должны приводить к аварийной ситуации.

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

Кроме сбора требований особое значение имеет процесс управления требованиями. В технологии Rational Unified Process определяются пять уровней зрелости процесса управления требованиями:

  1. требования записаны в согласованном формате;
  2. требования организованы, используются стандартные форматы и метаданные о требованиях, поддерживается контроль версий;
  3. требования структурированы в соответствии со своими типами (функциональными и нефункциональными);
  4. требования отслеживаются в соответствии с их типом;
  5. требования интегрируются с процессами управления изменениями, моделирования, кодирования и т.д.

Чтобы соответствовать первому уровню, достаточно взять стандартный текстовый редактор или электронную таблицу для хранения требований; при этом принципы их использования разными группами команды разработки не стандартизованы. На втором уровне документы с описанием требований должны иметь согласованный формат, следовать определенной схеме нумерации и контроля версий. Уровень структурированных требований означает переход к созданию стандартных спецификаций с целым рядом атрибутов (приоритет требования, риск, стоимость и др.). Следующие уровни ставят задачу отслеживания зависимостей между различными требованиями, а также их влияния на другие модели в жизненном цикле ПО.

Хорошую спецификацию отличают следующие элементы:

  1. Акцент на деталях и их четкое определение.
  2. Забота о недопущении неверного толкования.
  3. Непротиворечивость внутри данной спецификации и другими спеками.
  4. Логическая взаимосвязь компонентов.
  5. Полнота охвата предмета.
  6. Соответствие нормативным актам.
  7. Соответствие деловой практике.

С-Требования

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

Перед проведением интервью:

  • перечислить и расставить приоритеты в списке интервьюированных;
  • спланировать интервью с фиксированным временем начала и конца;
  • составить глоссарий проекта, в котором перечисляются основные термины предметной области.

Во время интервью:

  • задокументировать требования;
  • составить эскиз графического интерфейса;
  • спланировать следующую встречу.

После интервью:

  • составить черновик С-требований SRS с использованием CASE-инструментов;
  • определить конфигурацию оборудования;
  • передать черновик С-требований заказчику для получения его замечаний.

Рисунок – Порядок составления С-требований
Порядок составления С-требований

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

  • Методология SADT;
  • Диаграммы вариантов использования (use case) UML.
  • Диаграммы последовательности (sequence diagram) UML.
  • Диаграммы состояний (statechart diagram) UML.
  • Прототипирование дизайна пользовательского интерфейса входит в фазу проектирования программного обеспечения, однако его также можно считать и частью фазы формирования требований.

Порядок анализа требований заказчика включает следующие шаги:
1. Если требование простое и не имеет связей с другими требованиями, его выражают четкими предложениями в соответствующем разделе SRS.
2. Если требование представляет собой взаимодействие пользователя и приложения, то его, как правило, выражают с помощью варианта использования. Для этого:
2.1. Задают имена вариантам использования;
2.2. Определяют действующие лица;
2.3. Записывают последовательность действий пользователя и приложения;
2.4. Минимизируют ветвление.
3. Если требование затрагивает элементы обработки, каждый из которых получает и выдает данные, используют диаграмму потоков данных (DFD). При этом:
3.1. Определяют элементы обработки (обычно высокого уровня);
3.2. Определяют хранилища данных;
3.3. Показывают пути передачи данных между обрабатывающими элементами. Указывают типы данных, передаваемых в каждом случае.
4. Если требование затрагивает состояния, в которых может находиться программа (или части программы), строят диаграмму состояний в следующей последовательности:
4.1. Определяют состояния (каждое состояние обычно определяют отглагольным существительным, например «Ожидание»);
4.2. Указывают исходное и конечное состояние.
4.3. Определяют события, происходящие вне рассматриваемой части системы, и приводящие к переходу между состояниями;
4.4. Определяют вложенные состояния.

Как только С-требования собраны, как правило, возникает необходимость обновления SPMP. Такое обновление происходит в течение всего жизненного цикла системы. После анализа С-требований также может быть уточнена оценка стоимости системы.
Задача формулирования и корректного управления требованиями становится нетривиальной, если количество требований исчисляется несколькими десятками.

D-Требования

Разработчикам программного обеспечения нужна база для проектирования и разработки. Эта база представляет собой детальные требования (D-требования). D-требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа. Каждое из этих требований пронумеровано, помечено и отслеживается по ходу разработки. D-требования должны быть согласованы с С-требованиями.
Типичная последовательность действий для сбора и документирования D-требований показана на рисунке.

Рисунок – Порядок получения D-требований
Порядок получения D-требований

Существуют несколько типов D-требований:
1. Функциональные требования – определяют работу, которую должно выполнять проектируемая система (например, «приложение будет вычислять стоимость портфеля акций пользователя»).
2. Нефункциональные требования.
2.1. Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Заказчики и разработчики обсуждают ограничения по времени вычислений, использованию оперативной памяти, объему запоминающих устройств и т. д.
2.2. Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Требования такого типа предполагают вероятность неидеальной работы программы и ограничивают область ее несовершенства. Особое внимание в ПЗ необходимо уделить вопросам обеспечения безопасности системы с учетом возможности искажения данных посредством несанкционированного доступа, сбоя системного или прикладного ПО.
2.3. Обработка ошибок. Эта категория требований объясняет, как программа должна реагировать на возникающие ошибки. Например, что должна делать программа, если она получает сообщение из другой программы в неразрешенном формате? Это не касается ошибок, генерируемых самой программой.
2.4. Интерфейсные требования. Интерфейсные требования описывают формат, в котором программа общается с окружением.
2.5. Ограничения. Ограничения на проектирование или реализацию описывают границы или условия того, как приложение должно быть задумано и разработано. Например, накладываются ограничения на инструменты и языки программирования ввиду сложившихся традиций организации, опыта программистов, совместимости и проч.
3. Обратные требования – это функционал, который система не обеспечивает.

 

Типичная последовательность получения функциональных D-требований с использованием объектно-ориентированного подхода приведена ниже:

1. Процесс начинается с перечисления классов, упомянутых в вариантах использования – это т.н. классы анализа.
2. Полученный набор классов обычно неполон и следует попытаться найти остальные классы предметной области.
3. Для каждого из полученных классов выписывается вся необходимая функциональность программы, за которую отвечает данный класс. Например, «у каждого клиента будет имя» (атрибут класса Клиент) и «программа должна иметь возможность вычислять капитал каждого клиента» (метод класса Клиент). События, которые должны обрабатывать объекты класса, также должны быть определены. В это же время должны быть разработаны и планы тестирования для каждого D-требования.
4. Связи между классами определяются в два этапа:
4.1. Начальный набор связей определяется на основе анализа диаграмм сотрудничества (collaboration) или диаграмм последовательности. Если два объекта взаимодействуют (обмениваются сообщениями), между ними на диаграмме должна существовать связь (путь взаимодействия), которая преобразуется в двунаправленную ассоциацию между соответствующими классами. Если сообщения между некоторой парой объектов передаются только в одном направлении, то для соответствующей ассоциации вводится направление навигации.
4.2. Анализируются и уточняются ассоциации между классами-сущностями. Задаются мощности ассоциаций, могут использоваться множественные ассоциации, агрегации, обобщения и ассоциации-классы.
5. D-требования проверяются и сравниваются с С-требованиями.
6. D-требования проверяются заказчиком и, затем, публикуются.

Особое внимание необходимо уделить вопросу получения классов анализа, поскольку – это творческий процесс, тесно связанный с анализом информации о предметной области.

При получении классов анализа необходимо учитывать следующие аспекты:

  1. Класс анализа является четкой абстракцией, моделирующей один конкретный элемент предметной области. Он должен имеет от 3-х до 5-ти операций. Все свойства класса служат реализации его назначения. Однако для реализации своего назначения класс должен иметь минимальное количество связей с другими классами.
  2. В классах анализа содержаться только ключевые атрибуты и операции, определенные на очень высоком уровне абстракции. Как правило, каждая операция уровня анализа затем разбивается на несколько операций уровня проекта.
  3. Необходимо избегать глубоких деревьев наследования (3 и более уровней), поскольку частой ошибкой при построении иерархии наследования является использование функциональной декомпозиции, где каждый уровень абстракции имеет только одну операцию. Наследование использует только там, где есть явная иерархи наследования, вытекающая непосредственно из предметной области.
  4. При выявлении классов посредством анализа текста С-требования, существительные указывают на классы или атрибуты, а глаголы служат признаком операций. Однако синонимы и омонимы могут стать причиной появления ложных классов.
  5. При выявлении классов совместно с пользователями часто используют т.н. CRC(Class-Responsibilities-Collaborators)-анализ с помощью стикеров и мозговой штурм.

Без возможности четкого контроля каждого требования от проекта до программного кода, реализующего это требование, было бы сложно убедиться в том, что программа разработана в соответствии с установленными требованиями. Когда требования меняются (чего следует ожидать), это становится еще сложнее. Возможность отображать каждое требование на соответствующие части проекта и программы называется прослеживанием.
Один из способов, помогающих обеспечить прослеживание, заключается в отображении каждого функционального D-требования на конкретную функцию целевого языка. На рисунке демонстрируется обеспечение принципа прослеживания для некоторого требования №NNN «Поиск учебно-методических материалов (УММ)»:

  1. С-требования, сформулированные заказчиком при проведении анкетирования (или интервью), отображаются на диаграмме вариантов использования;
  2. на этапе проработки D-требований, каждое С-требование представляется комплектом из трех диаграмм: деятельности, классов и последовательностей;
  3. при проектировании архитектуры системы для удовлетворения требования №NNN в некотором классе слоя предметной области предусматривается соответствующий метод(ы) (например, «findByAuthor» и «findByTitle)»;
  4. на стадии детального проектирования прорабатывается алгоритм метода, отвечающего за выполнение требования №NNN, а также создается ER-диаграмма БД и конструируется SQL-запрос(ы), выполнение которого обеспечит удовлетворение данного требования;
  5. на стадии реализации для выполнения требования №NNN разрабатываются листинги соответствующих методов и, наконец, на стадии тестирования выполнение требования №NNN проверяется с использованием составленного плана тестирования.

Рисунок – Пояснение принципа прослеживания
Пояснение принципа прослеживания требований

На протяжении всего процесса проектирования необходимо прилагать усилия по планированию будущего тестирования. Существует несколько преимуществ в написании тестов одновременно с требованиями.
Во-первых, это позволяет прояснить требование.
Во-вторых, это переносит некоторую часть работы из фазы тестирования проекта в фазу разработки требований. Пусть, например, SRS включает в свой состав D-требование №NNN следующего содержания: «NNN. ФИО каждого студента информационной системы «Деканат» будет представлять собой строку символов от 1 до 256». C целью планирования процедуры тестирования необходимо составить проект плана тестирования, примерная форма которого может быть представлена в виде таблицы .

Таблица «Тестовые данные для проверки D-требования №nnn»

№ п/п Входные тестовые данные Ожидаемый результат
1 Иванов Иван Иванович Иванов Иван Иванович
2 length()<10 Сообщение с вопросом о корректности вводимых данных
3 length()>256 Сообщение с вопросом о корректности вводимых данных
4

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

Рисунок «Шаблон таблицы для проверки D-требований»
Шаблон таблицы для проверки D-требований

Во втором столбце таблицы приводится идентификатор D-требования. В столбце 3 приводится идентификатор С-требования, в состав которого входит данное D-требование. В столбце 4 приводятся идентификаторы D-требований, выполнение которых необходимо и достаточно для реализации данного D-требования. В столбце 5 делают отметку, если данное D-требование не противоречит никакому другому D-требованию из перечисленных в таблице. В столбце 6 делают отметку, если данное D-требование может быть реализовано с учетом ограничений, накладываемых другими С- или D-требованиями, средой разработки, аппаратной платформой и т.д.

В столбце 7 делают отметку, если данное D-требование не может быть истолковано двояко. В столбце 8 делают отметку, если данное D-требование сформулировано предельно просто. В случае отсутствия отметки необходимо привести дополнительные разъяснения по содержанию такого требования. В столбце 9 делают отметку, если в данном требовании указаны допустимые отклонения от необходимого результата. В столбце 10 делают отметку, если формулировка данного D-требования не претерпит существенных изменений при возникновении в будущем необходимости наращивания функциональных возможностей системы. В столбце 11 делают отметку, если для данного требования составлен план тестирования. В столбце 12 делают отметку по окончании реализации данного D-требования в виде программного кода.

Порядок разработки каждого D-требования показан выше на рисунке и включает следующие шаги:

  1. Предварительный анализ требования:
    1. Классификация требования как функциональное или нефункциональное (рекомендуется использовать подсказки IEEE SRS для большинства нефункциональных требований);
    2. выбор метода организации функциональных требований.
  2. Обеспечение прослеживания требования. Убедиться в возможности прослеживания при проектировании и реализации.
  3. Обеспечение тестируемости требования. Спланировать конкретный тест, устанавливающий выполнение требования.
  4. Проверка недвусмысленности требования.
  5. Назначение требованию приоритет. Например, высокий («важно»), средний («желательно») или низкий («не обязательно»).
  6. Проверка полноты требования. Для каждого требования следует убедиться в присутствии всех остальных необходимых или сопутствующих требований.
  7. Добавление состояния ошибки:
    1. сформулировать, что требуется выполнить при возникновении нештатных ситуаций;
    2. в критичных местах добавить состояния ошибок программирования.
  8. Проверка согласованности. Необходимо убедиться, что ни одно требование не противоречит каким-либо аспектам другого требования.

Как только все D-требования собраны, необходимо обновить SPMP и передать D-требования под управление конфигурациями.
Для формализации и детальной фиксации требований рекомендуется использовать спецификацию требований к программному обеспечению (Software Requirements Specification — SRS) в соответствии со стандартом IEEE 830-1993.


Babok v3: бизнес-анализ для управления изменениями

Автор: Демьяненко Василий, консультант по управлению изменениями ( «Управление изменениями — проект Василия Демьяненко» )


Что такое BABOK

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

Авторы руководства BABOK стараются объединить существующие точки зрения на задачи, стоящие перед бизнес-аналитиками, к которым относятся:

  • выявление потребностей;
  • обоснование изменений;
  • разработка решений.

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

  • стратегическом;
  • тактическом;
  • оперативном.

Изменения и BABOK

Важно отметить, что BABOK, являясь стандартом, динамично меняется с учетом новых знаний и опыта бизнеса-аналитиков. При чем даже в самых своих основах. Так, в третьей версии дано новое определение бизнес-анализа. Ранее акцент делался на работе по анализу и выработке рекомендаций в достижение целей и установление связей между заинтересованными лицами. Rick Strempler еще до выхода последней версии стандарта в статье «BABOK VERSION 3: WHAT BUSINESS ANALYSTS CAN EXPECT», отмечает, что при рассмотрении ключевых концептов, бизнес-аналитики много внимания уделяют выявлению проблем, возможностей (концепту NEEDS) и принятию решений (Solutions), пренебрегая другими концепциями. Теперь акцент сделан на проведении изменений, отражающих динамику происходящих процессов. Само понятие «change» рассматривается, как преобразующее действие в ответ на потребность. В третьей версии стандарта бизнес-анализ -это деятельность, позволяющая внедрять изменения в компании путем определения потребностей и рекомендации решений, которые обеспечивают ценность для заинтересованных лиц.

В общем, мы коснулись двух изменений — изменение самого стандарта и акцент на change в работе бизнес-аналитика.

Что учитывает управляющий изменениями (концептуальная модель)

Для того, чтобы достигать поставленных целей, удовлетворять потребности заинтересованных лиц необходимо проводить изменения. Инициативы в этом направлении рассматриваются, как улучшения организации и являются преднамеренными, контролируются через деятельность бизнес-аналитика.
Основой для понимания центральных идей стандарта являются шесть концептов (понятий). Это те направления, которые необходимо учитывать аналитику для достижения желаемого результата.
babok_concept_6_modules

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

  • потребностей;
  • воздействия и влияния на изменения;
  • отношений к решению.

Потребности (Needs) — проблемы и возможности, которые:

  • вызывают изменения;
  • являются стимулом действовать для заинтересованных лиц;
  • требуют решения;
  • разрушают или повышают ценности.

Ценность (Value) — потенциальная или реализованная стоимость, значимость или полезность чего-либо:

  • для заинтересованных сторон;
  • в конкретной ситуации (контексте);
  • удовлетворять потребности.

Решение (Solution) — выбор способа действовать, который:

  • должен удовлетворять потребности;
  • учитывать сложившийся контекст (ситуацию);
  • соответствовать заинтересованным сторонам.

Контекст (Context) — любые обстоятельства окружающей среды

  • обеспечивают понимание изменения.

Наряду с перечисленными концептами введено понятие «изменения», и, как мы видим, на рисунке ему отводится верхнее место (собственно и повествование о концептах начинается с «change»). Под изменением понимается акт трансформации деятельности предприятия для повышения производительности. При этом «изменения» рассматриваются в системной взаимосвязи с другими концептами (на рисунке это показанно в виде линий между понятиями). Руководство BABOK обращает внимание на то, что зависимости так же важны, как сами концепты.
Собственно для того, чтобы эффективно управлять изменениями необходимо обращать внимание на все элементы и взаимосвязи концептуальной модели (круговую поруку). Например, чтобы достичь ценности, необходимо разработать решение по изменению. Эффективное решение требует понимания контекста, в котором оно будет реализовываться. Ценность существует не сама по себе, а призвана удовлетворять потребности. Чтобы выявить потребности следует разобраться с заинтересованными лицами.
babok_change_management

Действия по управлению изменениями

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

  • понять текущее состояние КАК ЕСТЬ,
  • определить будущее состояние КАК ДОЛЖНО БЫТЬ,
  • определить действия по переходу от «как есть» к «как должно быть».

При этом не стоит рассматривать все этапы по переходу из одного состояния в другое, как запланированные. Стандарт предоставляет возможности выбора для бизнес-аналитика исходя из конкретного контекста и задач — некоторые этапы могут быть структурированы заранее, другие без предварительной организации.
Деятельность бизнес-аналитика заключается в содействии перехода от потенциальной ценности до ее превращения в реальную. Достигается это путем эффективного применения потенциала предприятия. Для чего и необходимо производить изменения.
babok_line_implementation

Как видно из рисунка работа разделяется на три части.

  • I-я: Стратегический анализ представляет собой непрерывный процесс по отслеживанию потребностей и текущей ситуации в их изменении. Познакомившись с этой информацией и возможными решениями, заинтересованные стороны определяются с тем, стоит ли удовлетворять озвученные потребности. Полученная в результате стратегия может представлять собой стратегический план, концепцию, дорожную карту и т.д.
  • II-я: Чтобы эффективно управлять процессом изменений необходимо перейти от общих, абстрактных желаний, жалоб, запросов к конкретным показателям и задачам. Для этого вводится понятие «требования», представляющее собой практическое отражение потребностей. Требования помогают понять те виды ценностей, которые будет возможно достичь для заинтересованных сторон. Помощником для бизнес-аналитика станет вопрос «Почему требование необходимо». Все требования должны быть взаимосвязаны и соответствовать друг другу (стандарт выделяет требования бизнеса, заинтересованных лиц и решения).
    Процесс выявления, анализа требований и формулирования возможных решений является итерационным. Таким образом проводятся мероприятия от исследования потребностей и описания начальной концепции до рекомендаций конкретного решения в следующей потребности: описывается набор требований; требования проверяются на непротиворечивость; они утверждаются, гарантируя ценность для бизнеса; структурируются для поддержания общей бизнес-цели; проводится анализ компромиссных решений и рекомендации по проекту.
  • III-я: Оценка решения происходит, как на этапе обоснования проекта, так и в процессе его реализации или по завершению. Это позволяет рекомендовать действия по устранению ограничений, преодолению трудностей и в работе с рисками.

Широкие возможности и учет особенностей конкретной инициативы

Принятие решения невозможно безотносительно к конкретной ситуации. Одной из составляющих контекста являются особенности, индивидуальность организации и заинтересованных лиц (в т.ч. убеждения, культура, стереотипы, стандарты компании и пр.). Бизнес-аналитик при выборе способов работы, конкретных методик, разработке решений опирается не только на методологии, но и специфику компании и личный опыт. Например, в одних компаниях процесс бизнес-анализа может быть формализован, стандартизирован, подписан ключевыми заинтересованными лицами (повышая обязательства всех сторон), а в других носить менее формальный характер. Подходы к планированию варьируются от прогнозных (сводящих к минимуму неопределенность и максимизирующими контроль) до адаптивных (рассчитанных на короткие итерации). Выбор того или иного подхода зависит, как от возможности определить будущее заранее, так и отношения заинтересованных лиц к неопределенности и контролю.
Babok нацелен на то, чтобы предоставить бизнес-аналитику широкие возможности проявлять гибкость в работе. Так, если стандарт ИСО 9001 опирается на процессный подход, то рассматриваемое руководство BABOK считает, что специалист может воспользоваться любой методологией, позволяющей удовлетворить бизнес-потребности с учетом конкретной ситуации. Для достижения лучшего результата бизнес-аналитикам рекомендуется изменять или создавать новые методы.

В BABOK рассмотрены наиболее распространенные точки зрения на организацию бизнеса . Они описывают различные взгляды на бизнес-анализ и служат неким направлением, в рамках которого аналитик смотрит на свою деятельность в конкретных условиях. К таким отнесены: гибкие методологии (agile); интеллектуальный анализ данных; информационные технологии; архитектура бизнеса; управление бизнес-процессами (список является неполным и бизнес-аналитики вправе использовать и другие). С помощью руководства BABOK читатель получает представление о том, каковы границы возможностей применения каждой точки зрения, каково влияние на изменения, цели, текущую деятельность, какие методы и приемы уникальны для каждой перспективы и пр.
На практике при реализации проектов, усилиях по определению целей может использоваться больше чем один из взглядов (перспектив). Скорее всего они будут пересекаться и дополнять друг друга в зависимости от сложности инициатив. Например, может потребоваться оптимизация бизнес-процессов, осуществляемая с помощью гибких методик, для автоматизации (ИТ) системы.
Управление изменениями с помощью непрерывного обучения

Стандарт BABOK описывает область знаний по планированию и мониторингу бизнес-анализа. Это призвано координировать и организовывать деятельность бизнес-аналитиков вместе с заинтересованными сторонами, что достигается путем анализа деятельности и внесения изменений. Выявляя возможности повышения производительности бизнес-аналитика, обеспечивается непрерывное обучение, используются возможности совершенствования деятельности всех участников процесса изменений.
С этой целью вводятся показатели эффективности, позволяющие отслеживать улучшения в работе путем определения профилактических, коррекционных или развивающих действий на всех этапах изменений. Важно отметить, что эффективность аналитической деятельности зависит от конкретной ситуации с учетом реализуемой инициативы и особенностей организации. Выбранные показатели эффективности призваны поощрять одни модели поведения и мешать другим.
Работа по оценке эффективности может документироваться или быть неформальной, показатели количественные и качественные – главное, чтобы она позволяла бизнес-аналитику определить проблемы и способы повышения эффективности. Выявив потенциальные точки улучшения, бизнес-аналитик руководствуется ими в работе над новыми задачами.
В работе по оценке ценности аналитической работы могут принимать участие все заинтересованные лица, бизнес-аналитик всегда открыт для обратной связи.

Выводы

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

  • Сделал акцент на роли бизнес-аналитика в управлении изменениями. При реализации инициатив не стоит зацикливаться на технических аспектах проекта.
  • Предоставляет широкие возможности для поиска результативных и эффективных решений в любой ситуации. Таким образом бизнес-аналитик имеет разносторонний набор перспектив будущего и инструментов для управления, что дает возможность ему, как субъекту проявить свободу воли.
  • Рассматривает управление изменениями всесторонне, а не только в границах перехода от «как есть» к «как должно быть». В частности, с учетом тех ценностей, которые призваны привнести изменения (а не изменения ради изменений), разных заинтересованных сторон, сил влияющих на процесс и все это в динамике складывающейся ситуации (а не статической картинки).
  • Предполагает анализировать цель с учетом потребностей всех заинтересованных сторон. Это позволяет вскрыть подводные течения, сделать процесс выбора цели и способа ее достижения более прозрачным и избежать перекосов в сторону какой-то из сторон (что в процессе деятельности создает обязательно дополнительные проблемы и вызывает сопротивление изменениям). Изменяемая система представляется не как механистическая, а сложноорганизованное живое предприятие.
  • Процесс управления рассматривается динамично. Контроль осуществляется через требования (показатели), позволяющие отслеживать действия и результаты по достижению поставленных целей. И наряду со статичными требованиями, которым должно удовлетворять решение и которые описывают потребности, выделяются переходные. Такие требования носят временный характер и позволяют осуществлять планомерный переход из одного состояния в другое, утрачивая свою актуальность после достижения промежуточных целей. Они используются для обеспечения непрерывности бизнеса, обучения, преобразования данных.
  • Ведет к развитию компании путем организации непрерывного обучения. Бизнес-аналитик с помощью заинтересованных лиц оценивает эффективность бизнес-анализа, выявляет причины отклонения от ожиданий и находит способы улучшить результаты в будущем.

Исходная статья: Babok v3: бизнес-анализ для управления изменениями


Методы решения проблем, поиска идей и работы с информацией

5 Whys (5 Почему). Техника решения проблемы путем пяти последовательных уточнений «Почему?». Позволяет уточнить причинно-следственные связи конкретной проблемы.
6 Thinking Hats (Шесть шляп мышления Эдварда де Боно). Метод группового (или индивидуального) принятия решений. Позволяет взглянуть на одну и ту же проблему с разных точек зрения. Шесть шляп: белая — информация; красная — чувства и интуиция; черная — критика; желтая — логический позитив; зеленая — креативность; синяя — управление процессом.
7S Framework (7S: structure, strategy, systems, skills, style, staff and shared values). Оценка внутренней среды компании, работающей на рынке: 1) стратегии компании; 2) конкурентные преимущества; 3) цели и ценностные установки; 4) кадровый состав; 5) стиль деятельности фирмы; 6) организационная и функциональная структура; 7) различные процессы, протекающие в ней (управление, производство, сбыт, движение информационных потоков).
After Action Review (Обзор после действия). Анализ командой прошлого опыта, успехов и неудач с целью улучшения будущей ситуации и избежания повторных ошибок. Включает задавание нескольких простых вопросов: что должно было случиться? Что на самом деле случилось? Что сработало нормально? Что не сработало нормально? Поняв ситуацию, можно снова запускать процесс обучения и основные механизмы действий.
Appreciative Inquire (Позитивное исследование). Поиск тех лучших свойств организации, которые помогают ей достигать успеха и оставаться эффективной, в целях дальнейшего роста (включает 4 этапа: открытие, мечта, дизайн, действие).
Backwards Forwards Planning (Обратное составление графика). Установление даты получения результата и разработка графика осуществления необходимых для этого действий.
Before Action Review (Подготовительный анализ). Метод предварительной оценки группой всех имеющихся знаний, возможностей, рисков и ресурсов перед принятием решений и началом действий.
Better Practice Transfer (Перенос лучших практик). Метод выявления и оценки наиболее успешных практик решения задачи для применения их в новых условиях.
Boundary Examination (Определение рамок проблемы). Способ улучшения формулировки проблемы для повышения ясности задачи, разделения того, что является релевантным и нерелевантным для решения конкретной проблемы.
Brainstorming (Мозговой штурм). Генерирование группой большого количества идей в ходе коллективного обсуждения. Любые идеи при этом принимаются без оценки и критики.
Card Sorting (Сортировка карточек). Метод упорядочения разнородной информации для создания ее структуры, лучшего понимания взаимосвязей частей — с помощью карточек.
Collective Notebooks (Коллективная записная книжка). Способствует генерации идей в рамках организации: каждый из участников в течение недели записывает свои мысли и идеи по поводу решаемой проблемы в блокнот. На регулярной основе участники собираются и обсуждают сгенерированные решения. Метод поддержки креативности и партнерства.
Communities of Practice (Сообщество практики). Обсуждение проблемы в сообществе экспертов из различных областей, каждый из которых привносит свой опыт и экспертизу для решения общей задачи.
Concept Fan (Веер идей). Способ обнаружения альтернативного подхода к проблеме. Основывается на принципе «сделать шаг назад», чтобы получить более широкую перспективу и варианты решений.
Consensus Mapping (Карта согласия). Техника приведения разнородной информации к общему знаменателю. Достигается путем нанесения на общую карту мнений и точек зрения, с которыми согласны большинство участников обсуждаемой проблемы.
Critical Decision Method (Метод экспертного решения). Проведение ретроспективного интервью с целью заполнения пробелов в решении сложных задач, требующих экспертного участия. Помогает понять, как выполняют задачу люди, имеющие опыт.
Environmental Scanning (Сканирование внешней среды). Метод сбора данных о среде организации, которая может быть использована для планирования, развития и контроля организационных процессов. Может применяться для подготовки организации к серьезным изменениям.
Fishbowl (Аквариум). Техника коллективного обсуждения проблемы в присутствии нескольких зрителей. Может использоваться для обмена идеями и информацией с целью освещения ее с разных сторон.
Force Field Analysis (Анализ силового поля). Метод решения проблем управления, который заключается в идентификации сил, способствующих и препятствующих достижению поставленной цели.
Future Backwards (Из прошлого в будущее). Метод сценарного планирования, позволяющий увеличить количество точек зрения на понимание прошлого и диапазон возможных вариантов будущего.
Gap Analysis (Анализ пробелов). Позволяет изучить несоответствия, разрывы между текущим состоянием компании и желаемым, выделить проблемные зоны, препятствующие развитию, и оценить степень готовности компании к переходу от текущего состояния к желаемому.
Heuristic Ideation Technique (Генерирование эвристик). Техника, позволяющая генерировать инновационные идеи, разделяя на составные элементы и комбинируя их в необычном порядке.
Interdependency Matrix (Матрица взаимодействия). Может быть использована для анализа взаимодействия и взаимозависимости параметров — задач, процессов, групп, целей. Помогает получить более полный анализ взаимодействия значимых факторов и оценить их влияние на эффективность.
Juggling Perspectives (Жонглирование перспективами). Метод принятия решений на основании хорошо взвешенных интересов путем выслушивания и обсуждения мнений всех заинтересованных сторон.
KJ-method. Применяется для выработки оптимального группового решения. Участники группы вырабатывают решения, которые затем группируются, и из них отбираются лучшие. Позволяет определить командные приоритеты и ресурсы.
Mind Mapping (Когнитивная карта). Способ изображения процесса мышления в виде схемы. Используется для создания идей, их визуализации и классификации как метод принятия решений (например, при мозговом штурме) при написании статей.
NAF (New, Appeal, Feasibility — Новизна, привлекательность, осуществимость). Простой способ оценки свежих идей на предмет возможности их воплощения по трем критериям.
Negative (Reverse) Brainstorming (Обратный мозговой штурм). Техника мозгового штурма с использованием обратных формулировок вопросов для разработки более креативных идей, чем при обычном мозговом штурме. Применяется в случаях, когда сложно найти прямое решение проблемы.
Nominal Group Technique (Техника номинальных групп). Метод принятия групповых решений, который предполагает учет мнений всех участников, ранжирование и выбор наилучшего.
Open Space Technology (Открытое пространство). Метод организации рабочего пространства для работы группы — на совещаниях, планерках, командных сессиях. Используется для поиска решения проблем, стратегического планирования, обмена знаниями и укрепления команды.
Paraphrasing Key Words (Перефразирование ключевых слов). Техника подразумевает изменение значения ключевых слов в формулировке задачи для того, чтобы создать альтернативное восприятие.
Peer Assist (Помощь сверстников). Техника группового предпроектного обучения: выяснение мнений по проблеме, проекту или деятельности, извлечение уроков из знаний и опыта участников.
PMI (Plus/Minus/Interesting — Плюс/Минус/Интересно). Метод оценки большого количества идей для их первоначальной фильтрации.
Reframing Matrix (Матрица рефреминга). Позволяет определить альтернативные видения деловой проблемы, которые в итоге могут способствовать разработке более широкого спектра креативных решений.
Rich Pictures (Визуализация). Механизм для изучения сложных или плохо определенных проблем, предполагающий использование картинок, пиктограмм, фотографий, которые позволяют получить лучшее представление о проблеме.
SCAMPER (быстрая оценка). Постановка вопросов, стимулирующих возникновение новых идей. Методика часто используется для разработки новых продуктов. Техника заключается в том, чтобы последовательно отвечать на вопросы о модификации рассматриваемой задачи (заменить, комбинировать, добавить, модифицировать, применить, упростить, перевернуть).
Skills Export-Import (Экспорт-импорт навыков). Метод используется для создания матрицы навыков, необходимых и уже имеющихся в команде.
Social Network Analysis (Анализ сетей). Метод визуализации нашего окружения, позволяющий определить, как лучше взаимодействовать с каждым для обмена знаниями.
Speed Networking (Быстрые знакомства). Формат проведения коротких нетворкинг-сессий в рамках деловых встреч для обмена информацией и установления новых деловых контактов.
Stakeholders Analysis (Анализ мнений заинтересованных сторон). Позволяет выявить ключевые группы стейкхолдеров, их мнения и ожидания относительно результатов проекта.
Stakeholders Management (Отношения со стейкхолдерами). Метод позволяет определить, какие отношения налажены с заинтересованными сторонами. Анализ того, как эти отношения могут быть преобразованы в партнерские.
Storytelling (Рассказывание историй). Метод передачи информации и идей путем рассказывания метафорических историй способствует более глубокому пониманию передаваемых знаний.
Strategic Conversation (Стратегический разговор). Беседа о будущем организации, которая позволяет проанализировать ситуацию и достичь большей эффективности.
SWOT-анализ (strength, weaknesses, opportunities, threats). Оценка сильных и слабых сторон, возможностей и угроз для объекта (организации) для принятия оптимальных решений.
Synectics (Синектика). Метод основан на простой концепции для решения проблем и креативного мышления. Вы должны генерировать идеи и оценить их.
The World Cafe (Мировое кафе). Метод работы в группе. Позволяет вовлечь в обсуждение всех участников, активизировать коллективный интеллект и располагает к полномасштабному, многоуровневому диалогу.
ИКР (Идеальный конечный результат). Модель эталонного/идеального решения. В конкретной ситуации ИКР может быть недостижим, но является при этом ориентиром желаемого будущего в процессе решения.
Инфографика. Графический способ подачи информации, данных и знаний. Позволяет более наглядно показать соотношение предметов и фактов во времени и в пространстве.
Метод «Снежного кома». Метод развития идеи путем постепенного прибавления к ней дополнительных деталей.
Метод Дельфи. Метод многоступенчатого заочного анонимного экспертного оценивания. Заключается в последовательных индивидуальных опросах, проводимых обычно в форме анкетирования. Ответы обобщаются и вместе с новой дополнительной информацией поступают в распоряжение экспертов, после чего они уточняют свои первоначальные ответы. Такая процедура повторяется несколько раз до достижения приемлемой сходимости совокупности высказанных мнений. Суть метода в том, чтобы с помощью серии последовательных действий (опросов, интервью) добиться максимального консенсуса среди экспертов при определении правильного решения. Прямые коллективные обсуждения исключаются, чтобы избежать влияния экспертных, более авторитетных мнений.
Метод Кепнера и Трего. Матричный подход к принятию решений через изучение альтернатив решения, сильных и слабых сторон и выбора окончательного наилучшего варианта. При заполнении матрицы для каждой альтернативы определяются цифровые показатели и высчитывается значение по каждому фактору с последующим получением веса каждого варианта решения.
Метод Уолта Диснея. Суть метода — представить себя последовательно в трех ролях: мечтателя, реалиста, критика. Техника подходит для решения простых и конкретных креативных задач. Используется в творческом процессе поиска новых идей и решений и основана на различных стратегиях мышления.
Метод фокальных объектов. Способ генерации необычных идей путем подбора ассоциаций к изначальному объекту посредством случайно выбранных трех других объектов. Применяется для совершенствования объекта за счет получения большого количества оригинальных его модификаций с неожиданными свойствами.
Морфологический анализ. Основан на подборе возможных решений для отдельных частей задачи (так называемых морфологических признаков) и последующем систематизированном получении их сочетаний (комбинировании). Комбинируя варианты реализации элементов объекта, можно получить самые неожиданные новые решения.
Попарное сравнение. Методика, основанная на попарном сравнении альтернатив — по одной или нескольким ключевым характеристикам.


Инструменты бизнес-анализа для бизнес-аналитика

Acceptance and Evaluation Criteria Definition

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

Определить, какие требования могут быть наиболее эффективно использованы в качестве критериев приемки или оценки.

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

Критерий приемки и оценки может быть определен, если может быть продемонстрированно, что решение или компонент решения соответствует требованию. Критерий приемки обычно используется, когда только одно возможное решение в настоящее время оценивается и, как правило, выражается в виде положительного или отрицательного решения. Критерии оценки используются для сравнения нескольких решений или компонентов решения и допускают использование диапазона возможных баллов.
Элементы метода
1. Тестируемость
2. Скоринг (рейтинг)

Backlog Management

Бэклог (backlog) — это приоритезированный список всех работ, записанный в виде коротких описаний.
Каждый элемент бэклога должен удовлетворять следующим принципам:

  • Detailed Appropriately — иметь надлежащую детализацию;
  • Estimated — иметь оценку;
  • Emergent — должен быть возникающим, неожиданно появляющимся. Эмерджентность — наличие у какой-либо системы особых свойств, не присущих её элементам, а также сумме элементов, не связанных особыми системообразующими связями, несводимость свойств системы к сумме свойств её компонентов. Т.е. бэклог не статичен, он изменяется с течением времени, по мере того, как мы больше узнаем о решении, истории в бэклог добавляются, удаляются элементы или изменяются их приоритеты;
  • Prioritized — элементы бэклога должны быть приоритезированы.

Управление бэклогом — это «наука» скользящей работы через этапы последовательного жизненного цикла продукта/решения в эффективной форме.

Ключевыми аспектами успешного управления бэклогом являются:

  • Постановка целей;
  • Назначение и согласование приоритетов;
  • Установление организационных обязательств и отношений;
  • Реализация процесса достижения целей;
  • Измерение производительности;
  • Анализ производительности;
  • Аудит процесса.

Управление бэклогом включает в себя следующие процессы:

  • Управление рабочими запросами;
  • Разработка заказов на выполнение работ, подготовка к работе и ремонтные процедуры;
  • Планирование работ;
  • Выполнение работы и мониторинг незавершенных этапов работ.

Product Backlog:
product backlog
Sprint Backlog:
sprint backlog

Balanced Scorecard

Сбалансированная система показателей (ССП) — концепция переноса и декомпозиции стратегических целей для планирования операционной деятельности и контроля достижения целей. По сути ССП — это механизм взаимосвязи стратегических замыслов и решений с ежедневными задачами, способ направления деятельности всей компании на достижение стратегических целей.
Сбалансированная система показателей
Основная структурная идея BSC состоит в том, чтобы сбалансировать систему показателей в виде четырех групп.
Первая группа включает традиционные финансовые показатели. Как бы мы ни доказывали важность рыночной ориентации предприятия и совершенства внутренних процессов, собственника всегда в первую очередь будут интересовать показатели финансовой отдачи на вложенные средства. Поэтому сбалансированная система должна начинаться (в классификации) и заканчиваться (в конечной оценке) финансовыми показателями.

Вторая группа описывает внешнее окружение предприятия, его отношение с клиентами. Основными фокусами внимания выступают:

  • способность предприятия к удовлетворению клиента;
  • способность предприятия к удержанию клиента;
  • способность приобретения нового клиента;
  • доходность клиента;
  • объем рынка;
  • рыночная доля в целевом сегменте.

Третья группа характеризует внутренние процессы предприятия:

  • инновационный процесс;
  • разработка продукта;
  • подготовка производства;
  • снабжение основными ресурсами;
  • изготовление;
  • сбыт;
  • послепродажное обслуживание;

Четвертая группа позволяет описать способность предприятия к обучению и росту, которая фокусируется в следующие факторы:

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

6 обязательных элементов СПП:
1. Перспективы (perspectives) — компоненты, при помощи которых проводится декомпозиция стратегии с целью ее реализации. Обычно используются 4 базовые перспективы, однако их список можно дополнить в соответствии со спецификой стратегии компании. Базовыми перспективами являются:

  • Финансы (получение стабильно растущей прибыли — «как видят нас акционеры компании»);
  • Клиенты (улучшение знания каждого клиента — «как видят нас клиенты»);
  • Процессы (внутренние процессы компании — «чем мы выделяемся среди конкурентов»);
  • Персонал (обучение и развитие) и инновации («как мы создаем и увеличиваем ценность для наших клиентов»).

перспективы
2.Стратегические цели (objectives) определяют, в каких направлениях будет реализовываться стратегия.
стратегические цели
3. Показатели (measures) — это метрики достижений, которые должны отражать прогресс в движении к стратегической цели. Показатели подразумевают определенные действия, необходимые для достижения цели, и указывают на то, как стратегия будет реализована на операциональном уровне.
показатели
4. Целевые значения (targets) — количественные выражения уровня, которому должен соответствовать тот или иной показатель.
5. Причинно-следственные связи (cause and effect linkages) должны связывать в единую цепочку стратегические цели компании таким образом, что достижение одной из них обуславливает прогресс в достижении другой (связь по типу «если-то»).
6. Стратегические инициативы (strategic initiatives) — проекты или программы, которые способствуют достижению стратегических целей.
Стратегические карты
проекты

Benchmarking and Market Analysis

Benchmarking (Бенчмаркинг)

Бенчмаркинг – это процесс изучения хозяйственной деятельности конкурентов, продуктов, услуг и процессов деятельности конкурентов, с целью использования их положительного опыта в работе своей компании (реализации изменений для достижения и сохранения конкурентоспособности).
В зависимости от объектов сравнения бенчмаркинг может подразделяться на несколько видов:

  • Внутренний бенчмаркинг – при этом виде бенчмаркинга осуществляется сравнение процессов (продуктов, услуг) внутри организации. В качестве объектов выбираются близкие или похожие процессы (продукты, услуги). При внутреннем бенчмаркинге довольно легко собрать данные, однако возможности для сравнения ограничены, и результаты могут оказаться предвзятыми.
  • Конкурентный бенчмаркинг – сравнение проводится с прямыми конкурентами (по предоставляемым продуктам или услугам), работающими на местном, региональном или международном рынке. Для этого вида бенчмаркинга необходимо выбирать конкурентов, находящихся на другом «уровне» рынка. Например, организация, работающая на местном рынке, может выбрать для сравнения организацию, работающую на международном рынке. В этом случае данные, полученные при сравнении, будут более обоснованными и важными, но их довольно трудно получить.
  • Функциональный бенчмаркинг – сравниваются процессы собственной организации с похожими процессами другой организации, но работающей в другой сфере деятельности. При таком виде бенчмаркинга можно получить объективные и важные данные с меньшими усилиями, применяя этичные и легальные методы получения информации.
  • Обобщенный бенчмаркинг – для этого вида бенчмаркинга отбираются организации, которые обладают лучшими в своем сегменте процессами и подходами. Такие организации открыто публикуют информацию о деятельности (примерами могут служить публикации по производственной системе Toyota, или по системе 6–сигм компании Motorola). Из этих процессов и подходов выбираются для изучения и сравнения наиболее подходящие. После чего они адаптируются для условий своей собственной организации.

Основные этапы бенчмаркинга включают в себя:
1. Определение, анализ и детализация объекта бенчмаркинга. В качестве объекта могут быть выбраны процессы, услуги или продукты организации. На этом этапе важно понять, сколько ресурсов и усилий организация готова потратить на процесс бенчмаркинга — будет ли это разовое мероприятие или бенчмаркинг станет постоянной практикой организации.
2. Выявление и определение характеристик, по которым будет проводиться бенчмаркинг. Это могут быть важные потребительские свойства продукта или услуги, или параметры качества процесса.
3. Формирование команды бенчмаркинга. В команду лучше включать специалистов из различных подразделений организации, чтобы была возможность более широко и объективно оценить возможности как своих процессов (продуктов, услуг), так и процессов (продуктов, услуг) партнеров по бенчмаркингу.
4. Выбор партнеров по бенчмаркингу. В качестве партнеров могут выступать организации-лидеры, добившиеся успеха в реализации интересующих характеристик (определены на этапе 2). Партнером может быть одна организация или несколько. Если выполняется внутренний бенчмаркинг, то такими партнерами будут смежные подразделения, процессы или продукты предоставляемые самой организацией.
5. Сбор и анализ информации, необходимой для сравнения. Чтобы провести сравнение может потребоваться представить полученную информацию в том же виде, как она представляется внутри организации. Например, если сравниваются технические характеристики продукта, то у разных производителей набор этих характеристик может различаться. Характеристики необходимо будет привести к единой «базе».
6. Проведение оценки возможности организации в достижении необходимых характеристик в сравнении с партнером (или партнерами) по бенчмаркингу. Оценка может проводиться различными методами, которые позволяют оценить существующий «разрыв» между работой собственной организации и работой партнера по бенчмаркингу (например, с помощью GAP – анализа).
7. Определение возможных изменений существующей практики работы. Создается «видение» будущего состояния организации. Это видение должно быть основано на результатах адаптации процессов партнера по бенчмаркингу к условиям своей организации.
8. Разработка стратегических целей и планов по их реализации для достижения желаемого уровня характеристик. В зависимости от масштабности изменений планы могут затрагивать изменение процессов, системы управления, организационной системы, культуру исполнения работ и др. аспекты.
9. Реализация запланированных изменений и постоянный контроль за ходом преобразований в организации. Если необходимо, то выполняются корректировки планов.
10. После достижения установленных целей и реализации планов принимается решение о повторении цикла и реализации всех этапов бенчмаркинга для новых условий.

Market Analysis (Анализ рынка)

Анализ рынка (Market Analysis) — внешний анализ спроса, потребностей, конкуренции, дистрибуции, факторов окружающей среды, влияющих на спрос и поведение потребителей.
Описание этапов анализа рынка:
Этап 1. Определить цели и основные задачи анализа рынка.
Этап 2. Составить последовательный план маркетингового анализа рынка.
Этап 3. Определить возможные сроки и максимальный бюджет на анализ рынка.
Этап 4. Определить методы анализа рынка и источники получения информации по рынку.
Этап 5. Провести необходимые маркетинговые исследования рынка товаров или услуг.
Этап 6. Подготовить наглядный анализ всей собранной информацией с выводами.
Этап 7. Составить сводный отчет по анализу рынка.
Этап 8. По необходимости подготовить презентацию по проведенному маркетинговому анализу рынка.

Перед тем, как приступить к анализу рынка, необходимо определить предмет анализа (что будем анализировать?) и описать цели анализа.

Предмет анализа Описание цели
Структура рынка Проведение анализа емкости и конъюнктуры рынка, оценка рыночных тенденции
Товар компании Проведение анализа развития рынка и рыночной доли товара компании в сегменте
Целевой сегмент Проведение анализа привлекательности сегментов рынка с целью выбора целевого рынка
Потребитель Проведение анализа спроса на рынке и анализа ключевых потребностей рынка, подробное изучение поведения, требований целевой аудитории к продукту
Цены Проведение анализа ценового позиционирования конкурентов, действующей структуры цен в отрасли
Свободные ниши Анализ сегментов рынка с целью поиска свободных рыночных ниш и новых источников продаж
Конкуренты Проведение конкурентного анализа рынка с целью анализа конкурентных преимуществ товара и определения слабых стороны компании

5 видов исследования рынка:
1. Интервью — индивидуальная беседа по открытым вопросам для выявления гипотез.
2. Наблюдение — наблюдение за потребителем в привычной окружающей среде.
3. Фокус-группа — групповая дискуссия по открытым вопросам для выявления гипотез.
4. Опросы — количественный опрос по закрытому списку вопросов.
5. Полевые исследования — количественная проверка и оценка нескольких альтернатив.

Описание доступных источников информации о рынке:
Личные интервью. Поговорите лично с целевой аудиторией рынка, проведите 5-10 интервью. Включите в интервью пользователей разных торговых марок, потребителей и непотребителей рынка. Опросите тех, кто принимает решение и влияет на покупку и тех, кто пользуется купленным товаром. На такой опрос вы потратите меньше недели и получите много полезной информации
Форумы и соцсети. Используйте возможности интернет: возможность спросить потребителей на форумах, в социальных сетях, по электронной почте, связаться по Skype — все это снижает затраты на исследование
Ресурсы интернет. Изучите имеющуюся информацию в интернет по интересующей тематике, в том числе информацию о смежных рынках.
Сотрудники компаний. Опросите сотрудников компании о вопросах, которые вас интересуют, узнайте их мнение; отдельно побеседуйте с представителями отдела сбыта. Если вы проводите исследование рынка как независимая сторона — проведите интервью с руководителями компаний.
Личное наблюдение. Сами понаблюдайте за поведением покупателей в местах продаж: как он делает выбор, как выбирает.
Личный опыт. Попробуйте сами стать покупателем своего продукта и опишите свои впечатления.

Brainstorming

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

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

  • Главное — количество идей. Не делайте никаких ограничений.
  • Полный запрет на критику и любую (в том числе положительную) оценку высказываемых идей, так как оценка отвлекает от основной задачи и сбивает творческий настрой.
  • Необычные и даже абсурдные идеи приветствуются.
  • Комбинируйте и улучшайте любые идеи.

3 этап — Группировка, отбор и оценка идей. Этот этап часто забывают, но именно он позволяет выделить наиболее ценные идеи и дать окончательный результат мозгового штурма. На этом этапе, в отличие от второго, оценка не ограничивается, а наоборот, приветствуется. Методы анализа и оценки идей могут быть очень разными. Успешность этого этапа напрямую зависит от того, насколько «одинаково» участники понимают критерии отбора и оценки идей.

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

Business Capability Analysis

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

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

Business Model Canvas

Бизнес-модель «Канвас» — представляет собой способ визуализации бизнес-модели, которая по-умолчанию состоит из 9 структурных блоков:

  • Ключевые партнеры;
  • Ключевые виды деятельности;
  • Ценностные предложения;
  • Взаимоотношения с клиентами;
  • Потребительские сегменты;
  • Ключевые ресурсы;
  • Каналы сбыта;
  • Структура издержек;
  • Потоки поступления доходов.

Иллюстрация структуры бизнес-модели «Канвас»
Структурные блоки бизнес-модели "Канвас"
Как работает модель?
Схема работы с бизнес-моделью
Три основные формы бизнеса:
Три основные формы бизнеса

Business Rules Analysis

Бизнес-правила являются условиями или ограничениями, которые определяют, как работает бизнес. Поэтому бизнес-правила должны быть проанализированы наряду с бизнес-требованиями.
Бизнес-правило — это конкретная, исполняемая и проверяемая директива, которая находится под контролем организации и которая служит для поддержания бизнес-политики.
Бизнес-правила состоят из различных компонентов: терминов, фактов и правил. Термины — это описание правил, факты опираются на термины, а правила строятся на фактах. Бизнес-правила представляют собой сочетание принципов и выводов, которые определяют, как мы делаем бизнес.

Бизнес-правила должны быть:

  • Указаны в соответствующей терминологии, чтобы позволить Экспертам по предметным вопросам домена проверить правила.
  • Документально независимыми от того, как они будут соблюдаться.
  • Изложенными на «атомном уровне» и в декларативной форме.
  • Отделенными от процессов, которые поддерживаются или ограничиваются правилом.
  • Обслуживается в порядке, который позволяет организации контролировать и адаптировать правила, как изменение бизнес-политик.

Бизнес-аналитикам может потребоваться выявить и проанализировать бизнес-правила. Однако, существует специальная роль бизнес-аналитика, которая посвящена управлению и анализу бизнес-правил: «аналитик бизнес-правил».
Аналитик бизнес-правил выполняет следующие функции:
1) Анализ, проектирование и выполнение бизнес-правил, которые управляют организацией и ее деятельностью;
2) Понимание, как бизнес-правила определяются, документируются и управляются;
3) Карта бизнес-правил и процессы, управляемые бизнес-правилами;
4) Обновление бизнес-правил в соответствии с организационными изменениями;
5) Проверка, какие бизнес-правила будут затронуты при ограниченных организационных изменениях;
6) Управление рисками, которые могут помешать реализации бизнес-правил.

Collaborative Game

Совместные игры относятся к структурированным методам, включают в себя правила, позволяющие участникам сосредоточить внимание на конкретной цели. Игры используются для того, чтобы помочь участникам поделиться своими знаниями и опытом по некоторой теме, выявить скрытые упущения, а также выявить знания, которые не могут появиться в ходе обычного взаимодействия. Обмен опытом в совместной игре поощряет людей с различными точками зрения работать вместе, чтобы лучше понять проблему и описать общую модель для ее решения.
Совместным играм дополнительную пользу приносит нейтральный участник (посредник), который помогает участникам понять правила игры и помогает обеспечить их соблюдение. Работа посредника состоит в том, чтобы сохранить игру и двигаться вперед, чтобы гарантировать, что все участники играют необходимые роли.
Совместные игры также обычно включают сильные визуальные или тактильные элементы. Такие действия, как перемещение заметок, написание на доске или рисование стимулируют творческое мышление и помогают взглянуть со стороны на обсуждаемые проблемы/темы.
12 совместных игр (agile инструментарий)

  • Broken Skype
  • Crazy Chat
  • Collaborative Origami
  • Listening Game
  • Movers & Shapers
  • Human Knot
  • 123 go
  • Columbian Hypnotist
  • Non Musical Chairs
  • Yes, and
  • Magic Stick
  • Singing, Clapping, Numbers

Data Dictionary

Словарь данных — аналитическая модель, описывающая структуры данных и атрибуты системы.
Словарь данных определяет состав структур данных, а также их значение, тип данных, длину, формат и разрешенные значения элементов данных, из которых состоят эти структуры. Серийные средства моделирования данных часто включают компонент-словарь данных. Во многих случаях словарь данных лучше хранить как отдельный артефакт, не внедряя его в спецификацию требований к ПО. Это повышает возможности повторного использования в других проектах.
Словарь данных (data dictionary) представляет собой набор подробной информации об используемых в приложении сущностях данных. Сбор информации о составе, типах данных, разрешенных значениях и т. п. в виде единого ресурса, служащего для определения критериев проверки данных, помогает разработчикам правильно писать программы и избавляет от проблем с интеграцией. Словарь данных является дополнением к словарю терминов проекта, который определяет термины предметной области или бизнес-термины приложения, сокращения и акронимы. Мы рекомендуем поддерживать словарь данных и словарь терминов отдельно.
Во время анализа требований информация словаря данных представляет элементы и структуры данных предметной области. Эта информация попадает в дизайн в форме схем баз данных, таблиц и атрибутов, что в конечном итоге определяет имена переменных в программах. Время, потраченное на создание словаря данных, будет более чем компенсировано временем, которые вы сэкономите, избежав ошибок по причине того, что участники проекта по-разному понимают ключевые данные. Если вы регулярно обновляете словарь данных, он останется ценным средством и при обслуживании системы, и при разработке схожих систем. В противном случае он может вводить в заблуждение, предоставляя устаревшую информацию, и члены команды перестают доверять ему. Ведение словаря данных — серьезный вклад в повышение качества. Определения данных часто повторно используются в других приложениях, особенно в одном семействе продуктов. Использование единообразных определений данных в компании снижает вероятность возникновения ошибок интеграции и интерфейса. По возможности используйте существующие стандартные определения данных из хранилища корпоративных знаний, используя менее масштабный набор определений в проекте для восполнения пробелов.

Data Flow Diagram

Диаграмма потока данных — модель анализа, описывающая процесс, хранилища данных, внешние сущности и потоки, характеризующие поведение данных, проходящих через бизнес-процессы или программные системы.
Диаграмма потоков данных (data flow diagram, DFD) — основной инструмент структурного анализа. Она позволяет определять процессы преобразования системы, совокупность (хранилище) данных или материалов, которыми система управляет, и потоки данных или материалов между процессами, хранилищами и внешним миром.
При моделировании потоков данных для системного анализа используется прием разложения функций, при котором сложные проблемы раскладываются на составляющие, размещаемые по нарастающей по уровням детализации. Этот подход отлично подходит для систем обработки транзакций и других приложений с большой нагрузкой на функциональность. Добавление элементов управления потоками позволило применять диаграммы потоков данных для моделирования систем реального времени.

Некоторые правила для рисования диаграмм потока данных:

  • Процессы взаимодействуют через хранилища данных, а не посредством прямых потоков от одного процесса к другому. Точно так же данные не могут передаваться напрямую из одного хранилища в другое, они должны пройти через процесс (кружок).
  • Не пытайтесь передать последовательность этапов процесса с помощью диаграммы потоков данных.
  • Называйте процессы как короткое действие: глагол + объект (например, «Создать инвентарный отчет»). Используйте названия, понятные клиентам и употребляемые в деловой или предметной области.
  • Присваивайте процессам уникальные номера согласно иерархии. На уровне 0 диаграммы, пронумеруйте каждый процесс целыми числами. Если вы создадите дочернюю диаграмму потоков данных для процесса 3, пронумеруйте процессы в ней как 3.1, 3.2 и т.д.
  • Не показывайте на одной диаграмме более 8-10 процессов, в противном случае ее будет трудно рисовать, изменять и понимать. Если у вас больше десяти процессов, создайте еще один уровень абстракции,сгруппировав связанные процессы в процесс более высокого уровня.
  • Кружки с только входящими или только исходящими потоками вызывают подозрение. Корректный процесс, изображаемый кружком на диаграмме потоков данных, как правило, отличается наличием и входящих, и исходящих потоков.

Пример Data Flow Diagram (DFD):
Диаграмма потоков данных

Data Modeling

Моделирование данных осуществляется с целью обеспечения разработчика информационной системы концептуальной схемой базы данных в форме одной или нескольких локальных моделей, которые относительно легко могут быть отображены СУБД.
Наиболее распространенным средством моделирования данных являются диаграммы сущность-связь — ERD (Entity Relationship Diagram). С их помощью определяются важные для предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с другом (связи).

На каждом этапе проектирования информационной модели будущей системы разрабатывается соответствующая модель данных:

  • Логическая модель (концептуальная) — СУБД-независимая модель, отображающая абстрактный взгляд на данные, представленные и поименованные так, как они могут выглядеть и называться в реальном мире, например: «Постоянный клиент», «Отдел» и т.д.;
  • Даталогическая модель — СУБД-ориентированная модель, представляющая реляционную модель базы данных в конкретной СУБД, включающей полный список отношений и их атрибутов с указанием первичного ключа;
  • Физическая модель — отображение системного каталога; описание всех типов файлов базы данных в зависимости от выбранной СУБД.

Процесс разработки модели данных выбранной предметной области с использованием Case-средства (например, All Fusion Data Modeler) сводится к последовательности действий, которая называется прямым проектированием (Forward Engineering):
1) Создание логической модели — описание всех выделенных в процессе обследования предметной области сущностей, их атрибутов и связей между ними;
2) Переход на даталогический уровень;
3) Осуществление генерации системного каталога СУБД или соответствующего SQL-скрипта.

Процесс может быть и обратным (Reverse Engineering) — создание модели данных на основе существующей схемы базы данных в определенной СУБД.

Decision Analysis

Анализ принятия решений — Подход к принятию решений, который изучает и моделирует возможные последствия различных решений. Такой тип анализа помогает в принятии оптимального решения в условиях неопределенности.

Цель
Для поддержки принятия решений при работе с составными, сложными или неопределенными ситуациями. Анализ решений позволяет бизнес-аналитику изучить и смоделировать последствия различных решений. Конечной целью данного инструмента является разработка обоснованного решения. Оно делается с помощью математического моделирования для оценки возможных результатов. Во многих случаях, анализ решения включает в себя сложные модели, созданные с использованием современных программных приложений.

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

Эффективный анализ решений требует, чтобы аналитик понимал:
— Ценности, цели и задачи, которые актуальны для решения проблемы;
— Характер решения, которое должно быть выполнено;
— Области неопределенности, которые влияют на решение;
— И последствия каждого из возможных решений.
Задачи в Области знаний Анализа предприятия описывают многое из того, что требуется для эффективного структурирования решения проблемы. Этот метод описывает конкретные инструменты, которые используются для анализа результатов, неопределенности и компромиссов. Анализ решений может включать в себя использование сложных моделей и специализированных программных приложений.

Элементы анализа решений
1. Результаты
Анализ решений обычно требует, чтобы бизнес-аналитик использовал некоторые формы математической модели для оценки возможных результатов.

Финансовый анализ
Финансовые модели оценивают рыночную стоимость активов организации, например, оценка нового решения для бизнеса или его приобретение.
Часто используемые методы финансовой оценки включают в себя:
— Дисконтированный денежный поток (DCF): будущая стоимость по конкретным данным
— Чистая приведенная стоимость (NPV): будущий вид затрат и выгод, преобразованный в сегодняшнюю стоимость
— Внутренняя норма доходности (IRR): проценты (или дисконт), при которой чистая приведенная стоимость равна нулю
— Средняя норма рентабельности (ARR): оценка доходности инвестиций
— Срок окупаемости (PP): количество времени, требующееся для окупания инвестиций
— Анализ затрат и выгод (CBA): количественная оценка затрат и выгод по предлагаемому решению

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

2. Неопределенность
Неопределенность становится актуальным для решения проблемы, когда невозможно узнать какой наступит результат. Это может быть из-за отсутствия информации, либо потому, что результат зависит от того, как другие реагируют. Общий метод борьбы с неопределенностью в решении проблем является расчет ожидаемой стоимости результатов. Расчет включает в себя оценку вероятности происхождения каждого события в процентах и их умножения на численное значение результата, связанного с этим процентом.
Дерево решений — это метод оценки предпочтительного результата, где может существовать несколько источников неопределенности.
Дерево решений

3. Компромиссы
Компромиссы становятся актуальными, когда решение проблемы включает в себя несколько, возможно, противоречивые задачи. Недостаточно просто найти максимальное значение одной переменной (например, финансовая выгода для организации), потому что более чем одна цель является актуальной. При принятии компромиссных решений, эффективные методы включают в себя:
— Исключение доминирующих альтернатив. Доминирующая альтернатива — это любой параметр, который явно уступает некоторым другим параметрам. Если параметр равен или хуже, чем некоторые другие параметры по рейтингу отношения к целям, то другой параметр может доминировать в нем. В некоторых случаях параметр также может доминировать, если он предлагает небольшие преимущества, но имеет существенные недостатки.
— Ранжирование целей, аналогичных по масштабам. Один из способов преобразования рейтинга аналогичного масштаба — это пропорциональный скоринг. Используя этот метод, лучшим результатам присваивается рейтинг 100, худшим — 0, а все остальные результаты получают рейтинг, основанный на том, где они находятся между двумя этими баллами. Оценка может быть назначена каждому результату как лучшая альтернатива, назначенная с помощью дерева решений, если результатам затем присваиваются веса, в зависимости от их относительной важности.

Особенности использования
1. Преимущества
— Анализ решений предоставляет эффективный метод, чтобы определить ожидаемое значение альтернативного сценария для организации.
— Использование последовательных методов финансового обоснования во всех бизнес-кейсах предоставляет лицам, принимающим решения, количественные показатели, чтобы принять инвестиционное решение по проекту.
— Анализ решений может заставить заинтересованные стороны честно оценить важность, которую они придают различным альтернативам.
2. Недостатки
— Анализ решения требует специальных знаний и навыков, в том числе математические знания, понимание вероятности и подобных концепций.
— Результаты анализа решений можно рассматривать как более определенные, чем они есть на самом деле, если лица принимающие решение, не понимают ограничения и предположения модели, которые стоят за ней.
— Лица, принимающие решения, могут быть не заинтересованы в пересмотре решений, даже когда больше информации доступно по областям неопределенности, которые могут изменить оптимальное решение.

Document Analysis

Анализ документов — Метод выявления требований к существующей системе путем изучения доступной информации, документов и определения ее релевантности.
Цель
Анализ документа — является средством для выявления требований, посредством изучения имеющейся документации о существующих и сопоставимых решениях и определения соответствующей информации.

Описание
Анализ документа может включать анализ бизнес-планов, маркетинговые исследования, договоров, заявок на предложения, инструкций по работе, служебных записок, существующих руководящих принципов, процедур, учебных пособий, литературы по конкурирующим продуктам, опубликованные сравнительные обзоры продукции, отчетов о проблемах, журналов предложений клиентов, спецификаций существующих систем. Выявление и принятие во внимание всех возможных источников требований приведет к повышению охвата требований, предполагая, что документация находится в актуальном состоянии. Анализ документа используется, если цель состоит в том, чтобы собрать информацию о существующих решениях, в том числе бизнес-правилах, сущностях и атрибутах, которые должны быть включены в новое решение или должны быть обновлены для текущего решения. Этот метод также применяется в ситуациях, когда эксперта по предметным вопросам по существующим решениям больше нет в организации или он не будет доступен в течение всего времени процесса выявления требований.

Элементы инструмента «Анализ документов»
1. Подготовка
Оцените, какие из существующих систем и бизнес-документации являются актуальными, доступными и необходимо для изучения.
2. Рассмотрение документов
— Изучите материал и определите соответствующие сведения бизнеса.
— Задокументируйте бизнес-информацию, а также вопросы для последующей деятельности с экспертами в предметной области.
3. Подведение итогов
— Рассмотрите и подтвердите с экспертами в предметной области выбранные детали.
— Организуйте информацию в формате требований.
— Получите ответы на дополнительные вопросы.

Особенности использования
1. Преимущества
— Не начинаем с чистого листа.
— Используем существующие материалы для обнаружения и/или подтверждения требований.
— Соответствует перекрестной проверки требований из других техник сбора информации, таких как интервью, работы-слежки, опросы или фокус-группы.
2. Недостатки
— Ограничено точкой зрения «как есть».
— Существующая документация может не быть современной или утвержденной.
— Данный процесс может быть трудоемким или даже утомительным процессом, чтобы найти соответствующую информацию.

Estimation

Цель метода проведения оценки
Методы оценки прогнозируют стоимость и усилия, которые вовлечены в проведение курса действий.

Описание
Методы оценки используются для углубления понимания возможного диапазона стоимости и усилий, связанных с любой инициативы. Оценка используется при невозможности определения точной стоимости. Оценка не может и не устраняет неопределенность; напротив, цель заключается в том, чтобы получить разумную оценку вероятной стоимости или усилий. Чем меньше информации, которая доступна для оценщика, тем шире будет диапазон неопределенности. Оценки должны быть пересмотрены по мере поступления новой информации. Многие методы оценки опираются на исторические записи показателей от организации, чтобы откалибровать их с фактическими показателями. Оценки (Estimates) должны включать оценку диапазона неопределенности, связанной с оценкой (estimate).

Элементы метода оценки
1. Аналогичная оценка
Используйте подобный проект в качестве основы для разработки оценок для текущего проекта. Он используется, когда мало что известно. Аналогичные оценки часто используются для разработки оценки «грубого порядка величины» (ROM), и также известен как оценка «сверху- вниз». Обычно это делается в начале проекта или фаз проекта и более детальные оценки следуют как становится больше известно.
2. Параметрическая оценка
Использование параметров, умноженных на количество часов. Чтобы параметрическая оценка была полезной, достаточно, чтобы история должна была быть доступна для использования в качестве основы для сравнения. При этом типе оценки, бизнес-аналитик сделал достаточно работы для того, чтобы определить какие параметры будут использоваться и сколько их там будет. Например, бизнес-аналитик определил, что будет разработано десять вариантов использования. Бизнес-аналитик также имеет историю, которая указывает для каждого варианта использования общее количество часов, которые будут потрачены, в этом случае будет 20 часов. Используя эту технику, бизнес-аналитик может умножить 10 на 20, чтобы получить итоговое значение, или 200 часов.
Ряд четко определенных методов параметрической оценки существует для разработки программного обеспечения, таких как COCOMO II, подсчет функциональных точек, точки вариантов использования и исторические баллы.
3. Оценка
С помощью этой техники, бизнес-аналитик собирает конечные результаты деятельности, задач и оценок от всех заинтересованных сторон и обобщает их, чтобы получить общие для всех активностей и задач. Потому что, как правило, легче оценить мелкие элементы, чем более крупные элементы, оценки снизу-вверх могут производить наиболее точные и обоснованные оценки.
4. Набегающая волна
Это метод привлечения уточнения оценок. Детали оценки для деятельности в текущей итерации или приращение и предоставление аналогичной оценки за весь объем работ. Как в конце итерационных подходов, оценки могут быть сделаны для следующей итерации и первоначальная оценка для всех активностей уточняется.
5. Трех-точечная оценка
Использует сценарии для:
— Самая оптимистичная оценка или самый лучший сценарий
— Самая пессимистичная оценка или самый худший сценарий
— Наиболее вероятная оценка
Обратите внимание, что наиболее вероятная оценка это не среднее между самым лучшим и наихудшим сценариями. Она требует глубокого знания ситуации. При правильных обстоятельствах, лучший сценарий может также быть наиболее вероятным.
6. Исторический Анализ
Использует историю в качестве основы для оценки. Метод похож на аналогичную оценку, но используется не только для оценки «сверху-вниз», но также и для детализации задач. Исторические оценки требуют предварительных записей проекта, которые поддерживаются формально в репозитории проекта или неформально в индивидуальной проектной документации.
7. Экспертное Заключение
Оценка опирается на опыт тех, кто выполнял работу в прошлом. Эти эксперты могут быть внутренними или внешними по отношению к проектной команде или организации.
8. Delphi Оценка
Эта техника использует комбинацию экспертной оценки и истории. Есть несколько вариантов этого процесса, но все они включают в себя индивидуальные оценки, обмен оценками с экспертами и имеют несколько раундов пока консенсус не будет достигнут. Используется среднее арифметическое трех оценок. Иногда, за среднее принимается взвешенное по оптимистическому, пессимистическому и умноженное на 4 наиболее вероятное, деленное на 6, чтобы получить среднее.

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

Focus Group

Цель
Фокус-группа — это средство выявления идей и взглядов о конкретном продукте, услуге или возможности в среде интерактивной группе. Участники делятся своими впечатлениями, предпочтениями и потребностями, под руководством модератора.

Описание
Фокус-группа состоит из предварительно отобранных лиц, целью которых является обсуждение и комментирование по теме. Это возможность для людей, чтобы поделиться своими точками зрения и обсудить их в группе. Это может привести участников к решению заново оценить свои точки зрения на фоне чужого опыта. Обученный модератор управляет административной предварительной работой, способствует проведению сессии и выдает отчет. Наблюдатели могут записывать или контролировать фокус-группы, но не участвовать. Так как эта техника выявления считается одной из форм качественного исследования, результаты сессии анализируются и регистрируются как темы и точки зрения, а не как численные результаты. Отчет также может содержать в себе избранные цитаты в поддержку темы. Традиционная фокус-группа собирается в одной комнате. Онлайн фокус-группа позволяет членам находиться удаленно, участвуя через сетевые соединения. Каждый подход имеет свои плюсы и минусы с точки зрения логистики и расходов.
Фокус-группа может быть использована в течение любого состояния жизненного цикла: исследовательский, в стадии разработки, готовый к запуску или стадии производства. Если темой группы является продукт стадии разработки, то идеи группы анализируются во взаимосвязи с заявленными требованиями. Это может привести к обновлению существующих требований или раскрытию новых требований. Если темой является законченный продукт, который готов к реализации, доклад группы может влиять на то, как позиционировать товар на рынке. Если темой является продукт стадии производства, то доклад группы могут дать указания по изменениям следующих версий требований. Фокус-группа может также служить средством оценки удовлетворенности клиентов с продуктом или услугой. Работа фокус-группы может быть похожа на то, что делается в сессии мозгового штурма. Одним из отличий является то, что фокус-группа, как правило, является более структурированной. Другое отличие состоит в том, что целью мозгового штурма является активный поиск расширенных, творческих и даже преувеличенных идей.

Элементы метода фокус-группы
1. Подготовка
Отбор Участников
Фокус-группы обычно имеют 6-12 участников. Отбор участников может быть необходим, чтобы пригласить дополнительных лиц или чтобы разрешить тем, кто не присутствовал на сессии из-за конфликтов, чрезвычайных обстоятельств или по другим причинам, обсудить тему. Если многие люди должны участвовать, то отбор участников может быть необходим, чтобы запустить более чем одну фокус-группу.
Тема фокус-группы должна будет влиять на отбор участников. Если темой является новый продукт, вполне вероятно, что должны быть включены в группу существующие пользователи (эксперты и новички). Существуют плюсы и минусы, которые необходимо учитывать при использовании однородного состава против неоднородного состава.
— Однородные — люди со схожими характеристиками. Внимание: различиями во взглядах не будут делиться. Возможное решение: проводить отдельные сеансы для различных однородных групп, чтобы собирать различные точки зрения.
— Неоднородные — люди с разнообразным опытом и/или взглядами на будущее. Предупреждение: люди могут подвергать себя само-цензуре, если им не комфортно с другими предпосылками или мнениями, что приводит к снижению собираемых данных.

Назначить Модератора и Регистратора
Модератор (ведущий) должен быть опытным в организации групп. Типичные навыки включают в себя следующие возможности:
— поощрение обсуждения
— задавать открытые вопросы (те, которые требуют или поощряют расширенный ответ)
— облегчать взаимодействие между членами группы
— вовлекать всех членов
— поддерживать фокусирование сессии (на том, чему она посвящена)
— оставаться нейтральным
— быть легко приспосабливающимся и гибким
Создать руководство по дискуссиям (обсуждениям)
Руководство по дискуссиям включает в себя цели/задачи сессии и пять-шесть открытых вопроса.
Запасное место и услуги
Выберите место для сессии. Организуйте техническую поддержку для расшифровки дискуссии на сессии и, если используется, аудио/видео-съемочное оборудование.

2. Запустите сессию фокус-группы
Модератор руководит обсуждением в группе, следует конкретным вопросам по заранее спланированному сценарию и обеспечивает достижению поставленных целей. Однако, групповая дискуссия должна обозначаться как свободно текущая и относительно неструктурированная для участников. Сеанс, как правило, длится от 1 до 2 часов. Регистратор записывает комментарии группы.
3. Создание отчета
Модератор анализирует и документирует соглашения и разногласия участников встречи, и синтезирует их в темы.

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

Functional Decomposition

Декомпозиция (Decomposition) — Техника, при которой проблема разбивается на компоненты для облегчения последующего анализа и понимания этих компонентов.

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

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

Элементы функциональной декомпозиции
В процессе выполнения функциональной декомпозиции выявляются высокоуровневые функции организации или решения (solution), а затем эти функции разбиваются на более мелкие части, такие как суб-процессы, виды деятельности, суб-функции и т.д.
При разложении организационных функций, модели функциональной декомпозиции начинаются с верхнеуровневых функций, которые соответствуют организационному юниту. Далее функции детализируются на суб-функции, представляющие собой процессы, которые осуществляются внутри этого юнита. Данный процесс направлен сверху вниз. Результатом функциональной декомпозиции является иерархическая диаграмма функций, диаграмма в виде дерева функций или списка пронумерованных функций, включающих в себя вложенные функции.
В управлении проектами существует аналогичный процесс, который носит название Структура декомпозиции работ (WBS, Work Breakdown Structure). Проект разбивается на фазы проекта, пакеты работ и конечные результаты.
Структура декомпозиции работ (WBS) является иерархической декомпозицией целей проекта на ориентированные на результат задачи, выполняемые проектной группой для достижения общих целей проекта. WBS образует основу всей деятельности по планированию проекта. WBS делит объем проектных работ на более мелкие, управляемые пакеты работ для сохранения лучшего контроля над операциями проекта.

Пример диаграммы функциональной декомпозиции
FDD (Functional Decomposition Diagram) — диаграмма функциональной декомпозиции
FDD (Functional Decomposition Diagrams) BABOK v 2.0

Glossary

Цель глоссария
Глоссарий определяет ключевые термины и данные, относящиеся к предметной области.

Описание глоссария
Глоссарий используется для официального выявления и определения всей терминологии, которая используется организацией или подразделением. Например, подразделение может различать клиента (client) и клиента (customer), где клиент (client) — это сторона, с которой бизнес имеет законную силу соглашения о предоставлении профессиональных услуг, в то время как клиент (customer) может иметь более непринужденные, на основе транзакций, отношения с бизнесом. В медицинской организации, такой как больница, термин пациент может использоваться, вместе с его уникальным определением, а не как клиент (client) или клиент (customer).

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

Interface Analysis

Цель анализа интерфейсов
Идентифицировать интерфейсы между решениями и/или компонентами решения, а также определить требования, которые будут описывать их взаимодействие.

Описание анализа интерфейсов
Интерфейс — это связь между двумя компонентами, канал передачи информации между двумя людьми, человеком и системой или между двумя системами. Большинство ПО (программ) требуют один или более интерфейсов. Различают следующие типы интерфейсов:
— Пользовательские интерфейсы, включая пользователей, непосредственно взаимодействующих с системой, а также отчеты, предоставленные пользователям;
— Интерфейсы для внешних приложений (входящие и исходящие);
— Интерфейсы для внешних устройств (входящие и исходящие).
Анализ интерфейса помогает уточнить границы взаимодействия приложений. Анализ интерфейса выделяет какое приложение обеспечивает определенную функциональность в соответствии с потребностями входных и выходных данных. Основой для успешной настройки взаимодействия необходимо четко и тщательно отделить требования для каждого приложения и затем описать требования к соединяющим интерфейсам.
Идентификация, какие интерфейсы необходимы для обслуживания приложения создает условия для выявления самых разнообразных требований. Раннее выявление интерфейсов раскрывает и подтверждает взаимодействие заинтересованных сторон, а также служит основой для последующего анализа детальных требований по каждому интерфейсу. Анализ интерфейса, безусловно, необходимо для программных решений или компонентов решений, но также может быть полезным для непрограммных решений, например, при определении требований к результатам, которые будут произведены третьими лицами.

Элементы анализа интерфейсов
1. Подготовка к этапу идентификации интерфеса
Обзор существующей документации на предмет наличия признаков требований к интерфейсам. Например, контекстная диаграмма может обеспечить эффективную визуализацию для входящих и исходящих интерфейсов для внешних сторон.
2. Сопровождение идентификации интерфейса
Для каждой заинтересованной стороны или системы, которая взаимодействует с системой, определить какие интерфейсы необходимы.
Для каждого интерфейса:
— Описать назначение интерфейса.
— Оценить, какой тип интерфейса может быть целесообразен в каждом конкретном случае: интерфейс пользователя, интерфейс система-система и/или интерфейсы к внешним аппаратным устройствам.
— Выявить высокоуровневые детали по интерфейсу, в зависимости от его типа.
Для интерфейса, в котором пользователь непосредственно взаимодействует с приложением, необходимо пользоваться техникой Создания прототипов.
Для интерфейса приложение-приложение или интерфейса к внешним аппаратным устройствам, кратко изложить содержание и связанные с ним события.
3. Описать интерфейсы
Требования к интерфейсу должны быть сфокусированы главным образом на описании входов и выходов интерфейса, должны быть описаны некоторые правила проверки, которые регулируют эти входы и выходы, а также требуется описать события, которые могут инициировать взаимодействия. Там может быть большое количество возможных типов взаимодействий, несмотря на это, необходимо описать все возможные взаимодействия без исключений.

Interview

Interview (BABOK v 2.0)

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

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

С целью выработки требований интервью бывает двух основных типов:
— Структурированное интервью: интервьюер имеет заранее определенный набор вопросов и ищет ответы.
— Неструктурированное интервью: интервьюер и интервьюируемый без каких-либо заранее определенных вопросов обсуждают в открытом формате заданную тему.

Успешное интервьюирование зависит от нескольких факторов, которые включают в себя следующие пункты (но не ограничиваются ими):
— Уровень понимания интервьюером прикладной области;
— Опыт проведения интервью интервьюера;
— Умение интервьюера документировать обсуждение (протоколирование интервью);
— Готовность интервьюируемого предоставлять релевантную информацию;
— Степень ясности в уме интервьюируемого о том, что бизнес хочет получить от целевой системы;
— Контакт интервьюера с интервьюируемым.

Элементы интервью
1. Подготовка к интервью
Определите фокус или цель интервью перед тем как продолжить подготовку.

Идентификация (выявление) потенциальных интервьюируемых
Бизнес-аналитик рассматривает следующие вопросы при определении, кого нужно опросить:
— Кто владеет наиболее достоверной и наиболее актуальной информацией по теме интервью?
— Какова их доля участия в текущей инициативе?
— Какова относительная важность информации, находящейся в распоряжении одного человека по отношению к информации другого человека? Эта информация полезна при анализе противоречивой информации, полученной из разных интервью?

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

  • Формат интервью — структурированное по сравнению с неструктурированным интервью. Для структурированного интервью характерны следующие типы вопросов:
    • Закрытые вопросы предполагают однозначный ответ (например, сообщение точной даты, названия, указания на количество чего-либо) или ответ «да» или «нет».Это гипотезы, уже готовые предположения, которые нужно лишь подтвердить или опровергнуть. Лучше гипотезы заменить открытыми вопросами, которые позволяют партнеру дать свою версию. Пример: Когда истекает срок сдачи проекта? Сколько человек у вас в группе? Ты хочешь отказаться от работы?
    • Открытые вопросы должны быть сформулированы так, чтобы партнеру хотелось на них отвечать. Эти вопросы предполагают развернутый ответ. Начинайте вопрос со слов: Что? Как? Почему? Каким образом? При каких условиях? Пример: На какие факты(условия, преимущества) мы должны обратить внимание? Что следует предпринять, чтобы изменить ситуацию? Какой результат был бы приемлемым для вас?
  • Организация вопросов: используйте вопросы в логическом порядке или в порядке приоритета/их значения. Например, вопросы могут задаваться от общих к частным, могут быть вопросы привязаны ко времени, от детальных вопросов к суммирующим вопросам и т.д. Фактическая организация базируется на таких факторах, как уровень знаний интервьюируемого и предмета интервью. Цель в том, чтобы следовать логическому порядку, а не прыгать от одного вопроса к другому в ходе интервью.
  • Расположение участников: интервью может проводиться при непосредственной встрече участников, по телефону, может организовываться в формате веб-конференции или с помощью других удаленных видов связи.
  • Время для интервью и площадка должны быть удобными для интервьюируемого.
  • Определите нужен ли вам секретарь (тот, кто будет составлять протокол интервью) и если да, то включите этого человека в процесс планирования. Определите, необходимо ли вести запись интервью. Если запись необходима, то обсудите цели записи и ее дальнейшее использование с интервьюируемым.

Установление контакта с потенциальными интервьюируемыми
Интервьюер устанавливает контакт с выбранными интервьюируемыми и объясняет им почему необходима их помощь. Цель установления контакта заключается в разъяснении целей интервью потенциальному интервьюируемому.

2. Проведение интервью

  • Открытие интервью. Интервьюер обговаривает цель интервью, обозначает некоторые начальные проблемы, поднятые интервьюируемым, а также объясняет, что замечания будут приняты и опубликованы для интервьируемого после интервью.
  • В ходе интервью:
    • Интервьюер сохраняет фокус на установленных целях и предварительно определенных вопросах.
    • Все проблемы, затронутые интервьюируемым, рассматриваются в ходе интервью или документируются для последующего отслеживания (follow-up) после интервью или разбираются в последующих интервью.
    • Интервьюером используется практика активного слушания.
  • Завершение интервью. Интервьюер спрашивает интервьюируемого о возможных упущенных деталях, областях, которые были пропущены на сессии. В завершении, интервьюер подытоживает сессию, напоминает интервьюируемому о предстоящем процессе обработки информации интервью и благодарит собеседника за потраченное его время.

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

Правила проведения интервью (bankiram.pro)

Данные правила помогут успешно провести интервью для сбора практически любой информации (описание бизнес-процессов, переговоры, получение экспертных оценок и опыта, исследование предметной области и т.п.).
1. Тщательная подготовка к интервью
Рекомендуется собрать и изучить всю возможную информацию о теме интервью и собеседнике. Заранее ознакомиться со всеми специфическими терминами, подготовить возможные дополнительные вопросы, примеры, комментарии и т.п.
2. Постарайтесь сделать так, чтобы вышестоящий руководитель вашего собеседника организовал интервью
Важно, чтобы руководитель того сотрудника, с кем вы собираетесь проводить интервью, объяснил ему, что это важно. В этом случае ваш собеседник с меньшей вероятностью станет игнорировать какие-то вопросы и предоставлять неполную информацию.
3. Слушайте, а не командуйте
В большинстве интервью вы задаете вопросы, на которые не отвечают просто да или нет. Вам необходимы исчерпывающие ответы, содержащие как можно больше информации. Единственный способ – слушать. Задавайте открытые вопросы.
4. Перефразируйте вопросы, говорите на понятном языке
Перед тем, как закончить интервью необходимо перефразировать и произнести вслух уже полученные ответы. Некоторые люди не думают и не выражают свои мысли в законченной (лаконичной) форме. Они «прыгают» с одного на другое и смешивают важные вещи с незначительными. Если вы перефразируете информацию, структурировав уже сказанное, собеседники могут ответить, верно ли их поняли. Такой прием также позволяет интервьюируемому добавить информацию или развить важные темы.
5. Не задавайте слишком много вопросов
Когда вы готовите план интервью, то старайтесь сузить круг вопросов, сфокусировав свое внимание на 3-5 наиболее важных.
6. Применяйте тактику «последнего вопроса»
Часто можно получить важный ответ, в котором нуждаешься, задавая его, уже собирая вещи и стоя в дверях.
Когда интервью закончено, все чувствуют себя расслаблено. Ваш собеседник не ощущает, что вы имеете какую-то власть над ним. Он с меньшей вероятностью займет защитную позицию и будет готов рассказать вам то, что вы хотите. Попробуйте этот прием, он работает.
Также вы можете задавать вопрос через 1-2 дня после проведения интервью. Этот вопрос необходимо обыграть таким образом, как будто вы забыли его задать в прошлый раз. Это также поможет вам получить ту информацию, которая требуется.
7. Всегда пишите благодарственные письма
Возвратившись с интервью, найдите время, чтобы написать письмо с благодарностью вашему собеседнику. Это будет вежливо и профессионально с вашей стороны. Может даже привести к более благоприятным результатам.
8. Обработка результатов интервью
После проведения интервью необходимо разобрать все сделанные конспекты и перевести всю информацию в электронный (компьютерный) формат для удобства дальнейшей работы с ней, поиска, сортировки и т.п. В случае возникновения вопросов, запишите их для проведения повторного интервью.

Item Tracking (Отслеживание пунктов)

Цель
Техника «Отслеживание пунктов» используется для того, чтобы захватить и назначить ответственных за проблемы и опасения заинтересованных сторон, которые оказывают влияние на решение.

Описание Item tracking
Отслеживание пунктов — это организационный подход, который используется бизнес-аналитиками для того, чтобы учитывать опасения заинтересованных сторон. Заинтересованные лица могут выявить такие типы пунктов, как действия, допущения, ограничения, дефекты, улучшения и проблемы. Когда беспокойство заинтересованных сторон впервые оглашается, то оно оценивается, чтобы определить насколько данная проблема жизнеспособна. Если проблема может превратиться в жизнь, то беспокойству присваивается определенный тип пункта таким образом, что оно может быть лучше отслеживаться и процесс отслеживания мог бы контролироваться, пока рассматриваемый элемент не будет закрыт. То есть пока проблема не будет исчерпана. Во время своего жизненного цикла пункту назначается одна или более заинтересованных сторон, которые несут ответственность за его исполнение. Отслеживание пункта позволяет следить за пунктом от начальной записи беспокойства (опасения) и степени воздействия до его закрытия. Записи при отслеживании пункта могут быть переданы заинтересованными сторонам для обеспечения прозрачности и видимости состояния и развития пунктов в записи.

Элементы отслеживания пунктов
1. Запись пункта
Каждый записанный пункт может содержать все или любые из следующих атрибутов для отслеживания пунктов. Эти пункты могут быть записаны с использованием различных программных приложений или может быть создан каталог вручную для обмена информацией между утвержденной группой заинтересованных сторон.

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

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

3. Метрики
Все заинтересованные стороны выиграют от более подробной информации, которая поддерживается по пункту и его прогрессу. Эти пункты могут быть рассмотрены в индивидуальном порядке в ходе разрешения или даже могут быть использованы для определения ключевых показателей эффективности с учетом процесса отслеживания пункта.
Просматривая выходную информацию, заинтересованные стороны могут определить насколько хорошо:

  • Пункты решаются при существующих ресурсах,
  • Инициатива продвигается,
  • Насколько процесс отслеживания пункта используется.

Особенности использования:
1. Сильные стороны

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

2. Ограничения

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

Lessons Learned Process

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

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

Элементы
Сессии могут включать рассмотрение следующих пунктов:
— Деятельность бизнес-анализа;
— Результаты бизнес-анализа;
— Конечный (финальный) продукт;
— Процессы бизнес-анализа;
— Используются или не используются автоматизация и технологии;
— Управленческие проблемы или вопросы;
— Как активы организационных процессов помогают или мешают бизнес-анализу и процессам работы с требованиями;
— Производительность по отношению к плану;
— Отклонения:
— Основные причины отклонений (первопричины);
— Отклонения были планируемыми или значительно аномальные;
— Какие корректирующие и/или профилактические действия были рекомендованы, утверждены или отклонены, а также приняты;
— Сессии извлеченных уроков могут проходить в виде формальных, неофициальных совещаний с заданными повестками дня и ролей участников встреч, в виде формальных или неформальных рабочих заседаний, неформальных собраний, любые из которых могут включать или не включать торжества.

Особенности использования
1. Преимущества

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

2. Недостатки

  • Все участники должны быть готовы избегать какого-либо желания присваивать в ходе сессии кому-либо вину, в противном случае честной дискуссии может не произойти.
  • Участники могут неохотно документировать и обсуждать проблемы.
  • Сессия может застопориться и возможности для улучшения могут быть упущены.

Metrics and Key Performance Indicators (KPIs)

Цель
Целью метрик и ключевых показателей эффективности является оценка эффективности решений, компонентов решения и других вопросов, которые представляют интерес для заинтересованных сторон.

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

Элементы
1. Indicators (Показатели)
Показатель (индикатор) определяет конкретное численное измерение для цели, воздействия, результат, вида деятельности, входных ресурсов (материалы, данные и т.п.). Каждый из этих факторов выгоды (пользы) имеет показатель для изменения его должным образом, но некоторым факторам может потребоваться несколько показателей. Хороший показатель удовлетворяет пяти характеристикам:

  • Clear (Понятность): показатель должен быть точным и однозначным;
  • Relevant (Соответствие или релевантность): должен соответствовать измеряемому фактору;
  • Economical (Экономичность): затраты на показатель должны быть умеренными;
  • Adequate (Адекватность): показатель должен обеспечивать достаточную основу для оценки производительности;
  • Quantifiable (Измеримость): показатель может быть независимо подтвержден.

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

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

3. Structure (Структура)
Создание системы мониторинга и оценки требует процедуры сбора данных, процедуры анализа данных, процедуры создания отчетности и сбора исходных данных. Процедура сбора данных охватывает блоки анализа, процедуры отбора образцов, выбор инструментов сбора данных для использования, частоту сбора данных и ответственность за сбор данных. Метод анализа определяет порядок проведения анализа и потребителей данных, которые могут иметь сильную заинтересованность в том, как проводится анализ. Процедура создания отчетности охватывает шаблоны отчетов, получателей отчетов, частоту создания отчетов и средства коммуникации (коммуникационные каналы). Исходная информация заключается в том, какие данные предоставляются непосредственно перед измерениями или в начале периода измерения. Исходные данные используются для того, чтобы узнать о последних успехах и оценки прогресса в отправной точке. Исходная информация должна быть собрана для каждого показателя, который будет анализироваться или использоваться в отчетности.
Существует три ключевых фактора в оценке качества показателей и их метрик — это надежность, достоверность (валидность) и своевременность. Надежность — это степень, в которой подход к сбору данных является стабильным и последовательным во времени и пространстве. Достоверность — это степень, в которой данные понятно (четко) и напрямую измеряют производительность, которую организация намерена измерить. Своевременность — это соответствие частоты и времени ожидания данных, в которых нуждается менеджмент.

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

Особенности использования
1. Преимущества
Создание системы мониторинга и оценки позволяет заинтересованным лицам понять, насколько решение соответствует целям и как эффективным была разработка решения (входы, выходы и деятельность решения).
Показатели, метрики и отчеты также способствует согласованности внутри организации, связываются цели с задачами, осуществляется поддержка решения, происходит лучше процесс управления базовыми задачами и ресурсами.
2. Недостатки
Сбор чрезмерного количества данных сверх того, что обеспечило бы получения требуемых результатов, приведет к напрасным затратам по сбору данных, их анализу и составлению отчетности. Это также будет отвлекать участников проекта от других обязанностей. На agile проектах это будет особенно актуально.
Бюрократическая программа по метрикам завершится с ошибкой из-за сбора слишком большого объема данных и не будут созданы полезные отчеты, которые позволят реализовать своевременные ответные действия. Лица, которым поручен сбор данных для метрик должны получить обратную связь для того, чтобы понять как их действия влияют на качество результатов проекта.
Когда показатели используются для оценки производительности, некоторые люди могут действовать таким образом, чтобы увеличить свою производительность на этих показателях, даже если это приводит к снижению производительности по другим видам деятельности.

Non-functional Requirements Analysis

Цель анализа нефункциональных требований
Целью нефункциональных требований является описание необходимых качеств системы, таких как юзабилити и эксплуатационные (технические) характеристики. Они дополняют документацию по функциональным требованиям, которые описывают поведение системы.

Описание
Документ с нефункциональными требованиями по качеству системы:

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

Строго говоря, термин «нефункциональные требования» применяется только при описании программного приложения. Тем не менее, различные категории нефукнциональных требований могут быть применимы и к другим компонентам решения, для которых требования могут быть разработаны. Например, требования к надежности для организационной единицы могут включать определенные часы обслуживания, а также требования к эффективности бизнес-процессов могут включать длительность цикла по решению запроса клиента и могут быть зафиксированы в соглашении об уровне обслуживания (SLA). В этих случаях, альтернативный термин требования «качество обслуживания» может быть предпочтительнее.

Элементы
Следующие элементы обычно включены в описание нефункциональных требований.
1. Категория
Нефункциональные требования, как правило, организованы по категориям. Классификация (категоризация) поддерживает выявление нефукнциональных требований путем представления в уме списка характеристик, которые следует учитывать при выполнении сбора требований. Схема, перечисленная здесь, основана на ISO 9126, но другие классификации/категории (такие как FURPS +) могут также быть использованы.
Reliability (Надежность): Доступно ли приложение ПО когда это необходимо? Требования к надежности включают в себя возможность приложения для того, чтобы исправлять ошибки, время безотказной работы или сбои в работе интерфейсов.
Performance Efficiency (Уровень производительности, эффективность исполнения): Обеспечивает ли приложение ПО приемлемый уровень производительности с учетом имеющихся ресурсов? Требования по уровню производительности включают в себя время, которое необходимо для выполнения активностей и уровни использования ресурсов.
Operability (Работоспособность): Данное приложение ПО понятно для пользователей? Требования по работоспособности включают в себя описание какие пользователи могут признать, что приложение будет на самом деле удовлетворять их потребности, а также описывается легкость обучения по работе с приложением и удобство применения (юзабилити) приложения.
Security (Безопасность): Препятствует ли приложение преднамеренному неправильному использованию? Требования безопасности включают в себя возможность обеспечения надлежащей конфиденциальности информации, целостности информации, которая хранится в заявке, возможность проверить какие и кем были осущеставлены действия в системе, а также возможность проверки подлинности пользователей (процесс аутентификации).
Compatibility (Совместимость): Может ли приложение эффективно работать с другими приложениями в той же среде (окружении)? Требования к совместимости включают в себя требования правильной замены другого приложения, способность сосуществования с другим приложениями, а также способность взаимодействия с другими приложениями.
Maintainability (Удобство сопровождения): Может ли приложение эффективно быть изменено после внедрения (реализации) для удовлетворения меняющихся потребностей? Требования по удобству сопровождаемости (обслуживания) включают в себя возможность изменения одного компонента без изменения остальных, возможность повторного использования компонентов, может ли приложение быть эффективно протестировано и могут ли проблемы быть правильно диагностированы, легкость внесения изменений и возможность осуществления изменений, не вызывая непредвиденные сбои.
Transferability (Переносимость): Может ли приложение быть установленно и в другой среде? Требования переносимости включают легкость установки и удаления приложения, виды разных сред, в которых приложение может работать, а также простота миграции приложения на новую среду.

2. Measurement
Определение нефункциональных требований должно включать в себя соответствующую метрику успеха для каждого требования, чтобы они могли быть адекватно протестированы. Некоторые нефункциональные требования могут показаться очень субъективными (например, «интуитивно понятный интерфейс»), но внимательное размышление, как правило, может обеспечить соответстующую метрику для измерения успеха.

3. Documentation
Нефункциональные требования, как правило, документируются в текстовом виде с помощью повествовательных высказываний, таких как:

  • 90% операторов должны иметь возможность использовать всю функциональность системы после того, как пройдут тренинг, который длится не более чем 6 часов.
  • Система должна обеспечивать 90% ответов в течении не более 2х секунд.

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

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

Observation

Наблюдение — К.Вигерс и Дж.Битти

Если вы попросите пользователей описать, как они выполняют свою работу, им наверняка будет тяжело быть точным — детали могут отсутствовать или быть некорректными. Часто это происходит из-за того, что задачи сложные и каждую мелочь не упомнишь. В других случаях причина в том, что пользователи довели выполнение задачи данных до такого автоматизма, что не состоянии сформулировать, что они в точности делают. Задача становится такой привычной, что они даже не думают о ней. Иногда можно узнать очень многое, наблюдая за тем, как пользователи в реальности выполняют свои задачи.
Наблюдения занимают много времени, поэтому они не годятся для каждого пользователя или задачи. Чтобы не нарушать ежедневную работу пользователей, ограничьте наблюдение двумя часами или меньше. Выбирайте для наблюдения важные или высокорискованные задания и множественные классы пользователей. При наблюдении в проектах гибкой разработки просите пользователей демонстрировать только задачи, относящиеся к будущей итерации.
Наблюдение рабочего процесса пользователя в рабочей среде позволяет бизнес-аналитику проверять информацию, полученную из других источников, определять новые темы для интервью, обнаруживать проблемы с текущей системой и определять возможности улучшения, чтобы новая система лучше поддерживала рабочий процесс. Бизнес-аналитик должен абстрагироваться и обобщать наблюдаемые операции пользователей, чтобы зафиксированные требования относились к классу пользователей в целом, а не к отдельным личностям. Опытный бизнес-аналитик часто может предложить идею по улучшению текущих бизнес-процессов.

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

Наблюдение может быть пассивным (молчаливым) или интерактивным. Пассивное наблюдение уместно, когда занятых пользователей нельзя отвлекать от работы. В процессе интерактивного наблюдения бизнес-аналитик может отвлекать пользователя и задавать вопросы. Это позволяет моментально понять, почему пользователь сделал именно такой выбор, или спросить, о чем он думал, предпринимая именно такое, а не иное действие. Документируйте свои наблюдения, чтобы их можно было потом проанализировать. Если позволяют корпоративные политики, может иметь смысл вести видеозапись, чтобы можно было освежить память в последующем.
Я разрабатывал приложение контактного центра для сотрудников по обслуживанию клиентов, которым нужно было просматривать печатный каталог и находить товары, которые заказывали клиенты. Команда бизнес-аналитиков встретилась с несколькими такими сотрудниками, чтобы выявить варианты использования нового приложения. Все как один сотрудники говорили о том, как сложно листать большое количество каталогов в поиске именно того товара, о котором говорил клиент. Каждый бизнес-аналитик сел рядом с одним из сотрудников и понаблюдал, как они принимают заказы по телефону. Мы увидели, что им сложно: сначала надо найти каталог по дате, а потом попытаться найти нужный товар. Наблюдения помогли нам понять, какие функции могут потребоваться в программном каталоге товаров.

Наблюдение за работой людей — Илья Корнипаев

Наблюдать за работой людей можно по-разному. Во-первых, можно попросить разрешения прийти на рабочее место человека, где он расскажет, как он работает. Во-вторых, можно найти место рядом с рабочим местом человека, наблюдение за работой которого вам интересно для получения требований. В-третьих, вы можете не присутствовать рядом, а наблюдать за работой человека удаленно, с помощью камер и/или средств, позволяющих видеть, что человек делает на компьютере (или использовать для этого журналы операций в системе).
Когда прибегают к таким способам получения требований? В основном, когда представители заинтересованной стороны (в частности будущие пользователи) не могут внятно рассказать о том, как они выполняют свою работу. В этом случае посещение рабочего места представителя заинтересованной стороны может существенно ускорить процесс получения требований. Аналитик своими глазами сможет увидеть, как и что делают люди.
Однако у этого метода есть также и свои недостатки. Во-первых, обычно это более трудозатратный метод по сравнению с интервью. Для получения одной и той же информации приходится тратить больше времени. Во-вторых, часть работы, возможно, аналитик не увидит, поскольку она может выполняться не каждый день. Это, например, периодическая отчетность или работа с нестандартными случаями или ошибками. В-третьих, человек может вести себя в присутствии аналитика на своем рабочем месте скованно и стесненно, бояться показаться некомпетентным в присутствии коллег, ошибаться и путаться. Может рассказывать не то, как он работает, а то, как это положено по инструкции, даже если это неудобно и он и его коллеги уже давно выработали для себя более эффективные способы выполнения своей работы.
Если работа аналитика связана с разработкой и развитием систем автоматизации деятельности предприятия, на котором он работает, т.е. он сотрудник той организации, для которой делается автоматизация, то ему имеет смысл найти рабочее место не в ИТ-отделе, а в бизнес-подразделении. Это способствует большему погружению аналитика в предметную область, хотя и имеет также свои негативные стороны. Если аналитик сидит вместе с представителями бизнеса, он очень много времени вынужден тратить на поддержку. И в то же время он становится менее доступен для команды разработки. Иногда возможен уход аналитика в бизнес-подразделение, после того, как он некоторое время поработал рядом с представителями бизнеса. Поэтому по возможности нужно стараться на некоторое время сажать аналитика в бизнес-подразделение, но потом возвращать его в ИТ. Если говорить об удаленном наблюдении, то это еще более трудозатратный способ, хотя не стоит его отметать полностью. Например, если текущая система позволяет понять по журналу операций, кто, когда и что делает, это может стать неплохим подспорьем аналитику. Он сможет по такому журналу, в частности, сделать вывод о том, какими функциями существующей системы пользуются часто, а какими не пользуются, и потом спросить, почему так происходит. Может быть эти функции совсем не нужны для работы, а возможно, они работают плохо, и людям приходится выполнять эту работу за пределами системы вручную. Также к недостаткам удаленного наблюдения за работой будущих пользователей системы можно отнести возможные неточности в интерпретации аналитиком увиденного, поскольку при таком методе наблюдения он не может спросить, что и зачем делает человек, а следовательно, может неправильно понять увиденное.
Таким образом, стоит применять этот способ получения требований, когда этом может помочь собрать требования лучше и полнее.

Organization Modeling

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

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

Элементы
1. Организационные цели и организационная структура
Functions (Функции): Функционально-ориентированные организации группируют вместе персонал на основе общих навыков или областей знаний. Они, как правило, утверждаются в целях содействия стандартизации работы или процессов внутри организации. Функциональные организации упрощают управление затратами и сокращают дублирования работы, но склонны к развитию проблем в коммуникации и в кросс-функциональной координации (их неофициально называют «силосы», т.е. появляется препятствие в обмене информацией).
Markets (Рынки): Термин «Ориентированный на рынок» охватывает ряд различных возможных способов организации предприятия, все действия которого базируются на обслуживании определенного сегмента клиентов, а не на общих навыках и знаниях работника. Структуры, ориентированные на рынок, позволяют организации лучше ориентироваться на потребности своих клиентов, но такие структуры склонны к развитию противоречий в том, как работа должна быть выполнена и происходит дублирование работы в разных подразделениях. Организация, ориентированная на рынок, может быть организована по группам клиентов, географическим районам, проектам или по процессам.
Matrix (Матрица): В этой модели существуют отдельные менеджеры для каждой функциональной области и для каждого продукта, сервиса (услуги) или группы клиентов. Сотрудники указывают в строке менеджера, который несет ответственность за выполнения того или иного вида работы и для выявления возможностей повышения эффективности в работе, а также менеджера по рынку (продукту/сервису/проекту и т.п.), который отвечает за управление продуктом, сервисом (услугой) и т.д. в разрезе функциональных областей.

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

3. Интерфейсы
Каждая организационная единица будет иметь интерфейсы с другими организационными единицами. Интерфейсы могут быть в форме рабочих пакетов, которые организационная единица получает или посылает другим единицам, коммуникации с людьми в других ролях и так далее. Рабочие пакет должны иметь определенные требования и стандарты качества, которые согласовываются заинтересованными сторонами, которых эти пакеты затрагивают. Эти требования, стандарты и ожидания могут быть определены формально или неформально, а также могут быть согласованы в каждом отдельном случае или допускают гибкость по отношению к первичному фиксированию (требований, стандартов и ожиданий).

4. Организационные Диаграммы
Принципиальной схемой, которая используется в организационном моделировании, является организационная диаграмма. Не существует официального стандартного набора для определения организационных диаграмм, хотя есть определенные стандартные соглашения, которым удовлетворяют большинство организационных диаграмм. Организационная диаграмма показывает:

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

Рисунок «Организационная диаграмма»
Организационная диаграмма (Org chart)

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

Prioritization

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

Для успешного определения приоритетов требуется понимание шести характеристик:

  • потребностей клиентов;
  • относительной важности требований для клиентов;
  • последовательности, в которой должны предоставляться функции;
  • требований, служащих основой для других требований, и других связей между требованиями;
  • потребности реализовывать какие-то группы требований целиком;
  • затраты на удовлетворение каждого требования.

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

  • Есть ли другой способ удовлетворить это требование клиентов?
  • Что случится, если это требование убрать или отложить?
  • Что произойдет с бизнес-целями проекта, если это требование не будет реализовано в ближайшие месяцы?
  • Почему пользователи будут недовольны, если реализация этого требования будет отложена до следующего выпуска?
  • Стоит ли из-за этой функции откладывать выпуск всех остальных функций с тем же приоритетом?

Метод 1 «Включать или не включать»
Группа заинтересованных лиц просматривает список требований и по каждому принимает простое бинарное решение — включать требование в следующий выпуск или нет? При этом надо держать в уме бизнес-цели проекта и пытаться свести список к абсолютному минимуму, необходимому в первом выпуске.
Далее, после начала реализации этого выпуска, можно вернуться к ранее исключенным требованиям и повторить весь процесс снова для следующего выпуска.

Метод 2 «Попарное сравнение и ранжирование»
Ранжирование списка требований предусматривает выполнение попарного сравнения между всеми требованиями, чтобы можно было определить, какой член в каждой паре приоритетнее.

Рисунок «Пример определения приоритетов атрибутов качества для терминала регистрации в аэропорту»
priority_requirements_method_2
Такое сравнение становится трудноуправляемым, если требований больше нескольких десятков. Оно может работать на уровне отдельных функций, но не для всех функциональных требований к системе в целом.

Метод 3 «Трехуровневая шкала приоритетов»
Этот способ оценки приоритетов предлагает учитывать два измерения: важность и срочность. Получаются четыре комбинации для определения шкалы приоритетов:

  • Требования с высоким приоритетом (high priority) — и важные (пользователям нужны функции), и срочные (они необходимы уже в следующем выпуске). Некоторые требования приходится включать в эту категорию согласно контрактным или юридическим обязательствам либо из-за непреодолимых бизнес-причин. Если реализацию требования можно отложить до более позднего выпуска без отрицательных последствий, тогда, в соответствии с этим определением, его нельзя считать высокоприоритетным;
  • Требования со средним приоритетом (medium priority) — важные (пользователям нужны функции), но не срочные (они могут ждать следующего выпуска);
  • Требования с низким приоритетом (low priority) — не важные (пользователи при необходимости могут обойтись без этой функций) и не срочные (пользователи могут ждать, возможно неограниченно долго);
  • Требования в четвертой клетке кажутся срочными части заинтересованных лиц, возможно по каким-то «политическим» причинам, но в действительности они не важны для достижения бизнес-целей. Не тратьте время на работу над ними, потому что они не добавят продукту ценности. Если они не важны, присвойте им низкий приоритет или вообще удалите.
  • Рисунок «Определение приоритетов требований по важности и срочности»
    priority_requirements_method_3_1

    Рисунок «Многопроходная приоритизация обеспечивает ориентацию на получение набора высокоприоритетных требований»
    priority_requirements_method_3_2
    При выполнении анализа приоритетов по трехуровневой шкале нужно помнить о зависимостях требований. У вас будут проблемы, если высокоприоритетное требование зависит от другого, у которого приоритет ниже и которое запланировано к реализации позже.

    Метод 4 «Схема классификации приоритетов MoSCoW»
    Четыре заглавных буквы в схеме определения приоритетов MoSCoW обозначают четыре возможных классификации приоритетов в наборе:

    • Must — требование должно быть удовлетворено, чтобы решение было успешным;
    • Should — требование важно и по возможности должно быть включено в решение, но оно не является условием успеха решения;
    • Could — это желательная функция, но ее можно отложить или удалить. Реализуйте ее, только если позволяет время и ресурсы;
    • Won’t — так обозначается требование, которое в этот раз реализовываться не будет, но может быть включено в будущий выпуск.

    Схема MoSCoW неоднозначна в том, что касается временных характеристик, особенно когда речь идет о рейтинге «Won’t» — это может означать «не в следующем выпуске» или «никогда». Такие различия должны определяться четко, чтобы у всех заинтересованных лиц было единое представление о последствиях данного конкретного рейтинга. Трехуровневая шкала более точна в отношении приоритетов (лучше пользоваться ею).

    Метод 5 «100 долларов»
    Дайте команде, занимающейся определением приоритетов сто воображаемых долларов. Члены команды должны потратить эти доллары на «покупку» конкретных требований из всего набора требований-кандидатов. На более приоритетные требования надо выделить больше денег. Если одно требование в три раза важнее для заинтересованного лица, чем другое, оно должно выделить, скажем, десять долларов на первое и три — на второе. Но каждый получает только 100 долларов — когда деньги кончаются, ничего больше нельзя реализовать, по крайней мере не в том выпуске, над которым сейчас идет работа. К процессу приоритизации привлекают различных участников для распределения своих долларов, после чего суммируются доллары по каждому требованию, чтобы определить, за какие требования было отдано больше всего долларов.

    Метод 6 «Определение приоритетов на основе ценности, стоимости и риска»
    Quality Function Deployment (QFD) — всесторонний метод определения относительной ценности для клиента предлагаемых функций продукта. В таблице показана модель, которая поможет вам оценить относительные приоритеты для набора вариантов требований. Эта методика была признана самой эффективной в сравнительной оценке 17 методик определения приоритетов требований:
    priority_requirements_method_6

    План использования модели:
    1. Перечислите в таблице все функции, варианты использования, направления вариантов использования, пользовательские истории или функциональные требования, для которых хотите определить относительные приоритеты.
    2. Попросите представителей клиентов оценить относительную выгоду, которую каждая функция дает клиенту или бизнесу, по шкале от 1 до 9: 1 балл означает, что никто не находит ее полезной, а 9 — что она крайне ценная.
    3. Оцените относительный ущерб, который понесет клиент или бизнес, если функция не будет реализована. Снова используйте шкалу от 1 до 9: 1 балл означает, что никто не расстроится, если она будет исключена; 9 показывает серьезный ущерб.
    4. В этой таблице подсчитаны итоговые значения для каждой функции как сумма баллов ее выгоды и ущерба (распределение весов описывается далее в этой главе). В ней суммируется ценность всех функций и вычисляется процент от общего значения для каждого набора функций, равного сумме ценностей каждой функции (столбец «Ценность, %»).
    5. Попросите разработчиков оценить относительную стоимость реализации каждой функции по шкале от 1 (легко и быстро) до 9 (трудоемко и дорого).
    6. Подобным же образом, разработчики оценивают относительную степень технического риска (не бизнес-риска), связанного с каждой функцией, по шкале от 1 до 9. Технический риск — это вероятность неудачной реализации функции с первого раза. 1 балл означает, что вы сможете запрограммировать ее даже во сне, 9 баллов означает серьезную озабоченность возможностью реализации, нехваткой сотрудников с необходимым опытом или использованием неиспытанных или незнакомых средств и технологий.
    7. После того как вы введете все результаты оценки в таблицу, по следующей формуле подсчитывается значение приоритета для каждой функции:
    Приоритет = Ценность % / (Затраты % + Риск %)
    8. Наконец, отсортируйте список функций по уменьшению подсчитанного приоритета — крайний правый столбец. Функции вверху списка характеризуются наиболее благоприятным сочетанием ценности, стоимости и риска, и поэтому — при равенстве остальных факторов — должны иметь наивысший приоритет.

    Process Analysis

    Анализ процессов

    Process Modeling

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

    Описание
    Процесс описывает как несколько человек или групп сотрудничают в течение определенного периода времени для того, чтобы выполнить работу. Процессы включают в себя ряд мероприятий, которые связаны потоком последовательности. Процесс повторяется и может иметь несколько путей для того, чтобы он считался завершенным.
    Процесс инициируется событием в области бизнеса, таких как продажа продукта клиенту, запрос о предоставлении информации старшим руководителем, или при возникновении сбоя в ходе выполнения транзакции. События могут быть деятельностью людей, результатом работы правил, которые вызывают действия, или возникать при прошествии определенного периода времени. Модель процесса может содержать ручную деятельность, деятельность может быть полностью автоматизирована, или может применяться комбинированный подход из автоматизации и ручной деятельности. Процесс завершается когда задачи или цели процесса выполнены/достигнуты.
    Модель процесса — это визуальное представление последовательного потока и логики управления набором взаимосвязанных мероприятий или действий. Процесс моделирования используется для графического представления текущего или будущего процесса внутри организации. Модель может быть использована на самом высоком уровне, чтобы получить общее представление о процессе или же на более низком уровне, в качестве основы для моделирования, для того, чтобы сделать процесс максимально эффективным.
    Figure «Flowchart»
    flowchart

    Figure «Activity Diagram»
    activity_diagram

    Элементы
    Существует множество различных нотаций, которые используются для описания моделей процессов. Наиболее часто используемыми являются блок-схемы (flowcharts) и UML диаграммы деятельности, хотя в последние годы широкое распространение получила нотация BPMN. Модели процессов обычно содержат некоторые или все из следующих основных элементов:
    1. Обозначения элементов
    Activities (Деятельность): Индивидуальные шаги или части работы, которая должна быть завершена в целях исполнения бизнес-процесса. Деятельность может проявляться в виде одной задачи или может быть в дальнейшем разложена на составные части подпроцесса (с его собственной деятельностью, потоками и другими элементами процесса).
    Decisions (Решения): Разветвления, где поток работы продолжается в двух или более потоках и, при необходимости, где отдельные потоки сливаются воедино. Решение может создать взаимоисключающие или параллельные потоки.
    Events (События): События происходят за рамками процесса и могут являться результатом принятых мер (действий), принятых сообщений, или по прошествии времени. События могут создавать, прерывать или завершать процессы.
    Flow (Поток): Укажите направление рабочего потока в виде последовательности действий «шаг за шагом». В общем, схемы рисуются сверху вниз или в направлении чтения, чтобы показать течение времени. Поток процесса может разделиться, чтобы показать деятельности, которые происходят одновременно и позднее сливаются.
    Roles (Роли): Роли представляют собой тип человека или группы. Определения ролей, как правило, совпадают с организационной моделью (organization model).
    Swimlanes and Pools (Дорожки и Пул/Объединение дорожек): Дорожки — это горизонтальные или вертикальные секции модели процессов, которые показывают какие виды деятельности выполняются определенной ролью. Когда поток работ пересекает границу дорожки, ответственность за работу переходит к другому лицу или группе лиц внутри организации.
    Объединение дорожек (Пул) представляет собой организационную границу. Пул может включать в себя несколько дорожек. Как правило, процесс будет включать в себя один пул для заказчика и второй пул для организации, хотя возможно, что процесс включает в себя любое количество пулов.
    Terminal Points (Конечные точки): Конечные точки представляют собой начало или конец выполнения процесса или потока процессов. Конечная точка, как правило, представляет собой некое событие, которое является видимым для организации или вне ее.

    2. Улучшение процесса
    Существует ряд фреймворков (framework, каркас или структура) и методологий, которые сосредоточены на методах совершенствования процессов, такие как Six Sigma, Lean, а также большое количество патентованных подходов BPM. Методы улучшения процесса включают в себя метод Value Stream Mapping (VSM, Систематизирование потока ценности), статистический анализ и контроль, моделирование процесса, бенчмаркинг, процессные фреймворки и другие. Общие изменения процессов с целью их улучшения включают в себя:
    — Анализ процесса для выявления или устранения тех видов деятельности, которые не добавляют ценности для заинтересованных сторон, где это возможно.
    — Сокращение времени, которое требуется для завершения процесса (за счет сокращения времени выполнения задачи или времени ожидания между задачами).
    — Улучшение интерфейсов или передачи обслуживания между ролями и организационными единицами, для устранения ошибок.
    — Сокращение или ликвидация узких мест и бэклогов (backlogs, невыполненных заказов).

    Особенности использования
    1. Преимущества
    — Большинство заинтересованных сторон знакомы с основными элементами и понятиями, которые лежат в основе модели бизнес-процессов.
    — Модели процессов являются эффективными в случае, когда необходимо показать, как обрабатывается большое количество сценариев и параллельных ветвей.
    — Модели процессов, вероятно, имеют ценность сами по себе, так как они будут использоваться заинтересованными сторонами бизнеса для подготовки и координации видов деятельности.
    2. Недостатки
    — Модели процессов могут стать чрезвычайно сложными и громоздкими, если их тщательно не структурировать. Сложные процессы могут содержать достаточное количество видов деятельности и ролей, что может привести к практически невозможныму для понимания виду ни для одного человека.
    — Проблемы в процессе не всегда можно идентифицировать, посмотрев на модель. Обычно необходимо привлекать непосредственно заинтересованные стороны, чтобы найти проблемы, с которыми они столкнулись при выполнении процесса.

    Prototyping

    Прототипирование — Тодд Заки Варфел

    Плюсы прототипирования

    • Прототипирование продуктивно;
    • Прототипирование дает возможность показать и рассказать;
    • Прототипирование снижает вероятность неправильного восприятия;
    • Прототипирование позволяет сэкономить время, усилия и деньги;
    • Прототипирование создает быструю цепь обратной связи, в результате снижаются риски.

    Процесс прототипирования в Messagefirst:
    Прототипирование — процесс, а не продукт, средство достижения цели. Несколько важных моментов:

    • Создание набросков — ключевая часть процесса прототипирования;
    • Используйте метод дизайнерской студии: составление набросков;
    • Показ и критическое обсуждение. Это помогает быстро и последовательно улучшать прототип;
    • Начинайте с количества, исследуя множество идей. Качество придет позже.

    Прототипы могут отличаться по качеству и функциональности, но наиболее типичное их использование включает:

    • создание среды для совместного общения;
    • переработку методом проектирования;
    • «продажу» идеи своему начальнику или коллегам в компании;
    • тестирование удобства использования;
    • оценку технической реализуемости и стоимости.

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

    • узнайте целевую аудиторию и ее намерения;
    • планируйте немногое, прототипируйте остальное;
    • формируйте ожидания;
    • делайте наброски;
    • это прототип, а не Мона Лиза;
    • если не можете что-то сделать, притворитесь, что можете;
    • прототипируйте только необходимое;
    • уменьшайте риски — прототипируйте на ранних этапах и часто.

    Инструмент Прототипирования — Частота использования:

    • Бумага — 77%
    • Visio — 59%
    • PowerPoint — 43%
    • Dreamweaver — 47%
    • Axure — 30%
    • OmniGraffle — 30%
    • Illustrator — 23%
    • Flash — 21%
    • Acrobat — 19%
    • Fireworks — 18%
    • InDesign — 12%
    • Photoshop — 10%
    • Другой редактор — 4%
    • Keynote — 3%
    • Flex — 2%
    • Blend — 0,2%
    • iRise — 0,1%
    • Другие (Excel,FileMaker) — 0,1%

    Факторы, влияющие на выбор инструментов прототипирования:
    1. Аудитория: кто будет смотреть прототип или работать с ним?
    2. Намерения: вспомните пять видов прототипов. Какие из них вам нужны?
    3. Степень знакомства и возможность изучения: знакомы ли вы с методом или инструментом, хотите ли их изучать?
    4. Стоимость: принимайте во внимание стоимость не только лицензии, но и простоя, пока вы будете изучать инструмент.
    5. Совместная работа: нужна ли она? Если да, то ваши возможности заметно ограничены.
    6. Распространение: как вы собираетесь сообщать результаты другим людям?
    7. Выбросить или использовать повторно: если нужен повторно используемый код, то выбор ограничен. Если нет, что гораздо более вероятно, то перед вами широкий выбор.

    Прототипирование программного обеспечения

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

    Шаги прототипирования программного обеспечения
    1. Определение начальных требований к программе (системе)
    2. Разработка первого варианта прототипа, в котором реализованы начальные требования к программе (системе). В основном первичный вариант содержит только пользовательский интерфейс;
    3. Демонстрация прототипа заказчику и конечным пользователям, сбор обратной связи о необходимых изменениях и дополнениях в программе (системе);
    4. Переработка функциональных требований, выпуск новых версий прототипа для того, чтобы учесть все замечания и предложения заказчика и пользователей. Шаги 3 и 4 могут повторяться.

    Типы прототипирования ПО
    Быстрое прототипирование (rapid prototyping) — технология быстрого «макетирования», быстрого создания опытных образцов или работающей модели системы для демонстрации заказчику или проверки возможности реализации текущей концепции системы. При использовании данного метода, предполагается, что созданный макет не станет частью готовой системы. Основное преимущество подхода — скорость представления макета в соответствии с требованиями. Стоимость изменений требований на этом этапе низкая. Быстрое прототипирование может осуществляться на платформе, которая отличается от промышленной системы.

    Бумажное прототипирование — широко распространённый метод проектирования программного обеспечения. Процесс, позволяющий разработчикам выяснить реальные ожидания и потребности пользователей, прежде всего в том, что касается пользовательского интерфейса. Это метод быстрого прототипирования, при котором создаются грубые наброски интерфейса, часто даже сделанные от руки, и используются в качестве прототипа (модели) будущего продукта.
    Бумажное прототипирование появилось в середине 1980-х и стало популярным в середине 1990-х, когда такие компании как IBM, Honeywell, Microsoft и другие стали использовать эту технику при разработке своих продуктов.
    Бумажное прототипирование экономит время и деньги, поскольку позволяет разработчикам тестировать интерфейс (как программных продуктов и веб-сайтов, так и потребительской электроники) до того, как писать код или начинать разработку. Метод также позволяет выполнять легкие и дешевые изменения предложенного дизайна.

    Эволюционное прототипирование (evolutionary prototyping) — последовательное создание макетов системы, которые будут с каждой итерацией приближаться к реальному продукту. На каждом шаге данного подхода мы команда проекта располагает работающей системой, которая может не обладать всей нужной функциональностью, но с каждой новой итерацией ее функциональность будет улучшаться. В данном случае, разработанный прототип может стать частью будущего продукта и разработанный код не будет «выброшен».
    Эволюционный подход к прототипированию может быть выбран, если все необходимые требования к моменту начала разработки неизвестны и будут определяться по мере создания программы. Разработчики могут сосредотачиваться на работе только над теми модулями системы, требования к которым уже определены.

    Risk Analysis and Management

    Анализ рисков на основе BABOK v 2.0

    Цель
    Идентификация и управление областями неопределенности, которые могут повлиять на инициативу, решение или организацию.

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

    Элементы
    1. Толерантность к риску
    Ключевым фактором в определении меры реагирования, которая будет выбрана человеком или организацией в отношении риска, является понимание их толерантности к риску. Не существует правильной или идеальной меры реагирования — общая стратегия должна быть адаптирована к каждой конкретной ситуации. Три основные категории толерантности к риску:
    — Неприятие риска. Люди или организации не толлерантные к риску будут стремиться снизить риски, особенно негативные риски, а также будут стремиться подойти как можно ближе к определенности, насколько это возможно. Сокращение потенциальных выгод в обмен на более определенные результаты рассматривается как приемлемый компромисс.
    — Нейтралитет. Нейтральный подход к риску означает, что вероятные выгоды, получаемые от реагирования на риск, должны быть равны или превышать затраты для того, чтобы оправдать действия.
    — Ищущий риски. Человек или организация ищущие риски будут готовы принимать относительно высокие риски для того, чтобы максимизировать потенциальную выгоду. Искатели рисков могут принять низкие шансы на успех, если выгоды от успеха выше.
    Лицо или организация, может иметь различные уровни толерантности к риску (допуски риска) в разное время. Размер и потенциальное воздействие риска также может повлиять на толерантность к риску.

    2. Оценка риска
    Оценка предполагает определение вероятности возникновения риска и воздействий риска, если он возникнет. Каждый из этих факторов оценивается по общей шкале (Высокая, Средняя и Низкая вероятность, ряд чисел от 1 до 5, и т.д.). Этот анализ позволяет сосредоточить внимание на наиболее важных рисках.

    3. Меры реагирования на риски
    Стратегии реагирования определяют как организация будет справляться с риском. Для отрицательных рисков стратегии включают в себя:
    — Acceptance (Принятие). Никаких усилий для борьбы с риском не производится. Организация принимает возможность того, что риск произойдет.
    — Transfer (Передача). Ответственность за работу с риском и возможными последствиями от риска переходят к третьей стороне.
    — Avoidance (Избегание). Организация принимает меры для того, чтобы риск не мог произойти.
    — Mitigation (Смягчение). Организация предпринимает шаги, чтобы уменьшить вероятность возникновения риска или возможных негативных последствий возникновения риска.
    Для положительных рисков также существует жизнеспособная стратегия. Другие стратегии включают в себя:
    — Share (Разделение). Работа с третьей стороной для увеличения возможного положительного результата в случае исполнения и согласие в разделении выгод.
    — Enhance (Усиление). Организация предпринимает шаги, чтобы увеличить вероятность риска и потенциальных выгод в случае реализации риска.
    — Exploit (Эксплуатирование). Организация работате для того, чтобы событие произошло.

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

    Анализ рисков и управление рисками на основе PMBOK Guide 5

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

    Организации воспринимают риск как воздействие неопределенности на цели проектов и цели организации. Для организаций и заинтересованных сторон приемлемыми являются различные степени риска в зависимости от их отношения к риску. На отношение к риску как организации, так и заинтересованных сторон могут оказывать влияние различные факторы, которые классифицируются по трем категориям:
    • Склонность к риску — степень неопределенности, которую хочет принять субъект в предвкушении вознаграждения.
    • Толерантность к риску — уровень, количество или объем риска, который организация или лицо могут выдержать.
    • Порог риска — измерение уровня неопределенности или уровня воздействия, к которому заинтересованная сторона может проявлять определенный интерес. Ниже этого порога риска организация примет риск. Выше этого порога риска организация не примет риск.

    Процессы управления рисками проекта:
    1. Планирование управления рисками — процесс, определяющий, каким образом осуществлять управление рисками проекта.
    2. Идентификация рисков — процесс определения перечня рисков, которые могут воздействовать на проект, и документирования их характеристик.
    3. Качественный анализ рисков — процесс расстановки приоритетов в отношении рисков для их дальнейшего анализа или действий, выполняемый путем оценки и сопоставления их воздействия и вероятности возникновения.
    4. Количественный анализ рисков — процесс численного анализа воздействия идентифицированных рисков на цели проекта в целом.
    5. Планирование реагирования на риски — процесс разработки вариантов и действий по расширению благоприятных возможностей и сокращению угроз целям проекта.
    6. Контроль рисков — процесс применения планов реагирования на риски, отслеживания идентифицированных рисков, мониторинга остаточных рисков, выявления новых рисков и оценки результативности процесса управления рисками на протяжении всего проекта.

    Общая схема процесса управления рисками проекта:
    General_schema_of_risk_management_pmbok_5

    Root Cause Analysis

    Цель
    Целью анализа основных причин является определение базового источника проблемы.

    Описание
    Анализ основных причин — это структурированное изучение аспектов ситуации для установления причин и последствий существующей проблемы. Важнейшим элементом анализа первопричин является то, что существующие бизнес-мышление и процессы подвергаются сомнению. То есть, имеют ли они смысл или обеспечивают необходимую ценность для бизнеса в свете существующих реалий.

    Элементы
    Два часто используемых метода анализа основных причин — это диаграмма «Рыбьей кости» и Пять «Почему?»:
    1. Диаграмма Исикавы — так называемая диаграмма «рыбьей кости» (Fishbone Diagram)
    Диаграмма «рыбьей кости» (также известная как диаграмма Исикавы или причинно-следственная диаграмма) используется для идентификации и систематизации возможных причин проблемы. Этот инструмент помогает сосредоточиться на причинах проблемы по отношению к решению и организует генерацию идей для дальнейшего анализа. Схема служит своеобразной картой, изображающей возможные причинно-следственные отношения. Этапы разработки причинно-следственной диаграммы включают в себя:

    • Фиксируем вопрос или проблему, которая обсуждается, в рамке (рамкой может служить прямоугольник) в верхней части диаграммы;
    • Проведите линию от рамки по бумаге или на доске (формирование позвоночника рыбьего скелета);
    • Нарисуйте диагональные линии от позвоночника, которые будут представлять категории потенциальных причин проблемы. Категории могут включать в себя людей, процессы, инструменты, а также политики организации;
    • Рисуйте меньше линий, которые представляют более глубокие причины;
    • Мозговой штурм категории и возможных причин проблемы и их фиксирование под соответствующей категорией;
    • Анализ результатов. Помните, что группа определила только потенциальные причины проблемы. Дальнейший анализ необходим для того, чтобы подтвердить фактическую причину на основе данных;
    • Мозговой штурм возможных решений после того, как фактическая причина была идентифицирована.

    Рисунок «Диаграмма Исикавы»
    fishbone_diagram

    2. Пять «Почему?»
    Пять «Почему?» — это процесс задавания вопросов для того, чтобы исследовать природу и причину проблемы. Подход пять «Почему?» заключается в том, что необходимо многократно задавать вопрос в попытке добраться до первопричины проблемы. Это один из самых простых инструментов, который можно использовать, в случае когда проблема имеет компонент взаимодействия людей. Чтобы использовать эту технику, необходимо:

    • Написать проблему на флип-чарте, белой доске;
    • Задать вопрос: «Как вы думаете, почему это происходит?», а дальше зафиксировать озвученную идею ниже проблемы;
    • Задать вопрос: «Почему?» снова и зафиксировать следующую идею, ниже первой идеи «Почему?».

    Продолжайте выполнять 3 шаг до тех пор, пока вы убеждены, что реальная причина не была выявлена. Процесс может вызвать больше или меньше вопросов — методика называется 5 «Почему?», потому что часто необходимо многократно задавать вопрос в попытке добраться до первопричины, а не потому, что вопрос должен быть задан ровно пять раз.
    Пять «Почему?» может использоваться самостоятельно или как часть диаграммы «Рыбьей кости». После того, как все идеи фиксируются на диаграмме, используйте пять «Почему?» для детализации причин.

    Особенности использования:
    1. Преимущества
    Анализ основных причин обеспечивает структурированный метод по выявлению первоначальных причин идентифицированных проблем, обеспечивая тем самым полное понимание рассматриваемой проблемы.
    2. Недостатки
    Анализ основных причин работает лучше всего, когда кто-то, кто имеет официальную подготовку или большой опыт, оказывает содействие команде специалистов. Главной задачей ведущего является способность оставаться объективным, обеспечивая эффективный процесс анализа первопричин.

    Scope Modeling

    Цель
    Модели границ (scope models) используются для описания границ анализа и границ решения.

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

    Элементы
    1. Контекстная диаграмма
    Контекстная диаграмма — это высокоуровневая диаграмма потоков данных. Она представляет единый процесс передачи данных для того, чтобы описать границы и показать внешние сущности, а также хранилища данных, которые предоставляют необходимые данные и получают данные из системы. Контекстные диаграммы до сих пор используются на многих проектах, на которых не используются иных диаграмм потоков данных.
    Рисунок «Контекстная диаграмма (Gane-Sarson Notation — нотация Гейна-Сарсона)»
    Data Flow Diagram (Gane-Sarson Notation)

    Рисунок «Контекстная диаграмма (Yourdon Notation — нотация Йордона)»
    Data Flow Diagram (Yourdon Notation)

    2. События
    Внешние события происходят во внешней сущности. Они являются внешними границами изучаемой системы (клиент делает запрос, партнер отправляет сообщение). Временные события управляются временем (например, ежемесячные или годовые отчеты). Время определяется бизнес-правилами, которые связаны со временем (например, производить этот отчет в конце каждого дня или подготовить налоговую декларацию по окончании каждого налогового периода).
    Когда события были определены, следующий вопрос, который необходимо задать — это «Какие процессы необходимо обеспечить, чтобы предоставить полный отклик (ответ) на это событие?» Ответы на этот вопрос идентифицируют процессы системы. Эти процессы могут быть задокументированы и в дальнейшем проанализированы, используя соответствующую методику моделирования процессов.

    3. Особенности
    Функция — это служба, которую обеспечивает решение для выполнения одной или нескольких потребностей заинтересованных сторон. Функции высокого уровня абстракции решения, которые должны быть впоследствии полностью описаны в функциональных и дополнительных требованиях. Они позволяют проставлять приоритет и управлять границами (scope), а также согласовывать обзор решения заинтересованными лицами.

    4. Диаграмма вариантов использования (Use Case)
    Диаграмма вариантов использования (use case) наглядно представляет варианты использования, которые поддерживаются системой, актерами, которые инициируют варианты использования, а также отношения между вариантами использования.

    5. Бизнес-процесс
    Модели высокоуровневых бизнес-процессов также могут быть использованы в качестве модели границ (scope model).

    Особенности использования
    1. Преимущества
    С помощью модели границ легче определить, что входит в рамки решения, а что выходит за рамки решения, даже когда идентифицируются новые требования или необходимы изменения в требованиях.
    2. Недостатки
    Модель границ, как правило, оставляют много детальных границ, которые нуждаются в иследовании и детализировании.

    Sequence Diagram

    Диаграмма последовательности — диаграмма, на которой показано взаимодействие объектов (обмен между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления. Используется в языке UML.

    Основными элементами диаграммы последовательности являются:

    • обозначения объектов (прямоугольники с названиями объектов);
    • вертикальные «линии жизни» (lifeline), отображающие течение времени;
    • прямоугольники, отражающие деятельность объекта или исполнение им определенной функции (прямоугольники на пунктирной «линии жизни»);
    • стрелки, показывающие обмен сигналами или сообщениями между объектами.

    Элементы диаграммы:
    Элементы диаграммы последовательности

    Пример диаграммы последовательности:
    Пример диаграммы последовательности

    Questionnaire

    Опросные листы — К.Вигерс и Дж.Битти

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

    • варианты ответов должны охватывать весь диапазон возможных ответов;
    • варианты ответов должны быть взаимоисключающими (никаких перекрытий в числовых диапазонах) и исчерпывающими (приведите все возможные варианты и/или добавьте свободное место, куда можно вписать вариант, о котором вы не догадались);
    • вопрос не должен подразумевать получение «правильного» ответа;
    • шкалы величин нужно использовать единообразно во всем опросном листе;
    • используйте закрытые вопросы с двумя или большим числом вариантов, если опросный лист предназначен для статистического анализа. Открытые вопросы позволяют пользователям отвечать так, как им хочется, что затрудняет поиск общих моментов в результатах;
    • стоит проконсультироваться со специалистом по составлению материалов и проведению опросов, чтобы удостовериться, что вы задаете правильные вопросы «правильным» людям;
    • всегда тестируйте опросный лист до его распространения. Очень обидно слишком поздно обнаружить, что вопрос был задан неоднозначно или какой-то вопрос вообще забыли добавить;
    • не задавайте слишком много вопросов, потому что люди просто не станут отвечать.

    Опросы — Илья Корнипаев

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

    SWOT Analysis

    SWOT-анализ — это базовая аналитическая модель поиска стратегии, которая основывается на общей оценке сильных и слабых сторон компании, а также возможностей и угроз внешней среды. SWOT-анализ весьма абстрактен, поскольку его выводы носят чисто описательный характер: они не предполагают никаких рекомендаций и не расставляют приоритеты. Но этого и не требуется. Его задача — просто представить нам структурированное описание ситуации, в отношении которой нужно принять решение.

    АНАЛИЗ ВНЕШНЕЙ СРЕДЫ (ВОЗМОЖНОСТЕЙ И УГРОЗ). Бизнес-единица должна постоянно отслеживать основные факторы макросреды (демографические, экономические, природные, технологические, политические, правовые, социальные, культурные), а также значимые элементы микросреды (покупатели, конкуренты, поставщики, дистрибьютеры, дилеры), которые влияют на получение прибыли. Обнаружить новые тенденции макро- и микросреды и происходящие в них изменения позволяет создание маркетинговой информационной системы. Для каждой новой тенденции руководство компании должно выявить соответствующие возможности и угрозы.
    Маркетинговая возможность — область покупательских потребностей и интересов, удовлетворение которых с высокой долей вероятности принесет компании прибыль.
    Угрозы внешней среды — это отрицательное влияние неких тенденций или неблагоприятное развитие событий, которые в отсутствие защитных маркетинговых мероприятий приводят к сокращению объемов продаж или прибыли компании.

    АНАЛИЗ ВНУТРЕННЕЙ СРЕДЫ (СИЛЬНЫХ И СЛАБЫХ СТОРОН). Оценка внутренних сильных и слабых сторон выполняется по следующим направлениям деятельности компании — организация, производство, снабжение и логистика, инновации, финансы, маркетинг, персонал, безопасность, материально-техническое обеспечение.

    На основе возможностей и угроз, сильной и слабой сторон составляются 4 типа стратегии:
    1. Стратегия сопоставления сильных сторон и возможностей;
    2. Стратегия сопоставления сильных сторон и угроз;
    3. Стратегия сопоставления слабых сторон и возможностей;
    4. Стратегия сопоставления слабых сторон и угроз.

    Пример SWOT-анализа:
    Пример swot-анализа

    User Cases

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

    Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования):

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

    Уровень детализации
    Алистер Коберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:

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

    Элементы сценария использования
    Имя сценария
    Имя сценария стоит писать в формате глагол-существительное (например, Заимствовать Книги, Забрать Наличные деньги). Оно должно описывать достижимую цель (например, Регистрация Пользователя лучше, чем Регистрирующийся Пользователь), и должно объяснять смысл сценария использования. Неплохо использовать имя сценария, цель актера, гарантируя таким образом внимание к потребностям пользователя. Два-три слова — оптимум. Если слов в названии больше, то обычно есть более короткое и более информативное имя.
    Цель
    Без цели сценарий бесполезен. Нет никакой необходимости в сценарии использования, когда нет никакой потребности ни в каком актере, чтобы достигнуть цели. Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
    Актеры (Акторы)
    Актер это кто-то или что-то вне системы и влияющий на систему или находящийся под ее влиянием. Актер может быть человеком, устройством, другой системой или подсистемой, или временем. Человек в реальном мире может быть представлен несколькими актерами, если у них есть несколько различных ролей и целей по отношению к системе. Они взаимодействуют с системой и производят над ней некоторые действия.
    Заинтересованные лица (Стейкхолдеры)
    Заинтересованное лицо — человек или отдел, которых затрагивает сценарий использования. Обычно это работники организации или отдела, для которого создается сценарий. К заинтересованному лицу можно обратиться с просьбой предоставить информацию, отзыв, или разрешение для сценария использования.
    Предварительные условия
    Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте так же, что предварительные условия это не «активаторы» (см. ниже). Так как верные предварительные условия НЕ инициируют выполнение сценария.
    Активаторы
    Активатор это событие инициирующее выполнение сценария. Это событие может быть внешним, временным или внутренним. Если активатор не реальное событие (например, клиент нажимает кнопку), но ряд сложных условий, тогда стоит описать процесс активации. Этот процесс должен периодически или постоянно проверять условия активации и инициировать сценарий.

    Есть несколько вариантов как описать ситуацию, когда активация происходит, но предварительные условия не удовлетворены.

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

    Порядок Событий
    Как минимум, каждый сценарий использования должен описать типичный ход событий, часто представленный как ряд пронумерованных шагов.
    Альтернативные пути и дополнения
    Сценарии использования могут содержать вторичные пути или альтернативные сценарии, которые являются вариантами основного. Каждое проверенное правило может привести к альтернативному пути и когда правил много количество альтернативных путей возрастает приводя к очень сложным документам. Иногда лучше использовать условную логику или диаграммы, чтобы описать сценарии со многими правилами и условиями.
    Бизнес-правила
    Бизнес-правила — cпособ задания логики системы для определения результата в зависимости от конкретного запроса к системе (например, входных данных). Правила описывают логику типа: «Если на входе такие данные, то система реагирует вот так». Они могут касаться одного сценария использования, применяться ко всем сценариям или ко всему бизнесу. Сценарии использования должны ясно ссылаться на бизнес-правила, которые для них применимы и используются.

    Пример Use Cases:
    Пример use cases

    User Stories

    Пользовательские истории (User Stories) — это короткие предложения (одно или несколько предложений), которые описывают требования клиентов на ежедневном или деловом языке пользователя. Пользовательские истории используются в Гибких методологиях разработки ПО. Пользовательские истории фокусируются на нуждах заказчика и не содержат в себе деталей реализации. Пользовательские истории — это быстрый способ документирования требований клиента, без необходимости разработки обширных формализованных документов, требующих ресурсов на их поддержание.
    Шаблон пользовательских историй:

    Как <роль>, я хочу <цель>, чтобы <деловая выгода>.
    или
    Как <пользователь>, я могу <действие>, для того, чтобы <цель>.

    Примеры пользовательских историй:
    1. Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать или продать их другим пользователям.
    2. Как рекламодатель я могу помещать свою рекламу в системе, ориентированную на пользователей.
    3. Как администратор я могу управлять фотографиями пользователей, так чтобы контент сайта был легальным.
    4. Во время обсуждения первой истории, заказчик и команда приходят к тому, что пользователи системы должны быть авторизированны системой перед выполнением каких-либо действий с фотографиями. Это приводит к появлению новой пользовательской роли «гостя» – группе людей, которые неавторизированны системой или вообще пока не имеют пользовательской учетной записи.
    5. Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
    6. Как гость я могу войти в систему под ранее созданной учетной записью, для последующей работы.

    Пользовательские истории можно выстраивать в иерархии (эпопеи). Эпопеи (epic) — это пользовательские истории, описывающие функциональность на высшем уровне. В дальнейшем, эпопеи разбиваются на более мелкие пользовательские истории и/или эпопеи.
    Пример «Разложение эпопеи на несколько пользовательских историй»
    example_epic_to_user_stories

    Пользовательские истории представляют работу, которую команда должна произвести над продуктом, чтобы выполнить требования заказчика. Объем работ пользовательской истории должен быть расчитан на 2-3 дня, для эпопеи объем работ не имеет значения, т.к. она потом будет детализироваться на более мелкие пользовательские истории.
    Когда начальный набор историй готов, все истории обговорены и детализированы до нужной степени, команда разработчиков переходит их реализации, выпуская программный продукт, в соответствии с приоритетами заказчиков и желаниями пользователей.
    Более подробную информацию см. Проекты гибкой разработки (Agile)>>>

    Vendor Assessment

    Цель
    Проведение оценки способности потенциального поставщика выполнить обязательства в отношении товара или услуги.

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

    Элементы
    1. Знания и опыт
    Общая причина для использования сторонних поставщиков заключается в том, что они могут предоставить знания и опыт, который отсутствует внутри вашей организации. В таких случаях, бизнес-аналитик должен рассмотреть вопрос о том, какую экспертизу необходимо передать и способность поставщика выполнить эту передачу. Желательно, чтобы целевые поставщики обладали определенным опытом в сфере необходимых методологий и технологий для того, чтобы этот опыт перенимался людьми внутри предприятия.

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

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

    4. Сроки и условия
    Услуги, которые оказывает поставщик, будут временными или постоянными? Бизнес-аналитику следует выяснить, содержат ли в себе лицензионные условия и технологическая инфраструктура поставщика потенциальные проблемы, которые могут возникнуть в случае, если организация впоследствии решит перейти к другому поставщику. Здесть также можно исходить из соображений, которые касаются использования поставщиком и его ответственность за сохранение целостности конфиденциальных данных организации. Дополнительно необходимо рассмотреть условия индивидуальной настройки продукта (кастомизация продукта).

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

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

    Особенности использования:
    1. Преимущества
    Эффективная оценка поставщиков снижает риск для организации развития отношений с неподходящим поставщиком и, вероятно, приведет в долгосрочной перспективе к удовлетворению в связи с принятым решением.
    2. Недостатки
    Данный процесс может быть весьма трудоемким, т.к. требует сбора достаточного количества информации о различных поставщиках. Некоторая информация может быть недоступна. Поставщиков новых и инновационных продуктов можно недооценить, потому что они не имеют существенной истории на рынке.

    Requirements Workshops

    Семинары — Илья Корнипаев (Требования для программного обеспечения)

    Это методика сбора требований. Суть состоит в том, чтобы собрать всех представителей заинтересованных сторон в одном месте на целый день или даже на два дня и полностью посвятить это время разработке и согласованию требований.
    Основной смысл таких семинаров — это сбор требований в необходимом объеме за минимальный срок.
    Подготовка к семинару:
    1. Выявление всех заинтересованных сторон и определение представителей от каждой из этих сторон. Каждого из этих людей нужно убедить в необходимости посетить семинар, ставя во главу угла эффективность этого мероприятия и те выгоды, которые получит он сам и/или его отдел/организация от успеха мероприятия.
    2. Выбор правильного времени и места проведения мероприятия. Все участники должны иметь возможность провести это время (день или два) за пределами рабочего места, не отвечать на звонки, электронную почту. Поэтому некоторая удаленность пойдет на пользу. Также важно продумать то, как люди попадут туда, где будет проводиться семинар. Задержка или, что еще хуже, неявка любого из участников может расстроить все планы.
    3. Сбор и распространение среди участников семинара подготовительных материалов. Подготовительные материалы могут включать как документы, относящиеся непосредственно к проекту, так и те, которые могут настроиться на правильный лад.
    4. Выбор ведущего (facilitator). Задачей ведущего является вести семинар так, чтобы участники не отвлекались, а работали в команде для достижения цели — собрать и утвердить в короткий срок требования. Если не удается найти внешнего независимого ведущего и приходится брать кого-то из проектной команды, то ему запрещается участвовать в обсуждении и вносить свои идеи на рассмотрение. Его работа — вести семинар и следить за регламентом и соблюдением правил семинара его участниками.

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

    К.Вигерс и Дж.Битти (Разработка требований к ПО)

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

    Приемы проведения эффективных семинаров выявления требований:
    1. Определите и отслеживайте выполнение основных правил. Участники должны договориться об основных правилах проведения семинаров, своевременно начинать и заканчивать семинар, не опаздывать после перерывов, отключить звук у всех электронных приборов, не проводить несколько обсуждений одновременно, следить, чтобы каждый принимал участие в работе и комментировать и критиковать решение, а не личность. После определения правил следите, чтобы участники придерживались их.
    2. Обеспечьте наличие всех ролей в команде. Организатор должен обеспечить выполнение участниками семинара следующих задач: ведение протокола, отслеживание времени, управление базовыми правилами, а также чтобы каждый был услышан. В частности, секретарь может фиксировать на бумаге все происходящее, а кто-то другой должен следить за часами.
    3. Планируйте повестку дня. У каждого семинара должен быть четкий план. Заранее составьте план и повестку дня семинара и доведите их до участников, чтобы они знали, какие задачи будут обсуждаться и что ожидать и к чему готовиться.
    4. Придерживайтесь границ проекта. Чтобы удостовериться, что предлагаемые пользовательские требования не выходят за текущие границы проекта, используйте документ о концепции и границах проекта. Следите, чтоб на каждой встрече уровень обобщения соответствовал выбранным целям. Периодически участники могут углубляться в обсуждения несущественных деталей. На это уходит масса времени, которое на начальном этапе работы следует потратить на прояснение пользовательских требований — время деталей наступит позже. Задача организатора — по мере необходимости возвращать участников к теме обсуждения.
    5. Фиксируйте темы для дальнейшего обсуждения. На семинаре всплывает масса случайных, но важных сведений: атрибуты качества, бизнес-правила, идеи по разработке пользовательского интерфейса, ограничения и т.п. Запишите их на плакатах — простейшим способом, — так вы не потеряете их и продемонстрируете уважение участнику, высказавшему их. Не отвлекайтесь на обсуждение деталей, не относящихся к теме дискуссии, если только они не окажутся критически важными, например бизнес-правилом, которое ограничивает варианты использования. После семинара опишите, что случилось с высказанными идеями.
    6. Ограничивайте некоторые дискуссии по времени. Подумайте о выделении фиксированного времени на обсуждение каждой темы. Возможно, некоторые дискуссии придется завершить позднее, но жесткие временные рамки помогают не тратить времени больше, чем запланировано, на первую тему обсуждения, в результате чего может не хватить времени для обсуждения остальных тем. Перед завершением обсуждения темы резюмируйте ее состояние и последующие шаги.
    7. Не увеличивайте размер команды и тщательно отбирайте участников. Небольшие группы работают намного быстрее. Семинары, число активных участников которых превышает пять или шесть человек, могут забуксовать, вылиться в параллельные дискуссии и даже ссоры. Попробуйте одновременного проводить несколько семинаров — это позволит исследовать требования различных классов пользователей. В обсуждении должны участвовать сторонник продукта и другие представители пользователей, возможно, эксперт в данной предметной области, бизнес-аналитик и разработчик. Допуском к участию в семинарах по сбору информации являются знания, опыт и право принимать решения.
    8. Вовлекайте в обсуждение каждого. Иногда участники самоустраняются от обсуждения, расстроившись по какой-то причине. Возможно, их идеи не воспринимают серьезно, поскольку другим участникам их проблемы кажутся неинтересными или они не хотят отвлекать группу от текущего обсуждения. Возможно, аутсайдер не уверен в себе и уступил право голоса более активным сотрудникам или главному аналитику. Организатору семинара необходимо следить за языком телодвижений, чтобы разобраться в причинах замкнутости того или иного участника, и попытаться снова вовлечь его в работу. Видимые подсказки недоступны, если обсуждение ведется в режиме телеконференции — в этом случае вы должны внимательно слушать и ориентироваться по тону голоса. Молчаливых участников можно спросить прямо, нет ли у них мыслей, которыми они хотели бы поделиться. Организатор обязан обеспечить, чтобы все были услышаны.

    Ресурсы в сети internet и книги, информация из которых использовалась при создании статьи

    1. http://lib.uml2.ru/
    2. http://tim.com.ua
    3. http://dic.academic.ru/
    4. http://businessstudio.ru/
    5. http://www.kpms.ru/General_info/Benchmarking.htm
    6. http://powerbranding.ru/rynok/plan-analiza/
    7. https://ru.wikipedia.org
    8. http://www.bankiram.pro/2011/11/blog-post_17.html
    9. Илья Корнипаев. Требования для рограммного обеспечения: рекомендации по сбору и документированию.
    10. Вигерс Карл и Джой Битти. Разработка требований к программному обеспечению.


    Инструменты McKinsey

    Литература

    Инструменты McKinsey

    Введение

    В данной статье приводятся основные тезисы, которые можно вычленить из глав этой книги. Я очень рекомендую приобрести данную книгу и полностью ознакомиться с ее содержанием.
    Почему на моем сайте, который предназначен для бизнес-аналитиков и системных аналитиков, существует этот раздел?
    McKinsey — знак качества в сфере консалтинга: всем известно, как сотрудники Фирмы блестяще решают чужие бизнес-проблемы. А можете ли вы сами справиться с трудностями в своей организации, применяя их секреты? Или нужно обязательно приглашать команду из McKinsey? Опросив несколько сотен своих экс-коллег (бывших сотрудников Фирмы), успешно применяющих теперь ее техники в других организациях, авторы пришли к выводу, что многое можно осилить самостоятельно. В этой книге они предлагают инструменты McKinsey, овладев которыми вы почувствуете себя «немного маккинзиевцем» и принесете большую пользу своей компании. Рекомендуется к прочтению бизнес-консультантам, руководителям и менеджерам, которым приходится решать проблемы и реализовывать решения на практике.

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

    Краткое описание всех разделов

    Структурирование проблемы: структурирование вопроса, построение его схемы, архитектура, визуализация с помощью ментальных карт или дерева вопросов. Очень полезный инструмент для приведения в порядок всех имеющихся данных. Организовывает и создает порядок, систематизирует материал. За структурой-схемой уже потом видна система, зная принцип работы которой, можно достроить недостающие звенья. Выдвижение гипотезы и проверка ее с помощью дерева вопросов.
    Разработка анализа: выработать план анализа, найти ключевые факторы, увидеть картину целиком, расставить приоритеты, использовать метод триангуляции (нахождение третьего неизвестного по координатам известных двух).
    Сбор данных: факты — самое главное. ищите главные факты- это основное в стратегии исследования. Интервью — это тот метод, который дает огромное количество фактов, главное правильно сформулировать вопрос. Прекрасные советы по проведению исследовательского интервью. Управляйте знаниями. Добытые вами факты должны быть легко и быстро доступны всем заинтересованным лицам.
    Интерпретация результатов. Правило 80/20. 20% анализируемых примеров создадут 80% изучаемого результата. Всегда помните о цели исследования.
    Презентация идей. В основе презентации должна быть структура. Та самая, о которой говорилось в первой главе. Все заключения давать в начале презентации. Будь проще. Планируйте.
    Управление командой. Формируйте команду под проект, цените разнообразие способностей. Способствуйте коммуникации в команде, создавайте и развивайте отношения в команде. Проводите регулярную оценку результатов деятельности команды.
    Управление клиентом. определите своего клиента и узнайте чем он дышит. Создавайте условия для внедрения вашего решения у клиента. Вовлекайте клиента в процесс, но четко разграничивайте время, место, обязанности двух сторон, помните о границах.
    Управление собой.Свобода от иерархии. Планирование. Знайте свои возможности и делегируйте. Уважайте свое личное время.

    Модель стратегического решения проблем

    model_of_strategic_solutions

    Структурирование проблемы

    Структурирование

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

    Соблюдайте принцип МЕСЕ. Концепция МЕСЕ (аббревиатура от Mutually Exclusive, Collectively Exhaustive — «взаимно исключающие, совместно исчерпывающие») — это базовый принцип мышления в McKinsey. Он заключается в том, чтобы разделить проблему на отдельные непересекающиеся вопросы и убедиться, что при этом не упущено ничего из того, что относится к вашей проблеме.
    Не изобретайте велосипед. На основе своего опыта McKinsey разработала множество схем, которые помогают ее консультантам быстро обрисовать многие распространенные в бизнесе ситуации. Если у вашей организации уже есть собственные схемы, по возможности пользуйтесь ими; если еще нет, то развивайте собственный инструментарий решения проблем.
    Каждый клиент уникален. Схемы — не панацея. Каждый клиент уникален. Стараясь просто подогнать проблемы каждой организации под соответствующие схемы, вы далеко не уйдете. Бывшие сотрудники убедились в правильности этого урока на своем опыте после Фирмы.

    Структурированное мышление

    Структурированное мышление — важное орудие для решения проблем в арсенале любого бизнесмена.
    Вы должны понять, что структурирование существует не в вакууме; нужно использовать его с определенной целью. А в контексте решения бизнес-проблем ваша цель — создать порядок из хаоса.
    Структурирование — лишь начало. Далее необходимо выдвинуть сильную гипотезу, выполнить нужные виды анализа, сделать выводы и организовать эффективную презентацию.
    Логическое дерево — это лишь одна из множества схем, используемых консультантами McKinsey, но особенно популярная. Как любая схема, она помогает разобраться в путанице сложной проблемы и создать порядок из хаоса, выстроив некое упрощенное представление о происходящем.
    logical_tree

    Выдвижение гипотезы

    Принципы выдвижения гипотезы:
    Решайте проблему на первой же встрече. Анализ фактов с намерением подтвердить или опровергнуть первичную гипотезу — гораздо более действенный способ, чем поочередный анализ этих фактов в поисках неизвестного ответа. Гипотеза дает своего рода карту для решения проблемы; следуя ей, вы будете задавать правильные вопросы и выполнять правильные виды анализа. Хорошая гипотеза экономит время: если вы пойдете по неправильному пути, она быстро укажет тупики и позволит вернуться к главному. Начальная гипотеза создается консультантом на основе ограниченного набора фактов, без значительных дополнительных исследований. Если вы не имели опыта работы с данной отраслью, вам может понадобиться несколько часов на изучение отраслевых публикаций и годовых отчетов; если же вы «в теме», то достаточно будет записать несколько предварительных соображений. В идеале затем вы потратите час-два на встречи с коллегами по команде и выработку вероятных ответов на проблему.
    Следующий шаг — решить, какие виды анализа выполнить и какие вопросы задать для подтверждения или опровержения своей гипотезы. Здесь вам поможет дерево вопросов — вид логического дерева, где каждая ветвь (аспект или вопрос) помогает заполнить разрыв между структурированием и гипотезой. Каждый вопрос, возникший в связи со схемой, как правило, можно разбить на подвопросы, а те, в свою очередь, подвергнуть еще более мелкому дроблению. Таким образом, дерево вопросов — это просто визуальное представление организованной по принципу МЕСЕ последовательности вопросов и подвопросов. Отвечая на них, вы сможете быстро определить обоснованность вашей гипотезы.
    question_tree
    Хорошо подготовьтесь. Команды McKinsey разрабатывают и тестируют начальные гипотезы в ходе мозговых штурмов. Однако для мозгового штурма в стиле McKinsey требуется, чтобы все члены команды пришли на встречу подготовленными, усвоив все известные факты и обдумав следствия из них. Процесс пойдет быстрее, если участники придут с уже выработанными начальными гипотезами, чтобы команда смогла обсудить их; но это не обязательное условие. Главное — никто не должен думать, что знает ответ. Каждый должен быть готов учиться.
    Освободитесь от предубеждений. Цель мозгового штурма — выработать новые идеи. Оставьте свои предубеждения за дверью. У всех участников должна быть возможность высказаться и поделиться знаниями. Чтобы мозговые штурмы были успешными, следуйте нескольким важным правилам. Во-первых, нет плохих идей. Во-вторых, не существует глупых вопросов. В-третьих, будьте готовы «убить» свою идею (если команда справедливо раскритикует ее). В-четвертых, знайте, когда закончить: не затягивайте мозговой штурм, иначе он станет неэффективным. И напоследок самое важное: фиксируйте ход штурма на бумаге.
    Помните, что настоящей проблемой может оказаться не та, которая лежит на поверхности. У каждого консультанта возникает соблазн поверить на слово клиенту, который «диагностировал» собственную проблему. Не поддавайтесь этому соблазну. Как пациенты не всегда правильно истолковывают свои симптомы, так и менеджеры иногда ставят неверный диагноз «болезни» своей организации. Единственный способ определить правильность предположений клиента — копать глубже, задавать вопросы и выявлять факты. Проявив некоторый скептицизм в самом начале, впоследствии вы сможете избежать многих разочарований. Более того, вы окажете клиенту большую услугу, найдя реальную проблему, даже если истина ему не понравится.
    Сформировав сильную начальную гипотезу, вы сможете более эффективно решать проблему. Но сначала нужно эту гипотезу выработать и протестировать. Так как это нужно делать в начале процесса решения проблемы, меньше полагайтесь на данные (ведь на тот момент их еще немного), а больше — на интуицию. Возьмите известные вам факты, прислушайтесь к голосу интуиции и подумайте, каковы наиболее вероятные ответы на ваши вопросы. Заметим, что самый вероятный ответ — не обязательно правильный, но он представляет собой хорошую отправную точку.

    Дерево вопросов (серия вопросов, на которые нужно ответить, чтобы подтвердить или опровергнуть гипотезу) — более развитая версия логического дерева (которое по сути представляет собой просто иерархическую группировку элементов). Дерево вопросов заполняет разрыв между структурированием и гипотезой. Каждый вопрос, возникший в связи со схемой, обычно можно разбить на подвопросы, а те, в свою очередь, — тоже. Эта визуализированная последовательность вопросов и подвопросов позволяет сформировать гипотезу и создает «дорожную карту» анализа. Дерево вопросов также позволяет очень быстро исключить тупиковые ветви в ходе анализа, так как ответ на любой вопрос сразу же отсекает ложные пути.
    Составляя дерево вопросов, группируйте возникающие вопросы по принципу МЕСЕ. Для начала разберитесь, какие вопросы являются определяющими — то есть должны соответствовать реальности, чтобы гипотеза оказалась верной.

    Разработка анализа

    Найдите ключевые факторы. Успех большинства компаний зависит от ряда факторов, но не все они одинаково важны. В условиях ограниченного времени и ресурсов вы не можете позволить себе такую роскошь, как подробное изучение всех аспектов проблемы. Вместо этого разберитесь, какие факторы являются ключевыми, и сосредоточьтесь на них. Копайте прямо к корням проблемы, а не вникайте до мелочей в каждый ее элемент без исключения.
    Старайтесь увидеть всю картину. Пытаясь решить сложную, запутанную проблему, вы легко можете потерять свою цель среди миллиона задач, которые нужно решить прямо сейчас. Когда вы чувствуете, что они накрывают вас с головой, сделайте мысленный шаг назад и разберитесь, чего вы пытаетесь достичь. Спросите себя, какое место в этой картине занимает выполняемая сейчас вами задача. Она помогает вашей команде продвинуться к своей цели? Если нет, то вы теряете драгоценное время.
    Не пытайтесь вскипятить океан. Работайте не больше — работайте умнее. В условиях сегодняшнего изобилия данных можно всесторонне анализировать выбранный аспект проблемы. Но вы только потеряете время, если эта кропотливая работа не является ценным вкладом в процесс решения проблемы. Продумайте, какие виды анализа вам действительно нужны, чтобы подтвердить или опровергнуть свою гипотезу; выполните их и двигайтесь дальше. Скорее всего, вы не можете позволить себе роскошь делать что-то сверх самого необходимого.
    Иногда вы должны дать решению прийти самому. У любого правила есть исключения. Не всегда возможно сформировать начальную гипотезу; в этом случае вам придется полностью полагаться на анализ фактов, чтобы постепенно найти путь к конечному решению. Старайтесь, чтобы гипотеза определяла анализ. При планировании анализа вам придется найти нужный баланс между интуицией и поиском фактов. Интуицию обязательно должен дополнять анализ фактов, чтобы основание для ваших решений было прочным. Еще один способ сосредоточиться на нужных вещах — постоянно помнить о конечной цели.
    Правильно расставьте приоритеты. Когда к заключению требуется прийти в сжатые сроки, а ресурсы для решения проблемы ограниченны, нужно разобраться, какие виды анализа жизненно необходимы, а какие — просто «гарнир». Здесь, как и в самом начале работы, вы должны разобраться, чего не надо делать. Когда направление задано гипотезой, вы легко избежите лишней работы. Сосредоточившись на самых выигрышных видах анализа и избегая ненужных, вы сможете многое успеть за краткий срок.
    Забудьте об абсолютной точности. Мы подчеркиваем важность анализа фактов в принятии бизнес-решений. Поэтому может показаться, будто мы противоречим самим себе, говоря, что вам не нужна точность результатов анализа. Но правда в том, что бизнес по большей части не точная наука, в отличие от физики или математики.
    Применяйте к трудным проблемам метод триангуляции. В геодезии и картографии триангуляция — метод определения точного местоположения неизвестной точки путем выполнения измерений с двух известных. Вы можете прибегнуть к аналогичной технике, когда у вас очень мало информации о проблеме (а в бизнесе так бывает очень часто). В какой-то момент вы столкнетесь с вопросом, который на первый взгляд не имеет ответа. Причины бывают разные: например, нужные данные являются коммерческой тайной вашего злейшего конкурента, или вы идете по совершенно новому пути в своей отрасли, или что-то еще превратило этот вопрос в такой крепкий орешек. Не отчаивайтесь. Скорее всего вы сможете придумать какие-то виды анализа, которые позволят нащупать хотя бы вероятные рамки ответа. Опять-таки, если вы идете в верном направлении и правильно определили примерный порядок величины, скорее всего этого будет достаточно для решения.
    Рабочий план
    Разрабатывая свой анализ, помните о его конечном продукте: своем рабочем плане. Полный рабочий план включает все вопросы и подвопросы, которые были определены при структурировании начальной гипотезы. По каждому из них вы должны перечислить следующие элементы:
    • ваши предположения относительно ответа;
    • виды анализа, которые должны подтвердить или опровергнуть эти предположения (в порядке приоритетности);
    • данные, которые нужно проанализировать;
    • вероятные источники данных (например, результаты переписи населения, проведения фокус-групп, интервью);
    • краткое описание вероятного результата данного этапа анализа;
    • имя сотрудника, ответственного за данный этап (вы или участник вашей команды);
    • сроки получения результатов.

    Сбор данных

    Выбор стратегии и инструментов исследований

    Принципы исследований:
    Факты — ваши друзья. В McKinsey решение проблем строится на основе анализа фактов. Факты компенсируют консультанту опыт и интуицию, которых у него еще нет, в отличие от руководителя компании-клиента, много лет проработавшего в своем бизнесе. Факты также помогают консультанту показать, что он разбирается в своем деле, и тем самым завоевать доверие клиента. Вместе с тем факты обладают такой силой, что многие бизнесмены их боятся; но, «пряча голову в песок», они в лучшем случае отсрочат неизбежное.
    Не принимайте ответ «У меня нет идей». У людей всегда есть идеи, если копнуть глубже. Задайте несколько целенаправленных вопросов, и вы изумитесь тому, сколько они на самом деле знают. Услышав от кого-то ответ «У меня нет идей», не спешите сдаваться. Скорее всего, у собеседника просто нет времени, он не уверен в себе или, что хуже всего, ленится думать. Ваша задача — понять причину сопротивления и действовать соответственно.
    Помните: «У меня нет идей» — ответ, который вы не должны принимать ни от других, ни от себя. Подумав получше, вы поймете, что знаете что-то или по крайней мере сможете обнаружить нужные данные.
    Некоторые конкретные советы о проведении исследований. Вот три эффективные техники McKinsey, которые усовершенствуют ваши исследования:
    1) начните с годового отчета;
    2) ищите все, что выходит за границы обычного;
    3) ищите лучшие практики.
    Ежегодный отчет компании-клиента — богатый источник информации о ней; обязательно прочтите «Сообщение для акционеров» или «Отчет СЕО».
    Анализ необычного (часто компьютерный) — инструмент для выделения ключевых возможностей компании и последующего их изучения. Этот метод заключается в том, чтобы вычислять соотношения или сравнивать ключевые показатели (например, продажи каждого продавца по регионам), уделяя особое внимание лучшим и худшим. И наконец, хотя термин «лучшие практики» (модный в бизнесе 1990-х) уже, наверное, набил оскомину, все равно всегда есть чему поучиться у конкурента или другой эффективной организации, даже из другой отрасли.
    Определите, насколько ваша организация ориентируется на данные. Культура McKinsey ориентирована на факты: высказываемые позиции обязательно должны подкрепляться данными, причем как во внутренней коммуникации (с сотрудниками), так и во внешней (с клиентами). Первый шаг к улучшению сбора данных в вашей организации — честно оценить ситуацию. Базируется ли культура вашей компании на фактах? Подкрепляют ли ваши коллеги свои идеи данными? Ссылаются ли те, кто принимает решения, на доказательства своего выбора?
    Продемонстрируйте силу надежных фактов. Тщательнее продумав сбор данных, вы сможете получить надежные результаты и сделать глубокие выводы (до которых иначе могли бы и не дойти); учитывая мощную фактологическую базу, вы можете быть уверенными в их точности. Больше полагаясь на факты, вы сможете увеличить воздействие своего анализа и рекомендаций на организацию.
    Постройте нужную инфраструктуру. В McKinsey консультанты пользуются внутренними исследованиями, отраслевыми отчетами, отчетами аналитиков, данными переписей населения и т.д. Определите ключевые источники той информации, которая наиболее важна именно для вашей организации, и потратьте столько, сколько необходимо для постоянного доступа к ней, — естественно, в рамках вашего бюджета.
    На базе исследований сделайте глубокие выводы, которые раньше были невозможны (именно такова цель эффективного сбора данных). Выделите время на то, чтобы узнать, что действительно важно для главных целей вашей компании — например, прибыльности и роста продаж. А потом соберите нужные факты и поделитесь выводами.
    Вложите средства в привлечение специалистов по исследованиям и дайте им все полномочия по приобретению нужных периодических изданий и отчетов, которые помогут потом сотрудникам принимать решения. Контролируйте расходы: отслеживайте использование материалов и оценивайте их пользу. Необходимо не только финансирование собственно проекта, но и правильные элементы культуры организации, в том числе стимулирование активного использования данных.

    Проведение интервью

    Интервью играют большую роль в работе McKinsey. Они задействованы во всех проектах Фирмы, так как не только приносят первичные данные, но и помогают найти прекрасные источники вторичных. Но интервью ценны не только как метод сбора информации — помимо этого они помогают тестировать идеи и убеждать слушателей.
    При проведении интервью важно подготовиться и проявлять вежливость. Правила для подготовки и проведения интервью:
    Готовьтесь: пишите предварительный план. Составьте письменный перечень желаемых вопросов в том порядке, в котором вы их планируете задать. План необходим по двум причинам. Во-первых, записывая свои мысли на бумаге, вы будете вынуждены их организовать. Во-вторых, план помогает и собеседнику подготовиться к разговору. Ваш план должен быть кратким: три-четыре важнейших вопроса. Ваша цель — за ограниченное время беседы получить на них ответы; все остальное — необязательный «гарнир». И не забудьте задать в конце любимый вопрос маккинзиевца: «Есть ли что-то еще, о чем я забыл спросить?» Случается, что это помогает найти «золотую жилу».
    Проводя интервью, слушайте и управляйте. Консультанты McKinsey знают, как тактично, но твердо выяснить во время интервью нужные вопросы. В этом играет ключевую роль так называемое активное слушание, когда вы проявляете интерес к словам собеседника с помощью кивков и междометий; но не следует недооценивать и молчание. Пусть ваши жесты и мимика будут ободряющими. Не давайте собеседнику уклониться от темы или, что еще хуже, водить вас за нос; вежливо, но твердо не давайте ему сворачивать с нужного пути.
    Семь советов для успешного интервью. У консультантов McKinsey есть много приемов проведения эффективных интервью. Вот главные:
    1. Добейтесь разрешения на интервью от начальника вашего собеседника.
    2. Проводите интервью парами.
    3. Слушайте, а не командуйте.
    4. Перефразируйте, перефразируйте, перефразируйте.
    5. Используйте косвенные подходы.
    6. Не задавайте слишком много вопросов.
    7. Применяйте тактику Коломбо.
    Большинство из них понятны без объяснений, кроме последнего. Лейтенант полиции Коломбо (в исполнении Питера Фалька) — персонаж из телесериала 70-х. Часто после окончания допроса он собирался уходить, но у двери останавливался, чтобы задать еще один вопрос — обычно решающий. Эта тактика срабатывала: многие подозреваемые в этот момент расслаблялись и выбалтывали правду. Вы можете испробовать этот подход, если вам кажется, что собеседник что-то утаивает. Кто знает, может, тогда вы раскроете дело.
    Не оставляйте собеседника «голым». Некоторые люди нервничают в обстановке интервью — вы должны суметь понять эти страхи. Установите контакт с собеседником, чтобы получить нужные вам крупицы информации. Не выжимайте человека, как лимон, заставляя его жалеть о том, что он согласился на этот «допрос»; вместо этого объясните основные цели интервью и положительную роль, которую может сыграть сообщаемая им информация, а в качестве благодарности за содействие расскажите ему что-то полезное. Вы как интервьюер часто находитесь на позиции силы по сравнению с собеседником и обязаны с умом распорядиться этой силой.
    Сложные интервью. Несмотря на ваш высокий уровень подготовки и внимательное отношение к собеседнику, когда-нибудь вам попадется человек, с которым просто сложно проводить интервью. Может быть, у него свои представления о сценарии разговора, и они идут вразрез с вашими. Если собеседник занял жесткую позицию, возможно, вам стоит сделать то же самое, — остается только надеяться, что он пойдет на уступки первым.
    Сложным может оказаться и тип собеседника, который можно назвать «мешок с песком»: он нарочно скрывает ключевую информацию. «Мешок с песком» придется просто обойти; путь наименьшего сопротивления должен привести вас к другому источнику нужной информации. Но сложнее всего проводить интервью с человеком, который действительно рискует потерять работу из-за вашего процесса решения проблемы. К сожалению, здесь нет легкого пути; просто оставайтесь верными своему делу на благо организации в целом.
    Всегда пишите благодарственные письма. Это проявление не только вежливости, но и профессионализма: благодарственные письма способны очень помочь в построении долгосрочных отношений (вспомните, как приятно самому неожиданно получить такое письмо). Часто бывает жалко времени на этот вежливый жест, потому что мы все время куда-то спешим, особенно в век «новой экономики» с электронными и беспроводными средствами коммуникации. Не торопитесь; вы получили то, чего хотели, теперь просто поблагодарите.
    Структурируйте интервью. Очень важно еще до интервью разобраться, что именно нужно узнать. Если вы не хотите застать собеседника врасплох, заранее ознакомьте его с планом интервью. И обязательно делайте заметки во время разговора, а потом расшифровывайте и понятно записывайте их.
    Умейте слушать. Активное слушание означает, что интервьюер поощряет и направляет ответы собеседника, посылая ему вербальные и невербальные сигналы. Кивки, скрещивание рук и выражение лица играют в интервью более важную роль, чем вы думаете. Если вы действительно уделяете внимание интервью, эти вещи должны происходить естественно. А если чувствуете, что приходится «выдавливать» эти сигналы из себя, то, наверное, интервью нужно было закончить минут пятнадцать назад.
    Проявляйте внимательность и тактичность. Некоторые считают, что из собеседника нужно выжать всю информацию до последней капли; на наш взгляд, это неправильно. Мы предлагаем действовать иначе. Попытайтесь наладить контакт с собеседником. Отнеситесь к интервью как к возможности завести новое знакомство и активно вовлечь человека в решение проблемы. Ведь этот двусторонний процесс — нечто гораздо большее, чем простая передача информации в одном направлении. Позволив собеседнику стать вашим партнером, вы сможете развить эти отношения. Избегайте деликатных вопросов в начале интервью. Помните и о личных целях, которые есть у всех, с кем вы встречаетесь: сотрудников, клиентов и конкурентов. Многие, возможно, надеются с вашей помощью реализовать свои замыслы или хотя бы значительно продвинуться в этом направлении. Иногда их цели противоречат вашим; вы как интервьюер должны предвидеть такие ситуации и иметь план на такой случай. Например, иногда вы можете согласиться оказать собеседнику поддержку (если это не идет вразрез с вашими установками). По крайней мере дайте ему понять, что вы входите в его положение, и избегайте вопросов, которые могут вызвать ненужные разногласия.
    Есть еще две возможности проявить дисциплинированность в отношении интервью: общение до интервью и работа с собеседниками — после. Вы должны заранее послать будущему собеседнику план интервью (хотя бы предположительный). Если вы посылали его более чем за неделю до назначенной даты проведения интервью, то стоит сделать это еще раз при подтверждении встречи. Так собеседник сможет подготовить ответы и определить, какие вспомогательные материалы могут оказаться полезными. После интервью запишите полученные данные и передайте эти документы собеседнику, чтобы убедиться, что правильно его поняли, и устранить все недоразумения.

    Управление знаниями

    Что такое управление знаниями? Во-первых, нужно сказать, что знания — это не данные или информация. Данные — это просто факты, наблюдения за происходящим и цифры. Информация — это какой-либо синтез данных. А знания — это сочетание информации, опыта и понимания контекста в процессе создания добавленной стоимости.
    Знания до поры до времени остаются в сознании людей (в таком случае мы называем их некодифицированными), а затем ими можно делиться с другими путем обсуждений или документирования (и в этот момент знания становятся кодифицированными). Управление знаниями — это систематический процесс, с помощью которого организация максимизирует ценность имеющихся у нее некодифицированных и кодифицированных знаний. В целом это означает, что кодифицированные знания зафиксированы в базах данных или документах.
    В McKinsey считают, что даже лучшие технологии Управления знаниями способны зафиксировать лишь малую часть знаний, которыми в действительности обладает фирма. Поэтому реального успеха достигнет та стратегия, которая выйдет за пределы технологии, чтобы зафиксировать ценный опыт, «гуляющий» по коридорам компании, и извлечь из него самое ценное.
    Центральный принцип управления знаниями в McKinsey таков: не изобретайте велосипед. Над какой бы проблемой вы ни работали, существует вероятность того, что кто-то уже делал нечто подобное. McKinsey понимает, какую ценность представляет сбор и использование этого опыта, и прилагает большие усилия для его кодификации. В Фирме ведется две основных базы данных. Одна называется PD-Net и содержит предыдущие отчеты, составленные и «вычищенные» для использования консультантами McKinsey; можно сказать, что это база данных «о чем-то». Другая база данных — справочник по всем экспертам Фирмы в различных отраслях и областях практики; назовем ее базой данных «о ком-то». Пользователи любой из этих баз могут сортировать данные по отраслям, времени, экспертам, представительствам и ряду других критериев.
    Схема факторов, влияющих на Управление знаниями:
    factors_in_knowledge_management
    Блок «Инфраструктура» относится к планировке представительств и отделов, организационной структуре и самой программе Управления знаниями в компании (включая высших руководителей). Если говорить о McKinsey, то в каждом ее представительстве есть обширная сеть специалистов в области информации, которые могут оказать немедленную помощь командам, стремящимся ознакомиться с новыми областями и отраслями. «Технология» представляет конкретные стратегии, с помощью которых можно наиболее эффективно кодифицировать данные и делиться ими. Одна из самых распространенных технологических платформ Управления знаниями — внутренняя сеть компании. Но с любой технологической платформой приходится решать задачу: как постоянно поддерживать актуальность и высокое качество содержащихся в ней данных. В центре треугольника на схеме — слова «бизнес-результаты»; они напоминают, что критерий успешности любых усилий по Управлению знаниями — их влияние на финансовые результаты организации.
    Развивайте культуру быстрого реагирования. Мы определяем культуру как сочетание общих ценностей и предположений сотрудников относительно организации, ее событий и процессов, программ стимулирования и характера ежедневного взаимодействия среди сотрудников.
    В McKinsey существует этический принцип реагирования: если любой сотрудник, даже самый младший консультант, позвонит коллеге в любую точку мира, то ему перезвонят с ответом в течение суток. Это очень помогает при сборе данных и вообще по работе.
    Приобретайте знания вне организации. Приобретайте знания вне организации. Знания могут формироваться как внутри организации, так и за ее пределами. Для создания внутренних знаний нужно распределять информацию среди сотрудников с помощью обсуждений или документов, и это существенная часть любой стратегии Управления знаниями. Знания вне организации тоже важны. Как мы уже говорили, McKinsey выделяет большие средства на то, чтобы постоянно иметь доступ к новейшим наработкам как в Фирме, так и за ее пределами. Каждый проект начинается с поиска внутренней документации, а также определения необходимых внешних изданий или экспертов в данной отрасли.
    Контролируйте качество данных: отсеивайте мусор на входе и на выходе. «Мусор на входе, мусор на выходе» — старая поговорка программистов. Одна из самых сложных задач при разработке полезных систем кодификации для Управления знаниями — постоянно обеспечивать доступность точных данных.

    Интерпретация результатов

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

    Истолкование данных

    В процессе решения проблемы вы подошли к развилке: либо результаты анализа подтверждают вашу гипотезу (тогда перейдите к следующей части этой главы), либо опровергают ее (в этом случае вернитесь к начальной гипотезе и реструктурируйте ее так, чтобы она соответствовала данным; возможно, для этого потребуется дополнительный анализ).
    Принципы, используемые при анализе данных: «80/20».
    Правило «80/20» — одна из великих истин в бизнесе. Согласно этому правилу, 20% анализируемых примеров создадут 80% изучаемого эффекта.
    Ежедневно делайте заметки. В конце каждого дня спрашивайте себя: «Какие три наиболее важные вещи я узнал сегодня?» Отведите полчаса перед уходом с работы на то, чтобы изложить эти вещи на бумаге; красивое оформление не нужно, достаточно на скорую руку набросать диаграмму или краткий список из нескольких пунктов. Это упражнение даст толчок вашим мыслям. Вы не забудете то, что изобразили на этой диаграмме, даже если потом не будете использовать ее. Если же вы не зафиксируете свои мысли, то они изгладятся из памяти уже к моменту выхода из офиса.
    Не подгоняйте факты под решение. Допустим, вы с командой сформулировали блестящую гипотезу; но будьте готовы к тому, что факты и анализ покажут вашу неправоту. В этом случае должна измениться именно гипотеза, а не факты.
    Всегда спрашивайте: «Что это нам даст?». Составляя план анализа, вы должны были исключить из него все те исследования — даже очень изобретательные и интересные, — которые ни на шаг не продвинули бы вас к подтверждению или опровержению первоначальной гипотезы. Но как бы ни был хорош ваш рабочий план, вам почти неизбежно придется провести еще один отсев — после сбора данных, обработки цифр и интервью. Некоторые результаты окажутся тупиковыми: интересные факты, аккуратные диаграммы — но ничего такого, что приблизило бы вас к решению. И ваша задача — отбросить ненужные результаты. Консультант должен синтезировать из разрозненных идей, полученных в результате анализа, глубокие выводы, которые решат проблему клиента. А это получается лучше всего, когда каждый полученный результат выдерживает проверку вопросом «Что это нам даст?».
    Проводите контрольные проверки. Конечно, всегда хочется как можно большей точности; однако в ситуации команд ной работы у вас как лидера команды, скорее всего, нет времени на подробную проверку всех результатов анализа. Но каждый раз, когда вам представляют какие-либо выводы и следующие из них рекомендации, вы можете провести быстрый тест, чтобы убедиться, что ответ по крайней мере правдоподобен. Задайте себе несколько целенаправленных вопросов, ответы на которые покажут, осуществима ли рекомендация и действенна ли она. Не существует единственного наилучшего способа проведения контрольной проверки, вы можете предотвратить многие проблемы, если перед окончательной презентацией зададите себе несколько критических вопросов.
    Помните, что возможности анализа ограниченны. Анализ играет жизненно важную роль в процессе решения проблем в McKinsey, но в конечном итоге его возможности ограниченны. Необходимо сделать некоторые заключения на его основе, ведь данные не говорят сами за себя. Вы достигли той точки в нашей модели консалтинга, где ведущая роль переходит от данных к интуиции. Данные без интуиции — просто «сырая» информация, а интуиция без данных — лишь догадки. Но если сочетать одно с другим, вы получите прочное основание для принятия решений.
    “Когда меняются факты, я меняю свое мнение” Если перенести этот принцип на процесс решения проблем в McKinsey, то получается: когда факты противоречат вашей гипотезе, вы должны менять ее, а не замалчивать факты.
    Существует цикл: от гипотезы к разработке анализа, оттуда к исследованиям, потом к интерпретации результатов и затем, если необходимо, обратно к гипотезе. И только после того как вы окончательно доказали свою заключительную скорректированную гипотезу, можно сформировать конечный результат — советы клиенту.

    Создание конечного результата

    Формирование гипотезы, планирование работы, проведение исследований и интерпретация результатов — вся эта работа выполняется в стенах вашего офиса или кабинета команды.
    В McKinsey есть принцип: убедитесь, что предлагаемое вами решение подходит клиенту.
    Убедитесь, что предлагаемое вами решение подходит клиенту. Менеджмент, как и политика, — это искусство возможного. Самое прекрасное решение, основанное на анализе огромного количества данных и обещающее миллиарды долларов дополнительной прибыли, будет бесполезным, если ваш клиент или его бизнес неспособны его внедрить. Вы должны знать своего клиента — его сильные и слабые стороны, а также возможности: на что менеджмент способен, а на что нет. Вырабатывайте свои решения с учетом этих факторов.
    Советы по выработке подходящего решения для клиента:
    Поставьте себя на место клиента. В зависимости от вашей должности и влияния в организации, а также от ее корпоративной культуры вам, возможно, придется опираться на чужое представление об основных целях СЕО (не исключено, что на представление самого СЕО). В качестве следующего шага спросите себя, как ваши решения будут создавать добавленную стоимость для вашего клиента или организации. Какой будет выгода от каждого действия, которое вы рекомендуете? Достаточна ли она, чтобы оправдать требуемые затраты времени, сил и ресурсов? Насколько эта рекомендация полезна по сравнению с другими? Если ее потенциальные результаты невелики, то первыми должны идти другие, более многообещающие проекты. Перефразируя знаменитую цитату Джона Кеннеди, можно сказать: «Не спрашивай, что твой анализ значит для тебя; спроси, что он может значит для твоего клиента».
    Осознавайте пределы возможностей клиента. Даже самая блестящая стратегия в мире вам не поможет, если ваша организация не в состоянии ее воплотить. Работая над конечным результатом, учитывайте, сможет ли клиент выполнить ваши рекомендации. Есть ли у него достаточные навыки, системы, структуры и персонал? Не прибегнут ли внешние силы (конкуренты, поставщики, клиенты, регулятивные органы) к действиям, которые сведут на нет воздействие вашей стратегии? Вы должны быть в состоянии ответить на эти вопросы, прежде чем давать рекомендацию. Ваш анализ в большинстве случаев должен быть понятен людям со стороны: тогда им будет легче принять, а потом и внедрить ваши рекомендации.

    Заключение

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

    Презентация ваших идей

    Выработка гипотез, планирование работы, исследования и анализ привели вас к презентации; но если неправильно ее провести, вся работа пойдет насмарку.
    Существует два аспекта презентации в стиле McKinsey:
    • Во-первых, необходимо структурировать презентацию, чтобы максимально повысить ее воздействие на аудиторию.
    • Во-вторых, необходимо использовать техники, которые помогают убедить аудиторию принять идеи.

    Структурирование презентации

    Структура презентации должна быть простой и логичной. Следуйте следующим правилам:
    Будьте структурированы. Чтобы успешно презентовать свои идеи, вы должны вести аудиторию путем логичных рассуждений, шаг за шагом, чтобы за вами было легко следовать. Ваша презентация — проявление вашего мыслительного процесса. Четкие рассуждения требуют столь же четкой формы их подачи. И наоборот: если в мыслях царит неразбериха, то их не удастся четко структурировать.
    «Лифт-тест». Иногда бывает совсем мало времени на изложение рекомендаций. Поэтому вы должны уметь ясно и четко изложить их суть клиенту за время 30-секундной поездки в лифте. Если вы прошли «лифт-тест», то вы хорошо подготовились для продажи своего решения.
    Будьте проще: одна идея на диаграмму. Чем сложнее диаграмма, тем менее эффективно она передает информацию. Читатели должны моментально понять значение диаграммы, так что приложите к этому все усилия. Не стоит совмещать в одной диаграмме несколько идей, лучше перерисуйте ее для каждой идеи отдельно и выделите актуальную информацию в каждой диаграмме. Диаграммы должны быть средством передачи сообщения, а не художественным проектом. В вопросе графики Фирма всегда склонялась к консерватизму. В ее презентациях вы не увидите активного использования цвета или объемной графики — за исключением случаев, когда это необходимо для передачи идеи диаграммы.
    Ваши идеи должны опираться на прочную структуру. Заглянув за внешние атрибуты презентации, мы увидим, что ее суть — в продаже. Даже если вы с командой гордитесь гениальностью своих идей и качеством всей проделанной работы, клиент, а также ваши коллеги и организация могут не разделить этого энтузиазма. Грамотно составленная презентация хорошей идеи может быть мощным инструментом изменений. Информирование всей организации о направлении движения действует как катализатор.
    Если вы верно разбили свою начальную гипотезу на вопросы и подвопросы по принципу МЕСЕ (а затем скорректировали ее согласно результатам анализа), то получили готовый набросок своей презентации. Если гипотеза имела хорошую структуру, то и презентация будет иметь хорошую структуру. И наоборот: если логика презентации «хромает», то имеет смысл пересмотреть логику гипотезы. Многие из опрошенных нами бывших сотрудников McKinsey обнаружили, что это полезная проверка их мышления. Просто сведите воедино подтверждения ваших аргументов и разместите их в нужных местах дерева вопросов.
    Приводите заключения или рекомендации в начале презентации. Когда заключения или рекомендации высказываются в самом начале («Мы верим в Х по причинам А, Б и В»), это гораздо легче воспринимается и производит большее впечатление, чем обобщение в конце («А верно, Б верно и В тоже верно; поэтому мы верим в Х»). Изложив свои заключения в начале презентации, вы получаете еще одно преимущество: контроль над уровнем детализации. Поставив выводы в начало, вы также поможете себе пройти «лифт-тест», суть которого, как мы уже говорили, — успеть произнести свои заключения за время поездки в лифте. И если вы следовали методу McKinsey, то ваш первый слайд — с рекомендацией и основными пунктами — и есть ответ на «лифт-тест».
    Если вам не удается четко и сжато выразить свои мысли, то причин может быть две: либо вы недостаточно понимаете материал и должны лучше с ним ознакомиться; либо структуре презентации не хватает четкости и краткости, и нужно ее пересмотреть.
    «Будьте проще». Ваша задача — сообщить ряд рекомендаций, а не проявить себя как художник. И хотя иногда полезно впечатлить аудиторию красивыми изображениями, все же они не должны отвлекать от сообщений, иначе вы только собьете людей с толку. На каждой диаграмме должна быть всего одна идея, которую в данный момент вы хотите донести до аудитории, и чем эта идея проще, тем лучше. Представляя данные, всегда указывайте их источники. Тогда вы сможете отвечать на вопросы, откуда взята информация. Кроме того, вернувшись к старой презентации через несколько лет, вы поймете, где найти эти источники.
    Помните, что, хотя наглядные материалы важны, простого их набора недостаточно: обязательно нужна хорошая структура, чтобы их организовать, иначе у вас будет всего лишь разрозненная группа интересных фактов, не объединенных общей темой. Помните: материалы должны соответствовать логике структуры изложения, чтобы аудитория смогла понять вашу идею; ведь именно в этом и состоит смысл всех ваших действий.

    Убеждение

    Презентация — это всего лишь инструмент; она не является самоцелью.
    Три способа восполнить недостаток информации и доверия:
    • во-первых, позаботьтесь обо всем заранее — ознакомьте аудиторию с вашими находками;
    • во-вторых, избегайте сюрпризов;
    • в-третьих, адаптируйте презентацию к вашей конкретной аудитории.

    Позаботьтесь обо всем заранее. В хорошей деловой презентации не должно быть новой информации, которая потрясет аудиторию. Прежде чем устраивать торжественную презентацию, подробно ознакомьте со своими находками людей, которые будут принимать решения по этому вопросу. Разослать этим людям выработанные вами рекомендации с просьбой сообщить их комментарии до презентации — это и есть «позаботиться обо всем заранее» в понимании McKinsey.
    В таких действиях есть несколько преимуществ. Во-первых, для вас не станут неожиданностью веские возражения против предлагаемого решения. Во-вторых, вы можете заранее склонить на свою сторону людей, которые должны будут одобрить или внедрять ваше решение. В-третьих, вы получаете возможность приспособить свое решение к внутренней политике организации. И наконец, такая подготовка позволяет вам лишний раз свериться с реальностью. Все это повышает вероятность принятия и внедрения вашего решения.
    Избегайте сюрпризов. В бизнесе людям не по душе сюрпризы. Мы имеем в виду не неожиданный дополнительный выходной или повышение бонуса, а новую информацию, заставляющую менять планы или процедуры. Поэтому у рискованных инвестиций — например, в акции компаний с малой капитализацией — выше ожидаемый доход, чем у надежных вложений (например, в государственные облигации). Позаботившись обо всем заранее, вы даете клиенту время свыкнуться с новыми идеями. Кроме того, такая подготовка помогает проверить ваши рекомендации, потому что люди при ознакомлении с ними могут указать вам на упущения и недоработки. Еще важнее то, что, обсуждая свои результаты вне контекста большой встречи, вы скорее убедите ответственных людей принять ваши идеи: во время встречи один на один легче объяснить свои рассуждения. Вы можете узнать, что беспокоит собеседника, и развеять эти опасения. Если он возражает против определенной рекомендации, у вас еще есть время выработать компромиссное решение. Даже если вам не удастся получить полное согласие заранее, предварительная подготовка позволит отточить аргументы.
    В такой ситуации очень полезно подготовить почву, чтобы избежать препирательств по фактам каждого отдельного пункта презентации. Ваша аудитория уже будет знать, из чего вы исходите, и сможет обсуждать ваши идеи, а не данные.
    Адаптируйте свою презентацию к конкретной аудитории. Это нужно делать обязательно, независимо от состава аудитории. Даже если все слушатели — ваши коллеги, они могут и не располагать вашими данными или знаниями по теме. Возможно, аудитория лучше отреагирует на определенный стиль презентации: например, если она будет более формальной, чем обычно; или будет проведена для большой аудитории, а не в узком кругу; или будет строиться на основе текстовых документов, а не в аудиовизуальном формате, и так далее. Одним нравится вникать в мельчайшие подробности, а другие хотят услышать только основные аргументы. Если вы хотите успеха вашей презентации, то изучите аудиторию, ее предпочтения и уровень подготовки. Иногда приходится даже корректировать структуру презентации. Если вы знаете, например, что ваша аудитория не любит излишних подробностей, зачем тратить на них время? Переходите сразу к заключениям.
    Однако нужно знать не только симпатии и антипатии данной группы слушателей, но и их менталитет и жаргон.
    Помните, что на разных языках могут говорить даже отделы одной и той же организации. Вы ведь не стали бы проводить одну и ту же презентацию, скажем, для совета директоров вашей компании и водителей грузовиков, доставляющих ее продукцию. И дело здесь вовсе не в интеллектуальных возможностях разных групп, а в том, что у каждой из них свои ожидания, цели и язык. И эти отличия требуют, чтобы вы приспосабливали свое сообщение к каждой группе.