Я работаю в организации, в которой “без багов” - это девиз. Развитие каждого разработчика руководители видят только в одном: он не должен делать багов, только так мы получим бизнес пользу от него. Давайте обсудим, почему это заранее проигрышная стратегия.

Ship wreck by Guido Giardino

Со стороны сотрудника

Не ошибается тот, кто ничего не делает.

Может быть философское, ненаучное утверждение, но, к счастью, я еще не встречал людей, которые, делая свою работу, не ошибаются. Программист, создавая продукт, будет создавать и ошибки. Во многом потому, что до него такой продукт еще никто не создавал, во многом потому, что он решает сложную инженерную задачу, во многом потому, что он работает не один, а в команде. Вы можете сказать: “Пиши тесты на свой софт - и багов не будет!” - однако это заблуждение. Программист не сможет написать всеобъемлющие тесты, потому что он наверняка заранее не узнает, как будет использоваться его софт. Так или иначе, останутся дыры.

Что будет делать человек, которому руководство сказало “не ошибайся, иначе не получишь повышения”? Правильно, скрывать свои ошибки от руководства. У программиста есть множество инструментов это сделать. Например, договориться с тестировщиком, если он найдет баг, то не оформлять тикет, а в личном сообщении об этом написать. Еще можно найти стрелочника и доказать, что этот баг сделал он. Еще можно доказать, что ошибка была изначально в задании. Все, что угодно. Конечно, это нечестно, но если статистика для такого программиста покажет, что он делает меньше багов и повышение будет - значит инженер все сделал правильно, а система была выстроена ошибочно.

Со стороны руководителя

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

Что я имею ввиду под “решать проблему”? Для начала разберемся, почему решили делать меньше багов. Очень просто: есть продукт, им пользуются клиенты, клиенты жалуются, что много ошибок и неправильного поведения. Как повысить удовлетворенность клиента? Очевидно же: нужно, чтобы было меньше ошибок в продукте. Когда продукт будет содержать меньше ошибок? Только тогда, когда каждый разработчик будет делать меньше ошибок. Отлично! Значит “без ошибок” - наш девиз! Вот такой прямой и поверхностной логикой можно прийти к ошибочному утверждению, и поставить это утверждение вектором развития компании. Найти способ повысить удовлетворенность клиента - сложная задача. И мы уже поняли, что она, к сожалению, в компании, где я работаю, решается контрпродуктивными методами.

Решение

Взглянем на исследование, которое провели в компании IBM. Если коротко, там проанализировали информацию о поддержке 8 продуктов и выяснилось, что удовлетворенность клиента не зависит от количества ошибок в продукте. Зависит удовлетворенность клиента от скорости решения проблем, которые мешают ему выполнять свою работу, от удобства использования софта. Чувствуете разницу? Вместо того, чтобы исправлять ошибки (что, конечно же, нужно делать), продуктивнее будет сделать возможность быстрого решения проблем и повысить удобство использования продукта. И это не чьи-то предположения, это исследование.

Продукт должен заботиться о своем клиенте

Далее. Если у вас MacOS, вы наверняка используете homebrew для установки недостающих пакетов. Автор этой программы говорит о том, что homebrew стал невероятно успешным потому, что “Он [homebrew] заботится о вас”, потому что если что-то пошло не так при установке пакета, то программа изо всех сил старается помочь решить проблему. Видите? Разработчик этой программы сократил время на решение проблем клиента, и его программа стала популярной и успешной. К тому же он утверждает, что homebrew написан ужасно и там полно ошибок. Но, как мы уже поняли, это не важно. Потому что в первую очередь продукт должен заботиться о своем клиенте.

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