Сергей Дерцап

Алексей Минкевич
Проджект-менеджмент.
Как быть профессионалом

Текст предоставлен правообладателем

http://www.litres.ru/pages/biblio_book/?art=58844959
Проджект-менеджмент: Как быть профессионалом:
Интеллектуальная Литература; Москва; 2020
ISBN 978-5-9072-7484-6

Аннотация
«Ну что нового можно сказать об управлении проектами!» –
недоверчиво подумает кто-то, увидев обложку. В опутанном
информационной паутиной мире сказать что-то новое вообще
становится все труднее. Поэтому так ценны теоретические
знания, отлично систематизированные и пропущенные через
личный опыт. У авторов книги на двоих – более 20 лет боевой
практики управления проектами. Этим богатым опытом они
щедро делятся, умело вплетая его в необходимую теоретическую
базу и терминологию. Они выстраивают кристально ясную
структуру управления проектами, рассматривают типичные
ошибки, облегчая понимание наиболее сложных нюансов с
помощью живых примеров. Знакомая тема, пожалуй, впервые
обрела формат, сочетающий в себе полезную методичку
с универсальным набором практических инструментов и
искренний рассказ о карьере и путях развития руководителей
проектов, их обучении, поражениях и, конечно, победах.
Начинающим менеджерам проектов книга точно подскажет, что,
как и когда нужно делать; опытному руководителю поможет
заполнить пробелы и упорядочить существующие знания;
владельцу бизнеса – получить больше контроля в собственной
компании; и, наконец, всем им – избежать неожиданностей и
сохранить много нервов.
 Содержание
Предисловие 14
Кому будет полезна эта книга 16
Глава 1 18
Первые шаги в IT 21
Глава 2 26
Для чего нужны проекты 28
Процесс появления проекта 30
Треугольник управления проектами 33
Как изменение содержания проекта влияет на 37
бюджет и расписание
Как изменение бюджета влияет на проект 39
Как изменение сроков влияет на проект 41
О качестве 43
Так что же важнее всего: бюджет, сроки, 44
содержание работ или качество?
Проекты на голубой тарелочке с золотой 46
каемочкой
Термины управления проектами 47
Офис управления проектами (Project 51
management office)
Модель жизненного цикла проекта 52
Процессы управления проектами 58
Взаимодействие групп процессов 61
 Что делает руководитель проекта 62
Выводы 64
Глава 3 67
Как выбрать сертификацию 70
Что такое PMP 71
Глава 4 73
Что должно быть в уставе 76
Практические рекомендации по составлению 83
устава проекта
Выводы 86
Глава 5 87
Базовый план 91
Выводы 105
Глава 6 107
Как работать с рисками 108
Процессы управления рисками 110
Идентификация рисков 114
Качественный анализ рисков 118
Составление рейтинга риска 119
Количественный анализ 121
Планирование реагирования на риски 123
Реестр рисков 127
Контроль рисков 128
Выводы 129
Глава 7 131
Процесс подачи заявки 132
 Требования к заявке 133
Как проходит экзамен на PMP 135
Несколько полезных советов тем, кто 136
собирается сдавать экзамен
Глава 8 139
Глоссарий оценки 141
Как происходит процесс оценки 142
Методы оценки 143
Характеристики методов оценок 147
Точность оценки и предположения, на 148
которых основывается оценка
Подготовка оценки 151
Документирование и утверждение оценки 155
Что делать, если просят уменьшить оценку 156
Выводы 159
Глава 9 161
Глоссарий расписания проекта 162
Что же такое расписание проекта? 163
Визуализация расписания работ 165
Диаграммы предшествования 168
Метод критического пути 175
Как построить критический путь 176
Что делать, если длительность проекта нужно 187
сократить
Что делать, если проект опаздывает и не 191
укладывается в расписание
 Несколько советов по работе с расписанием 194
проекта
Глава 10 195
Глава 11 199
Цель управления стоимостью проекта 202
Виды затрат по проекту 203
Что такое невозвратные издержки и откуда 205
они берутся
Два экономических закона, влияющие на 207
проект
Базовый план стоимости проекта 211
Оценка эффективности расходования средств 213
Выводы 216
Глава 12 217
Управление интеграцией проекта 218
Управление ресурсами проекта 219
Управление коммуникациями проекта 220
Управление качеством проекта 221
Управление закупками проекта 222
Выводы 223
Глава 13 225
Как правильно мониторить проект 227
Использование метрик при оценке состояния 228
проекта
Примеры метрик 231
Корректирующие и превентивные действия 233
Глава 14 235
Быть технарем 236
Быть менеджером 237
Глава 15 240
Что такое команда проекта 241
Управление командой проекта 242
Как создавать команду 244
Командообразование 245
Развитие команды 250
Мотивация команды 251
Управление командой 254
Работа с людьми 256
Найм сотрудника 257
Как выбирать тех, кого пригласить на 258
собеседование
Собеседование 259
Принятие решения о приеме на работу 262
Предложение о работе 263
Ошибки при поиске и найме людей 265
Адаптация нового сотрудника в команде 267
Увольнение сотрудника 269
А можно ли обойтись без увольнения? 271
Обратная связь 272
Модели обратной связи 273
Активное слушание 275
Урегулирование конфликтов 276
 Делегирование 279
Принятие решений 283
Выводы 286
Глава 16 287
Глава 17 289
Планирование управления коммуникациями 292
Управление коммуникациями проекта 296
Мониторинг коммуникаций проекта 298
Как бороться с эмоциями 300
Выводы 301
Глава 18 302
Планирование качества (Quality planning) 305
Стоимость качества 307
Постоянное совершенствование 309
Обеспечение качества (Quality assurance) 311
Контроль качества (Quality control) 314
Качество и люди в управлении проектами 318
Выводы 320
Глава 19 321
Начало карьеры 325
О переходе из разработки в управление 327
проектами
Глава 20 330
Откуда берутся изменения 332
Как работать с изменениями в проекте 334
Как организовать управление изменениями в 340
 своем проекте
Выводы 342
Глава 21 343
Планирование управления 347
заинтересованными сторонами
Управление и контроль вовлечения 349
заинтересованных сторон
Как добиться доверия заказчика 352
Выводы 354
Глава 22 355
Процесс завершения проекта или его фазы 356
Операции по завершению проекта 357
Оценка проекта после его завершения 359
Семинары по завершению проекта 361
Накопленные знания и выученные уроки 363
Обязанности менеджера проекта 364
Оценка личных успехов менеджера проекта 365
Глава 23 369
Что дала мне программа МВА 372
Глава 24 374
Стратегические планы компании 376
Модели количественной оценки 377
Анализ рисков и их последствий 379
Анализ ограничений 380
Экономические модели 381
Выводы 387
Глава 25 388
Juno 390
Глазами Сергея 393
Глазами Алексея 396
Глава 26 400
Agile 401
Scrum 405
Kanban 419
Extreme Programming 427
Lean 430
Выводы 434
Глава 27 436
Заключение 446
 Алексей Минкевич,
Сергей Дерцап
Проджект-менеджмент.
Как быть профессионалом
Литературный редактор Е. Закомурная
Руководитель проекта И. Позина
Дизайнер А. Маркович
Корректор Ю. Семенова
Компьютерная верстка Б. Руссо

© А. Минкевич, С. Дерцап, 2020

© Оформление. ООО «Интеллектуальная Литература»,
2020

Все права защищены. Данная электронная книга предна-

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

⁂
 Предисловие
Почему появилась эта
книга и для кого она
Вся наша жизнь состоит из проектов: больших и малень-
ких, простых и амбициозных, сложных и захватывающих.
Все они имеют точку старта и финиша и уникальный резуль-
тат – продукт или услугу, которые мы создаем в ходе проек-
та.
Управление проектами – это искусство профессионально,
не допуская ошибок пройти путь от начала проекта до его
успешного завершения. Так опытный пилот проезжает спе-
цучасток ралли: уверенно, мастерски, красиво. Пусть со сто-
роны это может выглядеть очень сложно, но этому реально
научиться.
Помочь вам грамотно управлять своими проектами может
только опыт других людей, который накапливался десятиле-
тиями. Ведь все вопросы и проблемы, с которыми вы стал-
киваетесь каждый день, не новы. Сотни руководителей про-
ектов по всему миру уже все это проходили и знают верные
ответы на ваши вопросы.
Эта книга написана в соавторстве Алексеем Минкевичем
и Сергеем Дерцапом. У нас на двоих более 20 лет практиче-
ского опыта управления проектами. Кроме этого, несколько
раз в год мы читаем курсы по управлению проектами в ка-
честве хобби.
Чтобы книга не получилась обычной методичкой, мы ре-
шили добавить в нее краткое описание нашего карьерного
пути: как мы стали руководителями проектов, как учились,
ошибались и побеждали и как все это повлияло на нашу
работу. Названия этих глав будут начинаться так: «Карье-
ра:…». Если вы предпочитаете канонические учебники, мо-
жете смело пролистывать эти главы.
В работе над книгой нам очень помогли Леонид Лосич,
Екатерина Гаврилина, Александра Кирпичева, Ксения Ан-
тихович.
 Кому будет полезна эта книга
Начинающим руководителям проектов. В книге вы
найдете необходимую теоретическую базу и терминологию
и получите понимание того, что и в какой момент нужно
делать руководителю проектов. При этом неважно, в какой
отрасли вы работаете. В футбол играют разными мячами и
на разных полях, но правила для всех одинаковые. Так и
с управлением проектами. Методология отлично работает
везде: в строительстве, образовании, медицине, нефтедобы-
вающей отрасли, банковском и ресторанном деле.
Опытным руководителям проектов. Книга поможет
заполнить пробелы, упорядочить и структурировать суще-
ствующие знания. Ведь многие опытные коллеги самостоя-
тельно приходили к лучшим практикам, которые уже кто-
то давно изобрел и задокументировал. Любая ваша ситуация
или проблема на проекте не уникальна: кто-то в мире уже с
ней сталкивался и успешно разрешил. А если и не разрешил,
то извлек уроки, которые помогут нам преодолеть эти про-
блемы. Будем разбирать сложные моменты.
Владельцам бизнеса, которые хотят навести в нем
порядок, достичь большей управляемости и получить
больше контроля в собственной компании. Мы с Серге-
ем – айтишники, поэтому и примеры в книге будут из сферы
IT. Сейчас эта отрасль впереди планеты всей с точки зрения
управления проектами. Настоящие истории успеха в бизнесе
сегодня рождаются на стыке отраслей, когда лучшие прак-
тики из одной отрасли сочетаются с наработками из другой.
Если вы примените в своей сфере, в своей компании лучшие
практики управления проектами, то получите значительное
конкурентное преимущество.
Тем, кто стоит перед выбором: становиться руково-
дителем проектов или оставаться техническим специ-
алистом. Одни из самых популярных вопросов – «А что ме-
ня ждет, если я решу стать руководителем проектов?», «Что
изменится?», «Смогу ли я оставаться экспертом-ремеслен-
ником, ведь эксперту легко найти работу, а руководителю
сложно?». О поиске ответов на эти вопросы мы расскажем на
собственных примерах. Главы «Карьера:…» написаны для
вас.
Задача книги – поделиться с вами практическими навы-
ками и знаниями, помочь избежать ошибок в проектах и до-
стичь успеха.
Так что в добрый путь! Приятного чтения и учебы.
С уважением,
Алексей Минкевич и Сергей Дерцап
 Глава 1
Карьера: знакомство,
или как я попал в IT
Всем привет! Меня зовут Алексей Минкевич. В настоя-
щее время я возглавляю центр разработки на 100 человек,
построенный с нуля. У меня за плечами 20 лет опыта рабо-
ты в IT: 5 лет продуктовой разработки, 15 лет работы в аут-
сорсинге, десятки успешных проектов в роли руководителя
проектов, тимлида и разработчика. В этой главе я поделюсь с
вами тем, как все начиналось. Еще до университета со мной
случилось несколько хороших вещей, которые мне очень по-
могли в дальнейшей карьере и потому достойны упомина-
ния.
Когда я был совсем маленьким, мама настояла, чтобы я
учился не в ближайшей школе вместе с друзьями со двора, а
в языковой гимназии с углубленным изучением английского.
Я помню эти бесконечные десять минут езды на троллейбусе
в школу и обратно, изо дня в день. Но, как оказалось потом,
это того стоило.
В восьмом классе два моих друга записались в кружок
программирования. Там были космические на тот момент
персональные 286-е компьютеры. «Вот это да!» – подумал я
и напросился в группу. Мы учили язык программирования
Pascal. Учили, конечно, очень условно – чаще играли в иг-
ры. Правда, всю «старую школу» мы еще застали: запуска-
ли компьютеры с дискеты, учили DOS и Norton Commander.
Там, в доме Юного Творчества 1 на Макаёнка, я увлекся про-
граммированием.
Я хорошо помню момент, который изменил мое отноше-
ние к учебе.
Моя мама работала программистом в Научно-исследо-
вательском институте электронно-вычислительных машин
(НИИЭВМ). Раз в год в НИИЭВМ проходил день открытых
дверей, когда можно было посмотреть на компьютеры, по-
ходить по коридорам и даже поиграть пять минут в первые
компьютерные игры. В течение нескольких лет я был уверен,
что у всех на работе именно так.
В девятом классе я был троечником и хулиганом, но про-
изошло одно интересное событие. На уроке гражданской
обороны нас повели на экскурсию в бомбоубежище завода
«Термопласт». А после бомбоубежища провели по цехам.
Завод выпускал изделия из пластмассы: ведра, дуршлаги и
прочие полезные в хозяйстве вещи. Тогда, в 1990-х гг., цеха
завода выглядели страшно. Все было в грязи, отовсюду раз-
давался лязг станков и грохот прессов. Стоял сильный горе-
ло-химический запах, и на вдохе покалывало в груди. По уг-
лам валялись запчасти, мусор и бракованные изделия. Сре-
1
Речь идет о Республиканском Доме технического и художественного творче-
ства учащейся молодежи, г. Минск.
ди всего этого с унылым видом ходили рабочие в кирзовых
сапогах и телогрейках.
Контраст с маминой работой был настолько сильным, что
в тот день я четко понял, что на заводе работать не хочу. И
стал серьезно относиться к учебе.
И еще я прошел жесткую школу пионерского лагеря. С 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

2
Если в конце главы не указан автор написанного, подразумевается, что текст
был создан в соавторстве.
 Глава 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, SAP и дру-
гих современных подходов и инструментов.
8. Воплощение мечты в жизнь. Например, проект по
созданию собственной команды по автоспорту или органи-
зация кругосветного путешествия.
На первом шаге бизнес определяется со своей целью. По-
том компания начинает рассматривать возможные вариан-
ты решения, пытаясь ответить на вопрос о том, как именно
можно достичь цели. Если вариантов несколько, то на следу-
ющем этапе выбирается один из них – и рождается проект.
После того как проект становится реальностью, бизнес про-
веряет, достигнута ли цель.
 Процесс появления проекта
Процесс появления проекта схематически показан на ри-
сунке 1.

Давайте разбираться на примере. Допустим, существует

банк. Совет директоров ставит стратегическую задачу: уве-
личить количество клиентов на 1 млн человек. Каким обра-
зом можно достичь этой цели?
Список возможных решений выглядит примерно так:
● установить рекламные билборды по всей стране;
● запустить рекламу на радио и телевидении;
● открыть новые отделения банка в населенных пунктах,
где еще нет представительств;
● привлечь новых клиентов из населенных пунктов, где
еще нет представительств банка, при помощи мобильных
пунктов продаж услуг.
Для последнего варианта нужно разработать мобильное
приложение, способное проверить паспортные данные и от-
крыть счет. Идея в том, что сотрудник банка берет мобиль-
ный телефон с установленным приложением и сумку с кон-
вертами. В каждом конверте есть кредитная карточка с ба-
лансом в 100 руб. Сотрудник едет в населенный пункт, где
еще нет отделения, и начинает рекламировать продукт бан-
ка – мини-кредит. Те, кто заинтересовался, могут сразу же
предоставить необходимую информацию о себе. При по-
мощи мобильного приложения сотрудник банка проверяет
эту информацию, открывает счет и привязывает к нему по
штрих-коду кредитную карточку с деньгами. Таким образом,
человек сразу получает кредит в 100 руб., а банк – нового
клиента.
Совет директоров банка принимает решение остановить-
ся на последнем варианте. Важно понимать, что цель бизне-
са и цель проекта – это не одно и то же. В данном примере
цель бизнеса – миллион новых клиентов. А цель проекта –
разработать мобильное приложение под Android OS, которое
умеет фотографировать паспорт, отправлять фото паспорта
и обмениваться информацией с серверами банка.
Приложение должно позволять сотруднику банка совер-
шать следующие действия:
● пройти авторизацию в приложении;
● используя камеру телефона, сфотографировать паспорт
потенциального клиента. Приложение должно распознать
штрих-код паспорта, отослать картинку и данные штрих-ко-
да в расчетный центр банка, где за пять секунд потенциаль-
ный клиент проходит проверку системы безопасности. Затем
принимается решение, можно ли открыть ему кредит с ли-
митом в 100 руб.;
● если ответ положительный, приложение должно счи-
тать QR-код с конверта с картой, создать нового пользовате-
ля в банке и привязать к нему кредитную карточку, а потом
подтвердить успешность операции.
Важным требованием является возможность работы при-
ложения в условиях медленного мобильного интернета (на
тот случай, если в населенном пункте нет 3G).
Только после этого представитель банка может выдать но-
вому клиенту карточку с кредитом в 100 руб. Чтобы активи-
ровать ее, клиенту необходимо приехать в ближайшее отде-
ление банка и подписать соответствующий договор.
Проект оказался очень успешным. С его помощью банку
удалось привлечь 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-проектах, с которыми я сталкиваюсь, основным огра-

ничением обычно является время. Когда становится понят-
но, что к сроку все запланированные задачи не успеть, обыч-
но жертвуют частью содержания работ. Чтобы владельцу
бизнеса не было обидно, что он не получил часть изначально
запланированного функционала, реализацию части проекта
переносят на последующие этапы.
Реже ключевым ограничением бывает бюджет или содер-
жание работ. Первая задача менеджера проекта – еще в са-
мом начале выяснить, что приоритетнее для бизнеса: бюд-
жет, сроки или содержание работ. И уже исходя из этого пла-
нировать проект.
 О качестве
Вы, наверное, заметили, что в треугольнике тройственно-
го ограничения есть еще такой параметр, как качество. Так
вот, его бы я тоже добавил к ограничениям проекта. Под ка-
чеством обычно подразумевается удовлетворенность бизне-
са характеристиками итогового продукта.
В работе с качеством можно использовать несколько так-
тик: можно пытаться доводить все до идеала, но сорвать
сроки. А можно, видя, что сроки горят, пожертвовать каче-
ством и уложиться в отведенное время. Например, вы выво-
дите на рынок новое приложение интернет-банкинга. Если
у 1 % пользователей происходит некритичная ошибка, ко-
торую можно обойти, бизнес может решить не срывать сро-
ки выхода продукта, а выпустить на рынок приложение, как
планировалось, и исправить дефект в следующих обновле-
ниях.
В нашем примере проекта ужина с друзьями мы немно-
го пожертвовали качеством ужина и поменяли мясо на сар-
дельки, но зато успели подготовиться к приему гостей.
 Так что же важнее всего:
бюджет, сроки, содержание
работ или качество?
Практически во всех проектах одно из ограничений бу-
дет являться самым важным для заказчика. В одном проекте
это может быть строго фиксированный бюджет: например,
10 000 руб. на ремонт, не больше. В другом – четкая дата
завершения или дедлайн: скажем, начало Олимпийских игр
перенести нельзя. В третьем – необходимость выполнения
всего объема работ. Очень важно знать это основное огра-
ничение проекта.
Но самое главное – это сделать так, чтобы бизнес был до-
волен результатом проекта. Часто возникают ситуации, ко-
гда вы можете не уложиться в сроки, не вписаться в бюджет,
даже сделать не совсем то, о чем изначально шла речь. Но
бизнес будет доволен и признает проект успешным, так как
он получил то, что ему было нужно. А можно все сделать как
по книжке: все работы проекта выполнять строго по техни-
ческому заданию, в срок и в рамках бюджета, но итоговый
продукт окажется ненужным, устаревшим или просто не сра-
ботает. Тогда бизнес будет «грустить», а проект не принесет
успеха.
Вся суть управления проектами заключается в навыке
умело управлять содержанием работ, расписанием, стоимо-
стью и качеством, чтобы сделать бизнес счастливым и при-
вести проект к успеху.
 Проекты на голубой тарелочке
с золотой каемочкой
Очень редко бывают проекты, где нет одного из ограни-
чений. Заказчик очень богат и не считает деньги. Или вре-
мени в вашем распоряжении сколько угодно. По-английски
такие проекты называются gold-plated. Нам с Сергеем такие
еще не попадались.
 Термины управления проектами
В управлении проектами, как и в любой другой области,
есть своя терминология и язык, на котором общаются руко-
водители проектов во всем мире. По ходу книги нам встре-
тится множество терминов, которые нужно знать. Давайте
начнем с основных.
Спонсор проекта (Project sponsor) – это человек, кото-
рый выделяет деньги или другие ресурсы для реализации
проекта. Примером других ресурсов могут быть помещения
для работы, свет и вода, инструменты, расходные материалы.
По отношению к компании, в которой выполняется про-
ект, спонсоры бывают двух типов – внешние и внутренние.
Под внешним спонсором мы понимаем заказчика проек-
та. Это человек в компании-заказчике, который иницииро-
вал проект и будет принимать непосредственное участие в
приемке его результатов.
Внутренний спонсор – это непосредственный руководи-
тель менеджера проекта. Он выделяет ресурсы на работу ко-
манды: помещение, мебель, компьютеры и прочее.
Если вы работаете с внешним заказчиком (внешний про-
ект), то спонсора будет два. Например, вы являетесь руково-
дителем проектов в компании, которая занимается изготов-
лением макетов. Завод «МАЗ» заказал у вашей компании
макет грузовика в масштабе 1:10, чтобы участвовать с ним
в выставке. Внешним спонсором в таком проекте будет ру-
ководитель завода. Он платит за готовый макет грузовика.
Внутренним спонсором будет директор компании – произ-
водителя макетов. Он выделяет помещения для работы, про-
ектировщика модели, время станка с ЧПУ для изготовления
деталей и двух инженеров, которые соберут и покрасят мо-
дель.
Но иногда, особенно в крупных компаниях, случаются
внутренние проекты. Например, проекты по внедрению но-
вых процессов или автоматизации старых. В таких проектах
только один спонсор – непосредственный руководитель. Он
выделяет все нужные ресурсы.
Программа проектов – это ряд взаимосвязанных между
собой проектов, которые координируются централизованно.
Делается это для повышения уровня управляемости.
Как это выглядит на примере. Допустим, у нас в подраз-
делении есть проект А, в котором ведется разработка систе-
мы заказа продуктов с доставкой на дом. Над ним трудят-
ся 12 человек. А еще у нас есть проект В, в котором разра-
батывается система поддержки платформы для заказа про-
дуктов. Она необходима для работы специалистов колл-цен-
тра и позволяет отслеживать функционирование основной
системы, а также решать вопросы, возникающие у клиентов
сервиса. В проекте В задействована команда из четырех че-
ловек. Эти проекты можно объединить в одну программу,
чтобы добиться лучшей их управляемости.
 О какой управляемости речь? Допустим, я как руководи-
тель программы вижу, что в проекте А дела идут хорошо
(ребята справляются, мы укладываемся в сроки), а вот про-
ект B буксует (сроки срываются). Тогда я принимаю реше-
ние взять человека из проекта А и перевести его на проект
B, чтобы усилить команду последнего и вовремя выпустить
новые функции всей платформы.
Портфель проектов (Project portfolio) – это категория,
стоящая выше программы проектов. Портфель включает в
себя как целые программы, так и отдельные проекты. Раз-
ница между программой и портфелем в том, что на уровне
портфеля бизнесом принимаются стратегические решения.
Как правило, уровень принятия решений здесь – совет ди-
ректоров или владелец бизнеса.
Например, программа проектов А идет хорошо и все по-
лучается. Но владелец бизнеса знает, что есть нечто, что в
будущем может приносить более высокую прибыль. Пусть
это будет направление криптовалют. Он решает создать про-
грамму проектов B, которая и будет работать в этом направ-
лении. Причем людей в команду новой программы В пере-
ведут из программы А – это инвестиции в будущее.
Есть хороший пример из реальной жизни, когда владелец
бизнеса не решился на такой шаг, что привело к упадку ком-
пании. Компания Kodak была мировым лидером в производ-
стве фото- и кинопленки, можно сказать, монополистом. Ин-
женеры именно этой компании первыми придумали фото-
чувствительные матрицы и технологию цифровой фотогра-
фии. Опасаясь, что новая технология убьет основной биз-
нес – производство фотопленки, – руководство решило оста-
новить работы в направлении цифровой фотографии. Кон-
куренты вышли на рынок с этим продуктом спустя несколь-
ко лет, и Kodak полностью утратила лидирующие позиции.
Разница между портфелем и программой проектов доста-
точно тонкая, но есть еще одно различие: программа проек-
тов – это взаимосвязанные проекты, и результат одного из
них используется другим. Например, в рамках одного проек-
та делают заготовки для двигателей, на втором проекте про-
исходит точная обработка, подгонка и сборка двигателей, на
третьем двигатели устанавливают в спортивный автомобиль
и производят настройку всей машины под конкретное топ-
ливо. Это программа проектов.
В портфеле этой компании может быть производство не
только спортивных автомобилей, но и гоночных лодок, са-
молетов, симуляторов управления гоночной техникой.
Если у вас абсолютно независимые друг от друга проекты,
да еще и для разных заказчиков, то это будет портфель про-
ектов, то есть результаты одного проекта никак не влияют на
результаты другого.
 Офис управления проектами
(Project management office)
В некоторых компаниях существует отдельная структу-
ра – офис управления проектами. Название может быть и
иным – например, отдел качества. Важно не название, а то,
чем занимается эта команда. Ее задача – помочь руководите-
лям проектов работать по правилам и в соответствии с про-
цессами, принятыми в компании. Дело в том, что у каждой
компании свои процессы, которые шлифовались годами и
подходят ее бизнесу и сотрудникам. Если компания работает
успешно, то эти процессы верны. Офис управления проек-
тами документирует и стандартизирует процессы, помогает
руководителям следовать им, тем самым повышая качество
работы.
Так что если к вам как к менеджеру проекта приходит кто-
то из проектного офиса и спрашивает о состоянии дел, то
не нужно отмахиваться от этого человека – он хочет помочь.
Для вас это хорошая возможность спросить совета и полу-
чить консультацию. В таких отделах, как правило, работают
очень опытные люди, у которых можно многому научиться.
 Модель жизненного цикла проекта
Работа над проектом похожа на путь от неизвестного к
определенному. В ходе работы команда получает много но-
вой информации и учится. Итог этого процесса обучения –
новый продукт, сервис или услуга. Чем больше похожих про-
ектов сделала команда и чем больше она знает об индустрии,
в которой работает, тем меньше будет рисков на пути и тем
быстрее проект будет выполнен.
Какие стадии развития проекта существуют?
Стадия инициации проекта. На этом этапе спонсоры
проекта определяют, каким будет проект: его цель, содержа-
ние работ, бюджет и время, к которому работы нужно завер-
шить. На этой стадии назначается руководитель проекта, а
самому проекту дается официальный старт.
Планирование проекта. На этой стадии начинается ра-
бота над проектом и детально планируется, что именно нуж-
но сделать и с каким уровнем качества. Далее производит-
ся оценка необходимого времени, денег, человеческих ре-
сурсов и т. д. Во время этого процесса часто происходит пе-
реутверждение условий проекта, поскольку на данном этапе
аккумулируется больше новой информации, которая может
оказать влияние на ход проекта.
 Выполнение работ. Это самая затратная часть всего
проекта: именно в нее вовлечено больше всего людей и дру-
гих ресурсов. На этой стадии выполняются работы, заплани-
рованные на предыдущем этапе.
Завершение проекта. На этом этапе работы заверша-
ются, а заказчик принимает результаты. Менеджер и коман-
да оценивают, как прошел проект, и выносят из него уроки,
чтобы не повторять ошибки в будущем.
Вот так выглядят крупные артефакты (результаты) каждо-
го этапа и количество вовлеченных в проект ресурсов в за-
висимости от этапа, на котором проект находится (рис. 7).
В начале проекта на этапе инициации в работу вовлече-
но немного людей: спонсоры и менеджер проекта. На этапе
планирования добавляется архитектор и начинает собирать-
ся команда. Во время выполнения работ количество вовле-
ченных людей достигает своего пика. А когда работы выпол-
нены и нужно сдавать результаты проекта, количество вовле-
ченных людей сокращается.
 Говоря о стадиях проекта, нельзя не упомянуть о рисках.
Их количество напрямую зависит от того, на какой стадии
реализации находится проект. Например, в начале проекта
рисков больше всего: команда еще не до конца понимает,
что делать, она оказалась в незнакомой ситуации и не может
предсказать, что будет.
 По мере планирования и дальнейшей работы над проек-
том количество рисков снижается. Команда получает боль-
ше информации, и уровень неопределенности падает. Уже к
середине проекта количество рисков уменьшается вдвое, а в
конце их почти не остается (рис. 8).
Со стоимостью внесения изменений в проект все наобо-
рот. На начальном этапе изменения можно вносить как угод-
но, и это будет бесплатно или недорого. Но чем дальше бу-
дет продвигаться проект, тем дороже будет стоить внесение
изменений (рис. 9).
Давайте рассмотрим на примере. Мы решили постро-
ить дом. Если на этапе проектирования задумаем одноэтаж-
ный деревянный дом, а потом, поразмыслив, решим строить
двухэтажный каменный, то эти изменения нам не будут сто-
ить почти ничего, разве что придется переделать проект до-
ма. Но если мы решим внести такие изменения, когда уже
залит фундамент, то нам, скорее всего, придется не просто
переделывать проект, но и перезаливать фундамент, чтобы
он выдержал увеличившийся вес дома.
 Процессы управления проектами
На схеме ниже представлены процессы управления про-
ектами (рис. 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-код с конверта с кредитной картой, создать нового
пользователя в банке и привязать к нему кредитную карточ-
ку, а потом подтвердить успешность операции.
Важным требованием является возможность работы при-
ложения в условиях медленного мобильного интернета (на
тот случай, если в населенном пункте нет 3G).
Только после этого представитель банка может выдать но-
вому клиенту карточку с кредитом в 100 руб. Чтобы активи-
ровать ее, клиенту необходимо приехать в ближайшее отде-
ление банка и подписать соответствующий договор.
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) – факторы в
рамках процесса планирования, которые считаются верны-
ми без предоставления доказательств и демонстраций. Здесь
же описывается влияние этих факторов на проект. Это пред-
положения, с которыми согласны и вы, и спонсор проекта.
Без этих предположений дальнейшее планирование проекта
невозможно. В случае, если допущение не срабатывает, про-
ект обычно требует изменения подхода и серьезного пере-
планирования. Например, если мы предполагали, что суще-
ствующая инфраструктура в состоянии поддержать работу
нового программного обеспечения, но это оказалось не так –
придется или покупать новый сервер, или вносить в систе-
му существенные изменения, которые позволят ей работать
на старом железе. Возможно, вообще понадобится написать
новую систему, используя другую технологию.
С терминами разобрались, теперь перейдем к основной
части.
 Базовый план
Базовый план – это первоначальный план проекта, утвер-
жденный спонсором. Этот план используется для сравнения
текущего положения дел в проекте с тем, что было заплани-
ровано изначально.
Для чего это нужно? Жизнь всегда вносит коррективы в
любой план. Например, я задумал повесить три светильни-
ка. Плановая стоимость светильников – 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-plated, или про-
екты «на голубой тарелочке с золотой каемочкой», в которых
бюджет и сроки неограниченны. В таких проектах реализу-
ются абсолютно все пожелания. Правда, такое бывает неча-
сто. В большинстве случаев у менеджера есть ограничения
расписания или бюджета. Соответственно, ему нужно разде-
лить пожелания того, что будет реализовано, – требования,
и того, что в рамках этого проекта создано не будет, – исклю-
чения. В требованиях нужно оставить то, что действительно
важно для достижения цели проекта и цели бизнеса, без че-
го бизнес остановится. Все остальное уходит в исключения.
Задача руководителя проекта на данном этапе – помочь за-
казчику с этим делением, предоставить больше информации
и разъяснить спорные моменты. Также нужно напомнить за-
казчику, что часть работ, необязательных для этого проекта,
всегда можно внести в содержание следующего совместного
проекта.
2. Как выглядят хорошие требования?
Требования должны быть однозначными, то есть измеря-
емыми и проверяемыми. Следует избегать размытых фор-
мулировок и фраз типа «и т. д., и т. п.», «интуитивно по-
нятный отчет», «дружественный пользователю интерфейс»
и тому подобных.
Пример из практики. Знакомый бизнесмен, владеющий
бизнесом по разработке и внедрению CRM, заключил дого-
вор с крупной логистической компанией. В договоре очень
хорошо и детально была описана CRM, а также имелась сле-
дующая формулировка: «Система должна генерировать сле-
дующие отчеты: 1. (описание), 2. (описание), 3. (описание),
4. (описание), 5. (описание), 6. (описание), 7. (описание), 8.
(описание), 9. (описание), 10. (описание), и т. д.».
После сдачи проекта заказчик не захотел подписывать акт
приемки и под пункт «и т. д.» попросил сделать еще один
отчет, а потом еще один, и еще… В итоге компания-испол-
нитель еще год занималась созданием отчетов в рамках кон-
тракта абсолютно бесплатно.
Требования должны иметь четкий критерий завершенно-
сти (definition of done). У менеджера должно быть четкое
определение того, что считать выполненным. Кто-то счита-
ет, что уборка сделана, когда носки спрятаны под кровать, а
для кого-то уборка – это вымытый с содой пол.
Хорошие требования – это полные требования. Менеджер
обязан собрать их у всех заинтересованных сторон. В самом
начале важно не упустить людей, влияющих на проект, и их
требования, в противном случае они будут блокировать сда-
чу проекта.
Требования должны быть описаны максимально четко и
детально, чтобы их поняли все заинтересованные стороны.
Хорошая практика – если вы работаете в IT, дать почитать
их кому-нибудь из сферы, не связанной с IT. Если человек
поймет, что нужно сделать, значит, работа с требованиями
проведена хорошо.
Картинка в большинстве случаев говорит лучше слов.
Мокап интерфейса – набросок того, как будут располагаться
элементы на экране, – всегда лучше фразы «интуитивно по-
нятный интерфейс». Используйте в требованиях как можно
больше картинок или прототипов.
Самое главное: требования должны быть задокументи-
рованы и согласованы со всеми ключевыми заинтересован-
ными сторонами. Документирование – это один из лучших
способов избежать разрастания содержания проекта (scope
creep). В любом проекте заказчик постарается добавить но-
вые работы, и содержание начнет разрастаться. Лучше всего
я прочувствовал это на проектах, где сам выступал заказчи-
ком.

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

Иерархическая структура работ (ИСР) – это список работ,

которые необходимо выполнить, чтобы успешно завершить
проект. ИСР формируется на базе требований к проекту и
отражает только те работы, которые нужно выполнить в ходе
проекта. Если в ИСР какой-то работы нет, то она не входит
в проект, а значит, делать ее не нужно.
Вот определение ИСР из PMBOK: «иерархическая деком-
позиция полного содержания работ, выполняемых командой
проекта для достижения целей проекта и создания требуе-
мых поставляемых результатов».
Суть понятия иерархической структуры работ лучше все-
го иллюстрирует следующий пример. Если вы идете в мага-
зин или собираетесь в поездку, вам нужно составить список
дел (To do list), которые необходимо сделать, чтобы ничего
не забыть. Например, собираясь в поездку, вы обычно со-
ставляете примерно такой список:
1. Собрать чемодан:
● пять пар носков;
● пять трусов;
● шесть маек;
● теплый свитер;
● удобные ботинки;
● косметичка с бритвой, шампунем, зубной щеткой и т. д.
2. Собрать рюкзак:
● ноутбук;
● наушники;
● зарядное устройство для ноутбука и телефона;
● бутерброды;
● бутылка воды.
3. Собрать документы/деньги:
● паспорт;
● водительские права;
● кошелек (наличные + две карточки).
Это и есть иерархическая структура работ (ИСР) ми-
ни-проекта сборов в дорогу. Когда мы выполнили все пунк-
ты, проект готов.
ИСР – это основа планирования проекта. Если у менедже-
ра нет четкого списка работ, то он не может посчитать, сколь-
ко будет стоить проект и сколько времени на него понадо-
бится. ИСР помогает структурировать и определить все со-
держание проекта. ИСР можно создавать в формате струк-
турированного списка, как в нашем примере, или в виде де-
рева (рис. 11).

При создании ИСР руководитель проекта должен деком-

позировать работы до того уровня, когда он сможет управ-
лять ими. Работы, находящиеся на нижнем уровне ИСР, на-
зываются пакетами работ. О пакете работ менеджер должен
знать три вещи:
1) кто его будет выполнять;
2) сколько времени на это понадобится;
3) как проверить, что работа готова.
Этих знаний менеджеру достаточно, чтобы эффективно
контролировать исполнение. Обратите внимание, что созда-
ние ИСР – это лишь перечисление дел, которые нужно сде-
лать в проекте. На этом этапе еще не важна оценка времени
или бюджета, а также последовательность выполнения опе-
раций. Ответы на эти вопросы будут получены на этапе оцен-
ки и составления расписания проекта.
Детализируя работы до уровня пакетов, менеджер проекта
должен понимать, какой специалист ему понадобится для ре-
шения конкретной задачи (разработчик или тестировщик),
сколько времени ему/ей понадобится на выполнение работы
и как проверить готовность задачи. Без этих данных мене-
джер не сможет управлять работами проекта.
Рекомендованный размер пакета работ – 40 часов, так как
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. Словарь ИСР и для чего он нужен

Сам формат ИСР подразумевает краткость формулиро-

вок, но в процессе ее создания у менеджера возникает много
вопросов, мыслей и идей. Чтобы их не потерять, можно ис-
пользовать словарь ИСР. По сути, это документ, в котором
менеджер оставляет заметки к конкретным задачам. В элек-
тронных инструментах работы с ИСР это могут быть специ-
альные поля типа Notes или «Заметки».
 Выводы
