Kitobni o'qish: «Проджект-менеджмент. Как быть профессионалом»

Name: Проджект-менеджмент. Как быть профессионалом
ISBN: 9785907274846

Алексей Минкевич, Сергей Дерцап

Shrift:

Знак информационной продукции (Федеральный закон № 436-ФЗ от 29.12.2010 г.)

Литературный редактор: Е. Закомурная

Руководитель проекта: А. Гришина

Дизайнер: А. Иванова

Корректоры: Е. Бударин, Н. Казакова

Верстка: О. Щуклин

* * *

В книге упоминаются социальные сети Instagram и/или Facebook, принадлежащие компании Meta Platforms, Inc., деятельность которой по реализации соответствующих продуктов на территории Российской Федерации запрещена.

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

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

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

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

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

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

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

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

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

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

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

Особую благодарность мы хотим выразить нашему коллеге Дмитрию Безуглому, который помог обогатить главу про искусственный интеллект примерами из своей практики, а также написал главу про стратегическое управление проектами в VUCA-мире. У Димы огромный опыт работы со стратегией, и мы благодарны ему за то, что он откликнулся на наше предложение и поделился своими знаниями в нашей книге. Спасибо, Дима!

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

Приятного чтения!

Кому будет полезна эта книга

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

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

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

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

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

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

Так что в добрый путь! Приятного чтения и учебы.

С уважением,
Алексей Минкевич и Сергей Дерцап

Глава 1
Карьера: знакомство, или Как я попал в IT

Всем привет! Меня зовут Алексей Минкевич. В настоящее время я вхожу в совет директоров европейской компании, занимающейся заказной разработкой. У меня за плечами 25 лет опыта работы в IT: 10 лет в продуктовой разработке, 15 лет в аутсорсинге, десятки успешных проектов в роли руководителя проектов, тимлида и разработчика. В этой главе я поделюсь с вами тем, как все начиналось. Еще до университета со мной случилось несколько хороших вещей, которые мне очень помогли в дальнейшей карьере и потому достойны упоминания.

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

В восьмом классе два моих друга записались в кружок программирования. Там были космические на тот момент персональные 286-е компьютеры. «Вот это да!» – подумал я и напросился в группу. Мы учили язык программирования Pascal. Учили, конечно, очень условно – чаще играли в игры. Правда, всю «старую школу» мы еще застали: запускали компьютеры с дискеты, учили DOS и Norton Commander. Там, в Доме юного творчества¹ на Макаёнка, я увлекся программированием.

Я хорошо помню момент, который изменил мое отношение к учебе.

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

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

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

И еще я прошел жесткую школу пионерского лагеря. С 12 до 14 лет каждое лето я ездил в лагерь «Звездный» в Радошковичах. Там я учился завоевывать уважение сверстников в отряде и узнал, что бывает, если это не удалось. Потом, с 15 до 18 лет, я работал в этом же лагере вожатым отряда. За лето проходило четыре смены. Это означало, что тебе нужно было четыре раза стать лидером новой группы детей, подружить их и создать команду, помогать во всем, решать проблемы и нести полную ответственность за этих маленьких людей.

В конце этой недолгой, но очень интересной карьеры детского педагога мне доверили самый младший отряд, из 30 детей пяти-шести лет. Это было замечательно. Главная задача заключалась в том, чтобы спланировать и провести с детьми яркий день, полный занятий и игр. Тогда наградой тебе было дружное сопение в 22:05, через пять минут после отбоя, и у тебя освобождался вечер для друзей и дискотеки, если ты не был дежурным по отряду. Сейчас я понимаю, что именно там, в пионерском лагере в Радошковичах, я получал свои первые уроки работы с людьми, лидерства, эмпатии и психологии.

Первые шаги в IT

К десятому классу мама убедила меня поступать в Белорусский государственный университет информатики и радиоэлектроники (БГУИР). Поскольку я учился в языковой гимназии, физика и математика у нас были очень слабенькие. Английский, конечно, в меня вдолбили хорошо, но для поступления в БГУИР он был не нужен. Отзанимавшись год на подготовительных курсах и с репетиторами, я отлично написал вступительные экзамены по физике и математике и поступил на факультет информационных технологий и управления. Специальность – «автоматизированные системы обработки информации». По слухам, там было легче учиться.

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

На соседней кафедре работали две студенческие лаборатории крупнейшей на тот момент минской IT-компании – IBA. В них занимались небожители! Я долго набирался смелости и, пересилив себя, однажды зашел в лабораторию Java:

– А можно к вам?

– Нет, все занято.

– Простите…

Вышел.

В тот момент подумал, что терять мне нечего, поэтому постучал в дверь с надписью: «Студенческая лаборатория Lotus Notes».

Вошел. Все были чем-то заняты. Меня заметили минут через пять.

– Тебе чего?

– Я… это… простите… можно к вам?

– Да. Вон свободное место. Садись.

