Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2010 г.

Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации

Селиховкин Иван
Санкт-Петербург – 2010

Содержание

Об авторе
Благодарности
Глава I. О чем эта книга?
Глава II. Предлагают должность – соглашаться?
Новая должность
Что такое проект?
Роль и ответственность менеджера проекта
Оцениваем свои полномочия
Мы правда этого хотим?
Глава III. Как определиться с подходом к проектному управлению?
Нужна ли нам методология?
Выбираем методологию
Компоненты проекта
Жизненный цикл проекта
Осматриваемся вокруг
Глава IV. Начинаем управлять проектом – инициация
Определяем спонсора проекта
Договариваемся со спонсором проекта
Формируем устав проекта
Чего не стоит делать в ходе инициации проекта
Глава V. Приступаем к планированию
Для чего нужны планы?
Как писать правильные планы?
«План управления проектом»
«План управления проектом» и контракт
Глава VI. Планируем содержание
Что такое «содержание проекта»?
Сбор требований
Создаем концепцию (scope) проекта
Глава VII. Определяем команду и планируем список покупок
Какие ресурсы потребуются?
Будем ли привлекать подрядчиков?
«Выбиваем» ресурсы
Глава VIII. Планируем время и стоимость с использованием специализированного ПО
Шаг первый: формируем ИСР (WBS)
Шаг второй. Определяем перечень действий.
Шаг третий. Определяем последовательность действий.
Шаг четвертый. Определяем ресурсы
Шаг пятый. Определяем продолжительность и стоимость.
Шаг шестой. Создаем расписание
Шаг седьмой. Определяем предельную цену проекта (cost baseline)
Подводя итог под уточнением треугольника
Глава IX. Планируем ответственность, коммуникации, качество
Распределяем ответственность
Планируем коммуникации
Планируем качество
Как планировать качество?
Глава X. Планируем и работаем с рисками
Что такое риски проекта?
Шаг 1. Планирование управления рисками
Шаг 2. Идентификация рисков
Шаг 3. Качественный анализ
Шаг 4. Количественный анализ
Шаг 5. Планирование реагирования на риск
Шаг 6. Изменяем планы и определяем резервы
Глава XI. Другие планы и шаг назад
Шаг назад
Другие элементы плана
Готовимся к запуску работ
Глава XII. Выполнение и контроль работ по проекту
Запускаем работы
Дело 1. Отслеживать выполнение работ
Дело 2. Управлять рисками
Дело 3. Управлять изменениями
Дело 4. Управлять ожиданиями заказчика
Дело 5. Мотивировать и развивать проектную команду
Дело 6. Отчитываться о выполнении проекта
Глава XIII. Закрытие проекта
Проводим сдачу-приемку продукта
Высвобождаем ресурсы
Сохранить информацию по проекту
Глава XIV. Что дальше?
Рекомендованная литература
Глоссарий
Приложения
Приложение 1 – Устав проекта
Приложение 2 – Реестр заинтересованных лиц
Приложение 3 – Матрица требований
Приложение 4 – Концепция проекта
Приложение 5 – Реестр рисков
Приложение 6 – Перечень ресурсов (команда)

Об авторе

Селиховкин Иван занимается управлением ИТ-проектами с 2005 года.

Участвовал в реализации десятков проектов в сфере заказной разработки и бизнес-консалтинга. Осуществлял работы для таких заказчиков как: Администрация Санкт-Петербурга, Федеральные службы и агентства (ФМС, Росздравнадзор и прочие), ГУП «Топливно-энергетический комплекс» Санкт-Петербурга, ОАО «Преображенская база тралового флота», Tieto Corporation.

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

PMP.

Благодарности

Выражаю благодарность моим друзьям и коллегам, внесшим вклад в создание данной книги, в особенности Дмитрию Письману – аналитику и руководителю проектов компании «С-Консалт».

Глава I. О чем эта книга?

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

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

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

Книга основана на адаптации стандарта PMBoK 4-th edition (свод знаний Международного некоммерческого института управления проектами) к реальному применению на ИТ-проектах. Одна из целей – показать, как используются основные положения стандарта в практике руководителя, в чем возможности «настройки» системы под себя и как все это может работать.

Специфика данной книги:

  1. Краткость (весь материал можно прочесть за несколько часов)
  2. Практичность (любое теоретическое описание процессов сопровождается описанием конкретных подходов к внедрению и шаблонами документов)
  3. Гибкость (нет и не может быть «единственно верных» проектных практик; описанные процессы и шаблоны могут быть произвольно модернизированы и скомбинированыпод нужды вашей организации)

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

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

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

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

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

По ходу повествования будут вводиться специальные термины и сокращения – их общий список приведен в конце книги (раздел «Глоссарий»).

Глава II. Предлагают должность – соглашаться?

Входы:

  • предложение возглавить проект
Новая должность

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

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

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

Что нужно знать, принимая назначения на должность?

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

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

Одно из самых простых определений гласит: проект это все, что имеет «начало, конец и цель».

Таким образом, когда в вашей организации предполагают запуск нового ПРОЕКТА – речь всегда идет о чем-то «конечном» и имеющим цель. «Разрабатывать программные продукты» – это не проект. Проект это, например, «создание и внедрение информационной системы XXY к 1 декабря следующего года».

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

Еще один аспект – масштабы проекта. Существует множество взглядов на этот вопрос. Согласно одному из них (которого я буду придерживаться в этой книге) менеджер, как обособленная фигура, обычно нужен на проектах, продолжительность которых превышает несколько месяцев, бюджет – хотя бы 50.000 долларов, а команда состоит не менее чем из 4-5 человек. Проекты меньшего размера, нередко, могут прекрасно обходиться «тим-лидерами». Если вам предлагают взять управление маленьким проектом – обязательно поинтересуйтесь, почему возникла такая необходимость и какова потенциальная роль в нем ПМ.

Роль и ответственность менеджера проекта

Роль менеджера (для краткости будем иногда использовать для его обозначения аббревиатуру ПМ – «проектный менеджер») можно описать двумя фразами:

  • ПМ отвечает за то, чтобы проект уложился в рамки тройственного ограничения
  • ПМ несет ответственность за проект в целом

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

Иногда внутри треугольника пишут еще одно условие – «удовлетворенность заказчика».

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

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

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

Оцениваем свои полномочия

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

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

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

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

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

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

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

Мы правда этого хотим?

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

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

Выходы:

  • решение об участии в проекте

Содержание Вперёд

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (6)
Пятница 17.11, 16:12
Apple запустила Pay Cash (2)
Четверг 09.11, 21:15
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...