что такое ресурсное планирование

Как организовать ресурсное планирование в Jira для больших и маленьких компаний

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

Важно, чтобы систему контроля можно было настроить по всем важным для вас параметрам, и в этом плане отлично подходит Jira. Не зря же она фактически стала стандартом в сфере IT. В Jira пользователь может настроить всё под себя, а это дает возможность использовать самые разные методики ведения задач. Если при этом пользоваться другими продуктами компании Atlassian, то можно бесшовно расширить управление задачами до реализации CI/CD и ведения документации, это тоже облегчает жизнь.

Но нам ведь важно не только удобство. В определенный момент компании приходится контролировать реальную стоимость решений, и проблема управления ресурсами и бюджетами выходит на первый план.

Малым и средним компаниям вполне хватит стандартных инструментов Jira для управления ресурсами: контроль трудозатрат «из коробки», решения Tempo для гибкого планирования и контроля, а также Big Picture и бюджетирование. Но, когда дело касается Enterprise сегмента, всё резко усложняется. Появляются дополнительные разрезы отчетности, группы проектов, различные бюджеты. Давайте постараемся найти лучшие варианты реализации ресурсного планирования в Jira, исходя из опыта, полученного нами ранее в реальных проектах.

Для начала сформулируем бизнес-проблемы и вытекающие из них требования к решению.

Бизнес-проблемы

Требования

· Невозможность реализовать единую методику управления крупными проектами с широким технологическим стеком;

· Сложность долгосрочного планирования;

· Сложность обоснования дополнительных ставок и непрозрачная загрузка текущих;

· Сложность оценки бэклога продукта;

· Затрудненный поиск ИТ-специалистов с необходимыми навыками для решения конкретных задач внутри компании.

· Наличие справочника навыков;

· Контроль фактических трудозатрат;

· Возможность календарного планирования бэклога спринта или релиза;

· Возможность прогнозировать точность планирования;

· Оценка загрузки команд:

· В разрезе компетенций;

· В разрезе продуктов и бюджетов бизнеса.

Рассмотрим эти требования более детально.

Кто есть кто и что он умеет? Справочник навыков

Чтобы грамотно распределить ресурсы, надо понимать, какой сотрудник справится с задачей лучше всего. Для этого пригодится справочник навыков. Причем недостаточно знать, что сотрудник является разработчиком, нужно понимать, на чём он пишет, с какими фреймворками знаком. То есть в идеале справочник должен быть многоуровневым. Пригодится и возможность масштабирования.

Справочник есть в Advanced Roadmaps (formerly Portfolio), хотя для больших компаний решение не подойдет – рассчитано всего на 25 команд. Или, например, облачное решение Align, но оно позволяет управлять только Scrum командами.

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

Контроль трудозатрат

На первый взгляд, весьма простая задача – оценка трудозатрат – доступна в Jira «из коробки». Но есть нюансы. Нам нужна (как минимум) возможность агрегации плановых и фактических трудозатрат разных команд. И нужно учитывать, что подходы к учету трудозатрат у команд могут различаться. Кто-то использует классические Jira worklog; кому-то удобнее отслеживать время нахождения в «рабочем» статусе; а кто-то предпочитает контролировать не время, а исполнение задач с помощью, к примеру, story point.

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

Календарное планирование

Плагинов, позволяющих планировать сроки исполнения задач на календаре, весьма много: от Gantt Chart до Team Calendar. Последний, к слову, хорошо визуализирует задачи Jira, хотя и является плагином Confluence.

Для разных методик ведения проектов оптимальными могут оказаться разные подходы к планированию и реализации различных разрезов не только ролей, но и команд/проектов. Так что нам нужно такое решение, которое позволит использовать не только краткосрочное планирование на конкретных исполнителей, но и долгосрочное планирование сотрудников с определенными навыками.

Нужно также учитывать реальную производительность сотрудников с учетом плановых отпусков.

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

Оценка загрузки команд

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

агрегировать краткосрочные данные для представления загрузки в различных разрезах для тимлидов и менеджеров;

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

визуализировать оценку потенциальной скорости развития продукта,

визуализировать обоснования решений о привлечении дополнительного бюджета при необходимости.