Это было очень круто! Ребята занимались уже больше года и делали серьезные прототипы проектов на Lotus. Я читал, пробовал, спрашивал. Атмосфера была очень приятная и дружественная, все помогали друг другу.

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

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

– Кто хорошо знает английский?

Руки подняли два человека: я и Лена с параллельной специальности.

– Вы приняты. Остальные свободны.

Вот и все собеседование. Ребята потом сильно негодовали, а я с трудом верил, что получил работу.

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

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

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

Если между проектами возникали паузы, мы всем отделом взахлеб учились и проходили сертификации. Это было своеобразное спортивное соревнование. Вопрос был не в том, сдашь ты экзамен или нет (провалов никогда не было), а в том, насколько быстро ты справишься. Я как-то поставил рекорд и успешно сдал часовой экзамен из 40 вопросов за 16 минут. Впрочем, его скоро побили, установив рекорд в 12 минут. Отличное было время.

В 2006 г. я получил очень желанный и крутой сертификат в линейке Lotus – IBM Advanced Application Developer. Правда, радость и счастье от успешной сдачи экзамена через несколько дней сменились апатией: это был последний экзамен в профессиональной ветке Lotus Notes. Куда расти дальше, было непонятно.

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

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

Через пару месяцев мне повезло: начальник небольшого отдела из семи человек, на проекте которого я в тот момент работал, решил уйти и открыть собственный бизнес. Виталий предложил мне эту позицию. Я с радостью согласился. Быстро стало ясно, что я понятия не имею, что делать с этими людьми: не знаю, как их мотивировать, как оценивать работу и согласовывать сроки, как проверять результаты и проводить работу над ошибками. Что вообще такое ошибка и как отличить ее от хорошей работы? Нужно было всему этому где-то научиться. В Минске хороших курсов по управлению не было, и я нашел через интернет очень крутой курс в IBM Москва.

Курс назывался «Основы и принципы управления проектами». Вот об этих основах управления проектами мы и будем говорить в следующих главах.

Алексей Минкевич³

Глава 2
Основы управления проектами

Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата. Такое определение дает нам PMBOK (Project Management Body Of Knowledge) – свод правил по управлению проектами, разработанный американским Project Management Institute (PMI).

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

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

Чтобы четко представлять себе разницу, рассмотрим пример автомобиля Lada Kalina. Разработка самой модели конструкторским бюро и налаживание производства – это проект, а вот ее серийная сборка на конвейере – это уже операционная деятельность. Другой пример из IT: работа по поддержке существующих систем. Сама поддержка является операционной деятельностью, но если в рамках поддержки необходима доработка системы и исправление ошибок, то эти доработки, собранные в обновления до новых версий, представляют собой полноценные проекты.

Для чего нужны проекты

Любой проект служит определенной цели и решает конкретные задачи бизнеса.

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

2. Требования рынка и соответствие времени. У всех конкурентов уже внедрено какое-то решение или функция, а у вас еще нет. Вы теряете клиентов, и это нужно исправить.

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

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

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

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

7. Обновление бизнес-процессов и инфраструктуры. Компания пересматривает внутренние процессы, чтобы повысить эффективность. Это может включать внедрение гибких методологий (Agile), автоматизацию работы с клиентами (CRM) или оптимизацию управления ресурсами (ERP-системы, такие как SAP).

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

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

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

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

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

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

● установить рекламные билборды по всей стране;

● запустить рекламу на радио и телевидении;

● открыть новые отделения банка в населенных пунктах, где еще нет представительств;

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

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

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

Приложение должно позволять сотруднику банка совершать следующие действия:

● пройти авторизацию в приложении;

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

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

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

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

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

Но всегда ли успешное выполнение проекта означает достижение бизнес-цели? И за что в таком случае отвечает руководитель проекта?

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

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

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

Давайте остановимся на каждой из его вершин подробнее.

Содержание работ (Scope). Это список всех работ, которые необходимо сделать в ходе проекта, своеобразный список дел (To do list).

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

Бюджет (Cost). Объем финансирования, который выделяется на реализацию проекта.

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

Давайте посмотрим на примере. Допустим, вы решили реализовать проект «Ужин для друзей».

Бизнес-цель – социальная необходимость: вы давно не видели друзей и хотите пообщаться.

Цель проекта – к 20:00 приготовить ужин на четверых: для вас и троих друзей.

Содержание работ будет выглядеть следующим образом:

1. Купить картошку, мясо и пиво;

2. Навести порядок в квартире;

3. Почистить картошку;

4. Приготовить мясо в духовке;

5. Сварить картошку;

6. Накрыть стол.

Бюджет проекта составляет 110 руб.:

● 1 кг мяса – 60 руб.;

● 2 кг картошки – 10 руб.;

● четыре бутылки пива – 40 руб.

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

1. Покупки займут 30 минут;

2. Уборка квартиры – 20 минут;

3. Почистить картошку – 15 минут;

