ИСПОЛНЕНИЕ ПРОЕКТА

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

ХОСЕ: В конце 2006 года я присоединился к высокотехнологичной компании, став руководителем отдела разработки возможностей учета продукта «Программа как услуга» (SaaS), который компания хотела запустить к середине 2007 года, то есть через девять месяцев. Одновременно компания пыталась освоить приобретение, которое она сделала год назад, и столкнулась с серьезным вызовом — проблемой совмещения с системой Oracle ERP. Прошел год после покупки, совмещения систем ERP так и не произошло, и руководство IT вынуждено было сфокусироваться на этой задаче.

РЭНДИ: Почему это стало приоритетом?

ХОСЕ: Было сложно разобраться со счетами. Приобретенная компания оказалась почти такой же большой, как та, что ее купила. К тому же рынок акций не радовал. Так что CEO требовал решить эту задачу. Невозможность совмещения с системами ERP означала, что бухгалтерии приходилось работать вручную, что влияло на эффективность работы всей организации. Поэтому все остальные проекты, включая мой, отложили на неопределенный срок. Однако дата запуска продукта SaaS оставалась прежней — май 2007-го!

Когда я изучал, как ускорить проект, потому что нам следовало двигаться вперед, я разобрался в методах Agile (например, Scrum, XP), которые позволяют создать продукт (обычно программное обеспечение) куда быстрее, чем каскадный метод. Если вы не в курсе, при каскадной модели все фазы разработки должны проходить последовательно. Анализ требований, проектирование, реализация и так далее. Agile же фокусируется на том, чтобы создать ценность (продукт) в очень короткие отрезки времени, от двух до четырех недель.

Я забросил идею использования Agile в комитет управленческого анализа, вице-президентам из IT и заказчику. Поскольку компания потратила немало времени и ресурсов на то, чтобы разработать собственную каскадную методологию, я услышал предсказуемый ответ: «Вы будете использовать нашу [каскадную] методологию!» Что мне было делать? Часики тикали, а наш проект все еще откладывали.

РЭНДИ: Какие факторы заставляли откладывать проект?

ХОСЕ: Необходимость сосредоточить ресурсы IT на совмещении систем с Oracle ERP. Ситуация авральная, все ресурсы IT уходили на Oracle ERP… но запуск все равно был назначен на май 2007 года.

Я вспомнил подход, который создала компания Intel, чтобы более эффективно и быстро разрабатывать их полупроводниковые продукты. Он описан Тимом Эске в книге No Surprises Project Management (1999). Его суть в том, чтобы отдельные работники выполняли работу и брали на себя обязательства о сроках ее сдачи. Этот метод стимулирует общение между членами команды и одновременно помогает предупреждать возникновение проблем. План разрабатывается в группе на встречах, которые называются «днем карты», потому что план выглядит именно так. Производительность отслеживается с помощью простых инструментов (таблица Excel). Если это сработало у Intel, то, подумал я, этот метод можно использовать и в моем проекте разработки. Что мне терять? Традиционное планирование и управление проектом гарантировали, что он будет исполнен слишком поздно, и осложняли общение с клиентом.

РЭНДИ: Не могли бы вы подробнее рассказать о том, как преодолели сопротивление руководства? Какие шаги предпринимали? У вас был сторонник или спонсор, который вас поддерживал? Как вы поступали? Вы двигались вперед вопреки мнению руководства или в соответствии с ним?

ХОСЕ: Я взял риск на себя, поставив моего непосредственного начальника в известность о том, что собираюсь использовать новый подход. Разрешения не спрашивал, хотя и проинформировал руководство о дне планирования, и многие пришли на него, чтобы запустить проект.

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

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

РЭНДИ: Какой была реакция на эти новости? Как вы отвечали на вопросы по поводу задержки?

ХОСЕ: К этому моменту команда клиента столкнулась с собственными задержками, и они были готовы принять эти перемены. Это оказалось проще, чем я думал, потому что основные представители клиента очень разумно отнеслись к ситуации. В противном случае вышла бы некрасивая история. Планирование завершили в один день. Как позже сказал мне один из главных участников, наш подход свел в один день то, что, как правило, занимает два месяца работы.

Этот подход использует схему Agile, которую сегодня иногда называют Commitment-Based Project Management (менеджмент проектов, основанный на обязательствах), или CBPM, поверх традиционной методологии разработки программного обеспечения. Помимо общего планирования еженедельно проверяется статус проекта, уровень результативности, оценивается, что сделано, а что задерживается, и все, что не вошло в расписание. К обязанностям подходят гибко, и человека, который приносит дурные вести, никогда не казнят. Мы поощряем сотрудников как можно раньше сообщать о проблемах. И одновременно все еще можем использовать каскадный метод и выполнить все его требования.

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

РЭНДИ: Пришлось ли вам приложить дополнительные усилия, чтобы предать гласности свой успех? Стали ли эти результаты прецедентом? Изменили ли они подход к работе?

ХОСЕ: Успех команды оценили по достоинству, и наш подход признали заслуживающим внимания. Как сказал один участник, кризисов не было, и программа работала как хорошо смазанный часовой механизм. Успех привел к запросам на внутреннее обучение этому подходу.

РЭНДИ: Вы можете рассказать о том, какие мотивы привели вас к тому, что вы стали специалистом по пропаганде информационных технологий?

ХОСЕ: Мне приходили запросы на помощь другим командам и обучение их подходу, который я поддерживал. С тех пор я использовал этот подход в разных сферах. С клиентом из обороны мы приложили его к развитию системы контроля третьей ступени (программное обеспечение и оборудование) ракеты комплекса ПВО. С крупным университетом — к развитию дозиметра радиации, который применяется при крупных ядерных катастрофах. В обоих случаях подход соответствовал методологии развития продукта, приводя к лучшей производительности команды.

Благодаря всем этим успехам и опыту обучения такому подходу в моей компании я начал проводить семинары о том, как планировать и исполнять проекты, используя CBPM. Я автоматизировал процесс отслеживания производительности с помощью Excel и сделал этот инструмент доступным тем, кто посещает мои мастер-классы, а также иным заинтересованным лицам. Благодаря этим мастер-классам, а также мастер-классам Тима Эске и других многие менеджеры проектов смогли успешно применить этот подход.