С этими задачами могут справиться построители отчетов или BI решения из стека компании. Например, можно использовать easyBI, если все необходимые данные будут вестись в Jira, нет необходимости в хранилище из разных систем, и логика системы не полностью переписана.

После детализации требований можно построить логическую модель системы:

А также вариант ее имплементации:

Попробуем обосновать этот вариант.

Каталог пользователей

Тут вариантов немного. Для вычисления согласующего лица в различных процессах может потребоваться информация о линейном руководителе сотрудника. При использовании LDAP для этих целей подойдет User Profile.

Справочник навыков

Основной объект Jira – issue (задача). Insight расширяет модель данных справочными объектами. Будет это CMDB, список клиентов CRM или иерархия организации – неважно. В итоге получаем встроенный механизм визуализации связей, отдельный механизм учета связанных задач и отдельный набор системных полей. Внедрять Insight исключительно ради справочника навыков я бы не стал, тем более что степень кастомизации карточки объекта Insight ниже, чем issue Jira. В целом оба варианта хороши.

Управление отпусками

Отпуска завязаны на отпускные выплаты и, как следствие – бухгалтерскую систему и ЗУП. Поэтому в Jira, как минимум, остается справочник отпусков, а как максимум – фронт заявки на отпуск. Отметим, что Jira не является мастер-системой отпусков, заявка на отпуск может делаться как типовой запрос проекта ServiceManagement или просто как задача Jira Work Management. Справочную информацию по отпускам можно получать из КХД, или же можно сделать прямую интеграцию с ЗУП.

Календарное планирование продукта

В рамках календарного планирования продукта происходит:

первичная оценка необходимого количества рабочих часов в разрезе навыков,

приоритизация бэклога продукта,

итоговое определение дедлайна.

Для фиксации оценки можно использовать плагин iDalko Table grid – он позволяет фиксировать необходимый набор компетенций в разрезе команд и навыков, при этом учитывая часы.

Приоритизация может быть сделана через сортировку требований на доске продукта по Rank (выше-раньше) или через вычисление какой-то частной формулы. В моей практике было и такое, что приоритет был f(ROI, влияние, ФИО автора) :-).

После приоритизации можно определить дедлайн (если он изначально не зафиксирован) и визуализовать сроки исполнения на диаграмме Гантта с использованием Structure.Gantt. В дальнейшем сроки могут корректироваться автоматически снизу вверх по факту планирования декомпозированных задач.

Планирование релиза

Выбор задач в релиз или спринт носит скорее методологический характер, как и нарезка детализованных задач. В работе нам более интересен вопрос детализации первичной оценки.

Во-первых, можно реализовать «вычерпывание» первичной оценки, когда при оценке конкретной задачи конкретным исполнителем учитывается первичная оценка и роль исполнителя. При этом выстраивается классическая цепочка: прогноз→план→факт. С точки зрения пользователя, это выглядит как обычный процесс эстимейта задачи. При этом мы можем не только сразу же визуализировать агрегированные затраты в разрезе команд и навыков в бизнес-задаче, но еще и зафиксировать данные для построения отчётности по точности прогнозирования. Переиспользование первичной оценки и немного Jira API c Groovy, никакой магии.

После оценки детализированных задач можно выстраивать календарные сроки задач в рамках релиза. Загрузка ресурсов подсвечивается, можно использовать авто корректировку ресурсов (с учетом связей Start-Start, End-Start и т.д.).

Ведение проектных задач

Тут нет ничего сложного. Нам нужен простой набор проектов с задачами, на которые декомпозируются бизнес-требования. Поля, процессы и типы задач в соответствии с потребностями команд. Кто-то живет по Scrum c User Story, кто-то хочет разделить задачи для разработки и задачи для аналитики. Методологически очень желательно обеспечить:

ведение бэклога продукта и релиза/спринта в Jira,

управление календарными сроками,

наличие практики оценки трудоемкости в часах,

управление справочниками компетенций,

интеграция с системой управления отпусками.

Отчетность

В начале статьи мы говорили о «дополнительных разрезах отчетности». Что же мы можем получить для наших топ-менеджеров и PO?

