PRO Определение «Проект»

Я работаю в IT-компании, в проекте по выпуску высокотехнологичных защитных продуктов для сегментов B2C и B2B. За последние несколько лет было проведено большое количество различных интервью на роль Системного аналитика. Основные принципы, которыми мы руководствуемся в принятии решения о найме, являются желание и возможности кандидата выполнять поставляемые задачи в текущих организационных и проектных средах, т.е. интервьюверам важно ответить на вопросы, а что соискатель хочет и может делать нужного, важного и полезного для успешной реализации продуктов нашего проекта. Относительно роли Системного аналитика - это управление содержанием работ по реализации поставленных требований.

В результате полученного опыта я пришёл к выводу, что зачастую кандидаты, приходящие на интервью, не всегда осознают ценность той или иной роли в проектной команде. Из-за недостаточного понимания ценности роли, будь-то Системный аналитик, Разработчик, Инженер по тестированию, Devops или другой, появляется (прим.: на мой субъективный взгляд!) ошибочное осознание проектной деятельности, и зачем вообще всё это нужно (~~главное, чтобы деньги платили~~).

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

Поехали

Продукты, услуги и/или конечные результаты делаются людьми и для людей. Стандарты (PMI, Prince2, RUP), подходы (Agile), методы (или методологии, такие как KANBAN) и фреймворки (Scrum) нужны для того, чтобы повысить вероятность успешного достижения, т.е. реализации, конечного результата. В любой деятельности, где присутствует команда (это группа людей, объединенные единой целью, которую невозможно или тяжело достичь по одиночке), члены такой команды должны знать как и уметь коммуницировать друг с другом на одном языке. Также, не менее важно обладать навыком корректного, четкого и, желательно, краткого изложения своих мыслей. Именно поэтому необходимо получить осознание ценности роли каждого участника проектной команды, а это хорошо бы сделать через понимание, а что же такое проект.

Немного истории

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

В середине 20го века случилась Холодная война между двумя противоборствующими блоками, где каждый блок хотел быть впереди другого. Темп жизни развитых стран стал стремительно набирать обороты, а это также потребовало изобретения новых гарантированных и быстрых способов для достижения поставленных целей. Первыми, кто задумался о необходимости стандартизации процесса реализации проектов, стали армейские структуры США. Таким образом, в 1975 году был создан Институт проектного управления PMI (https://pmi.org), который до сих пор выпускает "Библию" руководителей проектов - PMBoK (Project Managment Body of Knoweledge, читается как "ПМБуК").

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

IT-проекты.
Строительные проекты.
Научные проекты.

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

Опыт применения проектного подхода в армии оказался удачным. Проекты стали реализовываться масштабнее, качественнее, быстрее и без задержек. Правительства разных стран не могли не заметить такие успехи, таким образом в 1989 году в Англии был создан стандарт PRINCE2. Этот стандарт используется до сих пор, является MUST HAVE знанием для работы в правительственных структурах Великобритании. Если сравнивать PRINCE2 и PMBoK, то можно заметить принципиальное сходство стандартов.

В 1996 году проекты, реализуемые в крупных корпорациях (прим.: в основном IT), стали действительно масштабными. Это потребовало применения своих методов для увеличения вероятности успешной реализации продуктов. На свет появилась методология RUP (см. https://ru.wikipedia.org/wiki/Rational_Unified_Process). Если внимательно присмотреться к доменам данной методологии, то налицо сходство с PMBoK (прим.: редакции 6).

Получилась эволюция знаний об управлении проектами: Армия > Правительство > Корпорации. Небольшие IT-компании не могли позволить себе применения тяжелых, формальных подходов для разработки, и в 2001 году по инициативе снизу появился Agile. Это реакция от инженеров к руководству, как наиболее эффективно осуществлять разработку программного обеспечения (вообще, Agile - это образ мыслей, который соответствует здравому смыслу).

Определения проекта

В большинстве случаев проекты начинаются с идеи (вида "А давайте сделаем X"). Обдумывание идеи - это процесс принятия решения о необходимости применения подхода, метода, фреймворка или же регулярного менеджмента для реализации. По факту, нужно определить, а проект ли перед нами или нет? Что ответить на этот вопрос нужно определение проекта:

Определение проекта

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

Полученное определение лаконично, точно, конкретно и, в какой-то мере, красиво:

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

PMBoK6 предоставляет следующие описание термина Проект: "Временное мероприятие направленное на создание уникального продукта, услуги или результата". По моему мнению, данное определение неудачное, т.к. в нем отсутствуют ключевые характеристики проекта, приходится додумывать.
Также, в PMBoK6 (прим.: в PMBoK 7, Standards+) указаны следующие проектные ограничения (их 7): содержание, ресурсы, сроки, стоимость, качество, удовлетворение заинтересованных сторон, риски. Суть ограничений не поменялось (содержание, заинтересованные стороны и качество - это старое содержание, т.е. удовлетворение требованиям, стоимость и ресурсы - это старая стоимость), но добавились риски. Как можно попасть / не попасть в риски, как ограничения проекта, мне непонятно.

Группа людей и Совокупная деятельность - проект реализуется людьми и для людей.

Группа людей - это команда проекта. Команда проекта выполняет операции проекта.
Совокупная деятельность - это процесс выстраивания взаимоотношений и зависимостей между членами команды. Кстати, именно это понимается под термином "командообразование" (teambuilding), а не очередная пьянка всем составом.

Определение конечного результата проекта

Проект предпринимается для достижения конечного результата, а это:

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

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

Парочка дополнительных полезностей

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

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

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

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

Ценность роли

Если ценности роли Руководителя проекта очевидна из определения, то как же осознать роль другим участникам? Что же означает для человека - быть активным лоббистом своего дела, работы и проекта в целом?

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

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

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

ПРОЕКТНЫЙ КЛУБ

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

Клуб доступен тут: https://pmi.moscow

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

Если интересно управление проектами, есть вопросы или есть что сказать - присоединяйтесь!