Бесплатный фрагмент - Управление проектами. Правильный путь для начинающих

Предисловие

— Эта книга написана исключительно на основе моего личного опыта (более десяти лет). За это время я создал проекты для Nissan, Toyota, Альфа-банк, Бургер-Кинг, Nestle, Abbot, KT&G, Минпромторг, Росатом и множества других компаний. Обучил многих руководителей проектов, аналитиков, архитекторов и тимлидов искусству управлять, планировать и думать.

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

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

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

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

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

Буду рад и благодарен любым комментариям, пишите мне на почту petr@dikiy.pro или в социальных сетях.

Введение

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

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

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

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

Управление проектами настолько важно для делового мира, что существует прогнозируемая потребность в почти двух миллионах руководителей проектов, чтобы закрыть позиции к 2025 году. Чтобы понять, насколько ценно управление проектами и какие потребности в образованных руководителях проектов, давайте рассмотрим небольшую часть статистики по «провалам» проектов. В отчете The Standish Group за 2015 год (в выборку попало около 50 тысяч проектов по всему миру) указано, что около 70% проектов закончились провалом или были близки к этому, то есть результат проектной деятельности оказался спорным. В отчете за 2014 год только в одних Соединенных Штатах Америки каждый год тратится 250 миллиардов долларов на разработку программного обеспечения, а проектов реализуется около 175 тысяч. Из них 83% заканчивается провалом или близким к нему и только около 15,5% проектов уложились или не превысили бюджет более, чем на 20%. В 47,8% проектов сроки были превышены более чем в два раза, только в 7,3% проектов был реализован весь запланированный функционал.

Главным фактором успеха или неудач («провала») проектов по результатам этих исследований являются требования (бывают — не проработанные; качественно собранные и хорошо проработанные). Соглашусь с данным выводом, но нужно понимать, что «требования» это только один пункт из множества факторов, тем более в условиях нашей страны. Я постарался собрать в список основные факторы (относящиеся к различным этапам проекта), сильно влияющие на успешность проекта и его результаты:

— Вовлечение участников проекта и определение заинтересованных лиц.

— Квалифицированные сотрудники.

— Владелец продукта.

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

— Эмоциональная зрелость проектной команды (как на стороне исполнителей, так и заказчика).

— Поддержка, конструктивность и справедливость высшего руководства.

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

— Четкие цели (конкретные, достижимые и понятные всем участникам).

— Правильное планирование (включая качественную временную оценку, исполнителей и риски).

— Реалистичные ожидания.

— Использование Agile процессов.

Факторы, перечисленные выше, разберем далее в книге.

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

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

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

Что происходит, когда не используются стратегии управления проектами?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1. Что такое проект?

Согласно официальной терминологии:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Дизайнер.

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

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

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

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

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

— Дизайнер.

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

— Аналитик.

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

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

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

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

— Дизайнер.

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

— Аналитик.

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

— Поддержка.

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

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

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

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

— Тимлид/-ы.

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

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

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

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

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

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

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

— Поддержка.

Замечу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— инициация;

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

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

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

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

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

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

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

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

— Чтобы расходы оставались в рамках бюджета.

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

Уточню:

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

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

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

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

1.5.1 Этап «Инициация»

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

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

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

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

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

— Цели (по сути, это обоснование проекта).

— Сведения о руководителе проекта, проектной команде (включая роли и обязанности).

— Данные по клиенту, представители клиента и контактные данные.

— Основные этапы проекта.

— Риски и возможные проблемы.

— Список заинтересованных сторон и их участие в проекте.

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

— Ограничения, накладываемые организацией, окружением и внешней средой.

— Обоснование проекта, включая бизнес обоснование и данные о ROI (Return on Investment).

— Суммарный бюджет проекта.

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

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

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

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

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

1.5.2. Этап «Планирование»

Основная цель этого этапа — составить детальный план действий.

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

