Качества позволяет убедиться что требования заказчика интегрированы в каждую часть проекта

57. Идентификация и аутентификация проекта.

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

1. Степень организационного влияния участников проекта.
2. Воздействие участников на реализуемый ИТ-проект.

58. Формирование требований проекта. Организация и проведение результативного интервью. Использование функции качества.Ответ: Формирование требований проекта Процесс формирования требований проекта направлен на изучение требований заказчика, которые должны быть отражены в уставе проекта, и перенос их в более конкретные термины требований проекта, на основе которых формируются списки проектных работ и программа качества проекта. Организация и проведение результативного интервью:1. Подготовка.Формулировка точных основных идеи. Участники команды должны ясно представлять себе, какого рода информация нужна и каким образом она будет использоваться. После этого необходимо переходить к формированию вопросов. 2. Проведение. Рекомендуется планировать интервью исходя из максимальной продолжительности в 1,5 часа. Для проведения интервью часто составляют команды по два человека, один задает вопрос, а другой делает пометки. 3. Дальнейшие действия. После всех встреч нужно собрать полученную информацию в отчет. В качестве отчета по интервью готовится сводный протокол, который затем отправляется на согласование. Использование функции качестваФункция качества – это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента – убедиться, что требования заказчика интегрированы в каждую часть проекта. Процесс построения «дома качества» — инструмент, предназначенный для значительного повышения качества процесса управления требованиями проекта. Этапы заполнения «дома качества»:

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

Качества позволяет убедиться что требования заказчика интегрированы в каждую часть проекта

Сформулируйте вопросы. После того как определены три основные темы, приступайте к заполнению рекомендаций для обсуждения (см. рис. 4.5). Начните с внесения выбранных тем в блоки слева. Далее сформулируйте вопросы, чтобы побудить заказчика к обсуждению обозначенных тем. Есть два вида вопросов: ключевые и дополнительные. Подобно двум сторонам одной медали, они обеспечивают понимание тем первого уровня, вместе с тем давая целостное видение темы.
Заметим, что многие вопросы уже были обозначены во время мозгового штурма при выяснении тем. Теперь, зная три наиболее важные темы, мы можем оценить, каких вопросов не хватает. Это полезно для составления ясного и полного списка. Как правило, в одну тему может входить от пяти до десяти ключевых и дополнительных вопросов. Ключевые вопросы должны быть записаны в середине, а дополнительные – в первой части рекомендаций для переговоров (см. рис. 4.5). Результативность такой работы полезно проверить в ролевой игре: один участник команды задает остальным вопросы из рекомендации. Подтверждение правильного выбора вопросов не задействованными в проекте людьми также является выигрышной тактикой. Это поможет команде более точно сформулировать вопросы и оценить последовательность тем.

Использование рекомендаций для переговоров

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

Время использования. Собрание команды проекта – наиболее эффективный путь для разработки рекомендаций. Мероприятие может занять около часа (при более сложных задачах – до двух часов).

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

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

ИСКУССТВО ЗАДАВАТЬ ВОПРОСЫ
Источник большинства ошибок – неправильная манера задавать вопросы на интервью с заказчиком. Чтобы избежать проблем:
• не включайте в вопрос собственные предубеждения;
• не используйте наводящих вопросов. Этот термин взят из судебной практики, где на вопрос необходимо получить ожидаемый ответ;
• не задавайте ограничивающих вопросов. Это мешает заказчику дать развернутый ответ.
Ниже приведен список вопросов, наиболее полезных при проведении интервью с заказчиком:
• не ограниченные временем вопросы. Такие вопросы позволяют заказчику высказать все свои требования. Если спросить, например: «Каковы три основные проблемы, встречающиеся в процессе сдачи проекта?» – заказчик сможет рассказать о проблемах, основываясь на своем восприятии и с учетом собственных приоритетов;
• визуализирующие вопросы. Эти вопросы помогают заказчику обрисовать потребности. «Что, если ваш компьютер мог бы уведомлять о задержках проекта и конфликте ресурсов?» Пока эта возможность не реализована в компьютере, заказчик будет думать рационализаторски;
• оборачивающие вопросы. Такие вопросы подразумевают ответ вопросом на вопрос. Например, если заказчик спросит: «Какие технологии вы будете использовать в новом проекте?» – мы ответим: «А какой должна быть технология, чтобы соответствовать вашим требованиям?»

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

