@AndreyKotov799

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

Спорил со своим коллегой на днях - стоит ли платить разработчику за то, что он исправляет собственный баг. С одной стороны, он допустил ошибку и должен ее исправить. Непонятно за что тут должна платить компания. С другой стороны, если работать по скраму и делать скидку на "живой организм", то бывает, что написанный когда-то код для одного мог не предусмотреть другого. Невозможно все предусмотреть и написать универсальный код. В таких случаях кажется справедливым выплатить. Опытные проджекты, рассудите нас! Подскажите, справедливо ли платить за баги?
  • Вопрос задан
  • 860 просмотров
Пригласить эксперта
Ответы на вопрос 13
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
Не платите. Тогда все разработчики просто уйдут туда, где платят. А вы останетесь изучать теорию, объясняющую почему и как появляются баги, пока не осознаете их неизбежность.
Ответ написан
VoidVolker
@VoidVolker
Dark side eye. А у нас печеньки! А у вас?
Да, надо. Потому что это тоже работа: а любая работа должна быть оплачена. Не будете платить за исправление багов - разработчики просто будут растягивать разработку в несколько раз с целью отладки, написания дополнительных тестов, проверок и минимизации возможных багов. Так что платить будете все равно. Современные инструменты и методы разработки несовершенны, а программные продукты - механизмы огромной сложности и предусмотреть все возможные комбинации всех деталей для человеческого разума задача очень и очень сложная.
Ответ написан
@aleks-th
У меня примерно так:
1. Если задание выполнено строго по ТЗ и принято - любой вновь найденый баг - это уже новая работа которая должна быть оплачена.
2. Если задание не выполнено по ТЗ и баги при приемке не принимать - то это ошибка разработчика, пусть исправит.
---
3. ТЗ должно быть составлено так чтобы не могло быть двойного трактования - если ТЗ позволяет трактовать задачу размыто и компания может предполагать одно, а исполнитель другое - ошибка того кто дал это задание разработчику - соответственно это не проблема разработчика, он не знает что у вас в голове и работа по переделке будет оплачена.
---

А вообще никаких общих правил не существует - как договоритесь так и будет.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev
software engineer
Спорил со своим коллегой на днях - стоит ли платить разработчику за то, что он исправляет собственный баг.


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

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

Ну и не платить за работу - останетесь без разработчиков.
Ответ написан
Комментировать
Wacdis
@Wacdis
PHP, Python, GO, Rust, NodeJS, SOA/MSA
Если вы под "багом" подразумеваете то, что четко описано в ТЗ и не выполнено, то нет, платить не должны. Но если вы подразумеваете под "багом" что-то вроде "так это же очевидно, что оно должно так работать", но не описали в ТЗ, то да! Это будет не баг со стороны программиста, а баг со стороны вас, как ПМ-а. Ибо, что не сказано, то есть ложь! Если вы не удосужились описать четкий функционал, что должно вводится, что должно получиться на выходе, как это должно работать, то не ждите "очевидных" для вас решений, так как все, что очевидно для вас, не очевидно для других.
Ответ написан
Комментировать
DollyPapper
@DollyPapper
Надеюсь никогда не попаду в компанию, где вы являетесь ПМом :) Без обид, ничего личного, но даже возникновение мысли об этом поспорить уже абсурд. Сначала заказчик/начальник хочет чтобы функционал был сделан еще вчера, а на архитектуру, практики кодирования мы положим ботл, а потом у них возникают вопросы откуда баги. Ну вот оттуда и баги. Производство ПО это такое же производство как и любое другое производство. Если бы мы говорили про автомобильную индустрию, то на сколько бы вам хотелось ездить на машине которую сделали за вечер потому что сроки горят, конкуренты нас обходят? Мне вот тоже не хотелось бы. По этому в любом другом производстве уже давно выстроены процессы, есть отделы тестирования качества и прочие вещи, которые позволяют уменьшить/исключить брак. И только в ИТ почему то до сих пор является нормальным забить болт на все практики производства и потом спрашивать за баги с разработчика. Когда у вас появится формальное описание ТЗ (именно формальное, т.е. формализованное) в котором просто не может иносказаний одного и того же пункта, когда у вас появится опытный архитектор который будет довольно долго планировать архитектуру проекта, когда у вас появится нормальная процедура тестирования специально обучеными людьми и у вас все равно будут баги, тогда можно и задуматься, а стоит ли платить разработчику за баги, ведь теперь у меня есть все условия для того, чтобы багов не было. А до тех пор советую на эту кривую дорожку не вставать. Вот простой пример, рассудите сами:
Есть некоторый код который использует некоторую библиотеку. В библиотеке есть баг который всплыл у вас на проде. Разработчик в этом виноват? Может он виноват в том, что выбрал не качественную библиотеку? А у вас выстроен формальный процесс верификации запчастей из который состоит ваш проект? А у разработчиков библиотеки хорошие процессы разработки были? Это ведь тоже программный код который так же кто-то разрабатывал.
Ответ написан
Комментировать
AgentSmith
@AgentSmith
Это мой правильный ответ на твой вопрос
Разработчику оплачивается время работы.
Если он работает в определённое время, то оно должно быть оплачено.
Задача, выполняемая разработчиком, может быть принята, либо не принята. Если не принята, то она не оплачивается.
Процесс принятия работы - это отдельная тема.
Всё это прописывается в трудовом договоре, детки.
Ответ написан
Исправление багов это нормальная составляющая процесса разработки.
Ответ написан
Комментировать
GigaLORDex
@GigaLORDex
Бизнес-Системный аналитик
Ну и + к вышенаписавшим, надо еще понимать с каким уровнем работаете.
А то может работаете(и платите) с джуниором, а требуете как с сеньора.
И да, сеньоры тоже делают ошибки и исправляют их потом, ибо всего не предусмотреть, отвлекся из-за многозадачности (с вашей же опять стороны), где-то глаз "замылился", и тд тп.

В общем это риски и закладывать их тоже нужно. В заложенные риски закладывается и оплата(в том числе и клиенту).
Ответ написан
Комментировать
@lotse8
Баги бывают разные. Действительно баги, и не совсем баги, и совсем не баги. Без конкретики это как обсуждать сферического коня в вакууме. По каждому отдельному случаю надо смотреть и разбираться, и по ситуации принимать решение. Т.е. работать надо.
Ответ написан
Комментировать
mayton2019
@mayton2019
Bigdata Engineer
Баги на проекте - это нормально. Плохо когда баг был передан в релиз. Возникает вопрос - было ли тестовое покрытие а если было то почему не заметило этот баг.

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

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

Так разработчик спокойно идет в пятницу пить пиво и не думает о нежданчиках или о том
что ему позвонят и дёрнут на работу.
Ответ написан
Комментировать
BasiC2k
@BasiC2k
.NET developer (open to job offers)
Любой труд должен быть оплачен.
Причины возникновения ошибки тоже важны. Если рассматривать причины, связанные только с разрботчиком, то скорее всего это будет:
1. Недостаток квалификации. Нормальные работодатели считают правильным повышать квалификацию путём обучения. За счёт организации, а не за счёт сотрудника;
2. Недостаточное тестирование кода. Если разработчик ограничен по времени, то проверке кода выделяется меньше времени. Если это время оплатить, то это будет сделано;

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы