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

Как:

• Планировать и распределять время, какие для этого нужны инструменты;
• Правильно формулировать задачи и цели, грамотно их разделять;
• Расставлять приоритеты (что делать сначала);
• «Все успеть» и «ничего не забыть»;
• Перестать «тушить пожар» из срочных важных дел;
• Делегировать;
• Правильно завершать дела.

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

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

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

Спецпроект о цифровых инструментах, которые помогают банкам, стартапам и другим финкомпаниям. Тексты экспертов и ничего лишнего:

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

Всё про диджитал для «финансов» →

Реклама

Процесс управления проектом состоит из несколько стадий:

1. Инициация (старт)

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

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

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

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

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

«План — это ничто, а планирование — это все».

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

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

Все современные методологии управления проектами «гибкие» — то есть, планирование, исполнение и контроль происходят циклами:

• Создается план;
• Реализуется его часть;
• Контролируется исполнение;
• Вносятся изменения в план, поскольку модификация отдельных частей сильно влияет на конечный результат.

Таким образом — управление, исполнение и контроль взаимосвязаны.

Есть огромное количество теорий и методик, которые подразумевают гибкость процесса управления проектами, от Agile (используется в разработке ПО) до HADI, которую мы используем для продвижения проектов в Фонде Развития Интернет Инициатив (ФРИИ).

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

4. Завершение

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

Более детальный разбор этапов

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

По американской методологии PMBOK планирование занимает порядка 50% всего времени, что особенно подчеркивает его значимость.

Планирование лучше начать с разделения проекта на части (Work Breakdown Structure — WBS), где каждая фаза разделена на более мелкие задачи. Это помогает понять объем работ и учесть все нюансы.

Рис. 2 — Структура разделения проекта на подзадачи (WBS)

Графики работ

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

• Самый простой вариант диаграммы можно сделать в Exсel: слева в таблице находится название работ, а все остальные столбцы — даты.
• 
• Рис. 3 — Диаграмма Ганта, Microsoft Exсel

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

1. При наличии визуальной картины выполняемых задач работа над проектом существенно упрощается, так как они привязаны к календарному графику.
2. Рассмотрим пример диаграммы Ганта, построенной в MSProject.
3. 
4. Рис. 4 — Диаграмма Ганта, Microsoft Project

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

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

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

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

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

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

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

Как правильно ставить задачи (цели) по проекту

Рекомендую пользоваться принципом SMART. Как это расшифровывается:

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

M (Measureable — «измеримый»): чтобы понять, что поставленные цели действительно достигнуты, следует задавать и конечные, и промежуточные критерии оценки (в том числе финансовые).

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

Например, если нужно создать сайт, следует задать критерии измеримости (интернет-магазин на 1000 товаров, бюджет до 30 000 рублей и т. п.).

A (Achievable — «достижимый»): нужно требовать, чтобы исполнители приложили усилия, но при этом оглядываться на реальный мир и имеющиеся ресурсы. Не нужно ставить цели, которых не достигнуть, даже если вся команда будет работать 24 часа в сутки. Например, спланировать полет на Марс за 2 месяца нереально — для этого требуется гораздо больше времени.

R (Relevant — «последовательный»): все цели должны укладываться в общую концепцию, соотноситься со стратегией развития бизнеса. Например, если вы фокусируетесь на какой-то нише, то нужно развиваться именно в ней. Если не будет результатов, можно рассмотреть и другие ниши, но последовательно.

T (Timed/Timebounded — «измеримый во времени»): для целей нужно намечать временные рамки, не только конечные, но и промежуточные. Например, если сайт должен быть готов через месяц, нужно оценить сроки выполнения всех подзадач и четко сформулировать их сотрудникам и подрядчикам.

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

1. Составить полный список задач (SMART); 2. Распределить ресурсы на каждую задачу, убедиться, что их достаточно; 3. Построить взаимосвязь между задачами — можно ли выполнить их параллельно, последовательно, какие нужно завершить до начала реализации следующих; 4. Определить критический путь, учесть риски по срокам и переносу времени исполнения; 5. Исходя из плана и ресурсов высчитать себестоимость проекта для выставления сметы заказчику.

Исполнение

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

• Матрица Эйзенхауэра;
• Вычеркивание дел;
• Делегирование;
• Тайм-менеджмент (Хронос и Кайрос).

Работают они только тогда, когда вы их правильно и регулярно (!) применяете. Если человек один раз пробует и у него не получается — это не значит, что инструмент не работает.

Рассмотрим подробнее.

Матрица Эйзенхауэра. Делим дела на срочные, важные, несрочные и неважные.

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

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

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

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

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

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