4. Приготовить мясо – 60 минут;

5. Сварить картошку – 30 минут;

6. Накрыть стол – 15 минут.

Поскольку задачи 1, 2 и 3 выполняются последовательно, то есть друг за другом, в сумме они займут 65 минут (30 + 20 + 15). А вот задачи 4, 5 и 6 вы можете делать параллельно: за 10 минут вы подготовите мясо и поставите его в духовку на 50 минут. Пока будет готовиться мясо, вы сварите картошку и накроете стол. Вот как это выглядит на диаграмме Ганта, или «в колбасках», как нежно и с любовью ее называют некоторые менеджеры проектов (рис. 3).

Таким образом, вам понадобится 2 часа 5 минут на подготовку ужина для гостей, то есть уйти с работы нужно будет в 17:55. Как видите, проект простой и очень понятный.

Как изменение содержания проекта влияет на бюджет и расписание

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

1. Купить картошку, мясо, овощи для салата и пиво;

2. Навести порядок в квартире;

3. Почистить картошку;

4. Приготовить мясо;

5. Сварить картошку;

6. Приготовить салат;

7. Накрыть стол.

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

Это прибавит к бюджету еще 20 руб. Таким образом, бюджет всего проекта увеличится со 110 до 130 руб. Изменится и расписание проекта: добавится приготовление салата. Таким образом, время выполнения проекта увеличилось на 20 минут, то есть теперь на все потребуется 2 часа 25 минут (рис. 4). С работы нужно будет уйти в 17:35, так что придется отпрашиваться у руководства.

Как изменение бюджета влияет на проект

Давайте еще раз взглянем на первоначальный вариант проекта без салата (рис. 3). Допустим, в пять часов вечера вы обнаруживаете, что у вас с собой всего 80 руб. Нужно что-то менять. При этом важно помнить о главной задаче проекта – приготовить ужин на четверых. Чтобы цель проекта не пострадала, вы решаете вместо мяса купить килограмм сарделек. Возможно, это несколько изменит качество ужина, но зато вы уложитесь в 80 руб.:

● 1 кг сарделек – 30 руб.;

● 2 кг картошки – 10 руб.;

● четыре бутылки пива – 40 руб.

При этом поменяется и содержание работ, и расписание (рис. 5).

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

Как изменение сроков влияет на проект

Когда меняются сроки проекта, то содержание работ и бюджет обычно требуют пересмотра. Если в день встречи с друзьями вам поставили важное совещание с 17:30 до 18:30, это ограничивает вас во времени. Успеть все запланированное к 20:00 будет невозможно.

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

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

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

О качестве

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

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

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

Так что же важнее всего: бюджет, сроки, содержание работ или качество?

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

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

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

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

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

Проекты на голубой тарелочке с золотой каемочкой

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

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

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

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

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

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

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

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

Если вы работаете с внешним заказчиком (внешний проект), то спонсора будет два. Например, вы являетесь руководителем проектов в компании, которая занимается изготовлением макетов. Завод «МАЗ» заказал у вашей компании макет грузовика в масштабе 1:10, чтобы участвовать с ним в выставке. Внешним спонсором в таком проекте будет руководитель завода. Он платит за готовый макет грузовика. Внутренним спонсором будет директор компании – производителя макетов. Он выделяет помещения для работы, проектировщика модели, время станка с ЧПУ для изготовления деталей и двух инженеров, которые соберут и покрасят модель.

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

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

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

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

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

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

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

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

Обе программы входят в портфель финансовых инструментов компании. В рамках управления этим портфелем происходит перераспределение ресурсов: часть сотрудников из программы A переводят в программу B, а финансирование направляется на развитие нового рынка.

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

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

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

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

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

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

Офис управления проектами

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

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

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

Модель жизненного цикла проекта

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

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

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

Какие стадии развития проекта существуют?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как вы уже заметили, это зацикленный процесс. Итераций «планирование – исполнение – мониторинг и контроль – коррекция» может быть очень много. Это особенно актуально для Agile-методологий, где рекомендованная продолжительность одной итерации составляет две недели. Если проще, то рабочий процесс выглядит так: выбрали из списка работ самые важные на данный момент, спланировали ближайшие две недели, сделали, показали заказчику. И так снова и снова.

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

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

Взаимодействие групп процессов

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

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

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

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

Что делает менеджер проекта

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

Менеджер отвечает за:

● анализ и осмысление содержания проекта, работу с требованиями к результатам поставки проекта и критериями приемки, а также с критериями успеха проекта;

● обработку и структурирование имеющейся информации, преобразование информации в план управления проектом;

● оценку стоимости отдельных задач и всего проекта;

● управление рисками проекта;

● построение реалистичного расписания проекта;

● выполнение операций для обеспечения результатов проекта;

● измерение и мониторинг всех аспектов исполнения проекта, а также осуществление необходимых действий для достижения целей проекта;

● лидерство, вдохновение и мотивацию команды проекта на выполнение поставленных задач в ограниченных временных рамках;

● коммуникации: руководитель проекта тратит порядка 90% рабочего времени на общение с другими людьми;

● четкую работу с изменениями по ходу проекта;

● выбор и использование инструментов управления проектом, таких как Trello, Jira, MS Project. Важно не только уметь ими пользоваться, но и подобрать наиболее подходящие для команды и задач проекта;

● управление ожиданиями заинтересованных сторон: проект можно считать успешным, если заказчик доволен, даже если он получил не то, что задумывалось изначально;

● и, конечно, яркое и запоминающееся завершение проекта.

Выводы

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

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

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

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

«Ура! – сказали программисты. – Это же стандартная транспортная задача. Сейчас будем экономить километры пробега и топливо».

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

Изменение реализовали, и проект запустили. На запуск приехали владельцы компании и признали проект провалившимся. Оказывается, целью проекта было пресечение воровства среди директоров логистических центров. Они специально планировали неоптимальные маршруты, а машины отправляли по оптимальным, воруя таким образом топливо. В общем, проект переделали. Теперь маршруты и расписания стали приходить строго из головного офиса. Большинство директоров логистических центров уволились, и их места заняли новые люди. Воровство прекратилось. Если бы руководитель проекта знал, в чем состоит реальная бизнес-цель проекта, то он никогда бы не утвердил изменение, которое запросили директора, и сразу бы привел проект к успеху.

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

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

Глава 3
Карьера: как заставить себя учиться?

Теория, полученная на курсах, – это хорошо, но практика лучше! Или нет? Жизнь всегда резко отличается от книжной теории.

Где-то через полгода моей работы на новой должности из отдела, которым я руководил, почти одновременно уволились четыре человека из семи. Конфликтов у нас не было, времени прошло еще мало, и я не понимал, что пошло не так. Может, дело было во мне? Эта мысль не давала покоя. Я ведь верил, что стану отличным руководителем, создам сплоченную команду, и мы будем вместе приводить к успеху самые сложные проекты. А тут нá тебе: бóльшая часть отдела разбежалась, и я ничего не смог сделать.

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

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

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

1) собственная мотивация к обучению;

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

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

Сертификация имеет ряд преимуществ и для сотрудника, и для работодателя.

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

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

Как выбрать сертификацию

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

● американский PMP (Project Management Professional);

● швейцарский IPMA (International Project Management Association), который активно продвигали в России;

● английский Prince2 (PRojects IN Controlled Environments).

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

Что такое PMP

В США существует институт Project Management Institute. Он занимается тем, что создает, поддерживает и распространяет в сфере управления проектами стандарты, аналогичные нашим ГОСТам. Стандарт по управлению проектами называется PMBOK (Project Management Body of Knowledge). Он достаточно объемный и представляет собой справочник по управлению проектами: что и когда должен делать руководитель.

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

«Это то что надо!» – подумал я и задался целью за год подготовиться к сдаче экзамена.

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

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

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

Алексей Минкевич

Глава 4
Устав проекта

Устав проекта (Project charter) – это короткий документ, который «в крупную клетку» описывает детали проекта, формально авторизует его существование, закрепляет за ним руководителя, которому предоставляет полномочия использовать ресурсы компании для работы над проектом.

Устав проекта – это не единственное название документа. В разных компаниях его могут называть по-разному: карточка проекта, one-pager, executive summary, описание проекта и т.д.

Начнем с начала. На каком этапе менеджер узнает о своем назначении на проект?

Этап идеи – это, как правило, этап внутренних проектов. Начальник вызывает менеджера и говорит: «Слушай! Есть идея!» У таких проектов обычно только один спонсор – непосредственный руководитель менеджера.

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

Этап победы в тендере – обычно выглядит так: к менеджеру подбегает радостный сотрудник отдела продаж и говорит: «Отличные новости! Мы тут продали одному клиенту такой огромный проект! В общем, нужно еще и CRM им сделать. Короче, на все у тебя две недели. Удачи!» В этом случае у менеджера еще остается возможность обсудить с заказчиком содержание работ, составить расписание и сверстать бюджет проекта.

Этап подписанного контракта – менеджер попадает в проект, где уже оговорены конкретные сроки, четко прописан объем работ, все обещания уже даны. В этом случае менеджеру проекта нужно убедиться, что все реалистично и работы укладываются в оговоренные сроки и бюджет. Если это не так, то нужно немедленно обсудить ситуацию со спонсором проекта.

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

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

Конечно же, познакомиться с проектом и найти ответы на простые, но самые важные вопросы:

● Для чего нужен проект?

● Что именно должно быть сделано?

● К какому сроку все должно быть готово?

● Сколько денег выделено на проект?

● Кто может оказать существенное влияние на реализацию проекта?

Чтобы помочь найти ответы на эти вопросы, существует классный инструмент – устав проекта.

Что должно быть в уставе

