Ричард Ньютон - Управление проектами от А до Я

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

• обязательными, т. е. без них проект будет считаться незавершенным, а заказчик останется неудовлетворенным. Если готовый продукт не соответствует всем обязательным требованиям, это – провал;

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

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

Пример такого каталога требований приведен в табл. A.1.

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

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

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

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

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

• попросить представить вам план для ознакомления, чтобы удостовериться хотя бы в том, что он существует. При отсутствии плана стоит усомниться в способности подрядчика выполнить работу, если, конечно, речь идет не о выполнении слишком простой задачи;

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

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

Тестирование – задача сложная. В крупных проектах (например, при разработке сложных компьютерных программ) есть исполнители и даже целые команды, занимающиеся только тестированием. Характер тестирования зависит от вида продукта, полученного в результате выполнения проекта. Обычно проводят следующие тесты:

1. Тестирование на полноту выполнения проекта. Получены ли все ожидаемые результаты?

2. Тестирование функциональности. Насколько функционален готовый продукт?

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

4. Тестирование пригодности к эксплуатации. Может ли заказчик использовать готовый продукт и доволен ли он результатами работы?

5. Испытание в реальных условиях. Как работает готовый продукт в реальных условиях и может ли заказчик немедленно воспользоваться результатами вашей работы или нужны доработки?

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

Это довольно просто, если результатом вашего проекта стал один-единственный продукт. Но нередко проект предусматривает разработку серии продуктов, которые должны взаимодействовать друг с другом. Обеспечение их бесперебойной работы называют интеграцией или системной интеграцией. Так, если цель вашего проекта – создать новую коробку передач для разработанного вами кит-кара, на каком-то этапе понадобится интегрировать коробку передач с остальными частями двигателя. Точно так же, если вы разработали компьютерную программу, нужно, чтобы она была совместима с другим ПО, включая операционную систему. Я не буду пытаться объяснить принципы интеграции, которые достаточно сложны и зависят от типа продукта, а ограничусь тремя замечаниями о том, что нужно знать менеджеру проекта:

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