Резюме

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

Использование функции качества

Что такое функции качества?

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

Рис. 4.6. Функция качества

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

Подготовка требований заказчика. Требования заказчика – важнейшая информация при построении дома качества. Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. В идеальном случае для определения требований используются инструменты, о которых мы говорили ранее: сетевой график заказчика, целевой план, выборка и рекомендации для обсуждения. Их задача – помочь получить информацию, касающуюся нужд заказчика. В терминологии дома качества такие требования заказчика принято называть «Whats» (Что), обозначая этим словом пожелания заказчиков (в случае требований, расставленных с учетом приоритетов).
Наш пример определяет пять наиболее важных требований (рис. 4.7). Здесь заказчик – группа из семи управляющих и менеджеров проектов подразделения – потребовал предоставить краткий документ, описывающий культуру компании, понятную конечному пользователю и относящуюся к уровню рабочей группы проекта. Методология также должна была базироваться на корпоративном понятии жизненного цикла проекта.
Пять необходимых условий были выделены при анализе длинного списка требований, которым интервьюируемые уделяли особое внимание. Небольшое количество значимых требований обеспечивают простоту построения дома качества. Большая часть компаний, использующих функции качества, ограничивают список потребностей десятью пунктами. О работе с большим списком рассказывается во врезке «Кошмар 2500-й ячейки».

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

Рис. 4.7. Функции качества проекта

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

КОШМАР 2500-Й ЯЧЕЙКИ
Пат: Что произошло с вашей функцией качества? Такое впечатление, что ей еще далеко до завершения.
Джим: Моя команда ушла, а я отказался от роли менеджера проекта. Потому она и не завершена.
Пат: Но ведь все члены твоей команды пользовались функцией качества раньше? А потом ушли? В чем дело?
Джим: Они перестали приходить на собрание по разработке функции качества. Было множество разнообразных извинений, но я-то знаю: они просто были уверены, что работают впустую.
Пат: Много работы приходится делать впустую.
Джим: Мы уже потратили 16 часов. Возможно, потребуется еще 24. Команда говорит, что наша функция качества слишком большая и на ее составление уходит очень много времени.
Пат: Джим, у тебя матрица 50 × 50. Откровенно говоря, работать с ней действительно обременительно и невыгодно. Твои подчиненные – занятые люди и не могут потратить целую неделю на построение функции качества. Почему бы вам не уменьшить матрицу?
Джим: Я хотел. Я им говорил. Но они не желают больше обсуждать функцию качества. Вот почему я отказываюсь от роли менеджера.
Это типичный пример ситуации, когда неверное применение функции качества настраивает людей против менеджера проекта. Мораль здесь такова: функция качества является отличным инструментом только в случае ее правильного использования.

Крыша дома качества связывает соответствующие пары требований проекта. Для обозначения связи могут использоваться разные символы: так, для показа положительной связи мы применяем ●, а для показа отрицательной – ○.
Рассмотрим пример. Через проведение интервью и обследований мы изучаем корпоративный язык, который помогает при написании методологии. Вероятно, данная связь является положительной. С другой стороны, при поэтапном описании методологии неизбежны повторения, в частности на каждом этапе потребуется анализ развития. Это увеличит объем методологии, что недопустимо. Очевидно, что два условия противоречат друг другу.
Почему мы анализируем взаимосвязи и строим крышу? Потому что эти отношения показывают столкновение требований и возможность нахождения компромисса между ними. Мы видели это на примере связи требования ограничения объема страниц и проведения интервью. Построение крыши дома качества позволяет увидеть условия проекта в совокупности, а не по отдельности [12].