Даже если вы провели прекрасную работу по сбору и
утверждению требований, вам следует постоянно быть гото-
вым к изменениям. Бизнес меняется, и его требования меня-
ются тоже. И когда вас как менеджера проекта просят внести
изменения, не нужно отказываться, ссылаясь на подписан-
ные ранее документы. Если бизнесу что-то потребовалось,
то у него на это есть свои причины. И если новые требования
отвечают целям бизнеса, то нужно их принимать и согласо-
вывать вместе со всеми изменениями в содержании работ,
бюджете и расписании.
Не бывает проектов, в которых не было бы изменений. Да-
же если речь о небольшом двухнедельном спринте, то, ско-
рее всего, даже на этом отрезке появятся какие-то корректи-
ровки. Изменения – это хорошо, мы им рады и умеем ими
управлять, но об этом будет отдельная глава.
Работая по модели с MVP (минимально жизнеспособный
продукт) и прототипом, мы много раз сталкивались с од-
ним интересным заблуждением. 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 единиц.
Риски – это «известное неизвестное», так как мы их вы-
явили и подготовились к ним. Существует еще такое поня-
тие, как «неизвестное неизвестное» – непредвиденные об-
стоятельства. Как правило, менеджер и команда даже пред-
ставить себе их не могут, не говоря уже о том, чтобы оценить
вероятность возникновения.
Как правило, на такие события в каждом проекте преду-
смотрен управленческий резерв. Его величина обычно до-
стигает 10 % от бюджета проекта.
Давайте определимся, в чем разница между резервом на
возможные потери и управленческим резервом (табл. 2).
 Реестр рисков
Реестр обновляется после каждого промежуточного этапа
проекта. В него вносится следующая информация:
● выявленные риски и их описание, включая причины их
возникновения, триггеры и возможное влияние на цели про-
екта;
● результаты качественного и количественного анализа;
● согласованные стратегии реагирования для каждого
риска и действия, необходимые для активации стратегий ре-
агирования;
● кто «владеет» теми или иными рисками и несет за них
ответственность.
Вот пример реестра рисков для проекта по внедрению
единого решения автоматизации бизнес-процессов в сети го-
стиниц (рис. 14).
 Контроль рисков
У каждого риска должен быть человек, который за него от-
вечает. Это может быть любой член команды. Задача ответ-
ственного лица – наблюдать за триггерами, то есть событи-
ями, которые могут спровоцировать наступление риска, от-
слеживать их приближение и убеждаться, что мероприятия
по реагированию на риск выполняются. Задача руководите-
ля – следить, чтобы процессы управления рисками работали.
 Выводы
Управление рисками хорошо начинать во время создания
иерархической структуры или сразу после того, как она го-
това. Когда у вас перед глазами есть список дел по проекту,
вам гораздо легче идентифицировать риски, связанные с ра-
ботами проекта. Работа с рисками помогает уточнить содер-
жание проекта. Это как следующий уровень проработки дел
проекта. От каких-то очень рискованных дел можно отка-
заться. Для надежного выполнения других работ что-то по-
надобится добавить.
В случае, если мы принимаем стратегию снижения для
рисков, направленная на доведение риска до приемлемо-
го уровня работа должна быть включена в иерархическую
структуру работ проекта, оценена и внесена в расписание
проекта. Управление рисками – это не разовый, а повторяю-
щийся процесс. Как часто вы будете его повторять, зависит
от текущего состояния проекта, его новизны для команды и
уровня лояльности к рискам в компании.
 Завершить эту главу хотелось бы цитатой из книги Тимо-
ти Листера и Тома Демарко «Вальсируя с медведями»: «Из-
бегать рисков – дело проигрышное. Раньше вы могли бы от-
нестись к проекту, свободному от рисков, как к неожидан-
ному подарку судьбы и благодарили бы звезды за эту ред-
кую удачу – легкий проект. Мы реагировали так же. Какими
глупцами мы были! Проекты без риска – удел неудачников».
 Глава 7
Карьера: экзамен PMP
После полутора лет подготовки я все-таки решил, что
пришло время попробовать свои силы и подать заявку на
сдачу экзамена.
 Процесс подачи заявки
Указанный ниже процесс актуален на момент выхода кни-
ги. Мы рекомендуем проверить, не произошли ли измене-
ния, на сайте https://www.pmi.org/.
Шаг 1. На сайте pmi.org необходимо заполнить заявку, в
которой нужно рассказать о себе и своем опыте управления
проектами.
Шаг 2. PMI рассматривает заявку. Если все хорошо, то
ее утверждают. Если нет – просят доработать. При этом, как
показывает мой личный опыт, около 15 % заявок проверя-
ется усиленно. Если попасть в это число, то для проверки
вас попросят отправить по почте бумажные копии сертифи-
катов, подтверждающих пройденное обучение. Также потре-
буется письменное подтверждение опыта управления проек-
тами. Для этого будут необходимы копии документов про-
екта, если это возможно, или письмо от руководителя, под-
тверждающее ваш опыт.
Шаг 3. Оплата экзамена. После оплаты вы получаете код,
который позволяет выбрать и назначить дату и время экза-
мена. Сдать можно в любом из специализированных центров
компании Prometric, которая проводит экзамены и сертифи-
кацию по всему миру.
Шаг 4. В назначенное время прийти в выбранный центр
и сдать экзамен.
 Требования к заявке
Мы приводим требования, актуальные на момент выхода
книги, и рекомендуем проверить, не произошли ли измене-
ния, на сайте https://www.pmi.org/.
● 4500 часов опыта работы менеджером проектов в тече-
ние последних 36 месяцев – для кандидатов с высшим обра-
зованием. Для кандидатов без высшего образования – 7500
часов опыта работы менеджером проектов в течение послед-
них 60 месяцев. В заявке нужно описать проекты, над кото-
рыми вы работали, указать общее количество часов, отрабо-
танное в проекте, и детализировать, чем именно вы в нем
занимались. Детализация структурируется по областям зна-
ний.
Можно указывать опыт тех проектов, где вы не были руко-
водителем непосредственно, но занимались задачами управ-
ления. Например, выполняли роль бизнес-аналитика и рабо-
тали с требованиями проектов. Эти часы также учитывают-
ся. Для каждого проекта нужно указывать контактное лицо,
которое сможет подтвердить эту информацию. Это может
понадобиться, если вашу анкету выберут для детальной про-
верки: этот человек должен будет письменно подтвердить за-
явленную информацию.
● 35 часов обучения управлению проектами (Personal
Development Units). Это часы, которые вы провели на учеб-
ных курсах по управлению проектами и других обучающих
мероприятиях, например конференциях и вебинарах. Здесь
важно иметь сертификат или иное подтверждение, что вы
действительно прошли обучение. Если вашу анкету выберут
для детальной проверки, то копию сертификата необходимо
будет отправить в PMI. Раньше это требование было строже,
поскольку принимались сертификаты только от зарегистри-
рованных в PMI учебных центров. Но теперь любое обуче-
ние, подтвержденное документально, подходит под это тре-
бование.
После отправки заявки я волновался, но уже через
несколько дней пришел ответ, что все в порядке и я допущен
к экзамену. Ближайшие Prometric-центры, где можно было
сдать экзамен, находились в Москве, Санкт-Петербурге, Ки-
еве и Вильнюсе. Я выбрал Питер.
 Как проходит экзамен на PMP
Экзамен считается успешным, если у вас минимум 63 %
правильных ответов. Пусть процент и кажется невысоким,
но верно нужно ответить на 130 вопросов из 200.
Тест длится четыре часа и содержит 200 сложных си-
туационных вопросов с четырьмя вариантами ответов. Из
них нужно выбрать наиболее подходящий. Это оказалось
несколько сложнее, чем в привычных мне технических экза-
менах, где один вариант обычно верный, а остальные три –
нет. Здесь же есть два-три верных варианта, а потому нужно
решить, какой из них самый подходящий. Еще один важный
момент: в длинном тексте вопроса нужно уметь найти суть
и отличить основную информацию от «шума».
 Несколько полезных советов тем,
кто собирается сдавать экзамен
● Указывая в заявке опыт управления проектами, важно
не ошибиться с количеством часов. Создайте Excel-файл с
разбивкой вашего опыта на области знаний по каждому про-
екту, а затем зафиксируйте в нем свой рабочий опыт. Мне
кажется, что лучшим подходом будет не указывать в заявке
требуемый минимум в 4500 часов, а не полениться и указать
все проекты, над которыми вы работали. Чем больше часов,
тем, как мне кажется, лучше выглядит ваша заявка.
● При подаче заявки на экзамен укажите, что вам нужна
русская версия экзамена. Дело в том, что вопросы экзаме-
на составлены американцами с использованием неадаптиро-
ванного языка. Я считаю, что хорошо знаю английский язык,
но без перевода я бы не смог понять смысл десятка вопро-
сов. Пользоваться же словарем, который доступен в центрах
Prometric, – трата ценного времени.
● На экзамене нужно иметь максимально светлую голо-
ву. За пару дней до экзамена лучше прекратить подготовку
и дать себе отдохнуть и набраться сил. Еще важно хорошо
выспаться накануне.
● Если вы не уверены в том, какой ответ на вопрос пра-
вильный, пометьте его, чтобы можно было быстро к нему
вернуться. Очень часто в одном из следующих вопросов
встречается правильный ответ на вопрос, в котором вы не
уверены. В таком случае можно вернуться к проблемному
вопросу и ответить на него верно. Особенно это актуально
для вопросов на входы-выходы процессов.
● Если у вас осталось время, не пробуйте перепроверять
ответы на все вопросы подряд. После серьезной нагрузки, к
концу экзамена, голова работает намного хуже, и вы рискуете
исправить верные ответы на неверные.
● Перед экзаменом я выписал на лист все формулы и ин-
формацию, которую мне было сложно запомнить. Перед тем
как зайти в Prometric-центр, я внимательно просмотрел этот
лист глазами. На входе у вас попросят сдать все вещи, но
в экзаменационном кабинете у каждого экзаменуемого есть
бумага и ручка. Не начиная тест, я первым делом по памяти
записал на лист все формулы и сложную для меня информа-
цию. Этот лист мне здорово помог в ходе экзамена, посколь-
ку от напряжения и потери сил уже к середине экзамена я не
был уверен ни в чем.
Я успешно сдал экзамен. Впереди меня ждали интерес-
нейшие проекты, много работы и увеличение зарплаты за до-
стижения. Я же был единственным сертифицированным ру-
ководителем проектов в большой компании! Так я думал по
дороге домой и широко улыбался. Реальность же оказалась
совершенно иной, но об этом позже.
Сейчас давайте посмотрим, что делать в проекте на этапе
оценки и построения его расписания.
Алексей Минкевич
 Глава 8
Оценка проекта
Стоит ли нам участвовать в тендере? Сколько денег необ-
ходимо для бюджета этого проекта? Какова трудоемкость со-
здания продукта? Все это важнейшие вопросы, ответы на ко-
торые помогает найти процедура оценки проекта.
Оценка – это процесс определения трудоемкости, дли-
тельности и стоимости элементов ИСР. Здесь же определяет-
ся перечень специалистов, которые потребуются для выпол-
нения пакетов работ. Обычно проект оценивается в деньгах
или трудоемкости, например в человеко-часах. В крупных
проектах трудоемкость может оцениваться в человеко-меся-
цах или человеко-годах.
Оценка начинается с вопроса, какой должна быть ее точ-
ность. Оценка – это вероятностная величина. Нельзя заранее
точно определить время, которое займет выполнение проек-
та. Однако чем точнее будет оценка, тем меньше будет раз-
брос временного интервала. Например, если, по нашим под-
счетам, выполнение задачи займет месяц плюс-минус неде-
лю – это грубая оценка. Если задача займет месяц плюс-ми-
нус день – это точная оценка. Чем выше требования к точ-
ности оценки, тем больше времени на нее требуется.
В зависимости от обстоятельств оценка может быть при-
близительной или точной. Если нужно быстро принять ре-
шение об участии в тендере, то у менеджера будет всего
несколько часов. Как правило, в этом случае работа сводится
к тому, что сначала создается высокоуровневая ИСР, а затем
грубо, с низкой точностью, оценивается стоимость работ.
Для точной оценки, когда проект уже утвержден и плани-
руется, менеджеру понадобится детальная ИСР, декомпози-
рованная до уровня пакетов работ. Такая оценка отнимет на-
много больше времени. Таким образом, важно в самом на-
чале узнать наверняка, какова цель оценки, ее сроки и какой
уровень точности требуется.
 Глоссарий оценки
Трудоемкость (Effort) – количество единиц труда, необ-
ходимое для выполнения задания. Обычно измеряется в че-
ловеко-часах.
Длительность (Duration) – количество рабочих перио-
дов, за исключением праздников, выходных и других нера-
бочих дней, необходимое для завершения одного пакета ра-
бот проекта (операции). Длительность обычно выражается в
рабочих днях или неделях.
Операции проекта могут быть двух типов: основанные на
трудоемкости и основанные на длительности. Например, мы
знаем, что помывка окон в доме занимает 16 часов – это опе-
рация, основанная на трудоемкости. Если один человек моет
окна за 16 часов, то два работника одинаковой квалифика-
ции вымоют их за восемь. При добавлении ресурсов на опе-
рацию, основанную на трудоемкости, ее длительность умень-
шается.
Существуют операции, основанные на длительности. На-
пример, тестирование программного обеспечения после
внесения изменений в ядро системы занимает два дня. И это
не зависит от того, три или четыре человека будут проводить
тестирование.
 Как происходит процесс оценки
Процесс оценки показан на рисунке 15.
Допустим, менеджер узнал, с какой целью и точностью
необходимо делать оценку, собрал детали проекта и создал
соответствующую ИСР. Теперь нужно решить, каким мето-
дом оценки воспользоваться.
 Методы оценки
При проведении оценки можно использовать один или
несколько методов. Использование нескольких методов поз-
воляет подтвердить правильность оценки.
Оценка «сверху вниз». При этом методе разрабатыва-
ется первый уровень ИСР, и на базе прошлого опыта (реа-
лизованных ранее проектов) выполняется оценка крупных
частей проекта. Затем полученные оценки складываются, и
получается итоговая цифра.
Оценка «снизу вверх». При этом подходе разрабатыва-
ется ИСР, детализированная до уровня пакетов работ. Далее
проводится оценка стоимости и длительности каждого паке-
та в отдельности. Сумма оценок пакетов показывает общую
стоимость и длительность проекта. Оценка начинается с са-
мого нижнего уровня ИСР и идет вверх.
Оценка по аналогам. Предполагает использование ис-
торических данных по выполненным проектам. В этом ме-
тоде за основу берется похожий проект, который компания
уже выполняла в прошлом. Метод подходит, если у компа-
нии есть опыт работы над похожими проектами.
Параметрическое моделирование. Оценка проекта
производится при использовании модели с параметрами. На-
пример, мы знаем, что помыть одно окно займет 1,5 часа. В
офисе 14 окон. Следовательно, трудоемкость всего проекта
по мытью окон в офисе считается так:
1,5 часа × 14 окон = 21 час.
Экспертные оценки. Суть метода заключается в прове-
дении интервью с одним или несколькими экспертами, об-
ладающими опытом подобной работы. В итоге эксперт дает
свою оценку, базируясь на собственном опыте и имеющейся
на данный момент информации о проекте. Чем выше уро-
вень эксперта, тем точнее обычно его прогноз.
PERT (оценка по трем точкам). Похожа на предыдущий
метод, но эксперт дает не одну, а три оценки: наиболее ве-
роятную, пессимистичную и оптимистичную. Далее считают
по формуле (рис. 16).
Метод хорош тем, что корректирует наиболее вероятную
оценку с учетом количества рисков, связанных с выполне-
нием задачи. Если пессимистичная оценка не сильно отли-
чается от наиболее вероятной, значит, исполнитель не видит
больших рисков, связанных с задачей. Если наиболее веро-
ятная оценка – неделя, а пессимистичная – шесть недель, то,
скорее всего, у задачи есть серьезные риски.
 Анализ предложений поставщиков. Метод заключа-
ется в анализе предложений других поставщиков услуг. Для
этого проводится тендер, участников которого просят оце-
нить стоимость выполнения проекта. Допустим, пришло
пять предложений: $80 000, $130 000, $140 000, $150 000
и $230 000. Далее отсекаются крайние значения, поскольку,
скорее всего, они неадекватны ($80 000 и $230 000), а из
оставшихся выводится среднее:
(130 + 140 + 150) / 3 =140.
 Эта сумма и берется в качестве оценки стоимости проек-
та.
Такой метод компании используют, когда нужно оценить
проект в той сфере, где у них совсем нет или мало экспер-
тизы.
 Характеристики методов оценок
В разных ситуациях требуется разная точность оцен-
ки. Существует три категории точности: порядок величины
(Rough Order of Magnitude, ROM), бюджетная (budget) и пол-
ная оценка (definitive). В таблице 3 отображена разница меж-
ду ними.
 Точность оценки и предположения,
на которых основывается оценка
Каждая оценка должна содержать указание точности и
предположения, на которых она основывается. Поэтому
опытный руководитель проекта на вопрос, сколько времени
у него сегодня займет обед, отвечает так: «50 минут, минус
5 плюс 10 минут, при условии, что кафе не закрыто на спец-
обслуживание». В таком ответе есть четкое указание на точ-
ность оценки и предположение, на котором она основана.
Заметили ли вы, что точность оценки имеет разные зна-
чения в минус и в плюс? Все дело в распределении веро-
ятности. Если выполнение задачи оценивается в пять дней,
то вероятность выполнить задачу раньше ниже, чем вероят-
ность задержки. На практике это связано с тем, что обычно
при работе над задачей выясняются и уточняются новые дан-
ные, которые могут увеличить объем работ. Вдобавок могут
сработать риски, что приведет к увеличению первоначаль-
но определенной трудоемкости. Распределение выглядит так
(рис. 17).
Наиболее вероятно (НВ), что мы выполним задачу за пять
дней, но если повезет, то можем и за три. Если же что-то
пойдет не так, то решение задачи может растянуться на де-
вять дней. Таким образом, вероятность того, что задача бу-
дет выполнена ровно за пять дней, невелика. Именно поэто-
му при оценке нужно указывать интервал (рис. 18).
Если мы говорим, что выполним задачу за пять дней ми-
нус 10 % плюс 25 %, то вероятность попасть в интервал су-
щественно выше.
 Подготовка оценки
После того как менеджер определился с целями, точно-
стью и выбрал подходящий метод оценки, можно переходить
к самому процессу. Здесь важно учитывать несколько мо-
ментов.
Оценка трудоемкости задачи должна основываться на
среднем уровне компетентности специалистов в команде.
Обычно производить оценку поручают самым опытным и
сильным членам команды, а они судят о трудоемкости зада-
чи, исходя из своего опыта и навыков. В команде, как прави-
ло, присутствуют специалисты разных уровней подготовки.
И если продвинутые специалисты справятся с задачей быст-
ро, то новички будут работать дольше.
Длительность выполнения задачи зависит от доступности
людей. Если трудоемкость задачи четыре дня, но нужный
специалист занят в другом проекте и может уделять ей толь-
ко 50 % своего времени, то продолжительность работы со-
ставит не четыре, а восемь дней. А если трудоемкость задачи
четыре дня, но над ней могут работать два человека, то все
будет готово через два дня:
Длительность = трудоемкость / коэффициент
доступности
При этом важно понимать, что в IT не все так просто и
линейно. Если над задачей работают десять человек и они
планируют завершить ее через четыре недели, то добавление
еще десяти человек не означает, что задача будет готова за
две недели. Сначала нужно будет потратить время на обуче-
ние и ввод в контекст новых людей. Об этом подробнее по-
говорим в следующей главе.
И еще такой момент: если человек работает над двумя за-
дачами по 50 % своего времени, то восемь рабочих часов на
две задачи на самом деле дадут не 4 + 4 = 8, а в лучшем слу-
чае семь, поскольку нужно потратить время на переключе-
ние между задачами.
Стоимость рассчитывается на основании предполагаемой
ставки заработной платы (rate) тех, кто будет выполнять ра-
боту. Например, дизайнер получает $25 в час. Если трудоем-
кость его задач в проекте составляет 120 часов, то стоимость
всей работы дизайнера считается так:
120 × 25 = $3000.
В идеале необходимо привлекать к оценке тех специали-
стов, которые в дальнейшем будут выполнять работу. Во-
первых, оценка специалиста будет восприниматься им как
обещание и, соответственно, будет мотивировать человека
выполнить работу в срок. Во-вторых, чужие оценки все-
гда кажутся неадекватными, поскольку понимание ситуации
тем, кто оценивает, и тем, кто будет работать (если это раз-
ные люди), редко полностью совпадает.
Есть работы, которые необходимо вести в определенном
объеме в течение всего срока реализации проекта. Они на-
зываются масштабом работ (Level of Effort, LOE). Напри-
мер, это работа системного администратора, который будет
задействован в проекте несколько часов в неделю.
В оценке такие работы очень сложно расписать, посколь-
ку невозможно предсказать, когда у компьютера, например,
сгорит винчестер. Оценка таких работ происходит следу-
ющим образом: определяется количество часов в день, на
которые нужен специалист, а затем эта цифра умножается
на всю длительность проекта. Например, проект будет ид-
ти шесть месяцев, или 126 рабочих дней. Каждый день нам
нужна поддержка системного администратора на час. Сле-
довательно, мы добавляем в проект 126 часов работ по под-
держке.
Как ни странно, управление проектом также относится
к масштабу работ. Пытаться спланировать заранее конкрет-
ную работу руководителя в течение всего проекта неверно.
Руководитель проекта назначается на частичную или пол-
ную занятость, в зависимости от сложности проекта и раз-
мера команды.
Для быстрой оценки объема работы руководителя проек-
та можно применить такой способ: считается, что работа по
управлению проектом занимает порядка 10 % всей трудоем-
кости. Если трудоемкость проекта составляет 2500 часов, то
на управление им нужно отвести 250.
Оценка рисков проекта производится отдельно. После
проработки рисков проекта в ИРС попали работы по сниже-
нию рисков до приемлемого уровня. Эти работы оценивают-
ся отдельно. Вот, например, как должна выглядеть оценка
проекта, в которую включены риски. Предположим, что час
работы стоит $10.
Работы проекта: 800 часов или $8000.
Работы по снижению рисков: 85 часов или $850.
Итого оценка: 885 часов или $8850.
Когда оценка готова, очень полезно ее перепроверить.
Для этого можно воспользоваться другими методами. Мы
рекомендуем попросить своего товарища – опытного руко-
водителя проектов – провести свою оценку, но сделать это
другим методом. Если наши результаты более-менее совпа-
дают, то итоговую оценку можно брать в работу. Если же раз-
ница большая, то следует искать причины. Возможно, что-
то упущено из виду.
 Документирование и
утверждение оценки
Следующим шагом является документирование оценки.
Как уже было сказано выше, кроме самих цифр, нужно ука-
зывать точность и предположения, на основе которых рас-
считывалась оценка. Эти данные весьма вероятно могут по-
надобиться в дальнейшей работе.
Давайте представим, что вас попросили оценить сроки
выполнения проекта. Согласно вашим расчетам, на него по-
требуется два месяца. Документацию вы решили не вести.
Проект отложился на год, а потом все же стартовал. После
старта выяснилось, что вам понадобится не два, а четыре ме-
сяца. Будет очень тяжело вспомнить, какие предположения
вы делали при оценке год назад и почему тогда получилось
два месяца. Если мы получаем разбежку в два раза, то, ско-
рее всего, какое-то из предположений не сработало.
После того как оценка задокументирована, ее нужно
утвердить у спонсора проекта. Иногда спонсор полностью
согласен с тем, что показывает ему менеджер, а иногда – нет.
И в этом случае менеджера просят уменьшить оценку.
 Что делать, если просят
уменьшить оценку
Если оценка была сделана честно, то просто взять и со-
кратить ее без влияния на проект не получится. У менедже-
ра проекта в такой ситуации есть несколько вариантов дей-
ствий.
1. Сократить содержание работ. Например, отказать-
ся от части работ в текущем проекте и перенести их на сле-
дующий этап или проект, обязательно указав эти работы в
исключениях из проекта. Еще один вариант – полностью от-
казаться от каких-то работ.
2. Использовать менее дорогих специалистов. Это
увеличит длительность проекта, поскольку менее квалифи-
цированные люди будут выполнять задачи дольше.
3. Не менять свою оценку, а попытаться убедить
руководство снизить размер прибыльности проекта.
Оценка – это стоимость проекта, а вот цена, за которую про-
ект продается заказчику, определяется уже руководством
менеджера. Формула простая:
Цена проекта = стоимость проекта (оценка) +
прибыль компании-исполнителя
Чтобы в итоге цена осталась приемлемой для заказчика,
можно снизить запланированную прибыль, не меняя оценку.
 4. Переложить риски проекта на руководство ком-
пании. Поскольку риски мы оценивали отдельно, можно до-
говориться с руководством компании, что работа с рисками
проекта будет финансироваться не заказчиком, а компани-
ей-исполнителем. Если проект хорош для имиджа компании
и очень хочется победить в тендере, руководство компании
может пойти на такой шаг.
В моей практике было много случаев, когда меня просили
снизить оценку проекта, но один мне запомнился особенно.
Мне нужно было подготовить оценку для участия в тендере.
Я сделал это, воспользовавшись методом «снизу вверх», по-
том подтвердил ее у друга при помощи экспертной оценки.
После этого все задокументировал и отправил в отдел мар-
кетинга.
Через час мне перезвонил маркетолог и стал объяснять,
что он в курсе предложений других компаний и что моя
оценка превышает их в полтора раза. Это неприемлемо! Он
потребовал, чтобы я снизил оценку проекта в два раза. В
противном случае он собирался эскалировать вопрос на уро-
вень директора департамента.
Возможно, я бы в тот момент «дрогнул», если бы делал
нечестную оценку с искусственным завышением трудоемко-
сти, но моя оценка была абсолютно честной. Дешевле сде-
лать я бы не смог. Поскольку уменьшать содержание работ
в тендерном предложении нельзя, я предложил маркетологу
снизить размер прибыли. В ответ он совсем рассвирепел и
бросил трубку. Через десять минут директор департамента
получил от маркетолога эмоциональное письмо с описанием
ситуации и просьбой разобраться (я получил копию письма).
Было страшно.
Решение директора департамента было мудрым: он об-
ратился к другому отделению с просьбой произвести свою
оценку. В итоге она получилась еще больше моей. В сопро-
водительном письме было написано: «Если Минкевич сдела-
ет проект в соответствии со своей оценкой, то я приду в го-
сти с тортиком, чтобы узнать, как у него это получилось».
Важно упомянуть еще одну вещь: порой возникают ситу-
ации, когда в тендерном предложении кого-то из ваших кон-
курентов цена намного ниже вашей. Но это не значит, что
проект будет реализован за эту стоимость. Иногда подрядчи-
ки сознательно берутся за проекты, которые убыточны для
них. Ситуации могут быть разные. Допустим, у вас есть силь-
ная команда, которая сейчас сидит без работы, но вы не хо-
тите ее потерять. Тогда руководитель подразделения может
быть готов участвовать в тендере и предложить низкую цену,
чтобы выиграть его и занять людей. Да, проект будет убы-
точным, но если его не взять, то убыток от простоя команды
будет еще больше, и это в том случае, если команда, остав-
шись без работы, не разойдется. Иначе будет совсем плохо.
Так что если ваша оценка выше, чем у конкурентов, то это
еще не значит, что вы рассчитали ее неверно.
 Выводы
Выбор правильного метода проведения оценки зависит от
того, на каком этапе находится проект. От менеджера может
потребоваться дать быструю, грубую или точную оценку.
Оценка должна быть честной. Часто, имея предположе-
ния руководства о том, сколько будет стоить проект, мене-
джеры пытаются подогнать оценку под желаемый уровень,
но это неверно. Хуже этого может быть только сознатель-
ное занижение для получения мгновенного одобрения или
победы в тендере. Обычно заниженная оценка приводит к
срыву сроков и перерасходу бюджета проекта, что, в свою
очередь, очень портит отношения менеджера с заказчиком и
собственным руководством.
Оценка обязательно должна содержать указание ее точно-
сти, желательно в процентах. Все допущения, использован-
ные в работе по оценке, должны быть задокументированы.
Необходимо переделывать оценку в тех случаях, когда в со-
держание проекта, ресурсы, материалы и услуги вносятся со-
гласованные изменения.
По методологии рекомендуется делать оценку рисков от-
дельно от оценки проекта. Большой плюс такого подхода –
прозрачность. Всем сразу понятно, насколько проект риско-
ванный. Это очень хорошо работает в проектах, где заказчик
обладает большим опытом и пониманием специфики управ-
ления проектами. К сожалению, так бывает не всегда, и неко-
торые заказчики, особенно в наших краях, не понимают и не
принимают работу с рисками: «Какие риски? С вашей став-
кой за час вообще никаких рисков быть не должно!» В таком
случае руководитель проекта будет вынужден размазать ра-
боту с рисками по трудоемкости задач проекта. Мы против
такого подхода, поэтому всегда стараемся объяснить заказ-
чику важность правильной работы с рисками.
 Глава 9
Расписание проекта
При помощи ИСР и оценки проекта мы получили ответы
на два самых важных вопроса из трех: что делаем и сколько
это будет стоить? Остался последний вопрос: когда будет го-
тово? Именно на этот вопрос отвечает расписание проекта.
Расписание проекта похоже на план поездки: есть кон-
трольные точки, прогноз времени их достижения, конечная
точка путешествия. Идем по плану – молодцы. Задержива-
емся – разбираемся, почему, и думаем, как нагнать отстава-
ние.
Расписание проекта лучше всего позволяет понять, как
идут дела: нужно ли поднажать или все хорошо.
 Глоссарий расписания проекта
Давайте начнем с терминов, чтобы в дальнейшем говорить
на одном языке.
Операция (Activity) – это работа, выполняемая в рамках
проекта. Соответствует пакету работ (нижнему уровню ИСР/
WBS).
Контрольное событие (Milestone) – достижение или
значимое событие проекта. Например, завершение важ-
ной операции. Формулируется всегда в прошедшем време-
ни: «Завершена разработка мобильного приложения». Кон-
трольное событие в расписании имеет нулевую длитель-
ность, и на него не выделяются ресурсы.
Отношение предшествования (Precedence
relationship) – порядок, в котором выполняются операции
или операции и контрольные события. По сути, это ответ на
вопрос: «Что нужно сделать, прежде чем начать выполнять
эту задачу?»
 Что же такое расписание проекта?
Расписание – главный инструмент управления проектом.
Это план, в котором с привязкой ко времени отражено, кто,
что и когда будет делать. Расписание содержит информацию
об очередности и длительности операций, запланированных
датах начала и окончания, исполнителях и датах достижения
контрольных событий.
С его помощью собирают информацию о ходе проекта и
отслеживают, соответствует ли фактическая скорость реали-
зации запланированной.
Расписание отвечает на вопрос, кто и когда будет делать
работу. Зная стоимость ресурсов и материалов, можно со-
ставить бюджет проекта и спрогнозировать, к какому числу
сколько денег может понадобиться.
Расписание помогает менеджеру работать с изменениями
проекта. Решение, принимать или не принимать изменения,
зависит от того, насколько они повлияют на последователь-
ность операций, необходимые ресурсы, контрольные собы-
тия и сроки. Давайте представим ситуацию: вы опережаете
расписание на неделю, но тут к вам обращается заказчик и
просит добавить в разрабатываемую систему еще один от-
чет. Эта работа займет четыре дня. И вторая ситуация: за-
казчик обращается к вам с аналогичной просьбой, но разни-
ца в том, что вы опаздываете на неделю, а команда уже две
недели работает без выходных. Очевидно, что в первом слу-
чае согласиться включить дополнительную работу в проект
проще, чем во втором.
Если расписание показывает, что реализация проекта
опаздывает, то менеджеру необходимо принять корректиру-
ющие действия, чтобы вернуть проект в нужное русло.
Выше мы уже говорили о том, что расписание позволяет
нам понять, кто и когда должен выполнять те или иные рабо-
ты. Следовательно, лучше подбирать команду исходя из рас-
писания проекта: это намного продуктивнее, нежели снача-
ла набрать команду, а затем под нее составлять расписание
проекта. Во втором случае, скорее всего, выяснится, что на-
браны не те люди, не в том количестве, не с теми компетен-
циями.
 Визуализация расписания работ
Чтобы за всеми работами по проекту и их последователь-
ностью было удобнее следить, используют инструменты ви-
зуализации: диаграммы, схемы и графики.
К обычным видам визуализации расписания относятся
диаграммы предшествования, диаграмма Ганта и диаграмма
контрольных событий.
Диаграмма Ганта – один из любимейших инструментов
руководителей проектов (рис. 19). В ней на оси Х отмеча-
ется время, а по длине задачи (визуализируется полоской)
можно судить о продолжительности ее выполнения. Мене-
джеры нежно называют эту диаграмму «колбаски Ганта» из-
за определенной схожести с мясным продуктом.

Высшему менеджменту нужно быстро, буквально с пер-

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

В среде менеджеров проектов даже бытует шутка о том,

что существует метод управления по контрольным событи-
ям: завершили этап проекта в срок – получили похвалу. Не
успели вовремя – по шапке.
Главная задача диаграммы предшествования (PDM) –
определить последовательность операций. Диаграммы пред-
шествования помогают понять порядок следования работ и
то, какие работы нужно выполнять последовательно, а какие
могут осуществляться параллельно для экономии времени
(рис. 21).
Так как диаграммы предшествования очень важны, то
предлагаю на них остановиться подробнее.
 Диаграммы предшествования
Как мы уже знаем, ИСР дает нам список всех работ про-
екта. Теперь нужно расположить эти работы в той последо-
вательности, в которой они будут выполняться. И здесь нам
помогут диаграммы предшествования, которые также назы-
вают «операциями на узлах».
Это метод составления сетевых диаграмм, где заплани-
рованные операции представляются узлами, а связи между
ними – стрелками. Стрелки демонстрируют последователь-
ность выполнения.
Что мы делаем? Берем пакеты работ (нижний уровень
ИСР) и строим между ними зависимости (рис. 22).
 У нас добавились узлы «Начало» и «Конец». Обратите
внимание, что у этих узлов есть стрелки только одного на-
правления: у начала только на выход, у конца только на вход.
У всех остальных узлов есть одна или несколько стрелок и
на вход, и на выход.
Получилась очень простая диаграмма с типом зависимо-
сти «Финиш – Старт», когда для начала операции «Согласо-
вание ТЗ» нужно закончить работу над выработкой требова-
ний и разработкой дизайна.
Всего существует четыре типа зависимостей (рис. 23).
Давайте подробнее остановимся на каждом из них.
 Финиш – Старт (FS). Это самая простая и понятная
зависимость: следующая операция начинается только по-
сле того, как заканчивается предыдущая. Например, снача-
ла нужно построить фундамент дома, а потом уже возводить
стены. Поскольку тип зависимости «Финиш – Старт» наибо-
лее логичен и интуитивно понятен, при планировании про-
ектов в 99 % случаев применяют только его. Расписания,
в которых используют другие типы зависимостей, гораздо
сложнее читать. Каждый из остальных трех типов зависимо-
стей можно преобразовать в «Финиш – Старт» (чуть позже
разберемся, как это сделать).
Старт – Старт (SS). Это операции, которые должны
начинаться одновременно: старт одной операции означает
старт другой. Например, одновременно со стартом новой
услуги необходимо запустить службу поддержки потребите-
лей этой услуги.
Финиш – Финиш (FF). Это операции, которые заверша-
ются одновременно. Например, если я продал машину, то
прекращаю размещение платного объявления о продаже.
 Старт – Финиш (SF). Тип операций, когда выполнение
текущей операции завершается в момент начала следующей.
Например, компания готовит производственный цех до тех
пор, пока не привезут новые станки. Но как только прибыва-
ют станки, команда прекращает ремонт помещения, начина-
ет их устанавливать и запускает производство. Еще один хо-
роший пример для людей, знакомых с армией: солдаты дра-
ят плац до прихода генерала.
Иногда между операциями требуется определенный вре-
менной интервал. Он отображается в виде цифры над стрел-
кой. Положительная цифра означает, что нужно подождать
определенное время, прежде чем начинать следующую опе-
рацию. Это называется задержкой (Lag time). Например, по-
сле заливки фундамента нужно дать бетону 36 часов, чтобы
застыть, а уже потом можно возводить стены (рис. 24).

Если цифра отрицательная, это значит, что можно начи-

нать работать, не дожидаясь завершения предыдущей опе-
рации. Это называется опережением (Lead time). Например,
нам необходимо оштукатурить и покрасить три комнаты.
Штукатур будет работать 12 часов (три комнаты по четыре
часа на каждую), а маляр – восемь. Так вот, маляру не нужно
ждать, пока штукатур закончит все три комнаты. Он может
начинать красить первую через четыре часа после того, как
ее закончит штукатур, или через 8 часов после начала рабо-
ты штукатура. Как будет выглядеть эта зависимость, показа-
но на рисунке 25.
 Это пример зависимости «Финиш – Старт».
Пример зависимости «Старт – Старт» изображен на ри-
сунке 26.
Зависимость «Старт – Старт» можно легко переделать в
«Финиш – Старт», используя временной лаг, равный длине
первой операции (рис. 27).
 Таким образом, при помощи задержки и опережения мы
можем сделать из любого типа зависимости легко восприни-
маемый тип «Финиш – Старт».
Составление диаграмм предшествования – это первый
шаг в разработке расписания.
 Метод критического пути
После того как мы определили последовательность ра-
бот, у нас появилось понимание того, что и за чем следует.
Несмотря на это, мы все еще не можем ответить на вопрос
о том, когда проект будет завершен. В поиске ответа нам по-
может метод критического пути – это второй шаг составле-
ния расписания.
Метод критического пути используется для оценки мини-
мальной длительности проекта и определения степени гиб-
кости его расписания.
Критический путь – это самый короткий интервал време-
ни, за который может быть реализован проект. Современ-
ное программное обеспечение для управления проектами
без проблем рассчитает критический путь любого проекта.
Тем не менее, чтобы понять суть этого метода, разберем на
очень простом примере, как это делается.
 Как построить критический путь
Чтобы определить критический путь проекта, давайте
пройдем весь процесс по шагам.
Шаг 1. На базе диаграммы предшествования строится се-
тевой график. В сетевом графике узел выглядит следующим
образом (рис. 28).
● Ранний старт (Early start) – самый ранний момент вре-
мени, в который может начаться запланированная операция.
● Ранний финиш (Early finish) – самый ранний момент
времени, когда операция может быть завершена.
● Поздний старт (Late start) – самый поздний момент
времени, в который может начаться запланированная опера-
ция, чтобы не задержать выполнение всего проекта. Обрати-
те внимание, что если операция начинается после этой даты,
то весь проект будет задержан.
● Поздний финиш (Late finish) – самый поздний момент
времени, когда операция может завершиться, не увеличив
длительность всего проекта.
 Для примера возьмем маленький проект по созданию веб-
сайта. Вот его диаграмма предшествования (рис. 29).

На ее базе рисуем сетевой график (рис. 30).

На схеме появилась информация об узлах. Для каждой
операции в центральной ячейке сверху цифрой прописана
длительность ее исполнения. Выработка требований займет
три дня, разработка дизайна – четыре дня и т. д.
 Шаг 2. Выполняем прямой проход.
1. Устанавливаем дату начала проекта. Она одновременно
является и датой раннего старта первой операции. Ставим 0
у первых операций в ячейке раннего старта (рис. 31).
2. Добавляем длительность операции к дате начала, что-
бы получить ранний финиш для первой операции. В нашем
примере это 0 + 3 = 3 дня (рис. 32).
3. В ячейку раннего старта следующей операции вписы-
ваем цифру раннего финиша предыдущей операции. Ес-
ли предшествующих операций много, то в качестве ранне-
го старта последующей операции выбираем самую позднюю
дату раннего финиша. Например, операции «Согласование
ТЗ» предшествуют сразу две операции: «Выработка требо-
ваний» и «Разработка дизайна». В дату раннего старта опе-
рации «Согласование ТЗ» мы ставим 4, то есть самый позд-
ний вариант (рис. 33).
4. Повторяем действия слева направо по всему графику и
получаем вот такую картину (рис. 34).
 Итак, мы прошлись по верхним ячейкам и заполнили да-
ты раннего старта и раннего финиша для всех операций. Да-
та раннего финиша последней операции получилась 25. Это
означает, что проект по созданию веб-сайта можно выпол-
нить за 25 дней. Теперь делаем обратный проход и заполня-
ем нижние угловые ячейки – это необходимо, чтобы опреде-
лить гибкость нашего расписания.
 Шаг 3. Обратный проход.
1. В нижнюю правую ячейку позднего финиша опера-
ции «Демонстрация заказчику» вписываем день завершения
проекта из ячейки выше (рис. 35).
2. Вычитаем длительность операций из позднего фини-
ша, чтобы получить дату позднего старта операции. В нашем
примере это 25–1 = 24. Вписываем в левую нижнюю ячейку
(рис. 36).

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

дату позднего старта в ячейку позднего финиша предыду-
щей операции (рис. 37).

4. Если у предшествующей операции множество других,

то выбираем самую раннюю дату позднего старта предше-
ствующей (рис. 38).
5. Вот что у нас получается в итоге (рис. 39).
 Теперь осталось заполнить центральную ячейку снизу для
каждой операции, чтобы стало понятно, для чего мы это все
делаем.
Шаг 4. Считаем временной резерв (Float) для каждой
операции. Временной резерв операции – это время, на ко-
торое операция может задержаться, но при этом дата завер-
шения проекта не пострадает. Отнимаем от позднего старта
ранний старт и получаем временной резерв операции:
Float = LS (поздний старт) – ES (ранний старт).
Или другой вариант:
LF (поздний финиш) – EF (ранний финиш).
Тут все равно, какой вариант, поскольку оба расчета все-
гда дадут один и тот же результат.
В нашем примере для операции «Выработка требований»
это 1 – 0 = 1 (рис. 40).
 Рассчитываем временные резервы для всего проекта
(рис. 41).
В некоторых местах у нас получились нули – это и есть
тот самый критический путь проекта, то есть последователь-
ность операций, задержка на которых приведет к задержке
всего проекта. Серой заливкой обозначен критический путь
примера (рис. 42).
 У всех остальных операций есть резерв. Это значит, что
они не лежат на критическом пути и их задержка в рамках
временного резерва не повлияет на сроки сдачи всего про-
екта.
Вот как это выглядит в «колбасках» Ганта. Для упроще-
ния диаграммы мы задействуем для работы выходные дни
(рис. 43).
Руководитель проекта должен обращать максимум внима-
ния именно на операции, находящиеся на критическом пу-
ти. Ведь задержка в работе над любой из них автоматически
сдвигает дату завершения проекта. Риски, связанные с опе-
рациями критического пути, нужно прорабатывать в первую
очередь.

Кроме того, критический путь помогает нам в выравнива-

нии ресурсов. Выравнивание ресурсов – это работа с распи-
санием, при которой операции проекта сдвигаются так, что-
бы у членов команды не было переработок. Обратите внима-
ние, что на картинке выше программист Вася два дня дол-
жен работать по 16 часов одновременно над HTML-версткой
и программированием. Видя, что обе операции не лежат на
критическом пути, менеджер может корректировать распи-
сание, чтобы Вася не работал сверхурочно, а выполнял опе-
рации последовательно. Это изменение не повлияет на дату
завершения проекта, а Вася будет рад уходить домой вовре-
мя (рис. 44).
Вот новое расписание проекта, в котором дата заверше-
ния осталась прежней, а сотрудник не сгорел на работе.
 Что делать, если длительность
проекта нужно сократить
После того как расписание построено, у вас есть дата за-
вершения проекта. Если она всех устраивает, то менеджер
утверждает расписание и принимается за работу. Очень ча-
сто бывает так, что проект не укладывается в желаемые биз-
несом сроки, и тогда расписание нужно оптимизировать,
чтобы проект был готов к определенной дате.
Какие подходы может использовать руководитель проек-
та, чтобы сократить расписание? Есть четыре подхода: сло-
мать расписание, «быстрый проход», изменение подхода и
переоценка зависимостей.
Сломать расписание (Crashing). Если один человек со-
берет яблоки в саду за десять дней, то два человека сделают
это за пять дней. Таким образом, суть метода состоит в том,
чтобы привлечь к проекту больше людей и выполнить его
быстрее. Ломая расписание, менеджер смотрит на операции,
лежащие на критическом пути проекта, и анализирует, мож-
но ли выполнить их быстрее, если добавить людей в коман-
ду, – при условии, что у менеджера есть такая возможность.
«Быстрый проход» (Fast tracking). Эта методика подра-
зумевает сжатие расписания проекта с помощью полного или
частичного распараллеливания операций, которые обычно
выполняются последовательно. Например, обычно тестиро-
вание проводится после завершения разработки, но, вероят-
но, существует возможность начать тестирование за неделю
до завершения разработки и тем самым завершить проект
быстрее на неделю.
«Быстрый проход» сокращает сроки проекта, но часто
приводит к дополнительным рискам и увеличению стоимо-
сти. В нашем примере, если разработчики в последние дни
работы над проектом внесут в него серьезные изменения,
тестировщикам придется начинать работу с самого начала,
а все уже сделанное отправится в мусорку. Это как начать
строить дом до того, как работы над фундаментом завер-
шены, а потом понять, что фундамент недостаточно прочен
и его нужно доработать. Проще говоря, придется разбирать
все, что уже успели построить, переделать фундамент и по-
том начать строительство стен заново. Все это не добавляет
хорошего настроения команде. Вряд ли кому-то понравится
переделывать то, над чем он кропотливо работал неделями,
особенно если до этого работать приходилось с овертайма-
ми.
 Изменение подхода. Нужно посмотреть на проект и
найти иной путь реализации. Представим, что в рамках про-
екта одна из задач – постройка беседки. Закупка строймате-
риалов и строительство отнимает неделю. Если нужно сокра-
тить сроки проекта, то мы можем обратиться в компанию,
продающую готовые беседки. Таким образом мы можем по-
лучить беседку не за неделю, а за несколько часов. И далеко
не всегда такой ход приводит к увеличению бюджета проек-
та. Самый яркий пример изменения подхода в IT – это отказ
от написания собственного решения и покупка готового. На-
пример, не разрабатывать систему управления программой
лояльности, а купить готовую и проверенную временем, ко-
торая давно стала стандартом в области.
Изменение подхода и покупка готового решения требуют
от менеджера опыта и тщательности выбора. В противном
случае можно потратить месяцы на интеграцию стороннего
решения лишь для того, чтобы понять, что оно не подходит.
 Произвести переоценку зависимостей. Допустим, вы
можете начать разработку ПО только после того, как купи-
те мощный сервер. Это зависимость «Финиш – Старт». Де-
ло в том, что сервер могут доставить только через три меся-
ца. Может быть, не стоит терять это время и лучше попро-
бовать начать разработку сейчас на том оборудовании, что
есть, или арендовать сервер со схожими характеристиками?
Вполне вероятно, что уже к моменту доставки сервера все
будет готово и можно будет начать тестирование созданного
продукта.
Обратите внимание, что все вышеперечисленные методы
сокращения расписания нужно применять к задачам, нахо-
дящимся на критическом пути. Сокращение задач вне его
может никак не повлиять на сроки сдачи проекта в целом.
 Что делать, если проект опаздывает
и не укладывается в расписание
Мы разобрались с тем, что делать, если расписание про-
екта не укладывается в сроки еще на этапе планирования. А
что делать, если уже идущий проект не вписывается в пла-
ны? Ответ простой: переделывать изначальное расписание
проекта, используя те же методы. Здесь есть нюансы, кото-
рые нужно знать.
У слома расписания, особенно на поздних этапах проек-
та, существуют негативные последствия. В нашей практике
был вот какой случай. Для завершения работ проекта по раз-
работке программного обеспечения требовалось два меся-
ца, а остался только один. И неопытный менеджер предло-
жил удвоить размер команды, чтобы успеть в срок. В подоб-
ных проектах это большая ошибка: после такого изменения
производительность команды резко падает, потому что при-
ходится отвлекаться на обучение новичков. Графически это
можно проиллюстрировать следующим образом (рис. 45).
 Давайте разберем, что отображено на графике.
Команда работает на своем плато производительности.
При добавлении новых людей ребятам приходится тратить
время на их обучение, и это ведет к потере производительно-
сти. На графике мы заштриховали эту потерю темным. Толь-
ко через некоторое время новички смогут выполнять первые
задачи самостоятельно – производительность команды начи-
нает расти. Прирост производительности мы заштриховали
светлым.
Здесь главный вопрос – когда планируется заканчивать
проект? Если окончание близко, то добавлением людей мож-
но сделать только хуже. Если до завершения еще далеко,
то улучшенная производительность увеличенной команды в
какой-то момент перекроет время, потраченное на обуче-
ние новичков. То есть площадь прироста производительно-
сти (светлый штрих) будет больше площади потери произво-
дительности (темный штрих). В такой ситуации уже можно
выиграть.
Есть еще один вариант – прибегнуть к овертаймам и по-
просить команду поработать сверхурочно, но эта мера хо-
роша лишь в качестве временной. В конце концов продук-
тивность сотрудников, месяц работающих в полторы смены,
обязательно упадет. Команда устанет, и ее производитель-
ность рухнет. В худшем случае команда просто выгорит и
потеряет интерес к проекту.
Овертайм помогает увеличить продуктивность, но его
лучше не внедрять дольше, чем на одну-две недели. В край-
них случаях можно попросить команду поработать на выход-
ных. Но не забывайте, что команде нужен отдых и энергия
на новую рабочую неделю. Вместо рабочих выходных мож-
но оставаться на несколько часов дольше в течение рабочей
недели.
Вышеперечисленные методы работают, и часто после
адаптации расписания опаздывающий проект удается сдать
в срок. Славянским народам в принципе свойственно уме-
ние в нужный момент мобилизоваться и очень эффективно
справиться с горой накопившейся работы.
 Несколько советов по работе
с расписанием проекта
Знание критического пути помогает менеджеру понять,
на какие операции следует обратить внимание в первую оче-
редь. Необязательно помнить обо всех задачах сразу, но в
уме нужно постоянно держать текущую и следующую задачи
критического пути – про них нельзя забывать ни при каких
обстоятельствах.
Отличное решение – вовлекать команду в формирование
расписания проекта. Если команда помогает менеджеру, то
у нее впоследствии не будет вопросов, откуда взялись те
или иные сроки. Здесь работает тонкий психологический мо-
мент: если команда сама назвала сроки, то ей сложно потом
спорить с ними. Следовательно, команда сделает все, чтобы
выполнить обещанное.
При планировании расписания нельзя использовать такие
инструменты, как овертаймы, так как в критический момент
не останется пространства для маневра.
 Глава 10
Карьера: как стать тренером
«Вот здорово! C таким крутым сертификатом я могу все!
У меня будут самые интересные проекты, карьера пойдет
вверх! Сейчас начнется!» – такие радостные мысли крути-
лись в моей голове сразу после получения сертификата PMP.
Однако время шло, а работа оставалась все той же: новые
проекты не приходили, зарплата не менялась. Стало совсем
скучно. Чтобы развлечь себя, я стал помогать людям выби-
рать автомобили. Я хорошо разбирался в технике и мог по-
мочь не только с выбором определенной модели, но и с по-
иском варианта в хорошем техническом состоянии. За этим
занятием я провел все лето, но в итоге почувствовал, что это
путь в никуда. Не о такой работе я мечтал. Следом пришло
осознание, что я стал постепенно забывать многое из изу-
ченного при подготовке к экзамену. И я испугался, что все
усилия пойдут прахом. А еще и в компании настало затишье
в части новых проектов, что не добавляло оптимизма. Что-
то нужно было менять.
И тут меня осенило: можно попробовать сделать курс по
управлению проектами и делиться с другими людьми имею-
щимися знаниями. По опыту работы в пионерском лагере и
выступлений на конференциях я помнил, что если ты что-то
объясняешь людям, то обязан глубоко разобраться в теме. В
противном случае тебя «погребут» под вопросами и подни-
мут на смех. Подготовка к выступлению заставляет еще раз
внимательно просмотреть и повторить все материалы, и это
очень полезно.
В моей компании был свой учебный центр. Я напросил-
ся на встречу с его директором, чтобы рассказать о своей
идее. Тот очень обрадовался и сказал, что давно хотел сде-
лать такой курс и ждал меня пять лет. Учебник и материалы
курса мне выдал учебный центр. После нескольких месяцев
подготовки я прочитал свой первый курс для друзей и кол-
лег внутри компании. Все прошло хоть и не очень гладко,
но вполне успешно. Меня завалили вопросами, на многие из
которых я не смог ответить. Но дружественная обстановка
сильно помогла: совместными усилиями мы нашли ответы
на все сложные вопросы.
После преподавательского дебюта в Минске меня пригла-
сили читать управление проектами в учебный центр IBM в
Москве. Вот это был вызов! Мой первый курс в Москве чуть
не закончился провалом, едва лишь начавшись. Когда груп-
па собралась в первый раз, я начал занятие с приветствия:
«Добрый день, меня зовут Алексей, я из Минска». И тут по
аудитории пошел шепот. Москвичи были явно недовольны,
что тренер из «глубинки». Практически целый день у меня
ушел на то, чтобы заслужить их доверие и показать, что я
владею предметом.
 Зато каждый следующий курс был успешнее предыдуще-
го, поскольку я сам набирался тренерского опыта и знаний,
научился работать с группой и держать внимание аудитории.
В самом начале преподавание было для меня очень тяже-
лой работой. Со временем все изменилось: я стал получать
настоящее удовольствие от работы со студентами. Уровень
моих знаний тоже вырос в разы. Как итог, отзывы о моих
курсах стали отличными, и очень много людей начало при-
ходить на занятия по рекомендации друзей.
А тут и на работе стали появляться новые проекты, так что
я получил возможность применять знания на практике. Сна-
чала проекты были простые и небольшие, потом все больше
и сложнее. Вскоре меня попросили помочь с управлением
одной программой проектов, количество разработчиков ко-
торой со временем выросло в несколько раз.
Кроме этого, внезапно свою роль начал играть сертифи-
кат PMP: многие заказчики при проведении тендеров ста-
ли требовать сертифицированных руководителей проектов.
Поскольку я был единственным менеджером с сертификаци-
ей в компании, то вскоре обо мне узнало подразделение про-
даж, и мы успешно выполнили ряд проектов с фиксирован-
ной ценой.
Все это подтолкнуло меня к идее развить экспертизу
управления проектами внутри своей компании, и я стал ве-
сти группы по подготовке к экзамену PMP. За три года уда-
лось подготовить к успешной сдаче более 30 ребят внутри
компании и за ее пределами. Видеть прогресс и рост людей
вокруг тебя – это очень приятно. Понимать, что ты прило-
жил к этому руку, – вообще кайф!
Сейчас, оглядываясь назад, я думаю, что с моей стороны
было очень наивно полагать, что получение сертификата ав-
томатически гарантирует интересные, сложные проекты и,
соответственно, карьерный рост. Главная ценность сертифи-
ката PMP или любого другого в том, что он заставляет тебя
учиться. И эта учеба заложила во мне отличную базу для ро-
ста, который со временем удалось реализовать.
Решение стать тренером очень помогло мне быстрее на-
брать опыт. Разбирая кейсы студентов, я вместе с ними раз-
решал проблемы их проектов и, сталкиваясь потом с подоб-
ной ситуацией, уже знал, что нужно делать.
Алексей Минкевич
 Глава 11
Управление стоимостью проекта
Один из важнейших факторов успеха при выполнении
любого проекта – постоянная синхронизация между всеми
заинтересованными сторонами. Обмениваться информаци-
ей нужно о текущем состоянии дел и о том, что мы понимаем
под управлением той или иной областью знаний проектного
менеджмента.
Так как любой проект уникален, то и ожидания спонсо-
ра относительно полномочий и обязанностей руководителя
проекта при управлении стоимостью могут быть разными.
Зачастую под управлением стоимостью понимают:
● управление трудоемкостью – насколько точна была
оценка и как сильно мы от нее отклонились;
● управление лицензиями – сколько и когда мы планиро-
вали потратить на лицензионное ПО и сколько по факту по-
тратили;
● управление расходами на оборудование (обновление
парка техники может целиком лечь на бюджет проекта, если
оборудование закупается непосредственно под него);
● управление расходами на командировки (эту статью
расходов очень часто упускают из виду, так как она обычно
не связана ни с какой работой из ИСР);
 ● управление расходами, связанными с командными ме-
роприятиями (хорошим примером может быть выездное об-
суждение итогов проекта).
Какие-то из этих пунктов легко упустить из виду при под-
готовке предложения для участия в тендере, что потом вы-
ливается в убыточный проект.
PMI проделал огромную работу, чтобы, вне зависимости
от специфики проекта, предоставить руководителю набор
инструментов, который облегчает жизнь и вносит ясность в
вопросы управления стоимостью.
Управление стоимостью – это процессы, необходимые для
планирования, оценки, разработки бюджета, привлечения
финансирования, управления расходами и контроля над ни-
ми.
Чтобы проект выполнялся в рамках запланированного
бюджета, необходимо реализовать следующие процессы.
● Планирование управления стоимостью. Это про-
цесс, устанавливающий политики, подходы, процедуры и
определяющий документацию по планированию стоимости.
Иными словами, именно на этом этапе мы общаемся со спон-
сором и договариваемся, что же мы будем понимать под
управлением стоимостью.
● Оценка стоимости. Процесс оценки объема денеж-
ных ресурсов, необходимых для выполнения операций про-
екта.
● Определение бюджета. Процесс консолидации (сум-
мирования) оценочных стоимостей отдельных операций и
пакетов работ, чтобы создать базовый план по стоимости.
● Контроль стоимости. Процесс мониторинга статуса
проекта для актуализации его стоимости и управления изме-
нениями базового плана по стоимости.
Невозможно правильно оценить стоимость, определить
бюджет и контролировать его, если во время планирования
не были явно определены требования к управлению стоимо-
стью. Определение требований к управлению стоимостью в
двух словах можно описать как разговор между спонсором
и руководителем проекта на тему «Как вы понимаете управ-
ление стоимостью в нашем проекте».
В ходе беседы руководитель может пройтись по списку
ключевых для себя вопросов, которые мы уже затронули в
этой главе ранее, и проговорить со спонсором его ожидания
в явном виде. Самая большая ошибка на данном этапе очень
похожа на ошибку при сборе требований – придумать ответ,
не задавая вопрос: дескать, «это же само собой разумеется».
 Цель управления
стоимостью проекта
Главная задача управления стоимостью – это завершить
проект, не превысив согласованный бюджет. Для этого ме-
неджеру необходимо постоянно отслеживать состояние про-
екта и контролировать факторы, ведущие к тратам.
В управление стоимостью входит:
● отслеживание фактических затрат на всех этапах про-
екта, которое заключается в сопоставлении выполненного
объема работ с потраченными средствами;
● прогнозирование конечной стоимости проекта, а также
принятие решений, необходимых для того, чтобы не выйти
за рамки установленного лимита;
● проактивное управление факторами, которые вносят
изменения в базовый план по стоимости;
● работа с изменениями в содержании проекта (согласо-
вание и принятие решений, а также недопущение включения
в проект ненужных изменений);
● информирование заинтересованных сторон о состоя-
нии стоимости проекта и ее изменениях.
Главная цель этой области знаний – грамотно определить,
за что мы будем отвечать, и решить, как мы будем добивать-
ся нужного эффекта.
 Виды затрат по проекту
Если упростить всю экономическую теорию о природе за-
трат, то можно сделать два высокоуровневых обобщения: по
объему производства и по принадлежности к проекту.
По объему производства:
● переменные затраты (Variable costs), величина которых
зависит от объема выпускаемой продукции, – например, рас-
ходы на квалифицированных специалистов или материалы,
которые нужны для проекта (в IT это зарплаты);
● фиксированные затраты (Fixed costs), величина кото-
рых не зависит от объема выпускаемой продукции, – напри-
мер, покупка сервера и лицензий, необходимых для работы
над проектом.
По принадлежности к проекту:
● прямые затраты (Direct costs) – могут быть прямо и
непосредственно отнесены к конкретному проекту: вы мо-
жете указать на компонент проекта и сказать, что это одна из
ваших статей расхода и вы платите за него (например, для ре-
шения какой-то конкретной задачи отдельного проекта вам
нужно купить компьютер, который будет задействован толь-
ко на этом проекте);
● косвенные затраты (Indirect costs) – только частично
связаны с конкретным проектом (например, аренда поме-
щения, где работают команды над несколькими проектами,
оплата отопления, других коммунальных услуг и т. д.).
 Что такое невозвратные
издержки и откуда они берутся
Любой проект может столкнуться с таким понятием, как
невозвратные издержки или утопленные затраты, – это трата
денег на что-либо, что невозможно дальше использовать.
Например, была у вас мечта открыть собственный бар. Вы
берете помещение в аренду, вкладываете в ремонт $50 000
и запускаете бар. Но люди в бар не идут. В итоге содержа-
ние бара обходится в $1000 ежемесячно на аренду и зарпла-
ту бармена, а перспектив никаких. Вы продолжаете и про-
должаете вкладывать деньги в бар, поскольку вам жалко за-
крыть свое детище и признать, что идея не сработала. В этом
примере все вложенные в бар деньги – это невозвратные за-
траты. Владельцу бара лучше быстрее это признать, закрыть
бар и прекратить терять деньги.
В бизнесе такие затраты часто связаны с «проектами-пи-
томцами», которые рождаются внутри компании для ее соб-
ственных нужд. Реализуются они потому, что у конкретно-
го человека есть мечта или идея, которую он хочет вопло-
тить. Убедить инициатора в неактуальности этой затеи почти
невозможно, даже если ситуация на рынке изменилась, а ре-
зультатами работы никто пользоваться не будет.
Руководитель должен уметь идентифицировать невоз-
вратные затраты и, что еще важнее, иметь мужество иници-
ировать закрытие проекта, если:
● проект больше не отвечает целям бизнеса;
● стоимость переделок под новые цели бизнеса выше, чем
стоимость реализации нового проекта.
 Два экономических закона,
влияющие на проект
При работе со стоимостью проекта следует учитывать
два важных экономических закона, которые непосредствен-
но влияют на стоимость проекта.
Кривая обучения. Говоря об управлении стоимостью
проекта, мы не можем пройти мимо такого понятия, как кри-
вая обучения сотрудников. Она помогает эффективнее про-
гнозировать стоимость некоторых работ. Это особенно акту-
ально для IT-сферы, где основная часть затрат – это зарпла-
та.
Правило кривой обучения гласит, что со временем стои-
мость работы, которую мы выполняем, должна уменьшаться
в силу того, что специалисты становятся более опытными. И
это необходимо учитывать. Проиллюстрировать можно гра-
фиком, представленным на рисунке 46.
Действие этого правила мы можем наблюдать на примере
роста специалиста. Например, для некой работы мы нани-
маем молодого, но перспективного студента. Естественно, в
первое время он будет справляться с задачами не так быстро,
как хотелось бы, но со временем серьезно прибавит в скоро-
сти и навыках.
На практике некоторые менеджеры попадают в две ловуш-
ки, связанные с кривой обучения.
 1. Переоценка уровня подготовки сотрудника. Как след-
ствие, постановка нереальных целей.
2. Переоценка способностей человека к обучению. Напри-
мер, если раньше молодой специалист стабильно наращивал
уровень своей производительности, то менеджер продолжа-
ет верить, что сотрудник и дальше продолжит развиваться в
том же темпе. На самом деле так не происходит: скорость ро-
ста всегда замедляется. Это нужно учитывать, особенно если
планируется использовать кривую обучения при распределе-
нии задач на критическом пути. Задачи на критическом пу-
ти обычно требуют назначения опытных специалистов. Если
же мы хотим кого-то обучать, то делать это нужно там, где
есть временной резерв.
 Закон убывающей доходности. В управлении проек-
тами необходимо помнить еще и об экономическом законе
убывающей доходности. Этот закон гласит, что в какой-то
точке увеличение факторов стимулирования производства
не ведет к росту дохода. Иллюстрируется этот закон графи-
ком, представленным на рисунке 47.
В примере с IT-проектом речь может идти о том, что мы
добавляем в него новых сотрудников, а эффективность ко-
манды от этого не увеличивается. Больше не значит лучше.
Есть правило, гласящее, что семь человек сделают работу
девятерых эффективнее, чем 12. Семь человек будут рабо-
тать на пределе своих возможностей. У них будет меньше ка-
налов коммуникации и, соответственно, меньше разрознен-
ной информации, что позитивно скажется на их продуктив-
ности. Если в команде занято шесть-девять человек, это бу-
дет оптимальная структура для работы. А вот если одинна-
дцать и более, то в ней будут чаще обсуждать работу, чем
выполнять ее.
 Базовый план стоимости проекта
Базовый план стоимости проекта (Cost baseline) – это
согласованная спонсором проекта версия бюджета, распре-
деленная по периодам. Он не включает в себя управленче-
ский резерв, и изменить его можно только через согласова-
ние со спонсором.
Управленческий резерв (Management reserve) – это
предусмотренные планом управления проектом средства,
предназначенные для снижения стоимостных и временных
рисков.
Базовый план используется для сравнения фактических
затрат, возникающих в ходе работ, с изначально заплани-
рованными. Разрабатывается он путем суммирования одоб-
ренных бюджетов для различных операций расписания ра-
бот, включая резерв на возможные потери (рис. 48).
 Как правило, заказчик проекта выделяет бюджет не сра-
зу, а поэтапно. Чаще всего следующий транш приходит по-
сле достижения заранее определенной ключевой точки –
Milestone. До этого момента проект финансирует компа-
ния-исполнитель из своих средств. И чем меньше итерация
работы (чем больше ключевых точек), тем чаще в компанию
поступают деньги (рис. 49).
 Оценка эффективности
расходования средств
Понять, насколько эффективно расходуются деньги, мож-
но разными инструментами. Один из них – метод освоенно-
го объема.
Метод освоенного объема (Earned value
management) – это один из самых распространенных спосо-
бов контроля при управлении стоимостью проекта. Он по-
могает руководителю отслеживать отклонения фактическо-
го объема выполненных работ и их стоимости от заплани-
рованных. Метод работает абсолютно для любых проектов в
любой отрасли.
Метод использует следующие показатели:
● PV (Planned value) – запланированная стоимость работ
на рассматриваемый период времени;
● EV (Earned value) – запланированная стоимость фак-
тически выполненных работ на рассматриваемый период
времени, то есть освоенный объем;
● AC (Actual cost) – фактическая стоимость выполнен-
ных работ на рассматриваемый период времени.
Чтобы подсчитать, насколько мы отстаем от плана или
опережаем его, необходимо знать два индекса: SPI и CPI.
SPI (Schedule performance index) – индекс выполнения
календарного плана, говорящий нам о том, насколько мы
вписываемся в запланированный график. Он используется
для прогноза сроков завершения проекта. Рассчитывается
по формуле:

Если вы получили индекс меньше 1, то проект отстает от

расписания. Если больше, то опережает. Если индекс равен
1 – значит, все идет по плану.
При работе с этим индексом важно в первую очередь ана-
лизировать операции, находящиеся на критическом пути,
что позволит понять, с опережением или опозданием выпол-
няется проект в целом.
CPI (Cost per performance) – индекс стоимости выполнен-
ных работ. Рассчитывается по формуле:

Этот индекс иллюстрирует эффективность использования

бюджета с точки зрения выполненных работ. Если показа-
тель меньше 1, значит, тратится больше, чем было заплани-
ровано на этот объем работ. Если больше 1, то уровень за-
трат меньше, чем планировалось к этому времени. Если 1 –
все идет по плану. Также можно сказать, что данный индекс
показывает объем результатов на каждый вложенный доллар
или рубль.
Индексы могут серьезно обмануть менеджера, если ис-
пользовать их неправильно. Например, если мы таким об-
разом будем считать операции, не находящиеся на критиче-
ском пути, то можем получить весьма благостную картину,
когда все индексы будут больше 1. В то же время может ока-
заться, что операции на критическом пути уже отстают от
графика и перерасходуют бюджет, – следовательно, выбива-
ется из него и весь проект.
Хорошая практика – рассчитывать такие коэффициенты
отдельно для критического пути и для проекта в целом: тогда
можно получить объективную информацию о состоянии дел.
Для закрепления материала советуем посмотреть наше
видео с примером.
https://youtu.be/NSxsCFOFEZs
 Выводы
Управление стоимостью проекта дает менеджеру данные,
необходимые для принятия решений о невключении лиш-
них работ в проект.
Знание типов затрат проекта и базовых законов экономи-
ки помогает правильно оценивать его стоимость.
Разработка бюджета проекта на основании базового плана
по стоимости поможет избежать перебоев с его финансиро-
ванием, так как можно спрогнозировать, сколько денег необ-
ходимо для достижения каждой ключевой точки.
Управление освоенным объемом – прекрасный инстру-
мент для оценки состояния проекта. На базе этого метода
можно построить много полезных и информативных метрик.
 Глава 12
Процессы исполнения проекта
После того как проект спланирован, пришло время брать-
ся за работу, но так происходит в идеальном мире. В реаль-
ности работы проекта начинаются тогда, когда планирова-
ние еще в самом разгаре. В этом есть определенный риск:
итоговый план окажется иным, нежели мы представляли, а
часть работ будет выполнена зря. Мы осознанно идем на этот
риск, запараллеливая планирование проекта и работу над
ним, чтобы быстрее завершить проект.
Итак, что должен делать руководитель на этапе исполне-
ния?
 Управление интеграцией проекта
Управляя интеграцией проекта, руководитель должен
идентифицировать, объединить и связать вместе все процес-
сы, необходимые для управления проектом.
Задачи, которые нужно решить, выглядят следующим об-
разом:
● нахождение компромиссов между конкурирующими
требованиями и целями заинтересованных сторон;
● принятие решений о том, где концентрировать усилия
команды в определенный момент времени;
● построение удобных процессов и их адаптация под ко-
манду проекта и заинтересованные стороны;
● анализ потенциальных проблем и выработка способов
их решения до того, как эти проблемы станут критическими;
● координация работы проекта в целом.
Нужно убедиться, что все части проекта синхронизирова-
ны и согласованы. К работам по интеграции проекта относят:
● разработку устава проекта и плана управления проек-
том: ИСР, стоимость, расписание, коммуникации и т. д.;
● управление знаниями проекта: сбор и структуризация
всей информации;
● управление изменениями;
● руководство работами и мониторинг их исполнения;
● закрытие проекта или его фазы.
 Управление ресурсами проекта
Под ресурсами понимается команда проекта (мы не лю-
бим называть команду и людей «ресурсом», но так уж нам
диктует методология) и материальные ресурсы (оборудова-
ние, материалы и пр.). В IT-проектах главный и часто един-
ственный ресурс – это команда. Нужно определить, какая ко-
манда нам нужна, собрать ее и управлять ею.
 Управление
коммуникациями проекта
Главная задача управления коммуникациями в проекте –
это построить эффективное общение и обмен информаци-
ей между заинтересованными сторонами. Они могут иметь
разные взгляды, мотивацию и уровень знаний, а также куль-
турные различия. Нужно понять, кому, какая и в каком объ-
еме нужна информация, и настроить соответствующие кана-
лы обмена ею.
 Управление качеством проекта
Необходимо спланировать качество исполнения работ в
проекте и определить, какие действия будут направлены на
достижение этого качества. Далее нужно выполнить эти дей-
ствия и контролировать достижение целевых показателей.
 Управление закупками проекта
Если для проекта требуется купить какой-либо внешний
продукт или услугу, то руководитель отвечает за то, чтобы
спланировать такую закупку, произвести ее и проконтроли-
ровать исполнение обязательств продавцом.
В IT обычно закупками занимается отдельное подразделе-
ние, так что руководитель проекта редко делает закупки сам.
 Выводы
Исполнение проекта является самой интересной и слож-
ной частью работы менеджера.
Управление интеграцией проекта нельзя делегировать.
Ответственность за проект в целом лежит только на вас.
Нужно видеть общую картину, аккуратно собирать все части
мозаики вместе и объединять результаты работ. Еще необхо-
димо интегрировать все процессы на проекте. Большинство
процессов являются итеративными, то есть повторяющими-
ся. Например, выявление нового риска может повлиять не
только на содержание работ, стоимость и расписание проек-
та, но и на состав команды, который будет необходим. Пона-
добится повторить этап планирования и внести соответству-
ющие корректировки. И так снова и снова с каждой новой
вводной, которая может сильно поменять один из базовых
планов.
Руководитель проекта в первую очередь выступает в роли
лидера. Работа с командой, ее создание и развитие – основа
успеха любого проекта. Тема эта очень большая и интерес-
ная, и мы посвятили ей отдельную главу. Кроме того, важ-
ными являются темы качества и построения коммуникаций,
поэтому им мы также посвятили отдельные главы.
Во время исполнения проекта руководителю нужно отсле-
живать и держать под контролем все происходящие процес-
сы. Поэтому в следующей главе мы рассмотрим вопросы мо-
ниторинга и контроля проекта.
 Глава 13
Мониторинг и контроль проекта
На протяжении всего проекта руководитель должен четко
понимать, как идут дела, и держать в курсе происходящего
все заинтересованные стороны. Это необходимо, чтобы и ру-
ководитель, и заинтересованные стороны принимали верные
решения по текущим вопросам и проблемам, связанным с
исполнением проекта. Понимание текущего статуса необхо-
димо для прогнозирования дальнейшего развития проекта и
возможных сдвигов в содержании, расписании и стоимости.
Менеджер собирает информацию, документирует и рас-
пространяет ее и выявляет отклонения, из-за которых откла-
дывается достижение целей проекта. Чтобы определить ве-
личину отклонений, нужно сравнивать текущие и заплани-
рованные показатели выполнения.
Помните, что есть три базовых плана: по содержанию, сто-
имости и расписанию. Вот именно с ними и сравнивается те-
кущее состояние проекта. Менеджер должен не только оце-
нивать текущие тенденции, но и строить прогнозы, как будут
идти дела, если продолжать работу с той же скоростью. На-
пример, вы трудитесь над проектом, который по плану дол-
жен длиться шесть месяцев. Прошло уже полтора месяца, а
выполнен объем работы, который изначально планировалось
завершить за месяц. Какой вывод из этого следует? Расписа-
ние проекта увеличилось в полтора раза. Если не предпри-
нять корректирующих действий, то проект будет готов через
девять месяцев, а не через шесть.
 Как правильно мониторить проект
Задача менеджера – анализировать ход проекта с точ-
ки зрения целей, сроков, бюджета, качества и степени удо-
влетворенности заказчика, заданных изначально. Для этого
нужно сделать следующее.
1. Сфокусируйте усилия на анализе работ, которые долж-
ны были начаться или закончиться один период назад и два
периода вперед. Например, за прошлую неделю и на две
недели вперед.
2. Определите, какие работы выполнены успешно. Похва-
лите и поощрите людей, которые хорошо сделали свое дело.
3. Определите, какие работы выполняются с опозданием,
и оцените, как это повлияет на срок сдачи всего проекта. Ка-
кие действия можно предпринять для смягчения негативно-
го эффекта?
4. Проанализируйте работы, старт которых запланирован
на ближайшее время. Заранее убедитесь, что исполнители
знают о них, готовы их выполнять и завершат предыдущие
задачи к нужному времени. Если становится очевидно, что
какая-то работа не начнется вовремя, то нужно составить
прогноз относительно того, как опоздание повлияет на да-
ту завершения всего проекта: найти блокирующие факторы
и проверить, можно ли на них каким-то образом повлиять,
чтобы работа все-таки началась в намеченный срок.
 Использование метрик при
оценке состояния проекта
Нельзя управлять тем, что нельзя измерить. Метрика –
это графическое отображение результатов измерения ка-
кой-либо величины во времени. Как пример, можно постро-
ить метрику помесячного отставания прогнозируемого сро-
ка завершения проекта от запланированного изначально. Да-
вайте разберемся на примере (рис. 50).
На рисунке видно, что в сентябре и октябре мы прогнози-
ровали отставание срока сдачи проекта в две недели. В на-
чале ноября оно резко выросло до шести недель, а затем на-
чался тренд на снижение. Какие выводы можно сделать из
этой метрики?
В сентябре и октябре все было стабильно: отставание не
сокращалось, но и не увеличивалось. Это говорит о том, что
команда работала ровно, как и прогнозировалось. Внезап-
но в начале ноября произошло событие, которое привело к
тому, что отставание выросло до шести недель. Вполне воз-
можно, что сработал один из рисков или одно из допущений
проекта оказалось неверным.
Далее мы видим, что с декабря по март отставание начало
хоть и медленно, но сокращаться. Нам это говорит о том, что
менеджер проекта и его команда приложили усилия к тому,
чтобы сократить отставание.
 При помощи метрик можно отслеживать влияние, кото-
рое оказывает на производительность команды то или иное
решение, принятое в ходе работы над проектом. Допустим,
чтобы ускорить работу, в начале ноября руководитель пере-
строил рабочие процессы в командах. То, что отставание на-
чало сокращаться, говорит о верности принятых решений.
Еще метрики помогают увеличивать производительность
и достигать целей. Если цель проекта – завершить разработ-
ку в срок, то метрика будет очень мотивировать руководи-
теля и команду сделать все возможное, чтобы сократить от-
ставание до нуля.
 Примеры метрик

Метрики проекта:

● отклонение по срокам, или индекс выполнения сроков

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

Метрики продукта:

● увеличение дохода (Expansion revenue) – процент новой

прибыли, которую бизнес получает от клиентов;
● индекс приверженности клиентов (Net Promoter Score,
NPS) – опрос, который демонстрирует, насколько ваши кли-
енты готовы рекомендовать продукт своим друзьям;
● индекс удовлетворенности клиентов (Customer
Satisfaction Score, CSAT) – опрос, который демонстрирует,
насколько ваши клиенты удовлетворены продуктом;
 ● отток пользователей (Churn) – подсчет ушедших из
