Роль заказчика в проекте (роль руководителя)

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

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

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

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

В некоторых методологиях управления проектами (например, scrum) заказчика называют «владельцем продукта проекта». Мне нравится такое определение, потому что во многом оно отражает суть этой роли. Владелец продукта – это человек, который будет использовать продукт проекта в своих целях. А значит, он заинтересован в получении продукта проекта в срок, в бюджет, в соответствии с требованиями. Можно предположить, что владелец проекта будет всячески помогать руководителю проекта. Но происходит ли так на самом деле?

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

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

По данным Standish Group, на каждую $ 1000 стоимости времени людей в проекте приходится принимать 1.5 решения. Проект в миллион долларов будет иметь 1500 решений, в то время как $ 10 млн. проект будет иметь 15000 решений. Владелец продукта должен принять участие в 20% из этих решений.

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

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

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

Если во внутренних проектах (когда заказчик и команда проекта работают в одной компании) не получается найти человека, который способен выполнять функции владельца продукта, я бы посоветовал сто раз подумать, стоит ли стартовать. Проект, в котором нет заинтересованного заказчика практически обречен на попадание в когорту неудачных. Но если стартовать проект очень нужно, а подходящего заказчика пока нет – сделайте заказчиком самого заинтересованного в продукте проекта человека и отправьте его на курсы по scrum, где ему объяснят, чем должен заниматься product owner и какие методы ему использовать в своей работе.

Список литературы:

• 1. МИХНЕНКО П.А. «ТЕОРИЯ МЕНЕДЖМЕНТА»
  2. http://upr.ru/article/rossiyskie-praktiki-upravleniya/ROL__BIZNES_ZAKAZCHIKA_V_IT_PROEKTE.html
  3. https://infostart.ru/public/895027/
  4. https://books.google.ru/books?id=7pTcDwAAQBAJ&pg=PA606&lpg=PA606&dq=%D1%82%D0%B5%D0%BE%D1%80%D0%B8%D1%8F+%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%BC%D0%B5%D0%BD%D1%82%D0%B0+%D1%80%D0%BE%D0%BB%D0%B8+%D0%B7%D0%B0%D0%BA%D0%B0%D0%B7%D1%87%D0%B8%D0%BA%D0%B0&source=bl&ots=qXHtlgOx_o&sig=ACfU3U0sj4OB90OuMDFhDLCLujM_MMSurg&hl=ru&sa=X&ved=2ahUKEwiKoMfIy-LpAhWJfZoKHW__DagQ6AEwCXoECAoQAQ#v=onepage&q=%D1%82%D0%B5%D0%BE%D1%80%D0%B8%D1%8F%20%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%20%D1%80%D0%BE%D0%BB%D0%B8%20%D0%B7%D0%B0%D0%BA%D0%B0%D0%B7%D1%87%D0%B8%D0%BA%D0%B0&f=false