60 дней фильмов
и сериалов
18+
Условия подписки Плюс
Мульти: clck.ru/YMaCq
VC60
Забрать

Три смертных греха, которые испортят качество IT-продукта (или уже портят)

Привет! Меня зовут Женя, я руковожу агентством аутсорс тестирования «Кавычки». Мы занимаемся обеспечением качества для крупных российских и зарубежных компаний. В этой статье я хочу рассказать про три греха продуктовых команд, которые мешают создавать качественные IT-продукты. Окей, конечно, количество не ограничивается этой цифрой, потому что бесконечность — не предел. Но сегодня поговорим про три, да и VC не резиновый.

Почему появилась эта статья? На рынке выпускают все больше IT-решений, параллельно растет конкуренция за внимание пользователей. Никого уже не удивишь красивым интерфейсом. Пользователи ждут качество и максимальную заботу о себе. Тот, кто предоставит им лучший пользовательский опыт, будет лидировать в гонке за лояльность. Такие правила игры. Поэтому компании периодически начинают задумываться, как улучшить качество. Ну, или не начинают. Все, о чем я буду говорить дальше — это такой микс на стыке QA, UX и продуктовой аналитики. В общем то, что влияет на качество и как следствие — на лояльность пользователей. Это то, что касается каждого в продуктовой команде. Ну, поехали.

Грех 1: верить, что идеальный use case существует

Давайте честно, люди нелогичны и иррациональны. Ожидать, что они пойдут по тому пути, который вы предположили — опрометчиво. Нужно предвидеть множество пользовательских путей. И возможно, не промахнетесь. Но это не точно. Есть крутой пример, о котором писал Дейв Фельдман (бывший руководитель проектов в Google, Facebook, TechCrunch, Emu, Yahoo). Суть: от пользователей стали приходить жалобы, что приложение сломано, т.к. не приходят уведомления. Когда команда начала разбираться, поняли, что пользователи сами отключили уведомления у себя в приложении. Где логика?

А логика все-таки есть. Фельдман объясняет ее работой двух систем человеческого мозга: Система 1 и Система 2. Именно Система 1 задействована большую часть времени, она работает автоматически и быстро, основываясь на впечатлениях, эмоциях или ассоциациях. Система 2 более сложная, медленная и осмысленная. В данном случае Система 1 увидела слово «уведомления» и провела ассоциацию с чем-то негативным, поэтому пользователь отклонил их. Система 2 может даже не замечать этого или совсем смутно осознавать. Но уведомления уже отклонены.

К чему все это? Природа пользовательской логики такова, что на любом этапе взаимодействия с продуктом может возникнуть блок, который прервет цепочку действий или вообще — изменит весь пользовательский путь. Что такое блок? Это все, что мешает пользователю взаимодействовать с продуктом и совершить целевое действие (от лени, мыслей и страхов пользователя до неудобных кнопок, непонятного интерфейса и загрузки более 5 сек.). Например, это могут быть лишние формы, которые долго и лень заполнять, поэтому пользователи уходят; это может быть незаметная кнопка или фича, которая важна, но ее никто не видит.

Если речь об электронной коммерции, то тут целый букет блоков, потому что операции с финансами сильно напрягают и нервируют: «а не скам ли это?», «не украдут ли мои деньги?» и т.д. Чем сложнее продукт, тем больше у пользователя может возникнуть таких блоков. Поэтому здесь важно детально продумать возможные вариации поведения пользователей.

Вот пример блоков с финансовыми операциями. Не определяется сумма оплаты через Apple Pay и Google Pay. Пользователь просто не знает, сколько в итоге с него спишут.

Что еще вредит качеству:

  • Если мнение коллег в приоритете

Например, вы опираетесь на мнение коллег: удобный ли интерфейс; видна ли кнопка; понятно ли расположен блок. Это не значит, что ваши коллеги не разбираются. Есть вероятность, что они не смотрят на продукт критически, а это необходимо, когда нужно учитывать, как это будут видеть тысячи пользователей с разным восприятием и пользовательскими привычками. А коллеги просто из-за большой любви к вам могут сказать, что все ок, чтобы вы успокоились и пошли уже домой.

  • Если оцениваете все на позитиве

