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

Редакція Flowtly4 min

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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