#УправлениеПроектами #Теория #Содержание
Всем привет!
Продолжаем серию из 10-ти дневных постов о проектных областях знаний. Перечень областей знаний есть в прошлом посте 👆🏻а сегодня собственно о Содержании - будет покороче, чем по интеграцию, чтобы вас сильно не грузить))) наверняка вы сейчас гуляете по городу, пьете глинтвейн или проводите время с семьей))))
Поехали 🚀🚀🚀
Итак, основная задача управления содержанием - определить то, что вы будете делать в проекте, задать границы проекта (это называется scope проекта) и четко соблюдать обозначенные границы.
В традиционных ИТ проектах в эту область могут входить такие активности как обследование бизнес -процессов, разработка методологических документов, подготовка технического задания для проведения тендера и далее создание прототипов.
В digital проектах могут проводиться UX/UI исследования, в agile проектах - составляться user stories и прочее
🆘Очень важный аспект в этой области : собрать верные требования, явные и скрытые. но для этого важно грамотно определить заинтересованы стороны. Очень часто встречается следующая история: ИТ систему внедрили, а она "не летит", потому что конечных пользователей никто не спросил о том, как им будет удобно работать. Или ещё из классики: начать рассказывать пользователям про новую систему перед запуском - люди первый раз об этом слышат и начинают "раздувать" границы проекта дополнительными хотелками.
Вот тут вернемся на шаг назад и поговорим о том, как работать с новыми требованиями, как их ограничивать и как расаознать то, что действительно нужно. Перед тем, как начать собирать требования, определи, какие вообще требования ты будешь собирать, по каким критериям они будут утверждены, а какие - отклонены. Требования Обязательно должны соответствовать цели проекта. Все это можно описать в плане управления проектом (см прошлый пост про интеграцию).
Давай на примере?
если основная цель вашего проекта - повысить продажи в интернет магазине, вряд ли вы должны брать в работу требования менеджеров по продажам по улучшению интерфейса их рабочего стола и скорее всего наиболее полезным будут UX/UI исследования.
Следующая история - это подготовка ИСР - иерархическая структура работ. В agile проектах обычно представляет собой набор пользовательских историй.
🌟 важно : ИСР - это все то, что вы будете делать в проекте - визуализация границ проекта. Может быть в виде канбан-доски, большого ватмана, доски со стикерами.
🗂Группировка работ может быть по этапам проекта / по функциональным характеристикам/ по ключевым заинтересованными. Основная ценность в том, что команда проекта и любые заинтересованные стороны могут подойти к доске и посмотреть, что мы делаем в объёме проекта, а чего не делаем.
И теперь давайте подведем итог в виде последовательности действий:
1️⃣ определяем, какие требования будем собирать - пишем это в плане управления проектом
2️⃣ выбираем способ сбора требований (обследование, анкетирование, интервью, опросы, дизайн -мышление, мозговой штурм, отображение данных, экспертная оценка и др) + выбираем тех, с кем их будем собирать
3️⃣ проводим сбор требований, фиксируем в виде документов + составляем визуальную ИСР, проверяем на соответствие целям и задачам проекта. Обязательно обсуждаем с командой - создаём единое информационное пространство
4️⃣ утверждаем список требований с заказчиком
5️⃣ переходим к составлению расписания, но об этом завтра))
Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут
Как всегда, если есть вопросы - буду рада ответить 👇
Перейти к описанию следующей области управления проектами. Управление расписанием
Всем привет!
Продолжаем серию из 10-ти дневных постов о проектных областях знаний. Перечень областей знаний есть в прошлом посте 👆🏻а сегодня собственно о Содержании - будет покороче, чем по интеграцию, чтобы вас сильно не грузить))) наверняка вы сейчас гуляете по городу, пьете глинтвейн или проводите время с семьей))))
Поехали 🚀🚀🚀
Итак, основная задача управления содержанием - определить то, что вы будете делать в проекте, задать границы проекта (это называется scope проекта) и четко соблюдать обозначенные границы.
В традиционных ИТ проектах в эту область могут входить такие активности как обследование бизнес -процессов, разработка методологических документов, подготовка технического задания для проведения тендера и далее создание прототипов.
В digital проектах могут проводиться UX/UI исследования, в agile проектах - составляться user stories и прочее
🆘Очень важный аспект в этой области : собрать верные требования, явные и скрытые. но для этого важно грамотно определить заинтересованы стороны. Очень часто встречается следующая история: ИТ систему внедрили, а она "не летит", потому что конечных пользователей никто не спросил о том, как им будет удобно работать. Или ещё из классики: начать рассказывать пользователям про новую систему перед запуском - люди первый раз об этом слышат и начинают "раздувать" границы проекта дополнительными хотелками.
Вот тут вернемся на шаг назад и поговорим о том, как работать с новыми требованиями, как их ограничивать и как расаознать то, что действительно нужно. Перед тем, как начать собирать требования, определи, какие вообще требования ты будешь собирать, по каким критериям они будут утверждены, а какие - отклонены. Требования Обязательно должны соответствовать цели проекта. Все это можно описать в плане управления проектом (см прошлый пост про интеграцию).
Давай на примере?
если основная цель вашего проекта - повысить продажи в интернет магазине, вряд ли вы должны брать в работу требования менеджеров по продажам по улучшению интерфейса их рабочего стола и скорее всего наиболее полезным будут UX/UI исследования.
Следующая история - это подготовка ИСР - иерархическая структура работ. В agile проектах обычно представляет собой набор пользовательских историй.
🌟 важно : ИСР - это все то, что вы будете делать в проекте - визуализация границ проекта. Может быть в виде канбан-доски, большого ватмана, доски со стикерами.
🗂Группировка работ может быть по этапам проекта / по функциональным характеристикам/ по ключевым заинтересованными. Основная ценность в том, что команда проекта и любые заинтересованные стороны могут подойти к доске и посмотреть, что мы делаем в объёме проекта, а чего не делаем.
И теперь давайте подведем итог в виде последовательности действий:
1️⃣ определяем, какие требования будем собирать - пишем это в плане управления проектом
2️⃣ выбираем способ сбора требований (обследование, анкетирование, интервью, опросы, дизайн -мышление, мозговой штурм, отображение данных, экспертная оценка и др) + выбираем тех, с кем их будем собирать
3️⃣ проводим сбор требований, фиксируем в виде документов + составляем визуальную ИСР, проверяем на соответствие целям и задачам проекта. Обязательно обсуждаем с командой - создаём единое информационное пространство
4️⃣ утверждаем список требований с заказчиком
5️⃣ переходим к составлению расписания, но об этом завтра))
Все эти вопросы мы подробно разбираем на курсе Основы управления проектами, узнать , когда будет следующий поток или приобрести записи, можно тут
Как всегда, если есть вопросы - буду рада ответить 👇
Перейти к описанию следующей области управления проектами. Управление расписанием