Этапы организации руководства проектами

Кадр: фильм «Тринадцать друзей Оушена» / Warner Bros. Pictures

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

Руководитель проектов цифровой трансформации. Эксперт в области управления цифровыми и индустриальными инвестиционными проектами на территории СНГ и в Европе с 17-летним опытом. Слушатель программы MBA «Лидеры изменений». Email: aiparamonov@mail.ru

---

Фото: личный архив Александра Парамонова

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

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

Поэтому разбираться в том, как управлять проектами, должен любой менеджер и собственник бизнеса. В статье для Skillbox Media рассказываем:

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

---

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

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

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

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

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

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

Вот примеры проектов, выполнение которых стало вопросом выживания для некоторых видов бизнеса в последнее время:

• организация гибридного формата работы сотрудников;
• перестройка и локализация цепочек поставки;
• цифровая трансформация.

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

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

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

Этапы управления проектом соответствуют этапам его жизненного цикла. Согласно PMBok, они включают в себя:

• инициацию;
• планирование;
• исполнение;
• управление и контроль;
• завершение.

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

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

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

Исполнение. Этот этап предполагает выполнение проекта и коммуникацию с заказчиком и командой.

Управление и контроль. Мониторинг баланса проекта по факторам времени, бюджета и качества. Подробнее о таком балансе говорили в этой статье.

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

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

Методы управления проектами — системы принципов, инструментов и процедур, которые используют менеджеры.

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

В этой статье поговорим о методах Agile и Waterfall. Современный менеджер проекта должен владеть и тем, и другим.

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

Эту модель применяют в таких случаях:

• Требования к проекту тщательно продуманы и неизменны.
• Технологии выполнения проекта известны заранее.
• Приоритет проекта — высокое качество продукта.
• Заказчик не может участвовать в процессах проекта. Это характерно для проектов на аутсорсинге, где заказчик получает финальный готовый результат.
• Заказчику в самом начале важно знать точные сроки и бюджет проекта.
• Исполнитель реализовывал аналогичный проект ранее. Например, в строительстве типовых объектов или в разработке программ с использованием «коробочного» решения.

Agile (гибкая методология разработки). Это группа методологий гибкого управления проектами. К ним относятся Scrum, Kanban, XP и другие. В их основе лежит четыре принципа:

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

Методы Agile применяют в таких случаях:

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

Выбор метода зависит от специфики проекта. Например, в строительстве и сложных инженерных проектах agile-методологии почти не применяются. Для них больше подходит метод Waterfall. А вот в разработке программного обеспечения и цифровизации всё наоборот.

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

• простая упорядоченная среда;
• сложная упорядоченная среда;
• запутанная среда;
• хаотичная среда;
• беспорядочная среда.

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

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

Об инструментах управления проектами можно почитать в этой статье Skillbox Media.

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

Квалификация менеджеров проекта. Главное требование — базовые знания по управлению проектами. Их можно получить из PMBoK — это самая распространённая модель, которая лежит в основе многих стандартов. Есть и другие стандарты — например, APMBoK или P2M.

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

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

Личностные качества менеджеров проекта. Менеджер проекта — лидерская роль. Поэтому его личность и мотивация важны не менее, чем квалификация.

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

Можно ли управлять проектами без специального образования? Можно. Но велика вероятность, что такой менеджер потратит время впустую. Скорее всего, он начнёт «изобретать велосипед» и в итоге придёт к схожему проектному подходу.

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

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

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

Что ещё нужно знать об управлении проектами? Управлять проектами — это управлять собой. Только через управление собой можно управлять командой и окружением.

В проектах важна психология — результат не всегда предсказуем на 100%. Поэтому нужно уметь правильно реагировать на кризисы и вызовы. Об экологичных способах управления собой и командой можно почитать в этих книгах:

• «Психологическое айкидо» Михаила Литвака;
• «Игры, в которые играют люди» Эрика Берна.

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

• Если вы только начали знакомиться с управлением проектами и разбираетесь в его сущностях, прочитайте нашу статью — «Что такое проект: изучаем главное понятие проектного управления».
• В этой статье Skillbox Media можно узнать о структуре проекта и о том, как проработать её за семь этапов.
• Также в Skillbox Media есть статьи о методиках управления проектами: Scrum, Agile, Kanban, методе критического пути.
• Управлять проектами, работать с бюджетом, сотрудничать с заказчиками, управлять командой и презентовать проекты можно научиться на курсе Skillbox «Профессия Менеджер проектов».

Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше

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

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