компании клиентов и связанных с ними доходов, которые
недополучила компания;
● ключевые показатели эффективности (Key Performance
Indicators, KPI) – всевозможные показатели бизнеса, к кото-
рым нужно стремиться.

Метрики команды проекта:

● Производительность – объем работ, выполненный за

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

Метрики качества:

● Количество дефектов.
● Степень покрытия кода тестированием.
● Процент времени, когда система работала и была до-
ступна.
 Корректирующие и
превентивные действия
Например, метрика показала: на проекте что-то пошло не
так. А что делать дальше?
Дальше нужно вносить изменения в процесс работы орга-
низации, чтобы повлиять на источник возникновения неже-
лательных отклонений и убрать его. Всегда лучше заранее,
проактивно продумать, какие шаги предпринять в случае
ошибки, чем действовать по факту. И вот тогда в компа-
нии начинают появляться соответствующие процессы и ре-
гламенты. Корректирующие действия описывают, что надо
сделать в случае возникновения отклонения, на которое нам
укажет метрика. А превентивные действия позволяют не до-
пустить возникновение проблемы.
Например, вы ведете проект по разработке новой платеж-
ной системы. Метрики демонстрируют, что количество де-
фектов существенно выросло в начале марта. Анализ основ-
ной причины показывает: все дело в том, что первого мар-
та проект покинул архитектор Патрик, который решил орга-
низовать свой собственный стартап. Корректирующим дей-
ствием будет постараться как можно быстрее найти толко-
вую замену архитектору на рынке. А превентивным действи-
ем, чтобы избежать подобных проблем в будущем, будет на-
значить back up или заместителя для каждой ключевой по-
зиции на проекте. Ведущий специалист обучает более юно-
го коллегу таким образом, чтобы тот мог выполнять его обя-
занности во время отпуска или болезни. В случае ухода клю-
чевого сотрудника его заместитель сможет достаточно быст-
ро подхватить работу и не допустит провалов на проекте.
Суть процессов мониторинга и контроля проекта состоит
в сборе и проверке информации, ведению отчетности и ин-
формировании заинтересованных сторон. Эта работа ведет-
ся на протяжении всего проекта.
Метрики – это классный инструмент, но достаточно тру-
доемкий в применении, поскольку необходимо кропотливо
собирать данные и время от времени перепроверять их. По-
этому руководитель проекта сам должен выбрать те из них,
которые будут полезны и эффективны для конкретного про-
екта.
Заранее продуманные корректирующие и превентивные
действия помогают избежать крупных провалов, поскольку,
действуя в стрессе и спешке, легко что-нибудь упустить.
 Глава 14
Карьера: кем лучше быть –
техническим специалистом
или руководителем проектов?
В IT-отрасли принято растить руководителей проектов
внутри компании. Как правило, из разработчиков, тестиров-
щиков или бизнес-аналитиков, которым нравится общаться
и находить общий язык с заказчиками. Этому есть простое
объяснение: если нанимать руководителя проекта со сторо-
ны, то есть вероятность ошибиться и взять человека, кото-
рый не подходит культуре компании или не сработается с
командой. Цена этой ошибки обычно очень высока: не толь-
ко потеря времени на неудачно выбранного кандидата, но и
возможная потеря всей команды, поскольку люди приходят
работать в компанию, а уходят от конкретного руководителя.
Так вот, если перед вами вдруг встал выбор, кем быть –
продолжать развиваться как технический специалист или
попробовать себя в управлении проектами, – то эта глава для
вас. Попробуем разобраться в плюсах и минусах каждого из
вариантов.
 Быть технарем
У хорошего технаря есть ряд существенных преимуществ
перед руководителем проектов, который больше не пишет
код, а тратит 100 % своего времени на управление.
Во-первых, всегда есть куда расти. Технологии идут впе-
ред семимильными шагами: появляются новые стеки, но-
вые языки программирования, развивается инфраструктура.
Это все очень интересно, но, чтобы постоянно быть в курсе
всех изменений, нужно много времени посвящать изучению
нового.
Во-вторых, если понадобится, разработчик может рабо-
тать удаленно из любого уголка мира. Это здорово.
В-третьих, работу в другой стране найти проще инженеру,
чем руководителю проектов. Технологии ведь везде одина-
ковы, в отличие от культуры.
Есть и минусы. Во-первых, можно надолго застрять на од-
ном длинном проекте и остановиться в развитии.
Во-вторых, есть риск потерять навыки общения и связь с
окружающей реальностью. Это побочный эффект постоян-
ной работы за компьютером.
 Быть менеджером
Давайте начнем с минусов, чтобы закончить на позитиве.
Во-первых, постоянные встречи, переговоры и общение с
людьми отнимают много времени. Ваш календарь будет за-
полнен собраниями и встречами, и вы будете оставлять вре-
менные слоты для работы, чтения писем и обедов.
Во-вторых, постоянный стресс для руководителя проек-
та – это рабочая норма. Нужно научиться с этим жить.
В-третьих, проекты все время требуют внимания. Часто
дела нужно заканчивать поздно ночью, в выходные и даже в
отпуске. Просто отвлечься от работы не получится.
В-четвертых, если вы решите быть руководителем проек-
тов, то уже не сможете быть в курсе всех технологических
новинок: детально изучать их, скорее всего, не будет време-
ни.
В-пятых, придется отстраниться от команды: в качестве
«своего парня» вас воспринимать уже не будут, так как вы
стали начальником. Да и расстраиваться на людях теперь уже
нельзя. Если вы вдруг не знали, для чего руководителю про-
ектов отдельный кабинет, то он для того, чтобы запираться
в нем и плакать.
А как же плюсы? Конечно же, они есть.
Во-первых, большой масштаб решаемых задач. Управляя
командой, можно сделать гораздо больше, чем в одиночку.
Нет большего удовольствия, чем запуск крупного проекта и
осознание того, что вы сделали его вместе.
Во-вторых, менеджер принимает решения и несет ответ-
ственность. К слову, любому руководителю платят именно за
опыт и ответственность. Чем больше у него опыта, тем вер-
нее решения, тем спокойнее и хладнокровнее он будет вести
себя в сложных ситуациях, ведь он уже через них проходил.
Тут еще могу добавить, что, с моей точки зрения, любому
руководителю полезно заниматься адреналиновыми видами
спорта. Так можно натренироваться адекватно реагировать
на выбросы адреналина и в сложных ситуациях оставаться
спокойным и рассудительным.
В-третьих, помощь в росте и развитии людей. Каждый
проект – это процесс обучения. Очень редко руководите-
лю попадается команда, которая на 100 % знает, что делать.
Обычно члены команды учатся в ходе проекта, чтобы затем
успешно его завершить.
Для меня рост людей – это один из самых важных момен-
тов. Очень приятно наблюдать за тем, как люди сначала учат-
ся решать сложные, почти невыполнимые в начале проекта
задачи, а затем легко справляются с ними.
Какой путь выбрать – это сугубо индивидуальное реше-
ние. Если вы любите людей и общение, умеете быть лидером
и работать в условиях стресса, то из вас может получиться
хороший руководитель проектов. При этом нужно понимать,
что хорошим разработчиком вы уже не будете, так как фи-
зически не сможете изучать все технологические новинки.
Стать хорошим менеджером – это долгий путь, на осво-
ение этой профессии уйдут годы. В моем случае трансфор-
мация «разработчик – руководитель проектов» заняла пять
лет. Сначала я 90 % времени тратил на написание кода, а
оставшееся время – на управление. Через пять лет ситуация
была обратной. Свою последнюю строчку кода я написал в
январе 2011 г. В 2012 г. я уже стал руководителем портфе-
ля проектов и управлял отделением из 55 человек. И пере-
до мной уже стоял другой серьезный вызов – привести нашу
команду к успеху, а не написать код.
Алексей Минкевич
 Глава 15
Команда проекта
и работа с людьми
Если пустота накрыла пеленой наш общий стол,
Все по каютам разбрелись, забыли, кто есть
кто, –
Нужно начать с начала, прервать весь этот
вздор,
Вызов принять и вместе пройти сквозь общий
шторм.
Это наш общий шторм, наша новая картина.
Здесь пашут головы, работают руки и спины.
Все для того, чтоб общим трудом смогли мы
Корабль привести в новые зеленые долины.
И если так, то прямо сейчас нужно идти нам,
Нужно идти нам.
Каста

Команда – это фундамент проекта. Крайне тяжело грамот-

но спланировать проект без сплоченной команды, а реали-
зовать – просто невозможно.
 Что такое команда проекта
Команда – это группа людей, объединенных одной целью,
общими производственными задачами и общим подходом к
их решению. Члены команды обладают взаимодополняющи-
ми навыками.
Несколько свойств команды:
● идеальный размер – 6–9 человек;
● функциональные обязанности ее членов дополняют
друг друга;
● взаимная ответственность: группа работает по принци-
пу «мы отвечаем перед собой», а не «мы отвечаем перед на-
чальством» – в этом случае члены команды боятся подвести
друг друга, а не вызвать недовольство менеджмента;
● наличие общей цели, которая позволяет синхронизиро-
вать и сфокусировать деятельность всех членов команды.
 Управление командой проекта
Как и любая другая система, команда без управления
стремится к хаосу. Независимо от рабочего подхода, должен
быть человек, который будет упорядочивать работу коман-
ды.
Цель управления – добиться такого состояния системы,
при котором 100 % приложенных командой усилий прибли-
жают проект к успешному завершению.
С точки зрения PMI в управлении командой существуют
следующие процессы.
● Планирование управления человеческими ресур-
сами. Процесс идентификации и документирования ролей
в проекте, зон ответственности, требуемых навыков и отно-
шений подотчетности, а также создания плана обеспечения
проекта персоналом. На этом этапе менеджер определяется
с ожиданиями относительно команды, решает, какие специ-
алисты нужны на проекте, какого уровня и сколько.
● Набор команды проекта. Процесс подтверждения
доступности необходимых специалистов в компании и набо-
ра команды для выполнения задач проекта. На этом шаге мы
приступаем к собеседованиям и найму людей.
● Развитие команды проекта. Процесс обучения и по-
вышения квалификации людей в команде, улучшения уров-
ня взаимодействия между ними и общих условий работы
для того, чтобы повысить общую эффективность выполне-
ния проекта. Еще на этапе набора команды менеджеру сле-
дует определиться, каким образом он будет развивать людей
и какие возможности для этого предусмотрены на проекте.
● Управление командой проекта. Процесс контроля
эффективности работы команды, обеспечения обратной свя-
зи, решения проблем и управления изменениями, направ-
ленными на оптимизацию выполнения проекта. Менедже-
ру нужно определиться, как он будет управлять командой в
ежедневном режиме. Например, какие процессы и инстру-
менты будут использоваться в проекте, как будут принимать-
ся решения и преодолеваться конфликты и т. д.
 Как создавать команду
Отбор кандидатов в команду состоит из четырех этапов.
1. Планирование. Прежде чем нанимать людей, менедже-
ру следует ответить на несколько вопросов. Какую команду
вы собираетесь создать? Когда вы ее собираете? Кого вы в
нее отбираете? В чем ее назначение?
2. Отбор кандидатов. На этом этапе проводятся собесе-
дования, чтобы отобрать нужных людей. Во время собеседо-
вания необходимо обращать внимание на два аспекта:
● технические навыки: знания, опыт, способности;
● личностные качества: целеустремленность, умение ра-
ботать в команде, независимость, уверенность в себе и др.
Процесс отбора сложен и неоднозначен, поэтому в данной
главе мы рассмотрим его подробнее.
3. Создание команды. На этом этапе менеджеру нужно
организовать людей в команду и разделить между ними роли
и обязанности.
4. Выстраивание коммуникации. Менеджеру нужно
убедиться в том, что значимая информация передается кор-
ректно. Также необходимо регулярно проводить совещания
о ходе выполнения работ и распространять протоколы с их
итогами среди заинтересованных сторон проекта.
 Командообразование
Итак, мы набрали людей, но назвать их командой пока
нельзя. Американский психолог Брюс Такман описал четы-
ре стадии командообразования, а со временем появилась и
пятая. Схематически их можно изобразить так, как показано
на рисунке 51.

Поговорим о каждой подробнее.

Формирование (Forming). На этой стадии менеджер со-
бирает людей вместе и начинает проект. Все рады и вооду-
шевлены, но производительность пока очень низкая. Задача
руководителя проекта на этом этапе – сформулировать и по-
яснить людям цель и задачи проекта.
Вдруг что-то идет не так: люди начинают понимать, что
проект сложнее, чем казался с первого взгляда, уже есть ряд
проблем, возникают споры и конфликты. Мы переходим к
стадии шторма.
Шторм (Storming). На этой стадии члены команды не по-
нимают, что происходит и почему все идет не так. Начина-
ются конфликты, недоверие и взаимные обвинения, которые
усиливают бурю. Каждый член команды по-своему пережи-
вает шторм: кто-то будет валить всю вину на других; кто-то –
говорить, что у него все в порядке и искать причины про-
блем нужно в другом месте; кто-то и вовсе может замкнуть-
ся в себе.
Преодолеть этот этап позволяет создание одного докумен-
та – устава команды. В нем должны быть отражены:
● цель команды и ее задачи;
● роли и ответственность;
● обязательные правила, в рамках которых будет работать
команда.
Подписать устав должны все члены команды. И в случае
возникновения проблем менеджер всегда может апеллиро-
вать к нему: «Ребята, а вы помните, о чем мы с вами догова-
ривались? Мы будем конфликтовать или все-таки займемся
делом?»
 Устав команды должен говорить о том, что проблем толь-
ко лишь у одного человека в команде не бывает. Если они
есть у одного – они есть у всех.
Основная задача руководителя – перевести конфликт из
деструктивного в конструктивный, то есть сделать так, чтобы
участники конфронтации обсуждали конкретный вопрос и
варианты его решения, а не переходили на личности с огуль-
ными суждениями и критикой.
Распространены случаи, когда во время стадии шторма
команда недовольна всем. Тогда нужно попросить каждого
высказать свое мнение относительно проекта и его разви-
тия. Разговор нужно строить в ключе улучшения существу-
ющих процессов, а не критики существующего порядка. Де-
ло в том, что если мы спрашиваем: «Что не так?», то человек
может начать критиковать действия другого члена команды,
а это приведет лишь к деструктивному конфликту, в то вре-
мя как вопрос «Что мы можем сделать лучше?» убирает лич-
ностный момент и направляет диалог в конструктивное рус-
ло.
Когда команда начинает решать конфликты конструктив-
но, она переходит к следующей стадии.
Нормализация (Norming). Этот этап характеризуется
тем, что команда выбирает общую цель и план ее дости-
жения. Личные амбиции уходят на второй план. Конфликт-
ность снижается, а коллектив становится сплоченным. Здесь
уже начинается командная игра.
 Основная проблема данного этапа – члены команды не хо-
тят ругаться и спорить, так как очень дорожат хорошими от-
ношениями с коллегами и готовы согласиться с посредствен-
ным предложением, только чтобы избежать напряженности.
Задача руководителя – стимулировать конструктивное об-
суждение, чтобы команда сфокусировалась на возможностях
и улучшениях. На этом этапе менеджер проекта строит куль-
туру команды и объясняет правила работы, общения, приня-
тия решений: что такое хорошо и что такое плохо. Произво-
дительность команды начинает расти.
Высокая эффективность (Performing). На этом этапе
команда начинает работать с высокой эффективностью.
Задача руководителя проекта – работать с приоритета-
ми и определять задачи для команды согласно расписанию.
Ведь основная опасность этой стадии в том, что при отсут-
ствии ясных приоритетов и ответственности за определен-
ные участки работы команда может легко вернуться на ста-
дию штормов. К наиболее популярным конфликтогенным
факторам можно отнести следующие:
● нечеткие рабочие требования;
● отсутствие приоритетов;
● команда не знает, кто и за что отвечает.
Источником конфликтов может также выступать органи-
зационная структура компании – например, при работе в
матричной структуре, когда у каждого сотрудника два ру-
ководителя: ресурсный и руководитель проекта. Если мене-
джеры между собой в явной форме не обсудили условия во-
влечения сотрудников в проект, то команда будет испыты-
вать постоянные проблемы с конфликтующими приоритета-
ми и, вероятно, ясностью при принятии решений.
Роспуск (Adjourning). Рано или поздно проект заканчи-
вается. Сотрудникам тяжело работать с полной отдачей, не
имея ни малейшего представления о том, что с ними будет
дальше. Они начинают переживать и искать работу на тот
случай, если их текущий работодатель не запустит новый
проект.
Самое важное, что в этой ситуации может сделать мене-
джер, – рассказать, что ждет команду после окончания про-
екта. Если готовится новый – это отлично, но если нет, то
можно поддержать специалиста, рассказав, что с его опытом
и умениями он сможет легко найти работу. К тому же мене-
джер может предложить помочь хорошей рекомендацией.
Сильнее всего людей пугает неопределенность. Чем мень-
ше ее будет, тем спокойнее будет чувствовать себя человек.
 Развитие команды
Развитие команды – это процесс совершенствования ком-
петенций сотрудников и улучшения взаимодействия между
ними для повышения эффективности выполнения проекта.
Развивать команду – очень важная и интересная задача для
менеджера.
Совершенствование может быть направлено на:
● превращение группы людей с разными интересами,
прошлым и профессиональным опытом в интегрированное
и эффективное рабочее подразделение, исповедующее сле-
дующие принципы:
● вместе мы сильнее, чем каждый взятый в отдельности;
● совместные решения лучше, чем индивидуальные;
● увеличение креативного потенциала каждого отдельно
взятого члена команды;
● повышение уровня сознательности каждого отдельно
взятого члена команды.
Для построения личностного плана развития сотрудников
руководитель проекта должен периодически лично встре-
чаться с каждым из них для обсуждения их желаний и ожи-
даний относительно обучения и карьерного роста. Далее
формируется план достижения личных целей.
 Мотивация команды
Согласно PMI, одной из самых популярных теорий моти-
вации на текущий момент является теория американского
психолога Фредерика Герцберга. Она основывается на гипо-
тезе, что у каждого человека есть внутренние потребности,
которые побуждают к тем или иным действиям в зависимо-
сти от созданных условий.
Герцберг провел ряд экспериментов, на основе которых
выделил две группы факторов:
● гигиенические – факторы, удерживающие на работе
(административная политика компании, условия труда, зар-
плата, отношения с начальниками, коллегами, подчиненны-
ми);
● мотиваторы – факторы, мотивирующие на работу (до-
стижения, признание заслуг, ответственность, возможности
для карьерного роста).
Гигиенические факторы не способны мотивировать чело-
века, хотя наличие проблем с ними приводит к неудовлетво-
ренности работой.
С мотиваторами тоже все очень интересно: их отсутствие
не влечет за собой неудовлетворенности работой, а их на-
личие вызывает удовлетворение и мотивирует работников,
стимулирует их развитие и повышает эффективность.
Поэтому для развития команды важно понимать, что дви-
жет ее членами. Кто-то хочет приносить пользу миру (такие
люди, например, работают в open-source-проектах), кто-то
хочет добиться признания коллег, кому-то важнее карьер-
ный рост. Людям нужно предоставлять работу, которая со-
ответствовала бы их ценностям.
Практически в любой компании сотрудники большую
часть времени вынуждены выполнять задачи, которые не
всегда им интересны. Чтобы их мотивировать, можно чере-
довать рутинные процессы, необходимые для работы ком-
пании, с интересными сотруднику задачами. Этого намного
проще добиться, если в коллективе работают и молодые, и
опытные специалисты: то, что является рутиной для одного,
может стать новым профессиональным вызовом для другого.
Как вы уже поняли, деньги далеко не лучший мотиватор,
но важно платить человеку столько, сколько платят в сред-
нем на рынке, чтобы соблюдать баланс гигиенических фак-
торов. Об этом говорит теория Герцберга. Ряд других уче-
ных также проводили исследования на тему зависимости эф-
фективности людей интеллектуального труда от вознаграж-
дения и доказали, что чрезмерно высокие зарплаты могут
вызывать обратный эффект – производительность падает.
Чтобы зарплата не демотивировала специалиста, важно
соблюдать несколько простых условий:
● удостовериться, что сотруднику понятны правила по-
вышения зарплаты;
● следовать правилу «сначала результат, потом повыше-
ние»;
● руководствоваться принципом «повышение зарплаты
сотрудника всегда связано с повышением уровня ответ-
ственности и/или увеличением его вклада в успех компании
(выросла производительность, выполняются более сложные
задачи)».
 Управление командой
Управление командой – это процесс наблюдения за рабо-
той сотрудников и ее оценки. Руководитель оказывает вли-
яние на поведение команды, обеспечивает обратную связь,
решает возникающие проблемы, управляет конфликтами и
изменениями с целью оптимизации выполнения проекта.
К инструментам и методам управления относятся:
● обратная связь;
● оценка исполнения проекта;
● урегулирование конфликтов;
● навыки межличностного общения:
● лидерство;
● влияние;
● результативное принятие решений.
Тяжело найти руководителя, который осознанно был бы
против карьерного роста. Как ни парадоксально, но на прак-
тике многие руководители сами делают все возможное, что-
бы их не повысили, – становятся «незаменимыми». Только
они обладают определенной информацией, компетенцией и/
или полномочиями, тем самым замыкая все ключевые реше-
ния на себя. В результате руководство крайне неохотно рас-
сматривает повышение таких людей, осознавая все сопут-
ствующие риски. Следовательно, задача руководителя, кото-
рый хочет двигаться по карьерной лестнице, – растить свою
команду и не бояться делиться ответственностью. В этой гла-
ве мы собрали ключевые инструменты для решения постав-
ленной задачи.
 Работа с людьми
Теперь перейдем к работе с людьми и наиболее часто
встречающимися ситуациями. Начнем с найма и увольнения
сотрудника.
Кажется, что в поиске людей нет ничего сложного: разме-
щаете объявление на сайтах с вакансиями, проводите собе-
седования с кандидатами, выдаете и проверяете тестовые за-
дания. Справился – берем, нет – не берем.
Все это хорошо работает лишь в теории. На практике все
гораздо сложнее. Вам нужно не просто найти специалиста с
требуемыми навыками, но и человека, который смог бы впи-
саться в команду, прижиться в компании и коллективе, при-
нять их культуру, правила и традиции.
 Найм сотрудника
Прежде чем начать поиск сотрудника, ответьте на вопрос:
кого именно мы ищем и как? Чтобы получить четкий ответ,
составьте описание вакансии и процесса поиска, который вы
планируете использовать. Даже если вы не опубликуете ва-
кансию, это поможет понять, какой именно кандидат вам ну-
жен и как вы будете выбирать подходящего человека.
К составлению описания вакансии и ко всему процессу
поиска сотрудника обязательно нужно привлекать команду,
в которой открыта вакансия. В частности, обсудите с коман-
дой, какой человек необходим, решите, кто проведет собесе-
дование и как именно оно будет проходить. Например, в ви-
де одного интервью или двух отдельных – общего и техниче-
ского. Заранее определите и согласуйте с ребятами, прово-
дящими собеседование, важные критерии отбора кандидата
и механизм оценки соответствия каждому критерию.
Далее вы публикуете вакансию или ищете подходящих
кандидатов во внутренней базе компании и собираете соот-
ветствующие резюме.
 Как выбирать тех, кого
пригласить на собеседование
Следующий этап – изучение полученных резюме. На нем
менеджер и команда решают, кого в итоге позвать на собесе-
дование. Команда поможет лучше оценить технические на-
выки кандидатов.
Компании заинтересованы в людях, с которыми можно
рассчитывать на долгосрочное сотрудничество. Читая резю-
ме, обращайте внимание на то, как часто человек меняет ра-
боту. Если инженер с десятилетним опытом ни в одной ком-
пании не задержался дольше года, то с очень высокой веро-
ятностью с ним что-то не так.
Очень полезно раздобыть рекомендации с предыдущих
мест работы. Наша практика показывает, что в IT-сфере
многие работали вместе, поэтому знают друг друга. Найти
знакомого (или знакомого знакомого), который работал с
кандидатом, не так сложно. Кроме того, многое о человеке
могут сказать его аккаунты в социальных сетях. Важно не
полениться и отыскать страницу или блог кандидата, чтобы
посмотреть, чем он увлекается и интересуется.
Итак, если резюме понравилось всей команде и о человеке
тепло отзываются его бывшие коллеги, то кандидата можно
звать на собеседование.
 Собеседование
Перед собеседованием распечатайте несколько копий ре-
зюме кандидата, чтобы коллеги, участвующие в интервью,
могли просматривать его по ходу разговора и задавать уточ-
няющие вопросы.
В первой части собеседования менеджеру нужно расска-
зать о себе, компании и команде, в которую ищут сотруд-
ника. Полезно перед началом рассказа о компании спросить
кандидата о том, что он уже о ней знает. Ответ на этот во-
прос – хороший показатель того, насколько вакансия инте-
ресна человеку. Ведь если кандидат перед собеседованием
даже не прочитал о профиле деятельности компании, то,
скорее всего, его интерес к ней невелик и вы просто потеря-
ете время.
Далее можно переходить к вопросам. Важно сделать так,
чтобы кандидат как можно меньше волновался. Начните с
простых открытых фраз: «Пожалуйста, расскажите о своей
карьере», «Пожалуйста, расскажите о том, чем вы занима-
лись на первой работе» и т. д.
Когда кандидат перестанет нервничать, можно перехо-
дить к основным вопросам: «Расскажите, пожалуйста, по-
дробнее о последнем проекте», «Что вам нравится, а что не
нравится в текущей работе?», «Сравните несколько компа-
ний, в которых вы работали», «Как выглядит ваш идеальный
день?», «Опишите работу своей мечты, которую вы ищете».
Цель этих вопросов – понять отношение кандидата к ра-
боте. Если он может четко рассказать, чем занимался, с горя-
щими глазами пояснить, что нравилось, и с сожалением го-
ворит о том, что не нравилось, значит, он увлекается рабочи-
ми задачами. И это очень хорошо. Сравнение компаний по-
казывает, что человек ценит в работодателе, а описание иде-
ального дня помогает понять, что его мотивирует. Ответ на
вопрос о работе мечты позволит оценить, способна ли ком-
пания дать это кандидату, не обманет ли она его ожидания.
Можно попросить собеседника дать отзыв о своих руково-
дителях – это покажет, как у него складываются отношения
с вышестоящими менеджерами. Далее можно переходить к
техническим вопросам и вопросам, специфическим для дан-
ной вакансии.
По ходу интервью ведите записи о кандидате, выставляя
ему оценки по критериям, которые важны для этой позиции.
Они впоследствии пригодятся при выборе наиболее подхо-
дящего человека и помогут избежать предвзятости. Часто
возникают ситуации, когда под воздействием первого впе-
чатления ты решаешь, что нашел идеального человека. И
дальше уже не хочется продолжать собеседование. Внутрен-
няя договоренность и необходимость оценивать по конкрет-
ным критериям помогает вернуться с неба на землю и про-
вести собеседование правильно.
В конце интервью стоит узнать зарплатные ожидания кан-
дидата и сроки его выхода на работу. Обязательно нужно
сообщить ему о том, когда вы с ним свяжетесь и сообщи-
те о результатах собеседования. Как правило, сразу дать от-
вет невозможно, так как для принятия решения нужно по-
общаться с несколькими кандидатами.
Если претендентов много и процесс поиска растягивает-
ся на несколько недель, то во время каждого из собеседова-
ний следует вести записи обо всем происходящем: ставить
оценки, делать пометки, отмечать, насколько кандидат соот-
ветствует критериям и требованиям вакансии. Эти записи и
оценки впоследствии помогут сравнить претендентов и вы-
брать лучшего.
 Принятие решения
о приеме на работу
После всех собеседований следует решить, кому все-таки
сделать предложение о работе. Для этого всем, кто участво-
вал в интервьюировании кандидатов, нужно собраться вме-
сте и обменяться мнениями. В разговоре обращайте внима-
ние на следующие аспекты: насколько каждый кандидат со-
ответствует требованиям к вакансии и насколько вписывает-
ся в культуру компании, хотите ли вы видеть этого человека
в команде, возникло ли ощущение, что вам будет комфортно
с ним работать. Принять решение помогут записи, сделан-
ные в ходе интервью.
 Предложение о работе
Принимая человека на работу, мы, по сути, подписываем
два контракта. В первом мы оговариваем его должностные
обязанности, график работы и зарплату. Второй – психоло-
гический, он содержит в себе определенные ожидания, ко-
торые есть у специалиста. И если их не оправдать, то через
некоторое время он разочаруется и уйдет. Предлагая чело-
веку работу, нужно еще раз рассказать о своих ожиданиях от
него, а также расспросить о его ожиданиях от компании.
Нужно распечатать для кандидата предложение о работе,
в котором указать его позицию в команде, предлагаемую за-
работную плату и график ее выплат, величину отпуска и про-
чие условия, которые могут быть важны при принятии кан-
дидатом решения. Важно сохранить копию предложения о
работе в электронном виде для архива. Это может помочь в
случае возникновения спорных вопросов.
Приглашая человека на работу, мы рекомендуем ему при-
нять окончательное решение еще до разговора с его руко-
водством. Если пойти по такому сценарию, то улаживание
вопросов с нынешним работодателем станет исключитель-
но технической процедурой. Он, конечно, может попытаться
удержать сотрудника и повлиять на него, но решение о смене
работы человек должен принимать сам.
После этого нужно будет лишь обсудить с кандидатом
срок, который понадобится ему на принятие решения, и
предложить ему задать интересующие его вопросы. Далее
остается ждать ответа.
 Ошибки при поиске и найме людей
Рассмотрим несколько ошибок и подводных камней при
найме людей.
Один из лучших источников кандидатов – это друзья дей-
ствующих сотрудников компании. Если людям нравится у
вас работать, то они с радостью будут рекомендовать своим
друзьям переходить в вашу компанию. Правда, иногда этот
механизм дает сбои. Очень важно, чтобы друзья, как бы их
вам ни расписывали ваши сотрудники, проходили собеседо-
вания и все этапы отбора наравне с другими кандидатами.
Самые серьезные ошибки при найме мы совершили тогда,
когда поверили в безупречность приведенных друзей и взяли
их на работу не в результате проведения стандартного про-
цесса, а после очень сокращенного интервью. Несколько та-
ких ребят оказались непродуктивным и даже токсичными,
разрушающими внутреннюю атмосферу в команде. Следо-
вание стандартной процедуре найма нового сотрудника по-
могло бы избежать такой ситуации. Друзья и знакомые – это
лучший источник кандидатов, но нельзя слепо ему доверять.
Обращайте внимание на то, как собеседники отзываются
о своих предыдущих работодателях. Если на всех прежних
местах работы, по мнению кандидата, менеджмент был ужас-
ным, это очень тревожный звоночек. Стоит один раз принять
решение, верное для компании, но неудобное такому чело-
веку, как все хорошее будет разом перечеркнуто и вы попа-
дете в категорию ужасных менеджеров, которые повстреча-
лись на пути этого сотрудника. Людям свойственно легко за-
бывать хорошее, зато долго помнить решения, которые идут
вразрез с их личными интересами.
В процессе найма важнейшую роль играет HR-команда.
Вы сможете находить и собирать вокруг себя действительно
хороших людей, только если разделяете с вашими HR-спе-
циалистами принципы, взгляды, отношение к жизни и куль-
туру. Только в этом случае к вам будут приходить люди, ко-
торые отлично впишутся в компанию и команду.
 Адаптация нового
сотрудника в команде
После того как человек принял приглашение, нужно еще
до его выхода организовать подготовку всей необходимой
ему техники и доступов. С первой же минуты в офисе у
сотрудника должна быть возможность приступить к работе.
Ситуации, когда человек неделю ждет компьютер или доступ
к какому-то сервису или ПО, возникать не должно.
Вторая важная задача – знакомство нового сотрудника с
командой, правилами и культурой компании. В самом нача-
ле первого рабочего дня нужно лично познакомить сотруд-
ника с членами команды, рассказать о принятых в компании
правилах и традициях. После чего предоставить ему для изу-
чения специальный документ для новичков, в котором опи-
сана культура и жизнь компании, команды, процессы, пра-
вила, план и оборудование офиса, пропускная система, гра-
фик работы, информация об отпуске и т. д.
Для нового сотрудника следует составить план обучения,
где будут отражены процесс погружения человека в работу и
специфика проекта. Каждому новичку назначается ментор,
которому он может задать любой вопрос. Таким ментором
может быть его непосредственный руководитель или кто-то
из команды.
Через две недели с новичком нужно провести встречу для
обсуждения его прогресса и возникающих трудностей. Ана-
логичную встречу нужно провести еще через месяц. Такие
беседы дают новому сотруднику возможность задать волну-
ющие его вопросы и ускоряют процесс адаптации.
Если вы нанимаете сотрудника с испытательным сроком,
то после его окончания нужно провести встречу и расска-
зать, какое решение приняла компания относительно даль-
нейшего сотрудничества. Каким бы ни было это решение,
менеджер должен его объяснить.
Очень важно, чтобы с первого дня новичок почувство-
вал себя как дома, поэтому этап адаптации очень важен.
Ведь чем быстрее человек станет частью вашей команды, тем
быстрее он начнет показывать отличные результаты.
 Увольнение сотрудника
Рано или поздно каждый менеджер оказывается в ситуа-
ции, когда он вынужден уволить человека. Это неприятная
процедура, но иногда другого выхода нет. Обычно ситуация
развивается по двум сценариям.
Первый сценарий – простой. Наняли нового сотрудника,
но он не смог успешно пройти испытательный срок. Здесь
моральный выбор довольно прост: у человека не получилось,
нет ожидаемой производительности, не соответствует куль-
туре компании или не вписался в команду. В этой ситуации
вы просто желаете ему удачи и расстаетесь. Вакансия откры-
вается снова. Вероятность того, что новый кандидат срабо-
тается с существующей командой, составляет всего порядка
60 %. Если у менеджера и его команды этот показатель вы-
ше, то можно смело говорить о том, что у него хорошо по-
ставлен процесс отбора кандидатов и проведения интервью.
Второй сценарий – сложный. Например, когда нужно уво-
лить человека, который долго проработал в компании. По-
чему? Здесь может быть много вариантов: человек выгорел,
не выдержал давления, повел себя неприемлемо и стал ток-
сичным, у компании или команды изменились цели и куль-
тура, а человек не может вписаться в новые условия. В такой
ситуации эмоционально сложно принять решение об уволь-
нении, так как это сотрудник, который работает уже давно.
Тем не менее такое решение нужно принять, и чем раньше,
тем лучше. Незаменимых людей нет.
Обычно команда помнит об уволенном сотруднике 3–5
дней. Если решение было верным, то все испытывают облег-
чение, работать становится легче, и об уволенном скоро за-
бывают. Как и обо всем плохом в жизни.
 А можно ли обойтись
без увольнения?
Если у менеджера появились первые мысли о том, что
с сотрудником нужно прощаться, то первым делом нужно
честно поговорить с ним о соответствии результатов его ра-
боты ожиданиям. Существует большая вероятность, что слу-
чай не хронический, человек поймет, что от него хотят, и
вернется в рабочую колею.
Очень важно набраться смелости и вызвать человека на
честный разговор. Менеджер должен объяснить сотруднику,
что именно его не устраивает и что нужно исправить. После
этого необходимо составить четкий план работы по исправ-
лению ситуации и установить сроки, в которые необходимо
уложиться. Ожидать какого-либо результата можно только
в случае, если требуется небольшая коррекция поведения.
Мы все росли в разных семьях, в разной атмосфере и усло-
виях. Пытаться скорректировать базовые принципы и цен-
ности человека не стоит. Перековать то, что в человека вло-
жили родители, – занятие сложное и неблагодарное.
Если эта мера не помогла, то наступает время второго
разговора – последнего предупреждения. Не помогло? Тогда
уже ничего не поделаешь: пришла пора расставаться.
 Обратная связь
Одна из составляющих успешного управления командой –
предоставление обратной связи. В широком смысле обрат-
ная связь (feedback) – это отзыв, отклик, реакция на любое
событие. Менеджер проекта должен постоянно давать обрат-
ную связь членам своей команды. Это важно, потому что:
● дает понять сотруднику, что его вклад важен и нужен;
● помогает сотруднику профессионально расти;
● помогает определить уровень квалификации сотрудни-
ка.
Положительная обратная связь обеспечивает рост и пре-
образование системы, отрицательная – стабильное функци-
онирование системы и корректировку отклонения от цели.
Человек не будет расти как профессионал, если он не по-
нимает, что делает верно, а где ошибается. Только отзыв
со стороны менеджера позволяет ему оценить собственный
вклад в общее дело.
Важно не только уметь давать обратную связь, но и на-
учиться принимать ее самому.
 Модели обратной связи
Существует несколько моделей работы с обратной связью.
Модель гамбургера. Ключевые принципы этого метода:
обсуждение того, что получилось, что можно улучшить, и
общего впечатления о работе.
Работа по этой модели выглядит следующим образом. Ме-
неджер рассказывает человеку о том, что у него получилось
хорошо. Далее переходит к тому, что можно было бы сделать
лучше и как. Нужно понимать, что между понятиями «выва-
лить тонну критики» и «предложить улучшения» – большая
разница. Хвалить человека за достижения очень важно. Ес-
ли же этого не делать и только ругать за провалы, то со вре-
менем он перестанет проявлять всяческую инициативу, опа-
саясь критики. В конце нужно поделиться общим впечатле-
нием от совместной работы.
Модель ролла. В упрощенном виде она выглядит так:
● описываете контекст рабочей ситуации;
● перечисляете свои наблюдения;
● выражаете свои эмоции относительно происходящего;
● сортируете информацию по значимости;
● подводите итоги, внося предложения.
Какую из этих моделей работы с обратной связью выбрать,
каждый решает сам. В любом случае нужно учитывать тот
факт, что все люди разные: с кем-то лучше работает один
подход, а с кем-то – другой.
 Активное слушание
В работе руководителя проекта очень важно уметь слу-
шать и слышать других людей. Научиться этому хорошо по-
могает методика активного слушания. Она позволяет по-
нять чувства и мысли собеседника с помощью особых при-
емов участия в беседе, подразумевающих активное выраже-
ние собственных переживаний и соображений.
● Во время разговора сосредоточьтесь на собеседнике,
его эмоциях, состоянии и сообщении, а не фокусируйтесь на
своих мыслях, чувствах и оценке происходящего.
● В краткой форме повторите информацию, которую вы
получили от собеседника. Пересказ дает собеседнику воз-
можность оценить, насколько верно вы восприняли сообще-
ние и его смысл.
● Делайте паузы во время разговора. Пауза дает возмож-
ность обоим собеседникам подумать и рассказать о чем-то,
что могло быть упущено.
● Не избегайте обсуждения болезненных вопросов. Раз-
вивайте мысль и уточняйте спорные моменты, а не додумы-
вайте за собеседника недосказанное.
 Урегулирование конфликтов