1)Долгосрочное прогнозирование загрузки команды по ролям в горизонте оцененного бэклога продукта с учетом отпусков. Можно, к примеру, заранее прогнозировать рост потребностей или вовремя подкидывать новые задачи команде.

2)Точность оценки прогнозирования загрузки команды и плановая загрузка команды в горизонте релиза.

3)Точность оценки прогноз/план/факт.

4)Прозрачный Time to Market для бизнеса с детализацией до конкретных задач разработчика при необходимости.

К чему мы в итоге пришли?

Серебряную пулю мы не нашли, хотя на самом деле и не особо искали – ее просто нет. Также мы не стремились описать архитектуры конкретных решений. В этой статье мы пытались показать, что решения на платформе Atlassin (хотя они и сфокусированы больше на оперативном управлении) могут весьма гибко реализовывать управление группой продуктов или проектов. Есть множество нюансов, и их нужно учитывать при выборе конкретных решений, особенно для крупных проектов.

Источник

Ресурсный план проекта и как его разработать

Давно не было теоретических постов, давайте сегодня про ресурсное планирование поговорим, что ли.

Что такое ресурсный план

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

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

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

В самом сложном случае ресурсный план представляет собой список всех задач проекта, для каждой из которых обозначены требования к ресурсам (например, на задачу составления ТЗ нужен аналитик с опытом 3+ года в аналогичной должности, знанием строительной отрасли, высшим техническим образованием и свободным английским, объем задачи – 180 часов). Такая степень детализации имеет смысл для крупных проектов типа внедрения SAP, под которые набираются или запрашиваются у партнеров целые команды.

В жизни чаще всего встречается нечто среднее – руководитель проекта просто планирует ресурсы с привязкой к роли (разработчик, аналитик, тестировщик и т.д.) и получает их из пула ресурсов компании. И тут уже не до выбора “с опытом 3+ года именно в стройке”, кого дали – того дали.

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

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

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

Как составить ресурсный план проекта

Составление ресурсного плана проекта – это обязательный этап при составлении базового плана проекта.

Шаги:

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

Мои принципы составления ресурсного плана

Это все была теория, а вот дальше – мои личные набитые шишки в части обеспечения проектов ресурсами.

Пример ресурсного плана проекта

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

Например, так (с детализацией по задачам и, видимо, на full-time):

Или так (c наложением на календарь, но без учета процента привлечения):

Или даже так (очень крутой план, кстати, я его еще до написания поста в статье на хабре встречала):

Лично я сейчас делаю ресурсные планы только на уровне всего портфеля проектов, а не для отдельных проектов. Но когда делала – мои планы выглядели примерно так:

В зависимости от проекта мог быть указан как абстрактный ресурс, так и ФИО конкретного исполнителя.

Используете ресурсные планы в проектах? Поделитесь лайфхаками!

Источник

Ресурсное планирование. Часть 4.1. Прежде чем делать ресурсный план

Ресурсное планирование отдельно взятого проекта — большая тема, и мы её поделим на несколько частей. В первой части мы рассмотрим задачи, которые надо решить, информацию, которую надо собрать и решения, которые надо принять при подготовке к ресурсному планированию. А во второй части поговорим о том, как делать ресурсный план.

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

О чём нужно помнить, когда делаешь WBS?

Качественный скоупинг и оценка объёма работ проекта — это то, что является фундаментом хорошего ресурсного плана. В разных компаниях используют разные шаблоны для подготовки и оценки структуры работ. Хорошие шаблоны уже содержат в себе чек-листы и соответствующие закладки для оценки модулей работ.

Общие вопросы

Отдельный список по QA-части

Частенько приходилось сталкиваться с недооценкой влияния QA на качество планирования. Но ведь QA — это далеко не только функциональное тестирование. Ниже — список, который поможет не забыть некоторые важные вещи.

Глядя на этот список, у многих может возникнуть вопрос — а зачем на этом этапе работать с HWE, NFR и SVT? Можно, конечно, с этими артефактами и не работать. Но в моей практике были случаи, когда все проектные оценки сделали, распланировали все ресурсы. И вроде даже HWE и NFR были и high-level SVT-план был. Только они не были согласованы между собой. Как можно догадаться, за это пришлось заплатить не одним десятком неоплаченных человеко-часов и кучей нервов.

