Этой статьей я начинаю цикл материалов, посвященных тому, что надо сделать руководителю проекта до старта проекта, чтобы снизить неопределенность. На мой взгляд, самое важное – определить продукты (результаты) проекта и проработать требования к каждому из них. Чем более четко сформулированы требования, тем легче спрогнозировать сроки, бюджет и объемы проекта. Давайте обсудим процесс сбора и анализа требований к продуктам (результатам) проекта.
Для компании, которая платит за проект, создается некая ценность – в виде материальных или нематериальных результатов проекта.
В ходе своих рассуждений я воспользуюсь определением термина «результат проекта», которое дает Свод знаний по управлению проектами PMBOK V:
Поставляемый результат (Deliverable) – любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта.
В статье речь пойдет о сборе требований и их анализе к поставляемым результатам проекта, но я позволю себе заменить термин «поставляемый результат» на термин «результат проекта», сохранив при этом определение термина.
Итак, до старта проекта руководителю и заказчику нужно договориться о том, каких результатов заказчик ожидает от проекта. Иногда это не так просто, как кажется на первый взгляд. Попробуйте определить цель для проекта проведения корпоративного праздника, а затем сформулируйте результаты, которые помогут реализовать эту цель. Как вы с этим справились? Думаю, было нелегко.
Давайте рассмотрим ситуацию на примере проекта «Внедрение CRM-системы в компании». Заказчик сформулировал следующие цели:
- стандартизировать действия сотрудников при работе с клиентами компании;
- сократить трудозатраты на выполнение отдельных операций;
- повысить достоверность данных о клиентах.
И отсюда результаты проекта:
- Регламент, описывающий работу сотрудников с клиентами
- Программный продукт, автоматизирующий правила работы с клиентами, описанные в Регламенте
- Обученные работе в программном продукте сотрудники компании
- Работающий сервис поддержки пользователей программного продукта
Для того чтобы удовлетворить ожидания заказчика, руководителю проекта необходимо уточнить требования к каждому результату проекта.
Что такое требование?
Существуют десятки определений этого термина.
Например, в ISO 9000 написано следующее: Требование – это потребность или ожидание, которое установлено, обычно предполагается или является обязательным.
В IEEE Standard Glossary of Software Engineering Terminology (1990) приведена такая трактовка: Требование – это условия или возможности, необходимые пользователю для решения проблем или достижения целей.
За основу возьмем определение из ISO 9000, при этом будем считать, что ожидание считается установленным, если оно записано в документе, который согласовал заказчик.
Классификация требований
Для некоторых продуктов уже разработаны классификаторы требований, которые позволяют снизить вероятность того, что некоторые важные требования к продукту могут быть упущены.
Например, существуют классификаторы требований к программному обеспечению. Один из них представлен на рисунке 1:
©Карл И. Вигерс «Разработка требований к программному обеспечению»
С точки зрения сбора требований к программному продукту такая классификация позволяет аналитику помнить о том, что кроме требований к функциям программного продукта необходимо уточнить требования к внешним интерфейсам, ограничения системы. Кроме того, данная классификация помогает понять, с чего начать сбор требований и как их уточнять (стрелки на диаграмме показывают последовательность сбора требований, но при этом аналитик может возвращаться к предыдущим этапам). В книге К. Вигерса даны определения каждой категории требований и примеры по ним, поэтому я не буду приводить их в статье.
Итак, при сборе требований к программному продукту аналитику требований уже есть чем руководствоваться – есть классификаторы требований и описания классов требований.
Рассмотрим, какие могут быть требования к регламенту, описывающему правила работы с клиентами компании. Как мне кажется, они могут быть такими:
- Регламент процесса должен содержать описание процесса в нотации …..(здесь нужно уточнить название нотации)
- Регламент должен содержать матрицу ответственности с перечислением функций каждого участника процесса (к матрице ответственности тоже можно предъявить требования)
- Документ не должен превышать определенное количество слов (это является ограничением)
- Документ должен быть написан определенным шрифтом (можно указать его название и кегль)
- В документе обязательно должны быть следующие разделы (к каждому можно предъявить требования по содержанию)
- Документ должен содержать раздел, описывающий внесенные изменения в документ и т.д.
Конечно, при наличии классификатора требований к документам типа «Регламент» аналитику было бы проще учесть все классы требований, но такого классификатора я пока не встречал.
Какие требования можно предъявить к такому результату, как обученные сотрудники?
- Сотрудники должны пройти обучение по работе с программным продуктом
- Для обучения сотрудников должна быть разработана программа обучения (могут быть требования к содержанию программы)
- Обучение должно проходить на реальных примерах компании. Примеры для обучения должны быть утверждены заказчиком проекта
- По итогам обучения проходит тестирование знаний сотрудников. Средний балл по итогам тестирования на знание программного продукта составляет не менее ___ баллов (по 10-бальной шкале)
- Требования к методике тестирования знаний сотрудников следующие…. и т. п.
Требования к работающему сервису поддержки программного продукта можно сформулировать так:
- Стоимость сервиса поддержки в месяц
- Время предоставления сервиса (например, с 8.00 до 20.00 по GMT+2)
- Время реагирования на обращение в службу (к примеру, 30 минут с момента регистрации обращения в службе поддержки)
- Время на решение проблемы, описанной в обращении пользователя (здесь нужно вводить классификацию обращений и по каждому из них определять норматив на закрытие обращения или на перевод его в другой статус)
- Время на восстановление сервиса в случае сбоя
- Возможность для пользователей отследить статус своего обращения
- Возможность получить отчет по обращениям за определенный период и т. д.
Сформулировав требования к результатам проекта, руководитель проекта может начинать планировать состав работ и прогнозировать объемы работ, сроки и бюджет проекта.
Мы должны понимать, что любое пропущенное требование к результату проекта приведет к дополнительным объемам работ, а это повлияет на сроки и бюджет проекта. Поэтому для руководителя проекта очень важно попытаться собрать максимально полные требования перед стартом проекта.
Какие есть подходы к сбору требований к результатам проекта?
Самые распространенные подходы к сбору требований представлены на рисунке ниже:
Методы расположены на шкале сложности (отмечу, что расположение подходов на этой шкале – это мое субъективное мнение).
Наблюдение используется для получения информации о том, как определенная заинтересованная сторона проекта исполняет свои обязанности или задачи. На мой взгляд, метод хорош для уточнения требований к уже имеющемуся продукту, когда люди, пользующиеся продуктом, не могут или не хотят изложить свои требования.
Анкеты – письменные наборы вопросов, разработанные с целью быстрого сбора информации у большого числа респондентов. Анкеты лучше всего подходят для ситуаций, когда ограничено время на сбор информации, когда респонденты территориально распределены или когда бюджет на сбор информации по требованиям сильно ограничен.
Анализ документов используется для выявления требований путем анализа существующей документации и идентификации информации, которая имеет отношение к требованиям. Существует множество документов, которые можно проанализировать для выявления требований.
Интервью - подход, используемый для получения информации у заинтересованных сторон путем диалога с ними. В ходе интервью задают подготовленные и непосредственно возникающие вопросы и записывают ответы. В ходе интервью тот, кто проводит интервью, получает возможность считывать дополнительную информацию по мимике и жестам собеседника и задавать уточняющие вопросы, что невозможно при проведении анкетирования.
Фокус-группы позволяют выбрать несколько представителей от каждой из заинтересованных сторон проекта и провести совместное обсуждение, чтобы узнать их ожидания к обсуждаемому продукту или результату проекта.
Мозговой штурм – подход, применяемый для генерации и сбора разнообразных идей, связанных с требованиями к результатам проекта. Часто его используют вместе с другими подходами, которые предполагают приоритезацию собранных требований (например, метод номинальных групп, построение ассоциативных карт, диаграммы сходства и т. д.).
Инновационные игры – с помощью бизнес-игры модератор вовлекает заинтересованные стороны проекта в сбор требований к продукту и в ранжирование этих требований. Этот подход я уже описывал ранее в своей заметке: http://project-management.zis.by/uluchshenie-proektov/kak-povysit-tochnost-prognozirovanija-srokov-proekta.html
Прототипирование – способ сбора требований путем предоставления модели ожидаемого продукта. Модель будущего продукта может быть физической, графической или компьютерной, но она должна по максимуму продемонстрировать пользователям, каким будет будущий продукт. Через демонстрацию прототипа можно быстро получить обратную связь о том, насколько продукт удовлетворяет ожиданиям, и уточнить требования. Прототипы поддерживают концепцию последовательного уточнения требований в серии итераций, проведения экспериментов пользователем, формирования отзывов и пересмотра прототипа.
Моделирование процессов – метод используется для сбора требований к выполнению процесса (или некоторой деятельности). Используются графические модели, которые позволяют согласовать структуру действий в процессе, ответственных за выполнение отдельных действий, преобразования объектов деятельности. Для моделирования процессов при сборе информации часто используются интервью, анкеты, фокус-группы.
QFD (quality function deployment) — подход, который помогает определить критически важные характеристики для разработки нового продукта, отталкиваясь от требований будущих пользователей. В подходе используются матрицы, например, которые показывают связи между требованиями и техническими характеристиками продукта. Отмечу, что этот подход используется не только для сбора, но и для анализа требований.
После того как требования к результатам проекта собраны, их нужно проанализировать на предмет полноты, наличия противоречивых требований, наличия проблем с реализацией требований. Для решения этих задач аналитик требований может использовать такие инструменты, как реверсивный анализ требований, анализ систем-аналогов, ТРИЗ, Root Conflict Analysis Plus (RCA+), Value-Conflict Mapping +.
Как видно из списка подходов, аналитик требований должен знать и уметь достаточно многое для решения вопросов, связанных со сбором и анализом требований.
И в заключение я хочу привести простую мысль: если, будучи руководителем проекта, вы должны подписаться под проект с определенными сроками и бюджетом, но при этом ваша команда не понимает требований к результатам проекта или убеждена, что имеющиеся на входе проекта требования слишком абстрактны, ваш проект содержит слишком большую неопределенность. Как резко сократить неопределенность в таком проекте? Один из вариантов – вынести сбор и анализ требований к результатам проекта в отдельный проект, и только по его итогам определять сроки и бюджет проекта реализации. Да, не для всех проектов этот вариант подойдет, но его не стоит отбрасывать без дополнительного анализа.
Итак, подведем итоги размышлений:
- Успех проекта закладывается на его старте путем уточнения целей проекта, результатов проекта, требований к результатам.
- Сбор требований к результатам проекта позволяет команде проекта понять, чего ожидают от результатов проекта заинтересованные стороны. На основании собранных и проанализированных требований команда может разрабатывать технические решения по реализации требований, определять список работ по проекту, прогнозировать трудозатраты работ проекта. Чем полнее требования к результатам проекта, тем точнее может сделать прогноз по трудоемкости проекта, срокам и бюджету руководитель проекта.
- Собранные требования к результатам проекта нужно проанализировать на предмет их полноты, наличия противоречивых требований, наличия проблем с реализацией требований.
- В проекте, в котором требуются сбор или уточнение собранных требований, нужно планировать использование аналитика требований, который должен владеть различными подходами к сбору и анализу требований.
Лично я в небольших проектах совмещаю роли руководителя проекта и аналитика требований. Но если проект сложный и бюджет проекта позволяет, я стараюсь привлекать к нему профессиональных аналитиков, чтобы снизить риски, связанные с неполными требованиями к результатам проекта.
Удачи вам при сборе и анализе требований в проектах!