2.7 Определение возможностей решения
2.7.1

Говорить на языке возможностей (Features)

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

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

Создание ценности

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

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

Соответственно, на уровне бизнеса мы, в конечном итоге, получаем так называемый impact, или влияние: что произойдет в бизнесе от этих изменений — бизнес станет более эффективным, мы заработаем больше денег, или наши клиенты станут более удовлетворены тем, что они получают (и мы заработаем больше денег).
2.7.3

Проектные документы

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

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

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

Формулирование возможностей (Features)

Этап 1 - генерация возможностей:
  • анализ потребностей;
  • анализ сформулированных функциональных требований;
  • "мозговой штурм"
Этап 2 - работа над списком возможностей:
  • значимость каждой возможности (дискретность);
  • достаточность;
  • осуществимость.
Этап 3 - анализ альтернатив.
Всю работу с возможностями системы можно разделить на три этапа:
(1) формулирование возможностей, то есть поиском возможных вариантов;
(2) работа над полученным списком и
(3) сравнение того, что у нас получилось, с возможными альтернативами, или с той ситуацией, которая существует на данный момент.
Первый шаг для того, чтобы сформулировать возможности – выбрать потребности, полученные в результате анализа проблемы, и сформулировать «Какие возможности соответствуют, связаны с этими потребностями?». Эта работа достаточно непростая и не всегда удается выделить те возможности, которые необходимы.
Поэтому применяется обратное проектирование. Понимая, какие технические возможности необходимы для того, чтобы реализовать ту или иную возможность, мы можем переформулировать определенное требование к системе на языке заинтересованных сторон – повысить уровень абстракции от функционального требования к возможности, описывающей, что в итоге может или должен получить заказчик.
Третий способ, очень хорошо помогающий в продуктовых моделях разработки и работы с требованиями, – специальный мозговой штурм, посвященный генерации идей о том, какими возможностями должен обладать продукт для того, чтобы быть успешным и решить проблемы заказчика.

Очень хорошая метафора, которая помогает сфокусироваться именно на возможностях:

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

Критерии формулировки возможностей

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

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

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

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

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

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

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

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

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

Пример. Powerade.

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

Для того, чтобы улучшить ваше понимание того, что значит говорить на языке возможностей и на языке предметной области, приведу пример, как компания Coca Cola производит, позиционирует и описывает продукт.
Первый пункт: изотоническая формула (Powerade ION40) — для большинства обывателей формулировка "ни о чем". Однако спортсмены знают, что потребление различной жидкости меняет плотность крови, а при изменении плотности крови изменяется нагрузка на организм. Это — адресное сообщение, которое увидят только те люди, которые действительно могут понять и оценить ценность этого продукта.

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

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

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

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

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

Если мы согласовываем требования к продукту, то такие важные мелочи, конечно, должны где-то быть зафиксированы. Суммарно можно было бы их сформулировать как еще одну feature, которая была бы описана как "позволяет использовать продукт в процессе занятия спортом".
2.7.7

Задание - формулировка возможностей

Подготовьте 5-7 Высокоуровневых требований к системе (Features), определяющих ценность для посетитель кафе в отношении проекта (Продукта)

Пример Реестра возможностей с установленными взаимосвязями с потребностями.

Ориентировочное время необходимое на выполнение задания: 25-30 минут.

Результаты: Перечень возможностей с кратким описанием.

Оцените по 5 бальной наличие ценности для заказчика в каждой приведенной возможности.
2.7.8

Позиционирование решения

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

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

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

В отличии от приобретения дополнительной техники, которая может быть установлена в кабинеты, наш продукт снижает Total cost of ownership (затраты на владение) и, дополнительно, ведет учет создания печатных копий конфиденциальной информации.


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

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

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

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

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

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

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