Какие накладные расходы нужно закладывать в ресурсный план?

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

Шаринг бойцов с другими проектами

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

Шаринг и работа с техподдержкой

Если ваш проект — долгоиграющая история и предыдущие версии уже находятся на проде, то есть большой пласт вопросов, в которых нужно ориентироваться для качественного ресурсного планирования.

Совещания и коллы

Другим видом накладных расходов является участие членов команды в совещаниях. В совещаниях. Типичная картина — на сеньёрного разработчика запланировано по 40 часов разработки в неделю, а по факту он регулярно тратит по несколько часов в день на коллы и очные совещания с командой и заказчиком. И вместо 40 часов у него на работу остаётся 30. В результате разработчик или не успевает или овертаймит или выдаёт код не самого лучшего качества.

Ещё более острая проблема, обычно, складывется у бизнес-аналитиков. С одной стороны, они, по роду своей деятельности, должны тесно работать с заказчиком. С другой стороны, бесконечные совещания у заказчика зачастую пожирают более половины общего времени BA и он не успевает детализировать требования к следующим спринтам, начинает овертаймить и/или выдавать требования не лучшего качества.

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

Как вы понимаете, и то и другое — плохо. Если в первом случае вы искуственно создаёте своей команде изначально стрессовую ситуацию и предпосылки к нескончаемым овертаймам, то во втором случае вы просто перестаёте понимать реальную структур работ.

Хорошим вариантом решения проблемы совещаний будет определение круга бойцов, которые будут регулярно участвовать в совещаниях и в явном виде заложить это LOE в оценку. Для каждого такого бойца определить предельное количество часов, которое он действительно может тратить на разработку/анализ/дизайн и в ресурсном плане использовать именно его.

Сразу решить, как управлять изменениями

Управление требованиями — отдельная большая тема, и здесь мы рассмотрим только небольшой её кусочек, связанный с ресурсным планированиям.

За более чем 20 лет работы в ИТ я не участвовал ни в одном проекте, где требования бы не менялись по сравнению с первоначальной постановкой. Требования обязательно будут меняться. И перед подготовкой ресурсного плана лучше сразу решить, кто и как будет управлять изменениями и как вы это будете отражать в ресурсном плане.

Если у вас большой проект, вы сразу согласовали с заказчиком объём возможных изменений и у вас есть CR Bucket (объём LOE, оплаченное заказчиком, которое будет потрачено на изменения) — отлично. Тогда у вас есть почти точная цифра часов, которые вы должны заранее зарезервировать под пока неизвестные задачи. В зависимости от размера этого LOE и предполагаемого потока изменений, полезно заранее решить. В любом случае, нужно ответить себе на следующие вопросы:

Подумать про методику учёта и сбор фактического времени

Ресурсный план — один из мощнейших инструментов управления проектом. Его ценность определяется, том числе, его актуальностью. Задачей руководителя проекта является не только актуализировать ресурсный план на будущие периоды, но и аккуратно собирать факт за прошедшие периоды. И если элементы, необходимые для планирования, мы уже достаточно подробно рассмотрели, то к сбору факта пока не приступали.

Факт не равен факту

Что такое факт в терминах ресурсного планирования? Это часы, которые члены команды действительно потратили за прошедший период на:

Зачем руководителю проекта нужны фактические цифры, мы уже обсуждали в предыдущих статьях. А вот как собирать факт?

Приступая к этому вопросу нужно осознавать разницу между часами для ресурсного планирования и LOE, выделенным на выполнение задачи. Например, разработчик в течение дня закрыл два бага, на каждый из которых он потратил 3 часа. В сумме он отработал по задачам 6 часов. В Jira списано 6 часов. Но заработную плату он получит за 8 часов и на проекте он отработал 8 часов за этот день. И это нормально — часы нахождения на проекте никогда не будут равны эффорту, потраченному на решение проектных задач.

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

Как собирать факт в ресурсный план?

Вариант номер 1. Целиком полагаемся на таск-трекер (например, Jira)

Вариант номер 2. Используем систему таймшитов

Вариант номер 3. Две крайности

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

