Мы развиваем облачную систему службы поддержки Okdesk. Наши принципы работы — не «впаривать», а решать реальные проблемы среднего и малого бизнеса в части сервисного обслуживания. Именно поэтому мы уделяем пристальное внимание развитию возможностей продукта.
В разработке системы мы находим баланс между планами развития на несколько лет вперёд и текущими «хотелками» наших активных пользователей. Очевидно, что нужно поддерживать как лояльность тех, кто уже доверил нашему сервису свой бизнес (улучшать созданные функции, повышать удобство работы и т.д.), так и развивать те функциональные блоки, которые ориентированы на компании, чьи проблемы мы решаем не в полной мере.
Задача кажется легкой, если у вас есть большое количество рук, голов и времени — но в реальности всё обстоит иначе.
В этой статье подробный рассказ, о том, как мы решаем описанные выше проблемы.
Баланс между крупными функциями и улучшениями в разработке
Разработку ИТ-решения логично сравнить со строительством здания.
В начале — проект здания, затем закладка фундамента, возведение несущих конструкций и проведение коммуникаций.
Когда «коробка» готова — вы сможете в ней укрыться от ливней и жаркого солнца, в конце концов согреться зимой (при наличии отопления). Однако для комфортного проживания нужно коробку «обжить» — сперва разобраться с внутренней планировкой, сделать ремонт, купить и установить мебель. Очевидно, что планировку, отделку и создающие уют, но не столь важные вещи, вы можете изменять или добавлять уже проживая в здании без его перестройки.
Так и в «строительстве» ИТ-системы (в нашем случае — системы службы поддержки).
Всегда есть верхнеуровневое видение развития, зафиксированное на уровне крупных блоков.
Это видение основано на реальных проблемах и задачах клиентов, на решение которых, собственно и ориентирован продукт. При разработке такого плана анализируется рынок, конкуренты, проводятся маркетинговые исследования и интервью с клиентами (например, мы опросили около 500 сервисных компаний разных масштабов и специфики). Верхнеуровневый план может и должен изменяться при получении обратной связи от рынка — но не радикально (разве что в плане приоритетов).
Серьезное изменение плана возможно, но только со сменой концепции всего проекта.
Если нет основных функциональных «кирпичей», практически невозможно формулировать верные требования более низкого уровня — к интерфейсу, простоте и удобству использования, другим функциям, входящим в блок.
Когда реализована первая версия большого функционального блока и начато использование разработанных функций, у создателей продукта накапливаются «хотелки» по их дальнейшему развитию — через призму собственного опыта, а также на основании обратной связи от активных клиентов (подробности ниже).
Таким образом, в backlog-е продукта есть крупные «стратегические» блоки, и накапливаются задачи по улучшению созданных ранее функций меньших масштабов. Новые и большие модули важны для расширения областей использования продукта (выход на новые отрасли, целевые аудитории и т.д.). Улучшения необходимы для удобной и полноценной работы в системе (рост лояльности текущих клиентов и сокращение оттока).
Для сохранения баланса между крупными блоками и «улучшайзерами» наш продуктовый backlog разделен по типам задач. При этом в каждый релиз мы включаем задачи всех типов: как правило, одну большую и несколько улучшений сделанного ранее. Так, развитие нашей системы службы поддержки идет «по двум направлениям». Это позволяет повышать удовлетворенность действующих клиентов и привлекать новых, чьи задачи мы ранее мы не могли автоматизировать.
Пожелания клиентов — важный аспект разработки продукта
Обратная связь от пользователей — важный источник ключевых требований к развитию системы службы поддержки. Абсолютно все пожелания фиксируются и анализируются. Именно на их основе в дальнейшем мы принимаем решение о реализации новых возможностей.
Нет сомнений, что feedback от пользователей важен. Однако, здесь есть одно существенно «но». В текущем контексте пользователи бывают принципиально двух типов — платные и не клиенты.
Когда «не клиенты» тестируют систему, они часто дают обратную связь в виде списка требований в стиле: «доработайте это... и тогда я заплачу».
Мы никогда не беремся за реализацию таких «хотелок».
Ведь чаще всего подобные пожелания не являются причиной отказа в оформлении подписки на сервис. Причина на самом деле бывает любой: от «нет денег» до «устраивает текущее положение дел».
Наша статистика неумолима — процент тех, кто просто не начинает использование любого платного сервиса даже в течение года достаточно высокая.
Поэтому, если пользователь говорит «я бы купил, если бы вы сделали...», мы отвечаем «мы сделаем, если вы купите...». Когда такой пользователь становится клиентом — с его требованиями мы начинаем работать полноценно. В качестве вывода: настоящую ценность имеют пожелания, тех, кто перешел на этап «Успешная продажа» в воронке продаж. У клиентов нет причины, чтобы искать изъяны или недоделки. Они сообщают о том, что им мешает или чего не хватает в системе в рамках ежедневной работы и бизнес задач.
Необходимо понимать, что за сформулированным пожеланием клиента всегда скрывается реальный сценарий использования системы. А текст присланного требования — ни что иное, как сформулированный вариант решения его проблемы.
Проблема заключается в том, что вариант решения придумывает тоже клиент, иногда «на ходу» и почти всегда без системного подхода. И, конечно, подобное решение зачастую не оптимально, тем более для системы, которой пользуются сотни других компаний.
Именно поэтому мы всегда уточняем реальный сценарий использования и сложность, с которой столкнулся пользователь. Этот подход позволяет придумать оптимальное системное решение проблемы, которая, с большой вероятностью, рано или поздно возникла бы и у других клиентов.
Реализация пользовательских требований «как есть» со временем превращает систему в непригодный набор «заплаток» (каким, к сожалению, становятся через пару лет большинство решений).
Во второй части мы поделимся реальными клиентскими «хотелками» и о том, как мы их решали. А также расскажем как у нас устроен процесс разработки и какие инструменты мы для этого используем!
