– Первое определение утверждает, что проект – предприятие с определенными датами начала и завершения, предпринятое для создания продукта или услуги (сервиса) в соответствии с заданными ресурсами и требованиями (ISO/IEC/IEEE 15288:2008 Systems and software engineering – System life cycle processes).

– Еще одно определение данного понятия из свода знаний PMBOK утверждает, что проект (в управленческой деятельности) – временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

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

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

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

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

– Проект имеет четкие функциональные рамки.

– Проект может потребовать использования рискованных решений.

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

– Для проекта может потребоваться уникальное расположение места реализации.

– Проект имеет ограниченные временные рамки. После завершения не продолжается.

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

1.2. Почему управление проектами?

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

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

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

Далее собрал в список основные причины распространения проектного управления:

1. Сокращение жизненного цикла товаров.

2. Усиление конкуренции.

3. Рост неопределенности внешней среды.

4. Стремительное развитие технологий.

5. Возросшие требования потребителей.

6. Сокращение расходов.

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

1.3. Проектная команда и ее варианты

Как мы помним, проект – это деятельность, значит управление проектом это управление теми, кто ведет эту деятельность, если упрощенно излагать суть.

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

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

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

Далее хочу привести наиболее интересные варианты команды (без учета специалистов внутри команд):

– Вариант 1. Проектная команда только из штатных (in-house) сотрудников;

– Вариант 2. Проектная команда из штатных сотрудников, включая распределенных по разным офисам и/или удаленный штат (работающие из дома);

– Вариант 3. Проектная команда из группы штатных + команда аутстаффер;

– Вариант 4. Проектная команда из группы штатных + команда/-ы на аутсорсе (им передают части, а приемку осуществляют внутренние специалисты).

Варианты 1 и 2 понятные и пояснять их не буду. А вот варианты 3 и 4 более интересные, потому что, когда есть потребности/проекты, подключаешь дополнительные ресурсы, а когда нет их, то просто не подключаешь и нет затрат на них.

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

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

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

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

1. Состав «Упрощенный»

– Руководитель проекта.

– Программисты (FronEnd/BackEnd или Fullstack/Mobile).

– Дизайнер.

– Аккаунт-менеджер.

2. Состав «Классический»

– Руководитель проекта.

– Технический лидер.

– Программисты (FronEnd/BackEnd/Fullstack/Mobile).

– Дизайнер.

– Аккаунт-менеджер.

– Аналитик.

3. Состав «Классический +»

– Руководитель проекта.

– Технический лидер (иногда добавляют системного архитектора или один совмещает две роли).

– Программисты (FronEnd/BackEnd/Fullstack/Mobile).

– Дизайнер.

– Специалист по продажам.

– Аналитик.

– Специалист внедрения и сопровождения.

– Поддержка.

4. Состав «Расширенный»

– Руководитель отдела разработки или Технический директор.

– Руководитель проекта (часто в таком составе РП находится в подчинении руководителя отдела или CTO).

– Системный архитектор.

– Тимлид/-ы.

– Программисты (FronEnd/BackEnd/Fullstack/Mobile).

– Дизайнер/-ы и/или Дизайнеры UI/UX.

– Специалист/-ы по продажам.

– Аналитик/-и.

– DevOps-инженер/-ы (не всегда).

– Контент-менеджер/-ы.

– Специалист/-ы внедрения и сопровождения.

– Поддержка.

Замечу:

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

1.4. Руководитель проекта. Кто такой? Какие у него обязанности?

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

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

Руководители проектов часто могут удвоить отдачу от инвестиций организации, используя проектное управление и сведя к минимуму используемые ресурсы за счет повышения эффективности каждого сотрудника. Можно уменьшить число исполнителей на проекте за счет систематизации работы оставшейся команды, применения других мер или принятия решения о том, что новые задачи не берутся в работу (конечно, их можно принимать, систематизировать, а потом вернуться к их обсуждению с заказчиком, и принять решение о реализации или закрытии задач), доделывается текущий функционал для выпуска проекта. Таким образом можно запустить проект, пусть и с ограниченным функционалом, чтобы продукт начал выполнять свои функции и приносить результат заказчику. Например, я сталкивался со случаем, когда в отделе разработки ПО одной компании работало 50 человек, проекты были просрочены (честно говоря «проваливались») как минимум на 50% по времени, качество было низкое, клиенты, как следствие, недовольны. В результате разбора было выявлено, что отсутствовало: проектное планирование работ; подбор проектной команды под проект; контроль работы специалистов; контроль потока задач от заказчиков. За счет введения проектного управления и перечисленных ранее пунктов, получилось вернуть проекты в прогнозируемые сроки, максимально увеличить эффективность работы специалистов, а это в свою очередь дало возможность уменьшить количество человек в проектных командах и перераспределить их между другими проектами. Все это привело к улучшению финансовых показателей проекта и компании.

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

1. Снижение стоимости и сокращение сроков создания новых продуктов (включая и внутренние цели, например, внедрение новой IT-системы).

2. Повышение качества новых продуктов (результатов) и эффективности.

3. Повышение прозрачности процесса создания новых продуктов.

4. Минимизация отклонения по срокам.

5. Повышение удовлетворенности владельцев, инвесторов, повышение мотивации персонала.

6. Усиление конкурентной позиции компании.

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

1.5. Четыре этапа управления проектом

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

Вообще, в жизненном цикле проекта выделяют пять этапов управления проектом:

– инициация;

– планирование;

– исполнение (выполнение);

– мониторинг;

– закрытие (завершение).

Вы явно зададите вопросы – «Как пять?!», «Разве в названии не четыре указано?!». И будете правы, но ошибки тут нет, я рассматриваю исполнение и мониторинг, как неразрывно связанные процессы одного этапа – «Исполнение». Данное взаимодействие я изобразил на рисунке 1. Приведу пример, поясняющий суть мысли. Невозможно приготовить сложное блюдо, всего лишь один раз взглянув на рецепт. Вы постоянно будете заглядывать в него и сверяться, в какой последовательности и какие ингредиенты добавлять, сколько готовить, какая температура должна быть и так далее.

Вы будете очень внимательны во время приготовления, чтобы получилось указанное в рецепте блюдо. Получается это будет проектом, блюдо – это продукт, а контроль времени приготовления, объема ингредиентов, последовательности добавления будут составляющими этапа «Мониторинг», который невозможно отделить от приготовления – «Исполнения». Работа над любым другим проектом идет примерно также. Конечно, это упрощенный пример, в проектной деятельности руководителю проектов придется контролировать как минимум:

– Соблюдение сроков.