Хто повинен платити за виправлення / помилки? [зачинено]

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

Який найкращий спосіб вирішити виправлення на нібито прийнятій і завершеній роботі?

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

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

Це залежить.

У першу чергу слід заплатити, оскільки можна стверджувати, що робота не завершена.

Пізніше клієнт повинен платити за постійну підтримку.

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

Вам справді потрібно встановити ці речі до того, як ви поставите роботу, але якщо ви цього не зробили, можливо, зараз час так сказати - "Я підтримаю це безкоштовно протягом наступних N днів / тижнів, але після цього ми потрібно обговорити контракт на підтримку »(відзначте мій акцент на« ми »).

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

Усі наведені вище відповіді хороші. Однак я додам кілька пунктів, які слід врахувати:

• Чи цінний для вас клієнт? Іноді варто пройти зайвих кількох ярдів, щоб підтримувати клієнта щасливим, якщо ти вважаєш, що вони цінні для тебе і принесуть тобі більше роботи в майбутньому. Вам потрібно знайти баланс між суворістю та гнучкістю, і це може відрізнятися для кожного клієнта. Не втрачайте майбутньої роботи лише тому, що ви впевнені, що помилка, яку легко виправити, випадає із сфери застосування. З іншого боку, ви не хочете, щоб клієнт ходив по вас. Це тонкий баланс!

• Чи є помилка чимось, що можна було б пропустити при тестуванні користувача? Наприклад, візьміть помилку, пов’язану з датою, яка починає грати лише тоді, коли введено певний рік (подумайте про помилку тисячоліття тощо). Клієнт не міг очікувати, що він помітить це під час тестування, тому на них слід виправити це.

Коли я працював на фрілансінгу, в моїй базовій угоді з клієнтом було визначено умову під назвою "прийняття", яка була необхідна перед тим, як я представив проект на публіку. На момент прийняття почався 30-денний період, який я закликав "підтримувати та підтримувати підтримку". Після цього 30-денного періоду поточна робота над проектом була підлягає оплаті щогодини.

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

Як правило, ви можете отримати безкоштовну підтримку протягом фіксованої кількості днів після доставки заявки. Безумовно, безкоштовна підтримка протягом життя не можлива / неприйнятна.

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

Якщо він перевірив його і підписав, ви можете стверджувати, що він повинен платити.

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

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

Ви могли процитувати плату за підтримку на передній план як додаткову частину до початкової роботи з розробки.

У своєму договорі вкажіть погодинну ставку та слідкуйте за своїм часом. Коли ви даєте клієнтові ціну, уточніть, що це приблизна оцінка, а фактичний результат може бути меншим або більшим.

Слідкуйте за тим, щоб клієнт був у курсі про прогрес, і коли він неминуче вносить пропозиції, ви можете просто сказати йому час, який вам знадобиться (якщо зміна не відповідає оригінальним специфікаціям), і він може вирішити, чи варто зміна коштувати грошей. Тому будуть додані лише важливі для нього зміни.

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

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

Крім того, клієнт, який не прийме це застереження, швидше за все, поганий клієнт.