Про погодинну модель

[toxi]

Воно справді важливе та актуальне, тому поділимося власною практикою.

Почнемо з головного: якщо ви не хочете з самого початку зіпсувати відносини із замовником і перевести їх у площину постійних суперечок — ніколи не виставляйте йому рахунок у годинах (за поодинокими винятками).

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

Однак тут є нюанси. Якщо спочатку виконання завдання займало дві години, а після набуття досвіду - одну, чи потрібно знижувати вартість?

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

І певною мірою він матиме рацію. Виставляючи рахунок у годинах, ви фактично декларуєте, що продаєте не послугу з визначеним кінцевим результатом (який і є предметом оплати), а свій робочий час.

А якщо виставлено час - його потрібно відпрацювати. Або ж коригувати очікування відповідно до фактично витрачених годин.

Ми неодноразово стикалися з конфліктами, коли інтегратор за технічним завданням оцінював обсяг робіт у 200–250 годин, виконував їх силами одного спеціаліста протягом місяця, після чого замовник відмовлявся оплачувати рахунок і обґрунтовано цікавився, як це фізично можливо. Чи працював спеціаліст безперервно? Чи були залучені додаткові ресурси?

Можливо, замовник і не зовсім правий. Адже в нашій галузі «година» давно перестала бути фізичною астрономічною годиною. Це радше усереднена галузева метрика: умовно, спеціаліст середньої кваліфікації виконає цю задачу за одну годину. Тоді як провідний експерт витратить на неї лише 15 хвилин.

Можна, звісно, підвищити погодинну ставку, але це може відлякати замовника. У результаті оцінка починає підганятися під бажаний фінансовий результат: часові межі формуються виходячи із «середньої години по ринку», щоб забезпечити необхідну економічну доцільність проєкту.

Тому за жодних обставин не виставляйте замовнику години як предмет оплати. Ні в кошторисі, ні в технічному завданні, ні в договорі.

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

Але назовні ви маєте продавати послугу.

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

І вже не має значення, скільки часу ви витратили на її реалізацію. Обіцяли виконати за тиждень, а впоралися за три дні — це лише підтверджує ваш професіоналізм. Вартість при цьому не змінюється. Замовник сплачує за результат.

Оптимізували процес і тепер виконуєте роботу за годину замість двох? Чудово. Ваша ефективність зросла, прибутковість не зменшилась, і жодних додаткових запитань не виникає.

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

Єдині випадки, коли виставлення годин є логічним і виправданим - це роботи або послуги, безпосередньо прив’язані до часу.

Наприклад, проведення навчання для співробітників замовника. Узгодили дві години: одна - лекція, одна - відповіді на запитання. Якщо фактично навчання тривало три години - у рахунку зазначаються три години. У такій ситуації це прозоро та обґрунтовано.

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