Хабрахабр

Как мы выбираем идеи для развития своих продуктов: вендор должен уметь слышать…

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

Срок
жизни нашего продукта 14 лет. Мы разрабатываем автоматизированную систему расчетов (АСР) – биллинг. Один из важнейших аспектов долгой жизни для программ – постоянное развитие. За это время система прошла путь от первых версий промышленного тарификатора до модульного комплекса, состоящего из 18 продуктов, дополняющих друг друга. А для развития нужны идеи.

Идеи

Источники
Можно выделить 5 источников:

  1. Главный друг разработчика корпоративных информационных систем – это клиент. А клиент – это собирательный образ из ЛПРов, спонсоров проекта, владельцев и исполнителей процессов, инхаус айтишников, рядовых пользователей и еще большого количества в разной степени заинтересованных личностей. Для нас важно, что каждый из представителей клиента потенциально является поставщиком идей. В худшем случае мы получаем только негативную обратную связь о проблемах в системе. В лучшем – со стороны клиента находится человек, который является постоянным источником идей для улучшения, предоставляющий структурированную информацию о потребностях клиента.
  2. Наши продавцы и аккаунт-менеджеры являются вторым по важности источником идей для улучшения. Они много и активно общаются с представителями отрасли, из первых рук получают запросы о функционале биллинга от потенциальных клиентов. Продавцам и аккаунтам приходится быть в курсе всех значимых изменений своего функционала и последних обновлений софта конкурентов, уметь обосновать плюсы и минусы разных решений. Именно эти наши сотрудники первыми ощущают, если какие-то возможности биллинга становятся де-факто стандартом, без которого софт нельзя считать полноценным.
  3. Владелец продукта — один из наших топ-менеджеров или очень опытный руководитель проектов. Держит в голове стратегические цели компании и корректирует в соответствии с ними планы по развитию продукта.
  4. Архитектор, человек, который понимает возможности и ограничения выбранных/используемых технологических решений и их влияние на развитие продукта.
    Команды разработки, тестирования. Люди которые непосредственно занимаются развитием продукта.

Классификация обращений

От источников мы получаем сырые данные – письма, тикеты, устные запросы. Все
обращения классифицируются:

  • Консультации со смыслом «Как сделать?», «Как это работает?», «Почему не получается?», «Я не понял…». Обращения этого типа уходят на Линию поддержки 1 уровня. Возможна переквалификация консультации в другие типы обращений.
  • Инциденты со смыслом «Не работает» и «Ошибка». Обрабатываются 2 и 3 Линиями поддержки. При необходимости оперативного исправления и выпуска патча могут быть переданы из саппорта сразу в разработку. Возможна переквалификация в запрос на изменение и отправка в бэклог.
  • Запросы на изменения и развитие. Попадают в бэклог продукта, минуя Линии поддержки. Но для них существует отдельная процедура обработки.

Также всплески обращений бывают, когда в наши облачные сервисы приходит новый клиент с большим количеством пользователей. Есть такая статистика по обращениям – сразу после релиза количество обращений вырастает на 10-15% на непродолжительное время. Даже небольшой клиент при начале работы в системе легко сжигает более 100 часов консультаций за месяц. Люди учатся пользоваться новыми возможностями софта, им нужны консультации. Часто даже выделяем конкретного специалиста. Поэтому при подключении нового клиента мы всегда резервируем время на первичные консультации. Период адаптации занимает, как правило, от 1 до 3 месяцев, затем потребность в консультировании существенно снижается. Стоимость аренды, конечно, не окупает эти трудозатраты, но со временем ситуация выравнивается.

Но постепенно перешли на продукты Atlassian. Ранее для хранения обращений мы использовали самописные решения. Сейчас все критичные процессы живут в Jira SD, плюс обеспечиваются различными плагинами к Jira, плюс Confluence. Сначала перевели разработку, чтобы было проще работать по Agile, затем саппорт. Получилось, что задачи у нас теперь сквозные, могут передаваться между поддержкой и разработкой без перепрыгивания из одной системы в другую. Самописные решения остались только на некритичных для деятельности компании процессах.

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

Наш аналитик изучает запрос, формирует спецификацию и ТЗ верхнего уровня. Обработка запросов на изменение

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

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

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

В бэклоге накапливаются поступившие запросы на изменение и развитие. В формате обсуждения совет разбирает и приоритезирует заявки из бэклога и согласует 5 задач по развитию для реализации в ближайшем релизе.

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

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

Разработка обходится дорого.

Мелкие фиксы и индивидуальные запросы обрабатываются без каких-то изысков. Запросы на изменение классифицируем следующим образом: отраслевая потребность или индивидуальная особенность предприятия; существенный объем нового функционала или мелкий фикс. Индивидуальные запросы просчитываются и реализуются для конкретного клиента в рамках проектной работы с ним.

В случае поступления такого запроса от клиента мы можем взять на себя затраты на разработку модуля, клиенту предоставить модуль бесплатно или с частичной оплатой, а сам модуль выставить в общий доступ на продажу. Если это не массовая отраслевая потребность и объем функционала большой, то может быть принято решение о разработке нового отдельного модуля, который будет продаваться дополнительно к основному функционалу. Клиент на себя в такой ситуации берет часть методологической нагрузки и по сути проводит на себе пилотное внедрение модуля.

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

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

В каждом релизе забронировано время на реализацию 5 задач, поступивших от технического совета. DevOps

Разработка готовит два крупных релиза в год. Таким образом за текучкой мы никогда не забываем о развитии продукта.

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

Это промежуточный формат позволят оперативно реагировать на инциденты первых приоритетов и выполнять заявленные SLA. Дополнительно к релизной системе существует формат быстрых багфиксов, чтобы клиенты не жили с ошибками по полгода.

Для облачных сервисов, ориентированных на SMB сегмент, таких широких возможностей для клиентов по участию в развитии продукта нет. Все вышесказанное справедливо в первую очередь для корпоративного сектора и on-premise решений. Вместо change request в виде четких требований от корпоратива здесь только обычная обратная связь и пожелания по сервису. Формат аренды для SMB этого даже не предполагает. Мы стараемся прислушиваться, но продукт массовый и желание одного клиента принести из своей старой исторической системы что-то привычное может противоречить стратегии развития системы в целом.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть