Управление проектами от А до Я

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

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

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

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

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

Тестирование, интеграция и внедрение

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

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

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

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

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

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

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

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

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

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

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