что такое процессы проекта

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

Главная страница » Блог » Основное отличие процесса от проекта

Основное отличие процесса от проекта

«Нам не нужен процессный подход, мы управляем проектами». Именно такое заявление мне однажды довелось услышать. Аккуратную попытку объяснить, что процессное управление касается в том числе проектов, прервали на полуслове. Но в чем основное отличие процесса от проекта?

О том, что такое бизнес процесс, мы уже говорили. Но что такое проект?

Отличие процесса от проекта

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

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

Теперь давайте обратим внимание на разницу.

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

Вроде бы все понятно. Так? Так, но хочу вас немного запутать двумя утверждениями:

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

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

Проект сосредоточен на получении результата как такового. Нам важно получить в итоге продукт. При этом мы не можем четко сказать, какие характеристики будет иметь полученный продукт и сколько мы потратим на проект. Проект отвечает на вопрос «ЧТО?»

Когда мы говорим о процессе, продукт нам уже известен. Важнее оказывается метод его получения. Снижение затрат на производство при заданных характеристиках продукта возможно только при рассмотрении хода процесса. Процесс концентрируется на вопросе «КАК?»

В итоге. То, что мы делаем впервые, является проектом. То, что мы делаем постоянно — процесс. Переезд в новый дом — проект. Уборка квартиры — процесс.

Источник

Управление проектами

Процессы управления проектами

Общепринятым на современном этапе подходом к управлению проектами является процессный подход.

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

1. Процессы управления проектами

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

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

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

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

Наложение групп процессов в фазе.

Процессы управления проектами накладываются друг на друга и происходят с разными интенсивностями на всех стадиях проекта, как проиллюстрировано на рисунке.

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

В реальном проекте фазы могут не только предшествовать друг другу, но и накладываться.

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

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

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

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

Напомним, что следует различать цели проекта и цели продукта проекта, под которым понимается продукция (или услуги), созданная или произведенная в результате исполнения проекта.

Цели продукта— это свойства и функции, которыми должна обладать продукция проекта.

Основные процессы планирования

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

Вспомогательные процессы планирования

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

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

Процессы исполнения и контроля

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

Как и в планировании, процессы исполнения можно подразделить на основные и вспомогательные.

К основным можно отнести сам процесс исполнения плана проекта.

Среди вспомогательных процессов отметим:

Процессы анализа включают как анализ плана, так и анализ исполнения проекта.

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

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

Процессы анализа также можно подразделить на основные и вспомогательные.

К основным относятся те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта:

Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:

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

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

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

К основным процессам управления, встречающимся практически в каждом проекте, относятся:

Среди вспомогательных процессов управления отметим:

Завершение проекта сопровождается следующими процессами:

Источник

Сила процессов в проектном менеджменте

Всем привет. Меня зовут Даша Викторова, я Project Lead направления автоматизации доставки в Lamoda. Сегодня поговорим про проектный менеджмент… Но не совсем 🙂

Как правило, проджект-менеджер (или просто PM) отвечает за реализацию проектов — как ни странно! Однако любой проект состоит не только из задач, которые ведут к достижению конечной цели, но и из процессов, от которых зависит качество и скорость их достижения.

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

Сущности, с которыми работает PM

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

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

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

Процессы в проектном менеджменте

Что же такое процессы в Project Management? Ответ очень прост — это любой шаг, который мы предпринимаем для решения той или иной задачи. И все эти шаги можно и нужно описывать и регламентировать. Для кого-то может звучать неожиданно, что процесс, в котором человек работает каждый день, можно описать, а не просто «договориться на словах», но именно такой подход позволяет процессу жить, а всем участникам — соблюдать его.

Давайте разберем на примерах.

Каждое утро у вас есть стендап с командой. Он длится 15–20 минут, где все участники кратко рассказывают, что делали вчера и что собираются делать сегодня. Это кажется абсолютно обыденным действием, но на самом деле это самый что ни на есть процесс: он был построен кем-то из менеджеров или тимлидов этой команды, его правила были оговорены с участниками, его проведение было регламентировано и самое главное — его соблюдают.

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

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

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

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

