Стоит ли разработчикам платить за баги?

Question

[AndreyKotov799]

Спорил со своим коллегой на днях - стоит ли платить разработчику за то, что он исправляет собственный баг. С одной стороны, он допустил ошибку и должен ее исправить. Непонятно за что тут должна платить компания. С другой стороны, если работать по скраму и делать скидку на "живой организм", то бывает, что написанный когда-то код для одного мог не предусмотреть другого. Невозможно все предусмотреть и написать универсальный код. В таких случаях кажется справедливым выплатить. Опытные проджекты, рассудите нас! Подскажите, справедливо ли платить за баги?

Answer 1

[Сергей Горностаев]

Не платите. Тогда все разработчики просто уйдут туда, где платят. А вы останетесь изучать теорию, объясняющую почему и как появляются баги, пока не осознаете их неизбежность.

Comments

[ThunderCat]

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

Answer 2

[VoidVolker]

Да, надо. Потому что это тоже работа: а любая работа должна быть оплачена. Не будете платить за исправление багов - разработчики просто будут растягивать разработку в несколько раз с целью отладки, написания дополнительных тестов, проверок и минимизации возможных багов. Так что платить будете все равно. Современные инструменты и методы разработки несовершенны, а программные продукты - механизмы огромной сложности и предусмотреть все возможные комбинации всех деталей для человеческого разума задача очень и очень сложная.

Comments

[Антон]

Например, ситуация. Прожект подходит с задачей и просит оценить работу. Допустим, оцениваем в 2 часа (да, можно и с запасом). Клиент оплатил 2 часа, но вышло так, что спустя N времени оказывается, что все написанное имеет какой-то изъян, который надо править и, может получится так, что его правка может быть вдвое или втрое дольше затраченного уже времени. Что делать?
Ну и понятие бага, это ошибка сделанная разработчиком или неучтенный алгоритм действий, который мог повлиять на работу написанного - это надо как то разделять. За первое - все же, это твой косяк, мне кажется, а второе - как раз случай, который не мог быть предусмотрен

[Jacen11]

Антон,

неучтенный алгоритм действий

это уже не баг, это проблема тз, того кто оформлял задачу. Не смог предусмотреть, ну значит плати

ошибка сделанная разработчиком

значит задача не сделана, как платить за не сделанное?

но это на простых задачах, если проект большой, там нужен другой подход

[Сергей Горностаев]

Антон, бага может быть допущена разработчиком, так как его квалификация не соответствовала сложности задачи, заказчику стоило нанять кого-то подороже. Бага могла быть допущена, так как постановка задачи не учитывала граничных условий бизнес-процесса, в котором разработчик не может разбираться на столько глубоко. Бага могла быть допущена из-за того, что на разработку выделили недостаточно времени, чтобы учесть и обработать все возможные проблемы. Бага могла возникнуть, так как пользователи неправильно эксплуатируют систему. Бага могла возникнуть, так как система изменялась без учёта ограничений разработанного функционала. Бага могла возникнуть из-за инфраструктурных сбоев. Бага могла возникнуть из-за интеграционных сбоев. И т.д. и т.п., я могу весь день продолжать.

[Василий Банников]

Антон, кажется тут проблема скорее кривых эстимейтов. Нужно обязательно закладывать время на тестирование, доработки, и уточнение тз.

Answer 3

[aleks-th]

У меня примерно так:
1. Если задание выполнено строго по ТЗ и принято - любой вновь найденый баг - это уже новая работа которая должна быть оплачена.
2. Если задание не выполнено по ТЗ и баги при приемке не принимать - то это ошибка разработчика, пусть исправит.
---
3. ТЗ должно быть составлено так чтобы не могло быть двойного трактования - если ТЗ позволяет трактовать задачу размыто и компания может предполагать одно, а исполнитель другое - ошибка того кто дал это задание разработчику - соответственно это не проблема разработчика, он не знает что у вас в голове и работа по переделке будет оплачена.
---

А вообще никаких общих правил не существует - как договоритесь так и будет.

Answer 4

[Saboteur]

Спорил со своим коллегой на днях - стоит ли платить разработчику за то, что он исправляет собственный баг.

Приведите пример багов ;)
Выясните по какой причине возник баг.
Может выясниться, что баг возник по вашей вине как руководителя, который не смог выставить четкое ТЗ, в котором нет двумысленностей.
Может выясниться, что баг возник по вине архитектора, который не предусмотрел совместимость каких-либо компонентов.
Может выясниться,что баг возник по вине аналитика, который писал описание фичи

Большинство багов, которые допускают сами разработчики - фиксятся разработчиками еще на этапе компиляции и юнит тестов. А большинство багов, которые проходят дальше - допускают те, кто описывают задачу в джире.

Ну и не платить за работу - останетесь без разработчиков.

Answer 5

[Ross Alex]

Если вы под "багом" подразумеваете то, что четко описано в ТЗ и не выполнено, то нет, платить не должны. Но если вы подразумеваете под "багом" что-то вроде "так это же очевидно, что оно должно так работать", но не описали в ТЗ, то да! Это будет не баг со стороны программиста, а баг со стороны вас, как ПМ-а. Ибо, что не сказано, то есть ложь! Если вы не удосужились описать четкий функционал, что должно вводится, что должно получиться на выходе, как это должно работать, то не ждите "очевидных" для вас решений, так как все, что очевидно для вас, не очевидно для других.