В любом коллективе возможны конфликты, и от этого ни-
куда не деться. Чтобы конфликты не развалили проект, нуж-
но понимать, каким образом с ними можно разобраться.
Существует пять способов урегулирования конфликтов.
1. Уклонение (избегание). Перенос решения проблемы
на более поздний срок, отступление от фактической или по-
тенциальной конфликтной ситуации, чтобы лучше подгото-
виться к ее разрешению или передать на решение другим лю-
дям.
Эта тактика используется в тех случаях, когда менеджер:
● не может решить конфликт и повлиять на ситуацию;
● понимает, что эмоции зашкаливают и в данный момент
решения не найдется;
● принимает решение не заниматься урегулированием
конфликта, так как он будет исчерпан в ближайшее время.
Результат: решения нет.
2. Сглаживание (приспособление). Акцентирование
внимания на общих интересах конфликтующих сторон, а не
на конфликтогенных. По сути, это отказ от собственных ин-
тересов (или их части) в пользу благополучия команды, со-
хранения в ней спокойствия и гармонии.
Результат: обе стороны конфликта в проигрыше.
3. Компромисс (урегулирование). Поиск решения, ко-
торое удовлетворило бы обе конфликтующие стороны. На-
пример, есть две команды, которые разработали разные под-
ходы к решению одной и той же проблемы бизнеса. Мы не
хотим обидеть ни одну из них, поэтому считаем, что эти ре-
шения нужно объединить. Но при возникновении сложно-
стей с реализацией общего подхода обе команды будут недо-
вольны и продолжат считать, что их первоначальный вари-
ант был лучше.
Результат: компромисс является проигрышным для обе-
их сторон конфликта.
4. Принуждение (указание). Выбор и лоббирование ру-
ководителем интересов одной из конфликтующих сторон.
Если используется эта тактика, то менеджер просто отдает
приказ, который необходимо исполнить. В этом случае во
главу угла ставятся интересы проекта, а не личные амбиции
сторон.
Результат: решение является проигрышным для одного
участника и выигрышным для второго.
5. Сотрудничество. Объединение нескольких точек зре-
ния, призыв к сотрудничеству и открытому диалогу, кото-
рый способен направить усилия участников конфликта на
выработку совместного подхода. Чаще всего такое решение
на голову выше любого из изначальных предложений.
Результат: решение является выигрышным для всех
участников конфликта.
В идеальном мире руководитель хочет и может решать
все конфликты путем сотрудничества, так как это единствен-
ный метод, при котором конфликт будет исчерпан для всех
его участников. Однако не всегда этот метод может приме-
няться напрямую. Есть случаи, когда перед тем, как призы-
вать участников конфликта к сотрудничеству, необходимо
их охладить, убедиться, что каждая сторона понимает, по-
чему ее визави отстаивает определенную точку зрения. Тем
самым конфронтация переводится в конструктивное русло.
 Делегирование
Делегирование – это процесс передачи ответственности за
достижение определенных целей другим людям.
Если менеджер не будет использовать в своей работе де-
легирование, то вероятны следующие проблемы:
● руководитель будет постоянно завален текучкой, и, как
следствие, у него не будет времени на стратегическое разви-
тие команды и проекта;
● команда может испытывать проблемы с мотивацией и
пониманием приоритетов проекта, так как будет не в курсе
всех его нюансов и проблем;
● развитие команды может быть ограничено только тех-
нической стороной, так как все управленческие активности
будут купироваться руководителем, а без них невозможно
развитие таких позиций, как Team Lead или архитектор, не
говоря уже о возможности появления преемника самого ру-
ководителя проекта.
Прежде чем делегировать полномочия для решения ка-
кой-либо задачи, нужно четко представлять себе, каких
именно результатов вы ожидаете от своих подчиненных, ко-
гда и в какой форме они должны быть достигнуты. Только
добившись полной ясности в этих двух вопросах, можно де-
легировать задачу и контролировать ее исполнение.
Четкий контроль за результатами и строгая дисциплина –
это два фактора успешности делегирования.
Важно правильно выбирать инструменты контроля в за-
висимости от задачи и уровня подготовки исполнителя. Ес-
ли он ни разу ранее не выполнял такую задачу, в первый раз
ее лучше сделать совместно или разбить на такие подзадачи,
которые ему по силам.
Например, к совещанию, которое состоится через неделю,
необходимо подготовить сложный отчет. Руководитель по-
ручает подготовку способному сотруднику, который до это-
го выполнял аналогичные задачи, но подобные отчеты еще
не делал. В данной ситуации наиболее верным подходом бу-
дет разбить все на подзадачи и договориться о сроках выпол-
нения каждой из них. Первой подзадачей может быть сбор
необходимой информации из ряда источников. Убедившись,
что информация собрана верно, руководитель может поре-
комендовать, как именно ее структурировать. В случае за-
труднений на первом этапе у него есть возможность своевре-
менно узнать об этом и помочь сотруднику. Типичная ошиб-
ка руководителя в такой ситуации – поручить выполнить всю
задачу целиком или подготовить все за один день накануне
совещания. В результате руководитель только в последний
момент узнает о неточностях, создавая аврал и себе, и свое-
му подчиненному.
В идеале задачи должны ставиться по принципу
S.M.A.R.T. (рис. 52).
Почувствуйте разницу на примере.
 Обычная постановка задачи: стать
сертифицированным руководителем проектов.
Задача по SMART: успешно сдать экзамен PMP с
результатом не менее 70 % правильных ответов до 31
декабря 2022 г.
В первом варианте непонятен критерий завершенности и
нет временного ограничения. Во втором – есть четкий изме-
римый критерий завершенности и сроки, а цель достижима.
Такой вариант гораздо лучше мотивирует на подготовку к
экзамену.
Руководитель должен быть готов к тому, что первые по-
ручения отнимут больше времени, чем если бы он сделал
делегированную работу сам. Важно не поддаваться соблаз-
ну «сделаю сам, тут дольше объяснять, чем делать», кото-
рый обычно приводит к тому, что сотрудник привыкает сва-
ливать все нестандартные задачи на начальство. Как резуль-
тат, руководитель вечно завален работой. При таком подходе
менеджер превращается в «незаменимого», то есть того, кто
вечно перегружен, не ходит в отпуск и не поднимается по
карьерной лестнице, ведь, кроме него, никто не может вы-
полнить все эти задачи.
 Принятие решений
Решение – это выбор наиболее приемлемой альтернативы
из всего многообразия возможных вариантов.
Если менеджер столкнулся с проблемами в команде или
необходимостью принять сложное решение по дальнейше-
му развитию проекта и/или команды, то можно попробовать
применить следующий алгоритм действий.
Ответьте на вопрос: зачем принимать решение? На-
пример, вы решаете проблему, конфликт или задаетесь це-
лью развивать команду.
Очень важно до погружения в ситуацию понять, как вы-
глядит тот идеальный мир, в котором менеджер принял
некое идеальное решение и все получилось. Если руководи-
тель ловит себя на мысли, что ситуации «до» и «после» ни-
чем не различаются, то нужно ли вообще что-то делать?
Соберите информацию. Чем больше у менеджера дан-
ных, тем выше вероятность принять верное решение. Неза-
висимо от того, какой вопрос требует решения, нужно снача-
ла разобраться в текущем состоянии дел. Если есть пробле-
ма, то нельзя двигаться дальше, не разобравшись в ее при-
чинах. Говоря о развитии, сначала нужно прояснить, к ка-
кой цели мы стремимся, почему она важна и для кого. Ино-
гда бывает, что важность вопроса завышена из-за того, что
человек, для которого этот вопрос важен, просто не стесня-
ется громко о нем говорить, причем по поводу и без. Если
руководитель не разберется в ситуации, он может потратить
все силы на решение вопросов, которые волнуют нескольких
человек. Из-за этого пострадают стратегические вопросы.
Определите ключевые параметры , которые будут
указывать на то, в правильном ли направлении развивается
ситуация. Важно заранее определиться с тем, как будет изме-
ряться успех. Если этого не сделать, то велик соблазн все по-
ложительные изменения метрик объяснить произведенными
изменениями, не обратив внимания на прочие факторы, ко-
торые могли к этому привести.
Выявите возможные варианты решения. При фор-
мировании решений очень важно не зацикливаться на одном
и самом очевидном, а попробовать посмотреть на ситуацию
под разными углами – как с учетом, так и без учета суще-
ствующих ограничений. Возможно, вы найдете лучшее ре-
шение.
Выберите одну из альтернатив. Менеджеру важно
оценить, насколько каждое из решений приближает его к по-
ставленной цели и как это будет отражено в ключевых мет-
риках. Нужно принимать во внимание конечный результат
решения, ценность, которую оно способно принести, и за-
траты на его реализацию.
Безусловно, верных на 100 % решений не бывает, поэтому
выбирать нужно наиболее оптимальные на момент рассмот-
рения.
 Оцените, достигнута ли цель. Для этого сопоставьте
текущее положение дел с ключевыми метриками. Статисти-
ка показывает, что это действие забывают чаще всего. Пси-
хологически человек не любит чувствовать себя неправым,
поэтому, выбрав вариант решения и реализовав его, люди
расслабляются и считают вопрос решенным, хотя в действи-
тельности все может быть совсем наоборот. Будет просто за-
мечательно, если еще до реализации решения будет назначен
ответственный за подведение итогов. Возложив ответствен-
ность за эту активность на определенного человека, мене-
джер минимизирует вероятность того, что о ней забудут.
После того как оценка завершена, нужно принять реше-
ние относительно приемлемости результата. Если он непри-
емлем, то, возможно, придется поискать другие варианты,
пройдясь по каждому пункту алгоритма заново.
Важно понимать, что на выработку решений уходит вре-
мя. И бывают ситуации, когда правильнее принять три быст-
рых решения, корректируя каждое на ходу, нежели потра-
тить дни или недели на выработку оптимального, но уже
несвоевременного решения.
 Выводы
Хорошая команда является основным фактором, от ко-
торого зависит успех проекта. Всегда помните, что разви-
тие сотрудников имеет ключевое значение для осуществле-
ния целей проекта. Помогать команде расти является частью
обязанностей руководителя проекта.
Работа с людьми ярка, многогранна и удивительна. Пони-
мание того, как себя вести в той или иной ситуации, прихо-
дит с опытом и практикой. Будьте примером для команды,
ее лидером, а не начальником. На то, чтобы собрать вокруг
себя хорошую команду единомышленников, уходят годы. Но
когда у вас появится такая команда, вместе вы сможете ра-
ботать над самыми сложными и интересными проектами.
 Глава 16
Карьера: работа с людьми
К тому моменту, когда мне предложили возглавить отдел,
я проработал в компании около шести лет. Я не сомневался,
что у меня получится, но не совсем понимал, каково это –
руководить людьми, которые когда-то были моими началь-
никами и наставниками. Я не был самым сильным специали-
стом в технологии, на которой специализировался отдел, –
были люди опытнее и лучше подкованные технически. На-
чинать в таких условиях было крайне тяжело.
В течение первого месяца практически каждый день при-
ходилось сталкиваться с вопросами, о существовании кото-
рых я раньше и не предполагал. Общение с людьми по рабо-
чим вопросам вызывало некоторую неловкость, как мне ка-
залось, с обеих сторон. Я понимал, что со временем станет
легче, но вот сколько продлится это «со временем», не имел
ни малейшего представления.
В один прекрасный день мне попалась книга Стивена Ко-
ви «Семь навыков высокоэффективных людей», которая по-
могла найти правильный выход из ситуации. Я сфокусиро-
вался на том, чем я могу быть полезен своим людям, как я
могу им помочь, используя свои новые полномочия. Мораль-
но мне сразу стало легче, а со временем, когда получилось
сделать для ребят что-то осязаемое, я почувствовал, что из-
менилось и их отношение ко мне. С тех пор я придержива-
юсь простого правила: сначала сфокусируйся на том, чем ты
можешь быть полезен людям, и только потом у тебя появит-
ся право что-то просить или указывать им, что делать.
Старайтесь действовать в духе сотрудничества в кругу
единомышленников, и тогда вам не придется работать 24/7.
Вы будете спокойны, зная, что команда движется в нужном
направлении и сделает все возможное, чтобы достичь цели.
Алексей Минкевич
 Глава 17
Коммуникации проекта
В ходе проекта все заинтересованные стороны общают-
ся. И это замечательно, но только до тех пор, пока в про-
ект вовлечено мало людей. Если же их становится много,
то все коммуникации нужно планировать, управлять ими и
контролировать. Дело в том, что при росте команды количе-
ство каналов коммуникации растет геометрически. Простой
пример: между четырьмя людьми может быть шесть каналов
коммуникаций, но шесть человек создают уже 15 каналов.
Наглядно это показано на рисунке 53.

Рассчитывается количество каналов по формуле количе-

ства сочетаний:
 n(n – 1)/2,
где n – это количество человек.
Давайте представим, что в проект вовлечено 20 человек.
Возможное количество каналов коммуникаций между ними
резко возрастает до 190! При таком количестве участников
проекта руководитель просто обязан правильно выстраивать
все коммуникации, а не пускать их на самотек.
Серьезные проблемы начинаются тогда, когда участников
в проекте становится больше 60. В таком проекте постоянно
кто-то не знает о том или ином решении руководства, начи-
нании или инициативе. С другой стороны, в рабочих встре-
чах часто участвуют люди, присутствие которых там совер-
шенно необязательно. В итоге приходится с каждым случаем
разбираться индивидуально, а порядок наводить в ходе ре-
троспектив. Какие-то проблемы с коммуникациями удается
решить перестройкой процессов, но работы в этом направ-
лении еще очень много, а это время и ресурсы.
Что же нужно делать? Давайте разбираться.
Основная задача управления коммуникациями состоит в
том, чтобы наладить эффективное общение и обмен инфор-
мацией между заинтересованными сторонами. У заинтере-
сованных сторон могут быть различные взгляды, мотива-
ция, уровни знаний, а также культурные и организационные
различия. Необходимо обеспечить эффективное управление
всеми информационными потоками проекта: планировани-
ем, сбором, обработкой, хранением, распространением, от-
слеживанием и архивированием информации – и контроль
над ними.
 Планирование управления
коммуникациями
Сначала менеджер решает, как построить архитектуру ин-
формационных потоков. Это решение – основа всего плани-
рования. Архитектура включает в себя анализ требований к
коммуникациям, технологии и методы коммуникаций.
Анализ требований к коммуникациям. Нужно выяс-
нить, какие требования к проектной информации существу-
ют у заинтересованных сторон. Все заинтересованные сто-
роны делятся на группы, у каждой из которых свои пожела-
ния. Задача менеджера – понять, какая группа чего хочет, а
также как часто и в каком формате нужно предоставлять ей
информацию.
Технологии и методы коммуникаций. После того как
менеджер разобрался с тем, кому и что нужно, он опреде-
ляет технологии, которыми будут пользоваться заинтересо-
ванные стороны проекта. Учитывая все полученные данные,
менеджер выбирает метод и строит модель, которая впишет-
ся во все требования. Всего существует три модели комму-
никаций.
● Интерактивные коммуникации. Между участника-
ми проекта осуществляется многосторонний обмен инфор-
мацией. Это самый эффективный метод, чтобы все стороны
понимали, что происходит в проекте. Основное правило тут
такое: есть возможность поговорить с человеком или груп-
пой лично – иди и поговори. Если такой возможности нет, то
проводится видеоконференция через Google Meet, BlueJeans
и т. п. Если нет видеосвязи, то голосовой звонок. Важно пом-
нить, что любое обсуждение нужно «накрыть письмом»: обя-
зательно запишите результаты обсуждения и в тот же день
отправьте письмом всем участникам. Дело в том, что обыч-
но все заняты своими делами и со временем могут забыть,
какое именно решение было принято. Письмо поможет вос-
становить ход событий, если это потребуется.
Для быстрого решения простых вопросов хорошо подхо-
дят чаты и мессенджеры: Slack, Telegram, WhatsApp, Viber и
др. Для совместной работы над документами можно исполь-
зовать Google Docs, Confluence или другую удобную для вас
программу.
● Коммуникации методом беззапросного информи-
рования (push). Информация рассылается людям, которые
в ней нуждаются. Этот метод гарантирует распространение
информации, но не дает гарантии того, что она будет факти-
чески получена или понята получателем. Сюда можно отне-
сти письма, заметки, отчеты, сообщения электронной почты
и пресс-релизы.
● Метод информирования по запросу (pull). Исполь-
зуется для очень больших объемов информации или очень
больших аудиторий. С его помощью получатели самостоя-
тельно обращаются к передаваемому содержанию, когда им
это нужно. К таким методам относятся сайты, системы элек-
тронного обучения, хранилища знаний типа Confluence и др.
После того как для всех заинтересованных сторон выбра-
ны методы коммуникаций, следует определиться с тем, как
будет строиться общение между людьми.
В проекте может быть несколько команд, но совершенно
необязательно, чтобы все люди из этих команд напрямую об-
щались между собой. Почему так? Помните, в начале главы
мы говорили, что с ростом количества людей увеличивает-
ся и число возможных каналов коммуникаций. Чтобы ком-
муникации были эффективными, нужно четко разграничить
каналы: кто и с кем должен общаться.
Определение каналов коммуникаций позволяет избежать
стандартных проблем, когда в проект вносятся случайные
изменения. Бывает, что спонсоры проекта предпочитают об-
щаться с кем-либо из разработчиков напрямую и просят вне-
сти в проект незначительные изменения. Разработчик эту
просьбу выполняет, но забывает сообщить об этом архи-
тектору. Изменение, казавшееся разработчику незначитель-
ным, в итоге приводит к глобальному сбою всей системы. И
вся команда вынуждена разбираться с тем, что именно и ко-
гда пошло не так.
Чтобы избежать такой ситуации, менеджеры должны чет-
ко описать каналы коммуникации. Например, на схеме ни-
же (рис. 54) вы можете увидеть, что спонсор проекта (заказ-
чик) общается только с руководителем проекта и не может
напрямую обращаться к команде разработки. Руководитель
проекта обсуждает задачи только с руководителем группы, а
тот уже распределяет задачи внутри команды. Подобная схе-
ма упорядочивает общение и помогает избежать попыток за-
казчика увеличить содержание проекта, общаясь напрямую
с командой.
 Управление
коммуникациями проекта
Задача управления коммуникациями проекта – обеспе-
чить эффективный обмен информацией между заинтересо-
ванными сторонами. Нужно наладить процесс сбора, созда-
ния, распространения и архивирования информации. В то
же время менеджеру нужно обеспечить гибкость процесса
и все время адаптировать его под меняющиеся требования
людей, участвующих в проекте.
Даже если менеджеру кажется, что с коммуникациями в
его проекте все идеально, то всегда можно улучшить что-то
еще. У меня есть хороший пример управления коммуника-
циями. Однажды у меня сменился непосредственный руко-
водитель. Новый хотел держать руку на пульсе всех событий
и попросил меня ставить его в копию всех моих электронных
писем. Мне эта просьба показалась странной, так как у чело-
века нет физической возможности прочитать всю переписку
всех подчиненных руководителей проектов, но я согласился.
Тут же возникла другая проблема: я время от времени про-
сто забывал добавить руководителя в копию, а потому часть
событий в проектах все равно оказывалась для него сюрпри-
зом.
Тогда я решил попробовать оптимизировать процесс:
я прямо спросил, что именно его волнует. Оказалось, что это
ключевые события в моих проектах, новости, прогнозы по
загрузке команд, их росту или сокращению. Эти данные ему
были нужны для планирования и управления пулом ресур-
сов в подразделении. Тогда я предложил вариант, при кото-
ром сам буду собирать новости проектов, а также все нуж-
ные прогнозы в один отчет, который он будет получать раз в
неделю. В итоге коммуникации стали намного более эффек-
тивными. Начальник был в курсе всего, что ему нужно было
знать, а мне стало удобнее работать.
От того, насколько грамотно менеджер построит управле-
ние коммуникациями, зависит то, насколько легко ему будет
управлять проектом.
 Мониторинг коммуникаций проекта
В рамках мониторинга коммуникаций вы должны убе-
диться, что все заинтересованные стороны довольны тем, ка-
кую информацию они получают, в каком виде, объеме и ка-
ким способом.
Для этого время от времени менеджеру нужно узнавать у
заинтересованных сторон, все ли их устраивает, есть ли что-
то непонятное и т. д. В моей практике был один замечатель-
ный случай: я старательно отражал все операции проекта в
Microsoft Project, включая текущий статус проекта и процен-
ты выполнения задач. Каждую неделю формировался спе-
циальный отчет, который я отправлял спонсору со стороны
заказчика, своему руководителю и команде проекта. В нем
все было четко, ясно и максимально понятно. Так думал я.
До тех пор, пока через несколько месяцев руководитель про-
граммы проектов со стороны заказчика не поинтересовал-
ся у меня процентом выполнения одной из задач. И тут я
заподозрил неладное. Естественно, я поинтересовался тем,
смотрит ли он мои пятничные отчеты. Выяснилось, что он
не может открыть файл со статусом проекта из-за того, что
у него нет Microsoft Project. Оказалось, что заказчик поль-
зуется другими инструментами для управления проектами.
Тогда я начал отправлять по пятницам еще и pdf-файл со
статусом задач. После этого у руководителя программы про-
ектов отпали все вопросы.
Урок, который стоит извлечь из этой истории: если люди
ничего не говорят, то это еще не значит, что им все нравится.
 Как бороться с эмоциями
Есть еще одна тема, о которой хочется поговорить в раз-
резе коммуникаций, – эмоции. Иногда в ходе проекта мене-
джер получает информацию (как правило, письмо), которая
вызывает у него бурю эмоций. Так вот, не нужно сразу же
реагировать на такие случаи. Дело в том, что эмоциональные
всплески длятся в среднем 12–15 минут. Зная это, руково-
дитель может отказаться от моментального реагирования и
избежать попадания в негативные ситуации. Вот несколько
советов, которые помогают сохранить самообладание:
● сохраните ответное письмо как черновик и вернитесь к
нему через 15 минут, а еще лучше – на следующий день;
● обсудите возникшую проблему с кем-то, кого она на-
прямую не касается, то есть с тем, у кого она не вызывает
эмоций;
● отложите принятие решения на 15 минут;
● попробуйте поставить себя на место оппонента и по-
нять, что может им двигать.
Эмоции – это то, что мешает принимать правильные ре-
шения и адекватно оценивать ситуацию. Через них челове-
ком могут манипулировать, раскачивая его душевное состо-
яние, из-за чего он способен совершать необдуманные по-
ступки. При управлении коммуникациями важно не допус-
кать такие ситуации и избегать манипуляций.
 Выводы
Эффективное управление коммуникациями является
ключевым фактором в достижении целей проекта. Резуль-
тативные коммуникации означают, что информация предо-
ставляется в правильном формате, в подходящее время,
нужной аудитории и оказывает на нее требуемое влияние.
Эффективные коммуникации означают передачу только той
информации, которая действительно необходима. При по-
строении коммуникаций важно учитывать культурные раз-
личия и доступные инструменты.
 Глава 18
Управление качеством
Вы должны узнать, как клиент определяет
ожидаемое качество, прежде чем воспользоваться
оценкой качества товара как аргументом в
разговоре.
Брайан Трейси

Одна из обязанностей руководителя проекта – убедиться,

что все заинтересованные стороны говорят на одном языке и
у них единое понимание происходящего в проекте. Как по-
казывает практика, управление качеством возглавляет хит-
парад недоразумений, возникающих при выполнении проек-
та. Давайте попробуем разобраться, в чем же тут дело и по-
чему так происходит.
Начнем с определения качества.
Определений качества множество, и вот три самых рас-
пространенных:
● качество – это степень, в которой совокупность внут-
ренних характеристик продукта соответствует требованиям
(PMBOK);
● качество – это некоторая сумма функций или характе-
ристик продукта, необходимость которых определяется за-
явленными ожиданиями и потребностями (PRINCE2);
 ● качество – это совокупность характеристик объекта, от-
носящихся к его способности удовлетворять установленные
и предполагаемые потребности (ГОСТ Р ИСО 9000–2001).
Все определения едины в том, что качество является
некой «совокупностью характеристик», а вот дальше появ-
ляются различия: PMBOK говорит про соответствие тре-
бованиям, PRINCE2, по сути, говорит о том же самом, а
ИСО 9000–2001 приоткрывает нам ту самую первопричину
возникновения недоразумений: «способность удовлетворять
предполагаемые потребности».
Чаще всего под предполагаемыми потребностями пони-
мают стандарты, принятые в отрасли. Именно они могут вос-
приниматься заказчиком как что-то само собой разумеюще-
еся, а несоответствие им может вызвать у него волну него-
дования.
Рассмотрим пример. Заказчик попросил разработать веб-
портал для внутренней коммуникации между разными от-
делениями компании. Одна из задач программиста – разра-
ботать стартовую страницу с актуальными графиками по то-
варам на складе и проданной продукцией по каждому отде-
лению. Макет страницы был разработан с учетом всех заяв-
ленных требований. Заказчик был очень доволен макетом и
с нетерпением ждал результатов. В итоге стартовая страница
была разработана в срок и в точном соответствии с макетом,
но заказчик был вне себя от гнева. В чем проблема?
Проблема заключалась в том, что страница загружалась
несколько минут, и только единичные сотрудники дожида-
лись ее полной загрузки. Для заказчика скорость загрузки
страницы была чем-то самим собой разумеющимся, и он да-
же не задумывался об этом до момента получения результа-
та.
Далее мы рассмотрим, как PMI предлагает действовать,
чтобы не попасть в описанную выше ситуацию.
 Планирование качества
(Quality planning)
Управление качеством подразумевает целый ряд процес-
сов. Но, как обычно, все начинается с определения того, что
понимается под управлением качеством, то есть менеджеры
занимаются его планированием.
На этом этапе нужно решить:
● что будет считаться качеством, в том числе количе-
ственные критерии соответствия и несоответствия;
● сколько времени и денег может быть инвестировано в
качество в рамках проекта;
● что будет означать постоянное совершенствование;
● какими правилами и процессами руководствоваться
для соблюдения критериев качества;
● какие инструменты контроля мы будем использовать.
Основная ошибка, возникающая при управлении каче-
ством, – отражать в плане управления качеством не реаль-
ные, а желаемые и часто невыполнимые стремления и воз-
можности команды. Это обязательно подорвет доверие к
процессам управления качеством. Следовательно, они начи-
нают игнорироваться.
Планирование качества происходит параллельно с осталь-
ными процессами планирования и может оказать значитель-
ное влияние на все базовые планы проекта.
 Для планирования качества важно понимать, что такое
стоимость качества и постоянное совершенствование.
 Стоимость качества
Стоимость качества – это совокупная стоимость всех уси-
лий, направленных на достижение требуемого уровня каче-
ства продукта или услуги, а также совокупная стоимость ра-
бот, которые нужно будет проделать в случае несоответствия
этим требованиям.
Затраты на профилактику и затраты на соответствие тре-
бованиям к качеству продукта включают в себя расходы на
планирование, контроль и обеспечение качества: подготовку
персонала, системы контроля качества и т. д.
В стоимость «отказа», или, другими словами, затрат на
несоответствие качества, входит: доработка продуктов, не
отвечающих требованиям, их элементов или процессов; га-
рантийные работы и потери, а также репутационные потери.
Когда вы планируете качество, не забывайте о том, что
его стоимость складывается не только из соответствия, но
и из несоответствия. Возьмем, к примеру, автомобильную
промышленность. Допустим, какая-то компания выпустила
модель партией 10 000 автомобилей, а затем в ней обнару-
жились проблемы с закрытием багажника. Руководство ком-
пании узнает о дефекте и принимает решение отозвать всю
партию для устранения несоответствия, так как из-за неис-
правности могут пострадать люди, что приведет к скандалу,
штрафам и репутационным потерям. Поэтому производите-
лю дешевле начать отзывную кампанию и исправить недо-
статки, чем потом разбираться с проблемами.
Если мы говорим о программном обеспечении, то здесь
многое зависит от сферы, в которой работает заказчик. Ес-
ли мы создаем ПО для заказа обедов в офис, то, возмож-
но, требований к качеству будет меньше, чем при разработке
ПО для авиадиспетчеров. Во втором случае стоимость соот-
ветствия уровню качества намного важнее, чем страховка на
случай несоответствия, ведь речь идет о человеческих жиз-
нях.
Поэтому, планируя проект, учитывайте его особенности
и только после этого на основании имеющихся данных при-
нимайте решение о том, какой уровень качества будет при-
емлемым.
 Постоянное совершенствование
Работа с качеством неразрывно связана с постоянным со-
вершенствованием.
Постоянное совершенствование (Continuous
improvement) – это освоение новых операций и отказ от тех,
которые оказались малоэффективными или не имеющими
ценности.
Цель постоянного улучшения – повышение эффективно-
сти выполняемой работы за счет сокращения затрат, количе-
ства ошибок и потерь (доработка, время, трудоемкость, ма-
териалы и др.).
Говоря о совершенствовании, мы подразумеваем цикл Де-
минга – Шухарта, который состоит из следующих шагов:
● планирование (Plan) – изучение имеющихся проблем,
определение первопричин, планирование необходимых из-
менений и определение метрик, на основании которых мож-
но будет сделать вывод об удачности/неудачности внесенных
изменений;
● реализация (Do) – внедрение запланированных изме-
нений (желательно в малом масштабе), чтобы собрать эмпи-
рические данные для дальнейшего анализа;
● проверка (Check) – анализ полученных данных на ос-
новании определенных ранее метрик и оценка успешности
внесенных изменений: что пошло по плану, что получилось
не так, как было запланировано, а что вышло даже лучше,
чем представлялось ранее;
● действие (Act) – внесение изменения и новые попытки.
Иногда необходимо провести несколько итераций данно-
го цикла. Это помогает понять, принесло ли планируемое
улучшение те плоды, на которые компания рассчитывала.
Безусловно, не все эксперименты удачные. Бывает, что да-
же после нескольких «вращений колеса» качество продукта
не улучшается. Это признак того, что команда что-то делает
не так. В таком случае нужно менять тактику и двигаться в
ином направлении.
Рисунок 55 наглядно демонстрирует этот подход: успеш-
ность каждого последующего улучшения оценивается от
уровня предыдущего, а не от 0.
 Обеспечение качества
(Quality assurance)
В данном процессе менеджера должен интересовать не ко-
нечный результат, а способ его достижения. Руководитель
проверяет, насколько команда следует правилам и процес-
сам, которые договорились использовать.

Сам по себе тот факт, что команда следует определенно-

му правилу или процессу, не гарантирует достижения целе-
вого уровня качества, но на этапе контроля качества помо-
гает понять природу происхождения проблем.
Следование процессам предполагает получение предска-
зуемого результата, который можно измерить на этапе кон-
троля качества. Если результат будет неудовлетворитель-
ным, то с помощью проведения анализа можно определить,
на каком этапе текущего процесса возникают проблемы, а
затем предпринять меры по улучшению.
Не зная о том, что работа выполняется согласно оговорен-
ным процессам, менеджер не сможет понять, как достигался
определенный уровень качества и какова вероятность, что в
следующий раз он будет таким же.
Мероприятия, направленные на изучение процессов, по
которым работает команда, и выявление несоответствий то-
му, как команда договорилась работать, называются аудита-
ми. Они бывают внешними и внутренними.
Внутренние аудиты помогают понять, насколько эф-
фективны текущие процессы и какие в них есть узкие места,
с которых можно начать улучшения.
Внешние аудиты проводятся независимыми организа-
циями, чтобы определить степень соответствия процессов,
установленных в компании, процессам определенного меж-
дународного стандарта. Например, для сертификации ISO
9001–2008 – распространенного стандарта международной
организации по стандартизации, которая внедряет системы
менеджмента качества по всему миру. Международная сер-
тификация может быть полезна компании-подрядчику для
демонстрации своей зрелости и способности обеспечить ре-
зультат надлежащего качества в долгосрочной перспективе.
 Контроль качества (Quality control)
Процесс контроля качества направлен на приведение ко-
нечного результата в соответствие с теми критериями, кото-
рые были определены во время планирования качества.
Наиболее распространенные инструменты контроля ка-
чества – экспертизы и статистические выборки (statistical
sampling). Экспертиза используется тогда, когда речь идет о
продукте и его проверке.
Для чего они нужны?
● Экспертизы управления определяют статус проекта, до-
стижения, проблемы и их решения.
● Коллегиальные экспертизы определяют, соответствует
ли предложенная или завершенная работа требованиям.
● Экспертизы центра компетенций применяются для
утверждения документов, исследований и предложенных
технических решений проблем.
● Экспертизы пригодности определяют возможность ис-
пользования в реальных условиях продукта или части про-
екта.
Частным случаем экспертизы является Code review – про-
верка одним инженером кода, разработанного другим инже-
нером, на соответствие принятым правилам и стандартам.
Важное отличие от аудита заключается в том, что анализи-
руется готовый продукт (в данном случае – код), а не восста-
навливается процесс разработки с целью выявить, на каком
этапе имело место несоответствие.
Статистические выборки используются в том случае, ко-
гда по каким-либо причинам невозможно проверить весь
продукт. Например, в случае, когда проверка крайне трудо-
емка или приводит продукцию в негодность, что, в свою оче-
редь, ведет к неоправданному удорожанию конечной про-
дукции.
Так, например, ручной пересчет и осмотр зубочисток для
проверки качества продукции и соответствия ее допускае-
мым отклонениям по количеству будет примером неоправ-
данного удорожания товара, а вскрытие банок со шпротами
для проверки качества их наполнения – примером приведе-
ния продукции в негодность.
Статистические выборки всегда идут рука об руку с та-
ким инструментом, как контрольные диаграммы, благодаря
которым можно легко понять, какие действия необходимо
предпринять руководителю.
Предположим, у нас есть некоторая метрика (М), помога-
ющая оценить качество произведенной продукции – напри-
мер, количество зубочисток в упаковке (рис. 56). Мы знаем,
что идеальное количество X = 100 (среднее значение – Mean)
c допустимой погрешностью ± 5. Тогда значения 95 и 105
будут для нас контрольными лимитами. Если вдруг количе-
ство зубочисток в упаковке будет больше 105 или меньше
95, то есть значение выпадет за контрольный лимит, то та-
кое отклонение должно быть воспринято как происшествие
(Issue).

Происшествие – такое событие, которое нарушает нор-

мальный ход вещей. Соответственно, мы должны выяснить,
что его вызвало (найти причину), и предпринять меры по
предотвращению подобных событий в будущем.
Событие, при котором семь контрольных измерений под-
ряд оказываются ниже или выше среднего значения, хотя и
в пределах контрольных лимитов, также должно быть вос-
принято как происшествие. Почему это тоже происшествие?
Представьте себе, что аппарат раскалибровался и постоянно
складывает на две зубочистки больше – это может сказать-
ся на удорожании себестоимости продукции. Случай, когда
аппарат кладет минимум на две зубочистки меньше, также
может быть критичен для компании, так как это могут заме-
тить покупатели. В результате пострадает репутация компа-
нии, а продажи упадут.
 Качество и люди в
управлении проектами
Многие руководители жалуются на своих подчиненных.
Дескать, как можно говорить о качестве, когда человек не
может самостоятельно выполнить простейшее поручение,
что ни сделает – все не так. Вроде и процессы есть, и ин-
струкций вагон, а он все равно не может качественно выпол-
нять свои обязанности. Такой ситуации можно было бы из-
бежать, если бы руководитель изначально проверил членов
своей команды по некоторым пунктам.
● Понимает ли человек, чего от него ждут и какой резуль-
тат предполагается получить после выполнения порученно-
го задания?
● Имеет ли человек необходимые теоретические знания
для выполнения порученной работы? Знает ли исполнитель
о существовании определенного процесса или инструкции,
согласно которой должно быть выполнено задание? Если да,
то ознакомлен ли он с ней?
● Выполнял ли человек подобное задание ранее? Теоре-
тические знания – это, конечно, хорошо, но без практиче-
ских навыков они не позволяют гарантировать результат.
● Владеет ли человек инструментарием для выполнения
работы? Незнание всех возможностей инструментария се-
рьезно замедляет процесс и блокирует достижение результа-
та нужного качества.
● Понимает ли человек, как оценить результат во время
выполнения работы? Неумение распознать ошибку на ран-
нем этапе может сделать установленные критерии качества
недостижимыми, а отсутствие эталона (примера, к которому
нужно стремиться) – вызвать у человека иллюзию того, что
лучше уже не будет.
● Хочет ли человек выполнять данное задание? Послед-
ний в списке, но не по значимости пункт. Отсутствие же-
лания зачастую делает невозможным достижение результата
необходимого качества.
Чтобы работа выполнялась стабильно и качественно, важ-
но, чтобы команда придерживалась всех договоренностей.
И здесь есть особенности: если у вас в команде собрались
сплошные «звезды», то вы сможете выполнить один проект
блестяще, но это совершенно не гарантирует стабильного ре-
зультата в долгосрочной перспективе. Нужно учитывать, что
«звезды» не всегда придерживаются правил. А порядок ча-
ще всего бьет класс.
 Выводы
Качество планируется, а не инспектируется. Невозможно
проверить продукт на соответствие тому, о чем не догово-
рились. Стоимость качества включает в себя как стоимость
соответствия, так и стоимость несоответствия.
Цикл «Планирование – Реализация – Проверка – Дей-
ствие» – это цикл операций, стимулирующий постоянное со-
вершенствование и являющийся основой для улучшения ка-
чества. Процессы управления качеством приносят результат
только при выполнении всей цепочки этого цикла. Необхо-
димо осуществлять проактивное управление, которое преду-
гадывает проблемы, а не борется с их последствиями.
 Глава 19
Карьера: биография Сергея
В каждом приключении надо сделать первый
шаг… Да, банально… Но даже здесь это работает.
Льюис Кэрролл

Я родился в Заславле, но всю свою сознательную жизнь