Как это ни странно, у полностью ручного варианта сбора и анализа тоже есть свои преимущества. Самое главное — ручной вариант ввода факта в ресурсный план предполагает глубокое погружение руководителя проекта в работу своей команды. Минусы тоже очевидны — высокая трудоёмкость метода и применимость только на небольших проектах.

У полностью автоматизированных систем ресурсного планирования и управления проектами преимущества и недостатки прямо противоположны ручному варианту — работая в таких системах руководитель проекта может легко потерять “связь с землёй”, полагаясь на цифры из своей системы. С другой стороны, такой процесс гораздо менее трудоёмкий и применим на проектах разного размера.

Как учитывать овертаймы?

Если у вас в компании практикуется оплата овертаймов по повышенной ставке, то нужно заранее определиться по двум важным моментам:

В любом случае, хорошо, если у вас будут ответы на эти вопросы до создания ресурсного плана.

В следующей части мы наконец-то начнём создавать ресурсный план.

Источник

Ресурсное планирование. Часть 1. О чем это вообще?

Что самое ценное для IT-компании? Что является главным активом и ресурсом почти для каждой IT-компании? Вероятно, ваша команда, ваши люди, ваши человеческие ресурсы. И если если в нужный момент у вас будет недостаточное количество вашего ключевого ресурса, то вы не сможете сделать важный проект и упустите выгоду. А если у вас будет избыток ресурсов, то вы будете нести убытки, оплачивая простаивающую часть вашей команды. Ресурсное планирование — вот что многое определяет.

Тема ресурсного планирования на удивление скудно представлена и в специализированной литературе и на пространствах рунета. Предполагается, что руководители проектов и компаний сами знают, что это такое и как с этим работать. Как показывает опыт, это немного не так. Безусловно, все понимают, что платить зарплату сотруднику, который ничего не делает — это плохо. Также плохо, когда у тебя не хватает нужных ресурсов. Но этого понимания не всегда достаточно для того, чтобы наладить в компании эффективное ресурсное планирование. И что же делать? Попробую поделиться своим пониманием вопроса.

Свое понимание планирую изложить примерно так:

Что такое ресурсный план?

Для затравки приведу пример ресурсного плана:

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

Если попробовать погуглить на тему resource management/resource planning tool, то вы получите довольно внушительный список платных (в большинстве своем) и бесплатных инструментов, которые в той или иной мере помогают в решении задачи управления ресурсами. Ну а мы будем пользоваться старым добрым MS Excel.

Теперь давайте договоримся о терминах:

Так чем же люди отличаются от денег?

Для лучшего понимания сути управления ресурсами проведем аналогию с управлением финансами:

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

В мире денег, если вы возьмете в банке в долг 100 000 рублей, вы сразу же сможете их начать тратить, инвестировать и т.п. — деньги сразу же начнут работать, их не нужно учить. В мире управления ресурсами, если вы возьмете “в долг” двух разработчиков, они, как правило, не могут сразу же начать приносить пользу вашему проекту. Потому что, в отличие от денег, ценность ресурса определяется не только его квалификацией и уровнем владения тем или иным инструментом, но и знанием специфики конкретно вашего проекта. А это знание можно приобрести только находясь внутри вашего проекта, потратив определенное время на его изучение.

Именно на эту тему часто возникают споры с заказчиком, которому нужно в кратчайшие сроки реализовать ту или иную внеплановую функцию. Как правило, риторика заказчика бывает примерно такой “В вашей компании работает ХХХ десятков/сотен/тысяч людей, добавьте еще Y на проект и сделайте, что мы хотим”. Правда заказчика в том, что да, в вашей компании, как правило, действительно достаточно много квалифицированных людей, которые могли бы сделать то, что он хочет. Но он не учитывает тот факт, что для того, чтобы приступить к реализации этих требований, квалифицированным специалистам с других проектов нужно приобрести необходимые знания о вашем проекте, а на это нужно время, которого у вас нет.

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

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

Первая версия статьи была опубликована на Хабре.

О сайте

Это сайт про ресурсное планирование в software development и IT-компаниях. Здесь иногда появляются интересные статьи и заметки на тему ресурсного планирования и построения систем управления.

Источник