Эта пятиступенчатая модель была определена Институтом управления проектами (PMI) в Руководстве PMBOK® по жизненному циклу проектов, которое также известно как «Свод знаний по управлению проектами». Руководство PMBOK® является отличным справочником для всех специалистов, желающих расширить свои знания и навыки в области управления проектами.

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

1. Инициирование проекта

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

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

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

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

• Название компании: Apollo Enterprises

• Название проекта: Руководство по OKR

• Менеджер проекта: Кабир Мадан

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

• Заинтересованные лица. Даниэла Варгас, Кэт Муни, Рэй Брукс.

• Период. С 1 июня по 20 июля 2021 г.

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

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

Читать руководство для начинающих по написанию эффективного экономического обоснования проекта

2. Планирование проекта

На стадии планирования проекта в рамках управления проектами формулируются чёткие цели с помощью дорожной карты проекта. Существует множество способов планирования целей, однако SMART-цели, CLEAR-цели, а также цели и ключевые результаты (OKR) — это три стратегии планирования проектов, которые помогут вам приступить к работе.

Читать о том, как создать план проекта, который будет вести вас правильным курсом

SMART-цели — это аббревиатура, которая расшифровывается как конкретные (Specific), измеримые (Measurable), достижимые (Achievable), реалистичные (Realistic) и ограниченные по времени (Time-bound). Многие коллективы используют этот метод для улучшения обмена информацией между сотрудниками, создания чёткой дорожной карты и формирования отслеживаемых показателей.

Читать о создании эффективных целей по методике SMART, с советами и примерами

Цели CLEAR — это аббревиатура, которая расшифровывается как совместные (Collaborative), ограниченные (Limited), эмоциональные (Emotional), разделяемые (Appreciable) и гибкие (Refinable). Многие команды выбирают этот метод, потому что он более реалистичен для практической реализации и фокусируется на совместной работе.

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

Читать о том, как задавать OKR

Сравнение SMART-целей, CLEAR-целей и OKR:

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

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

Вот пример постановки целей с использованием методологии SMART в управлении проектами.

Исходная цель. Повысить темпы привлечения клиентов.

Улучшенная SMART-цель:

• Конкретная. Повысить темпы привлечения клиентов путём распространения руководства по ресурсам.

• Измеримая. Повысить темпы привлечения клиентов на 15% месяц к месяцу.

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

• Реалистичная. Собирать контактную информацию клиентов в обмен на наше руководство по ресурсам.

• Ограниченная по времени. Ежегодно в январе перевыпускать руководство по ресурсам, чтобы поддерживать темпы привлечения клиентов.

3. Исполнение проекта

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

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

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

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

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

Читать о семи распространённых причинах разрастания объёма и о том, как их избежать

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

Хронология проекта: с 1 июня по 20 июля 2021 г.

Группа проекта: Кабир Мадан, Даниэла Варгас, Кэт Муни, Рэй Брукс

• 1 июня: Кабир создаёт задачи по проекту и назначает их участникам группы.

• 14 июня: Даниэла собирает данные по ресурсам.

• 18 июня: Даниэла организует данные и передаёт Рэю на разработку дизайна.

• 28 июня: Рэй передаёт первый черновой вариант дизайна Кабиру на рассмотрение.

• 1 июля: Кабир предоставляет отзыв по дизайну.

• 6 июля: Рэй передаёт окончательный дизайн Кэт для внедрения.

• 12 июля: Кэт отправляет тестовую страницу Кабиру на рассмотрение.

• 15 июля: Кабир предоставляет отзыв по тестовой странице.

• 19 июля: Кэт передаёт окончательную версию страницы группе для тестирования.

• 20 июля: публикация руководства по ресурсам.

Читать: Пять элементов управления проектами и как их использовать

4. Оценка эффективности проекта

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

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

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

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

Давайте рассмотрим несколько примеров КПЭ.

• Цель проекта: увеличить темпы привлечения новых клиентов на 15% месяц к месяцу

• Фактические затраты: 6487 долларов, исходя из учётного времени работы

• Заработанная стоимость: 47 300 долларов за счёт увеличения темпов привлечения новых клиентов месяц к месяцу

