Все мы случайно или в результате ошибки, бывает, создаем баги в процессе разработки, так ведь? Мне еще не встречался программист, который бы от начала и до конца не допускал никаких оплошностей.
Как говорит нам Википедия, под багом понимается ошибка в программе или в системе, из-за которой программа выдает неожиданное поведение и, как следствие, результат. Институт системных наук IBM, со своей стороны, сообщает, что исправление ошибки после релиза отнимает в четыре-пять раз больше ресурсов, чем если бы она была замечена на стадии проектирования. Если же ошибка обнаружена уже на стадии поддержки проекта, расходы могут возрасти в сотню раз
Но эта статья не о том, как баги могут негативно повлиять на бизнес, а о том, как один мой коллега ухитрился создать баг и извлечь из этого пользу. Неплохая история в арсенале разработчика – по невнимательности прописать что-то не то в коде и получить за это лавры. К сожалению, это случилось не со мной.
Перейдем к подробностям. Прежде чем говорить о баге, вероятно, нужно дать вам представление о проекте, над которым мы работали. Мы делали CRM (Customer Relationship Manager, систему управления взаимоотношениями с клиентами) для одного из своих заказчиков. Основное требование к этому ПО состояло в том, чтобы на выходе получился механизм, позволяющий выстраивать отношения с потенциальными клиентами с максимальной простотой.
Принцип работы был несложным. При необходимости сотрудники отделов маркетинга и продаж обращались к подробной информации о продукте, хранящейся в системе, и с ее помощью продвигали продукты среди своей аудитории. Так вот: одна из функций этой программы называлась «напоминание для сотрудника». Она оповещала соответствующих работников компании о том, что нужно связаться с тем или иным клиентом в определенный день и час. Как правило, это время встречи задается самим клиентом или назначается по его просьбе.
И вот что смешно. Как уже говорилось выше, изначально предполагалось, что напоминания будут рассылаться сотрудникам. Но мой коллега случайно что-то напутал, и его бэкенд-функция стала отправлять уведомления не сотрудникам, а клиентам.
Тестировщик не поймал эту ошибку в самом начале. Первым баг заметил наш начальник, и это решило исход дела. Если бы на его месте оказался любой из разработчиков, включая меня, неточность была бы немедленно исправлена, и никто не заметил бы, что эта неверная реализация гипотетически имеет свои сильные стороны.
Коллега решил проблему, однако начальник поставил вопрос перед руководством: возможно, если мы будем оповещать клиентов перед звонком, такая модель покажется им удобнее? Руководству идея понравилась. Мы отправили версию системы с «неправильной» функцией на тест и получили отличные результаты.
Оповещение потенциальных клиентов о звонке за два часа повысило вероятность ответа на тридцать с лишним процентов, а продажи – на пять процентов. Кроме того, это позволило компании-заказчику урезать расходы.
Почему так вышло? В случае если потенциальный клиент оказывался занят, он получал возможность отказаться от разговора или перенести его на другое время электронным сообщением. Иными словами, компания не тратила зря на звонок ни время, ни деньги. К тому же, людям нравилось получать оповещения. Многих раздражает, когда их неожиданно отвлекают звонками из разных компаний, а так у них, во всяком случае, появляется выбор. Расклад оказался выигрышным для обеих сторон.
Мы до сих пор вспоминаем этот случай и посмеиваемся, когда по чьей-нибудь милости возникает баг. Только не пытайтесь их создавать нарочно (да я знаю, что вы не станете). Так можно лишиться хорошей репутации, а то и работы. Но если у вас тоже случались баги с забавными и неожиданным исходами, делитесь в комментариях.
Как говорит нам Википедия, под багом понимается ошибка в программе или в системе, из-за которой программа выдает неожиданное поведение и, как следствие, результат. Институт системных наук IBM, со своей стороны, сообщает, что исправление ошибки после релиза отнимает в четыре-пять раз больше ресурсов, чем если бы она была замечена на стадии проектирования. Если же ошибка обнаружена уже на стадии поддержки проекта, расходы могут возрасти в сотню раз
Но эта статья не о том, как баги могут негативно повлиять на бизнес, а о том, как один мой коллега ухитрился создать баг и извлечь из этого пользу. Неплохая история в арсенале разработчика – по невнимательности прописать что-то не то в коде и получить за это лавры. К сожалению, это случилось не со мной.
Перейдем к подробностям. Прежде чем говорить о баге, вероятно, нужно дать вам представление о проекте, над которым мы работали. Мы делали CRM (Customer Relationship Manager, систему управления взаимоотношениями с клиентами) для одного из своих заказчиков. Основное требование к этому ПО состояло в том, чтобы на выходе получился механизм, позволяющий выстраивать отношения с потенциальными клиентами с максимальной простотой.
Принцип работы был несложным. При необходимости сотрудники отделов маркетинга и продаж обращались к подробной информации о продукте, хранящейся в системе, и с ее помощью продвигали продукты среди своей аудитории. Так вот: одна из функций этой программы называлась «напоминание для сотрудника». Она оповещала соответствующих работников компании о том, что нужно связаться с тем или иным клиентом в определенный день и час. Как правило, это время встречи задается самим клиентом или назначается по его просьбе.
И вот что смешно. Как уже говорилось выше, изначально предполагалось, что напоминания будут рассылаться сотрудникам. Но мой коллега случайно что-то напутал, и его бэкенд-функция стала отправлять уведомления не сотрудникам, а клиентам.
Тестировщик не поймал эту ошибку в самом начале. Первым баг заметил наш начальник, и это решило исход дела. Если бы на его месте оказался любой из разработчиков, включая меня, неточность была бы немедленно исправлена, и никто не заметил бы, что эта неверная реализация гипотетически имеет свои сильные стороны.
Коллега решил проблему, однако начальник поставил вопрос перед руководством: возможно, если мы будем оповещать клиентов перед звонком, такая модель покажется им удобнее? Руководству идея понравилась. Мы отправили версию системы с «неправильной» функцией на тест и получили отличные результаты.
Оповещение потенциальных клиентов о звонке за два часа повысило вероятность ответа на тридцать с лишним процентов, а продажи – на пять процентов. Кроме того, это позволило компании-заказчику урезать расходы.
Почему так вышло? В случае если потенциальный клиент оказывался занят, он получал возможность отказаться от разговора или перенести его на другое время электронным сообщением. Иными словами, компания не тратила зря на звонок ни время, ни деньги. К тому же, людям нравилось получать оповещения. Многих раздражает, когда их неожиданно отвлекают звонками из разных компаний, а так у них, во всяком случае, появляется выбор. Расклад оказался выигрышным для обеих сторон.
Мы до сих пор вспоминаем этот случай и посмеиваемся, когда по чьей-нибудь милости возникает баг. Только не пытайтесь их создавать нарочно (да я знаю, что вы не станете). Так можно лишиться хорошей репутации, а то и работы. Но если у вас тоже случались баги с забавными и неожиданным исходами, делитесь в комментариях.