Критическая оценка и мышление — это must have для того, чтобы сделать качественный продукт. Нужно смотреть на продукт с точки зрения «что еще можно улучшить», всматриваться и искать в нем изъяны. А еще лучше — пользоваться продуктом на постоянной основе. Согласитесь, хуже, если эти изъяны найдут пользователи, которые побегут рассказывать вам об этом в Google Play или App Store, снижая рейтинг.

  • Если разбираетесь сами без привлечения специалистов

Это мой любимый пункт из серии «сами протестируем», «сами разберемся». Тестировать продукт с точки зрения богатого пользовательского опыта и насмотренности может тот, кто давно и профессионально этим занимается. Как вы поняли, вариаций поведения — много, поэтому качество во многом будет зависеть от того, какой специалист помогает на этапе разработки и тестирует ваш продукт.

Идеального use case не существует просто потому, что пользователи — живые люди с кучей мыслей и привычек. И это нужно учитывать.

Грех 2: не думать о своих пользователях

Если вы хотите создать успешный продукт для людей, то вам нужно их понять. Понимание своих пользователей закладывается на этапе идеи и разработки. Это история не только про удобный интерфейс, но и про функциональную начинку — а нужна ли эта фича, зайдет ли она пользователю, зачем она пользователю.

Пример фильтра в интернет-магазине. Выбрать мороженое можно только по весу. Даже не по вкусу или бренду. По весу. Зачем?

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

Например, существует метод персонажей. Это профиль будущих пользователей: кто они; как они взаимодействуют с продуктом; что им важно; какие у них привычки и т.д. Из этого складывается карта пользовательского поведения, которая помогает понять, как добиться высокого качества и сделать максимально удобный продукт для пользователей.

Что еще влияет:

  • Пользовательские привычки и паттерны поведения
  1. Важно тестировать гипотезы, как пользователи будут взаимодействовать с продуктом. А для этого нужно разбираться в моделях поведения каждой группы пользователей.
  2. С привычками есть очень интересная история — иногда они существуют даже на подсознательном уровне. Например, схема «далее-далее-далее-готово». Это пришло еще из лихих 90х (вспомните установку Winamp или др. прог). Такие программы приучили нас нажимать «далее», особо не вчитываясь в суть написанного в окне. И точно так же мы реагируем на всплывающие окна: не так важно, что там написано — главное: «закройся и не мешай!».

Почему это важно? Если вам нужно, чтобы пользователь что-то выбрал или прочитал (прям прочитал) — то нужно выделить это/обратить внимание, иначе он все пропустит, по привычке жмакая «далее», пока не дойдет до кнопки «готово».

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

Есть, конечно, привычки неизменно любимые всеми. Легендарная борьба за стену в VK — «Дуров, верни стену». Другой пример, когда Microsoft избавились от кнопки «Пуск» в Windows 8, это вызвало возмущение пользователей. Реакция была настолько суровой, что Microsoft восстановили кнопку «Пуск» в Windows 8.1, хотя и не то, что было.

  • Пользовательские особенности
  1. Здесь необходимо учитывать много характеристик: от демографических особенностей до индивидуальных. Например, если это платформа для детей с играми и набором очков, то нужно понимать, что в семье может быть несколько детей, поэтому для каждого ребенка должна быть возможность сделать персонализированный игровой аккаунт с индивидуальным набором баллов.
  2. Существует куча полезных прог, которые помогают учитывать индивидуальные особенности, например, Funkify — расширение для Chrome, которое позволяет разработчику взглянуть на веб с точки зрения людей с ограниченными возможностями.

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

Но с багами тоже лучше не косячить.

Грех 3: тестировать как попало

А теперь любимое — тестирование и QA, которыми так часто пренебрегают или уделяют недостаточно внимания. Давайте начистоту: вам не нужно QA и тестирование, если у вас нет пользователей или вы ничего не делаете. Во всех остальных случаях, скорее всего, вам нужно.

Как может выглядеть тестирование в команде, или кто тестирует:

  • Разработчики

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

Плюсы:

  1. Экономия бюджета на тестировщиках;
  2. Экономия времени на дополнительном тестировании;
  3. Погруженность разработчика в специфику продукта.

Минусы:

  1. Дополнительная нагрузка на разработчиков;
  2. Вероятность некачественного тестирования. Для качественного тестирования у разработчика должны быть навыки в тестировании и понимание логики поведения пользователей;
  3. Необъективная оценка. Здесь влияет сразу несколько факторов: разработчик знает, как все должно работать, и это мешает смотреть на продукт глазами пользователей, которые не знают как устроена программа. И второе, создателю тяжело критически смотреть на свое творение, что тоже влияет на объективность.
  • Штатный тестировщик или команда QA

