Примеры из практики для типичных ситуаций планирования¶

Эта статья описывает четыре типичные ситуации применения Rillsoft Project и поясняет, какое планирование, настройки и представления особенно важны в каждой из них.

Небольшая команда: прямой подход к планированию¶

Ситуация: проект с 5–15 участниками, чёткой зоной ответственности и обозримой структурой проекта. Большинство сотрудников работают ровно над одним проектом. Учёт отпусков и отсутствий ведётся по простой таблице или по договорённости.

Рекомендуемый подход:

Для небольших команд прямой подход к планированию без предварительной балансировки мощностей часто достаточен:

1. Создайте проект, добавьте подпроекты и работы.

2. Задайте связи и проверьте критический путь.

3. Назначьте сотрудников работам напрямую (без предварительного назначения ролей).

4. Проверьте загрузку сотрудников в представлении персонала.

5. Сохраните базовый план и ведите прогресс.

Какие представления помогают:

• диаграмма Ганта — для календарного планирования и назначения работ;

• представление персонала — для контроля загрузки;

• диаграмма Ганта по персоналу — для отображения динамики назначений сотрудников во времени.

Рекомендация по пулу ресурсов:

Для небольших команд достаточно простого пула ресурсов с сотрудниками, календарём и небольшим числом ролей. Integration Server не нужен; файлового режима работы достаточно.

Когда прямой подход достигает предела:

• сотрудники начинают одновременно планироваться в нескольких проектах;

• перегрузки возникают регулярно и неожиданно;

• становится важным планирование по квалификациям (кто что может выполнять?);

• отпускные дни нужно надёжно учитывать при балансировке мощностей.

С этого момента оправдан подход на основе квалификаций с балансировкой мощностей. Подробнее: Проведение балансировки мощностей

Несколько параллельных проектов: управляем конкуренцией за ресурсы¶

Ситуация: одновременно выполняется 3–15 проектов, использующих один и тот же пул сотрудников. Руководители проектов видят только свой проект; централизованное управление ресурсами отсутствует или трудоёмко. Дефицит возникает из-за двойных назначений, которые обнаруживаются слишком поздно.

Рекомендуемый подход:

1. Настройте общий пул ресурсов и ведите его централизованно.

2. Сначала планируйте работы по ролям (профессиональным квалификациям) — не сразу по именам сотрудников.

3. Регулярно анализируйте балансировку мощностей персонала по проектам: какой проект сильнее всего задействует ту или иную квалификацию?

4. Настройте портфель: объедините все активные проекты в портфеле.

5. Проверяйте загрузку по ролям в каждом проекте прежде, чем назначения сотрудников станут окончательными.

Управление портфелем:

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

• какая квалификация станет узким местом в следующем квартале?

• какие проекты могут пострадать при отсутствии сотрудника?

• какие сотрудники запланированы более чем в двух проектах?

Ключевые представления для многопроектной работы:

• балансировка мощностей персонала по проектам (Представления мощностей: варианты и дополнительные диаграммы);

• загрузка по ролям в каждом проекте (Ресурсные представления: варианты и области применения);

• персонал по проектам (выявление двойных назначений);

• представления ресурсов, сгруппированные по Проект > Роль > Сотрудник.

Без Integration Server:

Несколько проектов можно вести в файловом режиме через сводный проект или как отдельные файлы с общим пулом ресурсов. Это работает для 3–8 проектов с 1–3 планировщиками. При большем числе проектов или планировщиков рекомендуется Integration Server.

С Integration Server:

Централизованное хранение данных, многопользовательский режим и межпроектные связи. Подробнее: Углублённое многопроектное планирование

Дефицитная квалификация: управляем нехваткой ресурса¶

Ситуация: определённая профессиональная квалификация в компании редка (например, инженер по сертификации, специалист по CAD, сварщик со специальным допуском). Несколько проектов одновременно нуждаются в этой квалификации. Быстро увеличить мощность невозможно.

Цель: сделать дефицит видимым, принять обоснованные решения и адаптировать календарный план к реальной ситуации с мощностями.

Шаг 1: сделать дефицит видимым

1. Планируйте работы с дефицитной квалификацией целенаправленно через роли.

2. Откройте балансировку мощностей персонала: дефицит отображается как недогрузка/перегрузка в строке квалификации.

3. Проверьте балансировку мощностей персонала по проектам: какой проект и когда сильнее всего задействует эту квалификацию?

Шаг 2: определить приоритеты

Без решения о приоритетах дефицит не устранить. Согласуйте с руководством проекта или PMO:

• какой проект имеет приоритет по этой квалификации?

• какие проекты могут подождать без угрозы критическим срокам?

• есть ли временные альтернативы (поддержка со стороны ролей со схожей квалификацией, внешний ресурс, обучение)?

Шаг 3: скорректировать календарный план и назначения

После решения о приоритетах:

• сдвиньте по времени работы низкоприоритетных проектов, пока дефицитная квалификация снова не станет доступна;

• заново проверьте межпроектную балансировку мощностей;

• сделайте назначения сотрудников окончательными в соответствии с приоритетом.

Шаг 4: контролировать дефицит

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

• еженедельно проверяйте дефицитную квалификацию при балансировке мощностей;

• сразу проверяйте новые назначения на влияние на дефицит;

• регулярно сообщайте об изменениях в плане проекта и их влиянии на дефицит.

Качество пула ресурсов:

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

Серверная и облачная эксплуатация: выбираем режим работы¶

Ситуация: компания растёт, либо растут требования к совместному планированию, централизованным правам или доступу через веб. Возникает вопрос: файлы Standalone, Integration Server on-premises или Cloud?

Три режима работы в сравнении:

Рекомендации по выбору:

Выбирайте Standalone, если:

• работает один руководитель проекта или небольшая команда без централизованной координации;

• нет требований к веб-доступу, учёту рабочего времени или централизованным правам;

• решающее значение имеет быстрое внедрение без затрат на ИТ.

Выбирайте Integration Server on-premises, если:

• несколько руководителей проектов планируют совместно и используют один пул ресурсов;

• требуется разграничение прав, журнал изменений или СУД;

• организация эксплуатирует собственные серверы и важен суверенитет над данными;

• нужны веб-функции: учёт рабочего времени, планирование отпусков и временная шкала.

Выбирайте Cloud, если:

• нет собственной ИТ-инфраструктуры или она нежелательна;

• планировщики и сотрудники работают из разных мест или удалённо;

• решающее значение имеют быстрое развёртывание и масштабируемость.

Переход от Standalone к серверной эксплуатации:

Переход от Standalone к Integration Server технически возможен, но требует подготовки:

1. Централизуйте и приведите в порядок пул ресурсов.

2. Смоделируйте структуру каталогов и концепцию прав, прежде чем переносить проекты.

3. Создайте пользователей и определите роли.

4. Переносите проекты в центральное хранилище поэтапно — не все сразу.

5. Держите период параллельной работы (локально + сервер) как можно короче, чтобы избежать рассогласования данных.

Подробнее о настройке сервера: Настройка интеграционного сервера

Смежные темы¶

• Интеграционный сервер

• Настройка интеграционного сервера

• Углублённое многопроектное планирование

• Лучшие практики для Rillsoft Project

• Проведение балансировки мощностей

• Портфель проектов и многопроектное управление

примеры внедрения, сценарии использования, практический опыт, многопроектное планирование, несколько проектов, портфолио, портфель проектов, свободный проект, pmo, executive-management