Розробнику добре працювати щогодини, але важко пояснити клієнту переваги погодинної ставки.
Які ваші аргументи щодо погодинної ставки для замовника? Як ви пояснюєте йому його переваги і як ви сперечаєтесь на "Я хочу знати точну вартість проекту"?
Відповіді:
Старий анекдот: Зборна лінія зламається, і ремонтник підводиться. Оглянувши машину, він витягує молоток, б'є машину і вона починає бігати. Бригадир магазину дивується, поки ремонтник не каже: "Це буде 500 доларів". Захоплений під охороною, бригадир відповідає: "Ви хочете стягнути плату в 500 доларів за удар машиною молотком? Моєму фінансовому директору знадобиться деталізована накладна".
Рахунок-фактура надходить поштою:
Певним чином, погодинна ставка - це спосіб контролювати витрати. Що вартує програми, яка рятує компанію від необхідності наймати штатного працівника з мінімальною заробітною платою? Загальні щорічні витрати на цю особу, включаючи заробітну плату, допомогу, відпустку, лікарняний лист, можуть сягати 20 000 доларів США. Він повинен коштувати 15 000. Якщо розчинення виявиться імпортом у базу даних, яку можна створити за 30 годин або менше, я сумніваюся, що швидкість перебігу становить 500 доларів на годину.
Клієнт може контролювати витрати протягом усього життя проекту.
Багато проектів, які мають фіксовану плату, зазвичай вимагають половини фронту. Клієнт може платити, коли йде з погодинною ставкою.
Зарядка по годині мені просто здається неправильною. Мені хочеться, щоб мене цінували за те, що знають, куди замахнутися молотком.
Погодинна ставка не приносить користі клієнту. Це приносить користь розробнику, оскільки не має значення, скільки змін вимагає замовник.
Так само, як договір з фіксованою ціною не приносить користі розробнику. Принаймні, не без змін на замовлення. :-)
У будівництві існує чіткий поділ між аналізом та дизайном (архітектура) та впровадженням (будівництво). Навіть з таким розмежуванням та інформацією про витрати на впровадження століття чи більше, будівельні проекти можуть і не перевищувати бюджет.
У комп'ютерній розробці не існує настільки чіткого поділу між аналізом, дизайном та впровадженням. Замовник не усвідомлює, що коштує змінити екран після завершення кодування, порівняно з руйнуванням стіни.
Розробник несе відповідальність за навчання свого замовника та переконання, що замовник розуміє цінність на відміну від ціни.
Основна різниця між фіксованою ціною та погодинною полягає у тому, хто бере на себе ризик. Зокрема, у цій галузі кошторис проектів є лише приблизним і може мати велику кількість невизначеності.
Тому, за фіксованою ціною, розробник повинен переконатися, що він оцінить високу, щоб покрити непередбачені труднощі. Це розумно, оскільки в більшості видів діяльності, для покриття ризику варто коштувати гроші (саме так працює страховий бізнес).
Якщо замовник достатньо довіряє розробнику, погодинна ставка дозволить клієнту заощадити гроші, якщо проект закінчується раніше, ніж зазначений високий кошторис, хоча якщо він перейде, то замовник втрачає гроші. У цьому випадку замовник покриває ризик, і в середньому заощадить гроші.
Зокрема, якщо замовник є великою компанією, а розробник - фізичною особою, замовник, ймовірно, може опинитися в кращому становищі взяти на себе ризики. Платити додаткові ставки 160 годин, швидше за все, зашкодить більшій компанії менше, ніж працювати безкоштовно додатковий місяць, це зашкодить самотньому розробнику.
Це також полегшує узгодження змін специфікацій, коли розробнику не потрібно ретельно переоцінювати кожну зміну.
Погодинна ставка приносить користь клієнту у випадках, коли існує велика ймовірність того, що він захоче додати додаткові функції вище за первісно визначені. Він також піде на користь замовнику, коли процес розробки включає роботу з третіми сторонами, і коли роль розробника може включати інші завдання, які стосуються лише дотичного завдання програмування.
Погодинна ставка дозволяє розробнику сказати "Я подбаю про це". Замість того, щоб "Це не покрито ціною, про яку ми домовились. Це буде додаткові X долари ".
У цих випадках погодинна ставка усуває необхідність постійних переговорів і може допомогти запобігти непорозумінням, що виникають внаслідок різних поглядів на те, що було спочатку домовлено.
За погодинною ставкою замовник повинен переконатися, що ви працюєте ефективно. У договорі з фіксованою ціною замовник повинен точно описати, що він хоче. Якщо замовник хоче знати точну вартість проекту, ви повинні точно знати, що потрібно будувати. Зазвичай замовник не знає, або думає, що знає, але згодом передумає.
В обох ситуаціях продавець безпілотника знайде спосіб перезарядити замовника: запропонуйте низьку ставку на фіксовану частину проекту та поповнюйте це пізніше величезними рахунками за кожну незначну зміну чи доповнення, або дозвольте найбільш компетентним людям виграти ставку. і заміни їх пізніше програмістами лайно (з тією ж погодинною ставкою) пізніше.
Якби я був замовником, я вважав за краще:
Таким чином я вільний скласти свою думку, коли йду разом, і знаю, за що я плачу.
Розгляньте так:
Наскільки вони впевнені у своїх специфікаціях? Вони справді все продумали? Що може змінитися між часом і коли продукт вийде на екран? Поясніть, що з фіксованою ціною приходить фіксована специфікація. будь-які зміни, і ціна зміниться.
Тоді я б запропонував альтернативу. Зазначають ціну та надбавку до зміни специфікації, можливо, 20%. Таким чином, замовник вже запланував бюджет у якійсь кімнаті для змін, і якщо їм все-таки вдасться виправити специфікацію, в першу чергу вони приведуть проект у бюджет!
Якщо замовник хоче керувати процесом розробки та контролювати його та / або вносити часті зміни в продукт, він може це зробити, але він повинен погодитися на погодинну / щоденну норму.