Друзья, задался таким вопросом: кто платит за ошибки разработчика на проекте?
Классическая ситуация: разработчик сдал задачу. Ее протестировал заказчик и принял. Но в последствии возникают ошибки, которые нельзя отнеси на договор сопровождения и приходится признавать ошибками.
Собственно, опрос: как на вашей практике обрабатываются такие ситуации? Возвращаются ли задачи исходному разработчику? Делает ли он это сверх рабочего времени, либо эти затраты принимаются как оплачиваемое время?
Классическая ситуация: разработчик сдал задачу. Ее протестировал заказчик и принял. Но в последствии возникают ошибки, которые нельзя отнеси на договор сопровождения и приходится признавать ошибками.
Собственно, опрос: как на вашей практике обрабатываются такие ситуации? Возвращаются ли задачи исходному разработчику? Делает ли он это сверх рабочего времени, либо эти затраты принимаются как оплачиваемое время?
По теме из базы знаний
- Хроники хаотичного ведения учета и как не стоит внедрять проекты
- От стажера до эксперта: развиваем команду разработчиков
- Как найти подходящего кандидата на должность "Разработчик 1С?"
- Опыт руководителя проекта со стороны заказчика. Ищем баланс. Достигаем результата
- Импортозамещение. Перевод промышленного предприятия с M3 Infor на 1С:ERP за 2 месяца по технологии SCRUM
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
По умолчанию после подписания акта приёмки исполнитель вам ничего не должен, если иное отдельно не оговорено в договоре.
На практике, в договоре выделяют такие этапы как внедрение и послепродажное сопровождение. Но справедливости ради стоит отметить, что платить будет всё равно заказчик, потому что исполнитель включит в прайс расширенный период постпродажного сопровождения. Единственное чего может добиться в этом заказчик - это обязательства исполнителя реагировать на обращения заказчика и сроки этой реакции. Т.е. снизить риск ситуации, когда после подписания акта исполнитель "сплывает".
Пример сути договора. разделы которые имеет смысл раскрыть в плане ответственности и графика. Т.е. кто что делает, и как это соотносится с графиком.:
1. Формулирование требований, разработка проекта, документации, согласование проекта.
2. Разработка беты и тестирование.
3. Релиз и внедрение
4. Гарантированное сопровождение после продажи (с целью окончательной шлифовки, доводки и исправления скрытых багов). Обязательно оговорить время реакции на обращение и отразить нормативы исправления ошибок в зависимости от их категорий:
а). Если ошибка приводит к остановке работы предприятия, то она имеет высший приоритет и её исправление должно измеряться в минутах/часах (в зависимости от чувствительности бизнеса).
б). Если ошибка создаёт неудобства одному конкретному пользователю, то её исправление может растянуться на дни/недели.
в). Внедрение новых фич не меняющих архитектуру приложения, по согласованию сторон.
5. Сопровождение по желанию. Т.е. сопровождение в режиме обычной штатной работы. Здесь можно в принципе заключить рамочное соглашение о намерениях, а условия сопровождения оформлять отдельным договором. Потому, что сильно будет зависеть от специфики внедряемого ПО (или его изменений).
На практике, в договоре выделяют такие этапы как внедрение и послепродажное сопровождение. Но справедливости ради стоит отметить, что платить будет всё равно заказчик, потому что исполнитель включит в прайс расширенный период постпродажного сопровождения. Единственное чего может добиться в этом заказчик - это обязательства исполнителя реагировать на обращения заказчика и сроки этой реакции. Т.е. снизить риск ситуации, когда после подписания акта исполнитель "сплывает".
Пример сути договора. разделы которые имеет смысл раскрыть в плане ответственности и графика. Т.е. кто что делает, и как это соотносится с графиком.:
1. Формулирование требований, разработка проекта, документации, согласование проекта.
2. Разработка беты и тестирование.
3. Релиз и внедрение
4. Гарантированное сопровождение после продажи (с целью окончательной шлифовки, доводки и исправления скрытых багов). Обязательно оговорить время реакции на обращение и отразить нормативы исправления ошибок в зависимости от их категорий:
а). Если ошибка приводит к остановке работы предприятия, то она имеет высший приоритет и её исправление должно измеряться в минутах/часах (в зависимости от чувствительности бизнеса).
б). Если ошибка создаёт неудобства одному конкретному пользователю, то её исправление может растянуться на дни/недели.
в). Внедрение новых фич не меняющих архитектуру приложения, по согласованию сторон.
5. Сопровождение по желанию. Т.е. сопровождение в режиме обычной штатной работы. Здесь можно в принципе заключить рамочное соглашение о намерениях, а условия сопровождения оформлять отдельным договором. Потому, что сильно будет зависеть от специфики внедряемого ПО (или его изменений).
(2) Артано,
По умолчанию после подписания акта приёмки исполнитель вам ничего не должен, если иное отдельно не оговорено в договоре.
Тогда по умолчанию получается, что после подписания ТОРГ-12 поставщик ничего не должен покупателю, даже если в товаре впоследствии обнаружились скрытые дефекты?
(3) Не стоит передёргивать и использовать неадекватные абстракции. Вместо того чтобы прочитать остальной текст, вы предпочли выдернуть одну фразу из общего контекста. Постараюсь лаконично изложить суть своего первого поста для обхода фильтра "многабукаф":
Фактически вам продали услугу по разработке, внедрению и сопровождению. И передали неисключительные права на конечный результат разработки. Если в ходе внедрения проблем не выявлено, а в стоимость оплаты не входит послепродажное сопровождение, то сложно требовать то, за что не было уплачено. Во избежание конфликтных ситуаций рекомендуется явно выделять важные моменты в договоре, а не подразумевать их.
Фактически вам продали услугу по разработке, внедрению и сопровождению. И передали неисключительные права на конечный результат разработки. Если в ходе внедрения проблем не выявлено, а в стоимость оплаты не входит послепродажное сопровождение, то сложно требовать то, за что не было уплачено. Во избежание конфликтных ситуаций рекомендуется явно выделять важные моменты в договоре, а не подразумевать их.
(5), (4), (3)
Друзья, спасибо за проявленный интерес. Но речь идет немного о другом. Речь идет примерно о том, что сказано в (3):
Сидит Василий, ведущий специалист. Работает работу. У него две задачи по проекту "тюльпаны". И тут приходит РП Петр, у которому Василий делал задачу по этапу проекта №1.3.4 Разработка Большой обработки. Время на этап закончилось, этап в общем-то уже даже и закрыт. Но выяснилась ошибка.
Так вот, вопрос: будет ли именно Василий исправлять эту ошибку? Куда отпишет свое время человек, который будет ее исправлять?
Друзья, спасибо за проявленный интерес. Но речь идет немного о другом. Речь идет примерно о том, что сказано в (3):
Сидит Василий, ведущий специалист. Работает работу. У него две задачи по проекту "тюльпаны". И тут приходит РП Петр, у которому Василий делал задачу по этапу проекта №1.3.4 Разработка Большой обработки. Время на этап закончилось, этап в общем-то уже даже и закрыт. Но выяснилась ошибка.
Так вот, вопрос: будет ли именно Василий исправлять эту ошибку? Куда отпишет свое время человек, который будет ее исправлять?
(6) WanGoff, в описанной ситуации Вася пошлет Петю, но не туда, куда обычно посылают, а к Большому Начальнику. И на словах велит передать, что у него, у Васи, есть две задачи, но если Большой Начальник велит, он их похерит и займется этим говном, а если у него в зарплату это время не запишут, он пошлет их всех уже в то самое место.
Все просто. Петя потом аккуратно запишет эту работу в счет клиенту под видом разработки оптимизации интерфейса.
Все просто. Петя потом аккуратно запишет эту работу в счет клиенту под видом разработки оптимизации интерфейса.
пара Разработчик - Руководитель в общем случае все та же пара Исполнитель - Заказчик, а значит справедливо описанное в (2).
После того как решение одобрено, протестировано и принято контролем качества претензий к разработчику быть не должно, он требуемого функционала и качества в отведенные сроки достиг.
А там еще разбираться нужно является ли вообще претензия ошибкой и ошибкой какого исполнителя, может требования плохо выяснили, может ТЗ неправильно составили, может тестирование плохо провели да и руководитель должен риски запланировать.
После того как решение одобрено, протестировано и принято контролем качества претензий к разработчику быть не должно, он требуемого функционала и качества в отведенные сроки достиг.
А там еще разбираться нужно является ли вообще претензия ошибкой и ошибкой какого исполнителя, может требования плохо выяснили, может ТЗ неправильно составили, может тестирование плохо провели да и руководитель должен риски запланировать.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот