Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С уважением,

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

Глава 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Простите…

Вышел.

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

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

— Тебе чего?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Алексей Минкевич [3]

Глава 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).