Answer 6

[DollyPapper]

Надеюсь никогда не попаду в компанию, где вы являетесь ПМом :) Без обид, ничего личного, но даже возникновение мысли об этом поспорить уже абсурд. Сначала заказчик/начальник хочет чтобы функционал был сделан еще вчера, а на архитектуру, практики кодирования мы положим ботл, а потом у них возникают вопросы откуда баги. Ну вот оттуда и баги. Производство ПО это такое же производство как и любое другое производство. Если бы мы говорили про автомобильную индустрию, то на сколько бы вам хотелось ездить на машине которую сделали за вечер потому что сроки горят, конкуренты нас обходят? Мне вот тоже не хотелось бы. По этому в любом другом производстве уже давно выстроены процессы, есть отделы тестирования качества и прочие вещи, которые позволяют уменьшить/исключить брак. И только в ИТ почему то до сих пор является нормальным забить болт на все практики производства и потом спрашивать за баги с разработчика. Когда у вас появится формальное описание ТЗ (именно формальное, т.е. формализованное) в котором просто не может иносказаний одного и того же пункта, когда у вас появится опытный архитектор который будет довольно долго планировать архитектуру проекта, когда у вас появится нормальная процедура тестирования специально обучеными людьми и у вас все равно будут баги, тогда можно и задуматься, а стоит ли платить разработчику за баги, ведь теперь у меня есть все условия для того, чтобы багов не было. А до тех пор советую на эту кривую дорожку не вставать. Вот простой пример, рассудите сами:
Есть некоторый код который использует некоторую библиотеку. В библиотеке есть баг который всплыл у вас на проде. Разработчик в этом виноват? Может он виноват в том, что выбрал не качественную библиотеку? А у вас выстроен формальный процесс верификации запчастей из который состоит ваш проект? А у разработчиков библиотеки хорошие процессы разработки были? Это ведь тоже программный код который так же кто-то разрабатывал.

Answer 7

[Николай Савельев]

Разработчику оплачивается время работы.
Если он работает в определённое время, то оно должно быть оплачено.
Задача, выполняемая разработчиком, может быть принята, либо не принята. Если не принята, то она не оплачивается.
Процесс принятия работы - это отдельная тема.
Всё это прописывается в трудовом договоре, детки.

Comments

[Crash]

поэтому разработчику лучше работать за фикс-прайс (зарплату, желательно белую), а не за почасовую оплату)

Answer 8

[Евгений Батькович]

Исправление багов это нормальная составляющая процесса разработки.

Answer 9

[Игорь]

Ну и + к вышенаписавшим, надо еще понимать с каким уровнем работаете.
А то может работаете(и платите) с джуниором, а требуете как с сеньора.
И да, сеньоры тоже делают ошибки и исправляют их потом, ибо всего не предусмотреть, отвлекся из-за многозадачности (с вашей же опять стороны), где-то глаз "замылился", и тд тп.

В общем это риски и закладывать их тоже нужно. В заложенные риски закладывается и оплата(в том числе и клиенту).

Answer 10

[lotse8]

Баги бывают разные. Действительно баги, и не совсем баги, и совсем не баги. Без конкретики это как обсуждать сферического коня в вакууме. По каждому отдельному случаю надо смотреть и разбираться, и по ситуации принимать решение. Т.е. работать надо.

Answer 11

[mayton2019]

Баги на проекте - это нормально. Плохо когда баг был передан в релиз. Возникает вопрос - было ли тестовое покрытие а если было то почему не заметило этот баг.

С точки зрения бизнеса - идет просто почасовая оплата за активности разработчиков. И бизнесу по большему
счету все равно как распределяется время внутри спринта. Но во власти команды разработки принять какие-то
решения которые уменьшают вероятность возникновения бага за 5 минут до релиза. С моей точки зрения
здесь модульные тесты и код-ревью полезны. Но бизнесу об этом сообщать не надо. Это внутренняя кухня
разработки и написание тестов идет просто как часть процесса разработки.

И если например сравнивать риски появления бага в релизе с одной стороны или еще +20% времени
на написание логики с тестами с другой стороны - то я выберу второй вариант. Так - спокойнее.

Так разработчик спокойно идет в пятницу пить пиво и не думает о нежданчиках или о том
что ему позвонят и дёрнут на работу.

Answer 12

[Sergey В.]

Любой труд должен быть оплачен.
Причины возникновения ошибки тоже важны. Если рассматривать причины, связанные только с разрботчиком, то скорее всего это будет:
1. Недостаток квалификации. Нормальные работодатели считают правильным повышать квалификацию путём обучения. За счёт организации, а не за счёт сотрудника;
2. Недостаточное тестирование кода. Если разработчик ограничен по времени, то проверке кода выделяется меньше времени. Если это время оплатить, то это будет сделано;

Есть и другие причины, но с разработчиком они мало связаны.

Answer 13

[Сергей Шиловский]

Когда рабочие, при ремонте моей квартиры, допускали ошибку, они её исправляли бесплатно, потому что в смете есть конкретная услуга и конкретная цена. С программистами так не работает, потому что оплачивается не результат, а затраченное время. Не хотите платить за баги, переходите на оплату за конкретный готовый продукт, но не факт что это будет дешевле.