(лет с трех) прожил в Гомеле.
До старших классов я редко задумывался о будущей про-
фессии. В кругу общения моих родителей было много пред-
принимателей, да и отец, сколько я себя помню, все вре-
мя работал на себя. Мне тогда казалось, что единственно
возможное развитие событий – это найти свою тему, биз-
нес-идею, на которой можно было бы построить собствен-
ную компанию. Мы с отцом даже как-то всерьез просчиты-
вали вариант открытия компьютерного клуба – такие клубы
были популярны в то время. Хотя родственники подшучи-
вали: «Ты любишь поговорить – тебе в юристы нужно».
Программировать я начал в школе на уроках информа-
тики. Тогда в тренде был учебный язык программирова-
ния «Кенгуренок» – среда для обучения, где необходимо да-
вать команды кенгуренку: шаг, прыжок, поворот. С помо-
щью этих команд он перемещался по экрану и оставлял сле-
ды от хвоста. Не скажу, что меня сразу привлекло програм-
мирование, просто выбор был невелик: делать что-то или ма-
яться от безделья. А так и оценки хорошие, и время быстрее
проходило.
Постепенно стало интереснее, и я уже ждал урока и оста-
вался после него, чтобы успеть разработать новый алгоритм
или оптимизировать существующий, так как количество ко-
манд, которые можно было дать кенгуренку, было ограни-
чено. Дальше – больше: нам предложили освоить «Пылесо-
сик» – шкаф с ящиками 3×3, в котором нужно было отсор-
тировать вещи при помощи команд для пылесоса, – а потом
и Pascal.
Когда пришло время задуматься о поступлении в универ-
ситет, я понял, что математику придется сдавать в любом
случае, поэтому нужно было изучать что-то помимо школь-
ной программы. При поиске курсов выяснилось, что в лицее,
где были очень хорошие подготовительные курсы по матема-
тике, есть еще и курсы по информатике. Там учили програм-
мировать на Pascal, работать с офисным пакетом, а еще там
был интернет. В начале 2000-х интернет был чем-то необыч-
ным, и хотелось узнать о нем больше. Я пошел на курсы по
информатике, хотя на тот момент еще не предполагал, что
свяжу свою жизнь с программированием. Выбирая между
экономической и IT-специальностью, я выбрал последнюю.
Так я попал на кафедру автоматизированных систем обра-
ботки информации (АСОИ) ГГУ имени Ф. Скорины.
Уже в первый день я увидел пропасть между своими зна-
ниями в программировании и знаниями моих однокурсни-
ков. Я был почти «нулевой». Багажа, полученного на кур-
сах в лицее, мне хватило на два месяца изучения Pascal. Уже
к сессии я всерьез задумывался, стоит ли мне вообще быть
программистом. Переломный момент наступил в середине
первой сессии, когда я сказал отцу, что не знаю, как она за-
кончится для меня и мое ли это вообще. Я не понимал, что
меня пугало больше в тот момент: то, что я не смогу учиться
на данной специальности, потому что точные науки, к мое-
му большому удивлению, оказались «не моим», хотя в шко-
ле все учителя твердили об обратном, или то, что я подведу
родителей.
Папа посоветовал просто отвлечься и сходить вместе где-
нибудь посидеть. Когда мы шли домой, до меня дошло, что
самым сложным было признаться самому себе и другим, что
я могу не сдать экзамен. Да, я могу не знать ответов на во-
просы в билете и провалиться. Да, на пересдаче тоже может
произойти что-то подобное, и меня отчислят. И что дальше?
Сядем и будем жалеть меня, несчастного? Нет.
После того как я набрался смелости озвучить свои страхи
отцу, я понял, что меня никто не собирается гнобить, а вот
на поддержку в сложный момент я могу рассчитывать. А раз
так, я должен сделать все, что в моих силах. И начать нужно с
того, чтобы быть честным с самим собой и быть уверенным,
что я сделал все, что смог. С того момента у меня пропал
страх перед экзаменами и возможным отчислением.
 На подготовку ко второй сессии я потратил гораздо мень-
ше времени и, самое главное, нервов. Сдал ее на отлично. В
итоге я окончил университет с красным дипломом, не обла-
дая, на мой взгляд, выдающимися знаниями по математике,
физике и программированию. А через несколько лет защи-
тил магистерскую на математическом факультете.
 Начало карьеры
Карьера в IT для меня началась в 2006 г., когда после тре-
тьего курса я попал на практику в компанию IBA. Моей це-
лью было не просто пройти практику, а остаться там рабо-
тать. Как раз в это время моя семья собиралась уезжать из
страны, а я хотел остаться. Ведь переезд для меня означал на
год приостановить свое обучение, чтобы освоить в нужном
объеме новый для меня язык, и только потом продолжить
обучение по специальности. Я искренне верил, что могу сде-
лать гораздо больше за этот год в Беларуси, чем за ее преде-
лами. Единственное условие, при котором я бы мог остать-
ся, не обременяя родителей финансово, – хотя бы частичное
трудоустройство.
В IBA мне предложили продолжить сотрудничество в ро-
ли практиканта, а трудоустроиться удалось только через пол-
тора года. В течение этого времени я осваивал премудро-
сти Lotus-технологий на внутренних проектах и работал на
репутацию, благодаря которой мне, все еще студенту, пред-
ложили бы попробовать свои силы в международном про-
екте. Дело в том, что специфика технологии предполагала
численность команды от 1 до 4 человек и взаимодействие
каждого разработчика напрямую с заказчиком по вверенным
ему системам. Я успешно прошел собеседование и так полу-
чил свой первый опыт работы в международном проекте. Не
могу раскрыть название проекта из-за коммерческой тайны
IBA и из уважения к компании и ее заказчикам.
 О переходе из разработки
в управление проектами
Мой первый опыт управления проектами был неосознан-
ным. Еще студентом я сопровождал приложения для нужд
компании, когда мне предложили взять кураторство над па-
рой других студентов и разработать приложение с нуля. По-
том еще пару приложений. Задачи отслеживали букваль-
но на коленке: вели табличку с расписанием, контрольны-
ми сроками и трудозатратами. Теперь я понимаю, насколько
неверно все делал с точки зрения процессов разработки и
работы с людьми.
По-настоящему я пришел в управление проектами толь-
ко через пять лет – в 2012 г. К тому времени я параллель-
но работал на двух международных проектах, обучал новых
сотрудников работе с Cognos BI и технологии Lotus Notes,
а также отвечал за сопровождение некоторых внутренних
приложений.
Особенность технологии Lotus Notes заключалась в том,
что она не предполагала наличие больших команд. Зачастую
разработчик в проекте по этой технологии самостоятельно
выполнял все задачи – от сбора требований до подготов-
ки релиза. У меня была очень хорошая зарплата, много от-
ветственности, но никакого понимания того, как развивать-
ся дальше. Задачи были однообразные, что-то интересное
«прилетало» крайне редко, поэтому приходилось искать вы-
зовы вне основных проектов, которыми на тот момент для
меня стали разработка и сопровождение решений для внут-
ренних нужд компании.
В какой-то момент я начал понимать, что технический
стек устаревает и пора изучать что-то новое или уходить от
работы исполнителя к работе руководителя. На мою удачу,
руководство как раз искало кандидата, который хотел бы
сертифицироваться в области управления проектами.
Сертифицироваться как руководитель проекта по версии
PMI PMP (Project Management Professional) – достаточно
непростая задача, для выполнения которой нужно в сред-
нем полгода подготовки. Требованиям я соответствовал, же-
лание пройти сертификацию и получить возможность по-
пробовать себя в качестве руководителя в международном
проекте было огромное, но не было четкого понимания,
с чего именно начинать подготовку. Так я попал на свою
первую конференцию для руководителей, где и познакомил-
ся с Алексеем.
На тот момент он готовил ребят к сдаче экзамена на PMP,
и его группа занималась уже больше месяца. Он спросил ме-
ня, что я готов сделать, чтобы сертифицироваться (выяснял
серьезность моих намерений). Я ответил, что планирую от-
дать один из своих проектов, то есть лишиться почти поло-
вины зарплаты. Так я попал в группу, а через полгода успеш-
но сдал экзамен на PMP. Спустя некоторое время мне по-
счастливилось стать руководителем проекта в IBA для одной
крупной международной компании.
Сергей Дерцап
 Глава 20
Комплексное управление
изменениями
Изменение – это любое отклонение от ранее одобренного
базового плана. Оно может повлиять на основные ограниче-
ния проекта: расписание, содержание и стоимость, а также на
качество и на удовлетворенность заказчика. В лучшем слу-
чае изменения затронут какой-то один план, но чаще все-
го – все. Например, есть проект длительностью два месяца
и стоимостью 10 000 руб. Заказчик вносит корректировки и
добавляет к проекту дополнительную работу длительностью
две недели и стоимостью 3000 руб.
После согласования новых сроков и стоимости меняются
базовые планы проекта, в содержание добавляется работа.
Из-за этой корректировки обновится и расписание: проект
будет длиться два с половиной месяца. Изменится базовый
план по стоимости: она вырастет до 13 000 руб. В этом при-
мере поменялись все три базовых плана.
Именно поэтому управление изменениями называется
комплексным: корректировка одного из базовых планов
обычно влечет изменение остальных. Современное про-
граммное обеспечение по управлению проектами, например
Microsoft Project, связывает эти планы воедино, так что как
только меняется один, автоматически обновляются и осталь-
ные. Это удобно.
 Откуда берутся изменения
Существуют следующие источники:
● смена целей и приоритетов у бизнеса заказчика;
● несработавшие предположения, возникшие проблемы,
вопросы и т. д.;
● новая информация, которая появилась уже в ходе ра-
боты над проектом;
● смена или добавление новой заинтересованной сторо-
ны;
● изменения в законодательстве.
Изменения в проекте – это неизбежно и нормально. Новая
информация поступает постоянно, ситуация на рынке может
измениться в любой момент, поэтому не получится сказать
заказчику: «Подождите с новыми идеями. Сейчас проект до-
делаем, а потом уже обсудим». Хотя попытка сделать это –
частая ошибка начинающих руководителей проектов.
Agile – как подход и мировоззрение – учит нас привет-
ствовать изменения. И это абсолютно правильно. Если бы
в проекты не вносились корректировки, то заказчики ча-
сто получали бы ненужные им продукты, которые потеряли
свою актуальность еще до запуска. Например, выясняется,
что конкуренты выходят на рынок с аналогичным решением
через шесть месяцев, так что срок реализации проекта мо-
жет потребоваться сократить, чтобы опередить их.
 Или, скажем, в законодательстве появилось новое требо-
вание, согласно которому данные обо всех кассовых опера-
циях должны в режиме реального времени отправляться в
налоговую инспекцию, – это повод внести соответствующие
изменения в разрабатываемую систему.
 Как работать с
изменениями в проекте
Схематично процесс работы с изменениями выглядит сле-
дующим образом (рис. 57).

Давайте рассмотрим его детальнее.

1. Идентификация изменения. В этом помогает форма
запроса на изменение. Как правило, это простая форма, до-
ступная через интернет (в Google Forms или любом другом
аналогичном сервисе). Имя инициатора и время заполнения
определяются автоматически, поэтому заполнить нужно все-
го одно поле – описание запроса (рис. 58).
 В чем полезность этой формы?
Часто заинтересованная сторона проекта сообщает, что
возникла необходимость или желание что-то в проекте из-
менить. Человеку пришла в голову замечательная идея, и он
спешит ею поделиться. В этом случае руководитель проек-
та должен попросить заполнить форму запроса на измене-
ние. Человеку нужно будет описать свою идею – и тем самым
фактически расписаться в ее авторстве. И вот на этом этапе
исчезает достаточно много замыслов: после изложения идеи
в письменном виде она часто уже не выглядит такой привле-
кательной. Удобство формы также в том, что менеджер не
забудет об изменениях, как часто бывает, если запрос посту-
пил в телефонном разговоре.
2. Уточнение содержания. Когда запрос на изменение
получен, нужно убедиться, что менеджер его верно понял.
При необходимости следует уточнить содержание запроса
у инициатора. Полученная информация также должна быть
отражена в форме.
3. Оценка сложности и стоимости рассмотрения из-
менения и принятие решения об анализе изменения.
Иногда встречаются настолько сложные запросы, что толь-
ко для их оценки требуются недели. В таких случаях нужно
подготовить оценку трудоемкости рассмотрения изменения
и согласовать ее со спонсором проекта. Далее уже он решает,
нужно ли проводить оценку.
В нашей практике нередко случалась примерно такая
переписка: «Привет! Нужно добавить вот такой функцио-
нал» (далее идет описание). – «Привет! Это сложное изме-
нение. Архитектору нужно будет потратить неделю рабочего
времени, чтобы понять, сколько оно будет стоить и как по-
влияет на сроки». – «Хм. Я не думал, что это такая сложная
штука. Тогда не нужно».
В этом случае спонсор проекта не согласовал оценку из-
менения, и мы сразу отправили запрос в архив. Почему не
удалили? Архив нужен, чтобы указать спонсору на принятое
ранее решение в том случае, если он снова придет с этой же
идеей.
Если же спонсор утверждает затраты, необходимые на
анализ изменения, или анализ можно провести очень быст-
ро, то мы переходим к следующем пункту.
4. Идентификация влияния изменений на содержа-
ние проекта, сроки, стоимость и качество. Вместе с ко-
мандой проекта необходимо оценить, как именно запраши-
ваемое изменение повлияет на содержание существующих
работ проекта, расписание, бюджет и качество.
5. Оценка затрат, преимуществ и выбор альтерна-
тивы. Обычно существует несколько способов выполнить
запрос на изменение. Заинтересованная сторона проекта, за-
просившая изменение, не всегда может предложить опти-
мальный вариант, и команда проекта должна подумать, как
достичь такого же результата иначе и с меньшими усилиями.
Из ярких примеров: проект по доработкам внутренней
системы анкетирования сотрудников. Заказчик попросил
добавить возможность отправки определенного шаблона
опросника выбранным сотрудникам. Подобный функционал
требовал трех недель разработки. При детализации запроса
выяснилось, что необходимо учитывать профессиональную
позицию сотрудника, указав ее в начале анкеты: разработ-
чик, тестировщик или бизнес-аналитик. Команда предложи-
ла добавить в опросник возможность кастомизации и им-
порта полей из карточки сотрудника. Подобная альтернати-
ва предоставляла заказчику гораздо более гибкое решение,
и на ее реализацию нужно было потратить всего одну неде-
лю. Заказчик с радостью утвердил данное решение и был им
очень доволен.
6. Оценка стоимости изменения. Необходимо посчи-
тать, сколько будут стоить работы или как долго они будут
выполняться при разных вариантах исполнения запроса на
изменение.
7. Принятие решения о включении изменения в
проект. Спонсор проекта выбирает одну из предложенных
альтернатив, утверждает ее и все расходы на реализацию. За-
тем команда забирает изменение в работу.
8. Обновление документов проекта и внедрение из-
менения. Обычно изменение добавляет в проект опреде-
ленные работы. Поэтому после утверждения изменения но-
вые задачи нужно добавить в иерархическую структуру ра-
бот проекта, его бюджет и расписание. После этого можно
приступать непосредственно к реализации запроса.
9. Документирование решения и информирование
заинтересованных сторон. Перед внесением любых изме-
нений нужно создать или обновить документацию, где де-
тально будет описано, как именно работает дорабатываемая
система сейчас. Это особенно важно в проектах, которые
длятся много лет, иногда десятилетиями. Такая документа-
ция позволит отследить историю изменений проекта и найти
причину проблем, если они вдруг возникнут.
 Как организовать управление
изменениями в своем проекте
Внедрять систему управления изменениями лучше в са-
мом начале проекта. А еще лучше – обсудить ее с заказчиком
до того, как приступить к работам. Необязательно исполь-
зовать какой-либо сложный инструмент для документирова-
ния изменений, можно обойтись простым документом. Глав-
ное, чтобы всем сторонам это было удобно. Если менеджер
планирует внедрить управление изменениями на давно иду-
щем проекте, где все прихоти заказчика исполняются и он
к этому привык (и ничего менять не хочет), единственным
аргументом в дискуссии с ним будет то, что компания-под-
рядчик перешла на новый процесс работы с изменениями и
менеджеру необходимо ему следовать.
Помните, что любые изменения в проекте могут привне-
сти в него новые риски, поэтому не нужно забывать анализи-
ровать влияние изменений на проект и с этой точки зрения.
Скептики скажут: «И что? Теперь на каждый чих заво-
дить форму запроса на изменение и утверждать? Часто дел
там всего на пару минут». Замечание справедливое. В слу-
чае незначительных изменений следует заранее согласовать
со спонсором проекта определенное количество оплаченных
часов на такого рода работы, а также согласовать само опре-
деление «незначительных работ». Например, считать тако-
выми те, которые отнимают не более двух часов. Если сра-
зу очевидно, что изменение небольшое, то оно делается по
упрощенной схеме. При этом нужно отслеживать все запро-
сы на мелкие изменения. В случае, если мы исчерпали согла-
сованные часы, необходимо обговорить со спонсором новый
объем времени на подобные работы.
Менеджер должен организовать работу таким образом,
чтобы все изменения в проект вносились с его ведома:
управлять тем, о чем не знаешь, очень сложно. Почему это
важно? Общаясь с заказчиком напрямую, ваш разработчик,
например, может пообещать ему что-то сделать. Возможно,
он действительно может выполнить обещание, но, в отличие
от менеджера, разработчик не видит всего проекта целиком.
Следовательно, он не знает, как его обещание скажется на
работе других команд, в каком месте их интересы пересека-
ются и не вызовет ли это новых ошибок. Задача менеджера –
выстроить такую систему, при которой со всеми изменения-
ми заказчик шел бы прямо к нему, а не к кому-то из команды.
 Выводы
Процесс работы с изменениями помогает не допустить
бесконтрольного разрастания содержания проекта (Scope
creep), которое автоматически ведет к тому, что проект вы-
ходит из согласованного бюджета, сроки срываются, портят-
ся отношения между заинтересованными сторонами. Биз-
нес всегда будет стремиться добавить еще несколько задач,
и процесс работы с изменениями очень хорошо помогает
наладить конструктивный диалог и совместное обсуждение
возможных вариантов. Руководитель проекта должен быть
в курсе всех запросов на изменения. Ни одно изменение не
берется в работу без согласования и утверждения руководи-
телем проекта.
 Глава 21
Управление заинтересованными
сторонами проекта
Грамотная работа с заинтересованными сторонами про-
екта – ключевой фактор его успешного завершения. Ведь да-
же если проект превысил бюджет, сдан не вовремя, но заказ-
чик в итоге счастлив – значит, проект успешен.
У каждого проекта, большого или маленького, есть заин-
тересованные стороны. Это люди, которые могут влиять на
проект или, напротив, испытывать его влияние. Одни заин-
тересованные стороны непосредственно влияют на результат
проекта: спонсор, команда, руководитель. А есть заинтере-
сованные стороны, которое оказывают косвенное влияние:
СМИ, защитники окружающей среды или просто те, кто по-
чему-то сам решил, что является заинтересованной сторо-
ной, – они будут пытаться вмешиваться в ход работы.
Чтобы успешно завершить проект, нужно еще на ранней
его стадии определить все ключевые заинтересованные сто-
роны. Для этого используйте простой прием – задайте всем
участникам проекта один вопрос: «Кто еще может оказать
влияние на проект и на кого еще он может повлиять?»
Почему очень важно идентифицировать все ключевые за-
интересованные стороны? Если вы как менеджер «потеря-
ли» ключевую заинтересованную сторону и даже не догады-
ваетесь о таком человеке, то быть беде. Он обязательно по-
явится на этапе приемки работ и выдвинет все свои требова-
ния уже в конце проекта. А как мы помним, стоимость вне-
сения изменений в конце проекта максимальна.
Менеджеру нельзя забывать о том, что идентификация за-
интересованных сторон – процесс итеративный, то есть его
следует время от времени повторять. Дело в том, что люди
могут уходить из компании, а на их место придут новые спе-
циалисты – их-то и важно не упустить, чтобы в конце проек-
та не возникло неприятных сюрпризов.
Допустим, мы нашли все ключевые заинтересованные
стороны. Следующий шаг – собрать и проанализировать их
личные ожидания. Здесь менеджеру нужно выяснить, на-
сколько сильно эти люди влияют на проект, определить гра-
ницы их власти и степень заинтересованности в результатах
работы. Чем выше заинтересованность, тем сильнее такой
человек будет вовлекаться в проект и всячески содейство-
вать успеху. Чем выше уровень власти, тем более сильное
влияние он может оказать.
Собрав эти данные, можно разбить заинтересованные сто-
роны на четыре группы (рис. 59).
Люди из группы с высокой властью и сильной заинтере-
сованностью являются опорой менеджера в проекте, они бу-
дут помогать в достижении успеха. В этой группе всегда на-
ходится чемпион проекта – обычно это человек, который его
инициировал.
Самая сложная группа – это люди с высоким уровнем вла-
сти и невысокой заинтересованностью в успехе. Они будут
всячески мешать. Менеджеру необходимо очень тесно рабо-
тать с такими людьми, рекламировать проект и его результа-
ты. Например, рассказывая о том, насколько легче им станет
работать после того, как все успешно завершится. Возьмем
для примера проект по автоматизации бухгалтерии. Когда
мы говорим об автоматизации, то чаще всего подразумева-
ем сокращение штата бухгалтеров. Следовательно, они по-
чувствуют угрозу для себя и могут саботировать работу. В
работе над таким проектом главный бухгалтер должен быть
включен в список ключевых заинтересованных сторон. При
этом ему нужно «продать» проект: рассказать, для чего он
нужен, какие задачи решает, как поможет лично ему и т. д.
Если менеджер проигнорирует главного бухгалтера в нача-
ле проекта, то на этапе сдачи тот просто откажется прини-
мать итоги работы. Сотрудники его отдела, боясь увольне-
ния, скорее всего убедят своего начальника в том, что новой
системой пользоваться невозможно. «Да и власти у тебя ста-
нет меньше…» – добавят они.
 Здесь нам на помощь может прийти чемпион проекта,
который поможет убедить скептиков в полезности всего за-
думанного. Минимальная задача менеджера – добиться то-
го, чтобы скептики стали нейтральны к проекту и сказали:
«Мешать не буду – получится так получится». Задача-мак-
симум – перетащить их в квадрат к людям, заинтересован-
ным в успехе.
С группой, которая заинтересована в успехе проекта, но
имеет низкую власть, работать проще. Этих ребят просто
нужно держать в курсе новостей.
Группу с небольшой властью и невысокой заинтересован-
ностью и вовсе можно игнорировать. Как говорится, собака
лает, караван идет.
 Планирование управления
заинтересованными сторонами
В ходе планирования управления заинтересованными
сторонами менеджер должен разработать стратегии, позво-
ляющие эффективно вовлекать стороны в работу над проек-
том. Эти стратегии основываются на анализе потребностей
заинтересованных сторон, их интересов и потенциального
влияния на успех проекта.
Смысл этого процесса в том, чтобы создать четкий план
взаимодействия со сторонами с тем, чтобы продвигать ин-
тересы и цели проекта. Для работы со сторонами можно ис-
пользовать инструмент, представленный в таблице 3.

Эта таблица содержит список заинтересованных сторон

и их характеристику относительно того, в какой позиции к
проекту они сейчас находятся. Здесь же указывается и та по-
зиция, в которой менеджер хотел бы видеть данную сторону.
Текущий статус человека помечается буквой Т, а желаемый –
буквой Ж. Если текущий и желаемый статусы не совпадают,
менеджер проекта должен спланировать ряд мероприятий,
направленных на то, чтобы привести текущий статус в соот-
ветствие с желаемым.
 Управление и контроль вовлечения
заинтересованных сторон
Как всегда, в рамках управления и контроля менеджер
выполняет запланированные действия: проверяет, верен ли
план и продвигает ли он проект к успеху.
Хороший руководитель постоянно отслеживает и разви-
вает приверженность заинтересованных сторон проекту, пы-
тается выяснить, насколько проделанная работа соответству-
ет их потребностям и ожиданиям. Чем чаще команда проек-
та демонстрирует результат работы бизнесу, тем меньше ве-
роятность сделать с проектом что-то не то. При этом очень
важно пояснять всем заинтересованным сторонам, что имен-
но они получат, когда проект успешно завершится. Таким
образом и происходит управление ожиданиями заинтересо-
ванных сторон. А еще так можно избежать неловкой ситу-
ации, когда в конце проекта получается совершенно не то,
чего все ожидали в начале.
Эффективности работе с ожиданиями заинтересованных
сторон добавляет совместная честная и открытая работа с
возможными проблемами и рисками проекта. Да, здесь ме-
неджеру нужно иметь определенную смелость, чтобы не пы-
таться скрыть проблему от заинтересованных сторон. По-
верьте нашему опыту: открытая и прозрачная работа творит
чудеса. Приведем пример.
 Представьте, что утром вы оставляете машину на станции
для ремонта подвески. Механик вам говорит, что машину
можно будет забрать в 13:00. В 14:00 у вас важная встреча
на другом конце города. По вашим подсчетам, времени как
раз хватит, чтобы забрать машину и приехать на встречу во-
время. В 13:00 вы приезжаете на станцию, а машина разо-
брана. Выясняется, что болты подвески прикипели и их не
смогли открутить. Пришлось их срезать и высверлить. И еще
поехать на авторынок, чтобы купить новые болты. В итоге
машина будет готова только к 17:00, а работа будет стоить
в 1,5 раза дороже. Вы и так расстроились, а тут еще нужно
срочно вызывать такси, чтобы попасть на встречу. Как назло,
все службы заняты, а машина может приехать только через
15 минут. Вы понимаете, что опаздываете на встречу, вол-
нуетесь и ругаете механика.
А вот второй вариант.
Утром вы оставляете машину на станции для ремонта под-
вески. Механик предупреждает о вероятности того, что бол-
ты могут не выкрутиться и тогда придется их срезать и вы-
сверливать. Если все пойдет хорошо, то машину можно бу-
дет забрать в 13:00, а если придется срезать и сверлить, то
в 17:00 и работа будет стоить в 1,5 раза дороже. Механик
обещает вам позвонить в 11:00 и сообщить о том, по како-
му сценарию начала развиваться ситуация. И действительно,
в 11 часов вам звонят и говорят, что пришлось резать. Но
в этот раз вы абсолютно спокойны, так как у вас есть уйма
времени, чтобы заказать такси и отправиться на встречу. У
всех все хорошо: вы попали на встречу и даже не думаете
ругать механика.
Какой вариант вам нравится больше? Нам – второй. Вот и
ключевым заинтересованным сторонам всегда полезно быть
в курсе потенциальных или актуальных проблем и рисков
проекта. Беспокоящие вопросы необходимо выявлять и об-
суждать как можно раньше, чтобы лучше оценить связанные
с ними риски.
 Как добиться доверия заказчика
Установить доверие между заказчиком и исполнителем,
в том числе в вопросах внесения изменений, – крайне важ-
ная составляющая успеха проекта. На этот счет есть любо-
пытная история. Как-то во время встречи с заказчиком пред-
ставитель исполнителя предложил новую идею – пилотный
проект. И вот менеджер исполнителя решил пошутить на ан-
глийском языке (который не был его родным). Он сказал:
«We are not going to charge you for this… directly» («Мы не
будем выставлять вам счет за эти работы… напрямую»). За-
казчики не поняли юмора, но начали задавать неприятные
вопросы: мол, вы собираетесь маскировать какие-то работы
под работы текущего проекта, чтобы опробовать свою идею?
Безусловно, доверие между сторонами было утрачено.
Как правило, новый проект с новым заказчиком всегда на-
чинается в точке «мы друг о друге ничего не знаем». Соот-
ветственно, невысок и уровень доверия – его нужно повы-
шать. Как это сделать? Просить поверить на слово – это пло-
хой вариант. Доверие появляется тогда, когда мы постоян-
но общаемся с клиентом и рассказываем ему о том, что про-
исходит с проектом, как он продвигается, чего удалось до-
стичь. Идеальная точка – он говорит: «Хорошо, я вам верю,
делайте то, что нужно делать». Такая ситуация развязывает
менеджеру руки, он может работать, не особенно обращая
внимание на оформление документации.
И вот здесь появляется новый риск: бывает, что менеджер
со стороны заказчика, с которым установилось доверие, ухо-
дит из компании. На его место приходит другой человек, ко-
торый не понимает, что происходит, что вы вообще делаете,
тем более если работы не указаны в ИСР. В таком случае у
вас возникнут проблемы: отношения приходится начинать
строить не просто с нуля, а с большого недоверия.
Чтобы избежать такой ситуации, документацию все-таки
нужно вести надлежащим образом, независимо от уровня
доверия. Причем так, чтобы в ней была подпись ответствен-
ного лица со стороны заказчика. Тогда и вопросов со сторо-
ны нового менеджера будет меньше.
 Выводы
Управление заинтересованными сторонами – это созда-
ние и поддержание хороших отношений между ними и ко-
мандой проекта с целью удовлетворения их потребностей и
требований в рамках проекта.
Управление ожиданиями заинтересованных сторон помо-
гает увеличить вероятность успеха проекта, обеспечивая по-
нимание ими преимуществ и рисков, связанных с проектом.
По мере развития проекта состав заинтересованных сто-
рон и необходимый уровень их вовлечения могут меняться,
поэтому необходимо регулярно определять, анализировать
заинтересованные стороны и планировать управление ими.
Беспокоящие вопросы необходимо выявлять и обсуждать
как можно раньше для оценки связанных с ними рисков про-
екта.
 Глава 22
Завершение проекта
Процессы завершения – это важная часть проекта. Необ-
ходимо планировать как завершение всего проекта целиком,
так и отдельных его фаз.
 Процесс завершения
проекта или его фазы
Завершение проекта или фазы – это окончание всех опе-
раций и групп процессов управления проектом для их фор-
мального завершения. В рамках этого процесса мы должны
удостовериться, что все работы завершены и проект достиг
своих целей.
Необходимо проработать процедуры сдачи результатов
проекта или итогового продукта:
● что будет считаться готовым результатом или продук-
том;
● в какие сроки все будет закончено;
● какими будут критерии приемки.
Сдавать заказчику необходимо не только проект целиком,
но и каждую его итерацию. Это нужно, чтобы он понимал,
какой продукт получается, куда движется работа и нужно ли
вносить коррективы. Чем чаще команда проекта будет де-
монстрировать заказчику то, что получается, тем выше ве-
роятность своевременной сдачи проекта, так как не придет-
ся вносить в него изменения на поздних стадиях.
Процессы завершения планируются на старте проекта и
должны быть учтены в бюджете и расписании.
 Операции по завершению проекта
Вот список типовых операций, которые обычно произво-
дятся при закрытии проекта или его фазы. Вы можете ис-
пользовать его как чек-лист при планировании завершения
проекта (этапа).
● Разработать план передачи результатов проекта.
● Провести административное завершение:
● сбор всей информации о проекте;
● документирование данных о ходе проекта (метрик) и
финальных версий планов.
● Оценить проект после его завершения.
● Завершить работу с клиентом/спонсором:
● информирование клиента о завершении проекта;
● сдача (презентация) результатов работы;
● формальная приемка клиентом/спонсором результатов;
● проведение собрания по завершению проекта;
● передача ответственности за результаты проекта кли-
енту; вместе с готовым продуктом передаются и все рабочие
материалы по нему.
● Закрыть контракты.
● Подписать акты и документы по завершению.
● Разместить накопленные знания в активах организа-
ции. На этом этапе менеджер документирует все, что проис-
ходило по ходу проекта, все плюсы и минусы, а также выне-
сенные уроки. Когда-нибудь эта информация может потре-
боваться вновь.
● Передать важные документы по проекту в архив.
 Оценка проекта
после его завершения
Оценка, или ретроспектива, проекта необходима, что-
бы выявить ошибки, которые мы допустили в ходе рабо-
ты, определить их влияние на проект и найти способы, как
предотвратить подобные ошибки в будущем. Также можно
выявить действия и практики, которые привели к отличным
результатам, и использовать их в последующих проектах.
Ретроспективу проекта следует проводить спустя неко-
торое время после завершения. Временной период должен
быть достаточно продолжительным, чтобы можно было убе-
диться в том, что проект действительно завершился успеш-
но, дать ему время поработать в «боевых» условиях. Не ис-
ключено, что проблемы могут возникнуть через месяц после
сдачи продукта в эксплуатацию, поэтому следует подождать.
В то же время не нужно слишком затягивать, чтобы заинте-
ресованные стороны не начали забывать детали проекта.
Для проведения ретроспективы проекта необходимо:
● определить начальные и конечные цели, связанные с ка-
чеством выполнения проекта (конечного продукта), стоимо-
стью и календарным планом;
● понять, достигнуты ли цели;
● выявить факторы успеха в тех областях, где все шло хо-
рошо, и найти причины проблем в тех областях, где возни-
кали трудности;
● разработать политику и процедуру внесения изменений
в стандарты по управлению проектами компании для устра-
нения проблем, из-за которых цели не были достигнуты;
● согласовать изменения с руководством и внести их в
стандарты.
 Семинары по завершению проекта
После окончания проекта менеджеру следует провести
два собрания: одно для команды проекта, другое для заказ-
чика. Делается это для достижения следующих целей:
● обзор всего проекта;
● подтверждение того, что результаты были получены;
● информирование руководства компании об окончании
проекта;
● признание личного вклада каждого члена команды в
проект;
● сообщение об успехе проекта: написать новость в СМИ
или на сайт компании, рассказать сотрудникам в корпора-
тивной рассылке или на внутреннем портале;
● официальное оформление завершения проекта;
● подтверждение того, что полученный опыт и накоплен-
ные знания вошли в систему стандартов компании.
Подобные семинары – важное событие для всех, кто
участвовал в проекте. Это точка, которая говорит об оконча-
нии, а людям важно получить ощущение логической завер-
шенности работы. Каждый может получить признание сво-
их заслуг. Членам команды будет приятно, если им окажут
внимание таким образом.
Во время проведения подобного семинара на стороне за-
казчика очень важно похвалить людей из его команды, ко-
торые внесли большой вклад в успех проекта. Людям будет
очень приятно, что вы похвалили их при руководителях, и
они будут рады сотрудничать с вами на следующих проектах.
 Накопленные знания
и выученные уроки
В процессе выполнения проекта накапливаются знания.
Их можно идентифицировать на любой стадии проекта. Вот
как с ними следует работать:
● определите и утвердите ответственного за управление
полученным опытом;
● создайте или позаимствуйте методику процесса управ-
ления полученными знаниями;
● позаботьтесь, чтобы данная методика использовалась в
вашей организации;
● управляйте преобразованием опыта, полученного в хо-
де работы над проектами, в общие знания организации.
Извлекать уроки можно не только после окончания про-
екта, но и в процессе его выполнения. Например, если ме-
неджер заметил, что расписание составлено неправильно, то
это наблюдение он может зафиксировать сразу же, чтобы не
допускать подобных ситуаций в будущем. Делать записи луч-
ше в то время, когда впечатления еще свежи. В конце про-
екта их можно будет консолидировать в единый документ.
 Обязанности менеджера проекта
При завершении проекта менеджер обязан сделать следу-
ющее:
● оценить условия соглашений и исполнить все обяза-
тельства;
● освободить технические средства и оборудование;
● подготовить отзывы о работе участников проекта для
их функциональных менеджеров;
● позаботиться о перераспределении членов команды;
● получить отзыв от спонсора проекта;
● завершить соглашение со спонсором;
● оценить накопленные данные;
● передать накопленный интеллектуальный капитал.
 Оценка личных успехов
менеджера проекта
Позаботившись об оценке успешности проекта для всех
заинтересованных сторон, менеджер должен сделать выво-
ды из проекта и для себя. Оценка своих действий по итогам
проекта – хороший стимул для дальнейшего развития. Она
помогает лучше понять возможные направления улучшения
собственных навыков и инструментов. Для оценки можно
использовать следующий подход.
ШАГ 1. Определите список областей для развития.
За основу можно взять список из семи областей, представ-
ленный ниже.
● Методологии, фреймворки и подходы к разработке ПО.
Очень важно, чтобы руководитель осознанно принимал ре-
шение о подходе, в соответствии с которым будет выполнять-
ся разработка. Чем богаче его знания о существующих ме-
тодологиях, их слабых и сильных сторонах, тем больше у
него пространства для маневра. На наш взгляд, минималь-
ным необходимым набором являются: PMI PMBOK, Kanban
и Scrum. Для расширения кругозора и саморазвития пред-
лагаем изучить Lean, SAFe, ITIL или COBIT.
● Инструменты для ведения проекта. Часто определен-
ный набор инструментов – стандарт для компании, так что
руководитель проекта должен уверенно пользоваться всем
имеющимся инструментарием. Если в организации еще нет
такого стандарта, то будет нелишним его ввести, чтобы мене-
джерам проектов было проще пользоваться историческими
данными своих коллег. К нужным инструментам можно от-
нести MS Project, JIRA, Asana, RTC, Redmine, Project Libre,
Merlin Project, Trello, Targetprocess.
● Бизнес-домен. Крайне тяжело понять бизнес-цели про-
екта и обеспечить их выполнение без понимания нюансов
бизнес-домена.
● Технологический стек команды. Этот пункт – камень
преткновения между двумя группами руководителей проек-
тов. Одни уверены, что у менеджера должен быть приклад-
ной опыт использования технологического стека, а вторые
утверждают, что технические навыки скорее вредят, чем по-
могают.
С нашей точки зрения, технические знания и понимание
того, как все работает, необходимы: без них будет тяжело го-
ворить с командой на одном языке. Выросший из производ-
ства руководитель, который когда-то своими руками делал
такую работу, имеет больше шансов привести проект к успе-
ху.
Глубокое погружение в технологии – личное дело руково-
дителя. Правда, он не должен забывать, что даже самые фун-
даментальные знания не делают его архитектором проекта и
не дают права навязывать команде свои варианты реализа-
ции задач проекта.
 ● Навыки и инструменты работы с командой. Данная об-
ласть знаний подробно рассмотрена в главе 15 «Команда
проекта и работа с людьми».
● Навыки работы с заинтересованными сторонами. Для
оценки этой области можно изучить главы 20 и 23.
● Навыки публичных выступлений. Руководитель проек-
та должен уметь доносить информацию до заинтересован-
ных сторон. Зачастую для этого нужно овладеть навыками
ораторского мастерства и создания презентаций.
ШАГ 2. Оцените важность каждой из них. Самым
простым способом определения важности является способ
попарного сравнения.
● Берем область 1 и 2 и спрашиваем себя: «Что важнее?»
● Если область 1 оказывается менее важной, чем 2, ме-
няем их местами.
● Далее спрашиваем: «Какая область важнее: 1 или 3?»
Если необходимо, снова меняем варианты местами.
● Продолжать попарные сравнения нужно до тех пор, по-
ка весь список не будет пройден без перестановок.
ШАГ 3. Оцените ваш текущий уровень. Для оценки
можно использовать следующие вопросы:
● Соответствует ли мой уровень знаний в данной области
желаемому?
● Были ли во время выполнения проекта случаи, когда
недостаток знаний привел к негативным последствиям – на-
пример, к потере времени, неверному решению, неправиль-
ному пониманию текущей ситуации одной либо нескольки-
ми заинтересованными сторонами и т. д.?
● Есть ли что-то в данной области, чего я не знаю и чему
хочу научиться?
ШАГ 4. Обозначьте желаемый уровень. Для каждой
области знаний проставьте желаемый уровень. В идеале он
должен быть выше текущего, но достижимым, если прило-
жить усилия. Решите, что именно укажет вам на то, что цель
достигнута.
ШАГ 5. Выработайте план действий по улучшению. Для
каждого пункта продумайте следующий шаг, который необ-
ходимо сделать, чтобы достичь поставленной цели.
ШАГ 6. Приоритизируйте шаги. Главное – не браться за
все сразу. Фокус на одном конкретном улучшении позволит
стать лучше уже завтра. Поэтому выбирайте самую важную
область и приступайте к реализации следующего шага. По-
сле того как закончите с задачей по наиболее приоритетной
области, переходите к следующей.
Очень важно письменно фиксировать оценку вместе с ре-
шением о действиях. Это помогает в дальнейшем развитии:
при помощи таких записей менеджеру будет легче оценить
свой прогресс за год или несколько лет.
Теперь можно приступать к новому проекту.
 Глава 23