Связь условий заказчика и требований проекта. Основа дома качества – матрица отношений. Она использует подход, похожий на применяемый при построении крыши, для обозначения связи требований проекта и условий заказчика. При нехватке времени и необходимости упрощения процесса будем ставить крестик для обозначения сильной связи между требованиями (см. рис. 4.7). Например, использование корпоративного языка способствует как отражению корпоративной культуры, так и прозрачности методологии.
Отсутствие сильной связи указывает на то, что условия заказчика не перекрываются требованиями проекта – иными словами, при его выполнении могут возникнуть проблемы. С другой стороны, если проектное требование не поддерживает ни одного требования заказчика, оно считается избыточным. Большая часть функций качества, применяемых в сложных проектах, имеет тенденцию к усложнению видов отношений. Вместо крестика допустимо использовать другие символы, показывающие степень влияния. Их можно измерить и после умножения на степень важности задействовать для оценки значимости каждого требования проекта [1].

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

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

Остановка или продолжение. Многие проекты используют только функции качества: это позволяет встроить требования заказчика в процесс планирования. Забегая вперед, скажем, что в крупных проектах приветствуется уточнение нужд заказчика на протяжении всей работы над проектом. С этой целью стоятся еще три дома качества (рис. 4.8). Здесь требования проекта (как сделать) из первого дома перемещаются на место требований заказчика (что сделать) во втором и т. д. Основная цель данной процедуры – соотнести требования заказчика с последовательными низкоуровневыми сокращениями проектных работ, полностью переведя их на операционный уровень. Логика тут похожа на иерархическую структуру (WBS): нужно дойти до уровня совокупности работ – уровня, на котором работа выполнена. Такой подход гарантирует, что требования заказчика будут встроены в самое основание блоков, образующих проект. По мере построения четырех домов качества их необходимо анализировать и корректировать.

Рис. 4.8. Четыре функции качества

Использование функции качества

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

Время использования. Время, необходимое для построения дома качества, зависит от его размеров и числа людей, вовлеченных в этот процесс. Небольшой дом (см. рис. 4.7) могут создать три человека в течение 45 минут. Для построения большого (10 × 10) дома качества потребуются усилия пяти-шести членов команды и пять-шесть часов работы.

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

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

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

ПРОВЕРКА ФУНКЦИИ КАЧЕСТВА
Проверьте правильность структуры функций качества. В нее должны входить:
• требования заказчика (что нужно сделать);
• требования проекта (как это нужно сделать);
• крыша дома качества (матрица взаимосвязей);
• матрица соотношений;
• сравнительный анализ проектов конкурентов;
• конечные цели.

Резюме

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

Заключительные заметки

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

Литература

1. Shillito, M. L. 2001 “Voice of the Customer” Boca Raton, Fla.: St. Lucie Press.
2. McQuarrie, E. R. 1998 “CustomerVhits” Vol. 2. Thousand Oaks, Ca.: Sage Publications.
3. Goetsch, D. L. and S. B. Davis 2000 “Introduction to Total Quaitiy” 3d ed. Upper Saddle River, NJ: Prentice Hall.
4. Hammer, M. and J. Champy 1993 “Reengineering the Corporation” JewYork: Harper Business.
5. McKenna, R. 1995 “Real – Time Marketing” Harvard Business Review 73(4): 87 – 95.
6. Scholtes, P. R. 1996 “The Team Handbook” 2d ed. Madison, Wis.: Joiner Associates.
7. University of Michigan Business School and American Society for Quality 1998 “American Customer Satisfaction Index: 1994 – 1998” Ann Arbor: University of Michigan Press.
8. Thompson, A. T. and A. J. Strickland 1995 “Crafting and Implementing Strategy” Boston: Irwin.
9. Hoch, D. J., ?. R. Roeding, G. Purkert, and K. S. Lindner 2000 “The Secrets of Software Success” Boston, Harvard Business School Press.
10. Norman, D. A. 1998 “The Invisible Computer” Cambridge, Mass.: The MIT Press.
11. Shillito, M. L. 1994 “Advanced QFD” New York: John Wiley & Sons.
12. Evans, R. J. and M. W. Lindsay 1999 “The Management and Control of Quality” St. Paul, Minn.: South – Wesiern College Publishing.

Глава 5
Планирование содержания

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

Основные темы настоящей главы – это инструменты планирования содержания:

• устав проекта;
• SWOT-анализ [12] проекта;
• описание содержания;
• иерархическая структура работ.

Рис. 5.1. Роль инструментов планирования содержания в процессе управления проектами

Цель названных инструментов – определить, какие процессы необходимо выполнить в рамках проекта для того, чтобы успешно его завершить (рис. 5.1). В частности, они формируют базовый план для последующей разработки расписания и планирования стоимости. Их применение в сочетании с инструментами организационного планирования, а также планирования качества и риска в конечном итоге приводит к разработке плана проекта. Позднее, на стадии выполнения, базовый план содержания становится основой для упорядоченного контроля содержания и внесения изменений в него, создавая тем самым надежный барьер на пути «расползания» границ содержания.
Данная глава призвана помочь менеджерам проектов:
• познакомиться с различными инструментами планирования содержания;
• выбрать те инструменты, которые отвечают проектным потребностям;
• адаптировать выбранные инструменты в соответствии со своими нуждами.
Перечисленные навыки являются необходимой основой для успешного планирования проектов и разработки процесса стандартизованного управления ими.

Устав проекта

Что такое устав проекта?

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

Составление устава проекта

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

Критерии качества требований и как им следовать

Меня зовут Олеся Иванова, я работаю бизнес-аналитиком в компании Astound Commerce, а в свободное время преподаю на курсе SupremeBA от компании ImPM, поскольку работаю в бизнес-анализе и ИТ уже больше 10 лет.

В этой статье я:

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

Наверное, каждый аналитик на определенном этапе своей профессиональной жизни сталкивался с негативным отзывом команды или других участников проекта: «Требования плохие!» или «Требования некачественные!». Что делать? Как правильно реагировать на такие заявления?

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

Сравнительная характеристика критериев качества требований в различных стандартах

Для начала разберемся с критериями качества отдельно взятого требования.

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

• BABOK 3.0 от IIBA;
• Стандарт ISO/IEC/IEEE: 29148: Systems and software engineering — Life cycle processes — Requirements engineering (правда, доступный мне стандарт датируется 2011 годом, а новая версия вышла в 2018, но надеюсь, в ней не было принципиальных отличий касательно интересующей нас части);
• Guide to Business Analysis от PMI;
• Requirements Engineering Fundamentals от IREB.

Большинство критериев качества, описанных в этих документах, совпадают, однако, есть и уникальные характеристики. Давайте сравним.

Критерии качества отдельного требования — сравнительная таблица

IIBA (BABOK)	IEEE ISO/IEC/IEEE: 29148	PMI (Business Analysis for Practitioners: A Practice Guide)	IREB (Requirements Engineering Fundamentals)
Неделимое (atomic)
	Единичное (singular)
Полное (complete)	Полное (complete)	Полное (complete)	Полное (complete)
Последовательное (consistent)	Последовательное (consistent)	Последовательное (consistent)	Последовательное (consistent)
Краткое (concise)
Осуществимое (feasible)	Осуществимое (feasible)	Осуществимое (feasible)	Осуществимое (feasible)
Однозначное (unambiguous)	Однозначное(unambiguous)	Однозначное(unambiguous)	Однозначное (unambiguous)
Приоритезированное (prioritised)
	Необходимое (Necessary)	Необходимое (Necessary)
Проверяемое (testable)	Проверяемое (verifiable)	Проверяемое (testable)	Проверяемое (verifiable)
Понятное (understandable)			Понятное (understandable)
	Прослеживаемое (traceable)	Прослеживаемое (traceable)	Прослеживаемое (traceable)
		Измеримое (measurable)
		Правильное (correct)
	Не содержащее деталей реализации (Implementation-free)
			Согласованное (Agreed)
		Точное (precise)

Критерии качества набора требований — сравнительная таблица

Также в документах от IEEE и IREB приведены характеристики, которым должен соответствовать набор требований (то есть условный документ, содержащий все требования к продукту).

IEEE ISO/IEC/IEEE: 29148	IREB (Requirements Engineering Fundamentals)
Полный (complete)	Полный (complete)
Последовательный (consistent)	Последовательный (consistent)
	Однозначный (unambiguous)