В команде может быть как один/несколько тестеров, так и по харду — целая QA-команда.

Плюсы:

  1. Погруженность в специфику проекта;
  2. Минимизация рисков в качестве IT-продукта;
  3. Распределенная нагрузка команды. Каждый сфокусирован на своей задаче;
  4. Сработанная команда. Все уже знают друг друга и умеют работать вместе — не нужно выстраивать процессы (но это не точно).

Минусы:

  1. Уровень загрузки и з/п. Часто руководители не понимают, за что платить штатным тестерам. На одном продукте у них, обычно, не так много задач, отсюда и складывается впечатление, что они ничего не делают. Хотя это не так.
  2. Узкий кругозор. Не хочу обидеть коллег, но, как правило, если тестеры сидят на одном продукте, то заточены под него, соответственно их багаж знаний ограничен. Если прилетит задача с другим видом тестирования — могут возникнуть проблемы, потому что нет опыта и навыков.
  • Тестировщик или QA-команда на аутсорсе

Тут много вариантов: один или несколько тестеров, целая команда с QA-лидом или QA-лид в команду штатных тестеров. Тестировщики могут быть как отдельной проектной командой, так и работать со штатными тестерами, если расширился продукт или необходима дополнительная помощь.

Плюсы:

  1. Большой бэкграунд. Аутсорс команды работают с разными проектами и повидали в этой жизни если не все, то многое. У них широкий кругозор и сильные скиллы в тестировании.
  2. Дешевле, чем штатный тестировщик. Штатному товарищу вы обязаны выплачивать ежемесячную оплату, независимо от того, сколько он и чего сделал. С аутсорс командой работа идет проектно или по часовой оплате.

Минусы:

  1. Время на погружение в специфику продукта. Возможно, им понадобится больше времени, чтобы изучить продукт — все зависит от подготовки QA-команды;
  2. Некачественное исполнение/проблемный поставщик;
  3. Разногласия с командой разработки. Эта проблема бывает и у штатных тестировщиков. Здесь все зависит от опыта и soft skills.

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

Коротко о главном

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

!function(e){var o={};function t(n){if(o[n])return o[n].exports;var r=o[n]={i:n,l:!1,exports:{}};return e[n].call(r.exports,r,r.exports,t),r.l=!0,r.exports}t.m=e,t.c=o,t.d=function(e,o,n){t.o(e,o)||Object.defineProperty(e,o,{enumerable:!0,get:n})},t.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},t.t=function(e,o){if(1&o&&(e=t(e)),8&o)return e;if(4&o&&"object"==typeof e&&e&&e.__esModule)return e;var n=Object.create(null);if(t.r(n),Object.defineProperty(n,"default",{enumerable:!0,value:e}),2&o&&"string"!=typeof e)for(var r in e)t.d(n,r,function(o){return e[o]}.bind(null,r));return n},t.n=function(e){var o=e&&e.__esModule?function(){return e.default}:function(){return e};return t.d(o,"a",o),o},t.o=function(e,o){return Object.prototype.hasOwnProperty.call(e,o)},t.p="",t(t.s=0)}([function(e,o,t){"use strict";t.r(o);const n=e=>{if("object"==typeof Air){Air.import("module.ajaxify").one("Before page changed",()=>{e&&e()})}};((e="teaser",o=[],t="vc")=>{const r={root:e,index:e+"--index",entry:e+"--entry",loaded:e+"--loaded",location:e+"--%location%",sitename:`${e}--${window.__codename||t}`},a=document.querySelector("."+r.root),i=document.querySelector('[air-module="module.feed"]');if(a){a.classList.add(r.sitename),-1===r.location.indexOf("location")&&a.classList.add(r.location),i?a.classList.add(r.index):a.classList.add(r.entry);const e=()=>{a.classList.add(r.loaded)};return new Promise(t=>{var i;(i=o,Promise.all(i.map((function(e){return new Promise((function(o){var t=document.createElement("img");t.onload=()=>{o(t)},t.onerror=o,t.src=e}))})))).then(()=>{t({showBanner:e,oneBeforePageChange:n,rootHTML:a,css:r,siteName:window.__codename})})})}})("kpsk-footer",["https://leonardo.osnova.io/db4d29e8-6b05-57c9-a668-8be251b5999f/","https://leonardo.osnova.io/4bc540c7-94c3-523d-a568-289bb3048c90/","https://leonardo.osnova.io/f9b0fdc7-0122-5954-86d2-a9c7b69464e5/","https://leonardo.osnova.io/b955990b-dbc0-5bf5-b6b4-d580e1ae8174/"]).then(e=>{e.showBanner()})}]);
0
5 комментариев
Популярные
По порядку
Ольга Норд

Спасибо за полезный материал!

Ответить
2
Развернуть ветку
Аполлон Степанов

Примитивная статья, описанная со стороны разработчика. Со всем уважением.

С учётом того, что Российское ИТ всего 3% в мире, а крупных ИТ решений практически нет, то не удивительно, что пишутся такие примитивные статьи.

Ответить
–1
Развернуть ветку
Шизоидная обезьяна

Российское ИТ всего 3% в мире

С какого года подсчет?

Ответить
0
Развернуть ветку
Аполлон Степанов

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

Ответить
–1
Развернуть ветку
Евгений Пономаренко

Так, с этим понятно. Вы правы. Но может стоит сходить в статью про разработку и туда вставить комментарий?

Ответить
0
Развернуть ветку
Читать все 5 комментариев
OZON заблокировал аккаунт и отказывается объяснять причину

Ничего не предвещало беды. Как это обычно и бывает, я пришел в ПВЗ, чтобы забрать свой заказ, достал телефон, чтобы назвать сотруднику номер заказа, и столкнулся с проблемой: меня выкинуло из аккаунта. При попытке авторизоваться по номеру телефона или по почте я получил ошибку:

Сооснователь Endel Владислав Пинский запустил в Германии сервис распознавания документов ABC Doc и привлёк €500 тысяч Статьи редакции

Сервис помогает понять смысл документов и решить, что с ними нужно делать.

Пример работы ABC Doc
Как поднять продажи фармы в диджитале? Рассказываем про стратегию продвижения бренда «Ультра-Д» и показываем результаты

В пандемию фармотрасли тоже пришлось пойти в диджитал, но из-за ограничений ей это дается сложнее, чем остальным. Как построить стратегию продвижения фармпродукта в онлайне и поднять продажи, не нарушив закон? В 2020-м мы проверили в бою собственную стратегию продвижения фармы — а теперь рассказываем, как она работает и какие дает результаты.

Голова не варит: 10+ советов, как предотвратить умственное переутомление

Наш мозг потребляет уйму энергии, но мы почему-то часто игнорируем, продолжая нагружать его новыми задачами. Как следствие — возникает умственное переутомление, и мы печально и бессильно глядим в пустоту в конце дня. Разбираемся, почему такое состояние возникает и как с ним бороться.

Благодарность команде vc.ru

Эти ребята делают наш мир лучше.

Эвакуатор для своих: бармен из Санкт-Петербурга придумал как заработать, когда закрыли общепит Статьи редакции

Он сам переоборудовал грузовик Toyota Dyna и принимает заказы от владельцев автосервисов и знакомых автомобилистов.

Платформу для эвакуатора варили из металла вручную
Почему начинающим предпринимателям стоит выходить на маркетплейсы

Торговые онлайн-площадки готовы сотрудничать с бизнесом любого размера.

В OTUS стартует первый онлайн-буткемп «Java developer»
Праздник к нам приходит: когда заказывать подарки за рубежом

Ещё в ноябре для логистических компаний начинается горячий сезон, который продолжается до марта. 11 ноября — большая распродажа AliExpress, а сразу после неё — Чёрная пятница, плавно перетекающая в подготовку к Новому году, 14 и 23 февраля, и, наконец, к 8 марта. В это время Почта и другие логистические службы по всему миру доставляют особенно…

Пользователи Авито спасли от вырубки леса равные по площади территории Карелии и сэкономили электроэнергию близкую годов

Как деятельность Авито влияет на сокращение загрязнения окружающей среды? Перепродажа наиболее вредных с точки зрения производства товаров помогла пользователям Авито за 2020 год совместно сэкономить более 1,3 миллиарда кг различных материалов, 267 млн ГДж энергии и 123 млн м3 воды.

null