• Рентабельность инвестиций: 40 813 долларов

• Индекс соблюдения сроков (отношение заработанной стоимости к плановой): 0,88

• Стоимость привлечения клиента (отношение затрат к количеству клиентов): 0,61 доллара на клиента

• Темпы привлечения клиентов за месяц: улучшение на 18%

• Трафик сайта за месяц: улучшение на 4%

• Рентабельность: улучшение на 8%

Читать о том, что такое ключевые показатели эффективности (КПЭ)

5. Закрытие проекта

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

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

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

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

Вот пример повестки дня «посмертного» совещания, которая поможет завершить ваш следующий проект.

Название проекта: Руководство по OKR

Дата: 20 августа 2021 г.

Время: 10:00 — 11:00 МСК

Пункты повестки дня:

• Краткий обзор проекта (10:00): Кабир расскажет об исходных целях и задачах проекта и ожидавшихся результатах.

• Обзор результатов (10:15): Кабир проведёт обзор эффективности проекта с упором на исходную цель по увеличению темпов привлечения клиентов и дополнительных важных КПЭ.

• Отзывы заинтересованных лиц (10:30): Кабир, Даниэла, Кэт и Рэй выскажутся о том, что прошло хорошо, а что могло бы быть сделано лучше.

• Поручения: Кабир разошлёт заметки с совещания к концу дня 20 августа, а оптимизация графиков должна быть завершена к 3 сентября.

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

Читать руководство по комплексному управлению проектами (процесс из семи шагов)

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

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

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

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

Читать о том, какие преимущества даёт управление проектами

Управление неуправляемым

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

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

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

Познакомьтесь с Софией. Она возглавляет команду HR-специалистов в своей компании. Вместе им предстоит работа над очень крупным проектом по пересмотру всего процесса адаптации новых сотрудников.

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

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

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

Продолжим рассказ о Софии и ее команде и на их примере посмотрим, что такое типичный жизненный цикл проекта и каковы его этапы.

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

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

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

Возникновение проектного управления

Часто изобретение проектного управления приписывают NASA и лично доктору Мюллеру (англ. George E. Muller), отвечавшему за реализацию космической программы «Аполлон». Но история человечества знает куда более ранние примеры успешной реализации проектов — египетские пирамиды и великая китайская стена являются результатами проектного управления, пришедшие к нам из доисторических эпох. Увы, но документальные свидетельства того, как проходила реализация этих проектов не сохранились, и современное проектное управление безвозвратно оторвано от знаний и опыта прошлых веков.

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

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

Эта диаграмма был почти одновременно изобретена поляком Каролем Адамеки (англ. Korol Adamecki) и американцем Генри Л. Ганттом (англ. Genry L. Gantt) в начале XX века, но исторически получила имя американского инженера Гантта. Диаграмма Гантта графически изображает расписание проекта, основываясь на датах начала и окончания работ. Кроме того, диаграмма Гантта иллюстрирует длительность работ и взаимосвязи между ними, а также критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта.

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

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

Разным проектам нужен различный уровень контроля. Например, для многих проектов по разработке программного обеспечения важно управлять не только задачми и ресурсами, но и задействованными процессами. И вот два десятка лет назад появились гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

Классический подход

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

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

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

5 этапов традиционного менеджмента

Этап 1. Инициация

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

Этап 2. Планирование

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

Этап 3. Разработка

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

Этап 4. Реализация и мониторинг

На этом этапе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам.

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

Этап 5. Завершение проекта

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

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования.

Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

Как мы уже говорили ранее – не все проекты могут быть структурированы таким образом, чтобы быть реализованными по классическому проектному подходу. Возвращаясь к нашему примеру с шеф-поваром: приготовление одного блюда идеально ложится на «водопадный» подход, а вот вовремя приготовить и подать ужин из четырёх блюд будет практически невозможно, если придётся каждый раз ждать окончания приготовления одного блюда, чтобы приступить к приготовлению другого.

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на небольшие, хорошо управляемые модули, которые по итогам их реализации «собираются» в готовый продукт.

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова. Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки: Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

Вотчина  Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

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

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «бэклог».

Затем эти части приоретизируются владельцем продукта – представителем заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в спринте (англ. sprint) – так называются итерации в Scrum, длящиеся от 2 до 4 недель.  В конце спринта заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать.

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

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

В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

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

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

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания бэклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