Теперь разберемся, как это делать.

С чего начинать изменение процесса

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

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

разработчики уделяют ревью недостаточно времени;

разработчики не успевают проводить ревью;

на доске слишком маленькое ограничение на колонку ревью;

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

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

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

Итак, попробуем подойти к ситуации с разных сторон. Есть выявленная проблема — ревью тормозит реализацию задач. Следующий вопрос, который поможет вам определиться с действиями: «А как оно должно вообще работать сейчас? Как и почему оно работало раньше?» — типичное AS IS. Возможно, разработчики просто действуют вразнобой, потому что не понимают, как это надо делать «по ГОСТу». Так мы выявили одно из действий, которое предстоит предпринять в починке процесса — создать документацию по процессу.

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

Проработка вариантов решения проблемы

Итак, у нас есть документация, которая регулярно обновляется. Разработчики ее читали и даже стараются соблюдать — что тогда? Возвращаемся к началу и смотрим на другие возможные причины и прорабатываем гипотезы. Рано или поздно вы нащупаете root cause (то есть истинную причину возникшей проблемы) и тогда останется дело за малым.

Я предлагаю использовать продуктовый подход: просто отнеситесь к процессу как к продукту.

Проблему мы определили, гипотезы накидали и даже поняли, в какой из них вероятнее всего скрывается root cause. Теперь нужно понять, кто же потребители этого продукта (то есть — проблемы)? Иными словами, определяем ЦА. Важно учесть всех участников процесса, потому что для каждой группы нужно найти свое решение — такой же подход используется с b2b и b2c-продуктами. Проведите исследование и узнайте про аналогичные процессы у коллег: посмотрите, как они работают у них, с какими проблемами сталкивались команды и как их решали.

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

Нашли проблему, выбрали решение — что дальше?

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

Но не забывайте и про внедрение процесса. Все молодцы, проделали огромную работу, нашли проблему, продумали решение и устранили ее… А устранили ли?

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

Итак, время подводить итоги

К изменению процесса стоит подходить так же, как и к любому проекту или продукту. Для успешной реализации нужно проходить точно такие же шаги: создание BRD (AS IS и TO BE), выявление проблемы, проработка решения, аналитика и декомпозиция, внедрение и постподдержка.

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

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

Полезные материалы

Джефф Сазерленд «Scrum. Революционный метод управления проектами»

Михаил Рыбаков «Бизнес-процессы: как их описать, отладить и внедрить»

Источник

Процессы управления проектами: основные этапы, стандарты, инструменты

«Хочу завоевать мир» — звучит несерьезно и по-детски. «Проект захвата мира» — уже круче, да ведь? 🙂

Редакция Yagla решила разобраться, что делать, чтобы это не только звучало круто, но и выглядело так же на деле, и вообще чтобы всё получилось. Подробный план действий нам рассказал Юрий Волщуков — руководитель проектов по автоматизации с двадцатилетним опытом, автор книги «Успешный руководитель проекта».

Процессы управления проектами

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

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

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

Также признаком проекта является ограничение по срокам и по бюджету.

Снова на примере строительства: неважно, десять домов или два нужно построить в рамках проекта — когда-то он закончится. А вот если строительная корпорация постоянно что-то строит, то ее работа — не проект, а операционная деятельность: по поиску клиентов, запуску проектирования, строительству, сдаче объектов. Одно здание или жилой комплекс будут проектами, а общая деятельность организации — нет.

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

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

Что такое управление проектом

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

Например, вы за рулем автомобиля едете из точки А, чтобы достичь результата — доехать в точку Б: это деятельность. Увидели яму на дороге — повернули руль и объехали её — это управление: вы активно повлияли на процесс. Едете дальше — видите, что мост через реку разрушен или закрыт для проезда. В зависимости от ситуации вы будете принимать решение: либо искать объезд, либо переезжать реку вброд, что тоже будет активным влиянием на процесс.

