1.3 Бизнес-цели

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

Табл. 1-2. Примеры финансовых и нефинансовых бизнес-целей

Финансовые цели Нефинансовые цели

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

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

Разговор между бизнес-аналитиком и куратором, одним из топ-менеджеров компании, с целью определить бизнес-задачи и цели может выглядеть, как показано на рис. 1-3. Это иллюстрация к виртуальному проекту системы Chemical Tracking System в виртуальной компании Contoso Pharmaceuticals. На основе ответов топ-менеджера компании бизнес-аналитик может сформулировать бизнес-цели для Chemical Tracking System, как показано на рис. 1-4.

Вопросы аналитика Ответы топ-менеджера

Какими мотивами вы руководствуетесь, заказывая систему контроля химикатов?

Управление наличными запасами химикатов неэффективно и обходится слишком дорого.

Насколько вы бы хотели сократить свои расходы на химикаты?

На 25% в течение года.

Что сейчас мешает сократить расходы на 25%?

2.1 Основные функции

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

2.2 Объем первоначально запланированной версии

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

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

2.3 Объем последующих версий

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

2.4 Ограничения и исключения

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

3. Бизнес-контекст

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

3.1 Профили заинтересованных лиц

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

• основная ценность или преимущество, которое продукт принесет заинтересованным лицам, и то, как продукт удовлетворит покупателей. Ценность для заинтересованных лиц представляют:

❍ повышенная производительность;

❍ меньшее количество переделок;

❍ снижение себестоимости;

❍ ускорение бизнес-процессов;

❍ автоматизация задач, ранее выполнявшихся вручную;

❍ возможность выполнять совершенно новые задачи;

❍ соответствие соответствующим стандартам и правилам;

❍ лучшая, по сравнению с текущими продуктами, легкость и простота использования;

• их вероятное отношение к продукту;

• самые важные для них функции и характеристики;

• все известные ограничения, которые должны быть соблюдены.

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

3.2 Приоритеты проекта

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

• ограничение — сдерживающий фактор, в рамках которого должен оперировать менеджер проекта;

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

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

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

Какова будет ваша реакция? Возможные варианты ответов:

• Вы отложите реализацию определенных требований до более поздней версии.

• Сократите запланированный цикл тестирования системы.

• Оплатите сверхурочную работу ваших специалистов или пригласите специалистов по контракту для ускорения разработки.

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

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

1.6 Бизнес-риски

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

1.7 Предположения и зависимости

Предположение (assumption) — это утверждение, которое предполагается верным в отсутствие знаний или доказательств иного. Бизнес-предположения тесно связаны с бизнес-требованиями. Неверные предположения могут не позволить достичь поставленных бизнес-целей. Например, куратор из руководства компании может поставить бизнес-цель увеличить доход на 100 тыс. долларов в месяц. Определяя такую цифру, куратор сделал определенные предположения, например что новый сайт будет привлекать 200 дополнительных уникальных посетителей в день и что каждый посетитель в среднем будет тратить 17 долларов. Если новый сайт не привлечет достаточно посетителей, тратящих достаточное количество денег, проект может не достичь своей бизнес-цели. Если окажется, что те или иные предположения не оправдались, можете изменить границы или график проекта или запустить другие проекты, чтобы достичь другие цели.

Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный документ о концепции и границах. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, то избежите возможной путаницы и ухудшения ситуации в будущем.

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

2. Рамки и ограничения проекта

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

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

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

1.4 Критерии успеха

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

Рис. 1-4. Пример модели бизнес-целей для системы контроля химикатов

Бизнес-цели иногда невозможно измерить, пока не завершиться проект. В других случаях достижение бизнес-целей может зависеть от других проектов. Но все равно важно оценить успех конкретного проекта. Критерии успеха указывают, находится ли проект на пути достижения бизнес-целей. Эти критерии могут определяться во время тестирования или сразу после выпуска продукта. Для системы контроля химикатов одним из критериев может быть Бизнес-цель 3 на рис. 5-5: «Сократить время заказа химикатов до 10 минут в 80% заказов», потому что среднее время заказа можно измерить во время тестирования или после выпуска. Другой критерий успеха может быть связан с Бизнес-целью 2 с временем, намного более ранним, чем год после выпуска, например: «Отслеживать 60% контейнеров промышленных химикатов и 50% специализированных химикатов через четыре месяца».

1.5 Положение о концепции

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

• Для [целевая аудитория покупателей];

• Который [положение о потребностях или возможностях];

• Эта (этот) [имя продукта];

• Является [категория продукта]; • Который(ая) [основные функции, ключевое преимущество, основная причина для покупки или использования];

• В отличие от [основной конкурирующий продукт, текущая система или текущий бизнес-процесс];

• Наш продукт [положение об основном отличии и преимуществе нового продукта].

Вот как выглядит положение о концепции системы контроля химикатов Chemical Tracking System в Contoso Pharmaceuticals, о которой говорилось в главе 2; ключевые слова выделены полужирным:

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