Встреча по упорядочиванию бэклога (Backlog Refinement Meeting)

Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше.

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

Планирование спринта

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

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

Ежедневные летучки

Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.

Подведение итогов спринта

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

Ретроспектива спринта

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

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

Сильные стороны Scrum

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

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

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

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

Слабые стороны Scrum

Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта.

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

Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться. Подобрать такую зрелую  команду очень непросто!

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

Lean

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

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

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

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

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

Сильные стороны Lean

Если вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций  ̶  главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

Кроме того, создатель Kanban вдохновлялся супермаркетами, а именно их принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи.

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

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

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

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

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

1. Карточки. Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
2. Ограничение на количество задач на этапе. Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
3. Непрерывный поток. Задачи из бэклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
4. Постоянное улучшение. Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

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

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

6 сигм

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Билл Смит создал концепцию 6 сигм в 1986 году.

Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDС:

1. Определение (Define). Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
2. Измерение (Measure). 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
3. Исследование (Explore). На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
4. Разработка (Develop). На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
5. Контроль (Control). Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

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

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

Сильные стороны 6 сигм

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

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

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

Слабые стороны 6 сигм

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

Кроме того, основной лейтмотив 6 сигм: «Всё всегда можно сделать ещё лучше». Это может демотивировать сотрудников, не чувствующих удовлетворения от проделанной работы. Кроме того, если проект единичный и компания не планирует в будущем реализовывать подобные проекты, все затраты на анализ и извлечение уроков могут оказаться напрасными.

PRINCE2

NASA – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2.

Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту.

Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBoK не содержит:

• Специализированных аспектов управления проектом, например, отраслевых;
• Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

• 7 принципов определяют общие правила управления проектами по PRINCE2, определяют базу методологии;
• 7 процессов определяют шаги продвижения по проектному циклу;
• 7 тем – аспекты, по которым проводится контроль для достижения успеха проекта.

Кроме того, PRINCE2 рекомендует адаптировать методологию под каждую конкретную организацию. В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

• Бизнес-аспект (Принесёт ли этот проект выгоду?)
• Потребительский аспект (Какой нужен продукт, что мы будем делать?)
• Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

Начало проекта (Starting up a project)

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

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

Инициация проекта (Initiation a project)

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

Руководство проектом (Directing a project)

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

Контроль стадии (Controlling a stage)

При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям.

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

Управление созданием продукта (Managing Product Delivery)

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

Управление границами стадии (Managing a stage boundary)

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

Завершение проекта (Closing a project)

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

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

Сильные стороны PRINCE2

• Адаптируемость к особенностям организации;
• Наличие чёткого описания ролей и распределения ответственности;
• Акцент на продуктах проекта;
• Определённые уровни управления;
• Фокус на экономической целесообразности;
• Последовательность проектной работы;
• Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

• Отсутствие отраслевых практик;
• Отсутствие конкретных инструментов для работы в проекте.

Какие методы управления проектами использовать?

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

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

Просмотры: 126 510

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Заказчик — тот, кому принадлежит идея
• Исполнитель — тот, кому предстоит реализовать эту идею

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

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

• Руководитель проекта
• Администратор проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инициация

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

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

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

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

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

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

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

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

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

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

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

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

Анализ

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

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

Управление

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

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

Завершение

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

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

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

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

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

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

1. Сформулировать цель проекта 
2. Сформулировать описание результата
3. Сформулировать промежуточные результаты
4. Определить состав работ
5. Подготовить список ролей и предметную специализацию
6. Определить команду: соответствие ролей — людей и специалистов
7. Определить роли соответственно составу работ
8. Совместно с ролевыми специалистами детализировать состав работ до перечня работ с измеримым результатом
9. Назначить ответственных и сроки
10. Начать исполнение с ежедневным, еженедельным, ежемесячным контролем
11. Перейти от контроля к анализу соответствия плана-факта
12. Перейти к управленческому воздействию 
13. Повторить пункты 8-12
14. Перейти к завершению проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература для проектного менеджера

1. Питер Друкер — «Эффективный руководитель»: какие правила выполнять руководителю, чтобы работать эффективно.
2. Клейтон Кристенсен, Карен Диллон и др. — «Стратегия жизни»: о том, как применять методики менеджмента в жизни.
3. Элияху М. Голдратт — «Цель»: об управлении проектами в жанре романа-повести.