Организация и управление проектом при заказе разработки

Юрий Гончаров, директор по проектам, ЗАО «КОМПЭЛ»

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

Версия в PDF (43Kb)

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

Растущий рынок заказных разработок имеет ряд особенностей, которые не всегда учитываются, и зачастую — новыми участниками рынка. В результате возникает ряд актуальных проблем, из-за которых:

— около 55% разработок не исполняются в намеченный срок;

— около 45% не укладываются в бюджет;

— около 40% не достигают запланированной себестоимости продукции;

— до производства не доходят более 40% разработок.

Соблюдение нескольких основных принципов позволит минимизировать риски при заказе разработки и обеспечить получение требуемого результата в заданный срок.

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

— Заказчик проекта санкционирует выделение финансовых ресурсов (в зарубежной литературе часто именуется «спонсор проекта»).

— Менеджер проекта — лидер, координирующий усилия участников проекта и распределяющий финансовые ресурсы. Он отвечает за выполнение проекта в заданные сроки и с требуемым качеством. Менеджер обеспечивает постановку задачи, намечает основные пути и сроки ее выполнения.

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

Заказчиков разработки также можно разделить на следующие три группы.

1. Продавец готовых изделий, не имеющий собственных разработчиков.

2. Компания, не имеющая собственных разработчиков требуемого профиля.

3. Компания, которой не хватает собственных ресурсов для выполнения разработки в срок.

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

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

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

Фактически приведенные выше варианты развиваются по двум сценариям: у заказчика нет инженера проекта и у заказчика есть свой инженер проекта. В любом сценарии взаимодействие выходит за пределы одной организации, поэтому очень важно обеспечить информационный интерфейс. Заказчик не знает стандартов предприятия-разработчика и особенностей его документооборота, но в итоге хочет получить описание всех процессов. В этом случае заказчик лучше понимает, что он получит в конце работы, а подрядчик — как он должен отчитываться перед заказчиком.

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

— требования к конкретной разработке;

— требования, связанные с особенностями области применения;

— требования стандартов и законов страны, где будет продаваться устройство;

— требования производства.

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

Существуют методики, позволяющие описать любое изделие без понимания технической стороны вопроса, например в виде последовательностей «воздействие — реакция».

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

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

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

Вернемся к сценариям работы.

1. Заказчик проекта назначает менеджера проекта.

2. Менеджер проекта определяет его участников и создает координационный комитет, в состав которого входят следующие сотрудники:

— менеджеры проекта заказчика;

— инженер (инженеры) проекта заказчика и подрядчика;

— функциональные лидеры подразделений заказчика;

— начальник планово-финансового отдела.

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

Существует два вида проектов:

— с фиксированным временем выполнения;

— с фиксированными ресурсами.

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

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

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

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

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

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

В последнем случае координационный комитет состоит из менеджера проекта заказчика, инженера проекта заказчика, инженера проекта разработчика и инженера проекта производственника.

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

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

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

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

— четко определенные и понятные цели проекта;

— реальный план и сроки проекта;

— разумные и приемлемые правила работы.

Следование этим принципам — залог успеха.