Карьера: учеба на MBA
Время летело вперед, все шло замечательно: программа
проектов моего отделения развивалась хорошо, насколько
это было возможно. И я заскучал.
У меня была голубая мечта: пройти обучение по програм-
ме Master of Business Administration (МВА). И если в 25 лет
МВА хочется получить потому, что это престижно, то в 30
меня уже накрыл кризис среднего возраста. Стало страшно,
что если сейчас не начать делать все по-другому, то дальше
жизнь будет идти по накатанной. К тому же я почувствовал,
что застрял и нужно двигаться вперед быстрее.
Так как я все время работал по найму, то многие решения
бизнеса оставались загадкой. Мне хотелось познакомиться с
предпринимателями и понять, как они принимают решения,
как они думают. И на фоне кризиса вдруг пришло осознание
того, что многие в этой жизни достигли гораздо большего,
чем я.
Чтобы это осознать, можно проделать простое упражне-
ние. Посмотрите на главный проспект своего города и со-
считайте, сколько автомобилей стоимостью больше $100 000
проедет мимо вас за пять минут. Результат вдохновляет на
действия.
 Итак, я решился. Выбор пал на минскую бизнес-школу
ИПМ. Основной критерий был простым: там можно встре-
тить достаточное количество собственников бизнеса. Вари-
ант учиться за границей не рассматривал, так как не было
времени, да и стоимость обучения в европейских школах
значительно выше.
Следующий этап – попытаться убедить руководство в том,
что такое обучение мне необходимо. Переговоры с руковод-
ством были долгими, но прошли успешно. Меня отпустили
учиться и частично оплатили обучение. Я сдал вступитель-
ный экзамен – и вот я уже в группе EMBA 27 знакомлюсь со
своими одногруппниками.
Главное преимущество программы MBA состоит в том,
что ты попадаешь в группу очень сильных и умных людей. И
это очень крутое чувство! Я привык быть одним из лучших
в университете, в кабинете на работе, в компании в целом,
а тут на́ тебе: куча людей вокруг, и все объективно лучше
тебя – и это здорово! Это заводит: начинаешь видеть высо-
кую планку, к которой стоит стремиться, и людей, на кото-
рых нужно равняться.
Кроме того, в моей группе было несколько руководителей
государственных компаний. Сначала я их недооценивал, но в
ходе учебы в корне пересмотрел отношение к государствен-
ным управленцам. Они не просто молодцы, а зачастую го-
раздо талантливее людей, которых можно встретить в част-
ных компаниях.
 Задачи руководителей в госсекторе намного сложнее, чем
в частных компаниях: нужно не просто строить работу, но
и менять культуру и мировоззрение людей (когда это требу-
ется), проработавших на их предприятиях десятилетиями и
привыкших к устоявшимся порядкам. Для таких изменений
нужно быть не просто руководителем, а сильнейшим лиде-
ром и образцом для подражания, лидером, который может
убеждать и вести за собой людей.
Почти на два года получение MBA стало для меня серьез-
ной жизненной целью. Я очень хотел получить это образо-
вание, дотянуться до высочайшего уровня людей в группе и
продемонстрировать высокие результаты в обучении. Меч-
тал стать таким, как они: смелым, решительным, умным и
продуктивным. Понимание того, что ты движешься вперед,
добавляет много положительных эмоций и, как ни странно,
отлично поддерживает в трудную минуту.
 Что дала мне программа МВА
Как таковых новых знаний за время учебы я получил не
очень много. Да, были полностью незнакомые курсы: основы
права, финансы, маркетинг. Все остальное я уже так или ина-
че изучал в рамках проектного менеджмента. Самое важное,
что дает MBA, – шанс взглянуть на известные тебе вещи с
более зрелой позиции, пересмотреть свои знания, заметить
что-то, что ты упустил или ранее считал несущественным.
МВА помогает все структурировать и составить целостную
картину.
По-моему, самое ценное в МВА – это то, что програм-
ма переворачивает мир с ног на голову и существенно меня-
ет взгляды на многие вещи. Там ты встречаешь предприни-
мателей. Я всю жизнь работал по найму и не понимал, что
ими движет. Теперь понимаю, и это существенно упрощает
жизнь, да и мою работу.
Собственники – это люди с другой планеты. Нет, они не
небожители – это такие же люди, как и мы, но более целе-
устремленные, продуктивные, умеющие четко расставлять
приоритеты в работе и жизни. Я заметил, что предпринима-
тели всегда открыты новым возможностям и фанатично лю-
бят свои бизнесы. Это люди, которые меняют мир к лучшему
и много работают над этим.
После программы МВА вы начинаете больше занимать-
ся тем, что любите, потому что только это вы можете делать
лучше других. И, как следствие, вы начинаете тратить мень-
ше ресурсов на ненужную деятельность. Начинаете по-дру-
гому относиться к своему времени, людям вокруг и работе.
У MBA есть еще один очень приятный момент. Когда тебе
за 30, заводить новых друзей достаточно сложно, а я за два
года обучения обрел среди своих одногруппников несколько
замечательных друзей.
В сухом остатке: мне очень понравилось учиться. MBA
действительно стоит своих денег и времени. Идти учиться
нужно обязательно, если вы ищете в жизни новый импульс,
мотивацию, знакомства и ориентиры. В целом реальность
полностью соответствовала моим ожиданиям: смена обста-
новки и сильные люди, задающие новую планку в работе и
жизни.
Тем, кто соберется учиться по программе МВА, я хочу
сказать, что это не будет легкой и веселой прогулкой. Более
того, это сложно физически, так как учеба отнимает мно-
го времени. Скорее всего, на время обучения вам придется
полностью перестроить свою жизнь и изменить приоритеты.
Алексей Минкевич
 Глава 24
Как бизнес выбирает проекты
Руководителю проекта важно понимать, какой цели биз-
неса служит проект. Во второй главе мы уже рассматривали,
для чего бизнес может делать проекты. Давайте вспомним.
● Коммерческая необходимость. Запуск нового продукта
или услуги с целью получения прибыли является одной из
основных причин появления проектов.
● Потребности рынка. Например, конкуренты уже раз-
вернули удачное решение. Такая ситуация может возникнуть
даже в успешно функционирующей компании.
● Запросы пользователей. Как же без них. Для создания
успешных продуктов очень важно слушать пользователей и
реализовывать их запросы.
● Требования закона. Законодательство может меняться,
а ему нужно соответствовать всегда.
● Технический прогресс и внедрение новых технологий.
● Социальная необходимость. Если бизнес успешен, то
можно подумать над тем, как принести пользу человечеству:
благоустроить и сделать мир вокруг себя лучше.
● Обновление бизнес-процессов, инфраструктуры. Внут-
ренние проекты, направленные на оптимизацию работы
компании.
 ● Воплощение мечты в жизнь. Например, проект по со-
зданию собственной команды по автоспорту или организа-
ция кругосветного путешествия.
Руководитель проекта должен понимать цель, стоящую
перед бизнесом. Это поможет верно расставить приоритеты
в работе. А еще нужно понимать, что цели бизнеса могут
быть очень изменчивыми. Идеи конкурируют между собой:
даже если проект был самым важным и приоритетным вче-
ра, это не значит, что он будет таким же сегодня.
Периодически возникают ситуации, когда вы работаете
над важным проектом, у вас есть команда, которая отлично
справляется, но вдруг приходит начальник и переводит по-
ловину людей в новый проект. Это говорит о том, что в ком-
пании появился новый, более приоритетный проект. И это
нормально.
Давайте подробнее разберемся с тем, как бизнес расстав-
ляет приоритеты при работе с проектами.
 Стратегические планы компании
Собственник компании или совет директоров оценивают
перспективные ниши рынка и принимают решение о страте-
гическом плане развития компании. В зависимости от при-
нятых решений компания может инвестировать в новые на-
правления, развивать и усиливать текущую экспертизу или
перераспределять ресурсы компании в пользу других на-
правлений развития.
Например, закрыть стабильно работающее направление,
использующее устаревшую технологию, и развить новое пер-
спективное направление. В этом случае компания будет ин-
вестировать в обучение сотрудников новым технологиям и
пробовать развивать новую экспертизу на практике.
Далее начинается аналитическая работа.
 Модели количественной оценки
Модели количественной оценки приходят на помощь, ко-
гда для достижения стратегических целей компании нужно
выбрать один из нескольких возможных проектов. Иными
словами, методы количественной оценки помогают приори-
тизировать ряд проектов.
Например, менеджер готовит описание нескольких про-
ектов и раздает его членам совета директоров. У руководи-
теля есть заранее подготовленные критерии оценки с веса-
ми, и все, что остается, – это проставить баллы. Чем больше
проект соответствует критерию, тем выше балл. Далее баллы
перемножаются на веса, оценки складываются, и получается
итоговый результат. Табличка может выглядеть следующим
образом (табл. 4).
Наивысший приоритет получает тот проект, который на-
бирает больше всего баллов. Очень похожий анализ ис-
пользуют продуктовые компании для оценки «фичей» –
нового функционала в продуктах. Например, WSJF-ана-
лиз (Weighted Shortest Job First), в котором ценность ново-
го функционала еще делится на трудоемкость разработки.
Таким образом учитывается количество ресурсов, которые
нужно потратить на достижение цели.
 Анализ рисков и их последствий
Существуют проекты, реализация которых может нести в
себе существенные риски для компании. Например, если у
нее недостаточно экспертизы, чтобы выполнить проект, нуж-
но будет искать специалистов на рынке. Вероятность того,
что проект не будет выполнен, высока, особенно если в кон-
тракте на случай его невыполнения прописаны такие штраф-
ные санкции, которые обанкротят компанию. Скорее всего,
браться за такой проект не стоит.
 Анализ ограничений
У любой компании есть ограничения по экспертизе и ре-
сурсам. Если проект выходит за рамки таких ограничений,
то, возможно, и не стоит за него браться. Например, идет
тендер на крупный проект, который требует большую коман-
ду разработки из 70 человек на два года. Если в моей компа-
нии только десять разработчиков, то такой проект мне еще
не по силам.
 Экономические модели
Допустим, у вас есть несколько проектов и нужно решить,
за какой из них браться. При помощи моделей можно рас-
считать экономическое обоснование проектов и выбрать тот,
который принесет большую выгоду компании. Давайте для
примера рассмотрим наиболее часто используемые модели.
1. Период окупаемости (Payback Period, PP). Допустим,
у меня в гараже стоит станок, который делает пробки для
шампанского. Себестоимость каждой из них – $2. В какой-то
момент я начинаю сомневаться в эффективности своего про-
изводства и хочу ее повысить.
 Я узнаю, что на рынке есть станок стоимостью $200 000.
Количество отходов при производстве у него меньше, и себе-
стоимость пробки, произведенной на нем, составит $1,5. По-
считав период окупаемости станка, я вычислил, что он оку-
пится через 16 месяцев. В приобретении такого оборудова-
ния есть смысл, так как уже через 16 месяцев я начну по-
лучать чистую прибыль (рис. 60). Точно так же и при выбо-
ре проектов: приоритет отдается тому, который быстрее оку-
пится.
2. Прибыль на инвестиции (Return on Investments,
ROI). В этом случае мы рассчитываем, насколько выгодно
нам вкладывать деньги в новый проект. Считать необходимо
по формуле:

Например, мы хотим заказать разработку продукта сто-

имостью $1,25 млн, а затем продать его за $1,5 млн. Как
узнать, какую прибыль мы получим от инвестиции в этот
проект? Подставляем данные в формулу:

Получаем коэффициент 0,2, то есть наша прибыль соста-

вит 20 %.
Для работы с этой формулой важно знать следующее: ес-
ли итоговый коэффициент больше нуля, то проект прибыль-
ный, если меньше – убыточный; 0 – компания в плане денег
ничего не теряет, но и не зарабатывает. Если говорить о вре-
мени, то здесь ситуация двоякая: время может быть потра-
чено зря, а может быть получен хороший опыт.
3. Чистая приведенная стоимость (Net Present Value,
NPV). В этой модели мы учитываем прибыльность того или
иного проекта с учетом влияния инфляции. При помощи
формулы денежного потока можно рассчитать, сколько при-
несет проект в пересчете на его сегодняшнюю стоимость,
ведь ценность 100-долларовой банкноты каждый год падает.
Простой пример: допустим, годовая инфляция составля-
ет 10 %, а проект через год принесет $100. Какой будет цен-
ность этой сотни для компании? $91. Почему? Именно такой
будет покупательная способность сегодняшней сотни долла-
ров через год. Расчет приведенной стоимости производится
по формуле:

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

проект принесет $100 через два года, то при годовой инфля-
ции в 10 % эта прибыль будет равняться нынешним $83. И
если сейчас положить на депозит $83 под 10 % годовых (или
инвестировать их в любой другой инструмент с такой же до-
ходностью), то через год на счету компании будет $91, а че-
рез два – вся сотня.
Как это знание помогает бизнесу в оценке проектов? Рас-
смотрим проект (табл. 5).
 Допустим, компании нужно в ближайшие два года инве-
стировать в реализацию проекта $300 000. Ожидаемая при-
быль должна составлять $450 000. На первый взгляд, про-
ект хороший! А теперь давайте посчитаем с учетом инфля-
ции. Для простоты расчета допустим, что годовой уровень
инфляции составляет 10 %.
Итак, в первый год нам нужно инвестировать $200 000.
Кроме этого, еще $91 000 нам нужно положить на депозит,
чтобы через год, когда подойдет время вкладывать деньги в
следующую фазу проекта, их стало $100 000. Таким обра-
зом, приведенные затраты проекта составят $200 000 + $91
000 = $291 000.
То же самое делаем с прибылью. В первый год проект при-
нес $0. Во второй – $50 000, которые из-за инфляции пре-
вратились в $45 000.
Считаем: $100 000 на второй год – это $83 000 в сего-
дняшних ценах. Наша ожидаемая прибыль через три года –
$300 000, что в фактических сегодняшних ценах составля-
ет всего $225 000. Итоговая приведенная прибыль – это $45
000 + $83 000 + $225 000 = $353 000.
Фактически прибыль от реализации проекта составит не
запланированные $150 000, а всего $62 000. Остальное «съе-
ла» инфляция. Это очень хороший метод расчета для долго-
срочных проектов, который часто используется бизнесом.
Кстати, из этого пункта можно сделать интересный вывод:
если знакомый просит у вас в долг $10 000 на три года, то
дать их ему без процентов – это преступление. Давать деньги
в долг без процентов можно только близким друзьям, четко
осознавая, что тем самым вы оказываете им непосредствен-
ную финансовую помощь.
 Выводы
Решение о начале или остановке проекта принимается
бизнесом исходя из стратегии собственного развития, при
этом оно должно подтверждаться расчетами. Цифры всегда
говорят больше и помогают принимать более взвешенные
решения.
Если у вас в голове созрела идея замечательного проекта,
не поленитесь и приготовьте для нее бизнес-план (шаблон
легко найти в интернете). В бизнес-плане детально опишите
идею и дайте ответ на вопрос о том, как проект укладывает-
ся в стратегию компании. И обязательно приведите расчет
экономических показателей проекта. Поскольку идея ваша,
она будет вами очень любима.
Оценка идеи с точки зрения цифр поможет вам взглянуть
на нее с перспективы бизнеса. И возможно, это будет совсем
не та оценка, которую вы ожидаете увидеть. Но только по-
сле этого можно идти к руководству с просьбой рассмотреть
проект.
 Глава 25
Карьера: школа управления
проектами, запуск Juno
и совместная работа
Во время учебы по программе MBA получаешь очень
сильную мотивацию попробовать сделать что-то свое. При
подготовке к сдаче экзамена PMP студенты задают похожие
вопросы и часто делают одинаковые ошибки. Поэтому идея
создания нового продукта лежала на поверхности: разрабо-
тать симулятор экзамена PMP на русском языке с наиболее
сложными для понимания вопросами. К каждому вопросу
шло пояснение, почему именно такой ответ является вер-
ным.
Если работать над таким продуктом самостоятельно, то на
разработку уйдет несколько лет. Я попросил о помощи кол-
лег, которых подготовил к сдаче PMP. Отозвалось много лю-
дей, но один из них не просто помог, а стал соавтором симу-
лятора – это был Сергей Дерцап. Вопросы Сергея не нужда-
лись в правках, были сильными и с юмором. Я получал удо-
вольствие от чтения его вопросов. Вот так, работая над про-
дуктом, мы и подружились.
Изначально наш продукт задумывался как коммерческий,
но в процессе работы мы решили сделать его бесплатным.
Для симулятора экзамена нужно было разработать сайт, и
как раз в процессе работы над контентом родилась идея и
миссия Школы управления проектами:
«Искренне делиться своими знаниями и навыками. Разви-
вать, воодушевлять и вдохновлять руководителей проектов.
Повышать профессионализм менеджеров проектов и попу-
ляризировать профессию в Республике Беларусь и за ее пре-
делами».
С такой миссией все вопросы о том, делать ли симулятор
платным, отпали сами собой.
Запуск сайта и симулятора экзамена вдохновил нас: люди
начали пользоваться продуктом, время от времени приходи-
ли письма с благодарностью за помощь в подготовке к экза-
мену. За пять лет симулятором уже воспользовались более
19 000 человек.
Впоследствии мы с Сергеем начали читать курс по управ-
лению проектами вдвоем. Наш практический опыт здорово
дополняет друг друга.
Школа управления проектами – это хорошее и приятное
хобби. Оно дает возможность делиться знаниями и опытом
с людьми и быть полезными.
А что же работа?
 Juno
На MBA хорошо объясняют, что главный ресурс – это
время. Окончив программу, мне захотелось поучаствовать в
чем-то большем и новом, поменять привычный жизненный
уклад и немного изменить мир к лучшему. Ведь время идет.
Жизнь устроена таким образом, что если ты чего-то дей-
ствительно хочешь, то это происходит. В марте 2015 г. я по-
знакомился с основателями Viber Игорем Магазиником и
Тальмоном Марко. У них был положительный опыт постро-
ения центров разработки в Беларуси, поэтому центр разра-
ботки для своего нового продукта Игорь и Тальмон решили
открывать в Минске.
Новым проектом стал такси-сервис Juno – прямой конку-
рент Uber, но с другим подходом. Тальмон и Игорь изучали
рынок такси США и увидели интересную возможность: ли-
дер рынка строил свой сервис вокруг пассажиров, а водите-
ли уходили на второй план. Это проявлялось во всем: в от-
ношении к водителям, высоком проценте, который забирали
себе сервисы, плохой службе поддержки и прочем. Как в та-
ком случае может водитель, которому не нравится его рабо-
та, оказывать качественные услуги пассажирам? Никак.
Идея была в том, чтобы создать социально ответственный
сервис, который будет хорошим для водителей и изменит
сложившуюся ситуацию, когда о водителях почти не думают.
 Буквально с первых минут общения у меня сложилось
полное взаимопонимание с Игорем, и вскоре он предложил
мне возглавить разработку продукта в Минске.
Это был крутой вызов. С одной стороны, было страшно
что-то менять и я был очень предан и благодарен компании,
в которой вырос. С другой – стать частью чего-то настолько
масштабного, поучаствовать в чем-то, что меняет мир, было
очень интересно. Я решил: вперед!
Восемнадцатого мая 2015 г. мы открыли новый офис с
первой командой из 12 человек. Второго декабря мы нача-
ли набирать водителей и через несколько месяцев открыли
бета-тестирование сервиса для наших друзей и знакомых в
Нью-Йорке.
Нью-Йорк выбрали первым городом по двум причинам.
Во-первых, это один из крупнейших рынков такси в мире.
Во-вторых, в Нью-Йорке много небоскребов, что существен-
но усложняет геопозиционирование при помощи GPS. Как
говорится, если ты сделал это в Нью-Йорке, то сможешь сде-
лать везде.
Нужно сказать, что Juno – это стартап, а в стартапе руково-
дитель делает все. Сначала я помогал командам мобильной
разработки, потом переключился на серверную часть. А ко-
гда пошли полноценные коммерческие поездки, то посыпал-
ся шквал разнообразных отзывов, выявилось много дефек-
тов и проблем. Поначалу я справлялся со всем сам, но скоро
стало понятно, что для этой работы нужна целая команда.
Нужен был руководитель, который построил бы службу тех-
нической поддержки и наладил все процессы с нуля. И тут я
подумал, что Сергей – идеальный кандидат. Его опыт рабо-
ты и светлая голова прекрасно подходили для этой сложной
задачи.
В Juno мы никого не берем по блату. Поэтому Сергею при-
шлось пройти все собеседования, прежде чем он получил job
offer.
 Глазами Сергея
Когда Алексей предложил рассмотреть вакансию в Juno,
я уже задумывался о том, что пришло время двигаться даль-
ше, так как я не совсем понимал, куда расти в гомельском
отделении IBA. Я был начальником отдела, руководил меж-
дународным проектом, а попутно отвечал за проекты по со-
провождению внутренних систем компании и за систему ме-
неджмента качества. Я оказался в довольно комфортной зо-
не. Очень скоро пришло осознание того, что нужно искать
новые вызовы. И предложение попробовать свои силы в Juno
оказалось очень кстати.
С первого дня в Juno меня радовал (и одновременно сму-
щал) один момент: никто не ставил целей и задач, никто не
требовал отчетности. В IBA я привык защищать свои пред-
ложения и точку зрения, но тут вдруг выяснилось, что когда
нет арбитра и тебе дают полный карт-бланш, то становишь-
ся очень и очень строг к себе, начинаешь критически отно-
ситься к любой мелочи. Как говорил дядя Питера Паркера
(Человека-паука): «C большой силой приходит большая от-
ветственность».
Алексей и Игорь всегда говорили о важности службы под-
держки для развития продукта, уверяли в полном доверии ко
мне во всем, что касается развития ее технической составля-
ющей. И это доверие стимулировало делать все правильно,
чтобы моей команде нравилась работа и люди шли в офис с
удовольствием.
Мне не хотелось набирать команду до тех пор, пока сам
не разберусь в том, с чем ей предстоит столкнуться. Поэтому
моя работа в Juno началась с того, что в первое время я делал
все самостоятельно, позже поехал в Израиль знакомиться с
нашей командой клиентской поддержки. Только после пол-
ной синхронизации с израильскими коллегами мы открыли
набор в команду техподдержки.
В первые несколько месяцев мы буквально ночевали на
работе, так как серьезные перемены случались каждый день.
Это был хотя и сложный, но очень полезный период. Вскоре
у нас появилась команда, которая смогла обеспечивать тех-
поддержку 14 часов в сутки семь дней в неделю.
Отдел развивался очень быстро. Уже через полгода ребя-
та самостоятельно принимали решения о том, какие процес-
сы требуют изменений, понимали, как можно сделать рабо-
ту эффективнее. Со временем я стал замечать, что мои под-
чиненные хотят и дальше развиваться так же динамично, но
отдел техподдержки уже не мог обеспечить им эту возмож-
ность. И здесь на помощь пришли руководители других ко-
манд, которые согласились принять к себе тех, кто уже пере-
рос службу поддержки. А мы снова открыли набор.
К третьему «поколению» команды поддержки я вдруг осо-
знал, что времени на работу со своими людьми у меня оста-
ется все меньше и меньше. Теперь оно уходило на решение
задач по оперированию нашего сервиса, требовалось больше
межкомандного и межофисного взаимодействия. Внезапно
я оказался «бутылочным горлышком», начал тормозить ре-
бят. К счастью, в команде к тому времени уже вырос чело-
век, который очень легко подхватил мои инициативы. Тех-
поддержку возглавила Светлана Шахова, которая зарядила
команду энергией, вдохнула в нее новую жизнь. Я же начал
искать себе новые вызовы, одним из которых стала роль опе-
рационного руководителя нашего центра разработки.
 Глазами Алексея
В итоге Сергей не просто выстроил рабочие процессы в
службе технической поддержки, но и сформировал одну из
самых ярких и дружных команд в компании.
Самое важное для меня – это то, как быстро ребята из тех-
поддержки растут и развиваются: семеро из них перешли в
команды разработки и стали backend- и frontend-разработчи-
ками, mobile-тестировщиками, даже влились в команды Data
Science и DevOps. В итоге из службы поддержки получилась
отличная школа, пройдя которую ребята находят себя в раз-
работке. Это очень выгодно и компании: штат разработчи-
ков пополняют те, кто прекрасно знает контекст бизнеса, по-
этому не нужно тратить время на их адаптацию.
В начале мая 2016 г. сервис Juno прошел альфа- и бета-те-
стирование, и мы открыли его для всех пользователей. Па-
ру месяцев ушло на стабилизацию системы, и к концу осени
количество поездок уже приближалось к 100 000 в неделю.
Весной 2017 г. Juno купила израильская компания Gett Taxi,
а нашей главной задачей стал вывод компании в операцион-
ную прибыль. При этом нужно было сохранить рост по коли-
честву поездок. К июлю 2018 г. мы справились и с этой за-
дачей, и сервис Juno впервые вышел на операционную при-
быль на американском рынке.
К сожалению, у бизнеса не было возможности масштаби-
ровать сервис. Juno мог выйти в прибыль при открытии сер-
виса еще в пяти-шести крупных городах, но для этого нужны
были серьезные инвестиции. Компания замедлила свой рост
в поиске инвесторов.
Летом 2019 г. Сергей получил предложение, от которого
не мог отказаться, – возглавить компанию (Amasty).
Поиск инвесторов для Juno затягивался, и осенью 2019 г.
было принято тяжелое решение завершить работу компании.
Но для Минского центра разработки все закончилось очень
удачно: нашу команду в полном составе купила прекрасная
компания Lyft. Но это уже совсем другая история.
Удалось ли Juno изменить мир к лучшему? Однозначно
да. Со временем наши высокие стандарты качества работы с
водителями стали стандартом в отрасли.
Годы работы в Juno оказались очень интересными, увле-
кательными и яркими. Это не было просто и легко. Мы мно-
го раз сталкивались со сложностями: привлечение инвести-
ций, необходимость молниеносной реакции на изменения
рынка, выход основателей из компании, выгорание ключе-
вых ребят. Каждый из этих моментов стоил здоровья, но все
это мелочи. За эти годы мы встретили много прекрасных лю-
дей, у нас сложилась отличная команда, с которой хочется
работать всю жизнь.
А еще, и это самое лучшее, нас многому научила рабо-
та с израильтянами. То, как они умеют работать и отдыхать,
находить классные решения, с какой любовью относятся к
своему делу, – это высший уровень. Работать вместе с ними,
учиться у них, заряжаться их энергией и оптимизмом – про-
сто прекрасно. И это не говоря об опыте продуктовой разра-
ботки, который получила наша команда. Израильтяне дей-
ствительно умеют делать продукты. Это у них в крови.
Нам, белорусам, свойственно очень стараться и делать все
суперхорошо с первого раза. Из-за этого стремления у нас
иногда получается так называемый «overengineering», когда
решение задачи сложнее, чем требовалось.
У израильтян все иначе. Они не боятся ошибаться. На-
верное, это кроется в особенностях воспитания. У евреев не
принято ругать ребенка, если он ошибся. Он должен выне-
сти урок и не повторять ошибку, но в любом случае он все
равно остается лучшим. У нас же за ошибки ругают.
Отсутствие страха ошибиться порождает совершенно
другой взгляд на мир: давайте быстро, пусть с низким каче-
ством, но сделаем работающее решение. Оно сразу же по-
кажет нам, верно ли наше предположение о том, что нужно
пользователю. Таким образом, пока белорусские разработ-
чики продуктов будут искать свойственное им красивое ре-
шение, израильтяне сделают две-три разных версии, выяс-
нят, какая из них работает лучше, а после этого займутся
улучшением ее качества.
Именно отсутствие страха ошибки, умение действовать
быстро, продуктивно и с любовью к делу сделали из Израиля
лидера в мире стартапов. Лидера, у которого можно очень
многому научиться.
 Глава 26
Гибкие методологии
разработки ПО
Чтобы подробно рассказать о популярных сейчас гибких
(Agile) методологиях управления проектами, нужно напи-
сать отдельную книгу. В этой главе мы кратко рассмотрим
основные подходы и покажем, что они не противоречат клас-
сическим, а, наоборот, полностью им соответствуют и хоро-
шо дополняют, предоставляя больше полезных инструмен-
тов для управления проектами.
 Agile
Agile-подход – это не набор процессов, правил и практик.
Это не магический буклет, консультант или тренинг, после
которого все изменится, а проекты расцветут. Agile – это
другая логика, другой взгляд на разработку и отношение к
работе. Другая религия, если хотите.

Основные идеи Agile-подхода

● Люди и взаимодействие между ними важнее процессов

и инструментов.
Каждая команда уникальна и может выстраивать процес-
сы под себя. Процессы и инструменты вторичны, потому что
только помогают закрепить высокий уровень, которого до-
стигла команда. Если в какой-то момент команда понимает,
что может стать еще эффективнее, делая что-то по-другому,
она меняет процессы соответствующим образом.
● Работающий продукт важнее исчерпывающей докумен-
тации.
Нет смысла тратить время на описание продукта наперед,
если вы только начали работать – планы могут несколько
раз поменяться. Время на описание можно потратить более
эффективно, сделав что-то для более быстрой разработки.
Иными словами, зачем вам эксплуатационное руководство
на автомобиль, разработка которого еще в процессе?
● Сотрудничество с заказчиком важнее следования усло-
виям договора.
Важно вовлекать заказчика в разработку, проактивно ре-
шать возможные вопросы и делать то, что нужно сейчас, а не
то, что было нужно когда-то, при составлении договора.
● Готовность к изменениям важнее следования изначаль-
ному плану.
Этот пункт следует из предыдущего. Условия меняются
постоянно, современный бизнес развивается и адаптируется
к новым требованиям очень быстро. Поэтому нужно быть
готовым к изменениям в изначальном плане и принимать их
не просто как должное, а с радостью.
До работы по гибким методологиям нужно дорасти. Они
лучше работают в зрелых, состоявшихся, ответственных ко-
мандах, в которых люди понимают, чем они заняты, и стре-
мятся к общей цели. Очень важно не путать Agile и бардак:
часто бывает так, что в условиях полного хаоса и отсутствия
управления люди уверены, что работают по гибким методо-
логиям.
Agile – это целое семейство практик, которые можно раз-
делить на две группы: инженерные и процессные.
К процессным относятся Scrum, Kanban, Scaled Agile
Framework. Их задача состоит в том, чтобы организовать ра-
бочий процесс и управлять им.
Инженерные – это, например, Lean или Extreme
Programming. Они используются инженерами для организа-
ции своей работы.

Принципы Agile

Основные принципы Agile отражены в специальном ма-

нифесте, который был принят в феврале 2001 г. Agile
Manifesto содержит четыре основные идеи и 12 принципов 3.
1. Наивысшим приоритетом для нас является удовлетво-
рение потребностей заказчика благодаря регулярной и ран-
ней поставке ценного программного обеспечения.
2. Изменение требований приветствуется даже на поздних
стадиях разработки.
3. Agile-процессы позволяют использовать изменения для
обеспечения заказчику конкурентного преимущества.
4. Работающий продукт следует выпускать как можно ча-
ще, с периодичностью от пары недель до пары месяцев.
5. На протяжении всего проекта разработчики и предста-
вители бизнеса должны ежедневно работать вместе.
6. Над проектом должны работать мотивированные про-
фессионалы. Чтобы работа была сделана, создайте условия,
обеспечьте поддержку и полностью доверьтесь им.
7. Непосредственное общение является наиболее прак-
тичным и эффективным способом обмена информацией как
3
Речь идет о Республиканском Доме технического и художественного творче-
ства учащейся молодежи, г. Минск.
с самой командой, так и внутри нее.
8. Работающий продукт – основной показатель прогресса.
9. Инвесторы, разработчики и пользователи должны
иметь возможность поддерживать постоянный ритм беско-
нечно. Agile помогает наладить такой устойчивый процесс
разработки.
10. Постоянное внимание к техническому совершенству
и качеству проектирования повышает гибкость проекта.
11. Простота – искусство минимизации лишней работы –
крайне необходима.
12. Самые лучшие требования, архитектурные и техни-
ческие решения рождаются у самоорганизующихся команд.
Команда должна систематически анализировать возможные
способы улучшения эффективности и соответственно кор-
ректировать стиль своей работы.
Как видите, почти во всем принципы Agile полностью со-
ответствуют тому, чему нас учит и классическая методоло-
гия: вовлекать заказчика; частые результаты поставки лучше
крупных разовых; самое важное – команда и ее мотивация.
Обо всем этом мы уже говорили на страницах нашей книги.
Давайте еще больше углубимся и посмотрим детальнее на
Scrum, Kanban, XP и Lean.
 Scrum
Scrum – это фреймворк, предназначенный для разработ-
ки, поставки и поддержки сложных продуктов. Он хорошо
работает в среде высокой неопределенности и подразумевает
создание продукта или нового функционала в жестко фик-
сированные по времени и непродолжительные итерации –
спринты (sprints). Итог каждого спринта – предоставление
конечному пользователю работающего ПО с новыми воз-
можностями.
Scrum не является процессом, техникой или исчерпываю-
щим методом. Напротив, Scrum – это фреймворк, в котором
можно использовать разнообразные процессы и методы.
Основные элементы фреймворка – scrum-команды и свя-
занные с ними роли, события, артефакты и правила. Каждый
элемент фреймворка служит определенной цели и является
обязательным для успешного использования Scrum.
Правила Scrum связывают вместе события, роли и арте-
факты, регулируют отношения и взаимодействия между ни-
ми. Scrum использует итеративный и инкрементальный под-
ход, чтобы улучшать прогнозируемость и управлять риска-
ми.
Scrum основан на трех китах: прозрачности, инспекции и
адаптации.
Прозрачность. Прозрачность означает, что значимые
характеристики процесса должны быть известны тем, кто от-
вечает за его результат. Прозрачность требует, чтобы эти
характеристики были обозначены общими соглашениями, а
все участники одинаково понимали происходящее. Напри-
мер:
● терминология, имеющая отношение к процессу, долж-
на быть общей для всех участников;
● понимание критериев готовности должно быть общим
для исполнителей работ и тех, кто инспектирует результаты.
Инспекция. Участники процесса должны регулярно ин-
спектировать артефакты Scrum и свой прогресс в движении
к цели спринта, чтобы вовремя обнаружить нежелательные
отклонения. Частота проведения проверок не должна ме-
шать работе. Проверки приносят наибольшую пользу, когда
выполняются профессионалами с соответствующими навы-
ками.
Адаптация. Если в результате инспекции выясняется,
что одна или несколько характеристик процесса выходят за
допустимые пределы и это приводит продукт в неприемле-
мое состояние, то процесс или обрабатываемый материал
необходимо изменить. Чем раньше будут внесены измене-
ния, тем меньше риск дальнейших отклонений.
Scrum предполагает четыре формальных события для ин-
спекции и адаптации:
● планирование спринта;
● ежедневный скрам;
 ● обзор спринта;
● ретроспектива спринта.
Эти события детально рассмотрены в разделе «События
Scrum».

Ценности Scrum

Scrum-команда опирается на следующие ценности:

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

Основные роли

Работа по Scrum подразумевает задействованность в про-

екте нескольких ролей.
Scrum-мастер (Scrum master) – человек, который отсле-
живает соблюдение всех ритуалов фреймворка Scrum и по-
могает команде решать открытые вопросы. В его обязанно-
сти входит разрешение внутрикомандных противоречий и
защита от отвлекающих факторов.
Тут можно провести аналогию с руководителем проекта,
но она будет не совсем верна. В Scrum обязанности класси-
ческого руководителя проекта делятся между Scrum-масте-
ром и владельцем продукта.
Владелец продукта (Product owner) – человек, который
представляет в проекте интересы пользователей и других за-
интересованных сторон. Владелец продукта отвечает за фор-
мирование и приоритизацию списка известных требований
к продукту – бэклога.
Эта роль больше всего похожа на роль спонсора проекта,
но с дополнительной ответственностью за приоритеты, ито-
говый бюджет и сроки.
Команда разработки (Development team) – кросс-функ-
циональная команда проекта, состоящая из специалистов
разных профилей: тестировщиков, архитекторов, аналити-
ков, программистов и др. Идеальный размер команды в
Scrum – от трех до девяти человек. Команда отвечает за ре-
зультат проекта как единый исполнитель. Никто не может
вмешиваться в ее работу на всем протяжении спринта.

Scrum-артефакты

Артефакты Scrum отражают работу или ценность, со-

здавая новые возможности для инспекции и адаптации.
Они специально разработаны для обеспечения максималь-
ной прозрачности ключевой информации, чтобы все участ-
ники процесса обладали одинаковым ее пониманием.
Бэклог продукта (Product backlog) – упорядоченный
список известных требований к продукту. Это единствен-
ный источник требований к любым необходимым изменени-
ям в продукте. Владелец продукта является ответственным
за его бэклог, включая содержимое, доступность и упорядо-
ченность продукта.
Бэклог работ похож на иерархическую структуру работ.
Это те же пакеты работ, только расставленные в порядке важ-
ности для бизнеса. Такая сортировка отлично помогает в
условиях частых изменений приоритетов.
Бэклог спринта (Sprint backlog) – это набор элемен-
тов бэклога продукта, взятых в спринт, плюс план по дости-
жению цели спринта и поставке инкремента продукта. Бэк-
лог спринта – это прогноз команды разработки о том, какая
функциональность войдет в следующий инкремент и какая
работа необходима для создания готового инкремента.
Бэклог спринта отражает весь объем работ, который ко-
манда разработки считает необходимым выполнить для до-
стижения цели спринта. Фактически мы набираем в спринт
содержание работ, которые можем сделать за итерацию.
Инкремент (Increment) – это сумма завершенных во вре-
мя спринта элементов бэклога продукта и всех инкремен-
тов предыдущих спринтов. К концу спринта инкремент дол-
жен быть «готов», что подразумевает его соответствие кри-
териям готовности Scrum-команды и готовность к использо-
ванию.
Диаграмма «сгорания» задач (Burndown chart) – диа-
грамма, демонстрирующая количество проделанной и остав-
шейся работы относительно времени на разработку проекта
(рис. 61). При помощи этой диаграммы мы можем спрогно-
зировать, когда будет завершена работа над всеми задачами,
находящимися в бэклоге.
 Хотя диаграмма «сгорания» задач не является артефак-
том Scrum, все же хотелось бы ее отметить. Обратите внима-
ние на сходство с методом освоенного объема, который мы
рассмотрели ранее.

События Scrum

Спринт (Sprint) служит ядром Scrum. Это временной от-