К данному плану стоит относится, как к дорожной карте. Он определит масштаб проекта и в нем должны быть перечислены все этапы, чтобы можно было отслеживать любые движения и изменения. План также должен включать информацию о каждой фазе проекта и задачах (без технической или углубленной детализации), над которыми команда будет работать на протяжении всего жизненного цикла проекта. План должен показывать, какие члены команды отвечают за какие задачи, и установить предварительные (максимальные, с учетом возможных проблем, проверок и корректировок) сроки выполнения каждой задачи при первой итерации работы с документом. Далее, в плане должен появиться подробный график проекта от начала до конца. То есть, план может начинаться с нескольких функциональных блоков в начале этапа планирования, но к концу этого этапа он должен превратиться в подробный план, поскольку информация начинает поступать с появлением вопросов при уточнении и детализации плана. Задачей руководителя проекта является ежедневная работа с планом и сравнение его с фактическим статусом задач проектной команды. Для этого удобно использовать одну из систем отслеживания задач, например Jira, Redmine и подобные.

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

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

— праздники,

— отпуски,

— возможные отгулы,

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

— риски (например, задержки у клиента в предоставлении обратной связи),

— занятость на проектах (задействованы на других проектах и на сколько).

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

— прибыль компании от проекта,

— успех проекта (люди работают над проектом),

— своевременный найм сотрудников (а это работа HR),

— подготовка рабочего места (а это работа поддержки),

— эффективность работы компании.

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

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

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

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

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

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

Не забудьте обсудить с заказчиком его ожидания. Объясните ему, что создание дизайна самого продукта не является фирменным стилем, что его создание является отдельным проектом и на его основе можно будет сделать дизайн ИТ или другого продукта. Уточните, хочет ли клиент индивидуальный дизайн или достаточно использовать что-то готовое, шаблонное (часто клиент не задумывается или имеет свои мысли на этот счет). Это тот минимум, который необходим на старте каждого проекта. Многие руководители проектов не учитывают эти траты при планировании, а зря, они могут составить значительную сумму и время. Подобные расходы возможно просчитать на старте и на ближайший период достаточно точно, далее скорректировать и предупредить об этом клиента. Обязательно нужно заложить 5—10% от общих затрат на непредвиденные расходы. Далеко не всегда все идет по плану, и лучше, если вы будете к этому подготовлены не только морально, но и финансово. Исходя из своего опыта скажу, что дизайн проектов, фирменный стиль, отбор фотографий согласовывается не сразу, то есть это длительный процесс отбора и обсуждений у 80% заказчиков. Не забудьте, что существует такой тип работ, как «Фотосъемки», который стоит прорабатывать и обсуждать отдельно от общей сметы.

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

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

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

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

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

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

Уточнение:

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

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

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

— Далее идет документ запроса информации (RFI). Этот документ помогает команде определить потребности.

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

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

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

Заключительным блоком работ этапа планирования является еще один обзор проекта. В данном блоке работ в форме обзора проекта следует указать:

— планируется ли завершить проект в срок;

— соответствует ли он бюджету на сегодняшний день;

— устранены или нет какие-либо существующие препятствия и риски.

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

Более детально планирование будет рассмотрено во второй главе данной книги.

1.5.3. Этап «Исполнение»

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

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

1.5.3.1. Тайм-менеджмент

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

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

1.5.3.2. Управление затратами

Это процесс управления всеми расходами, связанными с проектом. Еще управление затратами это:

— Знание, когда, где и в каких объемах расходуются средства компании/проекта.

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

— Умение обеспечить максимально высокий уровень отдачи от использования ресурсов на реализации проекта.

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

— обязательства,

— бюджетные затраты,

— фактические затраты.

1.5.3.3. Обязательства

Это плановые, будущие затраты, которые возникают при заключении договоров, контрактов, заказе каких-либо товаров или услуг. Обычно это происходит заранее согласно плану проекта.

1.5.3.4. Бюджетные затраты

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

1.5.3.5. Фактические затраты

Это отчет, содержащий информацию о фактических расходах проекта. При этом они могут произойти:

— Во время выполнения работ проекта.

— В момент выплаты денежных средств.

— В момент списания денежных средств со счета.

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

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

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

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

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

— Зафиксировать способ финансовых расчетов с заказчиком, поставщиками и субподрядчиками.

— Согласовать и подписать ТЗ с заказчиком.

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

— Установить, нужно ли разовое привлечение сторонних специалистов и их стоимость.

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

1.5.3.6. Управление качеством

Качество проекта (Project Quality) — это совокупность характеристик продукта, относящихся к его способности удовлетворять установленные или предполагаемые потребности.

Управление качеством проекта (Project Quality Management) — одна из основных функций проектной команды и руководителя проектов. Представляет собой процесс управления и улучшения качества продукта для удовлетворения потребностей и требований, ради которых проект был запущен. Процесс управления качеством может помочь команде в определении целей в области качества, определить потенциальные риски и препятствия, которые могут привести к плохому качеству, если их не решить.

Замечу:

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

2. Оценка должна строиться на данных, которые будут собираться во время аудита. Аудит (audit) — системное исследование, проводимое для определения, насколько эта деятельность эффективна и приведет ли она к запланированным целям, то есть — к результату.

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

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

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

1. Основание проведения аудита (цель) и объем проверки (границы).

2. Мероприятия по улучшению.

3. Список замечаний, несоответствий (включая их источники) и претензий.

4. Способы разрешения спорных вопросов и конфликтов.

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

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

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

В любом случае каждую запись о проблеме нужно оформить правильно. Такую запись обычно называют «Баг-репорт» (Bug Report), в каждой компании свои стандарты оформления репортов, но в любом случае они должны позволить вам:

1. Зафиксировать и описать путь воспроизведения проблемы, описать саму ошибку/проблему, приложить изображения проблемы (если нужно и возможно).

2. Воспроизвести проблему (это не всегда возможно, но необходимо стремиться).

3. Установить ее важность (определить приоритет проблемы).

4. Понять в чем проблема и устранить.

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

1.5.3.7. Управление изменениями

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

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

— заказчик (может влиять на конечные характеристики проекта);

— аналитик/архитектор/руководитель проекта в зависимости от структуры компании исполнителя (может влиять на первоначальную документацию);

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

Основные причины возможных изменений в проекте:

— случайности в проектных решениях;

— непродуманные решения;

— совершенствование средств, методов, материалов;

— отставание от графика;

— изменение цен (работы, материалы).

А виды изменений обычно разделяют на:

— Внутренние. Зависят от параметров самого проекта (сроков, поставок, графиков, финансирования и прочего).

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

Замечу:

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

Стратегия состоит из прогнозирования, планирования, осуществления, контроля и регулирования изменений.

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

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

Опишу шаги на схеме:

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

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

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

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

Приведу пример из жизни:

На проектах, которые я делал, заказчики часто присылали в процессе работы какие-то замечания, «хотелки», мелкие доработки и переделки. Это может быть как изменение цвета элемента или изменение положения, так и дополнительный макет страницы, которая из простой становится адаптивной. Я начинал считать и показывать заказчикам, что это требует дополнительного времени (да, по Agile я мог добавить это), а значит будут дополнительные расходы. Они, в свою очередь, начинали долгие разговоры/переписки и не всегда в спокойном тоне, что их не так поняли, что мы сделали не то, договаривались о другом, что были устные договоренности и так далее. Были случаи, когда выходили на моих руководителей (владельцев бизнеса) и жаловались им. Зная, что такое может быть, в начале работы в компании и перед запуском проектов я общаюсь с руководством и доношу свою позицию — все договоренности должны быть зафиксированы и согласованы заказчиком хотя бы в письме. Это давало возможность устранить конфликты внутри компании (часто верят больше заказчикам), иметь четкую позицию в переговорах с аргументами в виде согласованных материалов, а значит прийти к согласию с заказчиками на выгодных условиях. Если этого не учитывать и не делать, то для исполнителей, то есть для меня и команды, это станет большой проблемой и финансовыми потерями для компании.

— Решение. По результатам обсуждения предлагаемого изменения должно быть принято одно из пяти решений:

1. Одобрить. Принять в работу и произвести предлагаемое изменение.

2. Отклонить. Признать нецелесообразным отдавать в работу.

3. Отложить. Запрос на изменение имеет смысл, однако временно будет отложен и рассмотрен позднее.

4. Доработать. Запрос на изменение имеет смысл, но нужно или что-то продумать лучше, произвести дополнительную оценку и анализ последствий.

5. Эскалировать. Запрос на изменение имеет смысл, но оценивать и принимать решение могут только вышестоящие специалисты.

— Отложено. Если задачу отложили (на этапе «Решение»), она попадает в блок/статус «Отложено» это временное состояние, из него задача попадает на обсуждение с заказчиком. Почему именно на обсуждение, все просто, все данные по задаче есть, нужно только понять, будем делать и когда, если нет и задача нужна, повторно отклоняем. Вечно отклонять не стоит, это будет говорит, что она не нужна, введите число отклонений, среднее число три раза (статистика из практики), после чего задача закрывается с пометкой — «Не будет реализовано».

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

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

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

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

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

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

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

Замечу:

— Встречаются компании, где нет даже третьего шага.

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

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

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

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

1.5.3.8. Управление рисками

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

Анализ различных определений риска позволил выявить следующие признаки:

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

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

3. Действие — любое действие может привести к возникновению риска, поэтому он всегда связан с действием. Если нет действий, то нет и рисков.

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

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

6. Возможности — деятельность по достижению цели направлена на использование существующих возможностей.

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

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

Замечу:

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

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

Стратегии реагирования на риски и угрозы:

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

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

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

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

Замечу:

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

Стратегии реагирования на позитивные риски:

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

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

1. Партнерство с совместной ответственностью за риски.

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

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

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

Отдельно идут еще две стратегии:

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

— Стратегия реагирования на непредвиденные обстоятельства.

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

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

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

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

Замечу:

Некоторые способы реагирования предназначены для использования только в случае возникновения определенных событий (наступление рисков). Эти способы прописываются в плане реагирования на риски. Его приводит в действие руководитель проекта и только при заранее определенных условиях — уверенность и достаточное количество признаков того, что данный план будет успешно выполнен.

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

— организационные;

— технические;

— финансовые;

— правовые и иные.

Этому команду может научить только руководитель проекта, да и проконтролировать — тоже.

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

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

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

На выходе: обновляемый список рисков.

2. Анализ. Качественный и количественный анализ рисков с определением условий и вероятности их возникновения. Приоритизация рисков.

На выходе:

— Список рисков с оценками, приоритетами и пометками, какие требуют дополнительного анализа.

— Вероятность невыполнения плановых сроков и бюджета.

— Оценка необходимых резервов ресурсов.

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

На выходе: разнесенные по категориям и последствиям воздействия (положительное или отрицательное) на проект риски.

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

На выходе:

— Переработанный/обновленный план реагирования на риски.

— Список корректирующих действий.

— Отчет (-ы) по управлению рисками.

— Вывод об эффективности реагирование на риски или необходимости изменений.

— Вывод о воздействии рисков на проект (оказалось запланированным или случайным).

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

Резюмирую:

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

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

3. Любой проект связан с неопределенностью, она порождает риски в самом проекте.

4. Риски бывают: негативными (угрозы) и позитивными (возможности).

5. Стратегии реагирования на негативные риски: уклонение, уменьшение, разделение/передача.

6. Стратегии реагирования на позитивные риски: использование, совместное использование, усиление.

7. Общая стратегия реагирования на риски — принятие.

8. Стратегия реагирования на непредвиденные обстоятельства — резервирование.

1.5.3.9. Управление закупками

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

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

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

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

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

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

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

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

1.5.4. Этап «Закрытие»

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

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