Баг vs feature request

levgem — 06.12.2023

Вынесу из поста во вконтакте: https://vk.com/wall707819804_6275 краткое про баги или фичереквесты.

Людям, не погружавшимся в проблематику, кажется что баг очень легко отличается от фичреквеста: баг — это когда не работает, как надо, а фичреквест — это не работало никогда, но хочется чтобы работало.

Так вот неприятная новость: это так далеко не всегда работает, сейчас покажу где оно работает, а где нет.

Как оно может быть?

Существуют сервисные организации, это организации, которые за клиента решают его задачу, сами подбирая средства и удерживая у себя знания для этого. Эти организации примерно представляют, сколько нужно ресурсов и как именно (т.е. есть знания) для решения каждой задачи. Россети знают, сколько нужно денег чтобы построить для вашей майнинговой фермы АЭС, проложить для неё кабели и приблизительно захеджировать риск вашего прогорания, вам надо просто оставить заявку на гигаваттное подключение. Это типичный фичереквест.

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

Аналогичным образом живет аутсорс, который по рукам и ногам связаны бумажками, которые превращают их в галеру, извлекающую лишь легкую наценку между зарплатой гребца и его отпускной стоимостью заказчику. Там даже термин существует: «заказчик», т.е. тот кто заказывает и определяет вектор движения. Заказчик является продактом, в аутсорсной организации нет продактов, потому что аутсорс всегда получает свои деньги от заказчика (даже если иногда пытаются продавать продакта на аутсорс, что мне кажется странным).

Т.е. баг наверное отделим от фичереквеста тогда, когда существуют относительно понятные критерии этого бага и есть понятные финансово договорные обязательства: за баг платит одна сторона, за фичереквесты другая.

В теории оно так, на практике даже близко нет. Взаимная грызня мозгов на тему: «вы тут напихали багов, сами оплачивайте их починку» — это непродуктивно и не работает. На практике софт взлетает с парой сотен критических багов, все из которых признаются как «с этим нельзя жить», а тот который вылизывают дочиста попросту не взлетает (давайте без набивших оскомину примеров про АЭС или самолеты, я готов это обсуждать с теми, кто реально сидел на кошельке такого проекта и отвечал за него своим будущим, а таких среди моих подписчиков нет).

Как оно на самом деле?

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

Дальше штука какая: если у тех, кто принимает обращение есть все средства и знания для решения и они работают в организации, которая ориентирована на решение задач клиента, то это отрабатывается и даже багом не называется. Никто не говорит, что рассыпавшийся жесткий диск — это баг. Это просто ситуация, её надо отработать по скрипту. Оттуда и берется фирменное ITSM-овское «на каждый алерт должен быть готовый скрипт по отработке алерта».

Но есть организации типа нашей, которые занимаются созданием средств. Мы за клиента жесткие диски у него в датацентре не меняем, мы создаем новый софт, т.е. средства.

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

Пример: наш сервер выдает http 500 на попытке экспорта архива, который был сформирован так: сначала писалось только видео, потом включили микрофон и был звук pcma, потом включили транскодер, аудио и видео поменялись местами и дорожка стала уже aac.

HTTP 500 вроде бы признак «бага», но тут ситуация другая. Баг тут или фича — это исключительно эмоциональная оценка клиента, но реальность такова: получив такое обращение, надо провести анализ:

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

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

Этот пример хорош тем, что для него нет простого понятного решения даже в сервисной/аутсорсной организации. Эта ситуация по всем параметрам выглядит как баг, но требует проработки вплоть до поездки в Китай выбирать правильные камеры клиенту.

У вас этот функционал заявлен!

Меня очень раздражает слово функционал, я коллегам обещаю привести настоящего функционала или, что гораздо страшнее, заставить объяснить за стабилизирующий функционал. В словаре Даля возможность программы называется «функциональность».

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

На собеседовании мне рассказывают о ситуации, когда инженер поддержки сам принимает решение о том, куда отправить обращение клиента: баг в разработку а фичереквест продакту на основании знаний в поддержке.

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

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

Выводы

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

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

Сохранено