Отмечу, что управлять людьми нельзя: вряд ли вы будете совершать какие-то непосредственные активные действия по отношению к ним с целью заставить их что-то делать. А вот организовать на исполнение чего-то — можно. Сложность «управления» с людьми заключается в том, что они говорят, делают, и думают по-разному. Тот, кто управляет процессом, должен слышать, что ему говорят, видеть, что на самом деле человек делает, и обладая определенным кругозором и умением проанализировать ситуацию, понять менталитет человека, что он за личность, его поведенческую модель и заранее предположить, куда он будет двигаться. Часть людей так поступают не специально, а часть пытаются таким образом влиять на процессы.

Если руководитель проекта не оказывает активного влияния на процессы, значит, он не не управляет.

Роли в проекте

Следует различать три основные группы ролей:

Участники проекта

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

Группа управления проектом

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

Группа реализации проекта

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

Необходимые компетенции для управления проектами

Организационно-управленческие навыки

Организационные навыки — это администрирование, о котором говорили выше.

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

Например, у писателя стоит задача — написать 25 страниц материала за неделю. В понедельник он написал 4 страницы — просадка примерно на полтора часа от общего времени. Если поработать сверхурочно по 25 минут в оставшиеся дни или просто ускориться — можно успеть к сроку. Но если изо дня в день продолжать писать по 4 страницы, к концу недели просадка будет на 5 страниц материала, а это уже критично: за пару часов ситуацию не исправить. Если заранее отследить назревающую проблему и пересогласовать сроки или делегировать часть материала еще одному человеку, развитие ситуации будет благополучнее.

Юридические знания

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

Задачи и цели проектного менеджмента

Зачем управлять проектами

Проведем аналогию: а что будет, если сидеть за рулем автомобиля и не управлять им? Рано или поздно произойдет ДТП. Однозначно, как говорили в начале — нужно ваше активное воздействие.

Разница между стандартами и методологиями

Проектный менеджмент строится на комбинации стандартов и методологий.

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

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

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

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

Группы процессов

Выделяют следующие группы процессов управления проектами:

Инициация

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

Планирование

Проектный менеджмент невозможен без планирования.

Процесс планирования делится на три этапа:

Этап базового планирования — определение состава работ и фаз проекта.

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

Итог планирования — детализированный план-график выполнения работ с привязанными к ним исполнителями и датами завершения. На его основании формируются ресурсный план и бюджетный план исполнения проекта.

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

Исполнение и контроль

Исполнение — это запланированные работы, которые выполняются в настоящий момент.

Контроль — это процесс проверки с целью соответствия планируемого и фактического. Но важно понимать, что можно проверить только результат, а не процесс.

Например, я вижу, что рабочий копает яму и знаю, что перед ним стоит цель копать. Это хорошо, но что это мне дает? Сколько он должен был выкопать? Он вчера должен был закончить или позавчера? Это результат, который реально проверить. Он копает яму такого-то глубины, длины, ширины и должен выкопать её за три дня.

Анализ

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

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

Управление

Самые важные стадии процесса управления проектами:

Завершение

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

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

Стадии планирования управления проектами

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

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

Соответственно, действия по управлению должны строиться так:

Взаимосвязи процессов

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

Какие проблемы могут возникнуть в процессе исполнения проекта

Есть две основные причины проблем в проектах:

1. Со стороны заказчика: «Это не то, что мы хотели».

2. Со стороны исполнителя: «Мы выполнили в разы больше работы».

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

Для профилактики второй ситуации определяйте взаимосвязи в проекте: какая цель перед нами стоит, кто за что отвечает, кто с кем договаривается, когда должен быть результат действий, и на основании этого анализируйте, вписываетесь вы в свои ожидания или нет. Когда оцениваете бюджет, объем работ и сроки — перестраховывайтесь и закладывайте 10-15% ресурсов на переработки.

Чем отличаются цель проекта и цель конечного продукта проекта

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

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

Инструменты проектного менеджмента

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

Онлайн-сервисы максимально к этому приближены, поэтому используйте Google Диск или Яндекс.Диск для обмена документами и другой информацией.

Если планируете расширяться, то рекомендую Confluence — это отличная система для выстраивания командной работы.

Источник