1 лекция. 1. Управление проектом (Project Management)
 Скачать 1.01 Mb.
|
2. Жизненный цикл проекта. Модели жизненного цикла проекта Каждый проект, программа имеют определённые фазы (стадии) развития, известные как фазы жизненного цикла. Жизненный цикл проекта – промежуток времени между моментом появления проекта и моментом его завершения. Любой проект в своём развитии проходит этот промежуток времени. Что принимать за момент появления (начало) проекта и момент его завершения (окончание) зависит от участников проекта. Началом проекта можно считать: момент рождения идеи, дату начала выполнения работ проекта, начало его финансирования. Окончанием проекта можно считать: его ввод в эксплуатацию, достижение поставленных целей или результата, момент окончания срока окупаемости всех затрат, прекращение финансирования, расформирование команды и перевод её на другую работу, ликвидацию проекта. Рассмотрим основные фазы проекта: начальную, основную, завершающую, фазу выполнения гарантийных обязательств (См. Рис 3а). По окончании любой фазы проекта осуществляют качественную проверку основных целей и степени выполнения проекта, чтобы определить, может ли данный проект перейти в следующую фазу и исправить допущенные ошибки с наименьшими затратами. Например:   Максимальные инвестиции Рис.3а. Жизненный цикл проекта Начальная фаза – на этом этапе выполняются разработка концепции проекта, сравнительная оценка альтернатив, утверждение концепции. Фаза характеризуется относительно небольшой интенсивностью инвестиций. Основная фаза – её отличительная особенность – максимальный объём инвестиций, благодаря которому выполняется наибольший объём работ по реализации проекта. Завершающая фаза – на ней достигаются конечные цели проекта и подводятся итоги. Фаза гарантийных обязательств – на этой фазе осуществляется эксплуатация результатов проекта. Во время гарантийного периода выявленные недостатки и поломки исправляются за счёт предприятия, которое несёт ответственность за соответствующие работы. Если за окончание проекта принимается момент завершения окупаемости всех затрат, связанных с его реализацией, жизненный цикл проекта можно представить в следующем виде:   Время Рис.3б. Жизненный цикл проекта Жизненный цикл ИС – это совокупность этапов создания и использования ИС, отражающая её различные состояния, начиная с момента возникновения идеи о создании данной системы и заканчивая моментом завершения её использования у всех без исключения пользователей. Этапы жизненного цикла ИС: анализ требований; проектирование; разработка (программирование); тестирование и отладка; эксплуатация и сопровождение. Соотношение ЖЦ управления проектом и ИС представлены на рис 4.  Рис.4. Соотношение ЖЦ управления проектом и ИС  Погружение команды в бизнес-контекст – важная фаза цикла разработки программного обеспечения, с которой начинается рабочий процесс. Клиент должен понимать, что он тратит время и ресурсы на этом этапе не просто так. Ему важно, чтобы команда проекта погрузилась в детали бизнеса и тщательнее разобралась, для какого рынка готовится продукт, как сделать его по-настоящему полезным. Это актуально для любой отрасли. Сбор и анализ требований – одна из наиболее важных фаз SDLC. Она выполняется при участии клиентов, отдела продаж и отдела аналитики. На этом этапе важно максимально точно и однозначно определить требования к проекту и для команды проекта, и для бизнеса. Аналитики помогают определить конечные цели и задачи работы. Подробнее об этом этапе вы можете прочитать в нашей статье. Дизайн. К этому этапу переходят, когда есть четкое понимание целей проекта, и достаточно подробно сформулированы его требования. На основании требований обычно предлагается несколько подходов к проектированию архитектуры продукта. Внутренний дизайн всех модулей архитектуры должен быть четко определен и описан в деталях. Кодирование. Это этап непосредственной реализации системы – написание кода на выбранном с учётом стоящих задач языке программирования. Тестирование. Система запускается в бой. Этот этап сопровождается проверкой работоспособности системы, выявлением, фиксацией и исправлением багов до тех пор, пока продукт не достигнет требуемых стандартов качества. В этот период обычно возникает много несостыковок, белых пятен, багов. Их нужно оперативно устранить. Внедрение. Когда продукт протестирован и готов к развертыванию, его выпускают на рынке. Иногда развертывание продукта происходит последовательно в рамках бизнес-стратегии. Продукт может быть сначала выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, затем, основываясь на отзывах, выйти как есть либо с улучшениями. Сопровождение. На этом этапе жизненного цикла обеспечивается периодическая техническая поддержка системы. Это позволяет убедиться, что система не устарела и отвечает современным стандартам и технологиям. Сюда входит постоянная оценка производительности и апдейты компонентов. Первый уровень. Базовая помощь, на этом уровне обрабатываются несложные вопросы, которые не требуют много внимания. Второй уровень. Расширенная помощь от персонала с более глубокими знаниями о продукте. Это не обязательно технические специалисты, но они точно отлично знают продукт. Третий уровень. Экспертный уровень, осуществляется опытными специалистами: менеджерами продукта, инженерами. Что такое организационная структура проектаОрганизационная структура проекта – это временная организационная структура, созданная для повышения качества управления и взаимодействия в проекте путем определения и визуализации процессов взаимодействия как между внутренними, так и с внешними участниками проекта. Определение, если что, не формальное из стандарта типа PMBoK, а авторское, не знаю, где взять формальное. Если у вас есть вариант лучше – здорово, предлагайте в комментариях! Типы организационных структур проектаКак уже было сказано раньше, почему-то большинство авторов подменяют понятие орструктуры проекта понятием оргструктуры компании, и приводят именно типы оргструктуры компании, что неверно, с моей точки зрения. К организационной структуре конкретного проекта эта информация имеет довольно посредственное отношения и просто является вводной. Формального распределения организационных структур проекта по типам я не знаю, но люди любят все раскладывать «по корзинкам», и я тоже люблю. Лично для себя за годы работы вывела следующие условные типы организационных структур проекта: Организационная структура управления проектом. Согласуется на уровне управляющего комитета, предназначена для определения уровней принятия решений (не забываем сначала согласовать построенную организационную структуру со спонсором проекта, просто потому что по аналогии с выступлением на управляющем комитете – это всегда должно быть вашей первой точкой согласования, если со спонсором вы хотите дружить). Организационная структура выполнения проекта. Согласуется на уровне тимлидов, предназначена для организации взаимодействия между командами, вовлеченными в проект (архитектура, тестирование, разработка, анализ и проч.). Организационная структура работы с подрядчиком или подрядчиками в проекте. Согласуется на уровне ответственных за проект от каждой вовлеченной стороны для определения процесса работы и точек принятия решений. Организационная структура программы проектов. Согласуется на уровне руководителя программы и ее спонсора для определения процесса взаимодействия между проектами (и, конечно, руководителями проектов), включенными в программу. Какой-то особенной ценности такое разделение по типам не несет, но помогает со временем понять (после пары грабель), какая информация в каком типе оргструктуры должна быть представлена. Есть еще отдельный кусок – организационная структура портфеля проектов, но это больше про процесс, а не про проект, поэтому сюда ее не включаю. Бывают и полные оргструктуры, отражающие все аспекты проекта от эскалации до взаимодействия с бухгалтерией, но, на мой взгляд, они сложны для понимания, допускают много возможных толкований, а значит – свою задачу не выполняют. Разработка организационной структуры проектаПеред разработкой организационной структуры неплохо бы сделать анализ стейкхолдеров, чтобы никого не забыть. Как это сделать – написано тут. Но если времени нет – то хватит и общего адеквата и понимания окружения проекта. Чаще всего организационная структура разрабатывается на этапе планирования и включается в план. Однако хорошая практика для сложных проектов или для проектов с большим количеством рисков – включать примерную (пусть даже упрощенную) оргструктуру проекта в устав проекта и согласовывать в самом начале. Для построения организационной структуры проекта нужно пройти следующие шаги: Понять, кто вообще будет вовлечен в проект (снова привет анализу стейкхолдеров). Понять, достаточно ли вам будет одной орструктуры или необходимо построить несколько, и для чего вообще вы ее строите. Например, организационная структура управления проектом, которую вы будете согласовывать на уровне управляющего комитета будет отличаться от организационной структуры выполнения проекта для организации взаимодействия между командами или от организационной структуры, которую вы делаете, чтобы четко определить процесс взаимодействия с подрядчиками в этом проекте. Накидать на слайд, в visio, mindmap или в любом другом инструменте список всех участников. Определить, какую информацию помимо ролей вам необходимо видеть. Обычно это как минимум должности и подчиненность, а как максимум – уровень принимаемых решений, конкретные имена, регулярность встреч и проч. Пытаться впихнуть туда все я не рекомендую – для этого есть план коммуникаций, а картинку с оргструктурой лучше этим не перегружать. Прорисовать подчиненность/иерархию и направления коммуникации. Посмотреть на свой рисунок и учесть политические моменты. Иногда вы понимаете, что РМ со стороны Заказчика в силу каких-то объективных причин должен подчиняться вам (и вообще он не РМ, а функциональный эксперт, будем честными), или что мнение конкретного директора по качеству в этом проекте вообще никого не интересует и видеть его тут не хочется, или что в данной проектной структуре финансовый директор должен бы подчиняться ИТ-директору (потому что сильно завязано на потоки денег, и именно ИТ-директор будет говорить финансовому, в какой момент и какие суммы надо спланировать). Но надо понимать, как это будет воспринято при согласовании, каковы ваши шансы такую оргструктуру «протащить», и как она соотносится с культурой компании и существующими в ней политическими течениями. Да, после этого вы будете себя чувствовать, как тот самый кролик, но от политики никуда не денешься. «Прилично» оформить картинку, избавившись от всей лишней информации, «потерявшихся» людей и стрелок и проч. Организационная структура проекта – один из основополагающих документов и должен выглядеть прилично, чтобы его воспринимали всерьез. Показать получившуюся оргстурктуру проекта кому-нибудь, не входящему в нее, но понимающему контекст. Этот человек сможет вам подсказать, что в ней непонятно, и, возможно, обратит вниманием на какие-то логические или политические несоответствия, т.к. в процессе разработки взгляд все-таки замыливается. Согласовать построенную организационную структуру со спонсором проекта или с другими заинтересованными лицами, чем мнение неплохо бы получить до обнародования вашего шедевра. После того, как орструктура проекта согласована со спонсором – либо добавить ее в устав либо вынести на согласование на соответствующий уровень как часть плана управления проектом. Примеры организационной структуры проектаКак и для WBS – единого стандарта для разработки организационной структуры проекта нет. Главное, чтобы она была понятна, не допускала двойного толкования и помогала в работе. Ниже вы найдете примеры оргструктур с разных моих проектов. Важно! Каждая орструктура проекта разрабатывается под конкретную задачу и в разных случаях содержит разную информацию. Поэтому искать логику в примерах ниже, возможно, смысла не имеет, т.к. схемы а) понятны и однозначны только для людей, погруженных в контекст б) анонимизированы для внешней аудитории. Пример 1. Классическая организационная структура проекта, которой будет достаточно в 95% случаев Пример 2. Организационная структура проекта, выполняющегося как часть большой международной программы Пример 3. Организационная структура проекта с разделением по уровням управления и одновременно – с выделением команды Заказчика и команды ИТ Пример 4. Организационная структура выполнения проекта |