• Проконтролируйте, действительно ли все ваши сотрудники, задействованные в проекте, могут быть «освобождены».
• Не забудьте отпраздновать ваш успех.
• Включите задачи, представленные в этой главе, в план и бюджет проекта.
• Если вы не успеваете закончить проект или не укладываетесь в бюджет, не поддавайтесь соблазну не выполнить эти задачи.
Литература
Данный вопрос больше интересует разработчиков различных продуктов (например, разработчиков ПО или конструкторов), чем менеджеров проектов, однако этот аспект очень важен для успешного завершения проекта. Я могу порекомендовать вам: The Definitive Guide to Project Management (Financial Times Prentice Hall) by Sebastian Nokes et al., 2003, Chapters 10–11. The Project Workout (Financial Times Prentice Hall) by Robert Buttrick, 2nd edn, 1999, Chapters 8–11, 27.
Что делать сейчас?
Проанализируйте ваш план. Подумайте, не нужно ли сделать что-то еще, чтобы заказчик мог успешно пользоваться готовым продуктом.
Убедитесь, что вы включили эти задачи в план и бюджет проекта и они поручены исполнителям, владеющим необходимыми знаниями.
Заключение
И вот вы подошли к концу книги. С помощью предложенного в ней алгоритма теперь вы можете управлять проектами. Дополнительную информацию вы найдете в Приложении, а определение понятий – в глоссарии.
В первой главе мы с вами освоили терминологию управления проектами. Прочитав вторую главу, вы научились определять цель проекта и составлять его описание. Ознакомившись с третьей главой, вы узнали, как составить план проекта, а в четвертой главе я рассказал о том, как управлять им. Из пятой главы вы могли почерпнуть некоторые рекомендации по успешному завершению проекта. Кроме того, в каждой главе выделены ключевые факторы успеха, которые помогают легче достичь поставленных целей.
Чтобы стать настоящим профессионалом и выполнять самые сложные и крупные проекты, вам нужно еще многое узнать. Однако в большинстве случаев вполне достаточно будет и тех знаний, которые вы почерпнули из нашей книги. Если вы о чем-то забыли, вы всегда можете перечитать соответствующий раздел.
Практика поможет вам усовершенствовать ваши навыки менеджера проектов. В конце концов управление проектами – это скорее практическая, а не теоретическая дисциплина. Анализируйте, как развивался ваш проект, и учитесь на своих ошибках. Наблюдайте за другими и используйте их опыт и знания.
Теперь же, завершив чтение этой книги, вы можете с полным правом именовать себя Менеджером проектов. Удачи и приятной работы!
Приложение
В этом Приложении я рассмотрю некоторые вопросы, которые могут пригодиться при управлении проектом, хотя и не являются очень важными для данной области. Все они характерны в основном для больших и сложных проектов.
Сбор требований
Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией. Так, проект по переоборудованию офиса, о котором речь шла в предыдущих главах, предусматривал установку новой мебели – столов и стульев. Этой информации достаточно для планирования и управления проектом. Ее, конечно, можно уточнить, оговорив, скажем, тип стульев, количество ящиков в столе и т. д. Эти уточнения и будут требованиями к проекту.
Крупные и сложные проекты обычно насчитывают тысячи требований; есть даже специальная дисциплина – бизнес-анализ, позволяющая выявлять проблемы и определять, что требуется для их преодоления. В этой книге я не буду подробно рассказывать о бизнес-анализе и о том, как его проводить. Отмечу лишь, что в крупных проектах (таких, как разработка программного обеспечения) сбор требований является одним из важнейших этапов жизненного цикла проекта, который может занять несколько недель.
Предположим, вы хотите собрать требования, в объеме несколько большем, чем нужно для описания проекта, но не настолько большом, чтобы потребовалась помощь специалистов по бизнес-анализу. (Напомню, что описание не должно быть слишком подробным; его задача – определить объем работ по проекту, а не собрать требования к нему). Иными словами, вам нужны требования, которые точно опишут продукт, какой надо получить в результате.
Для этого я рекомендую провести серию структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончиться крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:
• обязательными, т. е. без них проект будет считаться незавершенным, а заказчик останется неудовлетворенным. Если готовый продукт не соответствует всем обязательным требованиям, это – провал;
• желательными. Эти требования не обязательны, но важны для заказчика, поэтому их стараются соблюдать, за исключением тех случаев, когда они влекут за собой неприемлемое увеличение стоимости или продолжительности проекта;
• необязательными – это те требования, без которых заказчик вполне может обойтись и которые удовлетворяются только по возможности.
Пример такого каталога требований приведен в табл. A.1.
Привлечение сторонних исполнителей к работе над проектом
Нередко к работе над проектом привлекают исполнителей, не работающих в компании, – подрядчиков, консультантов, сторонних поставщиков и др. Это обычная практика. Они могут обладать особыми навыками, оказывать специальные услуги или просто располагать ресурсами, необходимыми для выполнения проекта.
Управлять этими специалистами следует так же, как и остальными членами команды проекта. В привлечении сторонних исполнителей есть как свои плюсы, так и минусы. Как менеджер проекта, вы обладаете определенными рычагами воздействия на них (можете, например, отказаться оплатить их услуги при некачественном выполнении работы и т. п.). Обычно этого достаточно, чтобы они работали с полной отдачей!
Существует другой вариант работы со сторонними исполнителями: вы привлекаете к проекту внешнюю компанию и передаете часть работ на аутсорсинг, т. е. эта компания принимает на себя всю ответственность за определенную часть проекта и самостоятельно управляет этой частью проекта. В этом случае ваша задача по управлению проектом может значительно упроститься: серия сложных задач превращается в простую задачу с датами начала и завершения, а детали ее выполнения вас не касаются. Такие задачи – «черные ящики» привлекательны по ряду причин. Прежде всего, не нужно беспокоиться о подборе исполнителей и об их мотивации – важны только даты начала и завершения задачи и стоимость услуг. Однако, привлекая компанию-подрядчика, вы должны по-настоящему ей доверять, потому что так же, как и вы, она может не уложиться в сроки!
Передавая сторонней компании часть задач по проекту, вы уже не занимаетесь планированием работ, связанных с выполнением этих работ. Но когда компания сообщит вам о сроках и стоимости своих услуг, вы должны:
• проверить их расчеты. Иногда вежливое, но обоснованное сомнение в реалистичности сроков и стоимости может заставить подрядчика пересмотреть расчеты и выполнить работы дешевле и быстрее;
• попросить представить вам план для ознакомления, чтобы удостовериться хотя бы в том, что он существует. При отсутствии плана стоит усомниться в способности подрядчика выполнить работу, если, конечно, речь идет не о выполнении слишком простой задачи;
• попросить компанию-подрядчика определить в плане ряд контрольных точек и сообщить их вам. Это позволит вам контролировать выполнение плана, и о любом сбое вы тут же узнаете.
Тестирование, интеграция и внедрение
В главе 5 мы писали о тестировании и внедрении готового продукта. Есть еще один этап, который следует рассмотреть, – это интеграция. В крупных проектах тестирование, интеграция и внедрение требуют участия специалистов и значительных затрат времени. Некачественное выполнение этих процедур нередко становится причиной провалов проектов. В рамках данной книги невозможно полностью раскрыть эти темы, поэтому ограничусь небольшим обзором.
Тестирование – задача сложная. В крупных проектах (например, при разработке сложных компьютерных программ) есть исполнители и даже целые команды, занимающиеся только тестированием. Характер тестирования зависит от вида продукта, полученного в результате выполнения проекта. Обычно проводят следующие тесты:
1. Тестирование на полноту выполнения проекта. Получены ли все ожидаемые результаты?
2. Тестирование функциональности. Насколько функционален готовый продукт?
3. Тестирование качества. Соответствует ли качество готового продукта спецификации? Качество можно измерять по-разному, но в любом случае необходимо учитывать такой параметр, как надежность.
4. Тестирование пригодности к эксплуатации. Может ли заказчик использовать готовый продукт и доволен ли он результатами работы?
5. Испытание в реальных условиях. Как работает готовый продукт в реальных условиях и может ли заказчик немедленно воспользоваться результатами вашей работы или нужны доработки?
Процесс тестирования должен быть очень тщательным и хорошо структурированным. Каждый раз полученный результат проверяется с помощью серии тестов, которые входят в так называемое техническое задание на тестирование. В идеале этот документ следует составлять одновременно со спецификацией и отражать требования заказчика. Каждому требованию должен соответствовать определенный этап тестирования.
Это довольно просто, если результатом вашего проекта стал один-единственный продукт. Но нередко проект предусматривает разработку серии продуктов, которые должны взаимодействовать друг с другом. Обеспечение их бесперебойной работы называют интеграцией или системной интеграцией. Так, если цель вашего проекта – создать новую коробку передач для разработанного вами кит-кара, на каком-то этапе понадобится интегрировать коробку передач с остальными частями двигателя. Точно так же, если вы разработали компьютерную программу, нужно, чтобы она была совместима с другим ПО, включая операционную систему. Я не буду пытаться объяснить принципы интеграции, которые достаточно сложны и зависят от типа продукта, а ограничусь тремя замечаниями о том, что нужно знать менеджеру проекта:
1. Интеграция, если она необходима, – это отдельная задача, которая требует затрат времени и ресурсов. Ее нужно включить в план проекта и представить в виде серии операций.
2. Интеграцию можно проводить только в том случае, если она предусматривалась при планировании. Коробку передач для кит-кара нельзя делать, как угодно, ее следует проектировать так, чтобы она соответствовала остальным частям двигателя. Вроде бы это очевидно, но, увы, нередко сложные проекты проваливаются, когда дело доходит до интеграции.
3. Интеграцией должен заниматься специалист, обладающий соответствующими навыками. У вас в команде должны быть исполнители, не только ответственные за достижение нужных результатов, но и те, кто может отследить правильность интеграции готовых продуктов.
По завершении интеграции наступает очередь внедрения. Ваша задача – обеспечить, чтобы те, для кого предназначен ваш проект, смогли воспользоваться результатами вашей работы. Если, например, речь идет о новой компьютерной системе, необходимо объяснять пользователям принципы ее работы. Новые разработки (будь то компьютерные системы, рабочие процессы или организационные структуры) обычно вносят какие-то изменения в работу. Люди должны быть готовы принять эти изменения. Нередко конфликты в рабочих коллективах и провалы проектов, о которых мы узнаем из СМИ, связаны с тем, что менеджеры неэффективно управляли изменениями при внедрении нового продукта.
Управление изменениями – это искусство убеждения: вы должны убедить персонал заказчика в необходимости инноваций. В упрощенном виде управление изменениями означает, что вам нужно внедрить готовый продукт в рабочую среду компании-заказчика и обучить персонал им пользоваться. Самое сложное здесь – подготовить людей к изменениям, снять возникающие у них возражения. Нельзя приступать к управлению изменениями ближе к концу проекта – этим следует заняться с самого начала. К завершению проекта все приготовления должны быть закончены и изменения должны приниматься без возражений.
Если рассмотреть тестирование, интеграцию и внедрение в целом, получается серия этапов, которые нужно включить в план проекта:
1. Тестирование продукта. Проверка полученных результатов.
2. Комплексное тестирование. Тестирование всех продуктов, полученных в результате выполнения проекта, как единой системы.
3. Одобрение пользователем. Конечные пользователи системы должны удостовериться, что готовый продукт соответствует их ожиданиям.
4. Испытание на практике. Интегрированные продукты тестируют в реальных рабочих условиях.
В крупных проектах на тестирование, интеграцию и внедрение может отводиться более 50 % общей продолжительности проекта.
Глоссарий
В глоссарии я привожу термины из области управления проектами, которые употребляются в этой книге. Все определения верны только в контексте управления проектами.
Бизнес-анализ
Структурированное изучение проблемы, имеющей отношение к бизнесу. Бизнес-анализ проводится, чтобы лучше понять проблему, а затем оценить, что требуется для ее устранения.
Бизнес-кейс/коммерческое предложение
Коммерческая цель или выгода является причиной выполнения проекта и может официально фиксироваться в документе, называющемся бизнес-кейсом, или коммерческим предложением. Этот документ обычно включает финансовые показатели (например, прирост выручки, снижение издержек и т. п.) или другие параметры (например, повышение уровня обслуживания потребителей, повышение мотивированности персонала и т. д.).
Бюджет проекта
Необходимые средства, выделенные на выполнение проекта.
Влияние
Последствия принятого решения, проблем, риска или изменения для проекта. Влияние обычно измеряется по отношению к объему работ, стоимости, качеству, срокам или рискам проекта. Например, влияние проблемы может проявиться в увеличении сроков или стоимости проекта; принятое решение может повлиять на рост рисков проекта; влиянием изменения может стать уменьшение объема работ.
Внедрение
Использование и эксплуатация в реальных условиях продукта, полученного в результате выполнения проекта. Внедрение охватывает широкий круг задач, в том числе ознакомление и обучение пользователей.
Внешняя зависимость
Связь одной или нескольких задач проекта с задачами, в него не входящими (иными словами, внешними по отношению к нему).
Выполнение
Завершение проекта или задачи с соблюдением определенных условий (обычно получение ожидаемых результатов в срок и с соблюдением бюджета).
Декомпозиция
Процесс деления (сложной) задачи на более мелкие, чтобы лучше ее понять и выполнить.
Дерево решений (Work Breakdown Stucture – WBS)
Формальное описание всех задач, необходимых для выполнения проекта, представленное в определенной последовательности. WBS является результатом декомпозиции проекта на составляющие его задачи.
Жизненный цикл
Обобщенное, высокоуровневое описание тех этапов, через которые проходит проект.
Зависимость
Логическая связь между двумя или более задачами в проекте, которая определяет последовательность их выполнения.
Задача – «черный ящик»
Задача проекта, которой не нужна подробная декомпозиция, так как она передана на аутсорсинг. В плане она определяется как один пункт. Менеджеру проекта нет необходимости управлять действиями, относящимися к этой задаче.
Заказчик проекта
Лицо (или группа лиц), в интересах которого выполняется проект. Обычно заказчик определяет требования проекта, оплачивает работы и получает готовый продукт, за что надеется получить определенную (экономическую) выгоду.
Изменение
Изменение – это трансформация одного из пяти параметров проекта (см. Параметры проекта). Изменение проекта всегда должно быть следствием осознанного выбора, а не случайным результатом каких-то действий.
Каталог требований/спецификация
Документ, содержащий набор требований, которым должен удовлетворять проект.
Контрольная точка