Какова правильная стратегия поддержки проекта после его сдачи?

Question

[Bynov]

Здравствуйте!
Столкнулся с проблемой выбора стратегии дальнейшей поддержки продукта. Выполняю заказ на сайт-каталог и подумал, что нужно как-то установить для заказчика цену для последующих правок (после сдачи) и, в частности, возможных багов.
Насчет правок - можно просто договариваться исходя из объема работ, а как быть с багами?
Сейчас думаю в сторону такого решения:
1. Установить определенный срок, если в этот срок заказчик нашел баг - делаю его по "гарантии".
2. Если позже срока - нужна оплата исходя из потраченных часов? Или сумма в N рублей для X часов в месяц?
Хотелось бы узнать, как решают такую проблему опытные фрилансеры и какая стратегия наиболее подходящая.

Answer 1

[Константин Нагибович]

Установить определенный срок, если в этот срок заказчик нашел баг - делаю его по "гарантии".

Поддерживаю, сам так делаю. Только надо сразу договориться, что есть баг, а что новая хотелка заказчика.

Если позже срока - нужна оплата исходя из потраченных часов? Или сумма в N рублей для X часов в месяц?

Тут надо смотреть по ситуации. Если будешь брать фикс за месяц, то тебя могут загрузить так, что в минусе останешься. Доработка с оплатой потраченных часов - хорошо, но они могут быть не регулярно. Я за вариант оплаты по фактическим часам.

Answer 2

[Андрей Б.]

1. Ставлю срок. Хотя в мире бывали случаи, что баги находят спустя N количество лет. )
2. Беру оплату по часам. Если что-то совсем простое и быстрое, делаю бесплатно.

Answer 3

[dmitriy]

1. Клиент принял сайт, все последующее в рамках тех.поддержки и доработок
2. Исправление багов осуществляется в рамках тех.поддержки сайта, тех. поддержка стоит опред. суммы в месяц, возможны разные тарифные планы
3. Доработки осуществляются платно при условии если есть тех.поддержка проекта

Answer 4

[bro-dev]

Я бесплатно правлю баги пожизненно, но нужна 100% гарантия что это моя ошибка. Для этого разворвачиваю свою последнюю версию у себя и смотрю есть ли такой баг, если есть правлю бесплатно если нет, или если нет возможности проверить то тока за бабки.

Answer 5

[Anton]

После окончания проекта Вам нужно зафиксировать текущее состояние проекта, т.е подписать документ приема-сдачи. Если проект будет развиваться дальше (Вашими силами или силами заказчика), то тут нужно сделать документ, в котором прописать все соглашения по проекту. Также в этом документе стоит описать гарантийные и не гарантийные случаи, а также случаи, когда вы отказываетесь от поддержки данного проекта (например, заказчик внес в проект что-то, что не было заложено в архитектуре, и тем самым может нарушить функционирование программы).
По поводу багов обычно практика такова: перед сдачей проекта, заказчику необходимо предоставить набор успешно пройденных функциональных тестов (и вообще замечательный вариант, если эти тесты гоняются ежедневно и есть отчетность по данным тестам (какие прошли, какие нет и почему)). Если заказчик найдет баг (а обычно так и происходит), тут главное найти причину данного бага, т.е. возможно, что какой то криворукий пользователе запустил приложение не так, или не с тем набором параметров или другое. Если вина на стороне заказчика (допустим не так запустил приложение), то это не считается багом и можно просто дать рекомендации о том, как запускать приложение.
Если же неправильно реализована логика для частных случае, то тут явный баг. Обычно для таких целей составляют смету о том, сколько уйдет времени на исправление данного бага (обычно человеко-часы). И дальше идет согласование. После согласования вы получаете количество согласованного времени и оплату.