Текущий пост, наверное, даже может стать интересен не только программистам, но и простым пользователям ПК. Я уже писал, что в современном мире программный продукт часто выходит в релиз как MVP с сопутствующими проблемами, а в развитии такого продукта есть свои сложности. Как итог – каждый первый продукт содержит то что «любят» все. И программисты и пользователи. Баги.
Баги есть всегда. Продукт, который не содержит багов – это тот который ничего не делает. Если ваш продукт хотя бы выводит строчку «Hello world» - в нем есть баги. Любые самые крупные и известные продукты, какими бы классными и надежными не были снаружи, содержат баги. Ключевые вопросы в данном случае:
1) Насколько много багов?
2) Какова их критичность и мешают ли они прохождению пользовательских сценариев?
3) Как быстро их исправляют?
Количество багов – вещь весьма относительная. Баг может быть один – но блокировать сценарий регистрации пользователя. Багов может быть много – но из-за них просто едет верстка или есть целая горсть обходных сценариев. Но вот если их сотни самой разной критичности – попахивает проблемами между экраном и креслом программиста. Истории что автоматизированные тесты помогают препятствовать возникновению новых багов – правдивы. Только вот их разработка здорово тормозит процесс разработки, и руководство может продвигать идеи нового функционала с гораздо большим рвением, чем правки багов.
Касательно критичности. Тут, наверное, больше мыслей для пользователей, не же для программистов. Существует всего 3 основных степени критичности: блокирующие, критические и основные. Фактически есть баги и ниже критичности «основной», но их рассматривать не интересно. Там даже не все могут согласиться, что это вообще баги. Если мои излияния читают люди, не связанные с разработкой, хочется сказать самое главное – если вы обнаружили баг, то сообщите о нем. Лучше через спец.форму или почту, а не звонками в тех.поддержку, но сообщите. Если вы думаете, что кто-то другой это сделает, или разработчики о нем знают - вы рискуете терпеть этот баг до скончания времен. Ну, или до поиска альтернативного продукта, в котором они тоже будут. С гарантией. Дело в том, что в процессе разработки мы не можем тестировать все возможные сценарии с любыми наборами входных данных – возможно, что баг симулируется только у вас.
Ну и, наверное, самое главное – как быстро их исправляют. Тут с сожалением должен констатировать, что баги ниже критических, скорее всего, будут жить и здравствовать. Это не значит, что их не надо исправлять. Или что о них не надо сообщать. Это значит, что они всегда были и будут. Мой учитель программирования всегда говорил что «исправление багов, это внесение новых, но более сложно симулируемых». Вообще блокирующие баги должны исправляться либо хотфиксом, либо плановым обновлением. Критические – только плановым обновлением. Только вот если продукт обновляется 5 раз в неделю – хрен вы дождетесь исправления в плановом обновлении.
Что же с этим делать, спросите? А ничего. Баги это часть программного продукта. Задача разработчика – чтобы баги не мешали клиенту пользоваться программным продуктом. Задача клиента – осознать, что в программном продукте они есть, и тут ничего не поделать, и сообщать о возникающих трудностях в работе с продуктом. В конечном счете – современная эксплуатация программного продукта (любого) – это набор компромиссов. Разработчик обещает подкидывать функционал и попутно править возникающие ошибки, а пользователь обещает терпеть до исправления. Правда как показывает практика – разработчики не часто выделают достаточно ресурсов на это направление и, в конечном счете, терпилка клиента лопается раньше, чем исправляется баг. Порой это жадность или глупость, а порой – специфика «Инди» разработки, но это тема для отдельного поста.
На этом я, пожалуй, закруглюсь. Мне остается только желать поменьше багов клиентам и получше руководство – разработчикам.
w
