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

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

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

Идеи

Источники

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

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

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

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

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

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

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

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

Обработка запросов на изменение

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

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

Управление функционалом продукта

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

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

Классификация запросов на изменения и финансы

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

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

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

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

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

DevOps

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

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

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

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

Источник: habr.com