Осуществимый (affordable)
Ограниченный (bounded)
	Структурированный (clear structure)
	Позволяющий изменение (modifiable) и расширение (extendible)
	Прослеживаемый (traceable)

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

Критерии качества отдельного требования

Неделимое (atomic) или Единичное (singular)

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

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

Пример.

Формулировка пользовательской истории «Как посетитель кинотеатра я хочу забронировать или купить билет в кино» указывает на то, что здесь на самом живет два совершенно разных требования, кстати, с совершенно разными value.

Та же ошибка в Acceptance Criteria:

GIVEN: Пользователь находится на экране со списком фильмов.

WHEN: Пользователь выбирает фильм.

THEN: Пользователь видит два варианта покупки: посмотреть разово или купить фильм навсегда.

Полное (complete)

Критерий качества «Полное» (complete) означает, что информации, представленной в требовании, достаточно, чтобы продолжать работу. Причем уровень полноты и детализации может отличаться в зависимости от выбранной методологии и фазы проекта. Так, требование может считаться «полным» в гибких подходах разработки, если описания достаточно для старта разработки.

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

Проверка соответствия требования этому критерию осуществляется в двух направлениях:

1. По форме:
   • проверить, что требование физически размещено в одном месте документа, а не размазано по нему в виде фрагментов текста выделенных другим цветом;
   • убедиться, что текст требования оформлен и закончен (например, не содержит TBD, либо со стейкхолдерами существует договоренность о том, когда будут получены ответы на открытые вопросы);
   • также для проверки полноты требования можно использовать специальные чек-листы: например, в скраме часто используют артефакт Definition of Ready, это как раз пример такого контрольного списка.
2. По содержанию:
   • убедиться, что в требовании описаны как очевидные (основные), так и неочевидные (ошибочные, альтернативные) варианты использования системы;
   • рассмотреть возможность дополнить текстовое описание функциональности графическими моделями. На рисунке проще увидеть, что какие-то элементы не стыкуются или отсутствуют;
   • наконец, для того, чтобы убедиться, что требование можно брать в работу, стоит обсудить его с теми, кто будет с ним работать. Например, если это требование к системе, то можно получить подтверждение от команды разработки, что им все понятно.

На рисунке ниже приведен возможный пример чек-листа для Definition Of Ready:

Последовательное (consistent) и Прослеживаемое (traceable)

Критерий «Последовательное» (consistent) присутствует во всех стандартах и указывает на то, что требование не должно конфликтовать с другими требованиями, в том числе с теми, которые находятся на других уровнях иерархии (например, требование уровня решения не должно идти вразрез с требованиями уровня стейкхолдеров).

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

1. Частое изменение требований (например, при итеративной разработке), наверное, самая частая причина конфликтов в требованиях.

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

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

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

Пример.

Требование уровня стейкхолдеров:

ТС1: Пароль для входа в систему должен содержать не менее 8 символов.

Неправильно	Правильно
ФТ1: Если Пользователь в форме регистрации ввел Пароль длиной менее 8 символов, Система отображает сообщение об ошибке с текстом «Пароль для входа в систему должен содержать не менее 8 символов».	ФТ1: Если Пользователь в форме регистрации ввел Пароль, не соответствующий критериям указанным в #ТС1, Система отображает сообщение об ошибке. Сообщение об ошибке должно содержать требования к паролю (См #ТС1)

2. Работа над документом нескольких аналитиков — еще один нередкий источник противоречивых требований.

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

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

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

Пример.

Хорошим примером ситуации, когда стейкхолдеры не могут договориться между собой, является необходимость следовать политике GDPR (General Data Protection Regulation).

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

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

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

Вывод — делим требования по географическим зонам. Например: если на сайте пользователь выбрал европейскую страну или язык одной из европейский стран, то должен использоваться дополнительный набор требований для поддержки GDPR. А если выбран турецкий язык или страна Турция, то используется свой дополнительный набор требований.

Критерий качества «Прослеживаемое» (traceable), по-моему, работает на достижение все той же, более высокоуровневой цели «Последовательное». Если у нас явно указана связь между требованиями разных уровней и между требованиями и деталями реализации, отследить проявления непоследовательности гораздо проще.

Осуществимое (feasible)

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

При проверке осуществимости хорошо помогает прототипирование. Сделав наброски пользовательского интерфейса или набросав карты процессов, легко оценить применимость тех или иных решений.

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

Пример.

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

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

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

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

Сложно	Легко

Однозначное (unambiguous), Точное (precise) и Понятное (understandable)

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

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

Основные причины неоднозначности

Использование естественного (человеческого) языка. Человеческий язык неоднозначен по природе. Есть прекрасная карикатура, это иллюстрирующая:

Для того, чтобы увеличить однозначность формулировок, используются специальные шаблоны для записи требований. Такие шаблоны подробно описываются в IREB и IEEE:29148. Конструкции языка Gherkin также были придуманы как раз как средство борьбы с расплывчатыми формулировками.

Пример.

Ниже приведу требования, сформулированные согласно стандартам IEEE:29148 и IREB:

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

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

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

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

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

Здесь поможет единый глоссарий, на который должна быть отсылка при каждом упоминании термина или сокращения.

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

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

Краткое (concise)

Критерий говорит о том, что требование не должно содержать лишнюю, не нужную информацию.

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

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

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

Пример.

Нефункциональное требование и примечание к нему.

НФ#1 Система должна поддерживать 4000 транзакций в день с увеличением числа транзакций до 10 000 в период с 1 декабря по 1 февраля.

Примечание: Увеличение активности в период с 1 декабря по 1 января обусловлено всплеском продаж в предновогодний период. В период же с 1 января по 1 февраля продажи держатся на высоком уровне за счет скидок, которые предлагает продавец.

Необходимое (necessary) и Приоритезированное (prioritised)

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

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

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

Очевидно, что требования с приоритетом «Пока не нужно», «Уже не нужно» и «Вообще не нужно» лучше вынести в отдельный документ или отдельный раздел, чтобы не мешали работе.

Проверяемое (testable, verifiable) и Измеримое (measurable)

Требование «Проверяемое» — в том случае, если оно содержит всю информацию для того, чтобы проверить, удовлетворяет ли система требование или нет.

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

Чтобы убедиться, что требование соответствует этому критерию, полезно использовать чек-лист с вопросами, на которые необходимо ответить при написании требования. Например:

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

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

Пример.

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

Можно переписать его так: «Система должна позволять сотруднику записаться на курсы повышения квалификации. Максимальное допустимое количество раз указано в ».

Правильное (correct) и Согласованное (Agreed)

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

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

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

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

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

Критерий «Согласованное» (Agreed) подразумевает, что с требованием и его приоритетом согласны все стейкхолдеры проекта.

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

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

Критерии качества набора требований

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

Полный (complete)

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

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

Последовательный (consistent) и Однозначный (unambiguous)

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

Так что все, что хотела, я уже сказала при описании этих критериев качества для отдельного требования.

Добавлю только, что с моей точки зрения, критерий «Последовательный» (consistent) как раз правильнее было бы оставить только для набора требований. Так как для отдельно взятого требования «в вакууме» он нерелевантен: психически здоровому человеку довольно сложно создать требование, которое противоречит само себе.

Но поскольку абсолютно все стандарты описывают этот критерий в разделе «Критерии качества отдельного требования», мне приходится смириться с тем, что, видимо, я чего-то недопонимаю. С удовольствием подискутирую на эту тему.

Осуществимый (affordable) и Ограниченный (bounded)

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

Понятно, что жизнь может внести коррективы даже в самые лучшие планы, но как best practice не стоит вносить в SRS или беклог требования, которые вы изначально не собираетесь реализовывать или планируете реализовывать по принципу «только одно из». Лучше определиться заранее, зафиксировать актуальное решение в документе, а потом изменить его, если будет такая необходимость.

Критерий «Ограниченный» (bounded) говорит примерно о том же: не вписывайте в требования ничего сверх того, что действительно необходимо стейкхолдерам.