1. Бизнес-цель проекта. Как уже было сказано в начале книги, руководителю проекта очень важно знать, какую цель преследует бизнес своим проектом и какую проблему он хочет решить с его помощью. Иногда бывает сложно докопаться до сути сразу, и происходят примерно такие диалоги: «Вячеслав, зачем мы автоматизируем бухгалтерию?» – «Для того, чтобы автоматизировать…» – «Хорошо, а для чего мы ее автоматизируем? Что вы хотите получить в итоге от проекта? Какова цель бизнеса?»

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

Бизнес-цель: увеличение базы клиентов банка на 1 млн человек за год.

2. Цель проекта. Описание того, каким образом будут достигнуты бизнес-цели проекта. Бизнес принимает решение о запуске конкретного проекта, проанализировав различные альтернативы и выбрав один вариант. В примере с банком таким решением может быть, например, приложение, помогающее выдавать мини-кредиты. Оно служит единственной бизнес-цели – увеличить базу клиентов банка. Решение должно быть задокументировано кратко и на высоком уровне. Это своеобразная карта, по которой нужно двигаться, чтобы помочь бизнесу достичь цели. Как это прописать в уставе? Примерно так.

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

● пройти авторизацию в приложении;

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

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

3. Требования / результаты поставки. Этот раздел фиксирует ключевые результаты проекта и основные требования к ним. В итоге формируется список дел, «to do» проекта.

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

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

Список результатов поставки для примера с банком:

● разработать мобильное приложение для телефона Lenovo P780 с функционалом, описанным в целях проекта;

● обновить банковское серверное решение для поддержания работы приложения;

● закупить 200 телефонов Lenovo P780;

● разработать обучающие видеоматериалы по работе с приложением;

● провести обучение 30 представителей банка;

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

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

4. Ограничения и допущения. Ограничения проекта – это перечисление факторов, которыми в проекте нас ограничивает заказчик. Есть решения, которые уже приняты, и мы их не можем менять. В нашем банковском примере есть всего одно ограничение: решение должно работать на телефоне Lenovo P780 под управлением Android 5.1.

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

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

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

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

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

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

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

Ключевые и контрольные события:

● проект запущен: 6 июля;

● API между мобильным приложением и сервером согласованы: 5 сентября;

● разработка серверного решения завершена и протестирована: 10 октября;

● разработка мобильного приложения завершена: 4 ноября;

● тестирование решения завершено: 2 декабря;

● проект успешно завершен: 12 декабря.

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

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

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

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

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

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

Практические рекомендации по составлению устава проекта

По методологии устав проекта должен создавать заказчик. Но в нашей практике этим часто занимался руководитель проекта. Это короткий документ, который легко прочитает и спонсор со стороны заказчика, и начальство менеджера. Этим документом руководитель проекта как бы переспрашивает: «Все ли я понял верно?» Если вдруг на этапе подготовки устава что-то упущено или понято не так, то это может привести к большим изменениям в проекте и, соответственно, большим дополнительным затратам. Если же менеджер получил письменное подтверждение того, что все понято верно, то проект пойдет в нужном направлении.

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

Устав может корректироваться в ходе реализации проекта. Почему? Например, у бизнеса поменялись цели. Такое бывает: время не стоит на месте, рынок меняется. В управлении проектами нет документов, которые «ламинируются». Любые планы нужно будет обновлять согласно новым вводным. Обратите внимание, что такая же история происходит и со стартапами. Очень редко стартап становится успешен со своей оригинальной идеей. Обычно только в ходе работы становится понятно, что именно нужно рынку. И успеха добиваются те, кто способен быстро адаптировать свою идею под нужды рынка или, если потребуется, полностью изменить ее. Например, YouTube начинался как сайт знакомств, фишкой которого была возможность записать короткое видео о себе. А сейчас это крупнейший провайдер видеоконтента.

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

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

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

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

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

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

Выводы

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

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

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

Глава 5
Содержание проекта. Требования и иерархическая структура работ проекта

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

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

Критерии приемки (Acceptance criteria) – четкий перечень условий, которые должны быть выполнены, чтобы результаты проекта могли быть приняты заказчиком. Это чек-лист, согласно которому заказчик будет принимать работу и проверять, насколько она соответствует его требованиям.

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

Исключения из проекта (Project exclusions) – формулировка того, что именно находится вне содержания проекта. Проще говоря, это описание того, что в проект не входит.

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

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

Некоторые заказчики чувствительны к формулировке «исключения из проекта»: «Мне это нужно! В смысле – не будем делать?!» В таких случаях этот пункт можно назвать «работа, которая будет выполнена в следующем проекте / на следующем этапе проекта».

Ограничения проекта (Project constraints) – это то, в чем нас ограничивает заказчик: например, в выборе субподрядчиков или технологии. Не нужно вписывать в этот пункт ограничение по срокам и бюджету: им всегда отводится особое место.

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

С терминами разобрались, теперь перейдем к основной части.

Базовый план

Базовый план (Baseline) – это первоначальный план проекта, утвержденный спонсором. Этот план используется для сравнения текущего положения дел в проекте с тем, что было запланировано изначально.

Для чего это нужно? Жизнь всегда вносит коррективы в любой план. Например, я задумал повесить три светильника. Плановая стоимость светильников – 100 руб. за штуку, плановая стоимость работ по установке – 250 руб. Это и есть мой базовый план. Приехав в магазин, я узнаю, что вышла новая коллекция светильников, но их цена уже 110 руб. за штуку, а старой коллекции нет. В итоге я вынужден потратить на светильники 330 руб. Установка прошла по плану и стоила 250 руб. В конце проекта я сравниваю фактические расходы с базовым планом. В итоге получилось отклонение в 30 руб.

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

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

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

Базовый план по содержанию проекта состоит из требований к проекту, соответствующей иерархической структуры работ (ИСР) и ее словаря.

I. Требования к проекту

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

1. Как собирать требования к проекту?

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

Есть и другие способы сбора требований.

● Фокус-группы. Для интервью собирают 5–10 человек из тех, кто будет пользоваться разрабатываемой системой, чтобы выяснить их пожелания. Пользователей у системы может быть огромное количество, но предполагается, что мнения этих 5–10 человек совпадут с мнениями остальных.

● Семинары с участием модератора. Если заинтересованных сторон не слишком много (до 15 человек), то можно провести специальный семинар по сбору требований.

● Методы совместной разработки (Joint Application Development, Voice Of Customer, Agile). Команда быстро создает прототип или сильно упрощенную версию продукта (minimum viable product, MVP) и показывает его пользователям. Затем собираются пользовательские отзывы, которые и становятся требованиями. Такими маленькими итерациями список требований обновляется постоянно.

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

● Анкеты и опросы. Можно собирать требования при помощи анкет и опросов. Например, создавать их в Google Forms или SurveyMonkey⁴ и рассылать пользователям.

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

● Бенчмаркинг. Заключается в адаптации лучших решений, применяющихся в других компаниях. Менеджер и команда изучают СМИ, отыскивая лучшие практики и решения у других компаний, а затем применяют их в своем проекте.

● Анализ существующих документов. Очень часто нужную информацию можно найти в существующей документации или переписке.

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

1. Почему мы делаем этот проект?

Этим вопросом мы уточняем бизнес-цель.

2. Какова ваша роль в проекте?

Анализируем заинтересованные стороны. Выясняем степень их влияния на проект.

3. Как итоги проекта могут повлиять на вашу карьеру или положение в компании?

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

4. Кто еще может влиять на проект, на кого он окажет сильное влияние?

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

5. Какое финансовое влияние проект окажет на компанию?

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

6. В состоянии ли существующая в компании инфраструктура поддерживать этот проект?

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

7. Каких результатов вы ждете от проекта? При каких условиях проект будет считаться завершенным?

Результаты поставки, которые заинтересованное лицо ожидает получить по завершении проекта.

8. Как вы определите успешность проекта?

Критерии приемки, с помощью которых мы сможем оценить, успешен проект или нет.

9. Когда и что должно быть готово?

Этот вопрос поможет найти существующие ограничения в расписании и сроках сдачи проекта.

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

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

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

2. Как выглядят хорошие требования?

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

Пример из практики. Знакомый бизнесмен, владеющий бизнесом по разработке и внедрению CRM, заключил договор с крупной логистической компанией. В договоре очень хорошо и детально была описана CRM, а также имелась следующая формулировка: «Система должна генерировать следующие отчеты: 1. (описание), 2. (описание), 3. (описание), 4. (описание), 5. (описание), 6. (описание), 7. (описание), 8. (описание), 9. (описание), 10. (описание) и т.д.».

После сдачи проекта заказчик не захотел подписывать акт приемки и под пункт «и т.д.» попросил сделать еще один отчет, а потом еще один, и еще… В итоге компания-исполнитель еще год занималась созданием отчетов в рамках контракта абсолютно бесплатно.

Требования должны иметь четкий критерий завершенности (definition of done). У менеджера должно быть четкое определение того, что считать выполненным. Кто-то считает, что уборка сделана, когда носки спрятаны под кровать, а для кого-то уборка – это вымытый с содой пол.

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

Требования должны быть описаны максимально четко и детально, чтобы их поняли все заинтересованные стороны. Хорошая практика – если вы работаете в IT, дать почитать их кому-нибудь из сферы, не связанной с IT. Если человек поймет, что нужно сделать, значит, работа с требованиями проведена хорошо.

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

Самое главное: требования должны быть задокументированы и согласованы со всеми ключевыми заинтересованными сторонами. Документирование – это один из лучших способов избежать разрастания содержания проекта (scope creep). В любом проекте заказчик постарается добавить новые работы, и содержание начнет разрастаться. Лучше всего я прочувствовал это на проектах, где сам выступал заказчиком.

II. Иерархическая структура работ

Иерархическая структура работ, ИСР (Work Breakdown Structure, WBS) – это список работ, которые необходимо выполнить, чтобы успешно завершить проект. ИСР формируется на базе требований к проекту и отражает только те работы, которые нужно выполнить в ходе проекта. Если в ИСР какой-то работы нет, то она не входит в проект, а значит, делать ее не нужно.

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

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

1. Собрать чемодан:

● пять пар носков;

● пять трусов;

● шесть маек;

● теплый свитер;

● удобные ботинки;

● косметичка с бритвой, шампунем, зубной щеткой и т.д.;

2. Собрать рюкзак:

● ноутбук;

● наушники;

● зарядное устройство для ноутбука и телефона;

● бутерброды;

● бутылка воды;

3. Собрать документы/деньги:

● паспорт;

● водительские права;

● кошелек (наличные + две карточки).

Это и есть иерархическая структура работ (ИСР) мини-проекта сборов в дорогу. Когда мы выполнили все пункты, проект готов.

ИСР – это основа планирования проекта. Если у менеджера нет четкого списка работ, то он не может посчитать, сколько будет стоить проект и сколько времени на него понадобится. ИСР помогает структурировать и определить все содержание проекта. ИСР можно создавать в формате структурированного списка, как в нашем примере, или в виде дерева (рис. 11).

При создании ИСР руководитель проекта должен декомпозировать работы до того уровня, когда он сможет управлять ими. Работы, находящиеся на нижнем уровне ИСР, называются пакетами работ. О пакете работ менеджер должен знать три вещи:

1. Кто его будет выполнять;

2. Сколько времени на это понадобится;

3. Как проверить, что работа готова.

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

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

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

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

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

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

Проект строительства дома

1. Подготовка фундамента.

2. Строительство стен.

3. Строительство крыши.

4. Прокладка электрики.

5. Подготовка сантехники.

6. Внутренняя отделка.

7. Постройка забора.

8. Обустройство участка.

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

1. Фундамент.

1.1. Подготовка котлована.

1.2. Обрешетка фундамента.

1.3. Заливка фундамента.

1.4. Заливка плиты.

…

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

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

Важно понимать, что ИСР отвечает на вопрос «Что нужно сделать в проекте?», но не отвечает на вопросы о том, в какой последовательности будут выполняться работы, сколько они будут длиться и в какую сумму обойдутся. Ответы на эти вопросы нам дают следующие шаги: оценка и расписание. Поэтому не нужно пытаться располагать работы строго в той последовательности, в которой, по вашему мнению, они будут выполняться.

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

Кстати, еще один важный момент заключается в том, что перед созданием ИСР нужно решить, каким образом она будет храниться, поддерживаться и распространяться. Возможно, это будут стикеры на стене, некий инструмент типа Microsoft Project или Smartsheet, файл где-то в облаке с возможностью общего доступа и редактирования или другой удобный для вас вариант.

III. Словарь ИСР и для чего он нужен

Словарь ИСР (Work Breakdown Structure Dictionary, WBS Dictionary) помогает зафиксировать и детализировать все элементы иерархической структуры работ. Сам формат ИСР подразумевает краткость формулировок, но в процессе ее создания у менеджера проекта возникает множество вопросов, идей и уточнений. Чтобы их не потерять, удобно использовать словарь ИСР.

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

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

В электронных инструментах для работы с ИСР, таких как Microsoft Project, словарь ИСР может быть реализован в виде встроенных полей Notes или «Заметки». Менеджер проекта может использовать их для пояснений, чтобы в любой момент было понятно, что означает тот или иной элемент структуры.

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

Выводы

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

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

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

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

Глава 6
Управление рисками

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

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

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

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

Как работать с рисками

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

Риск описывается тремя параметрами:

● событие;

● вероятность;

● влияние на проект.

В качестве примера рассмотрим очень распространенный случай – отсутствие ключевого сотрудника проекта из-за болезни:

● событие – болезнь ключевого сотрудника длительностью пять рабочих дней;

● вероятность – 20%;

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

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

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

Как и во всех остальных областях знаний проектного менеджмента, управление рисками начинается с планирования. А конкретно – с принятия решения о том, будем ли мы ими вообще управлять. Если ответ «да», то далее работа строится по схеме, показанной на рисунке 12.

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

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

Для чего нужно планирование?

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

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

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

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

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

Идентификация рисков

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

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

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

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

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

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

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

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

Карточки Кроуфорда. Одна из техник мозгового штурма. Всем членам команды раздают карточки и просят написать один самый значимый, по их мнению, риск проекта. Заполненные карточки помещаются в центр стола. Затем все повторяется 5–10 раз с единственным условием: нельзя указывать риски, которые участник написал в предыдущих итерациях.

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

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

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

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

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

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

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

Что нужно делать на этом этапе:

● привлечь к участию в процессе соответствующих специалистов, заинтересованные стороны и внешних экспертов;

● идентифицировать риск, который может повлиять на проект;

● указать внутренние и внешние источники риска;

● определить причины риска и его последствия для проекта;

● категоризировать риски: внешние, организационные, связанные с управлением проектом и др.;

● внести всю собранную информацию в реестр рисков.

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

Качественный анализ рисков

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

Что нужно сделать:

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

● определить последствия: сколько дополнительных средств или времени понадобится, если риск реализуется. Здесь также можно использовать определение на уровне порядка: низкие, средние, высокие;

● расставить приоритеты рисков на основании вероятности их наступления и влияния на проект;

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

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

Составление рейтинга риска

Для того чтобы оценить степень влияния риска на проект, ему следует присвоить рейтинг (severity). Рассчитывается он по формуле:

Рейтинг риска = вероятность риска × влияние риска.

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

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

После того как вы посчитали рейтинги рисков, нужно отобрать самые опасные и отслеживать именно их. Для чего? По закону Парето, 20% рисков несут в себе 80% проблем. Соответственно, если мы будем контролировать 20% самых опасных рисков, то сможем избежать 80% проблем.

Количественный анализ риска

На этом этапе оцифровывается вероятность наступления рисков и их влияние на проект. Вероятность оценивается в процентах, а влияние – в деньгах.

Рассмотрим все шаги оцифровки на примере отсутствующего из-за болезни сотрудника.

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

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

2. Оцифровываем влияние. В качестве влияния берем недельную нетрудоспособность сотрудника, которая может привести или к смещению даты сдачи проекта, или к сверхурочным работам для оставшихся членов команды с трудоемкостью 40 человеко-часов. Предположим, что ставка за час сверхурочной работы составляет 10 единиц. Таким образом, оцифрованное влияние будет вычисляться так:

40 человеко-часов × 10 единиц = 400 единиц.

3. Вычисляем рейтинг риска в деньгах. Для этого берем вероятность наступления риска, которая в нашем случае равна 50%, или 0,5, и умножаем на влияние, которое для данного случая равняется 400 единицам. Получаем денежный эквивалент рейтинга риска в 200 единиц.

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

Планирование реагирования на риски

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

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

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

Уклонение (Avoid). В этом случае за рамки проекта выводятся те работы, которые содержат этот риск, – их не делают вообще. Таким образом, риски просто исчезают.

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

● взять на себя этот риск и попытаться с ним работать;

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

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

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

Снижение (Mitigate). Вероятность наступления или влияние риска можно попытаться снизить. Например, менеджер видит, что ключевой сотрудник (пусть это будет архитектор) уже несколько раз приходил на работу в костюме, а в течение дня куда-то отпрашивался. Скорее всего, он ищет новую работу и посещает интервью. Оценим вероятность этого риска в 40%. Если он все же уйдет, то на поиск и адаптацию нового специалиста уйдет время, а это могут быть потери, например, в 35 000 единиц.

Можно попытаться снизить вероятность этого риска – например, пообещав архитектору премию за успешное завершение проекта. И вот уже вероятность его ухода падает с 40% до 10%, так как теперь он мотивирован довести проект до конца.

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

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

Принятие риска (Accept). Принятие риска может быть активным и пассивным.

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

Активное принятие подразумевает закладывание в бюджет резерва на случай возникновения риска. Например, если сломалось какое-то оборудование, то должны быть деньги на покупку или аренду нового. Рекомендуется закладывать резерв в размере рейтинга риска в деньгах. Например, риск того, что ноутбук разработчика выйдет из строя, составляет 20%, стоимость 2000 единиц, количество ноутбуков 5. Значит, в резерве на этот риск, согласно формуле 0,2 × 2000, должно быть заложено 400 единиц на сотрудника. На всех сотрудников понадобится резерв в 2000 единиц.

Риски можно разделить на две категории. Первые – это «известное неизвестное» (known unknowns), то есть риски, которые мы смогли выявить, внести в реестр и подготовиться к ним. Вторые – «неизвестное неизвестное» (unknown unknowns), непредвиденные обстоятельства, которые невозможно предсказать заранее.

Риски из категории known unknowns можно анализировать, планировать и контролировать, тогда как unknown unknowns остаются за пределами прогнозируемой зоны и требуют гибкости в реагировании, если они вдруг проявятся.

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

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

1.Речь идет о Республиканском Доме технического и художественного творчества учащейся молодежи, г. Минск.

2.Имеется в виду герой сериала «Звездный путь: Следующее поколение» (реж. К. Боул, Л. Ландау, У. Кольбе. США, 1987). – Прим. ред.

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

4.Домен surveymonkey.ru включен в реестр запрещенных сайтов как содержащий информацию, распространение которой в Российской Федерации запрещено. – Прим. ред.

5.Автор имеет в виду март-апрель 2020 г.

Bepul matn qismi tugad.