Запит на зміни (CR) — це те, як скоуп легально рухається після підписання: короткий документ, що фіксує, що саме змінюється, чому, вплив на ціну й строки та підпис людини, уповноваженої витрачати гроші клієнта. На fixed-price роботі це головний захист маржі — додатковий скоуп без CR за визначенням є безплатною роботою. На time and materials він захищає радше довіру: години й так білабельні, але бюджетне очікування в голові клієнта саме собою не посунеться — CR скидає його до того, як це зробить інвойс.
Що змушує механізм працювати в компанії на 10–50 людей:
- Шаблон на одну сторінку — важчий папір гарантує, що його обходитимуть.
- Піднімається одразу — тієї миті, коли «а можете ще…» прозвучало у дзвінку, а не наприкінці місяця, коли години вже витрачені.
- Ціна до початку роботи. CR після делівері — це прохання, а не переговори.
- Жодних усних погоджень. Email зі словом «approved» достатньо; кивок у дзвінку — ні.
Культурна половина складніша за папір: інженери кажуть «так» на дрібні прохання з ввічливості, а двадцять ввічливих «так» — це тиждень неоплаченої роботи. Звичка, яку треба натренувати: «залюбки — проведу це через нашого делівері-менеджера як запит на зміни».
У Helia немає модуля контрактного воркфлоу — затверджена зміна лягає правками в живий план: дати призначення, години на тиждень чи перекриття ставки для конкретної людини на проєкті, і наступний згенерований інвойс автоматично розцінюється за оновленими значеннями.