Пример из практики.

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

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

Структурированный (Clear Structure)

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

Документ или пакет документов должен быть подготовлен и структурирован таким образом, чтобы, с одной стороны, его было легко читать последовательно, без «прыганья» по разным разделам, а с другой — чтобы представители каждой роли могли безопасно пропустить те разделы, которые к ним не относятся. Возможные способы структуризации:

• по классам пользователей: этот способ удобен, когда у системы много пользователей с очень разными сценариями использования;
• по режимам работы системы;
• организация документа в виде списка функций (feature list или feature map).

Трансформируемый (modifiable) и Расширяемый (extendable)

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

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

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

Прослеживаемый (traceable)

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

Выводы

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

�� Подобається Сподобалось 12

До обраного В обраному 16

Что такое функции качества?

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

Рис. 4.6. Функция качества

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

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

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

Пять необходимых условий были выделены при анализе длинного списка требований, которым интервьюируемые уделяли особое внимание. Небольшое количество значимых требований обеспечивают простоту построения дома качества. Большая часть компаний, использующих функции качества, ограничивают список потребностей десятью пунктами. О работе с большим списком рассказывается во врезке «Кошмар 2500-й ячейки».

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

Рис. 4.7. Функции качества проекта

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

• ограничить количество страниц в документе методологии;

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

• использовать корпоративную терминологию при написании документа;

• писать в четком и понятном стиле;

• рассматривать этапы методологии через этапы жизненного цикла проекта.

КОШМАР 2500-Й ЯЧЕЙКИ

Пат: Что произошло с вашей функцией качества? Такое впечатление, что ей еще далеко до завершения.

Джим: Моя команда ушла, а я отказался от роли менеджера проекта. Потому она и не завершена.

Пат: Но ведь все члены твоей команды пользовались функцией качества раньше? А потом ушли? В чем дело?

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

Пат: Много работы приходится делать впустую.

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

Пат: Джим, у тебя матрица 50 ? 50. Откровенно говоря, работать с ней действительно обременительно и невыгодно. Твои подчиненные – занятые люди и не могут потратить целую неделю на построение функции качества. Почему бы вам не уменьшить матрицу?

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

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

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

Рассмотрим пример. Через проведение интервью и обследований мы изучаем корпоративный язык, который помогает при написании методологии. Вероятно, данная связь является положительной. С другой стороны, при поэтапном описании методологии неизбежны повторения, в частности на каждом этапе потребуется анализ развития. Это увеличит объем методологии, что недопустимо. Очевидно, что два условия противоречат друг другу.

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

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

Отсутствие сильной связи указывает на то, что условия заказчика не перекрываются требованиями проекта – иными словами, при его выполнении могут возникнуть проблемы. С другой стороны, если проектное требование не поддерживает ни одного требования заказчика, оно считается избыточным. Большая часть функций качества, применяемых в сложных проектах, имеет тенденцию к усложнению видов отношений. Вместо крестика допустимо использовать другие символы, показывающие степень влияния. Их можно измерить и после умножения на степень важности задействовать для оценки значимости каждого требования проекта [1].

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

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

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

Остановка или продолжение. Многие проекты используют только функции качества: это позволяет встроить требования заказчика в процесс планирования. Забегая вперед, скажем, что в крупных проектах приветствуется уточнение нужд заказчика на протяжении всей работы над проектом. С этой целью стоятся еще три дома качества (рис. 4.8). Здесь требования проекта (как сделать) из первого дома перемещаются на место требований заказчика (что сделать) во втором и т. д. Основная цель данной процедуры – соотнести требования заказчика с последовательными низкоуровневыми сокращениями проектных работ, полностью переведя их на операционный уровень. Логика тут похожа на иерархическую структуру (WBS): нужно дойти до уровня совокупности работ – уровня, на котором работа выполнена. Такой подход гарантирует, что требования заказчика будут встроены в самое основание блоков, образующих проект. По мере построения четырех домов качества их необходимо анализировать и корректировать.

Рис. 4.8. Четыре функции качества

Данный текст является ознакомительным фрагментом.