Книга: Проджект-менеджмент: Как быть профессионалом
Назад: Глава 1. Карьера: знакомство, или как я попал в IT
Дальше: Глава 3. Карьера: как заставить себя учиться?
Глава 2

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

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

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

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

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

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

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

  1. Коммерческая цель. Например, бизнес хочет создать и запустить новый продукт, чтобы заработать денег.
  2. Требования рынка и соответствие времени. К примеру, у всех конкурентов уже внедрено какое-то решение или функция, а у вас еще нет. Вы теряете клиентов, и это нужно исправить.
  3. Запросы пользователей. Клиенты сообщают о том, какой функционал они хотели бы получить, и мы усиливаем конкурентное преимущество нашего решения.
  4. Законодательные требования. Допустим, правительство приняло решение, что каждый кассовый аппарат должен отправлять в налоговую данные обо всех операциях в режиме реального времени. Следовательно, мы инициируем проект по внедрению решения, которое приведет работу кассовых аппаратов в соответствие с требованиями закона.
  5. Технический прогресс. Появляются новые, улучшенные технологии, а старые отмирают. Следовательно, нам необходимо постоянно поддерживать актуальное состояние. В качестве примера можно привести технологию веб-анимации Flash, которая в свое время была популярна, но потом ее вытеснил более современный и безопасный HTML5.
  6. Социальная необходимость. Например, озеленение и благоустройство улиц, обустройство парков или благотворительность.
  7. Обновление бизнес-процессов и инфраструктуры. Эта цель ставится в тех случаях, когда компания перестраивает себя изнутри, чтобы повысить собственную эффективность. Например, за счет внедрения Agile, CRM, SAP и других современных подходов и инструментов.
  8. Воплощение мечты в жизнь. Например, проект по созданию собственной команды по автоспорту или организация кругосветного путешествия.

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

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

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

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

Список возможных решений выглядит примерно так:

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

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

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

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

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

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

А кто виноват, если проект выполнен успешно, а бизнес-цель так и не достигнута?

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

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

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

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

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

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

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

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

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

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

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

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

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

2) навести порядок в квартире;

3) почистить картошку;

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

5) сварить картошку;

6) накрыть стол.

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

Проект ограничен во времени: стол должен быть накрыт к 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 руб.:

При этом поменяется и содержание работ, и расписание (рис. 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-методологий, где рекомендованная продолжительность одной итерации составляет две-три недели. Если проще, то рабочий процесс выглядит так: выбрали из списка работ самые важные на данный момент, спланировали ближайшие две недели, сделали, показали заказчику. И так снова и снова.

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

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

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

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

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

Что делает руководитель проекта

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

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

Выводы

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

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

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

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

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

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

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

Назад: Глава 1. Карьера: знакомство, или как я попал в IT
Дальше: Глава 3. Карьера: как заставить себя учиться?