Три смертных греха, которые испортят качество IT-продукта (или уже портят)
Привет! Меня зовут Женя, я руковожу агентством аутсорс тестирования «Кавычки». Мы занимаемся обеспечением качества для крупных российских и зарубежных компаний. В этой статье я хочу рассказать про три греха продуктовых команд, которые мешают создавать качественные IT-продукты. Окей, конечно, количество не ограничивается этой цифрой, потому что бесконечность — не предел. Но сегодня поговорим про три, да и VC не резиновый.
Почему появилась эта статья? На рынке выпускают все больше IT-решений, параллельно растет конкуренция за внимание пользователей. Никого уже не удивишь красивым интерфейсом. Пользователи ждут качество и максимальную заботу о себе. Тот, кто предоставит им лучший пользовательский опыт, будет лидировать в гонке за лояльность. Такие правила игры. Поэтому компании периодически начинают задумываться, как улучшить качество. Ну, или не начинают. Все, о чем я буду говорить дальше — это такой микс на стыке QA, UX и продуктовой аналитики. В общем то, что влияет на качество и как следствие — на лояльность пользователей. Это то, что касается каждого в продуктовой команде. Ну, поехали.
Грех 1: верить, что идеальный use case существует
Давайте честно, люди нелогичны и иррациональны. Ожидать, что они пойдут по тому пути, который вы предположили — опрометчиво. Нужно предвидеть множество пользовательских путей. И возможно, не промахнетесь. Но это не точно. Есть крутой пример, о котором писал Дейв Фельдман (бывший руководитель проектов в Google, Facebook, TechCrunch, Emu, Yahoo). Суть: от пользователей стали приходить жалобы, что приложение сломано, т.к. не приходят уведомления. Когда команда начала разбираться, поняли, что пользователи сами отключили уведомления у себя в приложении. Где логика?
А логика все-таки есть. Фельдман объясняет ее работой двух систем человеческого мозга: Система 1 и Система 2. Именно Система 1 задействована большую часть времени, она работает автоматически и быстро, основываясь на впечатлениях, эмоциях или ассоциациях. Система 2 более сложная, медленная и осмысленная. В данном случае Система 1 увидела слово «уведомления» и провела ассоциацию с чем-то негативным, поэтому пользователь отклонил их. Система 2 может даже не замечать этого или совсем смутно осознавать. Но уведомления уже отклонены.
К чему все это? Природа пользовательской логики такова, что на любом этапе взаимодействия с продуктом может возникнуть блок, который прервет цепочку действий или вообще — изменит весь пользовательский путь. Что такое блок? Это все, что мешает пользователю взаимодействовать с продуктом и совершить целевое действие (от лени, мыслей и страхов пользователя до неудобных кнопок, непонятного интерфейса и загрузки более 5 сек.). Например, это могут быть лишние формы, которые долго и лень заполнять, поэтому пользователи уходят; это может быть незаметная кнопка или фича, которая важна, но ее никто не видит.
Если речь об электронной коммерции, то тут целый букет блоков, потому что операции с финансами сильно напрягают и нервируют: «а не скам ли это?», «не украдут ли мои деньги?» и т.д. Чем сложнее продукт, тем больше у пользователя может возникнуть таких блоков. Поэтому здесь важно детально продумать возможные вариации поведения пользователей.
Что еще вредит качеству:
- Если мнение коллег в приоритете
Например, вы опираетесь на мнение коллег: удобный ли интерфейс; видна ли кнопка; понятно ли расположен блок. Это не значит, что ваши коллеги не разбираются. Есть вероятность, что они не смотрят на продукт критически, а это необходимо, когда нужно учитывать, как это будут видеть тысячи пользователей с разным восприятием и пользовательскими привычками. А коллеги просто из-за большой любви к вам могут сказать, что все ок, чтобы вы успокоились и пошли уже домой.
- Если оцениваете все на позитиве
Критическая оценка и мышление — это must have для того, чтобы сделать качественный продукт. Нужно смотреть на продукт с точки зрения «что еще можно улучшить», всматриваться и искать в нем изъяны. А еще лучше — пользоваться продуктом на постоянной основе. Согласитесь, хуже, если эти изъяны найдут пользователи, которые побегут рассказывать вам об этом в Google Play или App Store, снижая рейтинг.
- Если разбираетесь сами без привлечения специалистов
Это мой любимый пункт из серии «сами протестируем», «сами разберемся». Тестировать продукт с точки зрения богатого пользовательского опыта и насмотренности может тот, кто давно и профессионально этим занимается. Как вы поняли, вариаций поведения — много, поэтому качество во многом будет зависеть от того, какой специалист помогает на этапе разработки и тестирует ваш продукт.
Идеального use case не существует просто потому, что пользователи — живые люди с кучей мыслей и привычек. И это нужно учитывать.
Грех 2: не думать о своих пользователях
Если вы хотите создать успешный продукт для людей, то вам нужно их понять. Понимание своих пользователей закладывается на этапе идеи и разработки. Это история не только про удобный интерфейс, но и про функциональную начинку — а нужна ли эта фича, зайдет ли она пользователю, зачем она пользователю.
Насколько комфортно пользователю взаимодействовать с вашим сайтом или приложением — настолько высоки шансы для бизнеса заработать больше. А для этого нужно тестировать разные вариации поведения, предугадывать блоки в пользовательских путях, учитывать привычки и более того — особенности. Проводить эксперименты и делать выводы, основываясь на различных метриках.
Например, существует метод персонажей. Это профиль будущих пользователей: кто они; как они взаимодействуют с продуктом; что им важно; какие у них привычки и т.д. Из этого складывается карта пользовательского поведения, которая помогает понять, как добиться высокого качества и сделать максимально удобный продукт для пользователей.
Что еще влияет:
- Пользовательские привычки и паттерны поведения
- Важно тестировать гипотезы, как пользователи будут взаимодействовать с продуктом. А для этого нужно разбираться в моделях поведения каждой группы пользователей.
- С привычками есть очень интересная история — иногда они существуют даже на подсознательном уровне. Например, схема «далее-далее-далее-готово». Это пришло еще из лихих 90х (вспомните установку Winamp или др. прог). Такие программы приучили нас нажимать «далее», особо не вчитываясь в суть написанного в окне. И точно так же мы реагируем на всплывающие окна: не так важно, что там написано — главное: «закройся и не мешай!».
Почему это важно? Если вам нужно, чтобы пользователь что-то выбрал или прочитал (прям прочитал) — то нужно выделить это/обратить внимание, иначе он все пропустит, по привычке жмакая «далее», пока не дойдет до кнопки «готово».
Пожалуй, главное в привычках то, что люди — существа привычек. Поэтому любые изменения в функционале и интерфейсе должны быть поэтапными и мягкими.
Есть, конечно, привычки неизменно любимые всеми. Легендарная борьба за стену в VK — «Дуров, верни стену». Другой пример, когда Microsoft избавились от кнопки «Пуск» в Windows 8, это вызвало возмущение пользователей. Реакция была настолько суровой, что Microsoft восстановили кнопку «Пуск» в Windows 8.1, хотя и не то, что было.
- Пользовательские особенности
- Здесь необходимо учитывать много характеристик: от демографических особенностей до индивидуальных. Например, если это платформа для детей с играми и набором очков, то нужно понимать, что в семье может быть несколько детей, поэтому для каждого ребенка должна быть возможность сделать персонализированный игровой аккаунт с индивидуальным набором баллов.
- Существует куча полезных прог, которые помогают учитывать индивидуальные особенности, например, Funkify — расширение для Chrome, которое позволяет разработчику взглянуть на веб с точки зрения людей с ограниченными возможностями.
Качество — это не только про отсутствие багов. Это еще и про удобный, понятный для пользователя продукт. А чтобы он был таким, нужно на начальных этапах думать о том, для кого вы это делаете, учитывать их особенности и отдавать себе отчет, зачем пользователю нужна та или иная фича.
Но с багами тоже лучше не косячить.
Грех 3: тестировать как попало
А теперь любимое — тестирование и QA, которыми так часто пренебрегают или уделяют недостаточно внимания. Давайте начистоту: вам не нужно QA и тестирование, если у вас нет пользователей или вы ничего не делаете. Во всех остальных случаях, скорее всего, вам нужно.
Как может выглядеть тестирование в команде, или кто тестирует:
- Разработчики
Тестированием занимается разработка. По идее, все логично — сами написали, сами протестируют. На небольших и несложных проектах этого бывает достаточно.
Плюсы:
- Экономия бюджета на тестировщиках;
- Экономия времени на дополнительном тестировании;
- Погруженность разработчика в специфику продукта.
Минусы:
- Дополнительная нагрузка на разработчиков;
- Вероятность некачественного тестирования. Для качественного тестирования у разработчика должны быть навыки в тестировании и понимание логики поведения пользователей;
- Необъективная оценка. Здесь влияет сразу несколько факторов: разработчик знает, как все должно работать, и это мешает смотреть на продукт глазами пользователей, которые не знают как устроена программа. И второе, создателю тяжело критически смотреть на свое творение, что тоже влияет на объективность.
- Штатный тестировщик или команда QA
В команде может быть как один/несколько тестеров, так и по харду — целая QA-команда.
Плюсы:
- Погруженность в специфику проекта;
- Минимизация рисков в качестве IT-продукта;
- Распределенная нагрузка команды. Каждый сфокусирован на своей задаче;
- Сработанная команда. Все уже знают друг друга и умеют работать вместе — не нужно выстраивать процессы (но это не точно).
Минусы:
- Уровень загрузки и з/п. Часто руководители не понимают, за что платить штатным тестерам. На одном продукте у них, обычно, не так много задач, отсюда и складывается впечатление, что они ничего не делают. Хотя это не так.
- Узкий кругозор. Не хочу обидеть коллег, но, как правило, если тестеры сидят на одном продукте, то заточены под него, соответственно их багаж знаний ограничен. Если прилетит задача с другим видом тестирования — могут возникнуть проблемы, потому что нет опыта и навыков.
- Тестировщик или QA-команда на аутсорсе
Тут много вариантов: один или несколько тестеров, целая команда с QA-лидом или QA-лид в команду штатных тестеров. Тестировщики могут быть как отдельной проектной командой, так и работать со штатными тестерами, если расширился продукт или необходима дополнительная помощь.
Плюсы:
- Большой бэкграунд. Аутсорс команды работают с разными проектами и повидали в этой жизни если не все, то многое. У них широкий кругозор и сильные скиллы в тестировании.
- Дешевле, чем штатный тестировщик. Штатному товарищу вы обязаны выплачивать ежемесячную оплату, независимо от того, сколько он и чего сделал. С аутсорс командой работа идет проектно или по часовой оплате.
Минусы:
- Время на погружение в специфику продукта. Возможно, им понадобится больше времени, чтобы изучить продукт — все зависит от подготовки QA-команды;
- Некачественное исполнение/проблемный поставщик;
- Разногласия с командой разработки. Эта проблема бывает и у штатных тестировщиков. Здесь все зависит от опыта и soft skills.
Если вы задумались, нужна или не нужна вам дополнительная помощь, тестировщик или команда QA, и что это вообще такое, то стоит разобраться. Для этого мы с командой сделали небольшой тест, чтобы всего за восемь вопросов вы могли еще раз убедиться, надо оно вам или нет. Сорян, но там не будет сбора почт и выскакивающих баннеров про уникальность наших услуг. Тест сделан не для этого. Если пройдете его и узнаете для себя что-то новое — круто. Если нет, значит — не круто.
Коротко о главном
Любая экономия времени или сил на качественном тестировании и QA всегда несет риски аукнуться письмами «любви» от клиентов или запахом горящих стульев из отдела службы поддержки. Заботьтесь о своих пользователях, старайтесь сделать для них лучший и удобный продукт. Именно такие продукты завоевывают сердца и рынки. А для этого надо быть внимательнее к качеству, не экономить на проверке и думать о своих пользователях.