Встановлення попиту для ролі

Попит ролі — це те, що потрібно роботі, визначене окремо від того, хто її виконує. Це число, яке сітка Планування ресурсів вимірює для кожного бронювання, і причина, через яку незаповнена посада з'являється як прогалина, а не відсутність чогось взагалі.

Попит встановлюється для кожної ролі, для кожного проєкту і не змінюється, коли ви призначаєте роль. Бронювання відповідає на питання хто; попит відповідає на питання скільки, а різниця між ними — це нестача, яку сітка малює для вас.

Оголошення потреб ролі

У сітці ємності кожен рядок ролі має іконку людей у правому краю. Виберіть її, щоб відкрити попит ролі.

Діалог задає три питання:

• Потрібно людей — скільки штатних одиниць вимагає роль. Цілі числа — це звичайний випадок; 0,5 означає половину тижня однієї людини, тому 2,5 — це дві повні ставки і половина.
• Потрібно з і Потрібно до — період, який охоплює попит. Якщо роль уже має попит, ці значення починаються з вже охопленого нею періоду; інакше — з поточного відображеного на екрані.

Під полями діалог вказує, чим стає ваше число: Відкритих слотів: 3 · 250% разом. Цей рядок важливий, тому що попит зберігається як один слот на штатну одиницю — 2,5 людини це три слоти — і саме ці слоти рахує сітка. Нічого не з'явиться в сітці, що діалог не назвав першим.

Виберіть Зберегти попит, і клітинки ролі оновляться: цільова лінія переміститься, і кожен тиждень, коли заброньованих людей менше за неї, відображатиметься як прогалина.

Подальше коригування попиту

Відкрийте той самий діалог для ролі, яка вже має попит, і поля будуть заповнені поточними значеннями. Змініть число, період або обидва.

При збереженні слоти, які вже є у ролі, зберігаються там, де це можливо, і коригуються, а не знищуються і відновлюються. Підвищення попиту з двох до трьох людей додає один слот; зниження з трьох до двох видаляє один. Ось чому ідентифікатори за попитом ролі залишаються стабільними протягом редагування, і чому коригування є невеликою зміною, а не великою.

Якщо існуючі слоти ролі охоплюють різні періоди — бо роль оголошували кілька разів з різними датами або її попит надійшов з імпортованого плану, — діалог повідомляє про це перед збереженням і пропонує два варіанти. Застосувати до всіх місць, типовий варіант, дає кожному слоту один період, вказаний вище. Залишити наявні періоди зберігає кожному слоту його власний період: період вище тоді стосується лише слотів, які додає збереження, а зменшення кількості спершу прибирає слоти, додані останніми.

Відкликання попиту

Встановіть Потрібно людей на 0 і збережіть. Роль перестає щось оголошувати, і її клітинки перестають повідомляти про прогалину.

Діалог попереджає перед тим, як це станеться, і попередження називає єдину річ, яку варто знати: всі, хто вже заброньований на роль, залишаються заброньованими. Відкликання попиту відкликає вимогу, а не людей. Якщо ви хотіли видалити і бронювання — видаліть їх окремо — див. Лава і чернеткові бронювання.

Чого очікувати

• Роль без оголошеного попиту вважається однією штатною одиницею. Це розумне значення за замовчуванням, а не твердження, яке ви зробили. Якщо робота справді потребує лише половини тижня, вкажіть це тут, і сітка перестане повідомляти про нестачу, яка ніколи не була реальною.
• Попит може перевищувати ємність будь-кого, навмисно. Роль може потребувати чотирьох людей; це твердження про роботу, а не про людину, тому нічого не відмовляє. Ліміт ємності застосовується до окремих осіб — див. ємність за проєктом.
• Одна роль може мати щонайбільше 20 людей на одне збереження. Понад це робота краще описується як кілька ролей, і план так легше читати.
• Дата завершення не може бути раніше дати початку, і діалог не збереже, поки це не буде виправлено.
• Попит — це не бронювання. Він ніколи не з'являється у власній ємності будь-кого і ніколи не робить когось зайнятим. Тільки реальні бронювання роблять це.
• Збереження, яке охоплює кілька ролей, — це одна зміна, а не одна на роль. Або всі оголошені ролі записуються, або жодна з них. Немає результату, де деякі ролі зафіксовано, а інші ні — збереження, яке повідомляє про проблему, залишило план рівно таким, яким він був.
• Збереження відхиляється повністю, якщо хтось інший перемістив ті самі ролі, поки у вас був відкритий редактор. Нічого не записується, тому їхня зміна не перезаписується, а ваша не застосовується наполовину. Знову відкрийте попит ролі, щоб побачити, де він зараз стоїть, і зробіть свою зміну поверх їхньої.

