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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Пользовательские привычки и паттерны поведения

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

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

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

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

• Пользовательские особенности

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

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

А теперь любимое — тестирование и 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 всегда несет риски аукнуться письмами «любви» от клиентов или запахом горящих стульев из отдела службы поддержки. Заботьтесь о своих пользователях, старайтесь сделать для них лучший и удобный продукт. Именно такие продукты завоевывают сердца и рынки. А для этого надо быть внимательнее к качеству, не экономить на проверке и думать о своих пользователях.