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