резок длительностью до месяца, в течение которого создает-
ся «готовый», то есть пригодный к использованию и выпус-
ку, инкремент продукта. Желательно сохранять неизменную
продолжительность спринта на протяжении всего процесса
разработки. Новый спринт начинается сразу после оконча-
ния предыдущего.
Спринт похож на этап проекта. Маленький размер этапа
обусловлен тем, что при высокой неопределенности мы не
уверены, что все делаем верно. Если в конце спринта мы по-
нимаем, что часть работ сделана не так и что-то нужно пере-
делать, то количество исправлений не будет слишком боль-
шим.
Планирование спринта (Sprint planning meeting). Пла-
нирование происходит в начале новой итерации спринта. В
классическом Scrum делается это следующим образом.
● Из бэклога выбираются задачи, которые отдаются на
рассмотрение команде.
● Оценивается трудоемкость каждой задачи. Решение не
должно занимать более 12 часов (полутора дней). Если тре-
буется, то задача разбивается на подзадачи.
● Члены команды обсуждают каждую задачу и определя-
ют подход к ее решению. Как правило, продолжительность
такого совещания ограничена четырьмя часами. Обычно со-
вещание делится на две части. В первой владелец проек-
та и Scrum-команда выбирают задачи на спринт. Во второй
участвует только Scrum-команда, которая определяет техни-
ческие подходы к решению задач и наполняет бэклог сприн-
та. Как правило, это довольно длинные совещания с ожив-
ленными дискуссиями и спорами.
● Команда выбирает задачи, которые успеет сделать за
спринт. На основе выбранных задач формируется бэклог
спринта.
Ежедневное совещание (Daily Scrum meeting). Есть
несколько правил проведения ежедневных Scrum-встреч:
они всегда начинаются вовремя, длятся не более 15 минут и
проводятся в одном и том же месте на протяжении спринта.
Во время совещания каждый член команды отвечает на
три вопроса:
1. Что я сделал со времени последнего совещания, чтобы
помочь команде разработки достичь цели спринта?
2. Что я планирую делать сегодня, чтобы помочь команде
достичь цели спринта?
3. Вижу ли я препятствия для себя или команды, которые
могли бы затруднить разработку? (Если в ответе на этот во-
прос озвучиваются проблемы, то над их решением думает
уже Scrum-мастер. Как правило, решения таких затруднений
ищут вне совещания, а в поиске задействованы те, кого про-
блема может затронуть непосредственно.)
Обзор спринта (Sprint review meeting). Обзор проводит-
ся в конце спринта и нужен для того, чтобы показать итог
работы команды за итерацию. Команда демонстрирует при-
рост функциональности продукта его владельцу и всем за-
интересованным лицам. По результату обзора спринта воз-
можна адаптация бэклога.
Обзор спринта ограничен четырьмя часами, но может ид-
ти меньше, в зависимости от продолжительности итерации
и прироста функциональности продукта. В демонстрации
участвуют все члены команды. Демонстрируется только за-
вершенная работа. Все, что еще не готово, не демонстри-ру-
ется.
Очень важно провести обзор спринта максимально четко
и хорошо, потому что эта встреча похожа на развязку филь-
ма и оставляет наиболее сильное впечатление о ходе всего
спринта. Мы рекомендуем провести предварительный про-
гон с командой перед показом владельцу продукта, чтобы
потренироваться и исключить неожиданности.
Ретроспектива спринта (Sprint retrospective meeting).
Ретроспективное совещание – это встреча, которая прохо-
дит в самом конце спринта и подводит его итоги. Как прави-
ло, продолжительность такого совещания не превышает трех
часов. В течение этого времени члены команды:
● высказывают свое мнение о прошедшем спринте и от-
вечают на два основных вопроса: «Что в нем было сделано
хорошо?» и «Что нужно улучшить в следующий раз?»;
● улучшают процесс разработки: решают вопросы и фик-
сируют удачные решения.
В Juno мы попробовали несколько форматов ретроспек-
тив. Нам нравится вариант с использованием карточек Кро-
уфорда. Суть в том, чтобы попросить членов команды взять
четыре стикера, на двух написать, что понравилось в ходе
спринта, а еще на двух – что можно улучшить. Затем все пе-
речисленное выписывается на доску либо стикеры наклеива-
ются на нее (рис. 62).

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

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

Как выглядит рабочий процесс по Scrum

Владелец продукта формирует бэклог продукта или про-

екта, который содержит в себе задачи в виде User stories.
Каждая из них содержит описание того, что нужно сделать,
и критерии приемки. Это очень похоже на ИСР, но есть от-
личие: задачи в бэклоге приоритизированы. Та, что навер-
ху, – самая важная на данный момент. Приоритизируя зада-
чи, владелец продукта определяет то, что важно для бизнеса
именно сейчас (рис. 64).
 Далее начинается планирование спринта. Владелец про-
дукта вместе с командой разработчиков составляет перечень
работ, которые будут взяты в спринт. Попадают в него те за-
дачи, которые команда успеет сделать за спринт (по ее соб-
ственной оценке). Далее начинается работа.
В ходе спринта каждый день команды начинается с еже-
дневного Scrum-митинга. Он очень похож на утреннюю пла-
нерку: собрание длится около 15 минут и всегда проходит
стоя. Благодаря этому все хотят закончить его побыстрее,
поэтому говорят четко и по делу. В ходе митинга каждый
член команды должен ответить на три вопроса, которые мы
упоминали выше. Роль Scrum-мастера в данном случае напо-
минает роль менеджера проекта: он собирает информацию,
чтобы решать эти самые возникающие проблемы. Scrum-ми-
тинг – это ритуал, поэтому важно всегда проводить его в од-
но и то же время и в одном и том же месте.
В конце спринта проводится его обзор. Команда показы-
вает готовую работу владельцу продукта, получая от него ин-
формацию о том, все ли получилось так, как задумывалось.
После этого команда и владелец продукта проводят разбор
полетов – ретроспективу спринта.
Scrum хорошо работает в условиях неопределенности, ко-
гда приоритеты бизнеса быстро меняются. При таком подхо-
де команда в каждом спринте берет в работу самые важные
на данный момент задачи бизнеса.
 Kanban
Kanban в переводе с японского – «сигнальная доска».
Очень часто именно эти доски люди принимают за Kanban,
даже не пытаясь копнуть немного глубже и разобраться, на-
сколько он прекрасен.
Как и в случае со Scrum, Kanban – это не конкретная мето-
дология, процесс или набор инструментов. Это система цен-
ностей, которая помогает стабилизировать производство, в
том числе и разработку ПО, за счет визуализации незавер-
шенной работы, выявления «бутылочных горлышек» и по-
стоянного совершенствования процессов. Применение ме-
тодологий Kanban очень часто идет рука об руку с принци-
пами теории ограничений, которую идеально описал в своих
книгах Элияху Голдратт («Цель»), а его последователи пе-
реложили в историю, близкую каждому, кто посвятил свою
карьеру информационным технологиям, и связали с такой
трендовой в наше время философией, как DevOps, в романе
The Phoenix project.
В рамках этой книги мы сфокусируемся только на основ-
ных принципах данной методологии, чтобы не лишать вас
удовольствия от прочтения множества замечательных книг о
Kanban, в том числе одноименного издания Дэвида Андер-
сона.
Итак, четыре основных принципа Kanban.
 1. Визуализация процесса разработки. Одно из ос-
новных достоинств Kanban заключается в том, что с его по-
мощью можно визуализировать всю незавершенную работу,
что, в свою очередь, дает вам наглядное понимание пото-
ков работ и их ограничений. Для того чтобы начать работать
по Kanban, вам понадобятся карточки и доска. Обычно для
физических досок в качестве карточек используют стике-
ры (Post-it notes). Каждая задача записывается на отдельном
стикере, который затем помещается на доску, расчерченную
на столбцы. Каждый столбец соответствует этапу в рамках
вашего процесса разработки; в производстве колонки могут
быть эквивалентны узлам обработки или станкам. Главное
заблуждение – принимать в качестве «узла» конкретного че-
ловека, так как он может выполнять сразу несколько ролей
и вместо упрощения потоков производства у вас может по-
лучиться «порция спагетти». В самом простом случае столб-
цов будет три: «Бэклог», «В разработке», «Сделано». По ме-
ре работы над задачей карточка продвигается по колонкам
от «Бэклога» до «Сделано». В своей работе мы использовали
такие колонки:
● Бэклог (перечень всех задач, которые нужно сделать);
● Выбрано для работы (выбранные для разработки зада-
чи, которые мы будем брать в работу в ближайшее время);
● В работе (задачи, работа над которыми ведется в на-
стоящее время);
● Проверка кода (задачи, в которых процесс непосред-
ственно разработки уже завершен, но требуется согласова-
ние решения с другими членами команды и проверка кода);
● Тестирование (задачи, с которыми работает команда те-
стирования);
● Для демо (задачи, результат которых можно демонстри-
ровать владельцу продукта);
● Готово (завершенные задачи, результатом которых яв-
ляется работающее решение, что подтверждает владелец
продукта после демонстрации).

Доски могут быть как физические на стене в офисе, так

и электронные в специализированных сервисах, например в
Trello или Jira. Задачи продвигаются по колонкам слева на-
право. Правда, иногда бывает движение и в обратную сторо-
ну – к примеру, если в ходе проверки кода выяснилось, что
требуется доработка. Важно понимать, что естественным яв-
ляется только движение слева направо. Любое движение в
обратную сторону должно приравниваться к браку и, следо-
вательно, подвергаться анализу с целью устранения.
Обратите внимание на приведенную выше схему. Наверху
нашей доски есть строка (иначе ее называют «плавательная
дорожка» – от англ. swimlane) «Срочно», куда мы помеща-
ем срочные задачи, которые нужно завершить в первую оче-
редь. Такой подход таит в себе ловушку: если злоупотреб-
лять этой строкой, то постепенно туда могут перекочевать
все ваши задачи и вы опять вернетесь к вопросу «Как при-
оритизировать работу». Поэтому рекомендуем вам заранее
договориться о правилах приоритизации задач.
Визуализация Kanban – это очень здорово. Так приятно
передвигать задачу в следующую колонку по мере заверше-
ния очередного этапа работ. Кроме того, она показывает, ко-
гда на пути завал (скопление задач в одной колонке) и пора
остановиться и разобраться, что пошло не так.
2. Ограничение Work in Progress (WIP). Это количе-
ство задач, выполняемых одновременно на каждом этапе
разработки. Проще говоря, мы определяем максимальное
количество задач, которое можем выполнить на одном этапе.
Ограничения позволяют нам избежать тех самых завалов.
Представьте себе мост, по которому спокойно проезжают ма-
шины со скоростью 80 км/ч при 70 %-ной загрузке. Если же
загрузка вырастает до 80 %, то скорость падает до 60 км/ч,
при 90 %-ной загрузке скорость составит всего 20 км/ч, а ко-
гда загрузка приближается к 100 %, движение практически
останавливается. По сути, при разработке это правило дей-
ствует так же: чем меньше у исполнителя параллельных за-
дач, тем быстрее он выполняет свою работу. Быстро и каче-
ственно справляться можно только тогда, когда ты сфокуси-
рован на небольшом количестве задач, а в идеале – на одной.
Если параллельно вести десяток дел, то время выполнения
каждого из них серьезно увеличивается. Например, если те-
стировщик вдруг заметил баг, а разработчик занялся другой
задачей, не дожидаясь завершения проверки, то это окажет
значительное влияние на время, за которое будет завершена
первая задача.
3. «Охота на бутылочные горлышки». Как только вы
наладите свои мосты и узнаете их ограничения, у вас появит-
ся информация о пропускной способности вашей системы,
которая эквивалентна его самому медленному участку, или
«бутылочному горлышку». Увеличение производительности
самого медленного шага ведет к общему увеличению про-
изводительности всей системы. Kanban наглядно демонстри-
рует, где в процессе разработки находится «бутылочное гор-
лышко», то есть перед какой колонкой скапливаются карточ-
ки. Одним из способов решения вопроса «бутылочных гор-
лышек» является их расширение за счет более свободных
узлов.
Например, если в колонке «Проверка кода» постоянно об-
разуются очереди из задач выше определенного уровня, то
следует перестроить процесс таким образом, чтобы они не
застревали в этом статусе. Одна из наших команд договори-
лась, что утро рабочего дня начинается с ревью и коллеги не
приступают к разработке, пока вся колонка «Проверка кода»
не опустеет.
Методология Kanban подразумевает наличие кросс-функ-
циональной и самоорганизующейся команды, каждый член
которой может помочь коллеге. С моей точки зрения, это
возможно только частично. Например, если тестирование
не справляется, то разработчики помогают тестировщикам,
что теоретически возможно. А вот обратный вариант в моей
практике не встречался. Если Kanban указывает на то, что
«бутылочное горлышко» находится на этапе разработки, то
работать с ним нужно или увеличивая численность команды,
или инвестируя в инструменты сборки и тестирования.
Работа с «бутылочными горлышками» помогает видеть
проблемные места и итерационно улучшать работу над са-
мым медленным шагом, что, в свою очередь, ускоряет весь
процесс.
4. Измерение времени цикла. Главная метрика эффек-
тивности при использовании Kanban – это скорость, с кото-
рой задача «пролетает» из «Бэклога» в «Готово». Поэтому
важно измерять среднее время на выполнение одной задачи
и постоянно оптимизировать процесс, чтобы сократить его.
Отслеживать скорость можно при помощи контрольной кар-
ты – это метрика, которая указывает среднее время прохож-
дения задачи по доске. Хорошо, если каждый месяц скорость
немного возрастает.
Выглядит эта метрика так (рис. 66).
 Точки – время, за которое выполнялись задачи.
Прямая линия – среднее время выполнения задач за пе-
риод времени, выбранный для отчета.
Волнистая линия – скользящее среднее, показатель изме-
нения скорости прохождения задачи по доске со временем. В
нашем примере скользящее среднее уменьшается. Это очень
хорошо и свидетельствует о постоянном улучшении процес-
са.
Светло-серая область – стандартное отклонение. Оно по-
казывает, насколько предсказуемо время выполнения задач.
Kanban имеет множество применений. В сфере IT он рас-
пространен в командах оперирования, где идет большой по-
ток задач, которые может выполнить практически любой
член команды.
Также он отлично показывает себя в тех случаях, когда
приходится работать в условиях очень высокой неопреде-
ленности – например, над продуктом на высококонкурент-
ном рынке с частыми сменами приоритетов бизнеса и необ-
ходимостью регулярно вносить в систему изменения с целью
тестирования различных гипотез.
 Extreme Programming
От управленческого Agile перейдем к инженерному. Экс-
тремальное программирование (Extreme Programming, XP),
как и большинство других гибких методологий, – скорее фи-
лософия, чем набор инструментов.
Модель рабочего процесса по XP выглядит как частая по-
следовательность выпусков продукта. Настолько частая, на-
сколько это возможно. Но при этом обязательно, чтобы в
выпуск входила новая атомарная функциональность. «Ато-
марная» означает, что нужно продемонстрировать хоть и ма-
ленький, но новый и полностью рабочий функционал.
Разбить функционал на атомарный не так просто, как ка-
жется. В самом начале разработки клиентского приложения
такси-сервиса мы решили использовать такой подход и про-
вели несколько дней за размышлениями, как можно разбить
функционал приложения на атомарный. В итоге в первый
спринт была создана иконка приложения, по клику на кото-
рую оно запускалось и открывалась карта. Во втором сприн-
те на карту была добавлена метка с текущим местоположе-
нием пользователя, а еще появилась возможность масштаби-
ровать карту. В третьей итерации появилась строка адреса, и
при движении пользовательской отметки по карте автомати-
чески считывался текущий адрес, и т. д. В каждой итерации
добавлялся атомарный функционал.
 Согласно первому изданию книги Extreme Programming
Explained, выделяют четыре группы основных приемов экс-
тремального программирования.
1. Короткий цикл обратной связи (Fine-scale
feedback). Разработка ПО является диалогом между возмож-
ностями и желаниями, при этом меняется и то, и другое.
В этих условиях нужно искать баланс между требованиями
бизнеса, техническими возможностями и качеством. Владе-
лец продукта или заказчик работают напрямую с командой
и всегда доступны для вопросов и диалога.
2. Процесс разработки непрерывный, а не пакет-
ный. Если есть хороший инструментарий по сборке, автома-
тическому тестированию и выпуску в продакшн, то публи-
ковать новый функционал можно по его готовности частыми
небольшими релизами. При этом каждая строчка кода мо-
жет попасть в релиз почти сразу после написания. Чтобы это
стало реальностью, нужен хорошо подготовленный инстру-
ментарий непрерывной интеграции (Continuous integration).
Команда непрерывно осуществляет рефакторинг и улуч-
шение дизайна, архитектуры продукта, модулей системы и
процесса разработки. Хорошим процентным соотношением
считается 70 на 30: 70 % времени команда работает над за-
дачами бизнеса, а 30 % – над рефакторингом и устранением
дефектов.
3. Простота (Simple design) против избыточного проек-
тирования. Как ни странно это прозвучит, но очень легко
сделать что-либо сложным. Придумать действительно кра-
сивое и простое решение всегда тяжело: это требует време-
ни. Французский ученый и философ Блез Паскаль заметил:
«Я пишу длинно, потому что у меня нет времени написать
коротко».
С точки зрения проекта это означает, что его суть должна
умещаться в одну-две фразы или выражаться в емком обра-
зе, как миссия компании.
Для упрощения работы командами используются единые
стандарты по написанию кода и автоматические инструмен-
ты для проверки соответствия этим стандартам.
4. Социальная защищенность программистов
(Programmer welfare). Команда должна уметь поддерживать
высокий рабочий темп на неопределенном временном про-
межутке. И речь идет не о неделях, а о месяцах и даже годах.
Поэтому очень важно соблюдать баланс «работа – жизнь».
У разработчиков должен быть нормальный рабочий график,
чтобы они не «сгорали».
Все эти четыре группы приемов не только верны в тео-
рии, но и на практике используются в IT. Они продиктованы
здравым смыслом и опытом.
Теперь давайте посмотрим на Lean-подход, который очень
хорошо дополняет Extreme Programming.
 Lean
Методология Lean («Бережливое производство») роди-
лась в производственной сфере. Это произошло потому, что
нужно было устранить из производственной цепочки шаги,
которые не добавляли ценности итоговому продукту и за ко-
торые клиент не хотел платить. Понятие «lean» появилось
в 1980-х гг. Как правило, компании, применяющие Lean,
характеризуются культурой непрерывного совершенствова-
ния, которая проявляется и в организации как таковой, и на
базовом операционном уровне.
Базовым принципом мышления в стиле Lean является со-
здание ценности. Действие, создающее ценность, должно со-
ответствовать трем критериям:
● быть нужным потребителю;
● менять форму/функцию продукта/услуги, тем самым
приближая их к финальному состоянию;
● должно быть произведено без дефектов с первого раза.
Если одно из требований не выполняется, то считается,
что действие не создает ценности.
Lean-методология строится на идее снижения затрат, она
отодвигает в сторону любые вещи, не направленные на до-
стижение цели, – в частности, любые артефакты, которые не
создают реальную ценность для бизнеса. Например, зачем
писать детальную документацию, если система развивается
настолько быстро, что документ мгновенно устаревает? Но
раз уж совсем без документации нельзя, то можно изменить
подход и улучшить качество кода, чтобы он легко читался,
так что будет сразу понятно, как и что работает.
Lean базируется на шести принципах.
1. Исключение затратных процессов и продуктов
разработки. Фокусироваться нужно на основных функциях
продукта, которые необходимы большинству пользователей.
Не стоит тратить время на эксклюзивные свойства/функцио-
нал, востребованные небольшим числом пользователей. Бо-
лее того, если какими-либо функциями мало пользуются, то
их нужно убирать из продукта. Сопровождение этих функ-
ций требует денег, а наличие в кодовой базе замедляет раз-
работку.
Дефектов быть не должно. Зачем тратить время и нервы
на устранение дефектов в готовом продукте? Лучше потра-
тить чуть больше времени, но написать код качественно с
первого раза.
Переключение с задачи на задачу отнимает время. Инже-
неру приходится вспоминать контекст, заново прочитывать
требования, поднимать проектную переписку. Гораздо луч-
ше работать над одной задачей в один временной отрезок.
Планирование зависимостей осуществляется таким обра-
зом, чтобы минимизировать или вообще сократить до нуля
простои команд, когда одну из них блокирует другая.
Зачем работать над детальной документацией требова-
ний, если ее никто не читает и она мгновенно устаревает в
процессе?
К этой же категории относится микроменеджмент и из-
лишняя менеджерская деятельность. Команда разработки
должна знать весь контекст и понимать, что нужно делать.
2. Акцент на обучении и постоянном совершенство-
вании. Обучение должно проходить на собственном опыте.
Команда все время обогащает свои знания, пробует новые
подходы и экспериментирует. Как и везде, в этом нам помо-
гает цикл Деминга: планирование – действие – проверка –
корректировка.
3. Принимать решения как можно позже. Если у нас
есть возможность отложить принятие решения, то лучше это
сделать. Почему? Чем больше удалось собрать информации,
тем выше будет качество принятого решения. Следователь-
но, чем позже вы принимаете решение, тем больше у вас бу-
дет информации и тем более верным оно будет.
4. Поставлять как можно раньше. Тот же принцип,
что и в Extreme Programming. Предельно быстрая доставка
продукта заказчику и короткие итерации, создающие цен-
ность. Оперативная обратная связь.
5. Уважение и доверие. Важно уважать людей, с кото-
рыми работаешь, и поручать им ту работу, которую они уме-
ют выполнять лучше всего. Нужно обеспечить команду всем
необходимым для работы и доверить ей ответственность за
результат. Приветствуется уход от армейской системы управ-
ления с приказами и микроменеджментом. Вместо этого ко-
мандой нужно управлять, вдохновляя и мотивируя ее. Важ-
но отсутствие политики, то есть нужно делиться всей инфор-
мацией с командой.
Если команда полностью понимает контекст, то она сама
сможет принять лучшее решение. Так происходит, посколь-
ку у членов команды есть еще и технический контекст, в ко-
торый они разбираются лучше. Ответственность за резуль-
тат должен нести тот, кто делает реальную работу.
6. Строить целостное решение. Концентрироваться на
общей картине и том, что действительно важно, и не зацик-
ливаться на деталях. Важно смотреть на работу с точки зре-
ния продукта или системы, чтобы понять, насколько рабо-
та способствует их улучшению. Вся команда должна пони-
мать и разделять принципы бережливости: «Мыслить широ-
ко. Делать быстро. Ошибаться редко. Учиться стремитель-
но».
 Выводы
Классический подход и Agile – это набор инструментов
менеджера. Все больше проектов сочетают в себе разные ин-
струменты.
Количество проектов, которые используют смешанные
методологии, растет с каждым годом. Определяющим фак-
тором успеха при этом является не использование какой-ли-
бо определенной методологии, а применение формального
подхода к управлению проектами в целом. Если на проекте
используется любой из подходов, то его шансы достичь цели,
быть выполненным в рамках бюджета и в срок существенно
выше.
Гибкие методологии – это стиль и отношение к работе.
На уровне управления хорошей командой они дают заме-
чательный мотивирующий эффект, помогают с целеполага-
нием и повышением результативности. Фреймворк управле-
ния проектом по классической методологии, которому по-
священа эта книга, почти во всем пересекается с фреймвор-
ком гибких методологий, но он гораздо шире и охватывает
больше областей. Фреймворки гибких методологий объеди-
нили в себе хорошо работающие практики и идеи из «старых
книг», упростив сложные для понимания моменты.
Нам нравится следующая концепция: «Быть Agile – это
не слепое следование какой-либо методологии, это миро-
воззрение, в основе которого – постоянное совершенствова-
ние». К сожалению (или к счастью), в нашей практике не бы-
ло ни одного проекта, выполненного от и до в соответствии
с какой-либо методологией. Каждый раз это череда проб и
ошибок: что-то подходит и остается в работе надолго, что-
то не подходит, и тогда приходится искать работающие ин-
струменты дальше.
Основная идея состоит в том, что не нужно пытаться най-
ти идеальное решение – «серебряную пулю». Нужно быть от-
крытым к изменениям, не бояться пробовать что-то новое.
Шаблоны и наработки нужны, они сильно экономят время,
но это не панацея.
И вот мы подошли к главному вопросу: как узнать, какую
же методологию выбрать для проекта? Об этом мы погово-
рим дальше.
 Глава 27
Как выбрать
методологию для проекта
«Классика или гибкие методологии?» – тема для бес-
конечных споров на любой конференции или тренинге по
управлению проектами. Дискуссия очень заразная, и любой
руководитель проектов хотя бы раз участвовал в таком спо-
ре. Каждый участник обычно приводит достойные примеры
того, как работает его любимый подход и не работает подход
его визави.
Именно такой спор однажды произошел с одним из кол-
лег, занимающимся внедрением Agile в крупных российских
госструктурах. В результате мы договорились и сформули-
ровали утверждение следующим образом: «Раз есть ситуа-
ции, при которых одна методология работает лучше другой,
то должен быть и способ, позволяющий понять, что лучше
использовать для решения поставленной задачи».
Коллега сослался на очень любопытный фреймворк Ки-
невина, который мог бы помочь с поиском решения данного
вопроса. Мы начали набрасывать на него наши аргументы и
буквально влюбились в этот подход.
Модель Киневина (Cynefin Framework) была разработа-
на в начале 2000-х гг. в IBM Дейвом Сноуденом. C 1984 г.
Дейв работал в компании Data Sciences Ltd, после погло-
щения которой в 1996 г. оказался в IBM, где впоследствии
возглавил IBM Cynefin Centre for Organizational Complexity.
Модель Киневина еще называют моделью создания смыс-
ла (sensemaking), которая позиционировалась как процесс,
посредством которого люди придают смысл своему коллек-
тивному опыту. Cynefin в переводе с валлийского означает
«прибежище, среда обитания, привычный, знакомый».
Давайте рассмотрим эту модель подробнее и разберемся,
при чем здесь вообще проекты.
Модель состоит из пяти основных доменов принятия ре-
шений, в которых может находиться система. Домены также
могут называться контекстами или средами. В нашем случае
в роли контекста выступает проект, поэтому мы будем рас-
сматривать модель в адаптации к проектам (рис. 67).
 Домен I. Простой (Simple), или предсказуемый
(Obvious). В этом домене речь идет о простой упорядочен-
ной среде, где не возникает проблем с пониманием причин-
но-следственных связей. Решения принимаются по следую-
щей схеме:
Осознание ситуации → Категоризация ситуации
→ Ответ на ситуацию с использованием хорошо
известного решения.
Важно отметить вот что: предполагается, что у ситуации
всего одно решение, которое всем кажется очевидным. Си-
туации, в которых существует только одно решение, называ-
ют лучшими практиками (best practices). Использование луч-
ших практик встречается в управлении качеством, когда ор-
ганизации разрабатывают внутренние стандарты для ужесто-
чения требований, которые могут являться обязательными
и на уровне законодательства. Лучшие практики могут быть
основаны как на текущих результатах компании и желании
их улучшить, так и на анализе рынка (benchmarking).
Популярными лучшими практиками являются ГОСТ и
ISO. До сих пор, например, колбаса или тушенка с обозна-
чением ГОСТа на этикетке ассоциируется у потребителей с
высоким уровнем качества продукта. Пример лучших прак-
тик на уровне организаций – это рабочие процессы в ком-
паниях типа McDonald’s, которая смогла сделать так, что
бургер компании в любой стране мира будет иметь одина-
ковый внешний вид и вкусовые качества. Хорошим приме-
ром из IT-отрасли может служить тестирование, где есть чек-
лист, следуя которому сотрудник имеет возможность удосто-
вериться, что приложение (или его часть) работает коррект-
но.
Домен II. Сложный (Complicated). В этом домене среда
является упорядоченной, но уже не так просто найти связь
между причиной и следствием. Для нахождения таких свя-
зей требуется определенный уровень компетенции и опыта.
Решения принимаются по схеме:
Осознание ситуации → Анализ ситуации экспертом
→ Ответ на ситуацию с помощью одного из нескольких
вариантов решений.
Важно отметить, что, в отличие от предыдущего домена,
здесь уже нет единственно верного решения. Любые попыт-
ки действовать по принципу домена I вызывают недоумение
у экспертов и потерю всяческой мотивации. Это связано с
тем, что они могут быть не согласны с навязываемым «един-
ственным правильным решением».
Практики в этом домене называются «хорошими» (good
practices), как бы намекая на то, что существуют альтернати-
вы. К практикам этого домена мы можем отнести PMBOK,
PRINCE2, ITIL.
Ярким примером из IT будут проекты по внедрению на
предприятиях, скажем, SAP-решений. У таких проектов
есть несколько признаков:
● у исполнителя есть опыт выполнения подобных проек-
тов;
● заранее известно, что представляет собой готовое ре-
шение;
 ● решение не начнет приносить пользу до тех пор, пока
не будет выполнен основной объем работ.
В качестве аналогии можно привести задачу строитель-
ства бассейна, где вырытый котлован и подведенные комму-
никации будут абсолютно бесполезны до тех пор, пока чаша
бассейна не будет сконструирована и наполнена водой. При
этом один и тот же проект бассейна не гарантирует успеш-
ной реализации без привлечения эксперта, который сможет
проанализировать, все ли идет по плану, заменить материал
на аналогичный в случае, если необходимый невозможно ку-
пить, или решить, какие изменения нужно внести из-за осо-
бенностей почвы в данном районе.
Домен III. Запутанный (Complex). В этом домене среда
уже не является упорядоченной (unordered). Важно не путать
ее с беспорядком (disorder), о котором мы поговорим даль-
ше. Здесь приходится иметь дело с отсутствием и непонима-
нием связей между причиной и следствием. Лучший вариант
найти их – это собрать данные, основываясь на предприня-
тых действиях (экспериментах). Решения принимаются по
схеме:
Предпринять действия, которые помогут собрать
данные о ситуации → Осознание ситуации на
основании полученных данных → Получение ответа на
ситуацию, который позволит перевести ее в домен II
(запутанный).
В этом домене нет хороших решений. Все, что мы дела-
ем, это ищем свой путь и изучаем правила игры. Практики в
этом домене называются появляющимися (emerging); к ним
мы отнесли Agile. Чаще всего в такой ситуации оказываются
стартапы: у бизнеса есть предположение, что определенная
гипотеза может сработать. Для подтверждения гипотезы со-
здается минимально жизнеспособный продукт, после запус-
ка которого у компании появляется необходимая информа-
ция для планирования следующих шагов.
Это можно сравнить с тарелкой спагетти: сложно сказать,
как именно переплетены отдельные макаронины между со-
бой, и лучшее, что можно сделать, это потянуть за одну из
них и посмотреть, какие еще спагетти с ней соприкасаются.
Домен IV. Хаотичный (Chaotic). В этом домене прихо-
дится иметь дело с неупорядоченной (unordered) средой. Ес-
ли в предыдущем домене связи между причиной и следстви-
ем были неясными, то в этом их просто нет. Схема действий
такая:
Необходим лидер, который, основываясь на своем
чутье, предпримет действия, которые предотвратят
агонию → Основываясь на результатах действия и
факте, что «кровотечение купировано», лидер может
продумать следующие действия по стабилизации
ситуации → Получение ответа на ситуацию, который
переведет ее в домен III.
Практики, которые рождаются в этом домене, называют-
ся инновационными (novel). Ситуации в данной среде мож-
но сравнить с городом во время стихийных бедствий. В ка-
честве примеров мы можем взять дефолт в России 1998 г.
или крах Enron в 2001 г.
Несколько примеров из IT-отрасли:
● в проекте горят сроки, команда отказывается от всех
подходов, использовавшихся ранее, и лихорадочно начинает
доделывать работу;
● во время очередного релиза что-то идет не так: систе-
ма, которой уже активно пользуются, перестает функциони-
ровать, но при этом все еще неясно, что произошло с техни-
ческой точки зрения;
● система подвергается атаке злоумышленников, которые
нашли уязвимость, а сотрудники компании пытаются приме-
нить несогласованные меры для решения ситуации.
Если мы снова призовем на помощь аналогию, то все при-
меры, приведенные выше, можно сравнить с пожаром среди
ночи. В такой ситуации нет времени на планирование и об-
думывание – нужен лидер, который даст четкие распоряже-
ния по спасению жизней жильцов дома, а заодно и некото-
рого имущества. Только после этого, избежав угрозы, можно
все обдумать и спланировать следующие шаги.
Домен V. Беспорядок (Disorder) – именно так автор
данной модели назвал ситуацию, в которой люди, принима-
ющие решения, не осознают, в каком домене они находятся
и какие практики следует применять.
Модель предполагает, что в любой ситуации необходимо
двигаться по часовой стрелке: от хаотичного домена к упро-
щению. Благодаря этому основная масса неблагоприятных
ситуаций останется между сложным и запутанным домена-
ми, и лишь некоторая часть перейдет в первый домен, где
среда упорядочена.
Правда, стоит помнить, что пренебрежение сложностью и
чрезмерное стремление к простоте могут привести к обры-
ву (Cliff) VI, который мгновенно переведет ситуацию в ха-
отичный домен без возможности так же легко вернуться на-
зад.
Итак, давайте вернемся к тому, с чего начали: какую мето-
дологию использовать? Мы выяснили, что для ответа на этот
вопрос необходимо сначала разобраться в том, какую задачу
нужно решить, а затем выбрать соответствующий домен:
● Простой I (McDonald’s) – «лучшие» практики, в кото-
рых используются процессы по ГОСТ, ISO или от признан-
ных лидеров отрасли;
● Сложный II (бассейн) – «хорошие» практики, в кото-
рых используются классические подходы к управлению про-
ектами, например PMBOK или PRINCE2;
● Запутанный III (спагетти) – появляющиеся практики. В
этом домене используются Agile-практики;
● Хаотичный IV (пожар) – инновационные практики. В
этом домене нужно положиться на сильного лидера, который
поможет уйти с линии огня, а затем перейти в домен со спа-
гетти;
 ● Беспорядок V (нет понимания ситуации) – здесь нет
практик. Для начала нужно разобраться в том, где мы вооб-
ще находимся.
Хотелось бы отметить, что Agile-подходы уже нельзя на
100 % отнести к домену III, ведь за последние десять лет
они сильно повзрослели и обросли процессами, что посте-
пенно передвигает их в домен II. В то же время граница меж-
ду классическими подходами и Agile еще явно прослежива-
ется.
Если речь идет о стартапе, то он, скорее всего, в домене
III, и Agile ему подойдет больше. Если же речь о типовых
проектах с фиксированной стоимостью, за которые еще сна-
чала придется побороться в тендере, то мы предлагаем об-
ратиться к классическому подходу.
 Заключение
Мода на определенные методологии управления проекта-
ми приходит и уходит. Универсального подхода, который га-
рантированно вытянет любой проект, не существует. В итоге
процессы на каждом из этапов работы представляют собой
смесь различных методологий и инструментов управления.
Каждый проект требует индивидуального подхода. Что
именно использовать в каждом конкретном случае, зависит
от множества факторов. К ним относятся команда и ее пред-
почтения, отрасль и ее правила, задачи конкретного проек-
та, степень неопределенности и рисков, заказчик и его миро-
воззрение, конкретные инженеры и их взгляды на процессы,
правила и условия работы в компании.
Классический подход отлично работает в сложных проек-
тах, где ясно, какова цель и как к ней двигаться. Гибкие ме-
тодологии подходят для поиска цели или пути к ней.
Когда мы говорим про идеального руководителя, вне за-
висимости от того, какой подход к управлению он использу-
ет и как называется его роль (Project manager, Scrum master,
Delivery manager, Line manager), мы прежде всего подразу-
меваем, что человек отлично ориентируется в ситуации и
знает, что предпринять на текущем этапе. Ни один подход,
методология или философия не способны заменить живого
человека.
 Так в чем же секрет хорошего руководителя проектов? С
нашей точки зрения, в наличии определенных качеств, таких
как:
● уважение и любовь к людям, умение прощать ошибки,
подбадривать, принимать людей такими, какие они есть, и
продуктивно строить совместную работу;
● лидерские качества – каждый руководитель проектов
является лидером, способным сплотить команду вокруг об-
щей цели, мотивировать и вести за собой людей как в хоро-
шие, так и в плохие времена;
● коммуникабельность, умение слушать и понимать точ-
ку зрения других, умение высказать свою позицию, правиль-
но передать контекст;
● умение планировать работы, действовать проактивно и
не бояться принимать решения;
● честность и открытость – в проектном менеджменте нет
места политическим играм и обману;
● умение видеть картину в целом, внедрять систематиче-
ские улучшения для достижения результатов;
● умение учиться – мир идет вперед, появляются но-
вые методологии, подходы, инструменты, и менеджер дол-
жен стремиться к новым знаниям, посещать тренинги, кон-
ференции и митапы, делиться своими знаниями с другими;
● умение пользоваться современными IT-инструмента-
ми, которые существенно облегчают работу.
Спасибо за то, что прочитали нашу книгу. Следующим
шагом рекомендуем выписать понравившиеся идеи и ин-
струменты из книги и спланировать, как вы будете исполь-
зовать их в ваших проектах и в жизни.
Если у вас есть обратная связь по книге, напишите нам,
пожалуйста, на e-mail: book.ampm.by@gmail.com.
Подробнее о нашей команде и курсах можно узнать на
сайте ampm.by.
Удачи вам и успешных проектов!

Игорь Магазиник

сооснователь Viber, Juno

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

Борис Коренфельд

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

руководитель проектов в компании «Яндекс»

Прочитал книгу «Проджект-менеджмент: Как быть про-
фессионалом» Алексея Минкевича и Сергея Дерцапа бук-
вально за один присест. С одной стороны, она является пре-
красным дополнением ко многим другим книгам и учеб-
никам, посвященным различным методологиям управления
проектами, а с другой – в ней описаны пути развития авто-
ров, а также рассказывается об их опыте как профессиона-
лов. Поначалу я с некоторым недоверием отнесся к очеред-
ной книге об управлении проектами, однако, вчитываясь все
глубже, стал понимать, что истина – в деталях и нюансах.
Да, в книге описаны основные этапы управления проектами,
а также приведены базовые понятия «гибких методологий»
разработки. Но помимо этого в каждой главе авторы при-
водят прекрасные примеры, с помощью которых объясняют
суть того или иного понятия.
С отдельным удовольствием читаются главы об Алексее и
Сергее: в них авторы описывают путь своего профессиональ-
ного развития от школьных лет до становления и самосто-
ятельного руководства IT-компаниями. Любопытно понять
их мотивацию, зарядиться их энергией и желанием двигать-
ся вперед!
Лично для меня книга стала полезной не только как учеб-
ник, в котором в очередной раз упоминаются основы управ-
ления проектами, но и как переосмысление некоторой части
своей работы. Нюансы и примеры позволили мне по-новому
взглянуть на свою деятельность, а теоретическая база помог-
ла мне систематизировать мои знания и навыки.