Меня зовут Виктор Попов, я — технический руководитель продукта CI/CD в Samokat.tech. Мы с командой разрабатываем там комплекс CI/CD инструментов. Это единый продукт, который должен удовлетворить потребности продуктовых команд. Правда, не так просто разобраться, а удовлетворяет ли. Чтобы это понять, нужна коммуникация. А коммуникацию я очень люблю! А ещё всё, что связано с пользователями и построением процессов. Кажется, в этой роли я даже полезнее, чем в инженерной.
Только давайте сразу разделим понятия пользователи и комьюнити. У каждого продукта есть пользователи, но не у каждого — комьюнити. Это не одно и то же. Пользователи из разных сообществ помогают генерировать ценные, полезные советы по продукту. Например, сегодня комьюнити фронтендеров приходит и говорит, что фронтенд неудобно катить через наш CI/CD. Это резонная обратная связь, которая помогает менять продукт в лучшую сторону. А завтра люди из этого комьюнити придут к лиду разработки фронтенда и предложат обновить версию JS или переехать на другой фреймворк. Вроде бы и там и там обратная связь, только с разными отделами. Но это уже будет фидбек от пользователей, а не от комьюнити в целом. Поэтому предлагаю разобраться, как работать именно с пользователями, чтобы получать полезную обратную связь и понимать что с ней дальше делать.
Как работать с обратной связью
У нас в продукте стандартный пул программных инструментов: Gitlab, Argo CD, Harbor, Nexus и так далее. Но пользователям не нужен Gitlab или Argo CD сам по себе. Им нужно конечное решение, с помощью которого они смогут понятным образом доставлять свой код до разных сред. Причём делать это удобно и безопасно, чтобы все участники процесса были довольны.
Наша команда позиционирует эти инструменты как продукт, который их склеивает и превращает в сервис. Так получается готовый и понятный централизованный конвейер CI/CD с учётом требований разработчиков, наших рекомендаций и лучших практик индустрии.
У нашего продукта есть понятные бизнес-задачи, например:
Предоставлять интерфейс для красивого и удобного деплоя в 100500 дата центров;
высокоуровнево смотреть за всем этим;
централизованно приводить в порядок процессы CI/CD.
Но компания порой растёт быстрее, чем некоторые предоставляемые нами сервисы. По качеству услуг и поддержки эти сервисы начинают отставать от других. А это значит, что нашим продуктам нужен уход и тримминг, но порой без обратной связи от пользователей понять, что какой-то сервис проседает по качеству, очень сложно. Откуда мы получаем эту обратную связь?
У нас есть публичный роадмап: что и когда мы делаем, какие задачи стоят перед командой. А ещё наши пользователи могут поучаствовать в планировании задач и рассказать, что бы хотели видеть в будущем. Мы оцениваем всю обратную связь и берём задачи в работу с определенными сроками. Или же поясняем, почему задачу взять не получается и предлагаем альтернативные решения.
А ещё есть «коллективное сознательное» в виде чатов и тредов. Туда периодически врываются пользователи с хорошими идеями. Без всякой иронии! Хороших идей действительно хватает.
Сейчас мы не проводим опросы удовлетворенности пользователей, но планируем собирать такую обратную связь в будущем. Из-за этого какая-то часть фидбека пролетает ниже радаров, но это не слишком критичные проблемы на исправление которых не факт, что хватило бы ресурсов. Все наиболее острые проблемы и пожелания к новым фичам, либо довольно очевидны, либо пользователи подсвечивают их самостоятельно.
Негатив сообщают чаще, и это нормально
Люди чаще приходят с негативной обратной связью. В этом нет ничего странного, ведь у пользователей есть ожидания от сервиса. Если они совпадают с реальностью, никакой обратной связи нет. Зачем? Ведь и так всё хорошо! Пользователь получил обещанное. Он доволен и благополучно о вас забыл.
Вот если ожидания не совпали, тогда есть вероятность, что пользователь об этом расскажет. Чем больше разрыв между тем, что он хотел, и тем, что получил — тем больше вероятность получить отзыв. Ожидания обычно слегка завышены, поэтому сделать большой разрыв между ними и реальностью в положительную сторону довольно сложно, но и так бывает. В итоге пользователи всем рассказывают, какой хороший сервис и как они довольны.
Зато не оправдать ожидания пользователя — легко. Поэтому плохой обратной связи всегда больше. С ней сложнее работать, там часто много эмоций, но ценности тоже больше. Представьте, что пришёл человек и сказал, что у него с вашим продуктом всё хорошо. Какая от этого польза? Только проверить свой внутренний компас: да, мы двигаемся в правильном направлении.
Положительная обратная связь ценна с точки зрения мотивации, а отрицательная — с точки зрения продукта. Важно понимать корневую проблему негатива: что случилось и почему. И не забывать, что негатив делится на две категории: конструктивный и нет.
Неконструктивный негатив обычно происходит не по вашей вине. Бывает, что у человека не задался день: поцарапала кошка, ребёнок заболел, в автобусе нахамили. Он приходит на работу — а там ещё и ваш сервис тупит. Это становится последней каплей и он пишет всё, что думает о вас и вашем сервисе. С одной стороны обычно с вашим сервисом всё не настолько плохо, как вам расскажут, а с другой — ну а чего он тупит в неподходящий момент?! Поэтому не забывайте, что пользователь не желает зла лично вам. Просто так сложились обстоятельства. Не надо принимать всё это близко к сердцу.
Лучше попытаться извлечь пользу даже из такого фидбека. Ведь человек злится на ваш сервис не без причины. В идеале такого пользователя, фигурально выражаясь, нужно обнять, укрыть пледом, напоить чаем и за душевным разговором выяснить, почему ваш продукт стал для него последней каплей. Это сложно и не всегда стоит трудозатрат. Если ресурсы на такую работу с обратной связью есть, то скорее всего пользователь уйдет невероятно лояльным и восторженным. Если же нет — хотя бы подумайте, насколько далеко может распространиться этот негатив и нужно ли что-то с этим делать.
А вот конструктив пользователи обычно сообщают тогда, когда искренне хотят помочь сделать продукт лучше и видят простор для улучшения. В этом случае стоит запланировать работу по устранению недостатков и всё исправить. Конечно, бывает и другая причина. Пользователь просто не понимает, как что-то работает в продукте. Это тоже ваше упущение: значит, до него вовремя не донесли информацию об ограничениях при работе с сервисом. Или, возможно, у этого пользователя нетипичные требования, которые по каким-то причинам невозможно выполнить. В этом случае вы сможете объяснить в чём суть проблемы и почему с ней ничего нельзя сделать. А заодно поправить интерфейс сервиса и документацию так, чтобы у остальных пользователей в аналогичной ситуации подобный вопрос уже не возникал.
Даже если проблема очень редкая, её стоит внести в бэклог и дать пользователю номер тикета. Тогда, если вдруг появится возможность её решить, он об этом узнает. Важно не отрицать опыт пользователя и не утверждать, что у всех остальных всё работает, а он просто не разобрался в интерфейсе.
Мне кажется, давать реакцию нужно всегда. Правда, многое зависит от ресурсов и масштаба. Когда вашим сервисом пользуются сто человек, можно выслушать каждого. Получится очень крутая работа с обратной связью и ожиданиями. Но если это сервис на сто тысяч человек, ответить каждому — сложно. С ростом масштаба теряется персональный подход, и с этим трудно что-то сделать. Это нужно просто принять.
Конечно, ни одно письмо с обратной связью не должно остаться неотвеченным. Но даже если нанять много сотрудников поддержки, то их ответы всё равно будут стандартизированными. А от письма с пометкой, что оно написано роботом — не факт, что кому-то станет лучше. Можно ли сделать всё по-настоящему хорошо в больших масштабах, я не знаю. Вероятно, если и можно, то это не всегда экономически целесообразно.
Что делать с ожиданиями
Не забывайте, что у пользователей есть опыт, о котором вы не знаете. Может он работал с похожей системой и ожидает от вашего продукта аналогичной реакции на его действия... Или же у вашего сервиса есть требования по компетенциям для того, чтобы им пользоваться, а у сотрудниках этих знаний просто нет и он даже не знает, что они нужны.
Конечно, бывают и случаи целенаправленного хейта, но это скорее исключение. Обычно это фрустрация, за которой стоит несовпадение ожиданий с реальностью. Поэтому фрустрированных пользователей много, а плохих — единицы.
Несовпадение ожиданий и реальности в большей или меньшей степени будет всегда. Все ждут от продукта, что он будет работать идеально, даже если сам пользователь не до конца понимает, что вообще это значит. Часто разные пользователи могут представлять разный пользовательский опыт от вашего продукта, причем порой даже диаметрально противоположный. Что хорошо для одного пользователя, плохо для другого. Это ещё один факт, который нужно просто принять. Чаще всего ваш продукт должен подходить большинству, а остальным нужно объяснять почему всё работает именно так и чем обоснованы ограничения в его работе.
В идеальном мире, чтобы решить эту проблему, можно разносить пользователей по разным интерфейсам — например, упрощенный, и для продвинутого уровня. Но в мире реальном это обычно невыполнимо с экономической точки зрения.
На мой взгляд, правильнее отыскать золотую середину. Например, у вас есть сервис приёма заявок. Определённый процент заявок неправильно заполнены. Если их несколько штук в год, ничего с этим делать не нужно. Их проще исправить вручную или лично проконсультировать пользователей. Но если процент ошибочных заявок большой и отнимает много времени поддержки, скорее всего, есть проблемы с интерфейсом и ожиданиями пользователей и их стоит исправить.
Очень важно не делать предположений за пользователя. Поверьте, вы знаете своих пользователей хуже, чем вам кажется. Вы работаете со своей системой постоянно и, конечно, понимаете её лучше, чем пользователи. Поэтому взглянуть на проблему их «глазами» довольно сложно. В этом плане отлично помогают люди, которые недавно работают в компании. Можно попросить их воспользоваться вашим сервисом и собрать обратную связь.
Зачастую люди, предоставляющие сервис, этим сервисом не пользуются. Например, если вам нужен репозиторий в gitlab, которым вы управляете, вы скорее всего не создаёте заявку, а просто создаёте себе репозиторий. Потому что так проще и быстрее. Если вы сами избегаете использовать собственный сервис, то как вы можете оценить опыт его пользователей?
Ещё стоит обратить внимание на контракты ваших сервисов. Контракты формально фиксируют, что вы обещаете пользователям и что от них требуете. Другой важный аспект работы с ожиданиями — явно прописывать, что вы не обещаете.
Разъяснительная работа
Важно не забывать о коммуникации с пользователями. Вообще, я продвигаю максимальную прозрачность состояния продукта. Конечно до тех пор, пока это не нарушает требования безопасности.
Если у вас есть проблемы — пользователи о них узнают. И лучше от вас и с тем контекстом, который хотите донести вы, а не как-то иначе.
Например, хорошее решение — сделать роадмап публичным. С его помощью люди смогут посмотреть и узнать, над чем вы работаете сейчас и что планируете сделать в ближайшем и отдаленном будущем. Ещё отличная идея — выпускать регулярные дайджесты и таким образом рассказывать про новые фичи и решённые проблемы. Это показывает, чем вообще занимается ваша команда, повышает доверие к команде. Ведь пользователи начинают понимать объёмы и сложности задач, которые для них могут казаться очень простыми. Вообще, тема коммуникации с пользователями довольно большая, и я про это рассказывал на HL 2021. Можно посмотреть вот тут: или почитать вот тут и тут.
У меня есть такой пример из жизни. Знакомый работал в офтальмологической клинике в Краснодаре. Чтобы собрать обратную связь, сотрудниц ресепшн попросили записывать все вопросы, которые им задают. Так они обнаружили, что на третьем этаже нет таблички «туалет». Поэтому там спрашивали о его местонахождении раз двадцать в день, а на других этажах таких вопросов не возникало вообще. А так как сотрудники знали где туалет, то отсутствие таблички просто не замечали.
В разработке тоже так бывает. Например, у вас есть классные фичи, но пользователи о них не знают. Они могут даже не осознавать, что у них есть проблемы, которые эта фича могла бы решить!. Если вы сообщаете им, что есть кнопка, которая помогает выполнить задачу быстрее, то получите позитивную реакцию и снизите фрустрацию.
Сейчас все начали массово переименовывать внутренние IT сервисы в продукты. Нередко встречается ситуация, когда тимлида инфраструктурной команды переименовывают во владельца продукта. И эти тимлиды часто не понимают, что же им в этой роли делать. Ведь это область знаний, в которой за 15 минут не разберёшься.
Конечно, есть полезные инструменты и методологии, которые можно освоить довольно быстро. Вот только «быстро» тоже бывает разное. Например, в ИТМО учатся в магистратуре на product owner за два года. А компании хотят обучить этому сотрудника месяца за три. На конференции DevOps Conf я расскажу, что значит «внутренний продукт» и что делать, если на вас «надели шапочку» владельца продукта.
