Что нужно сделать до старта проекта. Часть 2

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

– В Части 1 речь шла о влиянии допущений на планирование проекта. Анализ допущений помогает руководителю сформулировать риски проекта и снизить неопределенность.

Но еще большая неопределенность в проекте порождается нечеткими требованиями к его результатам. Изучим вопрос сбора и анализа требований к продуктам (результатам) проекта.

В проекте создается некоторая ценность для компании, которая платит за проект. Ценность эта может выражаться в виде материальных или нематериальных результатов.

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

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

Давайте вернемся к кейсу, который был описан в Части 1 – проект внедрения CRM-системы. В этом проекте заказчик определил следующие результаты:

1. Регламент, описывающий работу сотрудников с клиентами.

2. Программный продукт, автоматизирующий правила работы с клиентами, описанные в Регламенте.

3. Обученные работе с программным продуктом сотрудники компании.

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

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

Что такое требование?

Существуют десятки определений термина «требование».

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

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

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

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

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

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

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

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

Рассмотрим, какие могут быть требования к регламенту, описывающему правила работы с клиентами компании. Как мне кажется, они могут быть такими:

1. Регламент процесса должен содержать описание процесса в нотации … (здесь нужно уточнить название нотации).

2. Регламент должен содержать матрицу ответственности с перечислением функций каждого участника процесса (к матрице ответственности тоже можно предъявить требования).

3. Документ не должен превышать определенное количество слов (это является ограничением).

4. Документ должен быть написан определенным шрифтом (можно указать его название и кегль).

5. В документе обязательно должны быть следующие разделы (к каждому можно предъявить требования по содержанию).

6. Документ должен содержать раздел, описывающий внесенные изменения в документ.

7. Прочее.

Какие требования можно предъявить к такому результату, как обученные сотрудники?

1. Сотрудники должны пройти обучение работе с программным продуктом.

2. Для обучения сотрудников должна быть разработана программа обучения (могут быть требования к содержанию программы).

3. Обучение должно проходить на реальных примерах компании. Примеры для обучения должны быть утверждены заказчиком проекта.

4. По итогам обучения проходит тестирование знаний сотрудников. Средний балл по итогам тестирования на знание программного продукта составляет не менее ___ баллов (по 10-бальной шкале).

5. Требования к методике тестирования знаний сотрудников следующие…

6. Прочее.

Требования к работающему сервису поддержки программного продукта можно сгруппировать по следующим темам:

1. Стоимость сервиса поддержки в месяц.

2. Время предоставления сервиса (например, с 8.00 до 20.00 по GMT+2).

3. Время реагирования на обращение в службу (к примеру, 30 минут с момента регистрации обращения в службу поддержки).

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

5. Время на восстановление сервиса в случае сбоя.

6. Возможность для пользователей отследить статус своего обращения.

7. Возможность получить отчет по обращениям за определенный период.

8. Прочее.

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

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

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

Самые распространенные – представлены на рисунке ниже:

Методы расположены на шкале сложности, чем сложнее метод (по моему субъективному мнению) – тем правее на шкале он находится.

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

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

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

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

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

Мозговой штурм. Часто его используют с другими подходами, которые предполагают приоритезацию собранных требований (например, метод номинальных групп, построение ассоциативных карт, диаграммы сходства и т.д.).

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

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

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

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

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

• на предмет их полноты,
• наличия противоречивых требований,
• наличия проблем с реализацией требований.

Для решения этих задач аналитик требований может использовать такие инструменты как реверсивный анализ требований, анализ систем-аналогов, ТРИЗ, Root Conflict Analysis Plus (RCA+), Value-Conflict Mapping+.

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

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

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

Подведем итоги:

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

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

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

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

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

Удачи вам при сборе и анализе требований в проектах!