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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По завершении интеграции наступает очередь внедрения. Ваша задача – обеспечить, чтобы те, для кого предназначен ваш проект, смогли воспользоваться результатами вашей работы. Если, например, речь идет о новой компьютерной системе, необходимо объяснять пользователям принципы ее работы. Новые разработки (будь то компьютерные системы, рабочие процессы или организационные структуры) обычно вносят какие-то изменения в работу. Люди должны быть готовы принять эти изменения. Нередко конфликты в рабочих коллективах и провалы проектов, о которых мы узнаем из СМИ, связаны с тем, что менеджеры неэффективно управляли изменениями при внедрении нового продукта.