Хто може це зробити

Встановлення попиту вимагає ролі Затверджувач ресурсів — вужчого дозволу, ніж роль Менеджера ресурсів, яка охоплює більшу частину сітки.

Це дивує людей, тому що оголошення попиту не схоже на затвердження. Причина в тому, що попит — це твердження, а не пропозиція: сказати цьому проєкту потрібно два розробники негайно зобов'язує план до вимоги, без жодного чернеткового етапу між ними і без чийогось підтвердження пізніше. Тому він підпадає під той самий дозвіл, що і підтвердження бронювання. Пропонування та підтвердження пояснює цей поділ.

Це нещодавно змінилося. Раніше оголошення попиту було пов'язане з роллю Менеджера ресурсів. Якщо ви встановлювали попит і виявили, що більше не можете його зберегти, — ось чому: попросіть того, хто адмініструє ваш обліковий запис Flowtly, надати роль Затверджувача ресурсів. Адміністратори вже мають її.

Відкликання попиту також вимагає ролі Затверджувача, як і підвищення або зниження кількості людей, з тієї ж причини: відкликати вимогу або змінити її розмір — таке ж зобов'язання, як і оголосити її.

Переміщення або зміна розміру підтвердженого попиту також цього вимагає. Щойно попит підтверджено, зміна його кількості або періоду (Потрібно з і Потрібно до) також є роботою затверджувача. Коли кожне відкрите місце ролі підтверджено, а ви не маєте ролі Затверджувача, кількість і період заблоковано в діалозі, а причина вказана поруч: Цей попит підтверджено. Зміна його кількості або періоду потребує ролі Затверджувач ресурсів.

Попит, що все ще є чернеткою або запитом, залишається доступним для Менеджера ресурсів. Переміщення його періоду або зміна розміру коригує вимогу, до якої ще ніхто не зобов'язався, тож менеджер усе ще може це зробити. Варто знати, що перепланування — це типове редагування, коли проєкт затримується. Коли роль має і чернеткові, і підтверджені місця, діалог залишається відкритим і перевіряє кожну зміну: редагування, яке зачепило б підтверджене місце, потребує ролі Затверджувача, а редагування чернеткового місця — ні.

Діалог визначає це з того, що ви фактично ввели, а не лише з ролі. Він відкривається для будь-кого, хто може дістатися до сітки, і Зберегти попит залишається доступним, поки ваша зміна є тією, яку ви маєте право робити; він сіріє з поясненням лише тоді, коли введені значення в сукупності складають зміну, що потребує затвердження. Тому ви дізнаєтеся до того, як підтвердите редагування, а не після.

Якщо збереження відхилено, нічого не написано наполовину. Перевірка виконується до того, як будь-яка частина зміни буде надіслана, тому попит ролі ніколи не залишається частково переписаним — ви отримаєте повідомлення, і попит залишиться рівно таким, яким він був.

Читання сітки не потребує нічого більше, ніж роль Менеджера ресурсів, яка дає доступ до сторінки.

Приклади використання

• Оголосити, що проєкт потребує двох бекенд-розробників з вересня, за місяці до того, як будь-кого з них найнято.
• Перетворити роль, яка тихо читалася як недоукомплектована, на точну роль на пів ставки і прибрати хибну прогалину з плану.
• Підвищити роль з однієї до двох людей після зміни обсягу і відразу побачити, які тижні тепер у дефіциті.
• Відкликати попит на роль, яку клієнт скасував, не порушуючи людей, що все ще завершують свою роботу на ній.
• Оголосити попит на цілий квартал, потім відфільтрувати за Тільки відкриті ролі і передати результат до рекрутингу як бриф.

Пов'язані сторінки

• Планування ресурсів
• Ємність за проєктом
• Лава і чернеткові бронювання
• Посади
• Проєкти