Делегирование. Здесь важно учесть:

1. Поговорка «если хочешь сделать что-то хорошо, делай это сам» очень вредна для бизнеса и карьерного роста. Без делегирования руководителю не обойтись.

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

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

4. Необходимо убедиться, что цели поняты исполнителем.

5. Нужно проводить периодический контроль и требовать отчетность.

Оптимальное распределение времени или «Хронос-Кайрос». Хронос — линейное планирование по часам (дела планируются на конкретное время); Кайрос — событийное планирование (например, во время поездки по городу встречается магазин, где можно сделать покупки, поэтому можно отклониться от маршрута, это и есть гибкое планирование).

1. Планируйте дела заранее в хронологическом порядке — встречи, совещания и т.д.

Подходы и методологии управления проектами

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

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

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

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

Типы методологий управления проектами

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

Большинство руководителей проектов считают такие методологии, как Kanban, Agile и Waterfall, основой для разработки проектов, а другие рассматривают их лишь как отправную точку.

В данном руководстве мы рассмотрим 7 подходов и методологий:

1. Водопадная модель
2. Agile
3. SCRUM
4. Lean
5. Kanban
6. Prince2
7. Six Sigma

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

Водопадная модель

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

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

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

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

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

СТАДИИ

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

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

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

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

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

Еще одним преимуществом метода является усиление надзора и контроля на каждом этапе.

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

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

ПРИМЕНЕНИЕ МЕТОДОЛОГИИ

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

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

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

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

Agile

Методология Agile – средство обхода слабых мест водопадной модели.

Хотя некоторые концепции Agile используются уже давно, эта методология управления проектами была официально представлена в 2001 году в “Agile Manifesto”.

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

Методология фокусируется на проектах, требующих скорости и адаптивности. Гибкое управление проектами основано на краткосрочных “спринтах”, а также высокой степени интерактивности и сотрудничества.

ЦЕННОСТИ AGILE

Методология Agile основана на четырех основных ценностях:

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

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

Откровенно говоря, Agile, это не методология. Это идеология и подход, которая находит свое отражение в таких методах как: Scrum, Adaptive Project Framework (APF) и Extreme Programming.

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

КЛЮЧЕВЫЕ ПРИНЦИПЫ

В манифесте Agile перечислены двенадцать основных принципов:

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

УРОВНИ ПЛАНИРОВАНИЯ

В дополнение к вышеприведенным принципам Agile использует шесть уровней планирования:

1. Видение — планирование видения, смысла проекта.
2. Дорожная карта — карта этапов работ, с указанием функционала, который будет реализован в данном этапе.
3. План релиза — каждый этап из карты работ разбивается на релизы.
4. Бэклог — перечень задач, который нужно реализовать, чтобы разработать продукт.
5. Бэклог спринта — перечень задач, который должен быть реализован в конкретном спринте.
6. Приращение функциональности продукта — планирование функциональности, которая будет добавлена продукту, по результатам спринта.

СИЛЬНЫЕ И СЛАБЫЕ СТОРОНЫ

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

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

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

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

9 лайфхаков для успешного управления проектом

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

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

1. Управлять проектом стратегически, а не операционно

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

Ошибка руководителя проекта

Наиболее популярные причины:

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

Решение тут одно — начните менять себя и свое взаимодействие с командой:

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

Ошибка в методологии проектной деятельности

Такая ситуация более сложная, но все равно решаемая:

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

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

2. Минимизировать бюрократию

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

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

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

В различных проектах/компаниях названия данных документов могут варьироваться, поэтому ниже приведено описание документов в терминах «Для чего они нужны в проекте?».

Документ	Для чего нужен
Устав проекта	Для фиксации цели, ожидаемых результатов и критериев успешности проекта
Реестр рисков	Для системного управления рисками в проекте
Требования	Для того, чтобы получить на выходе проекта то, что нужно заказчику
Календарный план	Для управления расписанием проекта и одинакового понимания всеми участниками проекта промежуточных результатов и сроков
Ресурсный план	Для контроля привлечения и получения ресурсов в ходе проекта
Бюджет	Для избегания кассового разрыва в ходе проекта
Протокол испытаний	Для фиксирования того, что результаты проекта соответствуют ожидаемым
Акт приемки	Для фиксирования факта приемки результатов проекта и их передачи в линейную деятельность

По любым дополнительным документам (сверх данного минимально необходимого перечня) необходимо иметь ответ на вопрос — для чего они нужны? Какие риски они закрывают, какие задачи помогают решить? Может, в проекте нужен документ под названием «Итоговый отчет». Если в проекте много нематериальных составляющих, это заметно упростит сдачу результатов проекта. Или в проекте нужен документ под названием «Карта стейкхолдеров», так как в проекте огромное количество заинтересованных сторон. 

При согласовании документов обязательно оценивайте:

1. Насколько необходимо согласование с каждой стороной. Что это даст и что будет, если не согласовывать?
2. Является ли перечень согласовантов полным? Не забыли ли вы кого включить в него?

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

3. Визуализировать производительность и близость дедлайна

В бизнес-романе Тома Демарко есть отличная фраза: «День, потерянный в начале проекта, значит так же много, как и день, потерянный в конце».

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

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

Но есть некоторые лайфхаки, которые, если и не сводят влияние этого синдрома на нет, то заметно снижают:

• Посчитайте, сколько рабочих дней длится проект.
• Каждый день ведите отсчет того, сколько дней и процентов времени осталось до конца проекта, сколько дней и процентов времени прошло с начала проекта.
• Визуализируйте эту информацию так, чтобы каждый член проектной команды каждый день видел этот отсчет — через некоторое время все увидят, что, на самом деле, дедлайн приближается быстро и времени-то не так уж и много.
• Эта визуализация приводит к тому, что на подсознательном уровне все ведут себя более ответственно, сосредоточенно и продуктивно.
• Ну, а если на некоторых членов проектной команды такой подход не окажет никакого влияния, то это, как минимум, повод задуматься о том, что с ним надо расстаться.
• Если в проекте можно измерять процент выполненной работы, то наложите на визуализацию приближения дедлайна еще и визуализацию с процентом выполненной работы (как, например, это сделано в Scrum в Burn Down Chart или в подходе Earned Value Management в PMBok) — в этом случае ответственность, сосредоточенность и продуктивность проектной команды увеличится еще в несколько раз.
• При необходимости такую визуализацию можно делать не только со всем проектом, но и с отдельной его фазой.

4. Сокращать ненужные усилия

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

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

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

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

5. Принимать решения как можно раньше

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

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

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

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

Не тяните, так как в данной области работает правило «1-10-100»: исправление ошибки на стадии планирования обойдется в 1 рубль, на стадии воплощения — в 10 рублей, а на стадии реализации, (когда все уже запущено и работает), — в 100 рублей.

6. Делать совещания реже и эффективнее

Есть хорошая поговорка: «Любую задачу можно загубить, если провести достаточное количество совещаний». Так и с проектом в целом: его можно загубить, если он погрязнет в совещаниях. Все сведется к тому, что все будут постоянно встречаться, что-то обсуждать, дискутировать, но действий, приближающих к успешному окончанию проекта, происходить не будет (или их будет крайне недостаточно).

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

Вот несколько советов, как это сделать:

• Ведите учет времени и трудозатрат совещаний (время умножить на количество участников).
• Ведите жесткий тайминг в ходе совещания.
• Не мешайте форматы в рамках одной встречи. Если встреча посвящена мозговому штурму, то занимайтесь только мозговым штурмом. Если это планерка-оперативка, то занимайтесь только ей. Если это совещание по стратегическим вопросам, то занимайтесь только ими.
• Приглашайте на совещание только тех, кто там нужен. Не приглашайте большое количество людей.
• Всегда формулируйте и рассылайте всем заранее цель и повестку встречи.
• Заранее позаботьтесь о наличии необходимой инфраструктуры (доски, флип-чарты, видео конференция, телефонная конференция, маркеры и пр.).
• Максимально используйте визуализацию в ходе совещания.
• В ходе совещания фиксируйте решения в протоколе, по окончанию совещания протокол должен быть сразу же готов. Не через 10 минут, не вечером, не на следующий день, а сразу. И сразу же рассылайте его всем участникам совещания.
• Если совещание по своему содержанию является логическим продолжением какого-то другого совещания, то вставляйте протокол предыдущего совещания в приглашение на новое. И начинайте новое совещание с анализа данного протокола и текущего статуса поручений в нем.

7. Держать внутреннюю кухню проекта в приоритете

Всегда действуйте не с оглядкой на быстрый внешний эффект, а с оглядкой на долгосрочный внутренний эффект:

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

8. Не терять заказчика в ходе проекта

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

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

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

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

9. Постоянно извлекать уроки

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

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

И так далее.

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

То есть в управлении проектом очень много неопределенности и вероятностного исхода.

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

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

Ниже приведен пример шаблона реестра извлеченных уроков:

№	Проект	Стадия управления проектом	Предметные области управления проектом	Описание ситуации	Решение	Каких последствий позволит избежать
1	…	…	…	…	…	…