Привет, Хабр! Меня зовут Антон Фоломин, я специалист технической поддержки в команде разработки КОМПАС-3D. Сегодня хочу поговорить о том, как идеи и предложения пользователей помогают развивать продукт.
Какие идеи действительно имеют шансы быть реализованными? Как сформулировать и обосновать предложение? И что происходит дальше с инициативами, которые попадают к нам от пользователей?
Куда направлять предложения
Основной канал для отправки предложений пользователей по доработке и улучшению функциональности продуктов АСКОН – это ServiceDesk. Чтобы оставить сообщение, необходимо зарегистрироваться в системе. Статус своего обращения пользователь всегда может отследить в личном кабинете. Все поступающие через ServiceDesk запросы мы фиксируем и даем на них ответ.
Кроме того, пользователи делятся своими идеями на форуме и в телеграм-чате КОМПАС-3D. Мы отслеживаем эти площадки, однако рекомендую все же писать в ServiceDesk, так предложение гарантировано попадет в поле нашего внимания.
Как с предложениями работают дальше
Сначала предложение поступает на первую линию поддержки. Первая линия – это региональная техническая поддержка (РТП далее по тексту). Ее специалисты работают для того, чтобы пользователи могли в своих часовых поясах обратиться и получить своевременную помощь. В РТП решается основная масса вопросов, происходит первичный анализ предложения и уточняются задачи.
Если первая линия не может решить проблему или предложение не в ее компетенции, сообщение передается на вторую линию — продуктовую техническую поддержку (ПТП далее по тесту). Как раз там работаю я. Отличие от РТП в том, что мы имеем непосредственное отношение к разработке ПО.
Далее, если предложение соответствует всем критериям, понятна цель и задача пользователя, предложение передается дальше в отдел аналитики. В нашей разработке аналитики – это высококвалифицированные специалисты с опытом инженерной деятельности и углубленными знаниями в отдельных областях, решаемых при помощи САПР. Они рассматривают предложение, уточняют данные. По результатам рассмотрения предложение может быть либо отклонено, о чем уведомляют пользователя, либо зарегистрировано в базе ошибок и предложений (БОиП), из которой оно будет реализовано в той или иной форме.
Резюмируя, идеальная схема движения предложения пользователя выглядит так:
Пользователь —> ServiceDesk —> РТП —> ПТП —> Аналитик —> БОиП —> Разработка —> Релиз.
Основные шаги работы с предложениями:
Сбор предложений: ServiceDesk.
Анализ и уточнение: РТП — ПТП — Аналитик.
Регистрация в базе предложений: Аналитик.
Реализация: Аналитик — Разработка.
Обратная связь: Аналитик — РТП, альфа-тестирование продукта, бета-тестирование.
Мониторинг: ServiceDesk, форум пользователей, телеграм-чат.
Категоризация предложений от пользователей
Пользователи присылают нам самые разные идеи об улучшении продуктов. Я их условно разделяю на четыре категории:
1. Функциональность для решения поставленной задачи есть, но пользователю нужно подсказать, где ее найти.
Специалисты технической поддержки всегда рады с этим помочь, также могут выручить наши справочные материалы: Азбука КОМПАС, вебинары и видеокурсы с сайта https://kompas.ru/publications/video/
2. Функциональность есть, но пользователь пытается решать задачу «по-старому», привычным инструментом из другой системы.
Привычка, как говорится, вторая натура. В данном случае задача специалистов техподдержки – донести до пользователя все имеющиеся способы решения поставленной задачи, попутно работая с возникающими возражениями.
3. Функциональность есть, но требует выполнения дополнительных действий.
В программе предусмотрена возможность решения задачи, однако иногда она требует дополнительных шагов, что пользователи могут называть “костылями”. Такие ситуации вполне допустимы. Важно, чтобы в процессе общения с пользователем было найдено рабочее решение, а при наличии идей по улучшению процессов они обязательно фиксировались и передавались на рассмотрение.
4. В продукте нет требуемой функциональности.
Если в системе отсутствует возможность решить задачу, важно детально проработать поступившее предложение. Недостаточно просто переслать текст пользователя — требуется корректное сформулировать и уточнить детали для дальнейшего анализа специалистами второй линии поддержки и аналитиками.
Задача специалистов первой линии – определить, к какому из описанных случаев относится обращение, и выстроить дальнейшее взаимодействие с пользователем.
Если функциональность отсутствует или решение требует доработки:
необходимо получить от пользователя точное и однозначное понимание решаемой задачи и предлагаемый им алгоритм работы;
будет полезным найти аналоги программ с необходимой функциональностью, если такие имеются, и сделать отсылку на них в составленном предложении. Только в качестве дополнительной иллюстрации, а не как руководство к действию;
возможно, что задачу пользователя можно решить, например, с помощью API. Если так, то предложить вариант такого решения.
Примеры предложений от пользователей
Специалисты РТП зачастую передают предложения пользователей без внесения уточнений. Вот пример заявки от пользователя, которая вряд ли будет рассмотрена отделом аналитики:
“Здравствуйте, прошу добавить в КОМПАС-3D возможность проставлять буквенные обозначения к позициям на чертеже автоматически. Пример: поз. 1А, поз. 1Б и т.д.”
В этом предложении нет главного – обоснования предложения. Будь то необходимость соответствия меняющимся ГОСТам или нечто другое, всегда должно быть понимание конечной задачи пользователя. Когда проблема изложена непонятно или неоднозначно, мы не можем ее решить.
Внутри команды у нас действует такая формулировка предложения, передаваемая сотрудником РТП коллеге из ПТП. Для рассмотрения она должна содержать следующее:
Исходные данные: точные, полные, желательно конкретные (из реальной работы клиента).
Конечный результат.
Решаемая задача.
Обоснование – почему необходима реализация.
Цель – что хочет получить клиент после реализации.
Если предложение соответствует всем этим критериям, оно абсолютно точно будет зарегистрировано. Либо вам скажут, что решение будет реализовано уже в разрабатываемой новой версии продукта.
Итоги
Резюмируя все вышесказанное:
Работа с предложениями пользователей является неотъемлемой частью процесса разработки и требует тесного взаимодействия на всех уровнях.
Если функциональность отсутствует или нуждается в доработке, важно получить от пользователя четкое описание задачи и ожидаемого результата: начальные условия —> предполагаемые действия —> итог.
Если решение уже есть, оно должно быть предоставлено пользователю в максимально понятной форме.
Главная цель при работе с предложениями – понять суть задачи. Чем яснее пользователь формулирует конечную цель, тем эффективнее техническая поддержка сможет ее рассмотреть и предложить оптимальный путь решения.
При работе с предложениями для нас важнее всего – понять, чего именно хочет достичь пользователь. Если цель сформулирована ясно и передана в техподдержку, предложение обязательно будет рассмотрено.
«Самая главная вещь при разработке программ – ясно представлять конечную цель»
— Бьёрн Страуструп, датский программист, автор языка С++.