ключевые термины и понятия в управлении проектами, ч 1
Всем привет! Сегодня хочу продолжить знакомство с менеджментом проектов и пройтись по самым ключевым его терминам и понятиям.
Какие-то блоки будут рассмотрены в отдельных статьях, поэтому по мере обрастания контентом я планирую добавлять ссылки или сноски на них.
Я могу казаться супер очевидной, но, повторюсь, мое видение блога — это последовательное изложение моего опыта погружения в управление проектами и примеры из личного опыта.
В сегодняшней статье я рассмотрю понятия проект, жизненный цикл проекта и роли в управлении проектами.
Проект
Мы знаем, что проект — это уникальное предприятие, ограниченное по времени и ресурсам, направленное на достижение конкретной цели. Как отличить проект от операционной деятельности? Ограничение во времени и четкое формулирование результата. Так, внедрение новой системы для бухгалтерского учета — это проект, есть время и результат — за полгода внедрить новое ПО и обучить сотрудников в нем работать, а ежедневное ведение бухгалтерскогоу чета, записи на счетах — это операционка, рутина, повторяющиеся во времени действия с разным результатом.
Если говорить о значимых датах и событиях в определении проекта, то не буду ходить вокруг и выискивать самых первых, буду говорить о самых системных. Основание PMI в 1969 году организации, посвященной развитию и стандартизации управления проектами, дало нам и первое официальное определение проектами, а также выделенную сферу знаний и научного интереса. Поэтому, пусть диаграмма Гантта появилась раньше (в 1910 году), легче и проще сосредоточиться на этапе после 1960-х, что во многом связано с внешними факторами экономики (конкуренция и инновации), а также требованиями к предприятию для достижения коммерческого успеха (интернациональность, технологичность, продуктовый подход) и формами самих этих предприятий — например, венчурными, или с матричными организационными структурами. То есть нам, в нашем веке и условиях развития, проще и легче понять исторические изменения в управлении проектами 1970-х, 1980-х, 1990-х за счет того что мы уже воспитывались и росли на теории «гибкого управления», такого адаптивного к условиям глобализации и технологического многообразия.
Цели и задачи проекта тесно переплетены с другим понятием, а именно — жизненный цикл проекта. У каждого этапа цикла свои задачи.
Жизненный цикл проекта
Жизненный цикл проекта — это как бабочка, только проект. От личинки до гусеницы и кокона, и, собственно, самой бабочки. Выделяют стадии цикла: инициация, планирование, выполнение, контроль, завершение.
- Инициация: Приходит идея сделать что-то, заинтересованные люди определяют цели проекта, то есть формулируют желаемый результат, договариваются о возможных сроках, очень поверхностно оценивают риски, чтобы понять целесообразность дальнейших шагов. На этом же этапе формируется команда проекта (не всегда вместе со всеми исполнителями, чаще на уровне заказчик — менеджер — спонсор).
- Планирование: Здесь детализация целей, разложение целей на задачи, переработка задач в расписание (сроки) и план в деньгах (бюджет), определение ресурсов (люди, инструменты).
- Выполнение: Реализация плана, выполнение задач, взаимодействие с командой. На выполнение влияет выбранная методология управления проектами (интеративный, спиральный, инкрементный подходы, гибкие методогии и т. д.).
- Контроль: Мониторинг хода выполнения, коррекция плана при необходимости — как по срокам, так и по бюджету, людям и инструментам. Решение конфликтов (в том числе между документацией и реализацией).
- Завершение: Оценка результатов, закрытие проекта. Признание проекта успешным, не успешным, сдача проекта, подготовка отчетной документации, или презентация готового проекта.
На иллюстрации — классическое определение жизненного цикла проекта и его стадий, но в теории управления проектами выделяют разные виды циклов:
- Предиктивный — требования к результату фиксированные, последовательное выполнение задач внутри проекта и одна поставка конечного результата (решила построить дом — спланировала дом — строитель построили от фундамента до крыши — прошла проверки от инспекций — заселилась в новый дом).
- Итеративный — требования к результату динамические, потому что постоянно дополняются за счет обратной связи, но поставка результата при этом одна, зато самая правильная из всех возможных (решила сшить брюки — скоструировала выкройку по меркам — раскроила ткань и начала шить, сначала наметала и добавила припуски, наметала и убавила в талии, примерила и скорректировала по длине, наконец все сшила, отутюжила — ношу новые брюки).
- Инкрементальный — требования к результату динамические, потому что меняются для каждого конкретного инкремента конечного результата, поставок этого результата много, зато заказчик самый довольный и постоянно видит результатики (ужин в модном ресторане с подачей 5 фьюжен-блюд, каждое блюдо — инкремент поставки всего ужина, у каждого блюда есть цикл от планирования до подачи заказчику, ужин завершился когда все 5 блюд были приняты гостем ресторана и съедены).
- Гибкий — требования к результату динамические, потому что на поставку каждого инкремента конечного результата дается обратная связь, по которой вносятся корректировки на этапах планирования и выполнения. Ценность в том что у заказчика есть регулярные результаты и возможность влиять на процесс (здесь приведу в пример поставку какого-нибудь saas-продукта крупному заказчику, узнали запрос — внедрились — скорректировали функции — доработали под заказ — внедрили и так далее).
По сути, жизненный цикл проекта зависит от того, что, собственно, за проект, в какой методологии он разворачивается, и какие требования к результату (переменчивые или же фиксированные). Работа внутри продуктовых ИТ-компаний не может быть только по одному виду жизненного цикла, это чаще всего микс. Однако существуют даже отдельные методы подбора подходящего цикла под проект (у PMI, например, рекомендована техника Agile suitability model по целым 9 критериям).
Роли в управлении проектами
Упоминала выше, что не все роли на всех этапах жизненного цикла проекта могут быть задействованы, здесь рассмотрю только такие роли как: проектный менеджер, спонсор, исполнители, заказчик. В зависимости от методологии эти роли могут называться иначе, быть раскрыты через дополнительные роли за счет их функций (в том числе поэтому методологии и роли внутри них я буду рассматривать отдельно, как и исторические какие-то моменты). Цели и задачи ролей раскрыты в их описании.
- Проектный менеджер: Отвечает за планирование, координацию и управление всеми аспектами проекта (бюджет, сроки, риски, результат). Коммуникационный менеджмент — все роли и все члены команды завязаны на менеджере проектов. Менеджер первым может заметить, что результат проекта не соответствует целям.
- Спонсор: Не смотря на почти 7 лет в менеджменте проектов, я к этой роли отношусь с позиции «Мам, купи!». Я знаю, что спонсор предоставляет ресурсы и поддержку, выступает заинтересованным стороной и решает стратегические вопросы. Но внутренне я испытываю легкий дискомфорт от того что мне нужно иметь некую фигуру для контроля за качеством моих управленческих решений. Поэтому для меня спонсор — это тот, кто разрешает купить больше инструментов и людей для закрытия проекта в срок, но может и не разрешить, если ты не даешь должного обоснования этим тратам.
- Исполнители: Люди, непосредственно выполняющие задачи проекта для достижения нужного результата с заданным уровнем качества (как работы, так и результатов этой работы). Исполнители — это все, и штатные сотрудники, и аутсорс, и фриланс, и аутстаф. Здесь важно помнить, что наложение ролей — тревожный знак. Нормально, если исполнителем на менеджерской задаче будет менеджер проекта (организовать и провести презентацию этапа проекта, например), но если менеджер проекта является исполнителем на задаче по доставке документов в роли курьера, или же рисует карту экранов мобильного приложения — о чем это говорит? Что нет исполнителя, нет исполнителя — нет ресурса, нет ресурса — не отработана связка менеджера и спонсора и либо было неправильно оценено, сколько каких людей на что потребуется и в какое время, либо нет управления изменениями внутри этого плана и оценки. Простите, отвлеклась.
- Заказчик: Тут просто, это человек или организация, которая приносит идею проекта. Приходят и говорят «хотим, чтобы было мобильное приложение с динозаврами», а уже менеджер проекта помогает в ходе коммуникации определить требования, результат ожидаемый согласовать, утвердить «ожидание — реальность», получить финансирование проекта. Здесь же важно помнить, идея у заказчика — это его «хочу, чтобы было вот такое» или «мне смертельно нужно, чтобы было такое».
Планирую разобрать роли внутри методологий, чтобы наглядно рассмотреть различия в методологиях по ролям, инструментам и подходам.
В этой части, я думаю, ограничусь этими тремя терминами. В следующей части хочу рассказать про методологии, бюджет и риски.
Может быть, есть термины, которые вы бы хотели увидеть на разборе?