Statement of Work перетворює підписані відносини на визначену співпрацю. Звична конструкція — рамковий договір (MSA), який один раз фіксує юридичні правила гри: відповідальність, IP, конфіденційність, умови оплати, — і окремий SOW на кожну співпрацю, який описує саму роботу. Новий проєкт — новий SOW, без переузгодження юридичної рамки.
Що фіксує робочий SOW:
- Скоуп — і явні виключення. Те, що НЕ входить, важить більше за те, що входить; саме на виключеннях тихо вмирають суперечки.
- Результати з критеріями приймання — що означає «готово», хто це підтверджує і за скільки днів.
- Таймлайн і майлстоуни, якщо до них прив’язані оплата чи дедлайни.
- Команду і білінг — модель (time and materials, ретейнер, fixed price), ставки або фіксовану суму, валюту, ритм інвойсингу.
- Припущення і залежності — доступи, рішення й середовища на боці клієнта; зірване припущення — легітимний запит на зміни, а не безплатна перевитрата.
- Процедуру змін — як рухається скоуп і хто підписує.
Тест простий: якщо на модель білінгу, ставку і «що означає готово» не можна відповісти з самого SOW — він не дописаний, і делівері перевідповідатиме на ці запитання пізніше, з пам’яті, під тиском.
У Helia немає репозиторію контрактів, але картка проєкту віддзеркалює операційні факти SOW — модель білінгу, ставку чи фіксовану суму, валюту, дати, клієнта й делівері-менеджера — і саме на цих полях далі працюють плани завантаження та згенеровані інвойси, тож числа SOW і числа в інвойсах лишаються одними й тими самими.