что такое ресурсы в проекте примеры
Ресурная концепция в управлении проектами
Доброго времени суток. Хотелось бы порассуждать об одном из известных аспектов проектов — ресурсном. Предпосылка такова — если открыть, например, учебник Мазура, Шапиро, Ольдерогге «Управление проектами», то там сходу проект рассматривается как «процесс перехода из исходного состояния в конечное— результат при участии ряда ограничений и механизмов».
То есть сначала была идея (сайта, софта, оказанной услуги), затем её конкретная вещественная реализация.
Реализация, очевидно, является цепочкой преобразования одних ресурсов в другие, как и любое производство. Этот пост будет посвящен рассмотрению ИТ-проектов если не как производства, то как ряда преобразований уж точно.
Здесь и далее под ресурсом будем понимать любой объект, наличие которого необходимо для достижения результата проекта. В том числе и промежуточные артефакты проекта будут являться для него ресурсами.
Распространенные ресурсы ИТ-проектов
Сильно вдаваться в понятие ни на примерах, ни в теории нет смысла. Понятно что любой материальный или нематериальный объект (или даже одушевленный), который необходим для достижения цели, можно обозначить понятием ресурс. Как и в любой системе, важны по сути не столько сами ресурсы, сколько их взаимосвязь.
Приведу пример из игростроя: для готового результата всегда нужны и арт, и код. Код без арта написать можно, протестировать нельзя. Арт без кода нарисовать можно, но посмотреть «живьем» на общий результат арта (вижн и интерэкшн) без кода практически нельзя. Что делать? Чаще всего пишут код с заглушками из арта, который повторяет основные свойства готового, а общий вижн по арту делают на скорую руку рендерерами средств разработки арта (без всякого интерэкшна). В конце всё сливается в экстазе воедино. Тут какие дела: качество конечного результата зависит от наличия художественного воображения у программистов с одной стороны, и понимания устройства программных систем у художников. К счастью такие ресурсы можно заменить их тесным общением.
Взаимосвязь методики ведения проекта с цепочкой ресурсных преобразований
Итерационный (с таймбоксами, буду называть далее обобщенно Agile) и каскадный подходы различаются с точки зрения преобразования ресурсов в основном тем, как они обходятся со временем. В одном случае оно «нарезано» на равные куски, в каскадном нет. Итерации могут быть и там и там, весь вопрос в том, какие промежуточные результаты создает проект: в случае гибких подходов мы имеем конечный неполнофункциональный продукт на каждой итерации, в случае каскада — мы имеем отдельные функции/модули. При этом количество результатов, очевидно, разное, особенно чем короче таймбокс.
Примеры цепочек преобразований
Рассмотрим пару вариантов — B2B и B2C. Для B2B рассмотрим проект разработки что-нибудь по типу простецкого документооборотного ERP, для B2C — сайт-биржу, где посетители заказывают и покупают друг у друга услуги.
Стрелки на диаграммах отражают последовательность.
B2B «ERP» Agile
B2C «Биржа» Cascade
Если диаграммы читаются плохо из-за того что, на первый взгляд, «все связано со всем», то их можно разбивать на несколько. Но все все равно связано со всем, это неизбежно. Проекты таковы, что результаты предыдущие используются в последующих, как при возведении многоэтажки строят снизу вверх (в случае строительства — из-за проблем с гравитацией, в случае с проектами — из-за неизбежных причинно-следственных связей). Такой ресурс как «время» вообще не приведен, дабы не захламлять всё стрелками.
И да. Если (вдруг) покажется, что гибкий подход «стройнее», то за примитивностью его диаграммы скрывается отсутствие некоторых ресурсов, которые есть во второй.
Вместо заключения — управление рисками в проекте через призму ресурсной цепочки
«План без рисков — набор пожеланий, риск без плана — казино». ((с) моё).
Риск — это событие, которое отклонит показатели проекта от нужных. Риск влияет на конечный результат проекта (либо он не в срок, либо некачественный, либо за бюджет вылезли). Теперь внимательно следим за руками 🙂
Утверждение. Последовательность создания и применения ресурсов, а также наличие или отсутствие самих ресурсов в ресурсной цепочке, определяет уровень рискованности проекта.
Доказательство. Рассмотрим произвольный показатель, его риском будет возможность отклонения значения от планового. Значения показателя в некоторый момент времени есть функция задействованных до этого момента ресурсов, в конце проекта — всех ресурсов. Из этого вытекает, что изменение состава ресурсов и их последовательности приводит к изменению (графика) значений показателя. Отсюда же вытекает и то, что проектов без риска не бывает (поскольку ресурсы по факту никогда не соответствуют плановым). Само «содержание» ресурса генератором риска назвать нельзя, так как меняя его «содержание» мы меняем ресурс (например база не MS SQL Server, а Firebird — это два разных ресурса). [Конец доказательства]
Если всё вышесказанное кажется какой-то теорией, задумайтесь о том, что эта теория проявляется и в большом и в малом. Даже когда вы решаете, какую задачу из бэклога взять первой, из двух вариантов лучше тот, который потребует создания меньшего количества промежуточных ресурсов «на выброс» (заглушек и прочего). Даже если вы пытаетесь решить, что лучше — организовать внедрение в сотне рабочих мест в разных офисах на основе географического разделения, или функционального — посмотрите, какой вариант ресурсной цепочки отклонит ваши показатели от желаемых меньше (выбор зависит от выбранной пары из тройки показателей проектного треугольника).
Спасибо за то, что прочитали. Всем удачных проектов!
Ресурсное планирование. Часть 1. О чем это вообще?
Что самое ценное для IT-компании? Что является главным активом и ресурсом почти для каждой IT-компании? На что компания тратит больше всего денег? Какая статья затрат является самой большой? На обслуживание какого ресурса у вас уходит больше всего денег? Не сильно ошибусь, если скажу, что ответом на все эти вопросы является “Команда компании”. Именно ваша команда делает проекты, двигает вашу компанию вперед и зарабатывает деньги, и именно на зарплаты, бонусы, налоги, оборудование рабочих мест и прочие прямые и косвенные выплаты вашей команде приходится основная масса затрат компании.
Если в нужный момент у вас будет недостаточное количество вашего ключевого ресурса, то вы не сможете сделать важный проект и упустите выгоду. А если у вас будет избыток ресурсов, то вы будете нести убытки, оплачивая простаивающую часть вашей команды. Поговорим о ресурсном планировании.
Тема ресурсного планирования на удивление скудно представлена и в специализированной литературе и на пространствах рунета. Предполагается, что руководители проектов и компаний сами знают, что это такое и как с этим работать. Как показывает опыт, это немного не так. Безусловно, все понимают, что платить зарплату сотруднику, который ничего не делает — это плохо. Также плохо, когда у тебя не хватает нужных ресурсов. Но этого понимания не всегда достаточно для того, чтобы наладить в компании эффективное ресурсное планирование. И что же делать? Попробую поделиться своим пониманием вопроса.
Свое понимание планирую изложить примерно так:
Что такое ресурсный план?
Для затравки приведу пример ресурсного плана
На примере мы видим ресурсный план для условного проекта вместе с финансовой информацией и некоторой аналитикой. В зависимости от уровня доступа руководителя проекта и специфики внутренних процессов, ресурсный план может видоизменяться в широких пределах. В частности, убрав зарплаты и часовые ставки, можно ограничиться только планированием человеко-часов.
Если попробовать погуглить на тему resource management/resource planning tool, то вы получите довольно внушительный список платных (в большинстве своем) и бесплатных инструментов, которые в той или иной мере помогают в решении задачи управления ресурсами. Ну а мы будем пользоваться старым добрым MS Excel.
Теперь давайте договоримся о терминах:
Так чем же люди отличаются от денег?
Для лучшего понимания сути управления ресурсами проведем аналогию с управлением финансами:
Деньги | Ресурсы |
---|---|
В моменте не хватает своих денег (например, чтобы выплатить зарплату — кассовый разрыв) — занимаем в банке или у друзей. | Нужен конкретный ресурс на небольшой период времени (например, чтобы сделать срочную работу без ущерба для основного скоупа) — договариваемся “пошарить” ресурс у соседнего проекта, где ресурс недозагружен |
Есть излишек денег — кладем их в банк или инвестируем в прибыльный проект. | Разработка “заблочена” длительным согласованием требований заказчиком — отдаем людей во временное пользование проекту, где они нужнее. При этом, затраты на этот период переносятся на соседний проект, экономим бюджет своего. |
На рынке появились дешевые деньги — перекредитуемся. | На соседнем проекте освободились свои разработчики, стоимость которых ниже, чем используемый на нашем аутсорсный ресурс — делаем замену |
Этими кейсами аналогия не исчерпывается. Общая подмеченная закономерность — почти в каждом случае управления ресурсами можно найти аналогию из управления финансами и наоборот. Однако, между деньгами и ресурсами есть очень существенная разница, которая определяет специфику этой предметной области.
В мире денег, если вы возьмете в банке в долг 100 000 рублей, вы сразу же сможете их начать тратить, инвестировать и т.п. — деньги сразу же начнут работать, их не нужно учить. В мире управления ресурсами, если вы возьмете “в долг” двух разработчиков, они, как правило, не могут сразу же начать приносить пользу вашему проекту. Потому что, в отличие от денег, ценность ресурса определяется не только его квалификацией и уровнем владения тем или иным инструментом, но и знанием специфики конкретно вашего проекта. А это знание можно приобрести только находясь внутри вашего проекта, потратив определенное время на его изучение.
Именно на эту тему часто возникают споры с заказчиком, которому нужно в кратчайшие сроки реализовать ту или иную внеплановую функцию. Как правило, риторика заказчика бывает примерно такой “В вашей компании работает ХХХ десятков/сотен/тысяч людей, добавьте еще Y на проект и сделайте, что мы хотим”. Правда заказчика в том, что да, в вашей компании, как правило, действительно достаточно много квалифицированных людей, которые могли бы сделать то, что он хочет. Но он не учитывает тот факт, что для того, чтобы приступить к реализации этих требований, квалифицированным специалистам с других проектов нужно приобрести необходимые знания о вашем проекте, а на это нужно время, которого у вас нет.
Отсюда вывод — при управлении ресурсами всегда нужно помнить о том, что вновь добавленный ресурс, каким бы квалифицированным он не был, потребует определенного времени на погружение в проект и только потом начнет приносить результат. Время, которое требуется на погружение, зависит от квалификации ресурса, степени его знакомства с предметной областью и проектом, информационной инфраструктуры проекта и наличия людей рядом, которые смогут в доступной форме рассказать про проект и показать, как он устроен.
На этом с первой частью закончим. В следующей части поговорим о том, на что влияет ресурсный план и качество ресурсного планирования.
Ресурсы проекта
Смотреть на youtube || на ИНТУИТ в качестве: низком | среднем | высоком
5. Ресурсы проекта
Составление списка ресурсов
Общие правила описания ресурсов
Эффективное управление ресурсами – одно из главных достоинств Project. Оценка ресурсов плановой операции призвана определить, какие ресурсы (человеческие, оборудование или материальные средства) будут использоваться и в каком количестве, и когда каждый из ресурсов будет доступен для выполнения проектных операций.
Ресурсы – это исполнители, оборудование и материалы, необходимые для выполнения задач проекта. В Project представлено три типа ресурсов – Трудовой, Материальный, Затратный:
Тип ресурса определяет принцип учета данного ресурса в плане проекта.
В Project для ресурсов определены свойства: доступность и стоимость. Доступность определяет, когда ресурс может работать над выполнением задач проекта, стоимость – затраты, связанные с использованием данного ресурса в проекте.
Для определения рабочего времени и выходных дней ресурса, может быть создан собственный календарь ресурса.
Планирование ресурсов начинается с определения состава ресурсов.
Количество ресурсов в проекте ограничено, практически, только здравым смыслом. Максимально возможное число – 700 000 ресурсов.
Можно вводить ресурсы по мере их назначения задачам, либо использовать список ресурсов, созданный для данного проекта.
Для работы со списком ресурсов обычно используется представление Лист ресурсов.
Ввод ресурсов
Для ввода ресурсов обычно используется таблица Запись представления Лист ресурсов.
Название ресурса вводится в поле Название ресурса.
По умолчанию любому ресурсу присваивается тип Трудовой. Значение поля Тип необходимо выбрать из раскрывающегося списка.
Тип ресурса определяет принцип учета данного ресурса в плане проекта. Участие в проекте трудовых ресурсов исчисляется во временных единицах, материальных ресурсов – в количественных, поэтому после выбора типа ресурса многие поля таблицы заполняются значениями, принятыми по умолчанию (рис. 5.1).
Для установки параметров ресурса используют различные таблицы представления Лист Ресурсов. Можно также использовать комбинированное представление, при котором в нижней части окна отображается форма сведений о ресурсе. Для этого следует нажать кнопку Подробно (Отобразить сведения о ресурсе) группы Свойства вкладки Ресурс.
Для ввода и/или выбора некоторых параметров ресурса может потребоваться диалоговое окно Сведения о ресурсе, которое отображается кнопкой Сведения группы Свойства вкладки Ресурс или двойным мыши щелчком по строке ресурса.
С помощью окна Сведения о ресурсе параметры можно изменять как для отдельного ресурса, так и для нескольких одновременно выделенных.
Следует обратить внимание, что некоторые параметры ресурсов целесообразно вводить только при их назначении.
Ресурсный план проекта и как его разработать
Давно не было теоретических постов, давайте сегодня про ресурсное планирование поговорим, что ли.
Что такое ресурсный план
Ресурсный план проекта или план ресурсного обеспечения проекта – это документ, в котором зафиксировано, какие ресурсы будут использоваться в проекте, и процессы получения и возврата этих ресурсов.
Так как блог про управление проектами в ИТ, под ресурсами, конечно, в первую очередь подразумеваются люди, а во-вторую – оборудование и сопутствующие вещи, количество которых в компании ограничено.
В самом простом случае ресурсный план выглядит так – “на проекте длительностью полгода нужны 2 разработчика-мидла на джаве на полный день, один ручной тестировщик на полставки и адекватный руководитель проекта”. или даже “на этом проекте пару месяцев поработает Петя, а потом еще кого-нибудь возьмем, да и тестировать пока сами будем”. Если в вашей компании все вас при этом понимают, риски осознают и проблемы с получением этих ресурсов нет – ну и отлично, значит, эта та степень детализации, которая вам нужна.
В самом сложном случае ресурсный план представляет собой список всех задач проекта, для каждой из которых обозначены требования к ресурсам (например, на задачу составления ТЗ нужен аналитик с опытом 3+ года в аналогичной должности, знанием строительной отрасли, высшим техническим образованием и свободным английским, объем задачи – 180 часов). Такая степень детализации имеет смысл для крупных проектов типа внедрения SAP, под которые набираются или запрашиваются у партнеров целые команды.
В жизни чаще всего встречается нечто среднее – руководитель проекта просто планирует ресурсы с привязкой к роли (разработчик, аналитик, тестировщик и т.д.) и получает их из пула ресурсов компании. И тут уже не до выбора “с опытом 3+ года именно в стройке”, кого дали – того дали.
Также в зависимости от специфики компании ресурсный план может предполагать привлечение фрилансеров или сторонних подрядчиков.
Еще есть такое понятие, как календарно-ресурсный план или ресурсный план-график – как легко понять из названия, это ресурсный план, наложенный на план-график проекта. Т.е. мы уже не просто говорим, что на проекте у нас будет два разработчика, а что у нас будет два разработчика, занятых на проекте три месяца подряд с 15 августа по 15 ноября.
Важно различать ресурсный план проекта, который отвечает на вопрос “кто будет работать в конкретном проекте”, и ресурсный план отдела/компании/портфеля проектов, который отвечает на вопросы “чем будут заниматься наши сотрудники на в ближайшие полгода” и “есть ли у нас люди, чтобы начать вот эти два проекта”. В посте мы в первую очередь говорим о ресурсном плане конкретного проекта, про ресурсное планирование уровня отдела или портфеля – в следующий раз.
Как составить ресурсный план проекта
Составление ресурсного плана проекта – это обязательный этап при составлении базового плана проекта.
Шаги:
На выходе у вас и у основных стейкхолдеров должно появиться понимание того, кто будет работать в проекте, когда эти люди должны приступить к своим задачам, и когда они освободятся для других проектов. Степень формализации может быть от заметки в чате в телеграме (но лучше, чтобы это было хотя бы письмо по электронной почте) до полноценного документа на 50 страниц, утвержденного протоколом заседания управляющего комитета.
Мои принципы составления ресурсного плана
Это все была теория, а вот дальше – мои личные набитые шишки в части обеспечения проектов ресурсами.
Пример ресурсного плана проекта
Если поискать в интернете, то можно найти сотню разных вариантов того, как выглядит ресурсный план. Все примеры из Яндекса, так что за качество сорри.
Например, так (с детализацией по задачам и, видимо, на full-time):
Или так (c наложением на календарь, но без учета процента привлечения):
Или даже так (очень крутой план, кстати, я его еще до написания поста в статье на хабре встречала):
Лично я сейчас делаю ресурсные планы только на уровне всего портфеля проектов, а не для отдельных проектов. Но когда делала – мои планы выглядели примерно так:
В зависимости от проекта мог быть указан как абстрактный ресурс, так и ФИО конкретного исполнителя.
Используете ресурсные планы в проектах? Поделитесь лайфхаками!
Обучение и трудоустройство проектных менеджеров
Видео материала «Основные типы ресурсов проекта»
Основные типы ресурсов проекта как их определять и планироваться
Ниже приведенная информация является справочным материалом. Подробнее о данном материале и его практическом применении вы можете узнать, просмотрев видео.
Содержание:
Основные типы ресурсов
Выделяются пять основных группы ресурсов:
Трудовые ресурсы – это люди и оборудование, которые выполняют работу, необходимую для завершения задач проекта. Трудовые ресурсы потребляют время (в часах или в днях) для выполнения задач. Трудовые ресурсы характеризуется максимальным количеством единиц ресурса (Макс. единиц), доступным для одновременного использования в проекте. Под количеством единиц ресурса понимается количество рабочего времени ресурса. Например, если в проекте будет задействован один программист, то для соответствующего ресурса максимальное количество единиц ресурса будет равняться 100%, в случае с двумя программистами максимальное количество единиц ресурса будет равняться 200% и т.п. Если же будет задействован только один программист, который сможет уделить проекту только половину своего рабочего времени, то для такого ресурса максимальное количество единиц ресурса будет равняться 50%.
Затратные ресурсы – этот тип ресурсов позволяет описать различные пути финансирования или расхода финансовых средств проекта. Данный ресурс часто используется для описания подрядных организаций либо инвесторов проекта. Объемы финансирования указываются при назначении ресурса на работу проекта.
Денежные ресурсы – ресурсы типа Cost (Стоимость). Эти ресурсы могут назначаться на задачи проекта и имеют финансовое измерение (в денежных единицах).
Использование ресурсов при планировании проекта позволяет:
Для того чтобы адекватно определить потребности в ресурсах, необходимо учесть следующие факторы:
Информация о том, как добавлять ресурсы в план-график MS Project Professional 2013, представлена в материале «Описание ресурсов»
Определите в Вашем проекте перечень ресурсов согласно приведенным ниже данным: